https://registry.falsify.devregistry.falsify.dev/commitregistry.falsify.dev/04fa1689ac552fb1…registry.falsify.dev/04fa1689 · locked
PRML · v0.1 · CC BY 4.0
Pre-registered ML manifest
Step 1 · Paste
Step 2 · Compute
Step 3 · Receipt
Step 4 · Badge
Open spec · CC BY 4.0
00
01
02
03
04
05
Lock the threshold before the data.
12 YAML fields. UTF-8. PRML §3 canonical bytes.
SHA-256 over the canonical bytes. Steps timing, not typewriter.
The hash is the protagonist. Any retroactive edit breaks it.
A re-derivable claim. No producer trust required.
The threshold, before the data.

Lock your eval claim
before the run.

One YAML file. One SHA-256. No account, no server-side state beyond the hash. The seal travels with you for the lifetime of the system.

version: "prml/0.1"
claim_id:    "01911000-0000-7000-8000-000000000088"
created_at:  "2026-05-18T11:00:00Z"
metric:      "accuracy"
comparator:  ">="
threshold:   0.92
dataset:
  id:        "imagenet-val-2012"
  hash:      "e3b0c442…7852b855"
seed:        42
producer:
  id:        "your-org.com"

Canonicalising 12 fields.

Per PRML §3 deterministic rules. Byte-equivalent across four reference implementations — Python · JavaScript · Go · Rust — verified by 20 conformance vectors.

Computing SHA-256 over canonical bytes…
Permalink
registry.falsify.dev/04fa1689…
Locked at
2026-05-18T11:00:23.471Z
Verifiable by
any of 4 reference impls, offline
Audit chain
prior_hash anchored; lifetime >= retention horizon
PRML locked 04fa1689ac55
[![PRML locked · 04fa1689ac55](https://registry.falsify.dev/badge/04fa1689…svg)](https://registry.falsify.dev/04fa1689…)

A reviewer who suspects the threshold was tweaked re-derives the SHA-256 from canonical bytes and either gets the same digest, or they don't.

The threshold,
before the data.

spec.falsify.dev registry.falsify.dev github.com/studio-11-co/falsify
1 YAML
2 Compute
3 Receipt
4 Badge
60s loop · spec.falsify.dev/demo