AEF 1001: Terminology

1. Status#

AEF 1001 v0.1 is an early draft and will change. It is the second document in the series and the first after the charter.

AEF 1000 is the source of authority for everything here. Every term below appears in 1000 or is directly required by something 1000 says, and section 12 lists the terms that do not appear verbatim along with what required them. Where a definition would need an assertion 1000 does not make, this document says so and points forward to the document that will make it, rather than introducing doctrine under cover of a definition.

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

2. Why this document exists#

A framework whose central words are undefined cannot be conformed to or disputed. Two parties can satisfy and violate the same requirement while both reading it correctly, and neither can be shown wrong, because the disagreement is about what the words denote rather than about what happened. That failure is invisible in ordinary use and appears only under pressure, which is exactly when the framework is supposed to work. Definitions are what make disagreement productive: once the terms are fixed, an argument about a record becomes an argument about facts.

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.

This document is almost entirely non-normative. Definitions constrain meaning; requirements live in later documents. Where a normative keyword appears below, it constrains how a term is used rather than what an implementation must do. An implementation cannot conform to AEF 1001, because there is nothing here to conform to. It can only use the vocabulary correctly or incorrectly.

4. Scope of these definitions#

These definitions govern the AEF series. They are not claims about how the words are used elsewhere, and a term defined here may mean something different and equally correct in another field. Where that risk is material, the entry says so.

Terms are ordered so that no definition depends on a term defined later, with one exception stated openly: run and declared scope are mutually dependent, and neither can be given first. Section 5.1 defines them as a pair.

5. What this document is not#

It is not a glossary of AI or agent terminology in general, and it does not define agent, model, tool, or autonomy. It is not a taxonomy of agent architectures. It does not define terms other standards already own.

Where a term belongs to another standard, this series uses it in that standard's sense and does not restate it. Cryptographic hash and digital signature are used in the sense of the NIST Federal Information Processing Standards, FIPS 180-4 and FIPS 202 for hash functions and FIPS 186-5 for digital signatures. Root of trust is used in the sense of NIST SP 800-193. Naming these is a reference, not an adoption of any wider requirement from them.

6. Core objects#

6.1 Run and declared scope (mutually dependent)#

These two cannot be ordered. A run is delimited by its declared scope, and a declared scope is a statement about a run. Defining either first would smuggle the other in, so both are given here and the circularity is broken by the ordering of events rather than the ordering of words: the declaration is made first, and the run is what then happens inside it.

Run. A discrete unit of agent-executed work whose boundary the operator declares before execution begins.

The position this takes, and its cost: the boundary of a run is set by declaration, not by any structural feature such as an invocation, a session, a conversation, a task, or a transaction. Structural boundaries were rejected because each is defeated by re-architecting. Split one piece of work across three invocations and each invocation is complete, while the work is not described anywhere. Declaration cannot be defeated that way, because the boundary is written down and attributable.

What declaration costs is real and is not hidden here. The operator chooses the boundary, so the operator can draw it to exclude inconvenient work. Declaration does not prevent that. It makes it visible, dated, and attributable to whoever declared it, which converts a silent omission into a stated claim a reviewer can reject. A reviewer MAY find a declared boundary inadequate to the question being asked, and the framework does not make that judgment for them.

The declaration MUST precede execution. A boundary drawn after the outcome is known is shaped by the outcome, which AEF 1000 principle 5 forbids.

Not: a run is not a session, not a conversation, and not a billing unit. It is not the same as the agent's internal control flow, and one run MAY contain many model invocations.

Derives from AEF 1000 section 4 and principles 3 and 5. Whether a declared boundary can be tested for adequacy rather than merely rejected is unsettled; AEF 1300 will address it.

Declared scope. The statement, made before execution, of what a run's record will cover and what it will not.

Not: declared scope is not the agent's permission surface. Permissions describe what could be touched; declared scope describes what the record accounts for. The two can differ in both directions.

Derives from AEF 1000 section 4 and principle 3.

6.2 Run boundary#

Run boundary. The limit set by a declared scope, expressed so a reader can determine whether a given act falls inside or outside it.

Derives from AEF 1000 principle 3, which requires completeness to be assessed against a stated boundary. AEF 1300 will settle what makes a boundary expression adequate.

