# AEF 1200: Verifier Requirements ## What a verifier must check, what it must report, and what it must not claim **AEF 1200. Version 0.1. Published 13 August 2026.** ## 1. Status AEF 1200 v0.1 is an early draft and will change. It is the fifth document in the series and the first in the 1200 block. **This document is normative throughout.** Every preceding document defines, analyzes, or constrains meaning. This one states what a verifier MUST do. Its requirements bind a verifier. They do not bind an operator and they do not bind a record. Requirements on what a record must contain belong to AEF 1300, and none are imposed here. Several checks below need a field no document yet requires a record to carry. Each of those is stated as a finding for AEF 1300 rather than smuggled in as an obligation, and section 15 collects them. AEF 1001 section 8 observes that **conformant** is currently defined and unusable, because nothing states how conformance is demonstrated. This document is half of the answer: it states what a verifier must do. AEF 1201 is the other half: it states how a verifier demonstrates that it does it. Neither half is sufficient alone, and no conformance claim is testable until both exist. 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 supplies the trust base requirements, cited by section. Versions are dated, kept at their own paths, and recorded in CHANGELOG.md beside this document. ## 2. Why this document exists A verifier is the only component of this framework a reviewer actually operates. Everything else is produced by the party whose account is in question. AEF 1001 section 6.11 defines a verifier as a program that checks an aer without recourse to the operator and reports whether the record holds, and until now nothing has said what checking consists of. The gap this creates is worse than an absence. In its absence, every implementer builds the checks they think matter, reports a result in language they choose, and a reviewer receives a green indicator whose meaning is undefined. Two verifiers can examine the same record, run different checks, and both report success, with nothing in either output revealing that they established different things. That is not a specification failing to constrain implementations. It is a specification producing false confidence, which is the failure mode this series exists to prevent. The design problem is narrower than it looks and is stated in section 7. A binary pass or fail is the wrong output shape for this framework, because AEF 1100 concedes twenty-two of twenty-three threats outright or conditionally. A verifier reporting PASS in those conditions is technically correct and practically misleading. AEF 1100 section 13 spent an entire section preventing that misreading in prose, addressed to a human. This document has to do it in an artifact, addressed to whoever reads the output next. ## 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 V1 through V42 and are collected with their classification in section 14. The numbering is stable within a version and is how a conformance claim under AEF 1201 will name what it satisfies. ## 4. What this document owes the series Four assignments arrive here. Their disposition is stated at the top rather than discovered at the bottom. **AEF 1100 section 14** states that a conformant verifier should be independently obtainable with a reproducible build, answering threat 9.3, and that a verification result should record the trust base in force, answering threat 9.4. **Answered** in section 12 and section 6 respectively. **AEF 1101 section 9** defers to this document what a verifier must check once the key-binding mechanism is known. **Answered** in section 8.2, per mechanism. **AEF 1101 section 12** defers how a verifier performs the re-verification comparison, including what counts as a difference and what a deprecated algorithm means for a record sealed before deprecation. This is AEF 1101 open question 4 and it is the hardest thing here. **Answered** in section 9, with the deprecation question answered by making the outcome depend on a mechanism AEF 1400 has not yet specified, which is stated as a limit rather than concealed. **AEF 1101 sections 11 and 12** already state what a verification result MUST contain. Those requirements are **bound, not restated**: V1 makes producing a conformant verification result a condition of verifier conformance. Section 6 adds what 1101 does not cover and says which is which. ## 5. What a verifier is not asked to do Stated first, because several of the requirements below are only intelligible against these boundaries. A verifier does not establish that the work was done as described. AEF 1100 section 12 states what an aer is worth: a strong constraint on revision and a weak constraint on construction. A verifier does not determine whether a declared scope was adequate to the reviewer's question. AEF 1100 threat 7.1 is CONCEDED deliberately, and AEF 1001 section 6.1 states that a reviewer MAY find a boundary inadequate without the framework making that judgment for them. A verifier does not certify. AEF 1001 section 6.11 is explicit that a verifier is not an authority, that it reports rather than certifies, and that its output is evidence a reviewer weighs rather than a conclusion a reviewer must accept. Section 13 turns that into requirements on output language. A verifier does not decide whether a difference at re-verification invalidates an earlier conclusion. AEF 1101 section 12 assigns that judgment to the reviewer and assigns surfacing the difference to the framework. A verifier does not establish that its own logic is correct. That is AEF 1100 threat 9.1 and it belongs to AEF 1201. Section 12 states why provenance does not close it. ## 6. The verification result Requirements in this section bind the output of a verifier. **V1.** A conformant verifier MUST produce a conformant verification result as defined by AEF 1101 section 11, for every verification it performs, including verifications that fail. AEF 1101 section 11 already requires the record identity bound by hash, the verification time and its time source, the trust base statement in force, the verifier identity and version, and the outcome with the failing check named on rejection. Those are not restated here. V1 makes them a condition of verifier conformance rather than a property of a well-behaved result, which is the binding AEF 1101 section 11 could not perform on itself because it binds an artifact and not a program. The requirements below extend that list. Each concerns something AEF 1101 section 11 does not cover. **V2.** The result MUST carry exactly one outcome, drawn from the vocabulary in section 7.1. **V3.** Where the outcome is PASS WITH QUALIFICATIONS, the result MUST carry at least one qualification. Each qualification MUST state what was not established and the condition that prevented establishing it. **V4.** Where the outcome is FAIL or INCONCLUSIVE, the result MUST name the check. AEF 1101 section 11 requires this for rejection; V4 extends it to INCONCLUSIVE, which AEF 1101 did not contemplate because the outcome did not exist. **V5.** The result MUST carry a negative claims block, in the form section 7.3 requires. **V6.** The result MUST NOT carry the outcome PASS where any qualification arose during the verification. **V7.** Every qualification MUST carry a class drawn from the registry in section 7.4. Where no class in the registry applies, the qualification MUST carry the class OTHER together with a statement of what it names. ## 7. Outcomes, qualifications, and the honest floor This section is the design decision of the document. ### 7.1 The outcome vocabulary Four values, and the fourth is forced by the analysis rather than added for symmetry. **FAIL.** A check this document treats as fatal did not hold. The record is not what it claims to be. **INCONCLUSIVE.** The verifier could not run a check this document treats as fatal, because a required input was absent, a dependency was unreachable, or an algorithm was unsupported. The record may be sound and may not be, and the verifier cannot tell. **PASS WITH QUALIFICATIONS.** Every fatal check held. One or more checks established less than that check is capable of establishing, and each such condition is named. **PASS.** Every fatal check held and no qualification arose. INCONCLUSIVE exists because collapsing it into either neighbour is a lie in a specific direction. AEF 1100 threat 6.6 is CONDITIONAL on the reviewer having an independent source for the artifacts. A verifier handed a record and no artifacts cannot compare hashes. Reporting PASS asserts a binding it did not check. Reporting FAIL asserts a defect it did not find. The distinction between a bad record and an unanswerable question is exactly the distinction this framework is about, and a three-value vocabulary erases it. ### 7.2 Whether PASS is reachable It is reachable in principle and is not reachable today, and saying so is more useful than implying otherwise. An unqualified PASS requires, among other things, that identity was established rather than continuity of use, that recorded times came from a source outside the operator, that artifacts were supplied by someone other than the operator, and that act log entries were chained. Three of those depend on record fields or mechanisms no document has specified: chaining is deferred to AEF 1300 by AEF 1100 threat 6.5, an external time source is deferred to AEF 1400 by threat 10.3, and the role disclosure field is deferred to AEF 1300 by section 15 below. So today, a conformant verifier examining a conformant record produces PASS WITH QUALIFICATIONS at best. That is the correct output and not a defect in the implementation. An implementation emitting PASS today is either checking something no record can currently carry or has defined its qualifications away, and a reviewer receiving an unqualified PASS in 2026 SHOULD treat it as a reason to inspect the verifier rather than as a stronger result. Section 17 records the pressure this creates, because a requirement whose satisfying state is unreachable invites implementers to redefine the states. ### 7.3 Qualifications, standing limitations, and the negative claims block Two different things get confused here and separating them is what keeps the vocabulary from collapsing. A **qualification** names a condition under which a check established less than that check is capable of establishing. Qualifications vary between records. A record whose artifacts the reviewer holds independently carries no artifact qualification; a record whose artifacts came from the operator does. A **standing limitation** names something no verifier can ever establish, for any record, under any conditions. These do not vary. They are the CONCEDED entries in AEF 1100 restated as non-claims. If standing limitations were emitted as qualifications, every result would carry the same dozen entries, PASS would be unreachable by construction rather than by circumstance, and the qualification list would stop carrying information about the record in front of you. If they were omitted entirely, the output would read stronger than AEF 1100 section 13 permits. So they are carried separately. **The negative claims block** is the list of standing limitations, and V5 requires it in every result whose outcome is PASS or PASS WITH QUALIFICATIONS. At minimum it MUST state that the result is not evidence that the work was done as described, that nothing outside the record occurred, that the declared scope was drawn honestly or before the outcome was known, that the approving signer saw what the approval record says they saw, that this is the record for the run the reviewer asked about, or that other records of the same work do not exist. Each traces to a CONCEDED disposition in AEF 1100: suppression at the source (6.3), adversarial scope declaration (7.1), scope amendment after execution (7.3), referent mismatch (8.1), substitution (6.7), and run splitting (7.2). The list mirrors the six sentences AEF 1100 section 13 states a reviewer cannot write. ### 7.4 Whether qualifications are enumerable in advance **Position: the classes are closed and the instances are open.** Each qualification MUST carry a class from the registry below, and MUST carry free text stating the particular condition. The argument for a closed set is that an open set is not comparable. Free-text qualifications mean two verifiers describe the same weakness in different words, a reviewer cannot tell whether two records carry the same reservation, and nothing can be aggregated across a population of records. A vocabulary whose terms are chosen per-instance is not a vocabulary. The argument against a closed set is that closing it asserts the failure surface is fully known, which AEF 1100 section 18 shows it is not. New dependency types will appear, AEF 1101 section 5.2 cuts the trust closure at a declared point rather than at a natural one, and later documents will find conditions this one did not anticipate. The resolution is the mechanism the series already uses for vocabulary it lacks. AEF 1100 section 16 and AEF 1101 section 15 record terms they needed that AEF 1001 did not define, rather than coining them silently. The same discipline applies here: an implementation encountering a condition no class covers MUST use OTHER and MUST state what it names, per V7. An OTHER occurrence is a finding against this document and is the input to the next version's registry. The open-endedness becomes observable rather than silent, which is the property that matters. The registry for v0.1: - **IDENTITY-NOT-ESTABLISHED.** The key binding established continuity of use rather than identity, per AEF 1101 section 9. - **NO-EQUIVOCATION-DETECTION.** The key binding mechanism supplies an assertion with no way to detect that the asserting party bound the same identity differently for another audience. - **TIME-OPERATOR-ASSERTED.** A recorded time came from a source the operator controls, per AEF 1100 threat 10.3. - **ARTIFACTS-UNAVAILABLE.** Input state or output artifacts were not supplied, so the binding was not checked. - **ARTIFACTS-OPERATOR-SUPPLIED.** Artifacts were supplied by the operator, so hash agreement does not exclude replay, per AEF 1100 threat 6.6. - **ORDER-UNCHAINED.** Act log entries carry no chaining, so pre-seal order is the operator's assertion, per AEF 1100 threat 6.5. - **ROLES-UNDISCLOSED.** The record does not disclose which parties held which roles, so independence is not established, per AEF 1001 section 7.1. - **APPROVAL-ABSENT.** No approval record is present, and whether one was required is not determinable by a verifier. - **KEY-HISTORY-DEPENDENT-ON-OPERATOR.** The key history is not independent in the sense AEF 1101 section 10 requires. - **ALGORITHM-DEPRECATED.** An algorithm the record relies on has been deprecated since sealing, per section 9.4. - **TRUST-BASE-CHANGED.** A difference was found at re-verification, per section 9. - **CAPTURE-TO-SEAL-INTERVAL-UNBOUNDED.** The interval is reported and nothing constrains it, per AEF 1100 threat 10.4. - **OTHER.** No class applies. The qualification states what it names. ### 7.5 What the output is for The requirements in this section exist to produce one property, and it is worth stating as a design target rather than leaving it implicit. **A reviewer holding a conformant verification result should be able to write AEF 1100 section 13's honest floor sentence without adding anything, and should not be able to write a stronger sentence by accident.** The floor sentence is: this record was sealed at a stated time under a key bound to a named party, has not changed since sealing, and is internally consistent with a scope its operator declared for the run. Each clause maps to a check and to a field the result carries. "Has not changed since sealing" comes from section 8.1. "Under a key bound to a named party" comes from section 8.2, qualified by IDENTITY-NOT-ESTABLISHED where the binding is continuity only, which is what stops the reviewer writing "under a key belonging to". "At a stated time" comes from section 8.6, qualified by TIME-OPERATOR-ASSERTED, which is what stops the reviewer writing "at that time". "Internally consistent with a scope its operator declared" comes from section 8.3, and the negative claims block is what stops the reviewer writing "complete". The second half of the target is the harder one and is why section 13 exists. Output that permits the floor sentence but also permits a stronger one has failed, and the way stronger sentences get written is by borrowing the verifier's own words. ## 8. The checks Checks are organized by what the verifier establishes rather than by which artifact they touch, so that the structure maps to what a reviewer wants to conclude. Each states what it establishes, what it operates on, what it depends on by party per AEF 1101 section 5.1, what a failure means, and whether failure is fatal or reported as a qualification. ### 8.1 That the record has not changed since sealing **Establishes.** That the sealed bytes are the bytes that were sealed. **Operates on.** The seal and the sealed content. **Depends on.** The signature scheme's integrity, controlled by the cryptographic library maintainers and the standard's authors; if misplaced, forgery is undetectable and the framework collapses entirely. The verifier's own correctness, controlled by the implementer; if misplaced, alteration passes, which is AEF 1100 threat 9.1. **V8.** The verifier MUST recompute the seal over the sealed content and MUST report a difference of a single byte anywhere in that content as a failure. **V9.** Failure of this check is fatal. The outcome MUST be FAIL. This is the one threat AEF 1100 section 15 counts as defended by what exists today, and it is the framework's core. AEF 1000 principle 4 is the reason V8 is stated in terms of what must fail rather than what must pass: a verifier that has never rejected a tampered record verifies nothing. Demonstrating that V8 holds is AEF 1201's subject. Note the boundary. This check establishes nothing about the record before seal time. Every concession in AEF 1100 section 12's first paragraph lives in that window. ### 8.2 That the seal is attributable **Establishes.** Either that the same key sealed this record and some other thing, which is continuity of use, or that the key belongs to a named party, which is identity. These are different conclusions and AEF 1101 section 9 is explicit that mechanisms supplying only the first are the common case. **Operates on.** The key binding, and whatever external assertion the binding mechanism references. **Depends on.** The asserting party, whether a certificate authority, a log operator, or the reviewer's own pinning; if misplaced, the record verifies against a key belonging to someone else. Where a log is used, the monitoring party, per AEF 1101 section 10; if nobody monitors, append-only is a property nobody checked. **V10.** The verifier MUST report which of identity or continuity of use was achieved, using those terms, and MUST record the key binding mechanism it relied on. **V11.** The verifier MUST NOT report identity where only continuity of use was achieved. A result reporting identity while recording a mechanism that supplies no external assertion is non-conformant on its face. **V12.** The verifier MUST obtain trust anchors, meaning roots, pins, and log public keys, from a source the reviewer designates. It MUST NOT use a trust anchor carried in the aer or supplied by the operator. V12 is the requirement in this document most likely to be violated by convenience, and it follows directly from AEF 1000 principle 2. An anchor taken from the record makes the check circular: the operator supplies both the claim and the standard against which the claim is measured. **V13.** Per mechanism, once the mechanism is known per AEF 1101 section 9, the verifier MUST perform the following. - **Bare signature with no external assertion.** Report continuity of use. Report no identity claim. - **X.509 public key infrastructure.** Verify the chain to a root the reviewer designated, and check revocation as of verification time. Report that no equivocation detection is present. - **Certificate Transparency, in the sense of RFC 6962.** Perform the above, and additionally check the inclusion proof against a log the reviewer can reach. Report whether a monitoring party is named in the trust base statement. - **Key transparency, in the CONIKS line of work.** Check inclusion and consistency proofs. - **Out-of-band pinning.** Compare the sealing key against the pin the reviewer supplied. Report that the pin's provenance is outside the verifier's knowledge. **V14.** Where the mechanism supplies an assertion without a detection mechanism for the asserter's equivocation, the verifier MUST emit NO-EQUIVOCATION-DETECTION. **Failure.** A chain that does not verify, a revoked certificate, or a failed inclusion proof is fatal. Absence of any binding mechanism is not fatal; it yields continuity of use and IDENTITY-NOT-ESTABLISHED. ### 8.3 That the record accounts for what it said it would **Establishes.** Internal consistency between the record and its declared scope. Nothing more. **Operates on.** The declared scope, the act log, and the record's internal references. **Depends on.** Nothing external. This check is entirely internal, which is why it is the check most likely to be over-read. **V15.** The verifier MUST test each act log entry for membership in the declared boundary and MUST report any entry falling outside it. **V16.** Where the declaration states that the record will contain an element, and that element is absent, the verifier MUST report a finding. It MUST NOT treat the absence as a pass. AEF 1000 principle 3 states that within a boundary, a step that produced no evidence is unsupported rather than presumed fine. **V17.** The result MUST carry, in the negative claims block, the statement that a pass on this check is not evidence that the declaration was honestly drawn. The reason V17 is a standing limitation rather than a qualification is that no verifier will ever establish declaration honesty for any record. AEF 1001 defines **complete** as containing everything the declared scope says the record contains, and states that completeness MUST NOT be read as a claim that nothing was omitted from the run. AEF 1100 threat 7.1 is CONCEDED deliberately and threat 6.3 is the framework's largest single concession. A verifier reporting this check as "complete" without the accompanying non-claim has produced the exact misreading AEF 1001 section 8 was written to prevent. **Failure.** An entry outside the declared boundary is fatal, because the record contradicts its own declaration. A missing declared element is a finding reported in the result rather than a fatal error, because AEF 1300 has not yet specified how a record marks an element unsupported, and failing every record until it does would be wrong. ### 8.4 That the record refers to this work **Establishes.** That input state and output artifacts held by the reviewer hash to the values the record binds. This is the defense against replay in AEF 1100 threat 6.6. **Operates on.** Input state references, output artifact hashes, and whatever artifacts the verifier is given. **Depends on.** Whoever supplied the artifacts. AEF 1100 threat 6.6 states the dependency precisely: if the only source is the operator, it supplies artifacts matching the record it chose to supply, and replay succeeds completely. **V18.** The verifier MUST recompute hashes over every artifact supplied to it, MUST compare them against the record's bindings, and MUST record the provenance of the artifacts it compared against as one of reviewer-supplied, operator-supplied, or unknown. **V19.** Where an artifact is not supplied, the verifier MUST report that binding as unchecked and MUST NOT report the record as bound to it. It MUST emit ARTIFACTS-UNAVAILABLE. **V20.** Where artifact provenance is operator-supplied or unknown, the verifier MUST emit ARTIFACTS-OPERATOR-SUPPLIED, because hash agreement under that provenance does not exclude replay. V18's provenance field is the part that does the work. A hash comparison reported without provenance reads as a strong result and is a strong result only under a condition the output did not state. **Failure.** A mismatch between a supplied artifact and its recorded hash is fatal. Absence of artifacts is not fatal and is qualified. ### 8.5 That recorded order is what was sealed **Establishes.** After seal time, that order has not been altered, which follows from 8.1. Before seal time, nothing, unless entries are chained. **Operates on.** Act log entry sequence and any chaining fields present. **Depends on.** The same parties as 8.1 for the post-seal property. For the pre-seal property, nothing external, since chaining is internal to the record. **V21.** Where act log entries carry chaining, the verifier MUST verify each link and MUST report a broken link as a failure. **V22.** Where act log entries carry no chaining, the verifier MUST emit ORDER-UNCHAINED, stating that pre-seal order is the operator's assertion. AEF 1100 threat 6.5 leaves chaining to AEF 1300 and this document does not require records to carry it. V21 states what a verifier does if it is there; V22 states what it says if it is not. Section 15 records the field as a dependency. **Failure.** A broken chain is fatal. Absence of chaining is qualified. ### 8.6 That recorded times mean what they appear to **Establishes.** That times are present, well formed, and internally ordered, and that their sources are identified. Not that they are true. **Operates on.** Capture times, seal time, approval time, and their recorded sources. AEF 1001 section 9 defines these as different moments and states that conflating any two is a class of error rather than an instance. **Depends on.** The time source, controlled by whoever administers it; if it is the operator's, the record establishes ordering relative to itself and nothing about when anything happened, per AEF 1100 threat 10.3. **V23.** The verifier MUST report the identified time source for each recorded time. **V24.** Where a time source is the operator's, or is not identified, the verifier MUST emit TIME-OPERATOR-ASSERTED naming which times are affected. **V25.** The verifier MUST compute and report the interval between the earliest capture time and the seal time, and MUST emit CAPTURE-TO-SEAL-INTERVAL-UNBOUNDED. **V26.** The verifier MUST report a capture time later than the seal time as a failure. V25 is what AEF 1100 threat 10.4 makes available. The window is visible in the record and nothing constrains it, so the verifier's contribution is to compute it rather than leave a reviewer to notice. The qualification is unconditional in v0.1 because no document bounds the interval; when AEF 1400 does, this becomes conditional on the bound. **Failure.** A capture time after seal time is fatal, because it describes an impossible record. Everything else here is reported or qualified. ### 8.7 That an approval exists in the required form **Establishes.** Presence and form. Nothing about the referent. **Operates on.** The approval record: the approving signer's identity, the approval time, and the referent identifier. **Depends on.** Nothing external for the form check. **V27.** Where an approval record is present, the verifier MUST check that it identifies an approving signer, carries an approval time, and carries a referent identifier bound by cryptographic hash, and MUST report a missing element as a failure of form. **V28.** The result MUST carry, in the negative claims block, the statement that the verification is not evidence that the approving signer was shown what the approval record says they were shown. **V29.** Where no approval record is present, the verifier MUST emit APPROVAL-ABSENT and MUST NOT infer that approval was unnecessary. Whether an approval was required is not determinable by a verifier and is recorded in section 15 as a dependency on AEF 1300. AEF 1100 threat 8.1 is CONCEDED and AEF 1001 open question 3 records it as unresolved, so V28 is a standing limitation rather than a qualification. AEF 1000 principle 6 holds that a signature requires a defined referent, and AEF 1100 threat 8.1 states the limit exactly: the referent is defined in the record rather than established by it. A verifier that reports an approval check as passing, without that non-claim beside it, has implied the opposite of what the framework concedes. **Failure.** Malformed approval structure is fatal. Absence is qualified. ### 8.8 That role combinations affecting independence are visible **Establishes.** Which parties held which roles, where the record says so. **Operates on.** Role disclosure, in the sense AEF 1001 section 7.1 requires. **Depends on.** Nothing external. **V30.** Where role disclosure is present, the verifier MUST report the combination, and MUST report that the approval is a self-assertion where the operator and the approving signer are the same party. **V31.** Where role disclosure is absent, the verifier MUST emit ROLES-UNDISCLOSED and MUST NOT treat the absence as evidence that the roles were separately held. AEF 1001 section 7.1 makes disclosure of the operator and approving signer combination a MUST on the record, and AEF 1100 section 17 records that nothing checks whether the disclosure was made. V31 is that check, and it is the reason absence is qualified rather than fatal: the obligation is on the record, AEF 1300 has not specified the field, and a verifier that failed every record today would be enforcing a requirement no record can currently satisfy. Once AEF 1300 specifies it, absence becomes fatal, and section 15 records that. **Failure.** Absence is qualified rather than fatal, for the reason above. ## 9. Re-verification Requirements in this section bind the output of a verifier. This section answers AEF 1101 open question 4. ### 9.1 What re-verification is AEF 1001 section 9 defines re-verification as a verification performed later than the first, particularly after key rotation or a change in the trust base, and states that verification time is evidence of nothing later: a record that verified in 2027 has not thereby verified in 2031. AEF 1101 section 12 draws the distinction that makes this hard. A record that no longer verifies has failed cryptographically, which is loud and needs no help. A record whose verification is no longer meaningful still checks, and the verifier reports success while the standing of a party the check rested on has changed. The second case is dangerous precisely because the failure is silent and the report is green. **V32.** A conformant verifier performing a re-verification MUST produce the comparison AEF 1101 section 12 requires of a re-verification result, and MUST classify every reported difference by the types in section 9.2. AEF 1101 states the obligation and assigns the method here; the keying rule and the type list are what this document adds. **V33.** The verifier MUST NOT report whether a difference invalidates the earlier conclusion. AEF 1101 section 12 assigns that judgment to the reviewer. A re-verification that carries no comparison is a second verification with no memory, which is not what AEF 1001 means by the term. Where no earlier verification result is available, the verification is a first verification and MUST be reported as such rather than as a re-verification with nothing to compare. ### 9.2 What counts as a difference The comparison is over dependency records in the form AEF 1101 section 6 requires, keyed by controlling party together with the assertion relied on. Keying by party alone is wrong, because AEF 1101 section 5.1 states that one party may be trusted for several things with materially different failure modes. Keying by textual identity is also wrong, because a statement rewritten with no change in substance would report differences that are not differences. Six difference types, and a verifier MUST report each by type. A seventh reported condition follows them and is not a difference in the base, for the reason stated there. **Withdrawn.** A dependency present at the earlier verification is absent now, or the party no longer makes the assertion. **Added.** A dependency present now was absent earlier. The base grew, and the earlier conclusion rested on less than the current check does, which is worth surfacing even though it sounds benign. **Controlling party changed.** The same assertion is now controlled by a different party. A certificate authority acquired, a log operator transferred, a hosting party replaced. **Standing changed.** The party still asserts, and its standing has changed. An authority distrusted, a key later reported compromised, a log shut down or found to have equivocated. **Externality changed.** The three tests in AEF 1101 section 7 now answer differently for a dependency. A vendor relationship that ended converts test two, and a reviewer who lost independent reach converts test three. **Mechanism deprecated.** An algorithm or construction the record relies on has been deprecated or broken since the earlier verification. Section 9.4 states what this means. **Cut-off moved.** The point at which AEF 1101 section 5.2's transitive closure was declared cut differs between the two statements. This is not a difference in the base itself and MUST be reported separately, because a base that appears to have shrunk may only have been cut higher. **V34.** Where any difference is found, the verifier MUST emit TRUST-BASE-CHANGED, and the outcome MUST NOT be PASS. ### 9.3 What the comparison cannot do The comparison operates on two trust base statements, and AEF 1101 section 16 records that a statement's completeness is self-certified. A dependency that was never disclosed at the earlier verification cannot appear as Withdrawn or Standing changed now, because there is nothing to compare against. The comparison detects changes in what was declared, not changes in what was true. This is the same shape as AEF 1100 threat 6.3 one level up: an undeclared dependency leaves nothing to detect. ### 9.4 A deprecated algorithm and a record sealed before deprecation This is the hardest question in the document, and the answer turns on separating two properties that a single word conflates. Deprecation is a statement about future use. That a hash function should not be used for new seals from 2031 is not a statement that a 2027 seal was forged. But it is a statement that someone holding the record can now produce an alternative that verifies equally well, and the record cannot say whether such an alternative was produced before or after the break. So the question is not whether the algorithm is sound now. It is whether the reviewer can place the record's existence, unchanged, before the point at which forging it became practical. That is a question about seal time, and AEF 1100 threat 10.3 makes seal time an operator assertion absent an external source. **V35.** Where an algorithm the record relies on has been deprecated since sealing, the verifier MUST emit ALGORITHM-DEPRECATED, and MUST report all of the following: the algorithm, the deprecation as the verifier knows it, whether the record's seal time is anchored to a source outside the operator, the anchoring party where one exists, and whether that anchor precedes the deprecation. Two cases follow, and the verifier reports which one applies rather than deciding what it means. **Where seal time is anchored externally and the anchor precedes the deprecation**, the reviewer has grounds to believe the record existed before forging it was practical. The qualification is real and bounded, and the reviewer can weigh it. **Where seal time is not anchored externally**, the record cannot be placed before the deprecation at all, because the operator could have produced it at any point. The qualification is corrosive rather than bounded, and the reviewer should treat the seal as establishing integrity against parties other than the operator and nothing against the operator. The honest limit, stated rather than concealed: the first case is currently unavailable. AEF 1400 has not specified what a time source outside the operator's control requires, so no conformant record can today demonstrate the anchor V35 asks about, and every deprecated-algorithm qualification will land in the second case. V35 is written now because the reporting obligation should not wait for the mechanism, and because a verifier that reports the absence of an anchor is more useful than one that reports nothing. **Where the verifier cannot compute a check because the algorithm is unsupported**, the outcome is INCONCLUSIVE per V36 below, not FAIL. The verifier did not find a defect; it could not look. **V36.** Where the verifier cannot execute a check this document treats as fatal, the outcome MUST be INCONCLUSIVE and MUST NOT be FAIL or PASS. ## 10. Trust base handling **V37.** The verifier MUST record the trust base statement it operated under as an assertion by whoever published it. It MUST NOT report any claim within a trust base statement as a verified fact. AEF 1101 section 7 requires a statement to record answers to three externality tests, and AEF 1101 section 16 records that those answers are given by the operator about its own dependencies with no party designated to check them. A verifier can check that the fields are present and that controlling party fields are non-empty. It cannot check that a named party is in fact external, that the closure was cut defensibly, or that the reduction statement is candid. Reporting form as substance would make the verifier the observer AEF 1101 section 16 says does not exist, which it is not. ## 11. Requirements the verifier places on nothing Stated so that the discipline in section 1 is visible rather than asserted. Several checks above are conditional on a field being present, and none of them require a record to carry that field. Where the field is absent, the verifier qualifies rather than fails, with two exceptions that are fatal because the record contradicts itself rather than because it omits something: an act log entry outside the declared boundary, and a capture time after the seal time. This is deliberate and it has a cost. A framework whose verifier qualifies everything and fails almost nothing produces results that are honest and weak, which is the correct state given AEF 1100's concessions and is uncomfortable to ship. The alternative, failing records for missing fields no document requires, would make this document impose record requirements by the back door, which section 1 forbids. ## 12. Verifier provenance AEF 1100 threat 9.3 is CONCEDED and is described there as the most likely real-world failure in the entire threat model, because it is the convenient path: the operator has a verifier, the reviewer does not, and running the supplied one is easier than building one. **V38.** A conformant verifier MUST be obtainable by a reviewer from a source that is not the operator and does not require the operator's cooperation. This is AEF 1101 section 7 test three applied to the verifier itself. **V39.** A conformant verifier MUST publish its source, and a build procedure by which a third party can produce an artifact bit-identical to the published one. The verifier's published identity and version are already required in every verification result by AEF 1101 section 11, and V1 binds that. This document does not restate it. **The limit, stated plainly.** Reproducibility establishes that the binary a reviewer runs corresponds to the source a reviewer can read. It establishes nothing about whether that source is correct. A verifier can be perfectly reproducible and wrong in exactly the way AEF 1100 threat 9.1 describes, which is a defect that passes records it ought to fail. Provenance and correctness are different properties, and AEF 1201 owns the second. Any reading in which V38 and V39 close threat 9.1 is a misreading, and it is a tempting one because reproducible builds are widely treated as a sufficiency claim in adjacent fields. Section 16 records that V38 and V39 change threat 9.3's character enough to warrant re-examining its disposition, which is a finding for AEF 1100 rather than a change made here. ## 13. What a verifier must not do Short, and it carries more weight than its length suggests, because every requirement here prevents an output that would be true and misleading. **V40.** A verifier MUST NOT report a conclusion it did not establish. This is the general form of V11, V19, V29, and V31, and it is the only requirement in this document with no observer, which section 16 records. **V41.** A verifier MUST NOT treat the absence of a field as a pass. Absence is a qualification or a finding, per AEF 1000 principle 3. **V42.** A verifier's output MUST NOT describe its result as a certification, and MUST NOT use "certified", "guaranteed", "proven", or "assured" of a record or of any check. AEF 1001 section 6.11 states that a verifier is not an authority, that it reports rather than certifies, and that its output is evidence a reviewer weighs rather than a conclusion a reviewer must accept. V42 makes that a property of the artifact rather than a disposition of the implementer, because the output outlives the implementer's understanding of it. AEF 1001 section 8 separately warns that **attested** in this framework does not mean an independent practitioner examined the subject matter and expressed an opinion, and verifier output is where that confusion will originate if it originates anywhere. ## 14. Requirement count and classification Forty-two requirements, V1 through V42. The classification below is the one AEF 1101 section 16 makes the relevant test: a requirement on an artifact has an observer, and a requirement on a judgment does not. **Checkable by inspecting the verifier: three.** V12 on the source of trust anchors, V38 on independent obtainability, V39 on reproducible build. **Checkable by inspecting its output: twenty-seven.** V1 through V7 on result form, outcome, qualifications, and the negative claims block. V10, V11, and V14 on key binding reporting. V17 on the internal consistency non-claim. V18, V19, and V20 on artifact provenance and unchecked bindings. V22 on unchained order. V23, V24, and V25 on time sources and the capture-to-seal interval. V28 on the approval referent non-claim. V30 and V31 on role disclosure. V32, V33, and V34 on the re-verification comparison. V35 on deprecation reporting. V37 on trust base handling. V42 on output language. **Checkable only by running the verifier against fixtures, which is AEF 1201's territory: eleven.** V8 and V9 on seal integrity and its fatality. V13 on per-mechanism key checks. V15 and V16 on scope membership and missing declared elements. V21 on chain verification. V26 on impossible capture times. V27 on approval form. V29 on approval absence. V36 on INCONCLUSIVE. V41 on absence never being a pass. **Not checkable: one.** V40, that a verifier MUST NOT report a conclusion it did not establish. It is the document's only requirement on judgment, it is flagged here as section 1's constraint requires, and it is retained because a specification that omits the general principle and lists only its instances leaves the next instance unaddressed. Thirty of forty-two are checkable without running anything, which is the proportion this document was aiming for and is the direct application of AEF 1101 section 16's finding. ## 15. Record fields these checks require that no document requires The dependencies AEF 1300 inherits. This list is the spine of that document. 1. **A declared scope whose boundary permits membership to be decided for a given act.** AEF 1001 section 6.2 requires it be expressed so a reader can determine membership. V15 needs a verifier to determine it, which is stronger. 2. **An enumeration, within the declaration, of the elements the record will contain.** Without it, V16 has nothing to test absence against, and AEF 1000 principle 3's finding cannot be made. 3. **A way for a record to mark a declared element as unsupported.** Otherwise absence and unsupported are indistinguishable, and V16 cannot separate an omission from an honest gap. 4. **Act log entry chaining.** V21. Already forward-assigned by AEF 1100 threat 6.5. 5. **A role disclosure field** covering operator, approving signer, and implementer combinations. V30 and V31. AEF 1001 section 7.1 states the obligation and no document specifies the field. 6. **A time source identifier attached to each recorded time.** V23 and V24. 7. **A key binding mechanism identifier.** V10 and V13, so that a verifier knows which checks apply and a reviewer can see from the output whether an identity claim was warranted. 8. **An approval referent bound by cryptographic hash.** V27. 9. **An indication of whether an approval was required for the run.** V29, which currently cannot distinguish a run needing no approval from one missing it. 10. **Algorithm identifiers for the seal and for content hashes.** V35, which cannot detect deprecation of an algorithm the record does not name. 11. **A seal time anchor and the anchoring party.** V35's first case. Depends on AEF 1400 defining what an anchor is. 12. **Input state reference form where content is not retained.** V18, and already AEF 1001 open question 2. 13. **A trust base statement carried by or referenced from the aer.** V37. AEF 1101 section 6 defines the artifact and no document says who publishes it or where it attaches. Item 3 was surfaced by writing this document and is not on any existing list. ## 16. Findings for earlier documents Per section 1's constraint, an analysis suggesting a threat is better defended than AEF 1100 concluded is a finding requiring revision there, not a quiet correction here. Two arise. **AEF 1100 threat 9.3, verifier substitution, currently CONCEDED.** V38 and V39 do not prevent a reviewer running the operator's verifier. They do make it visible, because AEF 1101 section 11 requires the verifier identity and version in every result, and a reviewer can compare that identity against an independently obtainable one. The threat's character changes from undetectable to detectable by a reviewer who checks. That is the shape of a CONDITIONAL disposition rather than a CONCEDED one, with the condition being that the reviewer performs the comparison. Recorded as a candidate revision for AEF 1100 v0.3. Not applied here. **AEF 1100 threat 9.4, trust base substitution, currently CONCEDED.** Its stated basis is that a verification result does not record the trust base in force. AEF 1101 section 11 now requires it and V1 binds it. The disposition is stale as written. Whether it becomes CONDITIONAL or IN SCOPE depends on whether the recording requirement counts as a mechanism this series has specified, which it now is. Recorded as a candidate revision for AEF 1100 v0.3. Not applied here. Neither finding weakens a concession. Both would strengthen one, which is why both are deferred to the document that owns them. ## 17. Requirements with no observer The defect class audited in AEF 1000, AEF 1100 section 17, and AEF 1101 section 16, applied to this document. **V40 has no observer at all**, and section 14 records it as the one uncheckable requirement here. **Qualification completeness has no observer, and this is the largest defect in the document.** Nothing establishes that a verifier emitted every qualification that arose. A verifier that silently omits one produces output indistinguishable from a verifier examining a record where the condition did not hold. This is AEF 1100 threat 6.3 relocated to the verifier: an omitted qualification leaves nothing to detect. Fixtures under AEF 1201 can demonstrate that a verifier emits a given qualification on a given input, which narrows the gap for conditions somebody thought to test, and the population of conditions nobody tested is unbounded, exactly as AEF 1100 threat 9.1 describes. **V38's "source that is not the operator" has no threshold.** A package registry the operator publishes to is not the operator and is not independent of them. Two honest readers can disagree about whether a given distribution channel satisfies V38 with nothing to settle it. This is the same defect AEF 1101 section 16 records for its own "identifiable parties" field. **V39's reproducibility has no designated performer.** Nothing says who builds the verifier from source and compares, or where that comparison is recorded. This is AEF 1100 threat 9.2's fixture adequacy defect in a new location: a property that is checkable in principle and unobserved in practice. **V7's OTHER class is chosen by the implementer.** Nothing prevents an implementer classifying a novel condition into a near-fit registry class rather than reaching for OTHER, which would suppress precisely the signal the open registry exists to produce. **V16 is currently unobservable** and will remain so until AEF 1300 supplies item 2 in section 15, because absence cannot be tested against a declaration that enumerates nothing. ## 18. Requirements the reference implementation currently fails Following AEF 1101 section 14, and added to the running list there. The reference implementation's verifier is built as a hostile target, with one flipped byte required to fail and golden fixtures re-pinned on every change, per AEF 1000 section 1. It satisfies **V8 and V9**, which are the framework's core check and the one threat AEF 1100 counts as defended today. It fails everything concerning the verification result as an artifact. AEF 1101 section 14 already records that its results do not record the trust base in force, so it emits no conformant verification result and therefore fails **V1**, and with it **V2 through V7**: there is no outcome vocabulary, no qualification structure, and no negative claims block. It fails **V32 through V34** because AEF 1101 section 14 records that it performs no comparison at re-verification, there being no recorded base to compare against. It fails **V35** for the same reason and because it records no seal time anchor. It fails **V38** and **V39**. AEF 1101 section 13 entry 4 states that what a reviewer runs is the operator's program today, which is the condition V38 exists to end. The status of the remaining requirements is untested rather than known, and reporting them as satisfied on the strength of the author's belief would be the defect this series keeps naming. AEF 1201 is what converts untested into tested. Two are worth calling out as newly failed rather than newly stated. **V12** is unmet: the implementation takes its trust anchors from configuration the operator controls. **V42** is unmet: its output uses the word "verified" as a bare result label, which is the exact overstatement section 13 exists to prevent, in the author's own system. ## 19. Weaknesses in this document Stated as findings against the current text rather than as future work. **The unreachable PASS creates pressure to redefine qualifications.** Section 7.2 concludes that no implementation can emit PASS today. An implementer who wants a green result has one available move, which is to argue that a condition is a standing limitation rather than a qualification, since standing limitations do not block PASS under V6. The boundary in section 7.3 is stated in words and settled by argument, and nothing adjudicates it. This is the most likely way the outcome vocabulary fails in practice. **The qualification and standing limitation distinction may not be exhaustive.** ROLES-UNDISCLOSED is a qualification because a record could disclose roles. But no verifier will ever establish that a disclosed role assignment is truthful, which is a standing limitation about the same subject. Some conditions appear to be both, one per property, and section 7.3 does not say how to split them. **Section 9.4's first case is currently unreachable**, which section 9.4 states. A requirement whose satisfying condition no record can meet is a requirement about the future, and it is written as though it binds now. It binds the reporting obligation now and the anchoring condition later, and a reader could reasonably say that is two requirements wearing one number. **INCONCLUSIVE is coarse.** It covers a missing field, an unreachable log, and an unsupported algorithm, which differ in what a reviewer should do next. A missing field is a defect in the record, an unreachable log is a liveness failure in the trust base per AEF 1101 section 10, and an unsupported algorithm is a defect in the verifier. Collapsing them was a choice for a small vocabulary and may be the wrong one. **V12 may push reviewers back to the operator.** A reviewer with no anchor infrastructure of their own has no designated source to point the verifier at, and the practical result is that they configure the operator's anchor and satisfy V12 in form. The requirement is correct and its failure mode is silent, which section 17 does not fully capture because the defect is in adoption rather than in observation. **The check organization asserts a mapping it does not prove.** Section 8 is organized by what the verifier establishes on the argument that this maps to what a reviewer wants to conclude. That claim is about reviewers and rests on nothing recorded here. ## 20. Open questions 1. **How a verifier demonstrates that it performs these checks.** Every requirement in section 14's fixture category is a claim until AEF 1201 exists. AEF 1201. 2. **Whether qualification completeness admits any observer.** Section 17 identifies it as the largest defect and offers only fixtures, which cover conditions somebody thought of. No document assigned. 3. **A threshold for V38's independent obtainability.** Section 17. AEF 1200 v0.2. 4. **Whether the qualification and standing limitation split is exhaustive.** Section 19. AEF 1200 v0.2. 5. **Whether INCONCLUSIVE should be subdivided.** Section 19. AEF 1200 v0.2. 6. **Whether a verification result should be sealed and attributable in its own right.** A result carrying an outcome, qualifications, and a trust base is evidence, and nothing here requires it to be tamper-evident, which means it inherits every threat in AEF 1100 section 6 with no defense. Surfaced by writing this document. No document assigned; it plausibly belongs in the 1300s beside record structure. ## 21. Terms used here that AEF 1001 does not define Recorded rather than coined silently, following AEF 1100 section 16 and AEF 1101 section 15. Each belongs in AEF 1001's next version. - **Outcome.** The single value a verification result carries, from section 7.1. AEF 1101 section 11 requires a result to record an outcome without defining what one is or constraining its range. - **Qualification.** A named condition under which a check established less than it is capable of establishing. Section 7.3. - **Standing limitation.** Something no verifier can establish for any record. Section 7.3. - **Negative claims block.** The artifact carrying the standing limitations. Section 7.3. - **Trust anchor.** A root, pin, or log public key against which a key binding is checked. Used by V12 and referenced implicitly by AEF 1101 section 9. - **Fatal.** Of a check: one whose failure forces the outcome FAIL. Section 8. Still undefined from AEF 1100 section 16 and AEF 1101 section 15 and used here: **time source** and **key history**. This document states what a verifier reports about a time source without AEF 1001 having defined what one is, which is the wrong order and is recorded as such, following the precedent AEF 1101 section 15 set for the same defect. ## 22. License and citation Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). Cite as: > Stellmacher, G. (2026). *AEF 1200: Verifier Requirements*, v0.1. 13 August 2026. https://grantstell.com/aef/1200 Cite the version and date, always.