Fintra Platform
Different engines, one book of record
Decision Ledger: Mixed Engines
Example figures- ROWS SEALED
- 48,912
- append-only
- CHAIN
- verify_chain() ✓
- unbroken
- ENGINES
- 3 registered
- same contract
- Finance engine · pay-run · $2.1M · 812 emp
- sealed · #48910
- Security engine · access grant · prod DB
- sealed · #48911
- Finance engine · vendor payment · $18k
- sealed · #48912
- Each row: prev_hash + payload, then sha256
- chained
- Tenant isolation enforced at write
- scoped
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
Implement the contract
The new engine maps its actions to the Decision Contract: actor, action, resource, verdict, factors.
Register it
The engine is registered against the shared contract; the platform routes its decisions through the same scoring and gating path.
Write to the same ledger
Its verdicts seal into the same append-only chain, tenant-scoped, right next to finance and security.
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
Questions people ask
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.
Keep reading
Guides
Calculators
One finance briefing a week
New guides, checklists and benchmarks, by email. Unsubscribe from any issue.
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.