6.3 Act log#

Act log. The ordered record of instructions received, tools invoked, and effects produced during a run.

Not: an act log is not application telemetry. Telemetry is written for whoever is debugging the system and is complete only where somebody instrumented it. An act log is written against a declared scope and is incomplete in a way that is detectable.

Derives from AEF 1000 sections 1 and 4.

6.4 Input state#

Input state. What the agent was given and what it read during a run, identified by cryptographic hash where the content is retained and by reference where it is not.

Derives from AEF 1000 section 4. AEF 1300 will settle what a reference must contain when content is not retained.

6.5 Output artifact#

Output artifact. A thing the run produced or changed, bound to the record by cryptographic hash.

Derives from AEF 1000 section 4.

6.6 Permission surface#

Permission surface. What the agent was authorized to touch during a run, recorded separately from what it did touch.

Not: the permission surface is not a record of access. It is the boundary of possible access, and its evidentiary value comes from the gap between it and the act log.

Derives from AEF 1000 section 4.

6.7 Approval record#

Approval record. The record of who approved a run, at what time, and what was in front of them at the moment of approval.

Not: an approval record is not a record that approval occurred. That is the weaker claim most sign-off produces today. The referent, meaning what the approver was shown, is what makes the approval mean anything.

Derives from AEF 1000 section 4 and principle 6. Whether a recorded referent can be checked against what was actually rendered to the approver is unsettled; AEF 1301 will address it.

6.8 Seal#

Seal. The operation that closes a record to further change and binds its contents to a key, and by extension the artifact that operation produces.

Not: sealing is not encryption and does not make a record confidential. It makes later alteration detectable, which is a different property and is the only one AEF requires.

Derives from AEF 1000 section 4.

6.9 Key binding#

Key binding. The statement of which key sealed a record and how that key is established as belonging to whom it is claimed to belong to.

The second half is the part that does work. A signature verified against a key nobody can attribute establishes only that the same key was used twice.

Derives from AEF 1000 section 4 and principle 2. AEF 1101 will settle what establishing a key requires.

6.10 Attested execution record (aer)#

Attested execution record, abbreviated aer. The sealed evidence produced by one run: its declared scope, act log, input state, output artifacts, permission surface, approval record, and key binding, taken together.

The term is written lowercase and used as a generic noun, as in "ship the aer with the run." AEF is the framework; an aer is the artifact the framework defines.

Derives from AEF 1000 section 4.

6.11 Verifier#

Verifier. A program that checks an aer against the framework's requirements without recourse to the operator, and reports whether the record holds.

A verifier is both a component of an implementation and an artifact of the framework, which raises the obvious problem that the verifier is itself a thing requiring evidence. The position taken here is that a verifier's evidence is its behavior, not its source. A verifier is credible to the extent that it has been shown to reject records it ought to reject, which follows directly from AEF 1000 principle 4: a verifier that has never rejected a tampered record verifies nothing. Reading the source establishes intent. Watching it fail establishes operation.

Not: a verifier is not an authority. It reports; it does not certify, and its output is evidence a reviewer weighs rather than a conclusion a reviewer must accept.

Derives from AEF 1000 section 4 and principle 4. AEF 1200 will state what a verifier must check, and AEF 1201 will state how a verifier demonstrates that it does.

6.12 Golden fixture#

Golden fixture. A pinned pair of input and expected verifier output, retained so that any change in verifier behavior becomes visible as a difference rather than a surprise.

A fixture set MUST include inputs that are required to fail. A suite of inputs that all pass demonstrates only that the verifier accepts things.

Derives from AEF 1000 section 1 and principle 4.

7. Roles#

Roles are functions, not job titles. One person or organization MAY hold several, and holding several is normal rather than suspect. What matters is which combinations remove the independence a record depends on, and that the aer records which combination applied.

Operator. The party that runs the agent, controls the systems that produced the record, and publishes the aer.

Implementer. The party that builds a system producing aers, or builds a verifier. The implementer and the operator are frequently the same party and frequently are not.

Approving signer. The party who approves a run and whose name goes on it. AEF 1000 calls this role the accountable signer in section 6 and the approver in section 4; both refer to this role, and this document uses one name for it.

