03 — Phase 2 Scope

Phase 1 is the AI-Safe CRUD register: all 19 models, the menu, the dashboard and a coherent seeded scenario. The source pack also specifies runtime behaviour — state machines, scoring, roll-ups, guard rules 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. Recommendation & review lifecycle state machines

The pack defines recommendation and review transition graphs. In Phase 1 status is a free field a user sets; Phase 2 would enforce the transitions and their guards:

Recommendation: NOT_STARTED → PLANNED → IN_PROGRESS ⇄ AT_RISK/BLOCKED → IMPLEMENTED → VALIDATION_PENDING → CLOSED  (or DEFERRED / SUPERSEDED)
Review:         RECEIVED → MOBILISING → IN_IMPLEMENTATION ⇄ AT_RISK → VALIDATION → CLOSING → COMPLETE → ARCHIVED

with conditions from the child records (e.g. "a blocking dependency → AT_RISK/BLOCKED", "all actions complete and evidence accepted → VALIDATION_PENDING").

2. Derived priority scoring

RecommendationPriorityAssessment carries five sub-scores and a derived_priority next to a management_priority. Phase 1 stores both as entered; Phase 2 would compute the derived priority from the sub-scores and flag where management overrides it.

3. Progress-snapshot roll-ups

ProgressSnapshot carries counts (not-started / in-progress / at-risk / blocked / validation-pending / closed, overdue actions, open blockers, decisions required). Phase 1 stores them as entered; Phase 2 would compute the snapshot from the live recommendation, action, dependency and decision records.

4. Closure guard rules

The rules that must all pass before a ClosureDecision may be APPROVED:

  1. Validated — a ValidationAssessment with outcome SUFFICIENT (evidence sufficient, all aspects addressed, sustainable).
  2. Evidence accepted — mandatory EvidenceRequirements have an ACCEPTED submission.
  3. No blocking dependency — no open Dependency with blocking = true for the recommendation.
  4. Actions complete — all ImplementationActions COMPLETED or explicitly out of scope.

In the demo REC-01 meets these (closed); REC-02 does not (blocking dependency, at risk). Phase 1 lets an operator record any closure; Phase 2 makes the guards hard.

5. Benefit measurement

Benefit carries baseline/target/current values and a status. Phase 2 would track the measure over time, drive ON_TRACK/AT_RISK/REALISED from current-vs-target, and roll benefit realisation up to the review.

6. 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 (recommendation.validated, decision.recorded, benefit.realised, recommendation.closed, …). It is dropped from Phase 1 because there is no publisher yet; it returns when SRIM 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 (§6).
  • unique / indexes blocks — advisory in this codebase's DSL.

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