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, a fairness cycle 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. Request & investigation state machines

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

Request:       RECEIVED → TRIAGING → (INFORMATION_REQUIRED) → ACCEPTED_FOR_ASSESSMENT → INVESTIGATION_OPEN → CLOSED  (or REFERRED / DECLINED / WITHDRAWN)
Investigation: PLANNED → OPEN → EVIDENCE_GATHERING → ANALYSIS → FINDINGS_DRAFT → RESPONSE_PENDING → FINALISING → COMPLETE

with conditions from the child records (e.g. "triage outcome ACCEPT_FOR_ASSESSMENT → eligible to open an investigation", "all findings settled and fairness complete → FINALISING").

2. Triage routing

TriageAssessment.outcome (accept / refer / external / decline / more-info) would, in Phase 2, automatically move the request (open an Investigation, create a Referral, or raise an InformationRequest) rather than a user doing each step by hand.

3. Procedural-fairness cycle

ProceduralFairnessResponse records the natural-justice step for a Finding. Phase 2 would gate a finding from SUBSTANTIATED until fairness is COMPLETE, track the response due date, and re-open the finding for review when finding_changed is true.

4. Closure guard rules

The rules that must all pass before a ClosureRecord may be approved:

  1. Procedural fairness complete for every substantiated finding.
  2. Conflicts resolved — no open ConflictAssessment in CONFLICT_CONFIRMED.
  3. Evidence index complete — every EvidenceItem verified or excluded, with custody.
  4. Records complete — required outputs (findings, recommendations, referrals) recorded.

The demo's ClosureRecord sets these flags true; Phase 1 lets an operator set them by hand, Phase 2 would compute and enforce them.

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 (request.triaged, investigation.opened, finding.substantiated, referral.sent, request.closed, …). It is dropped from Phase 1 because there is no publisher yet; it returns when ARIM 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.