AEF 1201: Conformance and Self-Test

1. Status#

AEF 1201 v0.1 is an early draft and will change. It is the eighth document in the series and the second in the 1200 block.

This document is normative throughout. Its requirements bind three subjects, separately and explicitly: a conformance claim, a fixture suite, and a verifier's self-test behavior. Each requirement states which subject it binds. Requirements on record structure belong to AEF 1300 and requirements on what a verifier checks belong to AEF 1200; where a gap in either blocks a fixture from being expressible, that is recorded in section 15 as a finding for that document's next version rather than patched here.

AEF 1001 section 8 defines conformant and states that the word is currently defined and unusable, because nothing states how conformance is demonstrated. AEF 1200 supplied half of the answer: what a verifier must do. This document supplies the other half: how anyone shows that it does it. Until this document, no conformance claim in the series was testable, and AEF 1001 open question 6 has been carrying that debt since 11 August 2026.

AEF 1000 is the source of authority. AEF 1001 supplies the vocabulary, used exactly and not redefined. AEF 1100 supplies the threat analysis, cited by threat id. AEF 1101, AEF 1200, and AEF 1300 are cited by section and requirement id. AEF 1900 is cited by finding.

Versions are dated, kept at their own paths, and recorded in CHANGELOG.md beside this document.

2. Why this document exists, and the problem it does not solve#

Self-test is the implementer grading its own exam. That sentence is the subject of this document and it is stated before anything is built on it, because every mechanism below is a response to it rather than an escape from it. The role is named per AEF 1001 section 7: the party that builds a verifier is the implementer, and where the implementer is also the operator whose records the verifier checks, both defects apply at once.

A fixture suite is authored by the party whose verifier it tests. AEF 1001 section 7.1 concedes that the reference implementation has exactly this shape: a verifier written by the party whose work it checks has no adversary in its history. Passing the suite therefore proves the verifier agrees with its author, which was never in doubt. AEF 1100 threat 9.1 states the residue precisely: a verifier can pass every fixture anyone wrote and fail on the case nobody wrote, and the population of records a verifier should reject is unbounded.

That makes suite adequacy a negative existential of the same species AEF 1101 section 8 refused for irreducibility. To assert that a suite is adequate is to assert that no input exists anywhere that the verifier mishandles and the suite misses. Nobody can establish that, for any suite, at any date. This document does not pretend to solve what AEF 1101 refused to solve.

What it does instead is apply AEF 1101 section 8's own move: replace the unprovable property with a checkable artifact. The suite cannot be shown to cover the cases that matter. What can be done is to declare what it covers, enumerate what it does not, convert every miss into a permanent fixture, and open the suite to counterexamples from anyone. Each of those is an artifact or a public record, and each is falsifiable by exactly the right party: a reader who finds a case the declaration misses has found a defect, and the defect is citable.

3. Normative language#

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174, and only when they appear in all capitals.

Requirements are numbered C1 through C21 and are collected with their classification in section 13. The numbering is stable within a version.

4. What this document owes the series#

Four debts arrive here. Their disposition is stated at the top rather than discovered at the bottom.

AEF 1001 open question 6, demonstrating conformance, assigned to this document at the series' start. Answered in sections 6 and 7: a claim has a required form, and a verifier claim is demonstrated by running the verifier against a versioned fixture suite and publishing per-fixture results.

AEF 1100 threat 9.1, a verifier that accepts what it should reject, CONDITIONAL where the fixture set is adequate. Not discharged, and not dischargeable. Section 2 states why the condition can never be shown to hold. Sections 7, 8, and 9 supply the honest substitutes: declared coverage, an open challenge path, and cross-verifier comparison. The threat's disposition is unchanged.

AEF 1100 threat 9.2, a fixture set with no required-to-fail cases, CONDITIONAL where an independent party inspects the set, with AEF 1100 section 17 recording that nothing says who inspects or where the inspection is recorded. Partially discharged, and section 16 states exactly which half. The coverage declaration in section 7 makes the inspection mechanical: whether required-to-fail fixtures exist is now read off a published manifest rather than judged. The challenge path in section 8 gives any inspection that does occur a public record. What remains undischarged is the inspector: no party is designated to look, and a mechanism anyone may use is not a mechanism someone must use.

AEF 1200 open question 1 and section 14, which identified the eleven requirements checkable only by running the verifier against fixtures. Answered in section 5: they are enumerated and they are this document's jurisdiction.

5. Jurisdiction#

AEF 1200 section 14 classifies its forty-two requirements by observer. Thirty are checkable by inspecting the verifier or its output, one binds judgment, and eleven are checkable only by running the verifier against fixtures. Those eleven are what a fixture suite exists to demonstrate, and they are the jurisdiction of this document:

V8 and V9, that one flipped byte fails and that the failure is fatal. V13, the per-mechanism key binding checks. V15, scope membership for every act log entry. V16, that a declared element's absence is a finding. V21, chain link verification. V26, that a capture time after the seal time fails. V27, approval form. V29, approval absence handled without inference. V36, INCONCLUSIVE when a fatal check cannot run. V41, that absence is never a pass.

Two further checks in the reference verifier, `declaration-binding` and `termination`, have required-to-fail fixtures and no AEF 1200 requirement id to map them to, because AEF 1300 section 14.2 recorded that AEF 1200 section 8's check list predates the fields those checks test. The coverage declaration in section 14 maps them to AEF 1300 requirement ids instead, and section 15 records the mapping gap as a finding for AEF 1200 v0.2.

