Product · Evidence
A record you can check without us.
Every decision writes a row that is never updated and never deleted, alongside a byte-exact copy of each external response it rested on, filed under an address derived from its own content. Years later you can reconstruct which rule applied, what data existed, and who decided what — and verify that none of it moved in the meantime.
The decision record
Written on every decision, including the ones that resolved to CREDIT in a millisecond and nobody ever looked at. There is no sampling, because sampling is only discovered to have been a mistake at the moment the missing record is the one being asked for.
- Never mutated
- The store takes inserts. Update and delete are not available to the application, to support, or to us.
- The full input
- The deposit as received, which address book entries it matched, every source consulted and what each of them returned.
- The rule that applied
- By version, resolving to the exact configuration text in force at that moment rather than the current one.
- The human steps
- If a hold went to review: who opened it, what they were shown, what they decided, and when.
- The access trail
- Every internal read of your data, including operational queries made by us, lands in a separate append-only log that you can export.
Content-addressed snapshots
Each external response is stored under an identifier derived from its own bytes. Change one character and it becomes a different object at a different address, while the original address still resolves to the original bytes. Tampering is not blocked so much as made pointless.
- Addressed by content
- A reference inside a decision can only ever point at the exact bytes that were seen when that decision was made.
- Write-once storage
- Object versioning with object lock. There is no overwrite path — not for the application, and not for an operator with production access.
- Raw before derived
- The response is stored before it is interpreted. A conclusion can always be recomputed; a raw record that was never kept cannot be reconstructed from the conclusion.
What an audit bundle contains
One request against a decision id returns an archive. It is assembled from the stored objects, not regenerated from current state.
| Item | What it is |
|---|---|
| manifest.json | Every field of the decision, the evidence hash, and written instructions for checking that hash yourself. |
| layer_a/ | The stored raw response from each authoritative list source consulted, whether it hit or not. |
| layer_b/ | The stored raw body from each paid source consulted, where that source’s terms allow it to be passed to you; otherwise the call record, the source name and the list version. |
| rule/ | The exact rule configuration that produced the verdict, at the version named in the decision. |
| chain/ | The on-chain record of the deposit as we read it at the time. |
| report.pdf | The same content laid out for a reader who is not going to open a JSON file. |
Retention
Decision records and their snapshots are kept for at least five years — longer than most applicable regimes ask for, and longer than most disputes take to arrive. It is a floor written into the contract, not a storage tier that quietly rolls off when it gets expensive.
Verify it yourself
Integrity you have to take our word for is not integrity. Three checks, none of which require us to participate:
- 01 Recompute the hash of every stored object in the bundle and compare it with the address it was filed under. A mismatch means the object is not the one the decision referenced.
- 02 Recompute the evidence hash across the bundle contents and compare it with the value written into the decision at the moment it was made.
- 03 Re-read the on-chain portion against a node you run yourself, with no dependency on ours.
When a freeze actually lands
A freeze that touches you becomes a package for the issuer and for counsel within minutes rather than days: the decision history for the affected flow, the evidence behind each decision, and a sequenced checklist for the first day, the next day and the first week. The reason to prepare it in advance is that the hours after a freeze are the worst possible time to be assembling records.
You can leave with all of it
Full export of every decision, snapshot and log that belongs to you, in the formats described above, without raising a support ticket. For institutions running the private deployment, none of it left in the first place. Not building lock-in is easier for you to verify than a promise not to exploit it.