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, monitoring logic 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. Lifecycle & approval-gate state machine

The pack defines the AI-system lifecycle (DISCOVERY → … → OPERATION → CHANGE → RETIREMENT) and a status graph. In Phase 1 lifecycle_stage / status are free fields; Phase 2 would enforce the transitions, driving them from approval gates (a system can't be DEPLOYED without an APPROVED/CONDITIONAL deployment gate) and reassessment triggers.

2. Risk scoring

EthicalRisk carries likelihood/consequence and inherent/residual scores. Phase 1 stores them as entered; Phase 2 would compute the scores and roll them into the system risk_tier.

3. Monitoring threshold-breach detection

MonitoringMetric carries warning/breach thresholds and a direction; MonitoringObservation carries an observed value and status. Phase 1 records the status as entered; Phase 2 would derive ACTIVE/WARNING/BREACH from the value against the thresholds and raise an AdverseOutcomeIncident on a sustained breach.

4. Deployment / approval guard rules

The rules that must pass before an ApprovalGate may be APPROVED (rather than CONDITIONAL/REJECTED):

  1. Assessment complete — a current RiskAssessment with an acceptable outcome.
  2. Mandatory controls effective — required Controls (and HumanOversightControl for decisions affecting people) are EFFECTIVE.
  3. Evidence accepted — mandatory EvidenceRequirements have an ACCEPTED submission.
  4. Transparency met & no open critical risk — required TransparencyObligations PUBLISHED; no open CRITICAL EthicalRisk without an effective control.

In the demo AI-CEA meets these (APPROVED) while AI-DRP does not fully (fairness residual, monitoring breach) — hence its CONDITIONAL gate. Phase 1 lets an operator record any outcome; Phase 2 makes the guards hard.

5. Reassessment triggers

AIChange carries material_change and reassessment_required. Phase 2 would, on a material change, automatically require a new RiskAssessment (and block re-deployment until it completes) — the demo's CHG-CEA-01 (model v1→v2) is flagged reassessment_required.

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 (assessment.completed, gate.decided, monitoring.breached, incident.raised, system.retired, …). It is dropped from Phase 1 because there is no publisher yet; it returns when AIGERM 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.