TenantAtlas/specs/262-lifecycle-governance-taxonomy/spec.md

# Feature Specification: Workspace, Tenant & Managed Object Lifecycle Governance v1

**Feature Branch**: `262-lifecycle-governance-taxonomy`  
**Created**: 2026-05-01  
**Status**: Approved for implementation on the standards-and-contract path only  
**Input**: User description: "Promote the deferred lifecycle-governance candidate explicitly and prepare a tightly scoped, taxonomy-first spec package without implementing deletion, purge, or provider-specific runtime behavior."

## Spec Candidate Check *(mandatory — SPEC-GATE-001)*

- **Problem**: TenantPilot already carries real lifecycle semantics across tenants, workspace commercial posture, provider-missing policy truth, backup schedule archive/force-delete, review-pack expiry, restore continuity, and audit history, but those meanings are still scattered and can be locally overloaded.
- **Today's failure**: A future feature can still confuse `archived`, `deleted`, `ignored`, `missing from provider`, `expired`, `suspended read-only`, `retained`, or `restorable` because there is no single lifecycle taxonomy saying which dimension owns which meaning, which source is authoritative, and which transition rules apply.
- **User-visible improvement**: Future destructive, retention-sensitive, and recovery-sensitive features can land with one truthful lifecycle vocabulary, one transition-governance matrix, and one explicit follow-up map instead of reusing the wrong field or label locally.
- **Smallest enterprise-capable version**: Define a taxonomy-first lifecycle governance contract that classifies the existing repo-real lifecycle dimensions, names their authoritative sources, answers the deferred candidate's mandatory questions, and sets follow-up boundaries for runtime work without opening any deletion or purge implementation.
- **Explicit non-goals**: No workspace deletion flow, no tenant deletion flow, no purge engine, no retention executor, no review-pack or evidence rewrite, no `SoftDeletes` rollout, no reinterpretation of `ignored_at`, no provider-missing rollout beyond Spec 261, no commercial-lifecycle runtime work beyond Spec 251, no lifecycle dashboard, no new panel, no new asset strategy, and no application-code mutation in this v1 contract slice.
- **Permanent complexity imported**: One shared lifecycle taxonomy, one transition-governance matrix, one standards-track reference target, one bounded follow-up map, and explicit review/test-governance expectations for future specs. No new product persistence, runtime engine, or UI framework is introduced.
- **Why now**: The active queue was intentionally emptied for automatic next-best-prep, but this candidate was preserved for explicit promotion once the repo had enough concrete lifecycle examples to justify a taxonomy-first package. Specs 143, 251, 261, and 091 now provide exactly that evidence.
- **Why not local**: The deferred candidate's mandatory questions span workspace state, tenant state, provider presence, suppression, retention, and restoreability. A page-local or model-local fix would reopen the same ambiguity instead of bounding it.
- **Approval class**: Core Enterprise
- **Red flags triggered**: New cross-domain taxonomy, broad lifecycle language, and lower immediate end-user visibility than a normal workflow slice. Defense: the package stays contract-only, reuses existing repo-real slices as its only inputs, introduces no runtime engine or new persistence, and exists specifically to stop future destructive work from overloading the wrong meanings.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 1 | Produktnähe: 1 | Wiederverwendung: 2 | **Gesamt: 10/12**
- **Decision**: approve

## Spec Scope Fields *(mandatory)*

- **Scope**: workspace + tenant + canonical-view
- **Primary Routes**:
  - no new runtime route is introduced in this slice
  - the taxonomy governs existing route families that later lifecycle follow-ups may touch, including `/admin/tenants`, `/admin/onboarding/{onboardingDraft}`, `/admin/t/{tenant}/policies`, `/admin/reviews/workspace`, `/admin/t/{tenant}/backup-sets`, `/admin/t/{tenant}/restore-runs`, and `/system/directory/workspaces/{workspace}`
- **Data Ownership**:
  - no new product persistence is introduced
  - the contract classifies existing workspace-owned and tenant-owned truth only: `Tenant`, workspace commercial state from Spec 251, provider-backed managed-object presence from Spec 261, review or report retention signals, and backup and restore continuity truth
  - audit evidence and `OperationRun` responsibilities remain transition-governance guardrails, not separate lifecycle source inventories
  - the lifecycle taxonomy itself is a standards and governance artifact, not a new product table or domain record
