The readiness certificate · PR-v1
Most “production ready” claims are a sentence in release notes. Ours is a runnable, machine-checkable artifact with a published boundary — decomposed into named clauses, enforced by checkers with failing exit codes, re-run every release cycle. It is true or false, never “green-ish”. And it has already refused to certify this project once, in public, when the evidence turned against it.
The claim
“The release is production-ready” is not a mood — it is a logical conjunction, and every clause is backed by named checkers with published pass criteria. If a checker did not run, the clause is FALSE. If the evidence goes stale, the certificate is FALSE. If a checker itself is broken, the certificate is FALSE.
PR-v1 = C1 ∧ C2 ∧ C3
// standing, not a snapshot:
// gates re-run every release cycle · evidence expires after 90 days
// re-issuing rewrites the same public files — an old TRUE can never lingerWhat stands behind each clause
The language behaves the way the specification says.
spec-lint --strict fails otherwise: 100% cited.Safe SuperJ cannot reach undefined behaviour: no memory-unsafety, no bad dispatch, no unproven escapes, no unchecked arithmetic hazards.
Memory behaves as documented — arena reclamation is exact and O(1), stack placement is safe, and no SDK surface has unmeasured allocation behavior.
Four more clauses are built and reported but deliberately not gating in PR-v1. A clause set that implied a completeness it does not have would be the first lie — so the phasing is explicit: PR-v2 adds C4 ∧ C5, PR-v3 adds C6.
Built and reported. Gates from PR-v2.
Versioned constants pinned to a named machine, armed with a >2× regression ratchet. Gates from PR-v2.
Corpus replay across releases. Gates from PR-v3.
The machinery that keeps this page honest. Reported, not gating.
The trust question
Fair question — a self-issued certificate is only as good as its incentives. Six properties separate this one from a press release.
Nothing about the claim requires trusting us. Every command on the evidence page is copy-paste runnable against the public corpus. If the certificate says FLAT and your run says LEAK, you have refuted it — locally, in minutes, without asking anyone. A claim you can refute yourself is a different kind of claim.
The certificate went TRUE only after going FALSE. When the SDK moved under the corpus — the 1.3.6514 string-model rework — 96 tests contradicted their pins, and the certificate folded, rendering FALSE with the failing clauses named until the migration landed. A gate that has visibly refused its own project is a gate with inspectable incentives.
Every report run is stamped with {plan revision, SDK version, corpus hash, git commit, tool versions}. The certificate cannot drift from its evidence: stale evidence, or evidence from a different commit, renders FALSE — not “probably fine”.
The certification campaign audited its own instruments and found five ways certification could lie — gates that never gated, denominators that shrank silently, mention-only coverage, unwired report layers, stale pins. All fixed, and turned into rules the certificate now enforces. Retracted claims are never edited away: there is an append-only corrections ledger. The full story →
Every issued page must carry a what this does not prove section. A contract that only lists passes is marketing; the boundary is what makes it a measurement. If a certificate page has no boundary section, treat it as void.
The release ships a few hundred bytes pointing at the evidence — no test code, no validators, no corpora bundled in the toolchain. Claim and evidence are one hop apart, and the evidence is regenerated per release. Nothing is bundled in a way you cannot inspect.
The honest part
Every certificate page must carry its boundary, verbatim from the contract. Here is ours.
MerkleTree.computeTreeNative silent no-op, upstream #6127) — visible as a red row in the report, explained in the boundary rather than hidden. A certificate with zero caveats is the one you should distrust.Refute it
# the 10-second check — is the claim standing right now?
$ curl -s https://superj.dev/readiness/PR-v1.json
# the real check — run every gate yourself (~30 min, provenance-stamped)
$ git clone <certification repository> # linked from the release notes
$ python3 scripts/test-report.py
$ python3 tools/readiness-cert.py # exit 0 = the claim holds todayAnything but TRUE in the JSON, or an age_days beyond the expiry rule, means the claim is not standing. If readiness-cert.py exits non-zero it prints the failing clause and the objective that broke — that output is the refutation. File it, cite it: the certificate's own contract says it must yield.
Lifecycle
| Event | What happens |
|---|---|
| Gates re-run per release cycle | New evidence, same file names. |
| A clause turns red | The public page flips to FALSE at the same URL — there is no archiving step to forget. |
| Evidence ages out (90 days, test/measurement tiers) | The certificate renders FALSE until re-issued. |
| A pinned defect's ticket closes | The pin flips to a fixed-contract assertion; the red row turns green the same day. |
| The contract grows (PR-v2 = +C4 ∧ C5, PR-v3 = +C6) | New contract version, new pointer file; the old one keeps its own status. |
The one-paragraph version
It is a standing, machine-checkable predicate — not a badge. Three clauses, published checkers with failing exit codes, a corpus whose every test cites its contract. Provenance-stamped, expiring when stale, failing closed, carrying its boundary and known defects in public. It has refused to certify this project when the evidence turned against it — and it can be refuted by anyone with a terminal in under an hour. That — the refutability, not the green checkmark — is what makes it worth trusting.