AEF Changelog

Conformance claim 0001, 15 August 2026#

• The first conformance claim in the framework's history, published at /aef/conformance-claim-0001.json per AEF 1201 C1 through C4: aef-reference-verifier 0.5.0 against AEF 1200 v0.2, the suite version named by digest, per-fixture results for all 43 pinned fixtures, expected against observed, all agreeing. The claim is partial and says so inside itself: fifteen requirements are listed as failed, partially exercised, or unexercisable, including V13's unimplemented branches, V32 through V34's absent re-verification comparison, and the anchor mechanisms' absent proof verification. It carries AEF 1201 section 9's shared-authorship sentence verbatim, which is written to be deleted and today is true, and no certification language anywhere, per C4 and V42.

Suite version six, 15 August 2026#

• Every fixture is now a pinned pair as AEF 1201 C5 defines one: inputs comprise the record, the declaration, supplied acceptances, renewals, and deprecations, the trust base statement, and the options, with the verification time pinned and artifact roots pointing at snapshots rather than the live repository. The core-0001 family pins what previously lived in regenerated tests; the hand-written tests remain as a labeled generated layer that discharges nothing. Every pinned fixture pins its complete qualification set by class, its outcome, its first failing check, and its exact fatal and non-fatal failure sets (C6). Every check that can fail has a failing fixture, all 15 fatal-capable checks have isolating fixtures asserted by exact fatal-set comparison (C7, C8), and three checks that cannot fail by construction are listed as such. The coverage declaration binds every pinned input by digest, options and trust base statement included (C10), and is generated from the suite so it cannot drift.
• The self-test AEF 1201 section 10 requires now exists: a digest-pinned subset of fifteen required-to-fail fixtures, one per fatal check, inputs inlined, executed in the deployed configuration before the first result in both the CLI and the browser build, refusing with fixture id, expected, and observed on any mismatch (C19, C20), with every result recording the subset digest and outcome (C21). The verifier moves to 0.5.0. The generator asserted every prior expectation before re-pinning and surfaced no divergence, so no challenge entry was filed and no retirement was needed; the five prior retirements carry forward. The running failure list against AEF 1201 is empty for the first time, which is not a statement of suite adequacy, per the document's own section 4.

The trust base confirmation, 15 August 2026#

• The operator reviewed the ten rows of the reference implementation's trust base statement against the live system and confirmed each; the statement now carries the confirmation as a member, dated, with the caveat that governs what it can mean: confirmation by the operator is the operator's account of its own system, per AEF 1101 section 16, and the rows move from agent-observed to author-confirmed, no further. An errata note in AEF 1101 v0.2 section 13 records the two party corrections the confirmation covers and points to the review record. AEF 1900 section 8's ten-item unknown ledger concerns the antecedent system, which this confirmation does not touch; it remains open. The confirmation member changed the statement's digest, so run-0001 and its results were regenerated under the record's established practice.

The review freeze, 15 August 2026#

• No new numbered document ships until an external review round of three reviewers has responded, or 90 days have elapsed, whichever comes first. Revisions that disposition challenges, and errata, remain permitted; the challenge mechanism stays open throughout.
• The reason is the series' own signal, read honestly. The two largest defects on record, AEF 1900 finding one and the seal-boundary discovery that forced AEF 1300 v0.2, were caught by structured hostile audit, not by the editor's unaided review. When one reader's review has stopped finding the big defects, continuing to specify on that reader's assurance is the overstatement failure in process form, and the series' answer to overstatement has always been the same: stop asserting, and invite the reader whose job is to disbelieve.
• The record of what external review is asked to attack, and how to file a challenge, is at /aef/start and in AEF 1201 section 8.

• A breaking revision, and the break is the point. What broke: R6's seal boundary. The v0.1 boundary removed the whole seal member from the signed bytes, leaving sealedAt, keyId, alg, and the anchor rewritable by any holder without a key, the defect AEF 1400 section 7's hostile review found. The v0.2 boundary removes only the seal's value: the seal signs its own time and anchor, and the form-0002 fixtures demonstrate both halves of the repair as required-to-fail inputs the old boundary would have passed. v0.1-form records are retroactively weaker, not retroactively wrong: they verify under their own boundary and carry the UNAUTHENTICATED-SEAL-MARGIN qualification naming what that boundary leaves open.
• What moved, and why. R2 now defines aefVersion as the record-form selector, inside the signed bytes, closing challenge-0003's unversioned-transition gap; a verifier that cannot determine the form reports it and checks nothing else. R24 is superseded by reference to AEF 1301 A3 with the member set closed, ending R1's hiding place one level down, and resolution-0003 rules that each form is tested as its claimed version defines it. R27 adds the supersedes member in the canonical-identity digest domain, resolving AEF 1400 T9's two-domain interim. R7 gains sealLatency per AEF 1400 T8. R23 gains the content-addressed SHOULD the run-0001 decay lesson forced.
• The signed-boundary audit, new as a section: every member of every structure enumerated against the signature that covers it. It found one further instance of the defect class, the acceptance envelope's own seal members, repaired in the same revision per the brief that ordered the audit.
• Section 13's fixture description is corrected per AEF 1201's inventory: the suite is described by its coverage declaration now, not by prose that can drift from it. Findings filed: AEF 1201 v0.2 owes the superseded-not-wrong retirement category and the resolution-entry mechanic; AEF 1400 v0.2 owes T3's form-dependent margin language.

AEF 1200 v0.2, 14 August 2026#

