03 — Phase 2 Scope

Phase 1 is the AI-Safe CRUD register: all 18 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. Deficiency lifecycle state machine

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

OPEN → ACKNOWLEDGED → REMEDIATION_IN_PROGRESS → READY_FOR_RETEST → RETEST_IN_PROGRESS
     → RESOLVED → CLOSED   (or → ACCEPTED via an approved risk acceptance)

Each edge has a condition (e.g. "all remediation actions reported complete", "latest retest outcome is PASSED") evaluated from the child records rather than asserted by hand.

2. Closure guard rules

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

  1. Retest passed — the latest Retest for the deficiency has outcome PASSED.
  2. No blocking gap — the deficiency (and any linked blocking item) is not still open-blocking.
  3. Completion declared — the linked ClosureRequest.declared_complete == true.
  4. Completed actions carry completion metadata — a COMPLETED RemediationAction has reported_complete_at and reported_complete_by.

In the demo these hold for DEF-ACC-01 (closed) and deliberately fail for DEF-ACC-02 (failed retest); nothing stops an operator overriding them in Phase 1 — Phase 2 makes them hard gates. A RiskAcceptance is an interim treatment, not a substitute for closure.

3. Operations (guarded transitions)

The pack lists operations that bundle an effect with its precondition and emit an event: acknowledge deficiency, approve remediation plan (mark prior current=false), report action complete, submit evidence, record retest, request/approve risk acceptance, 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 (deficiency.raised, remediation.approved, retest.completed, deficiency.closed, …). It is dropped from Phase 1 because there is no publisher yet; it returns when ISCRM is wired to the orchestrator/event layer.

5. Plan / evidence versioning

RemediationPlan carries plan_version + current, and EvidenceSubmission carries a supersedes_id. Phase 2 would enforce "one current plan per deficiency" and evidence supersession chains.


What Phase 1 deliberately dropped from the source pack

  • Tenancy / audit columnstenant_id, created_at/by, updated_at/by, row_version.
  • Integration columnssource_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.