Phase 2 — Runtime Engine Scope

Phase 1 (built) renders the 22-model schema as an AI-Safe CRUD register: you can create matters, claims, notices, assessments, evidence, disputes and settlements, navigate the relationships, and read the dashboard. The states are correct but static — the seed shows a claim already submitted, a notice already issued, an exception already resolved. Nothing is computed or transitioned by the system.

Phase 2 is the runtime that makes it live — it computes the deadlines, enforces the state machines, runs the periodic scans, and reacts to the rules the pack specifies. It is the same shape as the (already-built and cluster-proven) orchestrator engine, but single-app: no cross-app transport, just this database.

Everything below is drawn from the pack's workflows.yaml, rules.yaml, the DSL derived {} blocks and the ExecutiveClaimsDashboard definition — it is a scope, not a design; each workstream still needs the business decisions noted.

A. Derived-field & rollup engine

The DSL derived fields are seeded statically today; Phase 2 recomputes them.

Plus quantum rollups the pack implies (04_CLAIM_ASSESSMENT_AND_QUANTUM): a claim's claimed_amount / assessed_amount / agreed_amount should be the sum of its QuantumItems, recomputed whenever a quantum line changes.

Decisions: compute-on-read vs materialise-on-write vs recompute-on-tick; whether claim amounts are authoritative or derived from quantum lines.

B. State machines & guarded actions

The pack defines five workflows — each a state machine with transitions, the role allowed to make them, and precondition guards. Today a user free-edits the status field; Phase 2 exposes each transition as a guarded action (button / API) that enforces the guard, applies all effects atomically, and records the change.

Decisions: which transitions are UI buttons vs API-only; how roles map to the app's PIN/RBAC; whether guards block or warn.

C. Deadline engine (scheduled scans)

A background tick (hourly/daily) that watches the time bars and raises exceptions — this is the headline "claims never lapse" value. From rules.yaml:

• Notice warning — notice_due_date within 7 days and claim still potential/preserving_rights → create a critical notice_deadline ExceptionRecord + notify owner/legal.
• Notice overdue — notice_due_date passed, claim not yet notified → create a critical potential_time_bar exception + publish claim.notice_overdue.
• Submission due — submission_due_date approaching → task/exception.
• Dispute limitation — limitation_date within 30 days and dispute not settled/determined/discontinued → create a critical limitation_deadline exception + notify.

Decisions: the tick cadence; business-calendar (AU_QLD) support so "business days" is accurate (the pack ships business_calendars.yaml); dedupe so a scan doesn't raise the same exception every tick.

D. Rules / cross-record automation

Reactive rules that fire on a change and cascade (from rules.yaml):

• submission_requires_core_assessments — block a claim moving to submitted unless the latest entitlement/causation assessments are at least arguable/alleged, quantum > 0, and legal review is complete. (Also encoded as a claim-workflow guard — Phase 2 enforces it in one place.)
• privileged_evidence_not_produced — prohibit an EvidenceItem with privilege status potentially_privileged/privileged from transitioning to produced. (The privilege guardrail — prevents accidental waiver.)
• settlement_approval — a Settlement with an amount must have approved_by and approved_at set.
• high_value_claim_escalation — claimed_amount ≥ $1m → set risk_level=high and notify claims_manager/legal.
• claim_event_notice_screen — a ClaimEvent flagged potential_notice → auto-create a high-priority "Assess contractual notice requirement" Task and publish claim_event.notice_assessment_required.

Decisions: where the event bus goes (in-app only, or emit to the orchestrator); notify = email vs in-app; whether prohibitions hard-fail or flag.

E. Executive dashboard & KPIs

The pack's ExecutiveClaimsDashboard defines real metrics/panels that Phase 1 renders generically. Phase 2 wires them via the repo KPI framework (kpi_engine.py + a per-app kpis.py):

• Metrics: open matters; active claims; claimed / assessed / agreed value (portfolio totals); critical deadlines (notice due ≤ 7 days); active disputes; open exceptions.
• Panels: claims by status; claims by type; value by matter; upcoming deadlines; disputes by stage; high-risk matters; recent notices.

How it would be built

1. A per-app engine module (mirror server/lib/orchestrator_engine/, single-app): a compute pass (workstream A), a scheduler/tick (C), actions with guards (B), a rules evaluator (D). Opt-in via an env flag, single worker — exactly the orchestrator pattern.
2. KPIs (E) via the existing framework — lowest-effort, highest-visibility, and independent of the engine, so a good first slice.
3. Business-calendar support underpins C and A's business-day math.
4. Tests per workstream (the orchestrator's test_orchestrator_flows.py is the template).

Suggested sequencing

1. KPIs / dashboard (E) — visible, no engine, quick win.
2. Derived fields + quantum rollups (A) — makes the numbers self-consistent.
3. Deadline engine (C) — the core value (time bars), needs the business calendar.
4. State machines + guards (B) — turns free-edit into governed transitions.
5. Rules / automation (D) — the reactive layer, once B and C exist.

Each slice is independently shippable and demoable; none requires the others to be useful. The orchestrator (built and run live this session) is the working template for the engine, scheduler and tests.