• A consolidating revision: no new checks invented, every change a recorded debt paid. The four challenges are ruled first, resolutions 0001 through 0004 appended to the challenge record before the text that reflects them. V22 scoped: chaining absence is fatal for forms that require chaining, which is every current form, and ORDER-UNCHAINED survives for forms that do not, of which none exist. V29 split: required-and-absent is fatal, otherwise qualified, emission unconditional both ways. V27 tests the form the record's claimed version defines, which ruled against the shipped behavior; the disputed fixture is retired with its reason and re-pinned, an approval carrying any A3 member is held to A3's semantics so discriminator-stripping dodges nothing, and the ruling's first draft reached a second fixture it had no challenge for, reversed by the hostile review before publication. V25's emission is conditional on the declaration's bound, the only bound the series defines.
• Twelve ids issued, V43 through V54, for the checks that existed without them: declaration-binding, termination, the four approval checks from AEF 1301, the anchor set from AEF 1400, seal-latency, record-form, and per-check status, the revision AEF 1300 section 14.2 called its most substantive candidate. Eight of the ten fixture-checkable ids have pinned fixtures whose entries cite them; declaration-binding and termination are exercised by generated tests only, a C5 gap the declaration shows, and the two report-only checks discharge the required-to-fail obligation by the statement that there is nothing to fail.
• V13 is restated over supplied, stapled revocation data and inclusion proofs, closing the carve-out AEF 1201 section 15 finding 1 forced: the branches are expressible for the first time, remain unimplemented, and expressible-but-undone is a different debt than inexpressible. V35 is restated over the supplied deprecation list per AEF 1400 T11. The registry admits the twelve OTHER classes that earned their way in, plus the margin class; APPROVAL-SEMANTICS-UNEVALUATED entered through OTHER the day resolution-0003 landed and is v0.3's first candidate.
• The weaknesses section says the uncomfortable parts: four challenges filed by the editor were ruled by the editor, three in the shipped behavior's favor; the issued ids number what the one implementation already did; and fifty-four requirements make the coverage declaration the only practical audit surface, which makes the suite's honesty load-bearing for the document's.

AEF 1400 v0.1, 14 August 2026#

• Tenth document in the series, first in the 1400 block, and the last document on AEF 1000 section 9's committed-and-unwritten list. Normative throughout, requirements T1 through T12, binding anchor evidence, anchored records and declarations, renewals, retention for re-verification, and what a re-verification result names. Verifier checks are findings for AEF 1200 v0.2, implemented in the reference verifier so pinned fixtures exercise them over supplied material, per AEF 1201 section 15 finding 1's expressibility rule.
• The debt ledger is stated at the top, with 1100's dispositions quoted as they stand: 10.4 CONCEDED outright, 10.3 and 7.3 and half of 10.1 CONDITIONAL on mechanisms no document had specified, R14 without an observer, 1001 section 9's time-source assignment, 1101 section 10's interval endpoints, and the time semantics 1101 section 12 and 1200 section 9.4 left open. The success test is stated precisely: how many unrealizable conditions become realizable, and at what price.
• The price included the session's largest discovery, found by this document's own hostile review and stated before anything is built over it: under 1300 R6 the entire seal member, sealedAt, keyId, alg, and the anchor, sits outside the signed bytes, rewritable by any holder with no key, unauthenticated since 1300 v0.1 and load-bearing once R20 gave the member an anchor to carry. The record's only covering artifacts are external holders of its whole digest, renewals, acceptances, results, which is what makes renewal the counterweight rather than a nicety. The structural repair is the lead finding for AEF 1300 v0.2, priced as the breaking change it is.
• A time anchor is 1101 section 9's key pattern applied to time: an assertion by a party other than the operator that a named digest existed at or before a stated moment, plus detection for that party's own misbehavior. Mechanisms are named, not invented: RFC 3161 authorities, transparency logs, blockchain anchoring, each with its externality under 1101 section 7, none ranked universally, the trust base carrying the choice, and one differentiator stated: a monitored log makes an operator's anchoring volume observable, which is the only lever against the candidate-menu attack the review surfaced.
• The seal is the anchoring point; capture times stay the operator's, conceded plainly. Where both seals are anchored, the pair either establishes the declaration-first relation or reports that it establishes nothing: the first draft made the late case fatal as a self-contradiction, the review showed a late anchor is consistent with an old declaration, and the correction landed before the wrongly pinned fixture was ever published. The interval gets the declared-scope treatment, an exceedance is a finding inside a declared boundary, and the narrowed emission of V25's qualification is filed as challenge-0004 rather than claimed as pre-authorized, since 1400 imposed no bound of its own and 1200 section 8.6's note anticipated one.
• A sealed record is never re-sealed; correction is a new record referencing the old among its input state, in the retained-bytes digest domain, with the two-domain cost stated and the dedicated member filed for 1300 v0.2 per challenge-0003's lesson. Re-verification gets its three cases, with the third cut to what the construction supports: an anchor predating a public break preserves the content's anchored existence, not the seal's attribution, standing moves from seal to anchor, anchors chain, and a chain not extended by a renewal that predates the deprecation under undeprecated algorithms is a named lapse. V35's first case, which 1200 section 9.4 called unavailable, is now reachable and pinned in both directions over a pinned deprecation list.
• Applied in the same session: the anchor-0001 worked example with fabricated, well-formed evidence, two isolating required-to-fail fixtures for the two fatal anchor checks, the corrected late-anchor fixture pinned under its true expectation, the finding-not-failure latency fixture, and three chain fixtures; verifier 0.3.0, suite version three, nothing published removed or altered. The running failure list grows honestly: no mechanism proof verification is implemented, every anchored result says so via ANCHOR-PROOF-UNVERIFIED, and outside these fixtures zero real anchors exist anywhere in the ecosystem.
• The honest floor is rewritten in two sentences: unchanged for unanchored records, and for anchored ones every gain is enumerated with its condition attached, content not fabricated after the anchor against compromise that still reaches signatures, an anchored outer edge riding in the unauthenticated margin until an external holder binds it, and bounded lateness for the published declaration but not for the menu it may have been chosen from.

AEF 1301 v0.1, 14 August 2026#

