Compliance & Trust

The Decision Ledger

How every consequential decision - finance or security - is written to one tamper-evident, tenant-scoped ledger in one canonical shape.

Updated 8 min read1 labOwner / FounderAccountant

When decisions are scattered across a dozen systems, each with its own log and vocabulary, an audit or an incident can’t easily answer “who decided this, on what basis, and can you prove it wasn’t changed?” The Decision Ledger unifies that: every consequential action, whatever engine decided it, is written to one append-only, tenant-scoped table in one canonical shape.

What a ledger row records

  • Who acted - human, service account, or agent - resolved to one identity
  • What was attempted, on what target, and its blast radius
  • The canonical verdict: allow, step-up, hold, or block
  • A 0–100 Action Trust Score and its band
  • A sha256 seal over the decision, so any later edit is detectable
  • The organization it belongs to - every read is tenant-scoped

Many engines, one ledger

A finance pay-run decision and an Aegis security decision produce the identical record. They come from different engines, but they speak the same request and response shape and write to the same ledger. That’s what makes the audit trail uniform - and what makes adding a domain (HR, procurement, deploy-gating) a matter of registering an engine, not reshaping the contract.

Idempotent and tamper-evident

Writes are content-addressed: a retried, identical decision de-dupes to one row, while a genuine re-evaluation whose verdict or context changed produces a new row - exactly what an audit trail wants. Each row is sealed, so altering a stored record breaks its hash and is detectable, and row-level security scopes every read to its tenant.

Hands-on labs

Practice against a realistic scenario. Each lab lists the steps, what you should see, and the checkpoints that confirm you got the same result.

Lab 1

Prove two domains share one ledger

Scenario

You want to confirm that a finance decision and a security decision land in the same place, in the same shape.

Steps

  1. 1

    Run a guarded pay run so a payment decision is recorded.

    Expected: A finance-domain row appears in the Decision Ledger.

  2. 2

    Trigger a sample security decision (a privileged production IAM change).

    Expected: A security-domain row appears in the same ledger, same shape.

  3. 3

    Filter the ledger by verdict and by domain.

    Expected: Both rows share the verdict vocabulary; the summary shows counts by domain and by verdict.

Checkpoints - you got it right if…

  • A finance and a security decision both appear in one ledger
  • Both rows use the same canonical verdict vocabulary
  • Each row carries a sha256 proof and is scoped to your org

Frequently asked questions

What is the Decision Ledger?

A single, append-only, tenant-scoped record of every consequential decision Fintra makes across finance and security, each in one canonical shape with a verdict, a trust score, and a tamper-evident sha256 seal.

What does “many engines, one ledger” mean?

Different domains use different decision engines, but they all emit the same request/response shape and write to the same ledger, so the audit trail is uniform no matter which engine decided.

Does a retry create a duplicate row?

No. Writes are content-addressed, so a retried identical decision de-dupes to one row, while a real re-evaluation with a changed verdict or context creates a new row.

Is it multi-tenant safe?

Yes. Every decision is stamped with its organization and every read is scoped to that tenant, enforced at the database with row-level security.

Ready to try it in your own workspace?

Fintra is the AI Finance Operating System for SMBs - accounting, payroll, planning, HR, and compliance under one login, with governed AI doing the heavy lifting.

Talk to us