# Declaring Readiness Is Not Becoming Ready ## Claim A self-declared readiness flag records what you intend, so treating it as evidence of conformance moves the verification burden onto the people the flag was meant to protect. <!-- atomicity: 1 idea ✓ --> ## Evidence **Source**: [[3. Resources/Readwise/Articles/WordPress 7.1 Is Coming. Are Your Custom Blocks Ready]] — Ryan Welcher on `apiVersion: 3` > [!quote] > It's a promise, not the work. Setting `apiVersion: 3` in a block's `block.json` tells WordPress the block is iframe-ready. It is a one-line change and it is checked by nothing. The actual work — replacing bare `window` and `document` access with `ownerDocument` and `defaultView`, moving canvas styles out of `enqueue_block_editor_assets`, deleting `.wp-admin`-scoped selectors, auditing third-party libraries — is entirely separate and entirely optional from the platform's point of view. **Update, 2026-08-03 — the platform resolved this by removal.** The [7.1 dev note](https://make.wordpress.org/core/2026/08/03/iframed-editor-changes-in-wordpress-7-1/) makes the post editor *always* iframed, "regardless of the theme type, the block API versions of the registered blocks, or the block API versions of the blocks in the content." In 7.0, `apiVersion: 3` was precisely what triggered iframing. As of 7.1 it gates nothing. WordPress did not build a checker for the unverifiable declaration — it stopped consulting it. The claim below is unaffected; its worked example has been overtaken, and the manner of the overtaking is itself instructive. The consequence is precise: a user installing a block that declares version 3 has no more information about whether it works than before the flag existed. The declaration transferred confidence without transferring evidence. And because every failure mode here is silent, the person who discovers the gap is the end user, at the moment their editor misbehaves. ## Scope & conditions - **Holds** wherever a platform accepts a declaration in place of a check — API version flags, feature-support manifests, compliance attestations, accessibility statements, SBOM completeness claims. - **Breaks** where the platform can mechanically verify the claim. Then the flag is a cache of a check rather than a substitute for one, and it carries real information. - **Weakens** where the declaration carries a genuine penalty for being wrong — legal liability, delisting, loss of certification — since cost restores some signal even without verification. - **Weakens** where the declarer is also the party who bears the failure. Self-certification is most dangerous precisely when the cost lands somewhere else. ## Links - [[3. Resources/Permanent Notes/Silent Failures Cost More Than Loud Ones]] — because extends: a false declaration is itself a silent failure, and nothing announces when the promise and the state diverge. - [[3. Resources/Permanent Notes/Portability Is Proven by a Second Implementer Not by Design Intent]] — because extends: both replace a stated property with an observable test. FAIR's core/extension boundary was an assertion until TYPO3 exercised it. - [[3. Resources/Permanent Notes/Gate Contributions on Demonstrated Comprehension Not on Tooling]] — because extends: both distinguish a claim about work from evidence the work happened, and both prefer gating on an act that is costly to fake. - [[3. Resources/Permanent Notes/The Maker Should Not Grade Its Own Homework]] — because applies-in: a self-declared flag is the maker grading itself, with the same structural unreliability. - [[3. Resources/Permanent Notes/Update Signatures Prove Provenance Not Freshness]] — because contrasts on what a marker actually licenses you to conclude; a valid signature and a declared version are both narrower guarantees than they read as. - [[3. Resources/Permanent Notes/A Defense Experts Fail Is Not a Defense for Users]] — because extends: both describe a mechanism that looks like a control and functions as a disclaimer. - [[Open Source Governance MOC]] — because applies-in. - [[3. Resources/Readwise/Articles/SBOMit Making SBOMs Accurate With Attestations - Marco De Vincenzi & Justin Cappos, NYU]] — evidence-for, a second domain instance: a manifest declares what a build was *supposed* to contain; SBOMit's pie analogy makes the same claim about dependency lockfiles that this note makes about `apiVersion: 3` — declaration is a promise, not the work, and only build-time observation records what actually happened. ## Implications - Where a flag is mechanically checkable, check it. `apiVersion: 3` combined with a lint rule for bare `window.`/`document.` in editor scripts would convert a promise into a signal at low cost, and the detection is trivially automatable. - Where it is not checkable, do not let it into a trust decision. Publish it as intent, label it as intent, and require something else for assurance. - **Or remove it from the decision path entirely** — the third option, and the one WordPress took. If the platform can make the decision unilaterally, a declaration it was only ever consulting can simply stop being consulted. A false declaration then costs nothing, because nothing was riding on it. This is available whenever the flag was gating a choice the platform could make for itself, and unavailable when the declaration encodes information the platform cannot otherwise obtain. - The generalization is worth holding at a distance from software: accessibility statements, security attestations, and supply-chain declarations all have this shape, and all are routinely read as findings rather than as claims. ## Open Questions - Do blocks declaring `apiVersion: 3` show iframe defects at a similar rate to those declaring 2? That is directly measurable against the plugin directory and would settle whether the flag carries any signal at all. - What is the minimum verification that restores meaning — static analysis, a smoke test, a third-party audit — and at what point does the cost exceed the value of the flag? - Does adding a penalty for false declaration work better than adding a check, given checks are expensive and penalties require detection anyway? ## Source - [[3. Resources/Readwise/Articles/WordPress 7.1 Is Coming. Are Your Custom Blocks Ready]] — the promise-not-the-work framing and the six silent defects the flag does not prevent - [[3. Resources/Readwise/Articles/Iframed Editor Changes in WordPress 7.1]] — the 2026-08-03 dev note removing `apiVersion` from the iframing decision