When a court orders you to produce evidence of how your AI behaved, you have two bad options and one good one. Hand over everything, and disclose your customers, your costs and your model. Hand over a summary, and be asked why it should be believed. Or hand over exactly what is relevant, and let the other side check for themselves that nothing else was altered, removed or renamed. That third option is a construction, not a promise — and this page is it, running in your browser.
| decision | yield_and_halt |
| modelVersion | obstacle-net 4.2.1 |
| confidence | 0.91 |
| safetyOverride | false |
| contractRef | withheld — commercial |
| operatorOnDuty | withheld — personal data |
| modelWeightsDigest | withheld — trade secret |
Most of the attention in the room goes to the EU AI Act, and its high-risk obligations are now some way off. The nearer date is a different instrument, it needs no regulator to activate it, and it turns an absent record into an argument against you.
Directive (EU) 2024/2853 — the new Product Liability Directive — applies from 9 December 2026. Software and AI are products under it, and liability does not require anyone to prove you were careless.
The provision that matters to an evidence layer is the disclosure one: a defendant can be ordered by a court to produce the relevant evidence at its disposal — and where that order is not met, the court may presume the product was defective. The absence of a record stops being neutral. It becomes the claimant's strongest exhibit.
Dates below are drawn from the same public ruleset our sister product classifies against, so this page cannot quietly drift from the engine. Indicative — confirm the final published text for your market with counsel.
Every row below is performed live in your browser somewhere on this page, and the link takes you to the place it happens. If something is not on this list, this page does not do it — the roadmap at the bottom says what is arriving next, and when.
node — no dependency, no network, no cooperation from us.
Verify your own →
Hash a document and you get one number for the whole thing. Remove a line and the number changes, so a redacted document can never be checked against it. SureWard commits to a record differently: one salted leaf per field, combined into a Merkle root. That root is the record's identity, and — as the next act shows — it survives the removal of any field.
Meridian Robotics Kft. operates autonomous vehicles in a Kecskemét distribution centre. On 14 May 2026 one of them classified an obstacle and stopped. On 3 August a claim was filed. This is the record its systems wrote at the time — the field values are edited live, so the commitment below is computed from what is actually on your screen.
| Field | Value | Leaf |
|---|
safetyOverride has two plausible values; an opposing party would hash both
against the disclosed leaf and read the answer in under a second. The salt is exactly
sixteen bytes, and every component of the leaf carries its own length prefix — because an
earlier version of this construction allowed at least sixteen, which let the leading
characters of a value be pushed into the salt. A payout of 12345 could be re-presented as 345
with a salt two bytes longer, producing a bit-identical leaf and an identical commitment.
Found by adversarial review on 31 August 2026, before anything used it.
The claimant is entitled to the decision, the model version and the state of the safety controls. They are not entitled to the operator's staff number, the commercial terms, or the digest that identifies the model weights. Withhold those three and the other nine still check out — against the same commitment as before, with nothing recomputed and nothing re-signed.
| Field | Disclosed to the claimant | Leaf |
|---|
Now try to cheat. Each of these is the move a party would actually make.
There are two Merkle trees here, and they do different jobs. The first, in Act 1, is built over the fields of one record — that is what makes redaction checkable. The second is built over the records of a log, and it is what lets a single record be proved to belong to the whole without producing the whole. One tree protects the inside of a record; the other protects its place in history.
Twelve records were written that fortnight. The claim concerns one of them. Pick it and the page computes the audit path: the handful of sibling hashes that let anyone recompute the published root from that one record — without seeing any of the other eleven.
An inclusion proof says a record is in the log now. It does not say the log is the same log you were shown last quarter. A consistency proof does: it demonstrates that the earlier root is a prefix of the current one, so records were appended and none of the earlier ones were edited, reordered or removed. This is the property people are reaching for when they say "blockchain" — and it is a 1962-vintage tree with no chain, no consensus and no token.
The records are also linked to each other and signed in position. Every button below is an attack somebody would really try, in ascending order of sophistication — ending with one that assumes the attacker holds our signing key. Verification runs on your machine, so nothing you do here reaches us.
Redaction is abstract until it is your record and your claimant. Pick the business you recognise and the panel below works through one: the system that writes the record, the claim that arrives years later, which fields go across and which are held back — and why — and how long the record has to survive to still be there when it is asked for.
operatorOnDuty, or that it holds personal data.
The names above are a worked example of the shape of a disclosure — chosen so the
withholding reasons are legible — not a taxonomy we ship and not one you would be held to.
Deciding what a record contains is the specification, and the specification is not ours to write.
Nothing on this page is novel cryptography, and that is the point. Every primitive here is old, standardised, and implemented in tooling the other side's expert already trusts. Novel constructions get attacked in cross-examination; boring ones get recomputed and conceded.
An opposing expert recomputes our hashes with sha256sum and no software of
ours. A hash function chosen for novelty is a hash function you will spend a day of testimony
defending instead of using.
Signing is deterministic, so there is no per-signature random nonce and therefore no nonce-reuse failure — the mode that has repeatedly leaked ECDSA private keys in the wild. Keys are 32 bytes and verify with stock OpenSSL.
Certificate Transparency's tree, unmodified: leaves prefixed 0x00 and
interior nodes 0x01, so a subtree root can never be presented as a leaf. Odd
nodes are promoted, never duplicated — duplication is CVE-2012-2459, where two different
record sets share a root.
Because a record's identity is a root over its fields, removing a field leaves the identity intact. Nothing is re-signed at disclosure time, so the signature the other side checks is the one made when the record was written — not one made by lawyers afterwards.
Keys sorted recursively, no whitespace, so formatting can never break a check. One subtlety
that bit us: a payload field named __proto__ vanished from the canonical form
while remaining visible in the record. The accumulator now has a null prototype.
Signatures cover domain ‖ chainId ‖ seq ‖ prevHash ‖ recordHash, so a
valid signature cannot be moved to another position, another log, or another company. For a product
whose claim is this party did this, attribution is the one thing a signature must carry.
A verifier that needs our software, our servers or our cooperation is not evidence of anything — it
is a request to be trusted. Paste a bundle below and it is checked here, in this tab. You can also
take the file away and run it against bare node with nothing installed.
sw-verify is one file of plain JavaScript with no dependencies, no network calls
and no configuration. It is short enough to read in five minutes and to reimplement in another
language in an afternoon — which is the actual test of whether a record is checkable by someone who
does not trust you.
# nothing to install; node 22+ ships everything it needs node sw-verify.mjs bundle.json # exit 0, or exit 1 naming the record and what did not match
This is an early production beta and we would rather you heard the limits from us than found them. Each row says what is true today and what is committed, with a date. When a date moves, this page moves with it.
Everything you just used on this page is real code from the shipped library, running locally. The rows below are about what surrounds it.
openssl ts -verify against roots you choose. A verifier
that also vouches for its own trust anchors is asking to be trusted twice, which is the failure
this whole page exists to avoid. And we will not tell you whether a record helps your case.
net line in this log because this page makes no network request of any kind — not to us, not to a font host, not to anyone. The vhost enforces it with connect-src 'none'.