- **RBAC**:
  - no new capability or role family is introduced
  - the taxonomy preserves existing isolation rules from the contributing specs: non-member or out-of-scope access remains deny-as-not-found, capability denials remain `403` after scope is established, and future lifecycle follow-ups must not use lifecycle state as an authorization substitute

For canonical-view specs, the spec MUST define:

- **Default filter behavior when tenant-context is active**: This slice introduces no new collection surface. It preserves Spec 143's rule that remembered tenant context is convenience only and must not determine canonical record legitimacy.
- **Explicit entitlement checks preventing cross-tenant leakage**: This slice introduces no new viewer surface. It defines that lifecycle meaning on a canonical workspace record remains subordinate to workspace ownership plus referenced-tenant entitlement rather than to remembered tenant state.

## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*

- **Cross-cutting feature?**: yes
- **Interaction class(es)**: status messaging, badge vocabulary, destructive-action naming, confirmation rules, audit action naming, evidence/report availability wording, and restore or export precondition wording
- **Systems touched**: tenant lifecycle semantics from Spec 143, workspace commercial lifecycle from Spec 251, provider-missing policy truth from Spec 261, reversible archive / irreversible force-delete pattern from Spec 091, review-pack expiry and retention cleanup, backup/restore continuity, and the current audit plus OperationRun governance paths
- **Existing pattern(s) to extend**: existing lifecycle-bearing specs, the standards directory in `docs/product/standards/`, the current audit naming path, and the shared OperationRun UX contract
- **Shared contract / presenter / builder / renderer to reuse**: `BadgeCatalog` / `BadgeRenderer`, `AuditLog` + stable action IDs, current lifecycle-bearing specs and runtime models as authoritative sources, and the standards workflow described in `docs/product/standards/README.md`
- **Why the existing shared path is sufficient or insufficient**: The repo already has the concrete runtime truths and shared standards workflow. What is missing is the cross-domain lifecycle matrix that says how those truths relate and where later slices may extend them safely.
- **Allowed deviation and why**: none. Later slices may document bounded exceptions, but this v1 taxonomy must not create a parallel lifecycle language.
- **Consistency impact**: `archived`, `deleted`, `ignored`, `missing from provider`, `expired`, `retained`, `suspended read-only`, and `restorable` must each map to one lifecycle dimension and must not be used as interchangeable operator-facing labels.
- **Review focus**: Reviewers must verify that the package classifies lifecycle concerns by dimension and source instead of silently importing local runtime behavior or future-state assumptions.

## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)*

- **Touches OperationRun start/completion/link UX?**: yes, as a governance contract only
- **Shared OperationRun UX contract/layer reused**: existing shared OperationRun start UX and lifecycle rules remain authoritative for any future lifecycle transitions that become queued, long-running, or externally mediated
- **Delegated start/completion UX behaviors**: this package defines when future lifecycle work may remain audit-only and when it must use the existing shared `OperationRun` start UX rather than local queued toast/link/event logic
- **Local surface-owned behavior that remains**: later runtime specs remain responsible for their own initiation surfaces; this slice only defines the guardrail for choosing audit-only versus `OperationRun`-backed execution
- **Queued DB-notification policy**: unchanged; future lifecycle slices must use the shared policy already in force
- **Terminal notification path**: unchanged; any future lifecycle run must flow through the central lifecycle mechanism
- **Exception required?**: none

## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*

- **Shared provider/platform boundary touched?**: yes
- **Boundary classification**: mixed
- **Seams affected**: provider presence versus local lifecycle, suppression, restoreability, and retention vocabulary
- **Neutral platform terms preserved or introduced**: `provider missing`, `local suppression`, `archived`, `retained`, `purge due`, `restorable`, `metadata only`, `not restorable`, `suspended read-only`
- **Provider-specific semantics retained and why**: provider-side subtype filtering and provider proof of hard deletion remain provider-owned evidence. The taxonomy only defines their platform effect.
- **Why this does not deepen provider coupling accidentally**: provider presence is only one lifecycle dimension. It is explicitly separated from local record lifecycle, suppression, retention, and commercial state.
- **Follow-up path**: `follow-up-spec` for explicit provider-deleted semantics or multi-object provider-presence rollout beyond Spec 261

## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*

N/A - no operator-facing surface change. This slice prepares a taxonomy and standards package only and must not smuggle runtime UI work into the lifecycle candidate.

## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*