A fixture suite MAY exercise requirements outside this jurisdiction, and the reference suite does: output-form requirements such as V5, V6, V7, V10, and V42 are cheaper to check from a test harness than by hand. Nothing here forbids that. The obligations below attach to the eleven, because they are the requirements that are claims until a fixture demonstrates them.

6. The conformance claim#

Requirements in this section bind a conformance claim.

AEF 1001 section 8 states that conformance is always to a document and a version, never to the framework at large, and that a claim that does not name both is not a claim that can be checked. This section extends that test to the rest of what checking requires.

C1. A conformance claim MUST contain: the AEF document and version claimed against; the identity and version of the subject, where a verifier is identified as AEF 1101 section 11 requires and a record is identified by digest; the date the claim was made; where the demonstration results can be obtained; and, for a claim about a verifier, the version of the fixture suite the demonstration ran against, stated as the digest section 7 defines. A claim missing any of these is not a claim that can be checked.

C2. A conformance claim MUST be published at a stable path controlled by the claimant, and a superseded claim MUST remain readable at its own path. This is AEF 1000 section 1's versioning discipline applied to claims.

C3. The results a claim references MUST be per-fixture: for each fixture in the named suite version, the expected outcome and the observed outcome, in the vocabulary of AEF 1200 section 7.1. A claim whose results are a single total conceals exactly the information the suite exists to produce, because a suite passed 21 of 22 is a different fact depending on which fixture failed.

C4. A conformance claim MUST NOT describe itself as a certification, an accreditation, or an approval, and MUST NOT state or imply that any body conferred it. This is AEF 1200 V42's constraint applied to claims, and it follows from AEF 1000 section 11: there is no certification body, no registry, and no fee, and conformance is a claim an operator makes and a reviewer tests.

Where a claim lives, argued rather than assumed. A claim is self-published. The alternative is filing with some party, and every version of that party is a body the framework refuses. A registry that accepts and lists claims becomes an authority whose listing confers status, which is certification with the serial numbers filed off. It is also a single party whose withdrawal deletes the claim, which is the failure AEF 1101 section 7 test two names for trust dependencies generally. Self-publication has a real cost and it is stated rather than hidden: nobody can enumerate the claims that exist, a reviewer cannot discover a claim they were not pointed to, and a claimant can delete a claim undetectably, since C2's retention requirement has no observer once the path itself is gone. That is the same shape as AEF 1100 threat 11.2, it is accepted here for the same reason selective non-production is accepted there, and a reviewer should weigh claims accordingly.

What a claim means. Satisfying C1 through C4 makes a claim checkable. It does not make it true, and a checkable false claim is the intended failure mode: a reviewer who runs the named suite version against the named verifier version and gets different results has falsified the claim by exhibit, which is what checkable means.

7. The fixture suite#

Requirements in this section bind a fixture suite.

7.1 What a fixture is#

C5. A fixture MUST be a pinned pair in the sense of AEF 1001 section 6.12: the input retained byte-identical, together with the expected verifier outcome. The input comprises everything the verification consumes: the record, and where the exercised check requires them, the sealed declaration, the artifacts, and the verifier options. A test whose input is regenerated each time it executes is not a fixture and discharges no requirement in this section, whatever it demonstrates.

The exclusion is not a stylistic preference. AEF 1001 section 6.12 defines a golden fixture as retained so that any change in verifier behavior becomes visible as a difference rather than a surprise. A regenerated input changes silently with the code that generates it, so a behavioral change and an input change are indistinguishable in the test's history, which is precisely the drift the fixture exists to make visible. Generated tests are useful, the reference suite is mostly made of them, and they MAY accompany a suite. They pin nothing.

C6. A fixture's expected outcome MUST state: the outcome value from AEF 1200 section 7.1; where that value is FAIL or INCONCLUSIVE, the name of the failing or not-run check; and where that value is PASS WITH QUALIFICATIONS, the expected qualifications by registry class per AEF 1200 section 7.4, including the proposed class where the class is OTHER.

The failing check is required because AEF 1101 section 11 already requires a rejection to say which check failed, so a fixture that pins only FAIL tests less than the output carries: a verifier can reject the input for the wrong reason and match the expectation. The qualifications are required for the same reason one level down. A fixture that pins only the top-level outcome lets qualification behavior drift silently, and qualification behavior is most of what a verifier reports today, since AEF 1200 section 7.2 concludes that PASS WITH QUALIFICATIONS is the best reachable outcome. A verifier that stopped emitting TIME-OPERATOR-ASSERTED tomorrow would still pass every fixture that pins outcomes alone.

7.2 Required-to-fail coverage#

C7. For every check the claimed document defines, the suite MUST contain at least one fixture whose expected outcome is a failure of that check. AEF 1001 section 6.12 requires inputs that are required to fail; this extends the requirement from the suite as a whole to each check, because a suite whose failures all exercise one check demonstrates rejection in general and nothing about the other checks, per AEF 1000 principle 4.

C8. For every check whose failure the claimed document treats as fatal, the suite MUST contain at least one fixture constructed to fail that check and no other, with the expectation that every other fatal check holds on that input. Without isolation, a verifier can pass the suite by rejecting for the wrong reason: an input that fails three checks is matched by a verifier that detects any one of them, and the fixture then demonstrates a third of what it appears to.

