03 — Phase 2 Scope

Phase 1 is the AI-Safe CRUD register: all 22 models, the menu, the dashboard and a coherent seeded scenario. The source pack also specifies runtime behaviour — state machines, 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. Project & defect lifecycle state machines

The pack defines the project transition graph (ProjectStatus) and a defect graph. In Phase 1 status is a free field a user sets; Phase 2 would enforce the transitions and their guards:

Project:  PLANNED → INITIATED → IN_PROGRESS ⇄ AT_RISK/BLOCKED → READY_FOR_GO_LIVE → LIVE → CLOSED
Defect:   OPEN → TRIAGED → IN_PROGRESS → READY_FOR_RETEST → RETESTING → RESOLVED → CLOSED

with conditions evaluated from the child records (e.g. "a go-live-blocking defect moves the project to AT_RISK", "all remediation actions reported complete → READY_FOR_RETEST").

2. Go-live readiness guard rules

The rules that must all pass before a GoLiveDecision may be APPROVED (rather than CONDITIONAL/DEFERRED):

  1. Readiness green — every mandatory ReadinessArea is READY.
  2. No blocking defects — count(open, go_live_blocking) == 0.
  3. Reconciliations passed — every mandatory Reconciliation has passed == true.
  4. Evidence accepted — mandatory EvidenceRequirements have an ACCEPTED submission.

In the demo these are deliberately not all green (DEF-002 open, GL reconciliation sign-off pending), which is exactly why the seeded decision is CONDITIONAL and closure is DEFERRED. Phase 1 lets an operator record any outcome; Phase 2 makes the guards hard, and the closure guard additionally requires the go-live conditions to be evidenced as met.

3. Operations (guarded transitions)

The pack lists operations that bundle an effect with its precondition and emit an event: approve requirement/design, run migration batch + reconcile, record test result, raise/ resolve defect, submit evidence, assess readiness, record the go-live decision, and approve closure. Phase 2 would expose these as buttons/endpoints that also append a StatusHistory row.

4. 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 (migration.reconciled, defect.raised, readiness.assessed, golive.decided, project.closed, …). It is dropped from Phase 1 because there is no publisher yet; it returns when ERPAM is wired to the orchestrator/event layer.

5. Reconciliation & control totals

MigrationBatch carries extract/load/rejected counts and source/target control totals; Reconciliation carries source/target/variance/tolerance and a passed flag. Phase 2 would compute variance and passed from the totals rather than storing them as entered.

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 (§4).
  • unique / indexes blocks — advisory in this codebase's DSL.

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