corp-v1-channel-architecture/references/multidimensional-lifecycle-presentation-audit.md

Multidimensional lifecycle presentation audit

Use this audit when canonical task execution or deployment evidence has advanced but Scope, Architecture, Kanban, or release pages may still show an earlier snapshot.

Model the dimensions separately

For every affected Epic and Feature, record these as distinct fields rather than forcing them into one status:

1. Scope lifecycle — proposal and Approved for Solution state owned by Scope.
2. Solution package — package completeness, requirements, ADRs, and C4 impact owned by Architecture.
3. Implementation approval — exact Feature decision and conditions.
4. Execution — task-derived InBacklog, InProgress, or ToBeReleased state. Mark parent Epic/Feature values as derived unless they have their own canonical flow event.
5. Publication/deployment — application source, published artifact, selected GitOps revision, and verified runtime source.
6. Acceptance/release — Feature acceptance and final release allocation; never infer these from execution or deployment.

Evidence-first consistency matrix

Build an expected-versus-actual matrix from current remote default:

Surface	Required comparison
Canonical Feature records	Scope state, package status, implementation decision, proposed/final version
Canonical task records	status, flow_state, delivery_started, flow history, implementation evidence
Scope Roadmap	All lifecycle dimensions visible; current prose agrees with canonical tasks
Kanban Board/Focus	Exact tasks shown directly; parent execution clearly labelled as derived
Architecture lifecycle/registers	Historical admission snapshots are dated or updated; no current claim that Delivery has not started when tasks are active
Release readiness	Published source, selected GitOps revision, and runtime source kept distinct
Task evidence prose	Deployment claims agree with Releases/runtime evidence without implying acceptance
Public adapters and types	Verification fields are derived before private metadata is stripped
Tests	Production-data assertions plus mutations for stale prose, missing derived fields, and forged cross-record evidence

Do not accept a green build as semantic consistency. Search static prose for obsolete assertions such as Delivery has not started, all tasks are InBacklog, not deployed, or no implementation evidence, then compare each claim with canonical YAML and current immutable evidence.

Parent-state derivation rules

• Derive Feature execution only from verifier-admitted child tasks.
• Derive Epic execution only from verified child Feature/task execution.
• Label every derived parent state (derived) in visual nodes, tables, and accessibility text.
• Preserve Scope status as Scope status; do not rewrite Approved for Solution to InProgress.
• Define deterministic aggregation precedence and test mixed child states.
• A parent-derived InProgress value is presentation evidence, not a new lifecycle decision.

Coordinated remediation

1. Freeze six-channel high-watermarks and current remote default SHA.
2. Confirm the contradiction using canonical records and exact immutable implementation/deployment evidence.
3. Inventory every sibling surface and adapter that presents the affected records.
4. Update data derivation, types, visual nodes, semantic tables, accessibility text, static prose, and tests together.
5. Include negative assertions rejecting superseded current-state wording.
6. Run production-data derivation tests, all domain validators, TypeScript, strict build, browser QA, generated-output drift checks, and git diff --check.
7. Publish one owning PR, verify the complete changed-file list, wait for exact-head CI, merge only under the active authority contract, and verify exact-default CI.
8. Perform a final six-channel plus remote-artifact convergence pass.

Concurrent candidate rule

If another Architecture session has already disclosed or created an unpublished lifecycle correction, verify only its branch, base/head, cleanliness, publication state, remote PR inventory, and claimed CI. Do not modify, rebase, publish, validate as your deliverable, or create a competing PR. Report uncovered contradictions as required scope for the owning review, distinguishing current default truth from unpublished candidate work.