Different Engines, One Book of Record
A payroll run and a real security access decision could not look more different - but both are just decisions about consequential actions. Through one Decision Contract they land in the same append-only, tenant-isolated ledger, each row sealed with sha256 and chained to the last. Adding a new domain isn’t a new database; it’s registering another engine against the same contract.
Illustrative product view
One Decision Contract, any engine
The reason a pay-run and an access decision can share a ledger is that they share a shape. The Decision Contract is a single schema - who is acting, what action, on which resource, with what verdict and which factors. A finance engine and a security engine each produce that shape; the ledger doesn’t care which engine wrote the row, only that the row is well-formed and sealed.
- Append-only - rows are written, never edited or deleted, so history can’t be quietly rewritten
- Per-row sha256 seal over the payload plus the previous row’s hash - a true hash chain
- Tenant-isolated at write time, so one customer’s decisions can never leak into another’s book
- verify_chain() re-hashes the whole chain and fails loudly if any link is broken
- Durable in Supabase (Postgres) - not an in-memory demo that forgets on restart
Adding a domain = registering an engine
How a new domain joins
- 1
Implement the contract
The new engine maps its actions to the Decision Contract - actor, action, resource, verdict, factors.
- 2
Register it
The engine is registered against the shared contract; the platform routes its decisions through the same scoring and gating path.
- 3
Write to the same ledger
Its verdicts seal into the same append-only chain, tenant-scoped, right next to finance and security.
- 4
Fail soft if unconfigured
If the engine’s service isn’t env-configured, it stays off and simply produces no rows - it never blocks the domains that are live.
Honest about what’s durable and what’s off
Frequently asked questions
How can a pay-run and a security decision share one ledger?
Both are decisions about consequential actions, so both are expressed through one Decision Contract - actor, action, resource, verdict, factors. Whatever engine produces that shape writes to the same append-only ledger; the ledger doesn’t care which engine wrote the row, only that it’s well-formed and sealed.
What makes the ledger tamper-evident?
Each row carries a sha256 seal computed over its payload plus the previous row’s hash, forming a true hash chain. verify_chain() re-hashes the chain end to end and fails loudly if any link is broken, so edits or deletions are detectable rather than silent.
Is the ledger durable or just a demo?
It’s durable - backed by Supabase (Postgres), append-only, and tenant-isolated at write time. It persists across restarts and keeps one customer’s decisions strictly separate from another’s.
What does it take to add a new domain?
You implement the Decision Contract for that domain’s engine and register it against the shared contract. Its verdicts then seal into the same chain. If the engine’s service isn’t configured it fails soft - off, producing no rows, never blocking the live domains.
Does writing to the ledger execute the action?
No. The ledger records the verdict and the platform can gate the action, but live actuation is a separate step that happens only at the opt-in MCP boundary. Sealing a decision is not the same as performing it.
Stay in the loop
One practical finance briefing a week - new guides, checklists, and benchmarks.
One book of record for every engine
See a finance verdict and a security verdict seal into the same chain - and verify it end to end.
Talk to us