# AEF 1900: Provenance Findings

## Two occasions on which this series asserted more than it had observed

**AEF 1900. Version 0.1. Published 14 August 2026.**

## 1. Status

AEF 1900 v0.1 is an incident record. It is the seventh document in the series and the first in the 1900 block.

This document is non-normative and sets no requirements. It records two findings against the series, states what was withdrawn, states what is now unknown, and names the two implementations the series had been referring to with one label. Where it describes a correction, the correcting document is the authority and this one is the account.

Every statement here is either attributable to a published document, cited by document, section, and date, or observed by running or reading code and artifacts present in the repository that carries these documents. Section 11 records the one place that discipline is strained.

AEF 1000 is the source of authority. AEF 1001 supplies the vocabulary, used exactly and not redefined.

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

## 2. Why this document exists, and why it is numbered 1900

Two defects were found in this series between 13 and 14 August 2026, three days after its first documents were published on 11 August 2026. Both are instances of the thing the series is about. Neither is visible to a reader who reads only the corrected documents, because a correction that leaves no trace teaches nothing.

AEF 1000 section 1 states that every version is dated, kept at its own path, and recorded in the changelog, because a framework that overwrites its own history is asking to be trusted rather than checked. That principle governs versions of documents. It says nothing about how a framework records a finding against itself, and this document is the answer to that.

**On the number.** The block allocation in AEF 1000 section 9 assigns 1000s to foundations, 1100s to threat and adversary, 1200s to verifier and conformance, 1300s to the record, and 1400s to custody and time. Every one of those blocks is about the object of study. This document's subject is the series itself, which is a different kind of thing, and placing it in any existing block would put an incident record where a reader is looking for a specification.

The nearest alternative is 1002, in the foundational block beside the charter and terminology. It was rejected on two grounds. A reader scanning the 1000s for the framework's foundations would find an incident report between them, which is a discoverability defect rather than a filing convenience. And the 1000s are where the normative foundations sit, while this document sets no requirements at all.

A new block is opened instead, at 1900, with the gap between 1400 and 1900 left for specification blocks not yet allocated. The block is **records about the framework itself**: incident records, provenance findings, and errata accounts. Opening a block for a single document is over-structure if nothing follows it, and the honest expectation is that something will: two instances found without looking implies more found by looking, and section 9 records that the looking has now been done once. Adding the block and this document to the allocation list is a cross-reference change to AEF 1000 section 9, which the freeze in that section permits, and it was made together with an errata change described in section 5.

## 3. Classification of AEF 1101 sections 13 and 14

AEF 1101 v0.1, published 11 August 2026, carried two sections describing a software system. Section 13 was headed "The reference implementation's trust base" and contained a ten-row table. Section 14 was headed "Requirements the reference implementation currently fails" and named four.

Every statement in those two sections that makes a claim about that system is classified below. **Attributable** means traceable to a published statement, with the citation. **Observed** means verifiable by running or inspecting code present in the repository. **Inferred** means neither: presented as fact without either basis.

