Proof of exactly what data an AI used, who approved it, and that it hasn't changed since. The data stays yours; only a fingerprint goes on a public ledger.
Any authorised user of any accounting system can reopen a closed period, change a historical figure and close it again. Not an attacker — an ordinary person using a supported feature. Both numbers came from the real system. Neither is flagged as having changed.
Now connect an AI copilot. It reads whichever version exists at the moment you ask, and nothing outside the vendor's own database records which one that was.
Annex III high-risk AI: automatic, traceable, tamper-evident record-keeping becomes an obligation under the EU AI Act. Annex I embedded systems follow on 2 Aug 2028.
General-purpose AI penalties and Article 50 transparency duties have been enforceable since 2 August 2026 — up to €15M or 3% of global turnover.
Regulation (EU) 2024/1689. Annex III timing per the 2026 Digital Omnibus deferral. The Act requires traceability; it does not mandate any particular technology.
From a ledger, or any structured dataset. Pseudonymised or fully anonymised, depending on how you deploy it.
A named reviewer signs off the dataset. Configured once at dataset level, not per query.
A fingerprint and timestamp go onto a public ledger. The data itself never does.
Approved records only — or the answer declines. Not the raw ledger.
Every answer traces back to a record, a named approver and an on-chain timestamp — and anyone can check that trace without an account and without trusting us.
| Anchors a hash externally | Publishes how to reproduce the check | |
|---|---|---|
| Self-hosted digital signatures | ✗ | ✗ |
| "Blockchain-secured" vendors | ✓ | ✗ |
| OpenBookChain | ✓ | ✓ |
An anchored hash answers "was this hash tampered with?" It does not answer "can I, from outside, confirm this hash matches the real record?" That second question is the only one that matters — and answering it in public is the whole company.
We hold nothing of yours. Your own wallet, your own keys, your own storage — and in client-hosted mode we never see raw personal data at all.
Hash anchoring is mature and widely available. The published, reproducible verification method is the differentiator — not the anchor.
the AI used
approved it
they approved it
since that moment
We do not claim the data is true. No system can certify truth at the point of entry, and anyone who says otherwise is selling an illusion. What we make permanent is accountability: a bad figure isn't sanctified by the ledger — it's pinned to a name and a timestamp, visible, challengeable and correctable.
One limit, before you find it. A single anchored record proves that record hasn't changed. It doesn't prove nothing was left out of a set. Batch anchoring over a Merkle tree answers that — hash the period, publish the root — and it's a funded item on our roadmap, not a solved one.
Two founders. Nothing raised. We never claim a connector that isn't shipped, and we publish what isn't built yet on the same page as what is.
We're most useful where a contract already gives someone the right to check your numbers — and no practical way to do it.
Royalty and revenue-share figures self-reported by hundreds of separate businesses, audited once a year at most.
Claims certified after the fact by an independent auditor, against records that must still be there and unchanged.
Evidence whose reliability you have to stand behind — and which a client's system can silently revise.
Where you'll later be asked what the system was told, by whom, and whether it's still the same.
One subscription per connected source, per year. What the source is used for sets the band. Checking a proof is free, for anyone, forever — we don't charge the person doing the checking.
Low-cost entry, so the trail starts accumulating before it's needed.
Adviser-managed entities, bundled across a client book.
Highest exposure and value at risk. Talk to us.
Every answer traces to a record, a named approver and an on-chain timestamp.