Case is created, the contract is attached, the standard pipeline runs, findings land in the case folder.
CASE LAYER
Case management built for regulated finance.
Every analysis lives inside a case. Cases have an explicit lifecycle, a four-eyes approval workflow, row-level isolation by organisation, an append-only audit trail and a weekly counter-party re-screening cron. This is the operational layer between the contract engine and a real bank's risk committee.
Case lifecycle4-eyes Maker / CheckerRBAC + RLSWeekly re-screeningAudit Export JSON
LIFECYCLE
Three explicit states. Severity auto-escalation built in.
A case opens, gets reviewed and closes. Each finding the engine surfaces carries a severity that the case inherits — so a single critical flag can auto-escalate the case to under_review and pin it to the senior partner's queue without manual routing.
Triggered automatically by critical-severity findings or manually by a maker. Reviewer (separate from maker) must approve or reject before close.
Approved by the checker or formally rejected. Audit trail frozen. Outbound webhook fires. Case becomes read-only.
SEGREGATION OF DUTIES
Four eyes by default. The system enforces it.
Maker / Checker separation is enforced at the database layer: the user who creates a case or files a finding cannot be the same user who approves it. The engine refuses the operation if it detects the same user identity on both sides — there is no UI workaround.
Maker
Files the analysis, attaches the contract, raises findings, drafts the recommendation. Cannot approve.
Checker
Reviews the maker's case, accepts or rejects findings, approves or sends back. Cannot have authored what they review.
RBAC + RLS
Roles inside organisations, isolation across organisations.
Organizations are the tenancy boundary. Users belong to one or more organisations via org_members with a role. Row-Level Security at the database layer guarantees that a user in organisation A literally cannot read a row that belongs to organisation B — the SQL planner refuses it, regardless of the application code.
| Role | Capabilities |
|---|---|
owner | Everything inside the org. Manages billing, members, integrations. |
admin | Manages members and configuration. Cannot transfer ownership. |
member | Files cases, runs analyses, raises findings. Standard operator. |
viewer | Read-only access to cases. Used for auditors and external observers under NDA. |
Roles and RLS are evaluated server-side on every query. There is no frontend-only gating.
OPERATIONAL CAPABILITIES
What the case layer does beyond the workflow.
Conditions Precedent checklist
Standard CP tracker inside every case. Binary state per condition — only [L1] evidence flips it to met. Used in credit deals where closing depends on all CPs cleared.
Weekly counter-party re-screening
A cron re-runs OFAC SDN / sanctions screening on every active case's counter-parties every week. New matches reopen a previously closed case automatically.
Batch counter-party import
CSV or JSON upload of up to 50 counter-parties at once for screening. Used by KYC teams onboarding a portfolio of new clients in a single pass.
HMAC outbound webhooks
Every state change (case opened, finding raised, status changed, case closed) fires a signed HMAC-SHA256 webhook to your downstream systems. Replay-safe retry schedule.
Audit Export JSON
One-click export of the full case dossier — pipeline output, findings, severity, maker / checker identities, timestamps, integrity hash. Designed for regulatory inspection.
Prompt backtesting
Golden dataset of historical cases with expected verdicts. Used to evaluate any change in the underlying prompts before it ships. Jaccard / JSON-divergence scoring.
Want to run a case end-to-end?
Bring a representative deal and we will open a case on it, walk the maker / checker workflow, export the audit dossier and show the weekly re-screening trigger. Same offer as the rest of Finance.