Reviewer. The party who examines an aer in order to disbelieve it efficiently: an auditor, a regulator, a counterparty, an opposing expert, or an internal quality function.

Editor. The party who holds the seat that cuts releases of AEF documents and rules on objections. The editor is a role in the framework, not in a run, and never appears in an aer.

7.1 Combinations that destroy evidentiary value#

Operator and reviewer held by the same party destroys it. AEF 1000 principle 2 requires that verification not depend on the operator. A reviewer who is the operator is not performing verification in the sense the framework uses, whatever the quality of the work.

Operator and approving signer held by the same party collapses the approval. The charter's adversary list records that collusion with the approver is not survived, and where the two roles are one party, collusion is not a risk but a structural fact. The approval then attests only that the operator asserted something to itself. This combination is permitted, common, and MUST be visible in the aer, because a reviewer who cannot see it will read the approval as independent when it is not.

Implementer of the agent system and author of the verifier held by the same party weakens principle 4. The verifier is supposed to be a hostile target. A verifier written by the party whose work it checks has no adversary in its history. This is a disclosure obligation rather than a prohibition. The framework currently has this property itself: the author of AEF also writes its reference implementation.

Derives from AEF 1000 sections 4, 6, 8 and principles 2, 4, 6.

8. Properties and predicates#

Trust dependency. A single thing verification relies on that verification cannot itself establish: a key, a root of trust, a time source, a compiler, a piece of hardware.

Trust base. The complete set of trust dependencies a given verification relies on.

Derives from AEF 1000 principle 2. Whether a trust base is irreducible is not settled here or in 1000; AEF 1101 will address it.

Attested. Of a record: carrying an identified party's assertion about a defined subject at a defined time, sealed so a reviewer can check the assertion against the record without asking the asserting party anything.

Three neighbors are wrong, and all three are close enough to cause real harm.

Not logging. A log is a record made for whoever operates the system. It asserts nothing to anyone and is addressed to no reader outside the operator.

Not merely signing. A signature binds a record to a key. It establishes who, and it establishes that the bytes have not changed. It does not establish that anyone asserted anything about what the bytes mean.

Not certification. Certification is a third party's ongoing warrant about a subject, usually renewable and usually conferring status. AEF 1000 section 11 is explicit that there is no certification body, no registry, and no fee.

One further distinction matters more than the other three, because it will mislead the audience most able to use this framework. Attested in AEF does not mean that an independent practitioner has examined the subject matter and expressed an opinion on it, which is what the word denotes in professional assurance practice. An aer carries the operator's and the signer's assertions, sealed. Whether an aer can serve as subject matter for a professional attestation engagement is a genuine and separate question, and this document does not answer it. It is listed in section 11.

Derives from AEF 1000 sections 4, 8, 11 and principle 6.

Sealed. Of a record: closed to further change and bound to a key, such that later alteration is detectable by a verifier.

Complete. Of a record: containing everything its declared scope says it contains. Completeness is meaningful only against that declaration, and a record with no declared scope is neither complete nor incomplete, because the word has nothing to be tested against.

Completeness is a claim the record makes about itself. A verifier can test it for internal consistency against the declaration. Nothing in the framework establishes that the declaration was honestly drawn, and AEF 1000's adversary list concedes the mechanism: an event never emitted leaves nothing to detect. Completeness therefore MUST NOT be read as a claim that nothing was omitted from the run, only that nothing was omitted from what the operator said the record would cover.

Derives from AEF 1000 section 4 and principle 3. AEF 1100 will state what suppression at the source defeats.

Verifiable. Of a record: checkable by a party who trusts neither the operator nor the system that produced the record, given a trust base that is external to the operator, enumerated, and stated together with what fails if each dependency is misplaced.

Not: verifiable does not mean checkable with no trust at all. AEF 1000 principle 2 states plainly that zero trust is unavailable and that a framework demanding it would be unimplementable.

Derives from AEF 1000 principle 2.

Conformant. Of a record or an implementation: satisfying the requirements of a named AEF document at a named version.

