Locked & verifiable.
An evaluation claim anchored to a SHA-256 hash at the recorded time. Anyone can re-derive it from the canonical bytes below.
SHA-256
d43d6edeba8c875fc65fd7c93f289f22b1e6b38914940426cf548c5f4cd878c9Registered2026-10-13T14:04:50.194Z
Independent timestampRFC 3161 · 2026-10-13T14:04:50Z · timestamp.sigstore.dev · token
Transparency logRekor v2 · log2025-1.rekor.sigstore.dev · index 150870638 · inclusion proof
Kindraw hash anchor — not a conforming PRML manifest (code: unknown top-level field (schema additionalProperties: false))
Submitted by@Oxelra-AI
Manifest
claim_id: 01a13594-8815-7a01-8141-51e64a3da140 code: hash: 18d85918ec1daa91f5bcb7774a28cc2bedc944360f1306cee63b920c2481d9b2 id: verify_ers_d32.py comparator: '>=' created_at: '2026-10-13T14:04:49Z' dataset: hash: 353b06be464ae40140cbb4ee0605bcb9169ace3224f55fc43b700ed9dc36b6f2 id: qers-d32-certificate-inputs uri: https://github.com/Oxelra-AI/Qiushi-Engine-Kissing-Number-Research metric: https://arxiv.org/abs/2609.35051 notes: dim-32 ERS kissing-number lower bound. dataset.hash = sha256 of the concatenation, in lexicographic filename order, of the sha256 hex, two spaces and the filename of each of the three certificate input files (d32_supports_binary.txt, d33_kernel.txt, d33_representatives.txt). The combinatorial layer was independently recomputed without importing repository code; the geometric layer was re-transcribed from the repository checker and re-evaluated, not independently re-derived. producer: id: Oxelra-AI seed: 0 threshold: 347584.0 version: prml/0.1raw bytes →
README badge
[](https://registry.falsify.dev/d43d6edeba8c875fc65fd7c93f289f22b1e6b38914940426cf548c5f4cd878c9)Verify in CI
- uses: studio-11-co/prml-verify-action@v2
with:
mode: verdict
expected-hash: d43d6edeba8c875fc65fd7c93f289f22b1e6b38914940426cf548c5f4cd878c9github.com/studio-11-co/prml-verify-action →Verify this hash yourself
Paste your manifest YAML. The canonical hash must match d43d6edeba8c…. This runs the registry's own canonicalization module (canonical.js) in your browser; for verification that does not trust this registry at all, use any of the four reference implementations offline.
Verify the independent timestamp (RFC 3161, offline)
The token countersigns this manifest hash with the timestamp authority's key, so the time claim no longer rests on this registry. Verify with OpenSSL 3 (LibreSSL, the macOS default, cannot check the ESS extension):
curl -sO https://registry.falsify.dev/d43d6edeba8c875fc65fd7c93f289f22b1e6b38914940426cf548c5f4cd878c9.tsr
curl -s https://timestamp.sigstore.dev/api/v1/timestamp/certchain -o chain.pem
awk 'split_after==1{n++;split_after=0} /END CERTIFICATE/{split_after=1} {print > ("tsa-" n ".pem")}' n=0 chain.pem
openssl ts -verify -digest d43d6edeba8c875fc65fd7c93f289f22b1e6b38914940426cf548c5f4cd878c9 \
-in d43d6edeba8c875fc65fd7c93f289f22b1e6b38914940426cf548c5f4cd878c9.tsr -CAfile tsa-1.pem -untrusted tsa-0.pem
Expected output: Verification: OK.
What this receipt proves — and what it does not
- Proves: these manifest bytes hashed to this SHA-256, and the registry attests (Ed25519 signature over hash + timestamp, key at /pubkey) that it saw the hash at the recorded time.
- Timestamp: where an RFC 3161 token is present (the "Independent timestamp" row above), the time claim is countersigned by a public timestamp authority and verifiable offline; backdating it would require compromising that authority, not just this registry. Records without a token rest on the registry's clock alone until anchored. Where a "Transparency log" row is present, the hash is additionally mirrored to the public Sigstore Rekor log with a verifiable inclusion proof.
- Does not prove: ordering, or the claimed result. A PRML receipt establishes that these criteria existed no later than the recorded time; it does not establish that the evaluation ran afterwards — that is what a
prml-linkage/0record is for — and it never establishes that the result is good. - The signature covers hash + timestamp only, not the submitted handle. There is no key-rotation story yet; the current key id is served at /pubkey.
- Limitations: the registry itself is a signed key-value store, not an append-only log — per-record non-equivocation comes from the Rekor entry, and records committed before full-manifest storage (2026-07-11) carry their RFC 3161 token only. No long-term storage guarantee: mirror your hashes in your own infrastructure.
PRML v0.2 is a frozen RFC (comment window closed 2026-05-22) — spec.falsify.dev/v0.2-rfc. Editor: spec.falsify.dev/editor.