| # | Statement | Class | Basis |
|---|---|---|---|
| 1 | The author of AEF also writes its reference implementation, so the verifier has no adversary in its history | Attributable | AEF 1001 section 7.1, 11 August 2026 |
| 2 | The system produces signed act-log bundles for agent runs, with a verifier built as a hostile target | Attributable | AEF 1000 section 1, 11 August 2026 |
| 3 | The closure is cut at the hardware vendor because below that line the author has no visibility | Attributable | A statement of the document's own method by its author |
| 4 | Row 1: the sealing key was held only by the signer, controlling party the operator | Inferred | That signing occurs is in AEF 1000 section 1. That the operator holds the key is stated nowhere |
| 5 | Row 2: key binding, controlling party "to be named by the editor", external "Partly" | Inferred | An externality answer given for a party the row declines to name |
| 6 | Row 3: time source, controlling party "to be named by the editor", external "Partly" | Inferred | As row 2 |
| 7 | Row 4: the verifier a reviewer runs is the operator's, today | Inferred | Asserts a distribution state of a system not published |
| 8 | Row 5: golden fixtures, controlling party the author | Attributable | AEF 1000 section 1 states fixtures are re-pinned on every change |
| 9 | Row 6: signature and hash implementations, controlling party "Cryptographic library maintainers" | Inferred | Names a category. AEF 1101 section 6 states that a statement whose controlling party fields do not name identifiable parties does not satisfy that section |
| 10 | Row 7: language runtime, controlling party "Runtime maintainers" | Inferred | As row 6 |
| 11 | Row 8: build toolchain, controlling party "Toolchain maintainers" | Inferred | As row 6 |
| 12 | Row 9: retention at rest, controlling party "Hosting party" | Inferred | As row 6 |
| 13 | Row 10: hardware, controlling party "Hardware vendor" | Inferred | As row 6 |
| 14 | Ten parties, five external under all three tests, three under none, two partly | Inferred | Counts derived from the rows, with section 7's tests applied to parties never named |
| 15 | The three uncomfortable entries are 1, 4, and 5 | Inferred | Derived from rows classified above as inferred |
| 16 | Entries 2 and 3 name a party the editor has not published, and a worked example with an unnamed controlling party fails section 6 by its own test | Attributable | True on inspection of the table itself |
| 17 | The reference implementation fails four requirements in this document | Inferred | Aggregate of the four below |
| 18 | Section 6: it publishes no trust base statement at all | Observed | No such statement appears in the series or the repository. Absence of publication is checkable by looking |
| 19 | Section 10: it has no independent key history | Inferred | A claim about internal behaviour |
| 20 | Section 11: its verification results do not record the trust base in force | Inferred | A claim about the form of output nobody had seen |
| 21 | Section 12: it performs no comparison at re-verification | Inferred | A claim about behaviour |
| 22 | Section 13 entries 4 and 5 are the same failures viewed from the other side | Inferred | Derived from rows classified above as inferred |

**Counts.** Twenty-two classifiable statements. Attributable: five. Observed: one. Inferred: sixteen.

Six of twenty-two survived, which is twenty-seven percent. Of the ten-row trust base table, one row survived. Of the four requirement failures section 14 named, one survived, and it survived in a narrower form than it was written in: what is checkable is that no trust base statement for that system has been published, not that the system maintains none.

## 4. Finding one: inference published as observation

**What was asserted, and where.** AEF 1200 v0.1, published 13 August 2026, section 18, asserted two specific defects in a system it called the reference implementation: that the implementation takes its trust anchors from operator-controlled configuration, and that its output uses the word "verified" as a bare result label. Both were written as observations of a running system. Neither was supported by any published statement, and the system was not present in the repository that carries these documents.

AEF 1101 v0.1, published 11 August 2026, sections 13 and 14, carried sixteen further statements of the same kind, classified in section 3.

**How it was caught.** On 14 August 2026, while building the record published at `/aef/examples/run-0001`, the AEF 1200 section 18 claims were checked against the repository in order to correct the defect they named. No such implementation was found: no capture tool, no sealing tool, no verifier, and no fixtures were present, and the only AEF code was the site's document renderer and threat parser. The claims could not be verified because there was nothing to verify them against, which is also why the defect they described could not be fixed.

The mechanism that caught this is the distinction the framework already draws. AEF 1001 section 8 defines **attested** and separates it from logging, from signing, and from certification, and states that a signature establishes who and that the bytes have not changed while establishing nothing about what anyone asserted. AEF 1000 principle 1 holds that a control is not evidence until it has been observed enforcing. Applying the framework's own test for whether a claim rests on observation to the framework's own claims is what produced the finding. No external party raised it.

**What was withdrawn and what replaced it.**