Conformance is always to a document and a version, never to the framework at large. A claim to be AEF-conformant without naming both is not a claim that can be checked. Conformance is asserted by an operator and tested by a reviewer, and no body confers it.

Derives from AEF 1000 sections 5, 8 and 11. AEF 1201 will state how conformance is demonstrated, which is why no conformance claim is testable yet.

Superseded. Of a version of a document: replaced by a later version, and retained at its original path with its original content unchanged.

Not: superseded does not mean withdrawn, wrong, or unavailable. A superseded version remains the correct target for a citation that named it.

Derives from AEF 1000 sections 1 and 11.

9. Time#

These are five different moments. Conflating any two of them is a class of error rather than an instance, so each is defined here against what it is evidence of.

Capture time. When an act was recorded by the capturing system. Evidence of when the system observed the act, and of nothing about whether the act was recorded faithfully.

Seal time. When the record was closed and bound to a key. Evidence of the latest moment at which the contents could have been altered without detection. The interval between capture time and seal time is the window in which suppression is undetectable, which is why the two MUST NOT be treated as one.

Approval time. When the approving signer asserted. Evidence of when a party took responsibility, and, read against the approval record's referent, of what they had in front of them when they did.

Verification time. When a verifier checked the record. Evidence that the record verified at that moment under the trust base then in force. It is evidence of nothing later. A record that verified in 2027 has not thereby verified in 2031.

Re-verification. A verification performed later than the first, particularly after key rotation or a change in the trust base. Evidence that the record still holds under the trust base in force at the later time.

Every one of these times is asserted by some clock, and is worth exactly what that clock is worth. AEF 1000's adversary list records that backdating is survived only against a time source the operator does not control. AEF 1400 will state what a time source must be.

Derives from AEF 1000 section 4 and principles 5 and 6.

10. What this document does not settle#

Nothing here is a requirement, so nothing here can be violated. The definitions constrain what later documents can mean when they impose requirements, and the requirements themselves are in those documents.

11. Open questions#

Each of these is a term this document could not settle cleanly, with the document that will settle it.

1. Adequacy of a declared run boundary. A reviewer may reject a boundary as too narrow. Nothing states what makes one adequate, so rejection is currently a matter of judgment with no criteria. AEF 1300.
2. Reference form for unretained input state. When content is not retained, what a reference must contain to be checkable later is unspecified. AEF 1300.
3. Checking an approval referent. Whether what the approval record says the signer saw can be checked against what was actually rendered. AEF 1301.
4. Establishing a key. What it takes for a key binding to establish identity rather than continuity of use. AEF 1101.
5. Irreducibility of a trust base. Whether a trust base is as small as it could be, which AEF 1000 principle 2 explicitly declines to require because it cannot yet be tested. AEF 1101.
6. Demonstrating conformance. No conformance claim is testable until this exists, which means the word conformant is currently defined and unusable. AEF 1201.
7. Time source requirements. What a time source outside the operator's control must be. AEF 1400.
8. An aer as subject matter for a professional attestation engagement. Whether, and under what conditions, a record defined by this framework can be the subject matter another party opines on. This has no number assigned. It belongs in the 1300s, and assigning it is a cross-reference change to AEF 1000 section 9, which the freeze in that section permits.

12. Terms defined here that do not appear in AEF 1000#

Listed so that drift from the charter is visible rather than gradual.

• Approving signer. AEF 1000 uses accountable signer in section 6 and approver in section 4 for the same role. This document picks one name and records both.
• Implementer. AEF 1000 refers to the reference implementation, to vendor-specific implementation, and to two independent conformant implementations, but never names the party that builds them. Section 11 of the charter requires the role to exist in order for its stewardship trigger to fire.
• Run boundary. AEF 1000 principle 3 requires completeness against a stated boundary without naming the boundary as a thing.
• Capture time, seal time, approval time, verification time. AEF 1000 section 4 names capture, sealing, and verification as lifecycle stages and requires the approval record to state when. The moments are required; the names are not in the charter.

No other term below appears without support in AEF 1000.

13. License and citation#

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

Cite as:

Stellmacher, G. (2026). AEF 1001: Terminology, v0.1. 11 August 2026. https://grantstell.com/aef/1001

Cite the version and date, always.