Where a check cannot be expressed. A claimed document can define a check no pinned, self-contained input is able to exercise, and AEF 1200 V13's revocation and inclusion-proof branches are the standing example, per section 15 finding 1. C7, C8, and C19 do not bind the impossible: where no expressible fixture can fail a check, the coverage declaration MUST list that check as inexpressible together with the finding for the claimed document, and the check is outside C7, C8, and C19 until the claimed document's next version makes it expressible. This is the declared-scope move again, and its cost is stated rather than hidden: a check listed as inexpressible is a check no conformance claim covers, and a reader of the claim has to weigh a verifier whose hardest branches have never been demonstrated by anyone.

7.3 The coverage declaration#

C9. A suite MUST carry a coverage declaration: a manifest listing every fixture with the requirement ids it exercises, and listing plainly the requirements of the claimed document that no fixture exercises.

This is AEF 1000 principle 3 applied to test suites. Completeness of a suite is meaningful only against a stated boundary, and the coverage declaration is that boundary. Within the declaration, a requirement listed as unexercised is a finding a reader can weigh, cite, and challenge. Without a declaration, the suite's coverage cannot even be discussed, because there is nothing to test a coverage claim against, which is the condition AEF 1001 section 8 describes for records with no declared scope.

C10. A suite version MUST be the digest of its coverage declaration, computed over the declaration's published bytes with an algorithm the declaration itself names, and the declaration MUST bind every pinned fixture input by digest. No canonical form is defined for a declaration: the bytes as served are the bytes digested, which is cruder than AEF 1300 section 5's treatment of records and is chosen because a declaration is one file with one publisher rather than an interchange format. Any change to a fixture, an expectation, or the manifest is a new suite version. The challenge record of section 8 sits outside the declaration, precisely so that recording a disposition does not move the suite version. This is what makes C1's suite reference checkable: a claim names a digest, and a reviewer holding the suite can confirm they hold what the claim was demonstrated against.

7.4 The miss rule#

C11. When a defect is found in a verifier in the field, the input that demonstrated it MUST be added to the suite as a fixture before the fix ships, and MUST remain in the suite permanently.

The precedent is already in the series and is cited rather than invented, with its limit stated. AEF 1900 finding two records a verifier that was wrong in a configuration its tests never occupied: it returned INCONCLUSIVE to a reviewer holding only the published record, against AEF 1200 section 8.4's requirement that absence qualify rather than block. The input that found the defect became a pinned regression fixture in the set that runs on every build. That is the practice C11 makes an obligation. The ordering clause, before the fix ships, is C11's addition rather than something AEF 1900 records, and section 16 states why no artifact can record it.

The rule's value is that it converts the one source of fixtures that is not the author's imagination into permanent coverage. Every fixture the author writes tests a case the author thought of. A field defect is, by construction, a case the author did not, which makes it the most valuable input the suite will ever receive, and discarding it after the fix is discarding the only evidence the suite has of its own blind spots.

C12. A published fixture MUST NOT be removed or altered. A fixture whose expectation is found to be wrong is retired: marked in the coverage declaration with the reason and the date, retained at its path, and from the next suite version onward no longer among the fixtures whose expectations a demonstration is checked against. A demonstration passes a suite version when every fixture in it that is not retired produces its pinned expected outcome, which is the only sense of passing this document uses. The treatment of retired fixtures mirrors AEF 1000 section 11's treatment of withdrawn dormancy notices: a record that retains only the exchanges that went somewhere is not a record.

8. Suite governance and the challenge path#

Requirements in this section bind a fixture suite's governance, and the mechanism is this document's answer to AEF 1100 threat 9.2's missing observer.

The asymmetry that makes open governance workable is worth stating first, together with its limit. A fixture demonstrating a false PASS is a counterexample in the AEF 1101 section 8 sense: falsification by exhibit. It requires no standing and no argument about intent, and whether it reproduces is not a matter of judgment. What can still be a matter of judgment is what the claimed document requires of that input, because two honest readings of a requirement can resolve the same exhibit differently, and the first challenge ever filed, in section 14, is exactly that case. The exhibit settles what the verifier did. It does not always settle what the verifier should have done. A reproducing counterexample is therefore a contribution anyone can make and nobody can legitimately refuse to receive and disposition, and the dispositions below are shaped so that the contested case has an honest outcome rather than a forced one.

Dispositions in this section fall to the suite's publisher: the party that publishes a suite dispositions the challenges against it. For the suites this series itself publishes, that party is the editor, which extends the editor's seat from ruling on objections to documents, per AEF 1000 section 10, to ruling on challenges to fixtures. That extension is stated here rather than assumed, because AEF 1001 section 7 defines the editor's role more narrowly and a role used past its definition is the drift this series records rather than performs.

C13. Anyone MAY submit a challenge against a published suite: an input, the outcome the challenger believes the claimed document requires, and the requirement said to compel it. Submission is through the public repository that carries the suite, following AEF 1000 section 10's pattern, against the suite it concerns.

C14. The suite's publisher MUST give every challenge one of three dispositions, in writing, attributed: adopted, with the challenge input added as a fixture in the next suite version; rejected, with the reason stated; or recorded as unresolved and published. These are AEF 1000 section 10's three outcomes applied to fixtures, and a suite ships with its live challenges attached the same way documents ship with their live objections.

C15. Every disposition MUST be recorded in a public challenge record published beside the suite and outside the coverage declaration, so that a disposition does not move the suite version. The record is retained under the same discipline as everything else in the series: dated, at a stable path, with entries appended and never altered or removed. Appending a dated entry is not rewriting; changing one is.

