03 — Phase 2 Scope

Phase 1 is the AI-Safe CRUD register: all 17 models, the menu, the dashboard and a coherent seeded scenario. The source pack also specifies runtime behaviour — a state machine, guard rules, operations and an event outbox. Those are not built in Phase 1; they are recorded here so the model stays honest about what enforces itself versus what a user maintains by hand today.

1. System lifecycle state machine

The pack defines the system transition graph (LifecycleStatus). In Phase 1 lifecycle_status is a free field a user sets; Phase 2 would enforce the transitions and their guards:

ACTIVE → LEGACY → EXTENDED_SUPPORT → REPLACEMENT_PLANNED → REPLACEMENT_IN_PROGRESS
       → RETIREMENT_PENDING → RETIRED

with conditions from the child records (e.g. "support ended → LEGACY", "replacement approved → REPLACEMENT_PLANNED", "retirement checklist confirmed → RETIRED").

2. Obsolescence scoring

ObsolescenceAssessment carries six 1–5 sub-scores (technology, supportability, skills, security, fragility, integration) and an overall_score. Phase 1 stores the overall as entered; Phase 2 would compute it (e.g. a weighted mean) and drive a risk-ranking view.

3. Retirement guard rules

The rules that must all pass before a RetirementPlan may move to RETIRED (or an AssuranceDecision approve retirement):

  1. Replacement complete — the linked ReplacementInitiative is COMPLETE, or the service dependencies are re-pointed.
  2. Readiness green — every CutoverReadiness area is READY.
  3. Checklist confirmed — data_retention_confirmed, interfaces_disabled_confirmed, access_removed_confirmed, backup_retention_confirmed and business_signoff_confirmed are all true.
  4. No open critical risk without an effective control.

In the demo these are deliberately not all met (migration in progress, checklist part-confirmed), which is why the seeded decision is CONDITIONAL and the retirement is PLANNED. Phase 1 lets an operator set any status; Phase 2 makes the guards hard.

4. Operations (guarded transitions)

The pack lists operations that bundle an effect with its precondition and emit an event: assess obsolescence, raise/treat risk, activate a compensating control, submit evidence, progress the replacement, assess cutover readiness, record the assurance decision, and confirm retirement. Phase 2 would expose these as buttons/endpoints that also append a StatusHistory row.

5. The DomainEvent outbox

The source model includes a DomainEvent table (correlation/causation ids, idempotency key, publish status/attempts) — the transactional outbox for notifying downstream systems (obsolescence.assessed, risk.raised, replacement.progressed, system.retired, …). It is dropped from Phase 1 because there is no publisher yet; it returns when LSRR is wired to the orchestrator/event layer.

What Phase 1 deliberately dropped from the source pack

  • Tenancy / audit columns — tenant_id, created_at/by, updated_at/by, row_version.
  • Integration columns — source_system, source_reference, external_correlation_key.
  • DomainEvent outbox table (§5).
  • unique / indexes blocks — advisory in this codebase's DSL.

Everything else in the pack maps 1:1 to a Phase-1 model and field.