eFEC Roadmap — Toward the Vision¶
Vision: trust with mathematics. Every decision is a signed event; an auditor verifies the entire history independently, without database access. Onboarding, screening, investigation, case management, reporting — one system, one tamper-proof record, no side doors.
Where we are (June 2026)¶
The trust infrastructure is complete:
| Pillar | Status |
|---|---|
| Signed events, SHA-256 hash chain | ✅ Live |
| Engine single chokepoint (DB-enforced) | ✅ Live |
No bypass (SECURITY DEFINER, privileges locked) |
✅ Live |
| governed-events: single crate, native + WASM | ✅ Live |
| WASM parity proof in CI (Guard #3) | ✅ Live |
| Workflow engine (when/then/mutate, roles, outbox) | ✅ Live |
| Entity model (entities-as-processes, children, read model) | ✅ Phase 1+2 |
| React workflow editor + dynamic customer UI | ✅ Live |
What's missing is the compliance application that runs on top of it — the lifecycle that actually enforces deadlines, the verification that proves the chain, and the screening/case/reporting domains.
Milestones¶
M1 — Dynamic Triggers ✅ Done¶
Delivered: scheduled_actions table, $schedule / $unschedule operators, system actor, external watcher (trigger-watcher/), e2e escalation test. All guard-rule integration tests pass. Design record: triggers-spec.md.
M2 — Audit Completeness (the vision's proof)¶
Why: "An auditor can verify the entire history independently" is the core proposition. Today the Audit page verifies single events. It must verify the whole chain and produce a self-contained evidence bundle.
Scope:
- verify_chain(process_id) — reconstructs the full event sequence from raw rows, re-computes every hash link and signature, returns a structured verdict.
- Evidence export — a self-contained bundle (event JSON + public keys + signatures) that an auditor verifies with a standalone governed-events verify CLI, no DB access.
- Frontend: full-chain verification view, per-process integrity status, export button.
- Standalone governed-events verify CLI (Rust binary) — the auditor's tool.
Guard rules: #3, #16 (every event independently verifiable; canonicalization shared).
Exit criteria: export a process's full history to a file; a second machine with only the file + the public keys + the governed-events verify CLI confirms the chain is intact and every signature is valid.
M3 — Security Hardening (close the guard gaps)¶
Why: Two guard rules were convention, not enforced. SQL parameterization is now done. Key storage remains.
Scope:
- ✅ SQL parameterization (Guard #14) — all q() string interpolation replaced with Spi::get_one_with_args / Spi::run_with_args. Done.
- Key/token storage split (Guard #6) — Ed25519 secret key in sessionStorage (per-tab, cleared on close); JWT in localStorage. Never co-located.
- Separation-of-powers review (Guard #18) — audit all workflows for proposer=approver without a second gate.
Exit criteria: browser stores show keys in separate tiers.
M4 — Screening & Case Management (the compliance depth)¶
Why: Onboarding is built; the ongoing compliance lifecycle is not. Screening and investigations are the heart of FEC.
Scope: - Screening sub-workflow as a child process — sanctions/PEP watchlist match, adjudication (true match / false positive), continuous re-screening (uses M1 triggers). - Case management — alerts (from screening, triggers, or manual) → investigations → decisions. Cases are processes; evidence links to the triggering events. - Customer detail: Cases tab and Screening tab become live (Phase 2 entity model already supports children).
Guard rules: #7, #12, #18 (cases are governed processes; decisions derive from state; distinct investigator/approver roles). Depends on: M1 (re-screening cycles), M2 (case evidence is verifiable). Exit criteria: a sanctions hit creates a case, an investigator adjudicates it, the decision is a signed event, and the whole arc verifies independently.
M5 — Regulatory Reporting (the output)¶
Why: The FEC mandate produces reports (SAR, CTR). In eFEC, a report is itself a signed event — its provenance is verifiable, not just its content.
Scope: - Report-generation actions (workflow-driven) that assemble data from the process graph. - Report submission as a terminal signed event with a regulator-facing hash. - Report lineage: every figure in a report traces back to the signed events that produced it.
Depends on: M4 (cases feed reports), M2 (reports are independently verifiable).
Sequence & Dependencies¶
M1 Triggers ──────┬──► M4 Screening & Cases ──► M5 Reporting
│ ▲
M2 Audit ─────────┴───────────┘
M3 Hardening (parallel, no deps)
- M1 and M2 can proceed in parallel — different subsystems.
- M3 is parallel to all; do it early (cheap, removes real exposure).
- M4 depends on M1 (re-screening) and M2 (verifiable evidence).
- M5 depends on M4.
What we explicitly defer¶
- Merkle tree / partial-chain verification — optimization, not a correctness gap. Idea-stage.
- Multi-signature (M-of-N) — valuable but not on the critical path.
- Process templates / bulk actions — UX polish, not vision-critical.
- Configurable retention — operational, deferred until scale demands it.
The one-line strategy¶
Triggers make the platform run. Audit makes it prove. Hardening makes it trustworthy. Screening and reporting make it compliance. In that order.