• Ninth document in the series, second in the 1300 block. Normative throughout, binding an approval record, an acceptance envelope, and an implementation producing either. Requirements A1 through A15. Verifier checks are findings for AEF 1200 v0.2, implemented in the reference verifier so pinned fixtures exercise them, per the lesson AEF 1201 section 15 finding 1 taught: state every check over supplied data, never over liveness.
• The core distinction: approval is two things. An authorization asserts before execution, and its referent can only be what existed then, which for a 1300 record is exactly the separately sealed declaration; it cannot attest outcomes. An acceptance asserts after sealing, its referent is the sealed record by digest, and it lives outside the record, because a member cannot bind by digest the whole that contains it. A record carrying one and claiming the other's semantics is the overstatement failure wearing an approval. The ordinary case carries both.
• What an approval signature asserts is enumerated and closed: signer to the key binding's honest strength, time to its source's worth, presented bytes by digest in a declared presentation context, and the authorizing or accepting clause. It does not assert correctness, completeness beyond declaration, understanding, or competence, and anti-overclaim language in the pattern of 1200 V42 and 1201 C4 binds the record, the envelope, and how implementations describe them.
• AEF 1001 open question 3 closes as narrowed, not solved. The referent splits: a mismatch between the record's claimed referent and the stored artifact is now detectable, which bounds AEF 1100 threat 8.1's artifact half; a mismatch between the stored bytes and what the approver's eyes saw is structural and no record will ever carry it. Threats 8.2 and 8.3 keep their dispositions, 8.2 with its boundary marked by a new APPROVER-INDEPENDENCE-NOT-ESTABLISHED qualification, because distinct keys do not establish distinct parties, and 8.3 with an optional basis member, checkable as to presence and never as to substance.
• Automated approval takes a position without a new category: an approval is attributable to a party in 1001's role sense, a machine approving under the operator's key is the operator self-approving and must disclose it, and no agent-as-approver doctrine enters through a schema member.
• The professional-attestation question stops floating: what an aer supplies toward examinable subject matter and the two parts it lacks are stated, the criteria-reference member is specified as the record-side hook, and the remainder is assigned to AEF 1302 with the placement argued. The charter's cross-reference waits for a re-pinning run, per the constraint AEF 1201 section 14 recorded.
• Applied in the same session under 1201's suite discipline: the approval-0001 worked example at /aef/examples/approval-0001, an authorization sealed by a distinct approver key before the first act plus an acceptance sealed over the record after it, and eight pinned required-to-fail fixtures, each isolating one approval check. approval-form, which AEF 1201 found had no failing fixture of any kind, now has three. The worked example, the self-approved record, and run-0001 become the suite's first three entries with complete qualification sets pinned by class. The verifier moves to 0.2.0; the suite moves to its second version with nothing removed or altered.
• Two challenges filed. Challenge-0002: required-and-absent approval fails where AEF 1200 section 8.7's letter says qualify, because R24's approvalRequired field postdates that text; V29's emission half is honored on both branches and only fatality is contested. Challenge-0003, against this document's own transition: an approval in R24's exact three-member form satisfies V27's letter and fails the 1301-applying verifier, and the record's aefVersion has no way to name which form it carries. Both unresolved, published, referred to AEF 1200 v0.2 and AEF 1300 v0.2, alongside the V29 split, four registry candidates, and R24's supersession and member-set closure.

AEF 1201 v0.1, 14 August 2026#

• Eighth document in the series, second in the 1200 block. Normative throughout, binding three subjects separately: a conformance claim, a fixture suite, and a verifier's self-test behavior. Requirements C1 through C21.
• Closes AEF 1001 open question 6. Conformant was defined on 11 August and unusable since, because nothing stated how conformance is demonstrated. AEF 1200 supplied what a verifier must do; this document supplies how anyone shows that it does it. The jurisdiction is the eleven requirements AEF 1200 section 14 classified as checkable only by running the verifier against fixtures.
• The core problem is stated before it is built on: self-test is the operator grading its own exam, and suite adequacy is a negative existential of the same species AEF 1101 section 8 refused for irreducibility. The document applies 1101's move rather than pretending to solve it: coverage is declared, gaps are enumerated, misses become permanent fixtures under the miss rule, and the suite is open to counterexamples through a challenge path whose dispositions are public. AEF 1900 finding two's regression fixture is cited as the miss rule's precedent, not invented here.
• A conformance claim is self-published at a stable path, argued against the registry alternative, which AEF 1000 section 11 forbids in substance: a body whose listing confers status is certification renamed. A claim names the document and version, the subject, the date, the suite version by digest, and where per-fixture results live, or it is not a claim that can be checked.
• A fixture is a pinned pair per AEF 1001 section 6.12, and a regenerated input is not a fixture. Expected outcomes pin the failing check and the qualifications by class, not the top-level outcome alone. Every check gets a required-to-fail fixture; every fatal check gets one that fails it in isolation, so a verifier cannot pass by rejecting for the wrong reason.
• A conformant verifier carries a digest-pinned subset of its suite and runs it in its deployed configuration before its first result, refusing to verify on failure. The argument is AEF 1900 finding two: the reference verifier was wrong in the one configuration every actual reviewer occupies, and a self-test that ships inside the verifier is the only mechanism in the series that runs where the author never stood.
• Applied to the reference suite in the same session, per the pattern AEF 1101 section 14 and AEF 1300 section 13 set: the coverage declaration is published at /aef/examples/run-0001/fixture-coverage.json with the gaps listed and nothing fixed silently first. Four of twenty-two entries are pinned and even they fall short of C5 read strictly; counting generated tests five of twelve checks have no failing entry and approval-form has none at all, while counting fixtures as C5 defines them eleven of twelve have none and no fatal check has an isolating fixture; no entry pins a complete qualification set; the verifier runs no self-test. No conformance claim exists for the reference verifier and none can honestly be made yet, which the document states in its own section 12.
• The challenge mechanism shipped with one entry already filed, in a challenge record published beside the suite and outside the declaration so a disposition does not move the suite version. Writing the coverage declaration surfaced that a chainless record yields FAIL where AEF 1200 V22 says absence of chaining is qualified, while AEF 1300 R18 has since made chaining required, so two honest readings resolve differently. The input is pinned as challenge-0001, the reproduction recorded, and the disposition is unresolved, published, referred to AEF 1200 v0.2; one part survives both readings, that the implementation never emits ORDER-UNCHAINED on any input.
• Findings recorded and not applied: AEF 1200 V13's X.509 and Certificate Transparency branches are untestable by any self-contained pinned fixture, because revocation at verification time and log reachability are liveness properties an artifact cannot carry, which makes them requirements no conformance claim can ever demonstrate as written. AEF 1300 section 13's "twenty-two golden fixtures" overstates a suite of four pinned pairs and eighteen generated tests. AEF 1101 section 11's result form gains the self-test member. AEF 1100 threat 9.2's disposition is stale: the required-to-fail inspection is now mechanical against a published manifest, though no inspector is designated, and the document says plainly that half the defect is discharged and half relocated.

AEF 1900 v0.1, 14 August 2026#

