44 lines
3.7 KiB
Markdown
44 lines
3.7 KiB
Markdown
# Research: Workspace, Tenant & Managed Object Lifecycle Governance v1
|
|
|
|
## Decision 1: Implement the deferred candidate as a standards contract, not a runtime engine
|
|
|
|
- **Decision**: Keep this v1 on the standards-and-contract path only.
|
|
- **Rationale**: The deferred candidate explicitly says the smallest useful v1 is to define taxonomy, naming rules, state boundaries, audit expectations, OperationRun expectations, retention boundaries, and implementation guardrails before destructive runtime work proceeds.
|
|
- **Why this is enough**: The repo already has several lifecycle-bearing runtime slices. What is missing is the contract that tells future slices how those meanings fit together.
|
|
- **Alternatives considered**:
|
|
- immediate tenant archive/delete implementation: rejected because the deferred candidate explicitly excludes it
|
|
- broad lifecycle service or registry: rejected as premature abstraction
|
|
|
|
## Decision 2: Reuse existing bounded specs as authorities per lifecycle dimension
|
|
|
|
- **Decision**: Treat Specs 143, 251, 261, and 091 plus current retention/expiry surfaces as the authoritative current repo inputs.
|
|
- **Rationale**: These specs already codify the runtime meanings that the taxonomy must classify. Reopening them here would duplicate scope.
|
|
- **Alternatives considered**:
|
|
- define lifecycle dimensions from roadmap prose alone: rejected because the candidate requires repo truth
|
|
- infer lifecycle meanings directly from models without the spec layer: rejected because some meanings already live in spec packages, not only runtime code
|
|
|
|
## Decision 3: Keep the lifecycle dimensions orthogonal
|
|
|
|
- **Decision**: Define exactly six lifecycle dimensions for v1: local record lifecycle, provider presence lifecycle, operator suppression lifecycle, commercial/workspace lifecycle, retention/compliance lifecycle, and restoreability lifecycle.
|
|
- **Rationale**: These are the minimum dimensions needed to answer the deferred candidate's mandatory questions without collapsing meanings.
|
|
- **Alternatives considered**:
|
|
- a single generic lifecycle axis: rejected because it would recreate the current ambiguity
|
|
- more than six dimensions: rejected as broader than current repo truth requires
|
|
|
|
## Decision 4: Distinguish current repo-real values from reserved follow-up values
|
|
|
|
- **Decision**: The taxonomy will name reserved future values where the deferred candidate requires them, but it will mark them as follow-up-only when the repo does not yet model them.
|
|
- **Applied distinction**: `export requested` is named as a reserved retention/compliance value in v1, while the workflow that satisfies that request remains part of `Data Export Before Deletion v1`.
|
|
- **Rationale**: This keeps the package useful for planning without pretending the runtime already owns meanings it does not.
|
|
- **Alternatives considered**:
|
|
- model every listed candidate value as repo-real now: rejected as false product truth
|
|
- omit reserved values entirely: rejected because the deferred candidate explicitly asks for future lifecycle boundaries
|
|
|
|
## Decision 5: Use one transition-governance matrix to answer safety and observability questions
|
|
|
|
- **Decision**: Define one matrix describing confirmation, audit, OperationRun, and export/retention preconditions per lifecycle dimension.
|
|
- **Applied distinction**: The matrix records when irreversible transitions depend on export or retention preconditions, but it does not invent the export workflow itself.
|
|
- **Rationale**: The candidate's core risk is unsafe destructive or retention-sensitive follow-up work. One matrix is the narrowest cross-domain answer.
|
|
- **Alternatives considered**:
|
|
- leave safeguard choices to each future spec independently: rejected because that is the current failure mode
|
|
- define runtime handlers now: rejected because this v1 is non-runtime |