Not a log. A chain built as it happened
Every decision, approval and entry, linked from source to statement.
- Subject
- inv-18377
- Entity
- Acme US
- Events
- 8
- Sealed
- 20 Sept 2026 · 18:20 UTC
- Digest
- sha256:8dfffd44d91ed90536a6e8f6cbbdab51b8af7d85f00d35596a48dc2c69cc57a1
- Retained until
- 2033-10-06
- Ledger impact
- SL-US-310002 · GL-US-410002
Each event carries its own digest and the digest of the one before it, so a changed record is a broken chain rather than a quietly edited row.
An open chain stays open. It is never rounded up to sealed.
A subject still waiting on a provider response, a reconciliation or an adjudication has an incomplete record, and the record says so. The temptation an evidence product has to resist is closing a chain because every stage it happens to know about has passed.
Stages the subject has not reached are drawn empty, never optimistically green — the same rule the product’s own lifecycle rail enforces.
What an evidence package contains.
One transaction, and everything that was true about it — sealed as it happened, not assembled afterwards from systems that have since moved on.
The transaction record
Parties, amount, currency and purpose as instructed, with the invoice or purchase order it settles bound to it.
The decision
Approve, hold or reject, with the screening and risk inputs that produced it and the list versions in force at that moment.
The policy version
The exact version of your rules that decided this transaction — not the version running today.
The approver
Who approved or released a held transaction, under which rule, and when. Attribution is to a named actor, never to a role.
Routing & execution
Which rail the transaction was routed to, when it was submitted, and the provider reference bound to it.
Settlement
What settled, when, and against which record from the executing institution.
Ledger postings
The debits and credits the movement produced, exactly as they were written.
Reconciliation
Instructed, executed and settled matched against one another, and any difference is surfaced, not absorbed.
Do not take our word for it.
Every other claim on this page asks to be trusted. This one can be tested. Below is a signed evidence package in the format the platform produces — run the same check an examiner would run, then alter a record and watch the chain break.
What happens when you press Verify
- 1FetchYour browser downloads a signed evidence package containing five sealed payment decisions.
- 2RecomputeIt hashes every record with SHA-256 and compares each result to the hash sealed at decision time.
- 3Walk the chainIt checks that each record still binds to the one before it, then reports pass or fail.
- SyntheticThe payments, counterparties and decisions in the package are synthetic.
- RealThe SHA-256 hashing, the chain walk and the signature check are real, and run entirely in your browser.
The record behind every product.
Understand supplies the source record, Operate the context, ShieldOS the decision, Execute the outcome, Reconcile the comparison and Ledger the posting. Evidence ties each one to the same record as it happens.
Append-only record
Entries are added, never rewritten, and each one is chained to the last.
Tamper-evident chain
An altered entry breaks the chain that follows it, so tampering is detectable.
Decision context
The signals, the policy version and the reasoning that produced the outcome.
Named approver
Who decided, when, and what they saw at the time.
Execution verification
What the bank executed, compared against what was approved.
Settlement and reconciliation
How instructed, executed and settled were matched.
Bring your financial operations into one intelligent system.
Connect the ERPs, banks and providers you already run, establish one view of financial reality across them, and govern, reconcile and prove the work on top.
Onboarding is sales-led with company verification — there is no anonymous signup.