N/A - no operator-facing surface change.

## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*

N/A - no operator-facing surface change.

## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*

N/A - no operator-facing surface change.

## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*

N/A - no operator-facing surface change.

## Proportionality Review *(mandatory when structural complexity is introduced)*

- **New source of truth?**: yes - one lifecycle governance standard and contract artifact
- **New persisted entity/table/artifact?**: yes - a standards/contract artifact only, not a new product table or persisted domain record
- **New abstraction?**: no new runtime abstraction; one governance contract only
- **New enum/state/reason family?**: yes - one cross-domain lifecycle taxonomy that classifies current repo-real and reserved follow-up meanings
- **New cross-domain UI framework/taxonomy?**: yes - taxonomy only, explicitly not a UI framework
- **Current operator problem**: future destructive or retention-sensitive work can still overuse one local field or status label and make false lifecycle claims across operator surfaces.
- **Existing structure is insufficient because**: the current repo truths are correct only within their local slices. There is no one contract saying how tenant lifecycle, commercial state, provider presence, suppression, retention, and restoreability differ.
- **Narrowest correct implementation**: create one taxonomy-first contract that names the dimensions, authoritative sources, transition rules, and follow-up boundaries, then require later runtime slices to consume it instead of inventing new meanings.
- **Ownership cost**: one new standards document, one lifecycle matrix, bounded review overhead, and later follow-up specs that must cite the taxonomy explicitly.
- **Alternative intentionally rejected**: a broader runtime lifecycle engine or immediate archive/delete/closure implementation was rejected because the deferred candidate explicitly forbids it. A local per-feature fix was rejected because it would preserve ambiguity.
- **Release truth**: current-release truth grounded in already repo-real lifecycle meanings, not speculative multi-provider or post-production future-proofing.

### Compatibility posture

This feature assumes a pre-production environment.

Backward compatibility, migration shims, reinterpretation of existing lifecycle fields, and compatibility-specific tests are out of scope unless a later runtime slice explicitly requires them.

Canonical classification of existing lifecycle meanings is preferred over preserving overloaded semantics.

## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*

- **Test purpose / classification**: N/A - docs/standards-only governance package
- **Validation lane(s)**: N/A
- **Why this classification and these lanes are sufficient**: this v1 contract introduces no runtime behavior. Readiness is proved by repo-grounded artifact consistency, checklist review, and targeted repo searches.
- **New or expanded test families**: none
- **Fixture / helper cost impact**: none
- **Heavy-family visibility / justification**: none
- **Special surface test profile**: N/A
- **Standard-native relief or required special coverage**: N/A
- **Reviewer handoff**: reviewers must confirm that the six lifecycle dimensions, transition-governance matrix, and follow-up boundaries line up with Specs 143, 251, 261, 091, current retention surfaces, and the deferred candidate questions with no hidden runtime scope.
- **Budget / baseline / trend impact**: none
- **Escalation needed**: none
- **Active feature PR close-out entry**: N/A
- **Planned validation commands**:
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd /Users/ahmeddarrazi/Documents/projects/wt-plattform && rg -n -- "Workspace, Tenant & Managed Object Lifecycle Governance v1|Provider-Missing Managed Object Truth v1|Workspace & Tenant Closure Lifecycle v1|Data Export Before Deletion v1|Retention & Purge Governance v1|Restoreability Expiry & Evidence Retention v1" docs/product/spec-candidates.md specs/262-lifecycle-governance-taxonomy`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd /Users/ahmeddarrazi/Documents/projects/wt-plattform && rg -n -- "draft|onboarding|active|archived|ignored_at|missing_from_provider_at|suspended|expired|retention" apps/platform/app/Models/Tenant.php apps/platform/app/Models/Policy.php apps/platform/app/Models/ReviewPack.php apps/platform/app/Models/BackupSet.php apps/platform/app/Models/RestoreRun.php apps/platform/app/Console/Commands/PruneReviewPacksCommand.php apps/platform/config/tenantpilot.php specs/143-tenant-lifecycle-operability-context-semantics/spec.md specs/251-commercial-entitlements-billing-state/spec.md specs/261-provider-missing-policy-visibility/spec.md specs/091-backupschedule-retention-lifecycle/spec.md`

## Scope Boundaries

### In Scope