• First document in a new block. The 1900s are records about the framework itself: incident records, provenance findings, and errata accounts. Every existing block is about the object of study, so an incident record in any of them would sit where a reader is looking for a specification. The nearest alternative, 1002, was rejected because a reader scanning the foundational block would find an incident report between the charter and terminology. The gap between 1400 and 1900 is left for specification blocks not yet allocated.
• Records two findings against the series, both surfaced between 13 and 14 August 2026, three days after its first documents were published on 11 August 2026.
• Finding one: inference published as observation. AEF 1200 v0.1 section 18 asserted two specific defects in a system it called the reference implementation, written as observations of something running. AEF 1101 v0.1 sections 13 and 14 carried sixteen further statements of the same kind. The system is not present in the repository that carries these documents, and none of the claims was supported by a published statement. A specification about evidence contained unevidenced claims about its own implementation.
• What caught it was the framework's own distinction. AEF 1000 principle 1 holds that a control is not evidence until it has been observed enforcing, and AEF 1001 section 8 separates attested from signed on the ground that a signature establishes who and not what anyone asserted. Applying that test to the series' own claims produced the finding. No external party raised it.
• Section 3 carries the row-by-row classification of AEF 1101 sections 13 and 14 into attributable, observed, and inferred. Twenty-two classifiable statements: five attributable, one observed, sixteen inferred. Six 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 in a narrower form than it was written.
• Finding two: verification from inside the working tree. The same record verified from inside the repository returned PASS_WITH_QUALIFICATIONS and, downloaded over HTTP with no repository present, returned INCONCLUSIVE. The second configuration is the one a reviewer occupies. AEF 1200 section 8.4, published the previous day, states that a mismatch is fatal and absence is not, so the verifier was wrong against a requirement one day old. Fixed, with a pinned regression fixture.
• The closing section states what both have in common: an assertion that was true from where the author stood and unverifiable from where the reader stands. The claims about the antecedent system may all be accurate; what a reader lacks is a way to tell which were checked. That gap is the framework's entire subject, and it occurred twice inside the framework within three days of publication.
• Section 8 lists ten things the documents previously asserted and no longer do, each owed by whoever can observe the antecedent system.
• Section 9 records a search of the whole series for the same defect, made on the reasoning that two instances found without looking implies more found by looking. No further inferred claims were found. The search covered claims about software systems and did not audit AEF 1000 section 2's claims about the world, which carry a different provenance question and were gathered from search results rather than primary sources. That absence is recorded rather than implied.

AEF 1101 v0.2, 14 August 2026#

A withdrawal, not an extension. No requirement changed. Sections 1, 13, 14, 16, and 17 differ from v0.1; every other section is unchanged, and v0.1 remains readable at /aef/1101/v0.1.

• Section 13's ten-row trust base table is withdrawn. It described a system not present in this repository, and nine of its ten rows stated a controlling party, a failure consequence, and an externality answer that no published statement supported and no reader could check. Five of those nine named a category rather than a party, which section 6 of the same document says does not satisfy section 6.
• What the table got right is separated from what it got wrong, because withdrawing is not reversing. Its form was correct, and one row was supportable: the fixture set as a dependency controlled by the author, which AEF 1000 section 1 states. What failed was applying a correct method to a system nobody in a position to publish had looked at.
• Section 13 now points to a worked trust base statement produced by inspection rather than description, at /aef/examples/run-0001/trust-base.json, whose ten dependencies name parties rather than categories, including the answer that no party asserts the key binding because the mechanism is none.
• Section 14's four requirement failures are reduced to what can be checked. Three were assertions about the internal behaviour of an unavailable system and are withdrawn. Conformance is now reported for the implementation that can be run: section 6 met, section 10 not met, section 11 met, section 12 unexercised. The one surviving statement about the antecedent system is narrower than what it replaced: no trust base statement for it has been published, which is checkable by looking, and whether it maintains one internally is unknown.
• Section 17 open question 1 is closed for the AEF reference implementation and left open for the antecedent system.
• AEF 1900 carries the classification and the account.

AEF 1200 v0.1, 13 August 2026, section 18 revised 14 August 2026#

• Second correction to section 18, recorded rather than folded in. The first correction on 13 August withdrew two fabricated observations and rested the remaining list on AEF 1101 section 14. That section has since been withdrawn in part, so everything derived from it goes with it: the statements that the antecedent system fails V1, V2 through V7, V32 through V35, V38, and V39 are withdrawn, because each rested on a claim about internal behaviour nobody had observed.
• What survives is what AEF 1000 section 1 states, which bears on V8 and V9 and establishes nothing about verification result form, key handling, distribution, or re-verification. The status of every requirement against the antecedent system is unknown, and unknown is not untested.

AEF 1000 v0.3, 11 August 2026, errata 14 August 2026#

Two changes under the freeze in section 9, which permits cross-references to later documents and errata. Both are recorded here by kind.

• Errata. Section 1 called the author's system "the reference implementation". The series was using that label for two systems with different provenance and different evidentiary standing, which is the ambiguity that made AEF 1900 finding one possible: a claim about one reads as a claim about the other when both answer to the same name. Section 1 now names it the antecedent system, states that it is not published and is not the reference implementation of this series, and points to AEF 1900 section 5. The description of what the system does is unchanged and remains the author's own statement.
• Cross-reference. Section 9's document list was stale, still describing 1001, 1100, 1101, 1200, and 1300 as committed and unwritten after all five had been published. It now separates published from committed and unwritten, and adds the 1900s block.
• Superseded charter versions v0.1 and v0.2 retain the original label and are not rewritten, per section 1. A reader arriving at either should read AEF 1900 section 5.
• Also fixed, outside the documents: the citation helper on superseded-version pages was hardcoded to AEF 1000, so /aef/1100/v0.1 displayed a citation for the charter rather than for the threat model. The helper now takes the document number and title.

AEF 1300 v0.1, 13 August 2026#

Shipped with the first conformant record, which is the point of it. Twenty-six requirements, R1 through R26, binding a record and an implementation that produces one.

