Certified search · audit

Signed & verifiable screening record

How “certify and sign” actually works — the difference between “trust us” and “verify it yourself”.

Abstract A certified search guarantees, by construction, that no true match is dropped. But how does an auditor who does not trust the operator confirm that months later? We describe a screening record that carries the answer with witnesses, bound to the exact version of the sanctions list (a Merkle commitment) plus the parameters and the timestamp, and signed (Ed25519). An independent verifier — with only the public key and the list commitment — checks signature, soundness, membership and completeness, and detects any tampering. This is the artifact that Model Risk and audit actually ask for.

1Certifying is not the same as signing

“Certifying” is a property of the computation: the search returns every name within the radius, zero false negatives, because pruning only discards a point when a lower bound proves it is beyond the radius. It is a theorem, verified in tests against brute force at every layer.

“Signing” is something else: making the answer non-repudiable and third-party verifiable. A regulator does not want your word that the screening was correct — they want a record they can check themselves, years later, and be certain it was not altered. That is the difference between confidence and proof, now at the operational level.

2The parts of the record

Each screening emits a document with three blocks, sealed by a signature:

Figure 1. The record. The claim binds the answer to the exact list version (the Merkle commitment) and the parameters; the answer carries the matches with exact distances; the witnesses are Merkle membership proofs. Everything is canonically serialized and signed — tamper-evident and non-repudiable.

The Merkle commitment is the key to “against the right list”: a root hash of the whole sanctions list. Each match carries a short path (≈16 hashes) proving that name is in the list of that root — without transmitting the entire list.

3What the verifier checks — on its own

The verifier does not use the search index. It needs only the service's public key and the list commitment (both published out of band), plus the public spec (how to normalize a name and compute the distance):

Figure 2. The four independent checks. The first three are cheap (signature, a few recomputed distances, short Merkle proofs). The fourth — completeness — is the definitive audit: re-run the exhaustive search against the list of the commitment and confirm the same set.

// real OFAC SDN, 45,197 names · query = variant of a sanctioned name
query:  "shwx kokko special economic zone" · r_α=2 · floor ≥0.95
match:  "Shwe Kokko Special Economic Zone" (d=1) · signed (Ed25519)

INDEPENDENT VERIFICATION
  ✓ Ed25519 signature valid — tamper-evident, non-repudiable
  ✓ list commitment matches the trusted root
  ✓ each match ≤ r_α (recomputed distance) — sound
  ✓ each match is a member of the committed list (Merkle proof)
  ✓ completeness: exhaustive re-run returns the same set — nothing omitted

4Tampering is detected — both ways

The strength of the record is that verification does not depend on the operator's word:

// (a) alter the record after signing
alter the query after signing   → signature INVALID ✗ (detected)

// (b) forge a perfect match and RE-SIGN with the same key
forge distance=0 and re-sign    → the verifier recomputes and finds d=1 ≠ 0 ✗ (detected)

In case (a), the signature seals the exact content — one changed byte invalidates it. In case (b), even if the attacker re-signs, the verifier recomputes the distance from the name and the query: the proof does not come from the signer's word, it comes from the public mathematics.

5What the signature guarantees — and what it does not

The scope is part of what is signed

The signature guarantees the signed claim, with its scope and its premises: the metric, the radius, the conformal recall floor (with its exchangeability premise) and the exact list version. It does not guarantee the truth of the world — if exchangeability breaks (an adversarial name outside the calibration distribution), the guarantee does not cover it. But the premise is inside the record, explicit and auditable.

That is the difference between confidence and proof: confidence hides the premise; the signature names it, binds it to the record, and lets a third party check everything downstream of it.

6In production

The service's private key lives in an HSM/KMS; the public one is published (and can be anchored in a certificate or transparency log).
Each list version is committed by its Merkle root and dated — the record always points to the exact version it was screened against.
The records form a non-repudiable audit trail: for each screened client, what was checked, against which list, with which recall floor, when — verifiable by a third party years later.

Parts: Ed25519 signature and Merkle commitment with SHA-256 (both standard library). The verifier is ~100 lines and does not depend on the search engine. Open reference implementation (SIEVE engine).