C16. A challenge demonstrating that a verifier produces PASS or PASS WITH QUALIFICATIONS on an input the claimed document requires it to fail MUST be adopted where the demonstration reproduces against the named verifier and suite version and the requirement's reading is not itself in dispute. Rejection of such a challenge is not among the publisher's options. Where the reading is in dispute, meaning two honest readings of the claimed document resolve the input differently, rejection is not available either: the disposition is the third outcome, unresolved and published, carried together with the finding for the claimed document whose text failed to settle it.

What this buys, stated precisely. AEF 1100 threat 9.2's detection was inspection of the fixture set, and its dependency was somebody inspecting, with nobody designated and nowhere for the inspection to land. After this section, the inspection is mechanical, because C9's declaration states what is and is not covered; the result of anyone's inspection has a place to land and a form the editor cannot ignore silently; and a challenge the editor does ignore is itself visible, because the submission is public and the missing disposition is an absence within a declared obligation, which AEF 1000 principle 3 makes a finding. What this does not buy is an inspector. Nobody is obligated to look, and section 16 carries that honestly.

9. Cross-verifier agreement#

Requirements in this section bind the published results of an independent implementation, and the section is forward-looking, because its subject does not yet exist.

The strongest evidence available that a suite means anything is two independently implemented verifiers agreeing on every fixture in it. Agreement does not establish that either verifier is correct, since both can share a misreading of AEF 1200. What it establishes is that the suite's expectations are implementable from the specification's text alone, which is the property AEF 1000 section 5 demands when it rejects specifications only one implementation can satisfy. Disagreement is better than agreement: a fixture two conformance-claiming verifiers resolve differently is a finding against one implementation or against AEF 1200's text, and either way something specific gets fixed.

C17. For its results to be comparable, an independent implementation MUST publish them per-fixture in the form C3 requires, against a named suite version, under its own verifier identity and version.

C18. A disagreement between two verifiers on any fixture MUST be recorded as a challenge under section 8 against the suite, naming both verifiers and both outcomes, so that its resolution lands in the same public record as every other coverage dispute.

The sentence this section exists to print. Until a second independent implementation exists, every conformance claim in this ecosystem shares one author with its test suite. The claims are checkable, the coverage is declared, the challenge path is open, and all of it is one party agreeing with itself in public. AEF 1000 section 11 makes two independent conformant implementations, together with adoption by an organization unconnected to the author, the trigger for moving the framework to a standards body, and this is the mechanism by which the second implementation would demonstrate conformance, so the sentence is written to be deleted.

10. Self-test where the verifier runs#

Requirements in this section bind a verifier's self-test behavior.

The position: a conformant verifier carries its own required-to-fail fixtures and runs them where it runs. The argument is AEF 1900 finding two, and it is an argument no amount of author-side testing answers. The reference verifier passed its full suite every time the author executed it in the working tree, and was wrong in the configuration every actual reviewer occupies, because the author's environment supplied what the reviewer's does not. A suite exercised only where the author executes it has been exercised only under the author's conditions, which is AEF 1000 principle 2's defect transposed from records to tooling, as AEF 1900 states. A self-test that ships inside the verifier is the one mechanism in this series that exercises the verifier in configurations its author never occupied, because it executes in all of them.

C19. A conformant verifier MUST carry a digest-pinned subset of its fixture suite containing, at minimum, one required-to-fail fixture for every check the claimed document treats as fatal, excluding checks the coverage declaration lists as inexpressible per section 7.2, and MUST execute that subset in its deployed configuration before producing its first verification result in that configuration. For a verifier that is a library rather than a program, the configuration is the process that loads it, and the subset executes once per process before the first result that process produces.

C20. Where any self-test fixture produces an outcome other than its pinned expectation, the verifier MUST NOT produce a verification result, and MUST report the fixture id, the expected outcome, and the observed outcome.

C21. Every verification result the verifier produces MUST record the self-test subset's digest and its outcome. What this buys is stated exactly, because it is less than it sounds. The member is written by the program whose behavior is in question, so it is checkable as to form and not as to substance, the caveat AEF 1300 section 12 established: a verifier that never executed the subset and wrote the member anyway produces an identical artifact. And under C20 a conformant verifier only ever records a passing outcome, so the outcome member carries information solely about verifiers that violate C20. The member that works is the digest: a reviewer can compare it against the current suite's coverage declaration and see whether the carried subset has gone stale, which no assertion-free artifact could show them.

What the position costs, stated rather than weighed away. The distribution carries its fixtures, and the subset is bytes a reviewer downloads whether or not they care. Startup pays the time the subset takes before the first result. A corrupted fixture file converts a working verifier into one that refuses to verify, which is C20 operating as designed and will not feel that way to the reviewer it happens to; refusal is chosen anyway, because a verifier that knows it mis-verifies and verifies is worse than one that stops, and a result flagged as suspect invites exactly the flag-ignoring that AEF 1200 section 7.5 is built to prevent. The deepest cost is epistemic: a passing self-test establishes that the verifier still agrees with its own pinned history in this configuration, and nothing more. It does not touch AEF 1100 threat 9.1's core, the case nobody wrote, and a verifier advertising its self-test as evidence of correctness has converted a drift detector into a certification, which C4 and AEF 1200 V42 both forbid in words and cannot forbid in readers.