• The series reached five documents and roughly twenty-five thousand words with nothing that satisfied any of them. AEF 1000 section 9 says no requirement ships until something has been built that satisfies it and something has been built that fails it, and until now that rule had nothing to apply to. AEF 1200 section 7.2 had already conceded that an unqualified PASS was unreachable because three of its checks needed fields no document specified. This document supplies the thirteen fields AEF 1200 section 15 listed.
• Nine requirements exist in their current form because a first draft could not be satisfied. Section 14.1 lists them: the declaration had no separate seal, termination was absent entirely, `approvalRequired` did not exist so the verifier had to guess and guessed by treating absence as acceptable, `verifierAuthor` was missing from the role disclosure, canonicalization was the word "JSON", digests carried no algorithm, the selector grammar was a sentence saying boundaries should be checkable, and time sources were declared once per record rather than per recorded time.
• Positions taken rather than deferred to profiles: JSON with RFC 8785 canonical form, non-integer numbers excluded because that is the part of RFC 8785 implementations get wrong and no field needs it, and the sealed bytes defined as the canonical form with the `seal` member removed, so adding a member later cannot silently leave it outside the seal.
• Declared scope is inclusion and exclusion together, machine-decidable rather than merely readable. Inclusion alone cannot express a boundary minus a subtree without enumerating an unbounded complement; exclusion alone has no boundary. AEF 1001 section 6.2 requires only that a reader can decide membership, which is too weak for AEF 1200 V15.
• Termination conditions address AEF 1100 threat 6.4. What they buy is stated precisely and is less than it looks: truncation before a declared closing entry now fails a check, and an operator who intends to truncate declares a deadline and stops early within it. The threat's disposition is not changed here.
• Separate pre-execution sealing of the declaration addresses AEF 1100 threat 7.3 the same partial way. It produces an artifact that cannot be revised without detection. It does not establish ordering against an external clock, and the worked example demonstrates exactly that: the binding checks and the result still carries a qualification saying the seal time is unanchored. What changed is that there is now an artifact for an anchor to attach to.
• Run linkage is OPTIONAL, with the reason stated rather than buried. An operator fragmenting work to avoid describing it will not join the fragments. Mandatory linkage would produce singleton groups indistinguishable from complete ones. AEF 1100 threat 7.2 stays CONCEDED.
• The unsupported element status is the field AEF 1200 section 15 surfaced and no earlier list contained. It is what lets a record be honest about its own gaps instead of silently omitting them, and it is the difference between the two readings AEF 1000 principle 3 distinguishes.
• The worked example. A real run: the tooling read the eight AEF documents published before this one, computed a SHA-256 digest for each, and wrote a manifest anyone holding the repository can recompute. Eighteen act log entries, eight input state items, one output artifact, a trust base statement with ten dependencies and their controlling parties named, and a tampered copy. Published at /aef/examples/run-0001, byte-identical to what the verifier consumes.
• The result, in one line: PASS_WITH_QUALIFICATIONS, twelve checks, zero failed, zero not run, ten qualifications. Each qualification is published with a plain-language line on what it means a reader cannot conclude. An unqualified PASS would have contradicted AEF 1200 section 7.2 and would have been the most damaging thing this series could publish; the verifier exits non-zero if it ever produces one for this record.
• All four outcome values now exist as artifacts rather than as prose. The tampered copy returns FAIL on a single changed character, and fails a second check as well, because R18's chaining binds each entry to its predecessor. Verifying with the declaration withheld returns INCONCLUSIVE for a real reason. Twenty-two golden fixtures, ten required to fail.
• A defect found by reading the published files as a stranger would. Verified from inside the working tree the record returned PASS_WITH_QUALIFICATIONS; downloaded over HTTP with no repository present, the same record returned INCONCLUSIVE, because unavailable artifacts reached the not-run state that forces it. AEF 1200 section 8.4 makes a mismatch fatal and absence not, so the verifier was wrong. Fixed, with a regression fixture. Verifying your own artifact from inside your own working tree tests a configuration no reviewer occupies, which is AEF 1000 principle 2 applied to the framework's own tooling.
• Eight candidate revisions recorded for earlier documents and not applied, following the constraint that held in AEF 1200 section 16. AEF 1200's qualification registry is missing four classes the first record ever built emitted, correctly classed OTHER under V7, which is the mechanism working. AEF 1200 section 8's check list is missing two fatal checks. AEF 1200 has no per-check status, so a check that could not run inside an otherwise sound verification has nowhere to say so. AEF 1200 V42 is over-broad, having flagged a qualification class named TRUST-BASE-SELF-CERTIFIED that criticised the trust base rather than claiming anything. AEF 1101 section 6's dependency record cannot express an absent assertion, which is the honest answer for entry 2 of the worked trust base, where the mechanism is `none` and no party asserts anything.
• AEF 1101 open question 1 is answered for the implementation published here: there is no key binding authority, and the time source is the host system clock under the operator's control.
• Section 15 reports what could not be produced. The brief expected some checks to report INCONCLUSIVE for missing infrastructure; in the event every check ran, and manufacturing an inconclusive check to match the expectation would have been the defect this series is about. The fourth outcome value is demonstrated separately instead.

AEF 1200 v0.1, 13 August 2026, revised 13 August 2026#

Correction. The section 18 text as first published asserted two specific defects in the reference implementation: that it takes trust anchors from operator-controlled configuration, and that its output uses "verified" as a bare result label. Neither was supported by anything the author had published. They were inferences presented as observations, in a document whose subject is the difference between the two. Both are withdrawn, and section 18 now separates what is attributable to a published statement from what is not. The system AEF 1000 section 1 describes is not in the repository that carries these documents, so nothing about it is observable beyond what the author has written down. AEF 1300 supplies a second implementation whose conformance is reported by running it.

AEF 1200 v0.1, 13 August 2026#