AEF 1200 section 18 has been corrected twice, and both corrections are recorded in it rather than folded in. The first, on 13 August 2026, withdrew the two fabricated observations and rested the remaining list on AEF 1101 section 14. The second, on 14 August 2026, withdrew everything that rested on the three AEF 1101 section 14 claims now classified as inferred: the statements that the system fails V1, V2 through V7, V32 through V35, V38, and V39 are withdrawn, because each derived from a claim about internal behaviour that nobody in a position to publish had observed.

AEF 1101 v0.2, published 14 August 2026, withdraws the section 13 table and three of the four section 14 requirement failures. Section 13 now points to a worked trust base statement produced by inspection rather than description, published at `/aef/examples/run-0001/trust-base.json`, whose ten dependencies name parties rather than categories. Section 14 now reports conformance for the implementation that can be run, and states what is unknown about the one that cannot.

AEF 1101 v0.1 remains readable at its own path, unaltered. AEF 1000 section 1 requires that superseded content stay available, and a withdrawal that erased the withdrawn text would leave a reader unable to check the account in this document against what it describes. The correction is published rather than edited for that reason.

**What this amounts to.** A specification about evidence contained unevidenced claims about its own implementation. The claims were plausible, they were consistent with everything else the series said, and several of them may well be true. None of that is the point. They were presented to a reader as observations when they were inferences, and a reader had no way to tell which they were holding.

**What remains unknown** is listed in section 8.

## 5. Two implementations, one label

The series had been using "the reference implementation" for two different systems with different provenance and different evidentiary standing. That is a defect this framework would flag in anyone else, and it is what made finding one possible: a claim about one system reads as a claim about the other when both answer to the same name.

**The antecedent system.** The system AEF 1000 section 1 describes: signed act-log bundles for agent runs, with a verifier built as a hostile target where one flipped byte must fail, manifest path collisions tested rather than assumed impossible, and golden fixtures re-pinned on every change. AEF 1000 section 1 states that the doctrine came from building that system and breaking it, which is the role the name records. It is not published, and it is not present in the repository that carries these documents.

**What is claimed about it, and on what basis.** Only what AEF 1000 section 1 says, which is attributable to the author and unverifiable by a reader. No conformance against any document in this series is claimed for it. Its trust base, key handling, verification result form, and re-verification behaviour are unknown.

**The AEF reference implementation.** The implementation at `packages/aef` in the repository, which produced the record, the declaration, the trust base statement, the three verification results, and the tampered copy published at `/aef/examples/run-0001`, and which carries twenty-two golden fixtures of which ten are required to fail. AEF 1300 section 13, published 13 August 2026, reports what it produced.

**What is claimed about it, and on what basis.** Its conformance is reported by running it. Its source can be read, its fixtures can be executed, its record can be downloaded and checked, and its failures are published beside its successes.

**Recommendation: the AEF reference implementation is the reference implementation of the series.** The grounds are the ones the series already states. AEF 1100 threat 9.3, published 11 August 2026, records verifier substitution as CONCEDED and as the most likely real-world failure in that document, because a reviewer who cannot obtain a verifier independently runs the operator's. AEF 1200 V38 and V39, published 13 August 2026, require a conformant verifier to be obtainable from a source that is not the operator and to publish its source. Exactly one of these two systems satisfies the condition those requirements exist to create. A reference implementation a reviewer cannot obtain is a description of an implementation.

This is a recommendation about naming and standing, not a judgment about quality. Nothing here establishes that the antecedent system is worse, and by AEF 1000 section 1's account it is more mature. It is unavailable, which for this purpose is the only property that matters.

**Where the names now appear.** AEF 1000 section 1 was changed by errata on 14 August 2026 to name the antecedent system and to state that it is not the reference implementation of the series. That is an errata change under the freeze in AEF 1000 section 9, made together with a cross-reference change to section 9's block list, and the changelog says which is which. The superseded charter versions v0.1 and v0.2 retain the original label and are not rewritten, per AEF 1000 section 1; a reader arriving at either should read this section.

## 6. Finding two: verification from inside the working tree