11. What this document does not do#

No certification body, no registry, no badge, no fee. AEF 1000 section 11, restated because this is the document where the temptation lives. Conformance remains a claim an operator makes and a reviewer tests, and everything here exists to make the testing cheap rather than to move the claiming anywhere.

No suite is called adequate. The word appears in this document only where it explains why the property cannot be established, or where it quotes the condition AEF 1100 attached to threat 9.1. A suite satisfying every requirement here has declared its coverage, isolated its fatal checks, preserved its misses, and opened itself to counterexample. Whether it covers the cases that matter is a question with no answerable form, per section 2.

No requirements on records or on checks. Where a fixture cannot be expressed because a record field or a check definition is missing, section 15 records the gap for AEF 1300 or AEF 1200. One requirement in this document, C21, adds a member to the verification result; that binds the verifier's output, which AEF 1200 established as this block's subject, and the addition is recorded in section 15 for AEF 1101 section 11's next revision since that section owns the result's minimum form.

12. Conformance of this document's own subjects#

The test AEF 1000 section 9 imposes is that no requirement ships until something has been built that satisfies it and something has been built that fails it. The reference suite, held against sections 6 through 10, supplies both directions, and section 14 carries the detail.

Built and satisfying: the coverage declaration for the reference suite, published with this document in the form C9 requires, with its unexercised requirements listed plainly. The four entries that operate on the published run-0001 artifacts come closest to C5's pinned-pair definition, and the regression fixture from AEF 1900 finding two is the shape C11 obligates. Closest is not satisfying, and section 14 states the shortfall: their records and declarations are pinned, and their options include the wall clock and, for two of them, the live repository as artifact root, so even the best entries in the suite fall short of C5's requirement that the input comprise everything the verification consumes.

Built and failing: most of the rest. Eighteen of the twenty-two entries regenerate their inputs and fail C5 outright. No entry pins a complete qualification set and every entry therefore fails C6 in part. Counting fixtures as C5 defines them, eleven of the twelve checks have no failing fixture against C7 and no fatal check has an isolating fixture against C8, because the one pinned required-to-fail input, the tampered copy, breaks two checks at once. The suite had no coverage declaration and no version until this document forced both, and the verifier performs no self-test against C19 through C21.

One class of requirement has no satisfying instance: C1 through C4 bind a conformance claim, and no conformance claim exists. None can honestly be made, because C1 requires a suite version and the reference suite does not yet satisfy the requirements that make its version meaningful. The reference verifier is therefore not claimed conformant to AEF 1200, by its own author, in the document that defines how such a claim would be made. C5 has no fully satisfying instance either, per the shortfall above. Section 17 records what both cost this document under AEF 1000 section 9's test.

13. Requirement count and classification#

Twenty-one requirements, C1 through C21. By subject: C1 through C4 bind a conformance claim, C5 through C12 bind a fixture suite, C13 through C16 bind its governance, C17 and C18 bind an independent implementation's published results, and C19 through C21 bind a verifier's self-test behavior.

By observer, applying the test AEF 1101 section 16 established:

Checkable by inspecting an artifact: fifteen. C1, C3, and C4 by reading a claim. C5, C6, C7, C8, C9, C10, and C12 by reading a suite and its coverage declaration, with C7 and C8 confirmed by running the named fixtures and observing which checks fail. C15 by reading the challenge record. C17 by reading published results. C19 by inspecting the distribution for its pinned subset. C20 and C21 by reading verification results.

Checkable only across time or against conduct: six, flagged per the requirements-with-no-observer audit every document since AEF 1000 carries. C2's stable path is a property of the future, checkable only by looking again later. C11 binds a process: that a fixture entered the suite before the fix shipped is an ordering between two events the artifacts do not record, the same defect AEF 1300 section 12 flags for R14, and the field-discovery trigger has no observer at all, which section 16 carries. C13 grants a permission and binds nobody. C14 and C16 bind the publisher's conduct; both are visible after the fact through the public record, because a challenge without a disposition and a reproducing false-PASS challenge marked rejected are both readable off the artifacts, but nothing compels the reading. C18 binds two parties to file what only they know occurred, and a disagreement neither files leaves nothing to detect.

Fifteen of twenty-one sit on the artifact side, and the count is honest only with three discounts stated beside it. C12 and C15 carry retention clauses of C2's shape, a property of the future; the classification counts their present form and the same discount applies. C4's word "imply" binds judgment in exactly the way AEF 1200 section 17 records for V38's threshold, and the classification counts C4 by its stated-terms half. C19's carried subset is inspectable and its executed-before-first-result clause is an ordering nothing records, per section 16; C21 is the after-the-fact trace and is itself checkable as to form and not as to substance. Counting all fifteen as fully checkable would overstate what the classification means, which is AEF 1300 section 12's caveat applied here. The six that sit off the artifact side are the governance spine, and there is no artifact-only substitute for an obligation on future conduct.

14. The reference suite against this document#

Produced in the same session as this document, following AEF 1101 section 14 and AEF 1300 section 13: requirements ship with their own reference's gaps attached. The coverage declaration is published at `/aef/examples/run-0001/fixture-coverage.json` in the form C9 requires, and it is the machine-readable form of what follows. Nothing reported here was fixed before publication. The suite is reported as it is, and the fixes come after, under C11's discipline where they respond to misses and under ordinary revision where they respond to gaps.

