- Documentation
- /
- Iscrm
- /
- 03 — Phase 2 Scope
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:
- Retest passed — the latest
Retestfor the deficiency has outcomePASSED. - No blocking gap — the deficiency (and any linked blocking item) is not still open-blocking.
- Completion declared — the linked
ClosureRequest.declared_complete == true. - Completed actions carry completion metadata — a
COMPLETEDRemediationActionhasreported_complete_atandreported_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 columns —
tenant_id,created_at/by,updated_at/by,row_version. - Integration columns —
source_system,source_reference,external_correlation_key. DomainEventoutbox table (§4).unique/indexesblocks — advisory in this codebase's DSL.
Everything else in the pack maps 1:1 to a Phase-1 model and field.