**What happened.** On 14 August 2026, the record published at `/aef/examples/run-0001` was verified twice with the same verifier and the same inputs, differing only in where the artifacts were read from.

Verified from inside the repository working tree, with the artifact root set to the repository, the outcome was `PASS_WITH_QUALIFICATIONS`.

Verified from the published files alone, downloaded over HTTP with no repository present, the outcome was `INCONCLUSIVE`.

The second configuration is the one an actual reviewer occupies. The first is the one the author occupies.

**Why.** The verifier treated artifacts it could not obtain as a check it could not run, which under AEF 1200 V36 forces the result `INCONCLUSIVE`. AEF 1200 section 8.4, published 13 August 2026, states the correct disposition: a mismatch between a supplied artifact and its recorded hash is fatal, and absence of artifacts is not fatal and is qualified. The verifier was wrong against a requirement published the previous day.

**What changed.** The artifact check now distinguishes three states rather than two: a record that binds no artifacts, a record whose artifacts were not supplied, and a record whose artifacts were compared. Absence qualifies with `ARTIFACTS-UNAVAILABLE` and never reaches the state that forces `INCONCLUSIVE`. A reviewer holding only the published JSON now receives `PASS_WITH_QUALIFICATIONS` with the unavailable bindings named. A regression fixture pins the behaviour, and it is in the set that runs on every build.

**The general lesson.** Verifying your own artifact from inside your own working tree tests a configuration no reviewer is ever in. AEF 1000 principle 2 requires that verification not depend on the operator, and it is written about records. It applies with equal force to the tooling: a verifier exercised only where the operator's filesystem is present has been exercised under the operator's conditions, and its behaviour outside them is untested. The defect was not in the specification, which was correct and one day old. It was in checking the implementation somewhere the specification's reader will never stand.

## 7. What the two findings have in common

Both are assertions that were true from where the author stood and unverifiable from where the reader stands.

In finding one, the claims about the antecedent system may be accurate. The author has access to that system and may know each of the sixteen inferred statements to be correct. What a reader holds is a document asserting them, with no way to distinguish the statements the author checked from the ones the author supplied from memory or from expectation. The gap is not between true and false. It is between a claim and a claim a reader can test, which is the distinction AEF 1001 section 8 draws when it separates **attested** from signed, and the distinction AEF 1000 principle 2 draws when it requires that verification not depend on the operator.

In finding two, the verifier genuinely did produce `PASS_WITH_QUALIFICATIONS`, every time the author ran it. The result was reproducible, correct as far as it went, and wrong about the only configuration that matters, because the author's working tree supplied something the reader's download does not.

The framework exists because that gap is invisible from inside. It occurred twice inside the framework, within three days of its first publication, in documents written specifically about it. That is not evidence the framework is unsound. It is evidence that the failure mode it describes is not a property of careless operators, which is the assumption a reader might otherwise take from AEF 1100 section 4's characterisation of the adversary as a normal institution under pressure rather than an intruder.

## 8. What is now unknown

The list of statements the series previously asserted and no longer does. Each is owed by whoever can observe the antecedent system.

1. Who controls the sealing key for the antecedent system, and whether it is held solely by the signer.
2. What key binding mechanism it uses, and which party makes the binding assertion, if any.
3. What time source stamps its capture, seal, and approval times, and whether that source is outside the operator's control.
4. How its verifier is distributed, and whether a reviewer can obtain it without the operator's cooperation.
5. Which cryptographic library, language runtime, and build toolchain it depends on, named as parties rather than categories.
6. Which party retains its sealed bundles, and under what terms.
7. Whether it maintains an independent key history in the sense of AEF 1101 section 10.
8. Whether its verification results record the trust base in force, in the sense of AEF 1101 section 11.
9. Whether it performs a comparison at re-verification, in the sense of AEF 1101 section 12.
10. Its conformance against any requirement in AEF 1200, none of which is now claimed either way.

One statement about that system survives and is narrower than what was withdrawn: no trust base statement for it has been published in this series or in this repository, which is checkable by looking and says nothing about whether one exists internally.