- one lifecycle taxonomy covering local record lifecycle, provider presence, operator suppression, commercial/workspace lifecycle, retention/compliance lifecycle, and restoreability lifecycle
- one authoritative source map tying each lifecycle dimension to current repo-real models, specs, or runtime surfaces
- one transition-governance matrix covering direct mutation, confirmation requirement, audit requirement, `OperationRun` requirement, and export-before-delete or retention preconditions
- explicit classification that `export requested` belongs to the retention/compliance lifecycle as a reserved follow-up value while `Data Export Before Deletion v1` remains the separate runtime implementation slice
- explicit answers to the deferred candidate's mandatory questions
- explicit follow-up boundaries for runtime implementation slices
- a standards-track landing zone for later implementation in `docs/product/standards/`

### Non-Goals

- runtime archive, restore, delete, close, suspend, purge, or export flows
- new persistence, migrations, or lifecycle columns
- runtime changes to Spec 143, Spec 251, Spec 261, or Spec 091 behavior
- provider-specific rollout beyond the already bounded policy slice in Spec 261
- a new lifecycle dashboard, workboard, or operator console
- a new lifecycle service, registry, or orchestration framework
- changing global search, Filament resources, panels, providers, or assets

## Dependencies

- `docs/product/spec-candidates.md` and `docs/product/roadmap.md` for candidate truth and strategic framing
- `specs/143-tenant-lifecycle-operability-context-semantics/spec.md` for tenant lifecycle and canonical-view semantics
- `specs/251-commercial-entitlements-billing-state/spec.md` for workspace commercial lifecycle
- `specs/261-provider-missing-policy-visibility/spec.md` for provider-presence and restore continuity semantics
- `specs/091-backupschedule-retention-lifecycle/spec.md` for reversible archive / irreversible force-delete pattern
- `apps/platform/app/Models/Tenant.php`, `apps/platform/app/Models/Policy.php`, `apps/platform/app/Models/ReviewPack.php`, `apps/platform/app/Models/BackupSet.php`, `apps/platform/app/Models/RestoreRun.php`, `apps/platform/app/Console/Commands/PruneReviewPacksCommand.php`, and `apps/platform/config/tenantpilot.php` as current runtime truth inputs only

## Assumptions

- the explicit product decision to promote this candidate is the required override for its prior deferred status
- Specs 143, 251, 261, and 091 remain the bounded authoritative sources for their own runtime slices and are not reopened here
- review-pack expiry and configured retention values are current repo-real lifecycle signals even though there is not yet a general retention taxonomy
- later runtime slices will consume a standards document in `docs/product/standards/` rather than inventing a new lifecycle framework
- no application implementation is required to answer the deferred candidate's taxonomy questions in this v1

## Risks

- the taxonomy could drift into future-state wishlisting if it does not distinguish repo-real values from reserved follow-up values clearly
- the package could become too abstract if it names dimensions without tying them back to current specs, models, and commands
- later runtime slices may ignore the contract unless the follow-up map and review checklist are explicit
- terminology such as `deleted`, `expired`, `purged`, and `metadata only` could still be overloaded if the contract does not forbid proxy use across dimensions

## Candidate Selection Rationale

- **Selected candidate**: Workspace, Tenant & Managed Object Lifecycle Governance v1
- **Source locations**:
  - `docs/product/spec-candidates.md` deferred candidate section
  - `docs/product/roadmap.md` lifecycle-governance section
  - `specs/143-tenant-lifecycle-operability-context-semantics/spec.md`
  - `specs/251-commercial-entitlements-billing-state/spec.md`
  - `specs/261-provider-missing-policy-visibility/spec.md`
  - `specs/091-backupschedule-retention-lifecycle/spec.md`
- **Why selected**: The repo explicitly kept this candidate out of auto-prep, not out of product value. The user made the required explicit product decision, and the repo now contains enough concrete lifecycle slices to prepare a taxonomy-first contract without guessing.
- **Why this is the smallest viable implementation slice**: It answers the deferred candidate's mandatory questions through a standards and contract package only. It does not reopen runtime work already assigned to Specs 143, 251, 261, or 091.
- **Intentional narrowing from source candidate**: This v1 defines lifecycle taxonomy, naming rules, transition governance, and follow-up boundaries only. It does not implement workspace closure, tenant deletion, provider-missing rollout beyond policies, export-before-delete flow, retention executor, or purge engine.
- **Why close alternatives are deferred**:
  - tenant archive or restore runtime work would violate the candidate's explicit non-goals for this v1 promotion
  - further commercial-state runtime work belongs to Spec 251 and should not be duplicated here
  - broader provider-presence rollout belongs to a later `Provider-Missing Managed Object Truth v1` follow-up after the taxonomy is accepted