The inventory. Twenty-two entries in `packages/aef/test.ts`, of which ten are required to fail. Against C5, four entries come closest to being fixtures: the four that read the pinned artifacts published at run-0001, including the AEF 1900 finding two regression fixture. Even these four fall short of C5 read strictly, because the input comprises everything the verification consumes, and their options include the wall clock, and for two of them the live repository as artifact root, none of which is pinned. The record and declaration halves are pinned, which is why they are reported as the pinned entries throughout, with this shortfall attached. The other eighteen regenerate their inputs each time the suite executes, with fresh keys and fresh timestamps, and are generated tests. AEF 1300 section 13 describes all twenty-two as golden fixtures, and under AEF 1001 section 6.12's definition, which this document inherits, that description does not hold for eighteen of them. That is a finding against the suite's description, recorded here and in section 15.

Coverage of the eleven jurisdiction requirements. Asserted, meaning a test would fail if the behavior changed: six. V8 and V9 by the flipped-byte set and the pinned tampered copy. V15 by the out-of-boundary act. V21 by the broken chain. V26 by the capture time after the seal. V36 by the withheld declaration. Asserted partially: two. V13 for one of its five mechanisms, `none`; the pin mechanism is implemented and unexercised, and the X.509, Certificate Transparency, and key transparency branches are neither implemented nor exercised. V41 for one absence, artifacts, with the others unasserted. Occurring on every execution with nothing asserting it: one. V29's qualification is emitted on every generated input and no test would notice if it stopped, so a verifier that silently dropped APPROVAL-ABSENT would still pass the suite. Never arising at all: two. V16 has no fixture in which an element declared present is absent, and V27 has no fixture carrying an approval record in any state. The declaration extends this accounting to all forty-two of AEF 1200's requirements, and the widest gap is the middle category: twelve requirements whose conditions occur every time the suite executes, unasserted, which is drift waiting for nobody to notice.

Required-to-fail against C7. The reference verifier runs twelve checks, and the accounting has two layers, because C5 decides what counts. Counting generated tests, seven checks have at least one entry that fails them: `seal-integrity`, `declaration-binding`, `scope-membership`, `termination`, `artifact-binding`, `ordering`, and `time`; five have none: `key-binding`, `declared-elements`, `approval-form`, `role-disclosure`, and `trust-base-reference`. Counting fixtures as C5 defines them, one check has a failing fixture, `seal-integrity` through the pinned tampered copy, and eleven do not, because every other required-to-fail entry is generated. One check cannot currently fail at all: the implementation assigns `key-binding` no failing state, because the mechanisms under which AEF 1200 section 8.2 makes it fatal are unimplemented, and section 15 finding 1 records those branches as inexpressible for the purposes of section 7.2's carve-out.

Isolation against C8. Eight checks can force FAIL. Counting generated tests, seven have an isolating entry: the flipped `runId` fails the seal and nothing else, and the chain, boundary, termination, time, declaration, and artifact entries each re-seal so that only the target check fails. Counting fixtures under C5, none has an isolating fixture: the one pinned required-to-fail input, the tampered copy, breaks the seal and the chain link at once, which AEF 1300 section 13 reports as defense in depth and C8 counts as a fixture that demonstrates half of what it appears to. `approval-form` has no failing entry of any kind under either counting, so a verifier that never implemented the approval check would pass this suite.

Qualification pinning against C6. No entry pins a complete expected qualification set for any input. Two pin fragments: the regression fixture asserts that ARTIFACTS-UNAVAILABLE appears, and the V7 test asserts that every emitted class is a registry class. The published example's ten qualifications are enumerated in AEF 1300 section 13's prose and asserted nowhere, so the suite would pass if the verifier silently dropped nine of them.

Suite version against C10. The suite had no coverage declaration and therefore no version. The declaration published with this document supplies both: it names sha-256 for itself, and the first checkable suite version is its digest as served. Its binding of pinned inputs is also incomplete in a way C10 makes visible: the two entries that verify against the live repository consume the eight documents the record's own input state binds, which the declaration covers only transitively through `aer.json`, and the trust base statement and options it does not cover at all.

Self-test against C19 through C21. The reference verifier carries no fixtures, runs no self-test, and its results record none. All three requirements are failed.

The first challenge, filed while producing this. Writing the coverage declaration surfaced a divergence, and section 8's mechanism was applied to it rather than described. A record whose act log entries carry no chaining yields FAIL from the reference verifier, and AEF 1200 V22 and section 8.5 say absence of chaining is qualified, not fatal. The complication is that AEF 1300 R17 and R18 have since made chaining REQUIRED, so the input is a non-conformant record and the failure has a second honest reading. The input is pinned at `/aef/examples/run-0001/challenge-0001-input.json`, the reproduction is recorded, and the disposition is the third of C14's outcomes: unresolved, published, referred to AEF 1200 v0.2. One part of the divergence survives both readings and the record says so: the implementation never emits ORDER-UNCHAINED on any input, and V22's emission obligation is unconditional as written, so whatever AEF 1200 v0.2 decides about fatality, the qualification's absence is a defect on at least one reading of every outcome. The challenge record published beside the suite carries all of it, which means the mechanism this document specifies has one entry on the day it ships, filed by the party it is least comfortable for.

A constraint discovered while producing this. The run-0001 record binds eight of the series' documents as input state, so the repository copies of those files are frozen: an edit to any of them is exactly the artifact drift the record exists to reveal, and the suite's pinned-example fixture would report it. One consequence is that AEF 1000 section 9's list of published documents, which predates this document, cannot be updated by the cross-reference errata its freeze permits without a new run re-pinning the inputs. The stale sentence stays until then, and this note is the pointer a reader needs.

