Tools & Code · v0.1

s2l-verify — check our certificate without trusting us

One file · no dependenciesApache-2.0

An assay office that asks to be believed is a marketing company. The certificate we issue is only worth something if the counterparty can check it themselves, offline, without our servers being involved and without our goodwill being required. s2l-verify is that check: one Python file, no third-party dependencies, no network calls, readable in a sitting.

What a verification looks like

$ python s2l_verify.py certificate.json --sample ./delivered_data.jsonl

certificate 4f2a-91c8 · seller: Northside Clinical Data Ltd

✓ signature valid            rubric r2, issued 2026-07-14, key s2l-2026-a
✓ sample hash matches        sha256 9c1f… over 4,000 sampled records
✓ composite recomputes       72  (from published r2 weights)
✓ rubric version current     r2 is the live rubric (no revision since issue)
! relationship: advised      Sell2Labs advised this seller on remediation.
                             Cooling-off ends 2027-09-01.
! dimension incomplete       rights: not scored at issue

3 checks passed, 1 warning, 1 disclosure. exit 0

Every line is derivable from the certificate, the published weight table and the file on disk. Nothing in that output required asking us anything.

The two attacks it closes

Score inflation. A certificate is a signed document, so a listed composite that does not match the signed component scores is caught by arithmetic rather than by trust. The verifier recomputes the weighted sum from the published weights for the stated rubric version — it does not read the composite field and believe it. If someone edits a number, the recomputation disagrees and the signature fails first.

Sample swapping. The subtler attack: get assayed on a carefully prepared sample, deliver something else. The certificate names the SHA-256 of the exact sampled records, and the sampling procedure is deterministic given the seed recorded in the certificate. Point the verifier at the delivered file and it re-derives the sample and compares. A seller who delivers a different corpus than the one assayed produces a hash mismatch on the buyer's own machine, before payment.

Relationship disclosure is a check, not a footnote

An assay office that also advises sellers has a conflict, and the honest response is to make the conflict machine-readable rather than to claim it does not exist. Every certificate carries our relationship to the seller at time of issue:

--strict turns any disclosure into a non-zero exit, so a buyer can wire the verifier into their intake and refuse advised certificates as policy rather than as a judgement call.

Design constraints, and why they are constraints

• Single file, standard library only. A buyer's counsel should be able to read the whole verifier. Dependencies are a place for behaviour to hide, and a supply chain is an attack surface on a tool whose only job is to be trustworthy.
• No network. The public key is embedded and also published here and in the repository; verification works on an air-gapped machine. A verifier that phones home can be told different things about different certificates.
• Fails closed. Unknown rubric version, unknown key id, malformed certificate, or a dimension the published weight table does not contain — all of these are errors, not warnings. The failure mode of a verifier must be "refuse", never "assume".
• Key rotation is public. Keys are named in the certificate (s2l-2026-a above) and the full key history, with issue and retirement dates, is published. A certificate signed by a retired key still verifies for the period the key was live, and says so.

Use it

# no install; the file is the tool
curl -O https://sell2labs.example/tools/s2l_verify.py

python s2l_verify.py certificate.json
python s2l_verify.py certificate.json --sample ./delivered_data.jsonl --strict
python s2l_verify.py --print-weights r2      # the weight table it used
python s2l_verify.py --print-keys            # embedded key history

Exit codes: 0 verified (warnings allowed), 1 verification failed, 2 malformed input or unknown version. It is meant to be run in a pipeline as much as by a person.

What it does not tell you

The verifier proves that a certificate is authentic, unmodified, arithmetically consistent, and about the file in front of you. It does not prove the underlying judgement was right. A composite of 72 is our assessment under a published method with stated incompleteness — if the fidelity judge was wrong about an audited slice, the signature is still perfectly valid over a wrong number.

That is the correct division. Cryptography can guarantee integrity; only method and track record can earn the judgement, which is why the rubric, the weights and the deterministic checks are published — see assay — and why every certificate names which dimensions were not scored at all.

Found a way to make a modified certificate verify? That is the bug we most want to hear about, and we will publish it with the fix.