## Follow-up Candidates

- `Provider-Missing Managed Object Truth v1`
- `Workspace & Tenant Closure Lifecycle v1`
- `Data Export Before Deletion v1`
- `Retention & Purge Governance v1`
- `Restoreability Expiry & Evidence Retention v1`

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Classify lifecycle concerns before implementation (Priority: P1)

As a feature author or reviewer, I need one lifecycle taxonomy that tells me whether a concern belongs to local record lifecycle, provider presence, suppression, commercial state, retention, or restoreability so I do not overload existing fields or labels.

**Why this priority**: This is the minimum trust guardrail. If later runtime specs still have to guess where a lifecycle concern belongs, this package has not solved the core problem.

**Independent Test**: Can be fully tested by mapping the current repo-real examples from Specs 143, 251, 261, and 091 plus review-pack expiry or retention signals into the taxonomy and confirming that each one resolves to exactly one primary lifecycle dimension.

**Acceptance Scenarios**:

1. **Given** a future slice touches policy visibility, **When** the reviewer checks the lifecycle taxonomy, **Then** `provider missing` resolves to provider presence and does not reopen local delete semantics.
2. **Given** a future slice touches tenant or workspace archival, **When** the reviewer checks the taxonomy, **Then** the slice finds explicit distinctions between local archive, commercial suspension, retention, and restoreability instead of treating them as one state.

---

### User Story 2 - Choose the right transition safeguards (Priority: P1)

As an implementation reviewer, I need each lifecycle dimension to declare whether a transition is audit-only, confirmation-required, or `OperationRun`-backed so destructive or long-running work follows the correct safety path.

**Why this priority**: The lifecycle candidate exists to prevent unsafe destructive follow-ups from improvising their safeguards.

**Independent Test**: Can be fully tested by checking that the transition-governance matrix gives an explicit rule for archive, force delete, provider-presence observation, workspace suspension, export-before-delete, and restoreability expiry.

**Acceptance Scenarios**:

1. **Given** a future slice proposes irreversible deletion, **When** the reviewer checks the transition matrix, **Then** the contract requires explicit confirmation, audit evidence, and any additional export or retention preconditions before the slice can proceed.
2. **Given** a future slice proposes a long-running closure or purge action, **When** the reviewer checks the transition matrix, **Then** the contract tells the slice to use the shared `OperationRun` path instead of local action-only messaging.

---

### User Story 3 - Keep follow-up slices bounded (Priority: P2)

As a product planner, I need the broader lifecycle-governance candidate split into explicit follow-up slices so later work stays reviewable and does not hide purge, closure, export, provider-missing, and restoreability changes inside one large feature.

**Why this priority**: The candidate was deferred precisely because it was too broad for automatic prep. This v1 must keep it bounded even after promotion.

**Independent Test**: Can be fully tested by confirming that each major adjacent concern from the deferred candidate appears as a named follow-up slice and not as hidden primary-scope work.

**Acceptance Scenarios**:

1. **Given** the lifecycle package is reviewed, **When** the reviewer looks for workspace closure, `export requested`, export-before-delete workflow, retention/purge, and restoreability expiry, **Then** `export requested` is named under retention/compliance and each runtime concern still appears as a named follow-up rather than hidden inside the primary scope.
2. **Given** a future runtime slice wants to broaden scope, **When** it cites this taxonomy, **Then** the follow-up map shows which dedicated slice it belongs to instead of allowing scope creep.

### Edge Cases

- A runtime field such as `ignored_at` already exists and a later slice wants to reuse it for provider absence; the taxonomy must reject that proxy use explicitly.
- A status such as `expired` exists for review-pack retention but not for workspace state; the taxonomy must keep it in retention/compliance rather than promote it into a generic delete state.
- A future slice may require customer export before irreversible deletion; the taxonomy must classify `export requested` under retention/compliance while leaving the actual export workflow to `Data Export Before Deletion v1`.
- A workspace may be suspended/read-only while tenant data remains retained and partially restorable; the taxonomy must keep commercial state, retention, and restoreability distinct.
- A historical backup item may remain restorable when the live managed object is provider-missing; the taxonomy must preserve that separation.
- A future slice may propose audit-only handling for a destructive action; the taxonomy must state when audit-only is insufficient and `OperationRun` or stronger friction is required.