15. Findings for earlier documents#

Recorded, not applied, per the constraint that has held since AEF 1200 section 16.

1. AEF 1200 V13's X.509 and Certificate Transparency branches are untestable by any expressible fixture. A fixture is pinned and self-contained per C5. V13 requires revocation checked as of verification time and an inclusion proof checked against a log the reviewer can reach, and both are liveness properties a pinned input cannot carry. As written, the two branches can never enter a coverage declaration as exercised, which means no conformance claim under this document can ever demonstrate them, and without section 7.2's carve-out it would also mean C7, C8, and C19 had no satisfying instance against AEF 1200 v0.1 at all, since those branches are fatal and no fixture can fail them. The carve-out converts that impossibility into a declared gap, at the cost the carve-out states. The repair belongs to AEF 1200 v0.2: state the checks over supplied revocation data and supplied proofs, so that a fixture can staple them, and let liveness be the reviewer's procedure rather than the check's premise. This is the most consequential finding in this document, because it is a requirement that is not wrong and cannot be demonstrated.
2. AEF 1200 section 8's check list still lacks `declaration-binding` and `termination`. AEF 1300 section 14.2 recorded this; the coverage declaration makes it concrete, because two required-to-fail fixtures exist whose target checks have no AEF 1200 requirement id and map to AEF 1300's R13 and R15 instead. A manifest mapping fixtures to requirements needs the requirements to exist. AEF 1200 v0.2.
3. AEF 1300 section 13's description of the fixture set overstates it. Twenty-two golden fixtures is the sentence; four pinned pairs and eighteen generated tests is the inventory. The correction belongs in AEF 1300 v0.2, and the distinction it needs is the one C5 draws.
4. AEF 1101 section 11's result form gains a member. C21 requires a verification result to record the self-test digest and outcome. AEF 1101 section 11 owns the result's minimum contents and should carry the member in its next version, so that the requirement lives where a reader looks for the form.
5. AEF 1100 threat 9.2's disposition is stale as written. Its condition is an independent party inspecting the fixture set. After C9, the required-to-fail property is read off a published manifest, and after C15 an inspection has a public place to land. The condition's cost has changed from expertise plus access to attention, and whether that warrants CONDITIONAL with a restated condition is AEF 1100's call. Candidate for AEF 1100 v0.3.
6. AEF 1200 V22 and AEF 1300 R18 resolve a chainless record differently, and V22 does not say which reading governs. V22 and section 8.5 make absence of chaining a qualification; R17 and R18 make chaining REQUIRED, so a chainless 1300/0.1 record contradicts its own claimed version, which reads as fatal. The reference verifier fails it, challenge-0001 in the coverage declaration records the divergence with a pinned input and a reproduction, and the disposition is unresolved pending AEF 1200 v0.2 stating what a verifier does when the claimed version requires a field V22 treats as optional.

16. Requirements with no observer#

The defect class audited in every document since AEF 1000, applied here.

C11's trigger has no observer, and this is the largest defect in the document. The miss rule fires when a defect is found in the field, and nothing observes finding. An implementer who fixes a defect silently, with no fixture, produces a suite indistinguishable from one whose verifier never had the defect, which is AEF 1100 threat 6.3's shape relocated to the suite's history: a miss never recorded leaves nothing to detect. The rule binds the honest, which is the most a process requirement can do, and it is retained because the alternative is not requiring the one fixture source that outruns the author's imagination.

C11's ordering has no observer either. That the fixture entered the suite before the fix shipped is an ordering between two events, and where both land in one published change, the artifacts record no sequence. Same shape as AEF 1300's R14, recorded there for sealing before execution.

C2's retention is observable only while the path answers. A deleted claim is indistinguishable from a claim that never existed, absent an external index, which the series does not have and AEF 1100 section 16 has recorded as undefined since 11 August.

The challenge mechanism has a record and no inspector. Stated in section 4 and repeated here where the audit lives: C13 through C16 give any inspection a mechanical basis and a public destination, and no party is designated to perform one. A suite with an empty challenge record is a suite nobody has challenged, and nothing in the record distinguishes unexamined from unimpeachable. The claim this document makes for the mechanism is exactly this and no more: AEF 1100 threat 9.2's defect is that inspection had no designated inspector and no record; the record now exists and the inspector still does not. Half the defect is discharged, the half that is an artifact. The half that is a person is relocated, from a party nobody designated to an audience nobody compels, and calling that a discharge would be the overstatement this series exists to avoid.

C19's execution clause has no observer, and C21 does not supply one. That the subset executed before the first result is an ordering between two events, the same shape as C11's ordering and AEF 1300's R14, and nothing in the distribution or the result establishes it. C21's member is the after-the-fact trace and it is written by the program in question, so it is checkable as to form and not as to substance, which is AEF 1300 section 12's category and is counted the same way here. The self-test's value survives this for the honest implementer, whose verifier genuinely stops on drift, and evaporates for the dishonest one, which is where every process requirement in this series lands.

C19's subset can go stale against the full suite. The verifier carries the subset its distributor pinned, and nothing observes whether that subset tracks the suite as C11 grows it. A reviewer can compare the subset digest in a result against the current suite's declaration, which makes staleness checkable; nobody is designated to check.