## 9. Other statements with the same provenance problem

Two instances found without looking implies more found by looking, so the series was searched on 14 August 2026 for claims about the behaviour of any system, across AEF 1000 v0.3, AEF 1001 v0.1, AEF 1100 v0.2, AEF 1101, AEF 1200 v0.1, and AEF 1300 v0.1.

**What the search found.** No further inferred claims. The remaining statements about systems fall into three groups, all of which a reader can check.

Statements about the framework's own documents, such as AEF 1001's record of which terms AEF 1000 uses, are verifiable by reading the cited document.

Statements of general reasoning that name no system, such as AEF 1200 section 11's observation that a framework whose verifier qualifies everything produces results that are honest and weak, assert nothing about any implementation.

Statements about the AEF reference implementation in AEF 1101 v0.2 section 14 and AEF 1300 sections 13 and 14 are observable in the repository, including the two that report failures: that the signing key is generated on the build host and held by the operator, which `packages/aef/seal.ts` shows, and that no comparison is performed at re-verification, which the verifier's interface shows by taking no earlier result.

**What the search does not establish.** It covered claims about software systems. It did not audit the series' claims about the world, of which AEF 1000 section 2 contains many: dates, enforcement actions, audit outcomes, and regulatory histories across nine domains. Those carry a different provenance question, they were gathered from search results rather than from primary sources reachable from this environment, and auditing them is a separate exercise this document does not perform. Recorded here so that the absence is visible rather than implied.

## 10. What this document does not do

It sets no requirements. It proposes no revision to any requirement. AEF 1101 v0.2 and the corrections to AEF 1200 section 18 and AEF 1000 section 1 are the changes; this is the account of why they were made.

It does not claim the corrections are complete. Section 9's search covered one class of claim, and section 11 records what would show this document itself to be wrong.

It does not treat either finding as creditable. Both were defects, both were introduced by the author, and one of them was introduced into a document whose subject is precisely the distinction it violated.

## 11. Weaknesses in this document

Following the audit applied in AEF 1000, AEF 1100 section 17, AEF 1101 section 16, AEF 1200 section 17, and AEF 1300 section 16.

**The classification in section 3 is performed by the party whose statements are classified.** No independent reader has confirmed that the sixteen inferred entries are inferred or that the five attributable ones are attributable. The classification is checkable, because each row cites its basis and a reader can follow the citation, and it is not independent. This is the same defect AEF 1101 section 16 records for its own section 13 and does not escape either.

**The boundary between attributable and inferred is not sharp, and row 4 is where it shows.** That a signing system has a key held by somebody is close to definitional, and classifying "the operator holds it" as inferred rather than attributable is a judgment. A reader who thought the operator holding the key follows from AEF 1000 section 1 would count seven survivors rather than six. The strict reading was taken because the alternative is deciding case by case how much may be assumed, which is the mechanism that produced finding one.

**Finding two's general lesson rests on one instance.** One verifier, one record, one difference between two configurations. The claim that verifying from inside a working tree systematically tests the wrong configuration is a generalisation from a single case, and it is stated as a lesson because it follows from AEF 1000 principle 2 rather than because the instance count supports it.

**Section 9's search used pattern matching over prose.** It looked for verb constructions asserting behaviour, and a claim phrased differently would not have matched. The search's negative result is weaker than it reads, and a second pass by someone who did not write the text would be worth more than this one.

**This document is not itself an attested execution record.** It records findings about evidence in a form that carries none of the properties the series specifies: it is unsealed, its claims are not bound to the artifacts they describe, and nothing detects its alteration. AEF 1200 open question 6 and AEF 1300 open question 6 both record that verification results have the same problem. The observation extends to the series' own prose, and no document currently owns it.

## 12. License and citation

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

Cite as:

> Stellmacher, G. (2026). *AEF 1900: Provenance Findings*, v0.1. 14 August 2026. https://grantstell.com/aef/1900

Cite the version and date, always.