• First draft of the verifier requirements, the fifth document in the series and the first in the 1200 block. It is the first fully normative document: everything before it defines, analyzes, or constrains meaning, and this one states what a verifier MUST do. Forty-two requirements, numbered V1 through V42.
• Requirements bind a verifier, never an operator and never a record. Where a check needs a field no document requires a record to carry, that is stated as a finding for AEF 1300 rather than imposed here. Section 15 collects thirteen such fields and is the spine of that document.
• Binary pass and fail is rejected as the output shape, which is the design decision of the document. AEF 1100 concedes twenty-two of twenty-three threats outright or conditionally, so a verifier reporting PASS is usually technically correct and practically misleading. AEF 1100 section 13 prevented that misreading in prose addressed to a human; this document has to do it in an artifact addressed to whoever reads the output next.
• Four outcomes rather than three. INCONCLUSIVE is forced by the analysis rather than added for symmetry: a verifier handed a record and no artifacts cannot check the binding, and reporting PASS asserts a check it did not run while reporting FAIL asserts a defect it did not find. The distinction between a bad record and an unanswerable question is what the framework is about, and a three-value vocabulary erases it.
• Qualifications and standing limitations are separated. A qualification names a condition under which a check established less than it could and varies between records. A standing limitation names something no verifier can ever establish and is carried in a negative claims block whose six entries mirror the six sentences AEF 1100 section 13 says a reviewer cannot write. Merging them would make PASS unreachable by construction and would stop the qualification list carrying information about the record in front of you.
• Qualification classes are closed and instances are open. A free-text set is not comparable across verifiers or records; a closed set asserts the failure surface is fully known, which AEF 1100 section 18 shows it is not. The resolution is the discipline the series already uses for missing vocabulary: an unclassifiable condition takes the class OTHER and states what it names, and every OTHER occurrence is a finding against this document. The open-endedness becomes observable rather than silent.
• An unqualified PASS is not reachable today, and the document says so. Three of the eight checks depend on record fields or mechanisms no document has specified: chaining, an external time source, and the role disclosure field. A verifier emitting PASS in 2026 is either checking something no record can carry or has defined its qualifications away.
• AEF 1101 open question 4 is answered. Re-verification compares dependency records keyed by controlling party together with the assertion relied on, since keying by party alone ignores that one party may be trusted for several things, and keying by text would report rewrites as changes. Six difference types, with cut-off movement reported separately as a seventh condition that is not a difference in the base, because a base that appears to have shrunk may only have been cut higher.
• The deprecated-algorithm question turns on a distinction the word conflates. Deprecation is a statement about future use, not a finding that a past seal was forged. What matters is whether a reviewer can place the record, unchanged, before forging became practical, which is a question about seal time and therefore about AEF 1100 threat 10.3. Where seal time is anchored outside the operator and the anchor precedes the deprecation, the qualification is bounded. Where it is not, the qualification is corrosive. The first case is currently unreachable because AEF 1400 does not exist, and the document states that rather than implying otherwise.
• Trust anchors must come from a source the reviewer designates and must never be taken from the aer. An anchor supplied by the operator makes the check circular: the operator provides both the claim and the standard it is measured against.
• Verifier provenance is required and its limit is stated. Independent obtainability and a reproducible build let a reviewer confirm the binary matches published source. They establish nothing about whether the source is correct, which is AEF 1100 threat 9.1 and belongs to AEF 1201. Any reading in which provenance closes that threat is a misreading, and it is a tempting one because reproducible builds are treated as a sufficiency claim in adjacent fields.
• Two findings are recorded for AEF 1100 rather than applied here, because an analysis suggesting a threat is better defended than 1100 concluded requires a revision there. Threat 9.3 becomes detectable by a reviewer who compares the verifier identity in the result against an independently obtainable one, which is the shape of CONDITIONAL rather than CONCEDED. Threat 9.4's stated basis, that no verification result records the trust base, is stale now that AEF 1101 section 11 requires it and V1 binds it.
• Section 14 classifies every requirement by where its observer sits, applying AEF 1101 section 16's finding that requirements on artifacts have observers and requirements on judgment do not. Three are checkable by inspecting the verifier, twenty-seven by inspecting its output, eleven only by running it against fixtures, and one is not checkable at all. Thirty of forty-two need nothing run, which is what the document was aiming for.
• Section 17 names the largest defect: qualification completeness has no observer. A verifier that silently omits a qualification produces output indistinguishable from one examining a record where the condition did not hold. That is AEF 1100 threat 6.3 relocated to the verifier.
• Section 18 adds to AEF 1101 section 14's running list. The reference implementation satisfies V8 and V9, the seal integrity check that is the framework's core, and fails every requirement concerning the verification result as an artifact because it emits no conformant result at all. Two failures are newly surfaced: it takes trust anchors from operator-controlled configuration, and its output uses "verified" as a bare result label, which is the exact overstatement section 13 exists to prevent.
• Section 20 records a question the writing surfaced and no document owns: whether a verification result should itself be sealed and attributable, since it carries an outcome, qualifications, and a trust base, and nothing currently makes it tamper-evident.

AEF 1101 v0.1, 11 August 2026#

• First draft of the trust base document, the fourth in the series and the second in the 1100 block. Partially normative: sections 6, 7, 10, 11, and 12 carry requirements, and each requirement states whether it binds an implementation, a trust base statement, or a verification result.
• Five questions were deferred here by three documents. Four are settled, one is settled by replacement, and none is deferred again.
• Individuation is by party, not by component. A dependency is a party who could cause verification to accept a record it should reject. The reviewer's question is who can lie to me, and a list of libraries answers a question nobody asked. This rules out both failure modes at once: one line naming the platform fails because a platform is several parties, and four hundred lines of components fails because it names no parties at all.
• Composition is the transitive closure of parties with a declared cut-off, not the frontier. A frontier reading would let an operator name its immediate dependency and conceal the chain, which is AEF 1100 threat 7.1 at the level of trust. The closure does not terminate, so the cut is declared and completeness is assessed against the declaration, which is AEF 1000 principle 3 applied to the trust base.
• Externality is three separate tests rather than one flag: whether the operator can alter the assertion, whether it can cause the assertion to be withdrawn, and whether a reviewer can obtain the assertion without the operator. Most real dependencies pass the first and fail one of the others, and a statement collapsing them to a single yes or no has not done the analysis.
• Irreducibility is settled by concluding it cannot be claimed. It is a negative existential over the literature: to assert a base is irreducible is to assert no construction exists anywhere that removes one of its parties, which nobody can establish at any date. Reducibility is provable by exhibiting a construction; irreducibility is provable by nothing. A reduction statement replaces it, recording for each dependency whether a known construction would remove it and why it was not used, which is checkable by inspection and falsifiable by a reviewer who knows a construction the author did not cite. AEF 1000 principle 2 was right to drop minimality and did not go far enough.
• Establishing a key is partially settled. Identity requires an assertion by a party other than the operator plus a mechanism by which that party's equivocation is detectable. PKI supplies the assertion alone, Certificate Transparency adds discoverability, key transparency adds detection of equivocation, and out-of-band pinning removes the third party entirely. Which mechanism an implementation must use is not settled, because it depends on what a given reviewer can reach.
• Key history requirements are stated. Append-only public logs are the best current option and not the answer: they trade an undetectable failure for a detectable one, which is the real argument, while adding the log operator and a monitoring party as dependencies and making availability a liveness dependency.
• Section 11 answers AEF 1100 threat 9.4. A verification result must record the trust base in force, and one that omits it is not conformant. This is the most concrete deliverable in the document because it needs no new infrastructure.
• Section 12 distinguishes a record that no longer verifies from a record whose verification is no longer meaningful. The second is the dangerous case, because the verifier reports success while a dependency has been withdrawn or weakened.
• Section 13 states the reference implementation's own trust base as a worked example: ten parties, five external under all three tests, three external under none, two with controlling parties the editor has not yet named. Section 14 lists the four requirements in this document that the reference implementation currently fails.
• The markdown renderer gained pipe table support for section 13, with five tests including a pipe block with no separator row falling back to paragraphs rather than being dropped.