17. Weaknesses in this document#

Stated as findings against the current text.

The document defines a claim no one can yet make, which fails half of AEF 1000 section 9's shipping test. Something has been built that fails C1 through C4's regime, namely the reference suite's current state, and nothing has been built that satisfies it end to end: no conformant claim exists, because the reference suite does not yet meet sections 7 and 10. C5 is in the same position from the other side: eighteen entries fail it outright and the four closest still fall short on options and artifact roots, so the definition of a fixture ships with no instance that fully satisfies it. The requirements are shipped on the argument that the demonstration machinery and the claim form have to exist before either can be exercised, and a reader is entitled to discount them until the first full instance exists.

The isolation requirement C8 assumes fixture authors hold the sealing key, which is true for authors and false for challengers. An isolating fixture for a non-seal check requires re-sealing the mutated record, which requires a key the record's verifier will accept. A fixture author constructs records under their own key, so this costs nothing. An outside challenger constructing a counterexample does the same, but a challenger who wants to demonstrate a defect against a specific published record cannot re-seal it, and their challenge lands as a generated construction rather than a field record. The asymmetry is structural and unrecorded anywhere else in the document.

The miss rule and C10's versioning pull against each other. Every miss-rule fixture changes the suite version, which stales every conformance claim naming the prior version. That is correct behavior, claims are dated and superseded like everything else, and it hands an implementer a quiet incentive: each recorded defect invalidates their current claim. The rule is retained because the incentive to hide misses exists with or without versioning, and versioning at least makes the hiding a lie about a digest rather than a vagueness. The pressure is real and this document does not relieve it.

Section 9 binds a party that does not exist. C17 and C18 constrain an independent implementation, of which there are zero, so both are unfalsifiable today and will remain so until someone builds one. They are written now so that the second implementation arrives to a stated interface rather than negotiating one, and that is a bet about the future, not a demonstrated requirement.

The self-test position generalizes from one incident. AEF 1900 section 11 already flags that finding two is a single case, and C19 through C21 spend distribution size, startup time, and an availability failure mode on the strength of it. The costs are stated in section 10; whether they are priced correctly is not established by one working-tree defect, and a v0.2 with field experience may resize the subset or drop the refusal semantics.

18. Open questions#

1. Whether qualification completeness admits any observer beyond fixtures. Carried from AEF 1200 open question 2, narrowed by C6: fixtures now pin full qualification sets for the inputs somebody wrote, and the unbounded remainder stands. No document assigned.
2. Whether a conformance claim and a challenge disposition should be sealed records. Both are evidence, both are published as prose or JSON with nothing detecting alteration, and the same question is already open for verification results in AEF 1200 open question 6 and AEF 1300 open question 6. The 1300 block plausibly owns all three.
3. Who receives challenges when the editor seat is vacant. Section 8 routes everything through the editor, and AEF 1000 section 11's dormancy clause makes the seat interruptible. A challenge filed during dormancy has a public record and no party obligated to disposition it, and the fork right is a remedy for the framework rather than for the challenge. AEF 1201 v0.2.
4. Whether the self-test subset should be the whole suite. C19's minimum is one required-to-fail fixture per fatal check, chosen for distribution size, and the choice is a tradeoff this document asserts rather than measures. AEF 1201 v0.2.
5. Whether generated tests deserve a defined standing. C5 excludes them from discharging fixture obligations and the reference suite is mostly made of them, usefully. A category the framework relies on and refuses to define is the shape AEF 1100 section 16 warns about. AEF 1201 v0.2, or AEF 1001's next version if the term belongs to the vocabulary.

19. Terms used here that AEF 1001 does not define#

Recorded rather than coined silently, following AEF 1100 section 16, AEF 1101 section 15, AEF 1200 section 21, and AEF 1300 section 19. Each belongs in AEF 1001's next version.

• Conformance claim. The artifact section 6 defines. AEF 1001 section 8 defines conformant as a predicate and gives the claim no written form.
• Fixture suite. The versioned collection section 7 defines. AEF 1001 section 6.12 defines a single golden fixture and never names the collection.
• Coverage declaration. The manifest C9 requires.
• Suite version. The digest C10 defines.
• Challenge. The submission C13 defines, and its disposition record under C15.
• Isolating fixture. A fixture constructed to fail exactly one fatal check, per C8.
• Self-test. The behavior sections C19 through C21 bind, together with the deployed configuration C19 defines for a library verifier.
• Generated test. Named in C5 only to be excluded, and used throughout section 14; open question 5 records the definitional debt.
• Jurisdiction. The requirements of a claimed document that only fixtures can check, per section 5.
• Miss rule. The obligation C11 imposes, and the regression fixture it produces.
• Retired. Of a fixture: retained at its path, marked with the reason and date, and no longer among the expectations a demonstration is checked against, per C12. The fixture analogue of AEF 1001's superseded.
• Inexpressible. Of a check: one no pinned, self-contained fixture can fail, per section 7.2's carve-out.

Still undefined from AEF 1100 section 16 and used here: external index, on which section 6's deletion caveat and C2's limits rest. This is the fourth document in the series to lean on a term AEF 1001 has never defined, following the precedent AEF 1101 section 15 set for recording the wrong order rather than repeating it silently.

20. License and citation#

Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).

Cite as:

Stellmacher, G. (2026). AEF 1201: Conformance and Self-Test, v0.1. 14 August 2026. https://grantstell.com/aef/1201

Cite the version and date, always.