Lock #2: the first thing PRML falsified was its own distribution hypothesis. The second was its own counting bug.

The mechanism worked. The outreach didn't. Lock #2 resolved at 0 / 3 tonight: zero independent contributors filed RFC engagement during the two-week window. An honest account of what missed, the counting bug we caught two days before, and what changes for v0.3.

On 2026-05-08 I locked a public commitment:

Lock #2 — external_contributor_count for the PRML v0.2 RFC, target ≥ 3, resolve date 2026-05-22 23:59 UTC.

Hash: 6d85e0c3d3af446733f8777449f3ff617889dba99a04f7f27c73be763dedf98c.

Today the lock resolved at 0 / 3. Zero independent contributors filed RFC engagement (issues or PRs against rfc-v0.2-labelled tracks on studio-11-co/falsify) during the two-week window.

That's a real miss. Not partial. Not "we were close." Zero.

Four notes

1. The mechanism worked. Lock #2 exists exactly so that a missed commitment can't be quietly re-framed after the fact. The hash was public, the target was public, the resolve date was public. The fail is now public too — automatically, via the same registry, with no admin intervention from me. If Lock #2 had soft-failed silently, the whole pre-registration thesis would be theatre.

2. The diagnosis is a distribution problem, not an interest problem. The v0.2 RFC text is technically sound: the JSON Schemas validate, the conformance vectors pass byte-equivalently across four reference implementations, the field-name drift between v0.1 and v0.2 RFC is documented in the analysis appendix. What didn't happen is the RFC reaching rooms where someone is paid to read RFCs in this domain. That's on me, not on the spec.

3. v0.2 still freezes today, with founder-only authorship. The version doesn't get postponed because the engagement target was missed — that would be moving the goal-posts. The RFC text becomes v0.2 final on the originally-scheduled date.

4. Two days before this lock resolved, a registry-side audit found the counting routine for Lock #1 was buggy. The unique_producer_count source was supposed to deduplicate producer.id values across all committed manifests, excluding falsify.dev and studio-11.co. It was instead treating quoted ("falsify.dev") and unquoted (falsify.dev) values as distinct, and falling back to a regex on truncated previews that captured dataset.id and model.id as if they were producer.id. The displayed count was 8; the correct count is 2 (two test-placeholder producer.id values — example.com and onboarding-walkthrough-test — both also visible on /board, neither a real external user). The bug was fixed and deployed on 2026-05-20. The lock manifest itself was not modified — only the counting code that observes it. The result: Lock #1 is now correctly reading 2/25 with 26 days left, not the inflated 8/25 we'd been showing. This is what running the mechanism on yourself looks like in practice. If a critic finds the next bug, that's still PRML doing its job; if we find it first, that's also PRML doing its job.

What changes for v0.3

• Outreach starts before the lock, not in parallel with it.
• The lock target gets calibrated against a list of named potential reviewers, not a hopeful round number.
• The window is 90 days, not 14.

Things that did happen between lock and resolve

Stating this without celebration. The contributor target slipped; the rest of the work did not.

• Three byte-equivalent reference implementations now ship JS / Go / Rust alongside the original Python (20 conformance vectors, byte-equivalent across all four).
• Audit/compliance crosswalks published for three named frameworks: EU AI Act Article 12, NIST AI RMF 1.0, ISO/IEC 42001:2023. Subcategory-by-subcategory, FULL / PARTIAL / NONE tagged, honest about what PRML doesn't cover.
• GitHub Action (prml-verify-action, now v1.1.0) shipped four modes: guard, verdict, lock, and schema-only. On the GitHub Marketplace.
• MLflow plugin (mlflow-falsify, v0.1.3) auto-tags every run with the PRML manifest hash. The v0.1.3 fix closed a circular-import bug that had silently broken the entry-point in earlier releases.
• Inspect AI adapter (falsify-inspect, v0.1.2) wraps the UK AISI evaluation framework with PRML pre-registration. Includes a full MMLU-Pro worked example.
• Cookbook Pattern 11: PRML + Sigstore for execution integrity — closes the §8.1 execution-integrity gap with cosign + Rekor.
• First-party telemetry running across all three domains. First organic search referrers landed during the window.
• Four Zenodo DOIs minted (spec + three implementations). PRML is citable from this point forward.
• Two awesome-list inclusions, both during the v0.2 window:
  1. PRML accepted into awesome-leipzig on 2026-05-17 — first independent acceptance into a curated public resource.
  2. PRML merged into ASSERT-KTH/awesome-open-science-software (162 stars, maintained by Martin Monperrus at KTH/INRIA, sits alongside CodeMeta and Software Heritage) on 2026-05-20 — first inclusion into an academically-affiliated open-science software list.
  Neither merge counts against Lock #2 (different mechanism, different signal), but together they are evidence that the technical content reaches the audience it was written for once it lands in a curated list, even if direct RFC engagement did not.