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.