Sealed commitment: how do you prove criteria existed without disclosing them?

Some evaluation criteria cannot be published: dangerous-capability thresholds withheld for safety reasons, benchmarks that are commercially confidential, bounty pass levels that participants must not see. The party still needs to show, later, that the bar existed before the result. A sealed commitment does that.

Where the need shows up

• Frontier-model safety evaluations whose thresholds and test contents are withheld for information-hazard reasons; outside reviewers can then neither assess the evaluation nor verify the claim.
• Audits in which the criteria come from the audited party and are commercially confidential, such as the benchmarks a provider supplies under DSA Article 37 audits.
• Bug bounties and structured red-team exercises where pass thresholds must be fixed before participants start but hidden until the exercise ends.
• Runtime controls that must not reveal the full threshold, so the control does not become an optimisation target.

What a sealed commitment proves, and what it does not

• Proves: a specific byte sequence, the criteria, existed no later than the time in the independent timestamp; any later text that does not reproduce the hash is not that object.
• Does not prove: that the criteria were good; that the evaluation was run after the commitment; that all pre-registered criteria were later reported (a party can seal ten and reveal two); anything about the outcome.

It is evidence, not authority. The reviewer, auditor or committee still decides whether the bar was the right one. The commitment settles only which bar existed when.

How to do it by hand

1. Write the criteria as one file: metric, comparison rule, threshold, evaluation dataset identity and hash, seed where relevant, and the model version it applies to.
2. Compute the SHA-256 of the file. Store the file where only you can reach it; the digest is what goes public.
3. Obtain an independent time on the digest: an RFC 3161 timestamp token from a public time-stamping authority, or a public transparency-log entry. Both are free and both are checkable by a third party without trusting your clock.
4. Publish the digest and the time evidence wherever the relying party will look for it: the audit file, the model card, a public registry entry.
5. Reveal on demand. Give the relying party the file. They recompute the digest; if it matches the published one, the timestamp applies to that content. If it does not match, nothing was proved.

What the public registry does with it

registry.falsify.dev accepts sealed commits: the manifest is validated, canonicalised, hashed, signed and anchored to an RFC 3161 timestamp and a transparency log, the text is withheld, and the permalink and receipt show "sealed". A reveal is accepted only if the supplied bytes re-derive the hash. A sealed manifest is an ordinary PRML v0.1 manifest whose bytes the producer keeps private; nothing in the format changes. Field-level disclosure, revealing the threshold while keeping the dataset private, is an open design question in the v0.3 backlog.

Where PRML fits, if you want a standard form. The steps above need no particular tool. PRML is an open, vendor-neutral record format for exactly this object (metric, comparator, threshold, dataset identity and hash, seed) with a canonical byte encoding, a registered media type (application/vnd.prml+yaml) and free verifiers. It is evidence, not authority: the governance process still decides; the record independently proves which criteria object existed at the relevant time. What is PRML?

Sources

• Registry documentation: sealed commits
• PRML v0.3 backlog: sealed commitments and selective disclosure
• DSA Article 37 audits: where the criteria come from