## Requirements *(mandatory)*

**Constitution alignment (required):** This slice introduces no Microsoft Graph calls, no runtime write path, no queue, no new `OperationRun`, and no new product persistence. It prepares a standards and contract package only.

**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** The package may define lifecycle categories and governance rules only because current repo truth already spans multiple lifecycle dimensions and the deferred candidate requires those distinctions before destructive follow-ups proceed. It must stay explicit, bounded, and non-runtime.

**Constitution alignment (XCUT-001):** Lifecycle wording, status semantics, destructive-action naming, retention wording, and restoreability claims are already cross-cutting. This package must attach them to one shared contract path instead of leaving them local.

**Constitution alignment (RBAC-UX):** The package does not change authorization. It must preserve the rule that lifecycle state never replaces scope entitlement or capability checks.

**Constitution alignment (PROV-001):** Provider-specific evidence remains provider-owned. Shared lifecycle labels must stay platform-neutral.

**Constitution alignment (TEST-GOV-001):** Because this is a docs/standards package, runtime test lanes are not required. The package must still leave one explicit validation and workflow outcome.

### Functional Requirements

- **FR-262-001**: The lifecycle governance contract MUST 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.
- **FR-262-002**: For each lifecycle dimension, the contract MUST name at least one current repo-real authoritative source and MUST distinguish current repo-real values from reserved follow-up values. When adjacent dimensions need similar delete or purge concepts, the contract MUST use dimension-specific labels so each lifecycle term still has one canonical home.
- **FR-262-003**: The contract MUST answer the deferred candidate's mandatory meaning questions for `deleted`, `missing from provider`, `ignored`, workspace suspension or closure, data export before deletion, retained versus purgeable data, and restore eligibility. For v1, that answer MUST explicitly classify `export requested` as a reserved retention/compliance value while keeping the actual export workflow in the dedicated `Data Export Before Deletion v1` follow-up slice. This taxonomy-first package answers the export-before-delete question at the lifecycle-classification and guardrail level only; artifact-level export contents remain deferred to that follow-up slice.
- **FR-262-004**: The contract MUST forbid treating one lifecycle dimension as a proxy for another, including provider presence versus local deletion, commercial suspension versus retention, and restoreability versus current provider presence.
- **FR-262-005**: The contract MUST define a transition-governance matrix that states, per lifecycle dimension, whether a transition may remain direct local mutation, requires confirmation, requires audit evidence, requires shared `OperationRun` execution semantics, or requires export/retention preconditions.
- **FR-262-006**: The contract MUST classify the current repo-real lifecycle-bearing slices from Spec 143, Spec 251, Spec 261, Spec 091, current review-pack expiry, current retention cleanup, and existing restore-continuity signals without reopening their runtime behavior.
- **FR-262-007**: The contract MUST keep provider-specific semantics bounded to provider-owned seams and MUST use neutral platform terms for shared lifecycle labels.
- **FR-262-008**: The contract MUST define explicit follow-up slice boundaries for provider-missing rollout beyond policies, workspace/tenant closure, export-before-delete, retention/purge, and restoreability expiry.
- **FR-262-009**: This v1 MUST NOT introduce runtime deletion flows, a purge engine, a lifecycle dashboard, a new lifecycle service or registry, a new persisted domain model, or reinterpretation of existing lifecycle fields.
- **FR-262-010**: This v1 MUST use the existing standards workflow in `docs/product/standards/` as the intended implementation landing zone for the lifecycle contract and MUST NOT create a parallel standards mechanism.

## Success Criteria *(mandatory)*

### Measurable Outcomes

- **SC-001**: 100% of lifecycle terms used in the prepared package map to one explicit lifecycle dimension and authoritative source with no duplicate meaning.
- **SC-002**: The package answers all mandatory questions listed in the deferred candidate at the taxonomy and guardrail level appropriate to this v1 without requiring runtime implementation to understand the answer boundary.
- **SC-003**: Every major adjacent concern from the deferred candidate is represented as a named follow-up slice instead of hidden in the primary scope.
- **SC-004**: The package introduces zero runtime behavior, zero new product persistence, and zero reopened scope in Specs 143, 251, 261, or 091.