AEF 1100 v0.2, 11 August 2026#

• Restructured every threat entry to carry labelled fields, so the analysis reads as prose and parses as data without the two diverging. Fields are Action, Actor, Detection, Depends on, Residual risk, Forward, and Disposition. The prose renders as it did; the labels are the same bold-lead convention v0.1 already used, made uniform.
• Made CONDITIONAL a first-class disposition rather than a prose aside. v0.1 labelled nine entries "IN SCOPE ... CONCEDED otherwise" while section 15 counted them separately, so the entries and the summary disagreed. Every conditional entry now states its condition explicitly, and the parser rejects a conditional disposition that omits one. Counts are unchanged at one, nine, eleven, and two.
• Dependencies became lists, one per trust dependency, each stated with what fails if it is misplaced. The parser rejects a dependency with no failure clause, on the grounds that AEF 1000 principle 2 requires one. That check found nothing wrong in the shipped text, which is the outcome a control should have on the first run and not the outcome that proves it works.
• Four Actor fields carried justification clauses rather than clean values, which the matrix exposed as unreadable columns. The justifications moved to commentary paragraphs within the same entries. This is a case of a display surfacing a defect in the source, which is the argument for building the two from one text.
• The analysis is now published as structured data at /aef/1100/threats.json, with per-threat anchors so a consumer can link back into the prose.
• v0.1 is retained at /aef/1100/v0.1.

AEF 1100 v0.1, 11 August 2026#

• First draft of the threat model, the third document in the series and the first in the 1100 block. AEF 1000 section 4 named seven adversary capabilities in a paragraph and pointed here; this is the analysis, covering twenty-three threats against the record, the boundary, the approval, the verifier, and keys and time.
• The primary adversary is the operator, which is unusual and is the framework's central assumption following AEF 1000 principle 2. A requirement that verification not depend on the operator only means something if the operator is the party whose account is in question.
• Seal time is the boundary between what the framework defends and what it concedes. Before seal, the operator can suppress, delete, truncate, and reorder without leaving a trace. After seal, alteration is detectable. The framework does not make an operator honest; it converts the operator's freedom from unlimited and invisible into bounded and dated.
• Three threats were surfaced by the analysis and were not in AEF 1000's list. Seal-time delay: nothing bounds the interval between capture and seal, so an operator has one lever that widens the entire pre-seal defeat surface. Trust base substitution: a verification result does not record the trust base in force, so verification time is evidence of less than AEF 1001 claims. Key rotation as repudiation: where the key history is the operator's, rotation becomes a way to selectively unmake past attestations.
• Scope amendment after execution is the most consequential finding. AEF 1001 chose declaration over structural boundaries because a declaration made before execution cannot be shaped by an outcome not yet known. Nothing currently establishes that a declaration preceded execution, so that defense is an unchecked assertion in the ordinary case.
• Counting is stated honestly rather than favorably. Of twenty-three threats, one is defended by what exists today, nine are defended conditionally on mechanisms that are on the roadmap and unwritten, eleven are conceded outright, and two are out of scope.
• Section 12 consolidates every concession so a reviewer can read the defeat surface without assembling it. Section 13 states the honest floor: the sentence a reviewer could safely put in a report, and the six sentences they could not.
• Section 16 records four terms used here that AEF 1001 does not define: capturing system, external index, time source, and key history. All four are referenced by AEF 1000 and defined nowhere. They belong in AEF 1001's next version.
• Section 17 applies the same no-observer audit used on the charter to this document, and finds five detections that nobody is designated to perform.

AEF 1001 v0.1, 11 August 2026#

• First draft of the terminology document, the second in the series. Defines thirty-two terms across core objects, roles, properties, and time, all derived from AEF 1000.
• Took a position on the run boundary, which is the most consequential definition in the document because completeness is asserted against it. A run is bounded by operator declaration made before execution, not by invocation, session, task, or transaction. Structural boundaries were rejected because each is defeated by re-architecting: split work across three invocations and each is complete while the work is described nowhere. The cost is stated rather than hidden, since declaration lets an operator draw the boundary to exclude inconvenient work. What declaration buys is that the omission becomes a dated, attributable claim a reviewer can reject.
• Distinguished attested from logging, signing, and certification, and added a fourth distinction that matters more: attested in AEF does not mean an independent practitioner examined the subject matter and expressed an opinion, which is what the word denotes in professional assurance practice. An aer carries the operator's and signer's own assertions, sealed. Whether an aer can serve as subject matter for a professional engagement is an open question with no document number yet.
• Resolved the verifier's reflexive problem by locating its evidence in behavior rather than source, following AEF 1000 principle 4. Reading the source establishes intent; watching it reject what it should reject establishes operation.
• Named the role combinations that destroy evidentiary value, including one the framework has itself: the author of AEF also writes its reference implementation, so the verifier has no adversary in its history.
• Section 12 lists every term defined here that does not appear verbatim in AEF 1000, with what required it, so drift from the charter stays visible.
• Eight open questions recorded, each assigned to a numbered document except the professional attestation question, which needs a number in the 1300s.

v0.3, 11 August 2026#

Three fixes from the v0.2 weakness check, then AEF 1000 freezes.

