Attested Execution Framework
The challenge record
Every challenge filed against the reference verifier's fixture suite, with the pinned input that reproduces it and the ruling that resolved it. This page renders challenge-record.json and adds nothing to it; the JSON is the record, per AEF 1201 section 8.
How this record works
Published beside the suite and outside the coverage declaration, per AEF 1201 C15, so that recording a disposition does not move the suite version. Entries are dated, appended, and never altered or removed; a challenge whose disposition changes is resolved by a new appended entry referencing it, which keeps the append-only rule and is recorded as a finding for AEF 1201 v0.2, whose C15 did not state the mechanic.
challenge-0001adopted in part
The claim
A record whose act log entries carry no chaining should yield PASS_WITH_QUALIFICATIONS with ORDER-UNCHAINED, per AEF 1200 V22 and section 8.5, which state that absence of chaining is qualified, and per section 11, which lists only two absence conditions as fatal.
What was observed
FAIL with failedCheck ordering and no ORDER-UNCHAINED qualification, reproduced against aef-reference-verifier 0.1.0 on 2026-08-14, from the pinned input file with no repository present.
The complication
AEF 1300 R17 and R18 make chaining REQUIRED for a record claiming 1300/0.1, so the input is a non-conformant record and the failure can be read as the record contradicting its own claimed version rather than as a V22 violation. AEF 1200 V22 predates AEF 1300 and does not say which reading governs.
Disposition when filed: unresolved, published
The fatality question has two honest readings and the text that would settle them does not exist; referred to AEF 1200 v0.2, which should state what a verifier does when the record's claimed version requires chaining and chaining is absent. One part survives both readings: the implementation never emits ORDER-UNCHAINED on any input, and V22's emission obligation is unconditional as written, so the qualification's absence is a defect independent of how the fatality question resolves; whether a FAIL result must carry qualifications at all is part of what AEF 1200 v0.2 has to settle. Recorded per AEF 1201 C14's third outcome.
Ruling: adopted in part, the editor, ruling in AEF 1200 v0.2
AEF 1300 v0.2 keeps chaining REQUIRED for both forms it defines, so V22 v0.2 scopes ORDER-UNCHAINED to record forms that do not require chaining, of which none currently exist: for a record whose claimed form requires chaining, absence is the record contradicting its own claimed version, and the failure is fatal, which is what the verifier did. The reading-independent half is also ruled: qualifications that arose before a fatal check ride on FAIL results, which the implementation already does, and ORDER-UNCHAINED's emission obligation applies only where the qualification's condition can occur, so the verifier's non-emission for 1300-form records is conformant under V22 v0.2's scoping. The challenger's expected outcome is rejected for current forms and preserved for any future form that makes chaining optional.
challenge-0002adopted
The claim
A record with no approval record should yield PASS_WITH_QUALIFICATIONS with APPROVAL-ABSENT, per AEF 1200 section 8.7, whose failure paragraph states without exception that malformed approval structure is fatal and absence is qualified, and per V29, which makes absence a qualification.
What was observed
FAIL with failedCheck approval-form, reproduced against aef-reference-verifier 0.2.0 on 2026-08-14, because the record's declaration states approvalRequired true.
The complication
AEF 1300 R24's approvalRequired field postdates AEF 1200 v0.1, and V29's own text recorded the missing field as a dependency: a verifier could not previously distinguish a run needing no approval from one missing it. With the field present, treating required-and-absent as qualified would let an operator declare an approval required and ship without one at no cost, while treating it as fatal contradicts section 8.7's letter.
Disposition when filed: unresolved, published
Two honest readings, and the text that settles them belongs to AEF 1200 v0.2: state that absence where the declaration required an approval is fatal, and absence otherwise stays qualified, or reject the split with the reason stated. V29's emission half is not in dispute and is honored on both branches: the verifier emits APPROVAL-ABSENT whether or not the absence is fatal, so unlike challenge-0001 no reading-independent defect rides along. Recorded per AEF 1201 C14's third outcome. AEF 1301 section 13 carries the same referral.
Ruling: adopted, the editor, ruling in AEF 1200 v0.2
V29 v0.2 states the split the challenge asked for: where the declaration states an approval was required and none is present, the absence is fatal, because treating it as qualified would let an operator declare an approval required and ship without one at no cost; where none was required, absence stays qualified. The emission obligation is unconditional on both branches, as the verifier already honors. Section 8.7's failure paragraph is restated to carry the exception its letter lacked.
challenge-0003adopted
The claim
A record whose approval carries AEF 1300 R24's exact three members, approvingSigner, approvedAt, and referent, satisfies AEF 1200 V27's letter, which asks for a signer, a time, and a referent digest, and should not fail the approval form check.
What was observed
FAIL with failedCheck approval-form, reproduced against aef-reference-verifier 0.2.0 on 2026-08-14, because the verifier requires the AEF 1301 A3 members and the record carries only R24's.
The complication
AEF 1301 A3 extends the approval record and the record's aefVersion member can name only 1300/0.1, so a record conformant to the version it declares is fatally non-conformant to a verifier applying AEF 1301, with no version a record could name to distinguish the two forms. The transition is unversioned.
Disposition when filed: unresolved, published
The defect is real and belongs to the documents rather than the verifier: AEF 1300 v0.2 should version the approval structure or admit multiple document claims in aefVersion, and AEF 1200 v0.2 should state which form V27 tests. Until one of them does, a verifier applying AEF 1301 rejects R24-form approvals and this record says so. Recorded per AEF 1201 C14's third outcome; AEF 1301 section 16 carries the finding.
Ruling: adopted, the editor, ruling in AEF 1300 v0.2 and AEF 1200 v0.2 together
AEF 1300 v0.2 versions the record form: aefVersion selects the structural expectations, inside the signed bytes. V27 v0.2 tests the form the record's claimed version defines: R24's three members for a 1300/0.1 record, AEF 1301 A3's closed set for 1300/0.2, and within a v0.1 record, an approval carrying any of A3's distinguishing members claims A3's semantics and is held to them, discriminator included, so stripping the type member dodges nothing. The challenged behavior was wrong: verifier 0.4.0 accepts the challenge's bare three-member R24 approval, reports that only presence was examined, and the fixture that pinned the disputed FAIL is retired with this reason and re-pinned under the ruled expectation. The ruling reaches its challenge and nothing else.
challenge-0004adopted
The claim
Every verification result should carry CAPTURE-TO-SEAL-INTERVAL-UNBOUNDED, per AEF 1200 V25, which states without condition that the verifier MUST compute and report the interval and MUST emit the qualification.
What was observed
The qualification is not emitted for a record whose declaration states a seal latency bound, reproduced against aef-reference-verifier 0.3.0 on 2026-08-14; the interval is still computed and reported.
The complication
AEF 1200 section 8.6's own note says the qualification is unconditional in v0.1 because no document bounds the interval, and becomes conditional on the bound when AEF 1400 exists. AEF 1400 imposed no universal bound; it lets the declaration state the operator's own, which is a bound, and not the kind the note obviously anticipated. Whether an operator-declared bound satisfies the note's antecedent is exactly the kind of reading two honest parties resolve differently.
Disposition when filed: unresolved, published
Referred to AEF 1200 v0.2: restate V25 with its condition explicit, naming whose bound discharges it, or reject the narrowing with the reason stated. Recorded per AEF 1201 C14's third outcome; AEF 1400 sections 8 and 16 carry the same referral.
Ruling: adopted, the editor, ruling in AEF 1200 v0.2
V25 v0.2 names whose bound discharges the emission: the declaration's, per AEF 1400 T8. The interval is always computed and reported; the qualification is emitted where no bound is declared, and a declared bound converts the condition into the seal-latency check's finding, met or exceeded. An operator-declared bound is the only bound the series defines, the declared-scope move is the series' own answer to this shape, and section 8.6's note is restated with the antecedent it should have carried.
Filing a challenge
A challenge is an input the verifier is claimed to handle wrongly, with the outcome the challenger believes correct and the requirement it cites. The mechanism, including what a confirmed miss does to the suite version, is specified in AEF 1201 section 8. Every entry above is append-only: a resolved challenge keeps its original text, and the resolution is a new entry that references it.