Is this all of it? Proofs beyond one record

Is anything missing? Completeness chains

A firm that shows ten intact records may have sealed eleven and kept back the awkward one. A time stamp cannot catch that, because it proves only what it is shown. So a firm puts its records in numbered chains, one per desk, product, model or system. Each record carries its chain, its position and the fingerprint of the record before it, and the log refuses a position out of turn, with nothing written.

Anyone holding the chain’s tag asks the log what it holds in that chain:

GET https://api.riskrouter.eu/api/v2/evidence/chain?chain_tag=<64 hex>

The answer is signed with the same key as the log’s heads: how many positions the chain has as of a signed head, and when and where each was sealed. It names no firm and holds no record. The firm shows its records; the verifier checks every position from the first to the last, and names any position the log holds that nobody showed.

What it does not prove: that a record was put in a chain at all. That is a policy for the firm, its auditor or its supervisor to set, and the recorders chain every record automatically once given a chain secret. On a log a firm runs itself, a chain is that firm’s own word unless independent witnesses sign its heads. The construction

What did this field say? Selective disclosure

A lender asked about one decision needs to show the score it used, not the applicant’s file. Sealed this way, a record is a set of salted commitments, one per field. Later the firm reveals one field’s value and that field’s salt; the verifier checks that value against the sealed commitment, and the record against the log. The other fields stay sealed.

Each field’s salt comes from a secret the firm never discloses, so a hidden field with few possible values, such as approved or declined, cannot be found by trying them all. The names of the fields are visible; their values are not.

node records.mjs seal-fields decision.json
node records.mjs disclose decision.json --secret <hex> --salt <hex> --proof proof.json --fields score,outcome

The construction

Were the records kept? Spot checks

Sending an auditor everything is costly and hands over personal data. A sample is cheaper, but one the firm picks proves nothing, and one the auditor picks can be argued with. So the sample comes from a number neither side can choose: the hash of a Bitcoin block mined after the auditor sealed a plan naming its height. The population is the chain’s signed length. The draw is fixed and anyone can repeat it; here it is with the hash of Bitcoin’s first block, for a chain of 1,000 records and a sample of five:

node chains.mjs select --seed 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f \
  --population 1000 --sample 5
positions: 234, 243, 955, 993, 512

The firm shows those five records and no others, and the verifier checks each against the chain. One step stays with the auditor: confirming, on any Bitcoin node or block explorer, that the block at that height has that hash. The verifiers contact nothing, so they say so rather than look it up. The draw

Did both sides agree? Co-sealing

Disputes are usually between two parties who each kept their own version: broker and insurer, lender and bureau, platform and customer. A record only one side sealed is that side’s word. When both share the record and its salt, each seals the same fingerprint as an entry signed with its own registered key. The verifier checks both entries, that they carry the same fingerprint, and that the keys and the parties are different; given each party’s key as it published it, that each entry was signed with exactly that key.

It shows that each party asserted the same record at the time it claimed. It does not show the record is true, or that a key was not stolen. The check

Was it reported in time? Deadline proofs

NIS2, the GDPR and the Cyber Resilience Act set reporting clocks that start when a firm becomes aware of something. A sealed report record carries when the firm says it became aware, when it says it sent the report, and the fingerprint of the report as sent; the seal adds a time the firm did not choose.

node deadline.mjs check early-warning.json notification.json --key keys/

The tool checks each report against both times, and fails a report that claims awareness after an earlier sealed record of the same incident. It does not decide whether a report was due, whether its content was enough, or whether a delay was justified. DORA’s deadlines are set by delegated acts and are not computed here.

Check it yourself

• chains.mjs checks chains, completeness and spot-check bundles and co-seals; records.mjs checks disclosures; deadline.mjs checks reporting times. Standard-library Node, in the conformance kit with the code they import.
• riskrouter_verify.py checks all of them, written separately in standard-library Python.
• Both are held to the same published test vectors, and the conformance suite tests any other implementation against them. Its result is the implementer’s own statement, not ours.
• A software vendor can give its customers a verification page in its own brand: one HTML file that checks a receipt or a disclosure in the browser and is forbidden, by its own security policy, to send anything anywhere.

None of this proves a record is true, or that you have met an obligation; it shows what was sealed and when, and whether what you were shown is all of it. Whether that is enough is for you, your auditor or your supervisor to judge.