• Principle 2, revised for the second consecutive version. The reasoning is worth following, because each fix corrected the previous one's error rather than the original problem. v0.1 required verification by someone who trusts neither the operator nor the system that produced the record. That was wrong: it demanded zero trust, which nothing satisfies. v0.2 replaced it with a trust base that must be "enumerated, external to the operator, and minimal," which fixed the wrong half. Enumeration and externality are checkable by inspection. Minimality is not: any objection that a record trusts too much is answerable with "that is the minimum for this design," and no test settles it. v0.2 therefore traded an unsatisfiable requirement for an unfalsifiable one, which is not obviously an improvement. v0.3 keeps enumeration and externality, replaces minimality with a requirement that each dependency be stated together with what fails if that trust is misplaced, and assigns irreducibility to AEF 1101. The new half is checkable in one pass: either the failure consequence is written down or it is not.
• The same principle was also out of shape and had silently lost a requirement. The first v0.3 draft ran to six consequence sentences where every other principle runs to two, and the rewrite that removed "minimal" dropped "external to the operator" along with it, since both sat in the same clause. Externality is restored and the principle is back to four sentences. The regression is recorded here rather than quietly corrected, because a change record that only lists intended changes is a worse record.
• Section 2 was rebuilt around a counterexample search, which the v0.2 weakness check identified as the document's own evidentiary failure: it argued a pattern from confirming cases only, in the problem statement of a framework built to prevent exactly that. Nine domains were examined, and the search weakened the original claim rather than confirming it. "Every prior class of consequential automated work acquires an evidence requirement" is false. Algorithmic content moderation and ranking acquired no US requirement and only a 2024 EU audit regime whose first cycle produced one negative opinion and four disclaimers of opinion across nineteen platforms. Automated hiring had standing from 1964 and adverse impact guidelines from 1978, got a concrete audit requirement only in 2023, and the New York State Comptroller found its enforcement ineffective in December 2025. Automated claims adjudication acquired nothing, and production was eventually compelled by one magistrate in 2026.
• The standing hypothesis that replaced the universal claim did not survive intact either, and two domains added in this pass are why. Industrial control systems are a controlled comparison: the same SCADA technology carries mandatory, enforceable standards on the bulk electric system from July 2008, with penalties up to a million dollars per violation per day and a ten million dollar settlement against Duke Energy in 2019, and carries guidance with no comparable enforcement on municipal water systems. Same technology, same severity, different examination authority, opposite outcome, which is the strongest single piece of evidence in the set because it holds technology constant. Algorithmic trading cuts against standing: the Securities and Exchange Commission had complete standing and examination authority throughout, adopted the Consolidated Audit Trail rule in 2012, and the self-regulatory organizations represented the system as fully implemented only in July 2024. Standing was never the missing ingredient there; collective build cost was.
• The discriminator now has three conditions rather than one: a party must be able to detect that something went wrong, must be able to compel production, and production must cost less than the harm. Each counterexample fails a different one. Hiring and claims fail detection. Content moderation fails compulsion. The Consolidated Audit Trail failed cost for twelve years with the other two satisfied. Ad measurement is the positive control: advertisers had no statute and no regulator, and manufactured compulsion contractually by making accredited measurement a precondition of payment.
• The third condition changed what the charter claims about itself. Standing and detection arrive from outside and cannot be engineered. Production cost can be, so section 2 now states that lowering it is the framework's actual job, and that where harm is diffuse and undetectable the framework predicts its own non-adoption.
• Section 12's falsification condition was replaced twice. v0.2 said the premise fails if agent work is the first consequential automation never to acquire a requirement, which was the wrong test, since the pattern was never universal. The interim v0.3 wording tested a two-part discriminator that the trading and SCADA research then superseded. It now tests all three conditions, and adds the test that matters most for the framework's own thesis: whether cheap evidence gets demanded more often than expensive evidence.
• Section 11 made dormancy declared rather than inferred. v0.2 stated a condition, eighteen months without a release plus ninety days of editor silence, and then designated nobody to determine that it had been met, recorded the determination nowhere, and said nothing about an editor who reappears and disputes it. Two parties could hold incompatible views about whether the framework was dormant with neither shown wrong, which is a governance clause failing the framework's own principle about defined referents, inside the one section written to reassure a reader who expects the author to disappear.
• What replaced it produces a record instead of an opinion. A dormancy notice is opened as an issue in the public repository and must state the date filed, the most recent release the filer can find, and the basis for the claim, because a notice a reader cannot check is not a notice. It opens a ninety-day window, chosen to outlast an ordinary absence without leaving a framework abandoned while everyone waits to be sure. A substantive editor response in the repository within the window closes it; silence completes it, and dormancy runs from the date the window closed. Withdrawn notices stay in the record marked withdrawn rather than deleted, on the same reasoning that keeps superseded versions readable. If the editor reappears after completion, the fork stands, both lines may exist, and the original editor cannot unwind good-faith work or revoke what CC BY 4.0 already granted.
• Section 9 records the freeze. AEF 1000 now changes only for cross-references and errata.

v0.2, 11 August 2026#

• Renamed to the Attested Execution Framework (AEF). The framework and its artifact are now separate nouns: AEF is the framework, an attested execution record (aer) is the thing a run produces. v0.1 used one name for both, which left no word for the doctrine about sufficiency, custody, and signature meaning.
• Adopted numbered documents in blocks, starting with this charter as AEF 1000, and named eight documents that are committed but unwritten. A numbered document is a commitment; an unnumbered one is an intention.
• Rewrote principle 2. v0.1 demanded verification by someone who trusts neither the operator nor the producing system, which demands zero trust and is unsatisfiable, since every chain terminates in a key, a root of trust, a time source, a compiler, or silicon. It now requires independence from the operator plus a declared, external, minimal trust base.
• Merged principles 3 and 5 into one. v0.1 asserted that absence of a record is a finding without supplying a boundary, which made it untestable, and then supplied the boundary one entry later without acknowledging the dependency. Six principles remain.
• Rebuilt section 2's premise. v0.1 predicted that someone would demand proof and defended it nowhere. v0.2 argues from three documented precedents where consequential automated work acquired an evidence requirement after a failure, and states the inference as an inference.
• Added an adversary subsection under Scope, naming which attacks an aer survives and which it does not. An evidence standard without a threat model was the largest hole in v0.1.
• Added section 11, Governance: author versus editor, transfer of the editor seat, stewardship intent, an eighteen-month dormancy clause, the fork right stated affirmatively, and the employer non-involvement statement moved here from section 1.
• Cut two repetitions: the publication cadence appeared in both sections 1 and 9, and the certification disclaimer appeared in both sections 8 and 11.

v0.1, 11 August 2026#

• First public draft, published as Assay. Twelve sections, seven principles, no threat model, no governance section, no numbered series.
• This version is titled Assay throughout, and it is not retitled, because superseded versions are not rewritten in place. The framework was renamed to the Attested Execution Framework in v0.2; the reason is in that entry. A reader who arrives at v0.1 and finds a different name on it has arrived at the right document.
• Earlier working name during drafting: AER, Attested Execution Record.