AEF 1301: Approval and Signature Semantics

1. Status#

AEF 1301 v0.1 is an early draft and will change. It is the ninth document in the series and the second in the 1300 block.

This document is normative throughout. Its requirements bind an approval record, an acceptance envelope, and an implementation that produces either. Requirements on what a verifier does with them belong to AEF 1200, and every check this document needs is recorded in section 16 as a finding for AEF 1200 v0.2 rather than imposed here; the reference verifier implements the proposed checks now so that pinned fixtures can exercise them, which is the discipline AEF 1201 section 15 finding 1 taught: state every check over supplied data, never over liveness.

AEF 1000 is the source of authority. AEF 1001 supplies the vocabulary, used exactly and not redefined. AEF 1100 supplies the threat analysis, cited by threat id. AEF 1101, AEF 1200, AEF 1300, and AEF 1201 are cited by section and requirement id.

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

2. Why this document exists#

AEF 1000 principle 6 holds that a signature requires a defined referent, and that most sign-off on agent work fails this today. AEF 1001 section 6.7 sharpened it: an approval record is not a record that approval occurred, and the referent, meaning what the approver was shown, is what makes the approval mean anything. Then AEF 1100 conceded all three approval threats outright: the approver shown a different referent than the record claims (8.1), collusion between operator and approving signer (8.2), and approval routed to a party without standing or knowledge (8.3). AEF 1300 R24 gave the approval record three members and no semantics, and AEF 1201 section 14 found that `approval-form` had no failing fixture of any kind, so a verifier that never implemented the approval check passed the reference suite.

This document does not get to un-concede anything by assertion, and does not try. Its job is narrower: make each concession bounded, visible, and as small as an artifact can make it, and say plainly which residue is structural. The instrument for all three is the same one the series always reaches for, converting an unprovable property into a checkable claim: the approval states exactly what it asserts, binds exactly what it was shown, and discloses exactly who signed relative to who ran, so that what remains unknowable is unknowable on the record rather than by omission.

3. Normative language#

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174, and only when they appear in all capitals.

Requirements are numbered A1 through A15 and are collected with their classification in section 14. The numbering is stable within a version.

4. What this document owes the series#

AEF 1001 open question 3, whether a recorded approval referent can be checked against what was actually rendered to the approver. Answered: no, and the no has a shape. Section 8 splits the referent so that the checkable half is checked and the uncheckable half is named. A mismatch between the record's claimed referent and the stored artifact becomes detectable. A mismatch between the stored bytes and what the approver's eyes saw does not, and never will from inside the record. The question closes as narrowed, not solved.

AEF 1001 section 7.1's disclosure obligation, that an operator holding the approver role be visible in the aer, recorded by AEF 1100 section 17 as a MUST with nothing checking it. AEF 1300 R21 gave it a field at the record level. This document gives it an observer at the approval level: A10's relation member, checked for consistency against the role disclosure and against the keys a verifier can see, with the residue stated in section 17.

AEF 1001 section 11's unnumbered question, whether an aer can serve as subject matter for a professional attestation engagement, floating since 11 August. Given a number and a hook. Section 12 states what an aer supplies and lacks, specifies the criteria-reference member, and assigns the remaining question to AEF 1302 with the placement argued.

AEF 1100 threats 8.1, 8.2, 8.3, all CONCEDED. Dispositions after this document, argued in sections 8, 10, and 11 and recorded for AEF 1100 v0.3 in section 16: 8.1 splits, with its artifact half a candidate for CONDITIONAL and its rendering half structural; 8.2 and 8.3 unchanged.

AEF 1200 V27 and V29 and AEF 1201's approval-form gap. Answered by construction: section 15 ships pinned, isolating, required-to-fail fixtures for every approval check, and the reference verifier now fails them for the right reasons.

5. Two kinds of approval#

The series has said approval as if it were one thing. It is two, and conflating them is not a naming problem but an evidence problem, because the two have different referents and different standing under AEF 1000 principle 5: evidence captures what was known at the time.

An authorization is a pre-execution assertion. Its referent can only be what exists before the run: the declared scope, sealed per AEF 1300 R14 before the first act, the permission surface it describes, and the identity of the operator. An authorization cannot attest outcomes, because at authorization time there were none. A party who authorized a run has asserted that the run should happen as declared, and nothing about what then happened.

An acceptance is a post-execution assertion. Its referent is the sealed record, by digest, and where presented, its outputs. An acceptance cannot authorize, because the run already happened; a party who accepted has asserted that they were shown the sealed account and accepted the outcome it describes, and nothing about whether it should have been permitted.

A record carrying one and claiming the semantics of the other is the overstatement failure this series exists to prevent, wearing an approval. An authorization read as acceptance converts a permission into an endorsement of outcomes its signer never saw. An acceptance read as authorization backfills permission onto a run that executed without it, which is exactly the outcome-shaped evidence principle 5 forbids.

A1. Every approval assertion MUST carry a `type` member, either `authorization` or `acceptance`, and the assertions enumerated in section 9 attach by type. An approval without a type is not interpretable and MUST be treated as malformed.

The ordinary case. A run that matters SHOULD carry both: an authorization inside the record, made before the first act, and an acceptance outside it, made after sealing. The two bound the run at both ends, and each is worthless for the other's purpose. A record with neither is unapproved work and says so through APPROVAL-ABSENT and ACCEPTANCE-ABSENT. An acceptance with no authorization is ratification of work nobody permitted, visible as exactly that. An authorization with no acceptance is permission whose outcome nobody has owned.

6. The authorization record#

Requirements in this section bind an approval record carried in an aer.

A2. An approval record inside an aer MUST have type `authorization`. An acceptance MUST NOT be placed inside a record. The exclusion is argued rather than asserted, because a construction exists that looks like an escape: AEF 1300 R6's seal already binds the record minus its own seal member, and an in-record acceptance could bind a record-minus-seal form the same way. What rules it out is what that form is. It is bytes nobody else will ever hold, since what gets published, retained, and re-verified is the sealed record; an acceptance over it accepts an artifact that exists only inside the sealing ceremony. And it forces the acceptance to precede the seal, which reopens AEF 1100 threat 10.4's window exactly as section 7 describes. An acceptance's honest referent is the record as the world will hold it, and that referent exists only after sealing, which puts the acceptance outside.

A3. An authorization MUST carry: `type`; `approvingSigner`, the party asserting, named as the role disclosure names them; `approverRelation` per A10; `approvedAt`, a recorded time in AEF 1300 R19's form, with its source named per AEF 1001 section 9; `referent` and `presented` per section 8; `presentation` per section 8; `keyBinding`, in AEF 1300 R22's form, identifying the key that seals this authorization; and `seal`, computed over the canonical form of the authorization with its own seal member removed, per AEF 1300 R6's rule applied to this object. It MAY carry `basis` per section 10 and `criteriaRef` per section 12.

The three members AEF 1300 R24 requires keep their names and their meaning. The extension of R24's member set is recorded in section 16 as a finding for AEF 1300 v0.2 rather than performed silently.

A4. An authorization's `referent` MUST equal the record's `declarationSeal`: the digest of the separately sealed declaration envelope. This is the only artifact AEF 1300 defines that exists before execution, which makes it the only thing a pre-execution assertion can honestly bind. An authorization whose referent is anything else authorizes something other than this run's declaration, and the record carrying it contradicts itself.

A5. The authorization's seal MUST verify over its canonical form against the key its own `keyBinding` names. What that verification establishes is what AEF 1101 section 9 says it establishes: continuity of use under mechanism `none`, identity only where an external assertion supplies it, reported honestly in either case. An approver's key binding is subject to the same mechanisms, and the same limits, as the record's.

A6. An authorization's `approvedAt` MUST be no earlier than the sealing of the declaration envelope its referent names, and no later than the earliest `capturedAt` in the act log. Where a verifier does not hold the envelope, the declaration's `declaredAt` is the weaker lower bound the record itself carries, and checking against it is what remains possible. An authorization that predates the sealed declaration bound a digest that did not yet exist; one that postdates the earliest act asserts permission for work already underway, which its type cannot mean. The ordering is internal to the record and is checkable as such; the times themselves are worth what their source is worth, per AEF 1100 threat 10.3, and nothing here upgrades them. Violation is fatal on AEF 1200 V26's precedent, a recorded sequence that is impossible on its own terms, and the rejection set is careless implementations rather than adversaries, which is all an internal ordering can ever catch.

7. The acceptance envelope#

Requirements in this section bind an acceptance envelope.

A7. An acceptance MUST be a separate envelope outside the aer: an object carrying `acceptance`, the assertion, and `seal`, computed over the envelope's canonical form with the seal member removed. It is supplied to a verifier the way artifacts are supplied, because the record cannot reference an artifact that postdates its own seal.

This placement is chosen against two alternatives, both stated. Sealing the record only after acceptance would make seal time wait on a human, and AEF 1100 threat 10.4 already records that every pre-seal concession grows with that window; an implementation that holds records open awaiting approval converts its approval workflow into its tampering window. An in-record acceptance over a record-minus-seal form fails for A2's reasons: it accepts bytes nobody else will ever hold and still forces acceptance before sealing. Sealing first and accepting the sealed thing keeps the window small and gives the acceptance the referent the world will actually hold.

The placement has a cost, and it is the honest headline of this section: nothing in an aer reveals whether an acceptance exists. An operator can obtain an acceptance and withhold it, or never seek one, and the record reads identically. This is AEF 1100 threat 11.1's shape at the scale of one artifact, it is why ACCEPTANCE-ABSENT is a qualification rather than a failure, and no requirement in this document can close it, because the missing thing is an external index, undefined since AEF 1100 section 16 first recorded the term.

A8. An acceptance assertion MUST carry the members A3 lists for an authorization except `seal`, which A7 places on the envelope rather than on the assertion, and with two differences: its `referent` MUST be the digest of the sealed aer, the same identity a verification result binds per AEF 1101 section 11, and its `approvedAt` MUST be no earlier than the record's seal time. The envelope's seal verifies against the key the assertion's own `keyBinding` names, the same self-description the record's seal uses under AEF 1300. An acceptance MAY additionally carry `outputs`, an array of digests for output artifacts presented to the accepting party, each of which MUST appear among the record's output artifact digests; an acceptance naming an output the record does not carry claims a presentation the record contradicts, and the claim is checkable.

8. The referent, precisely#

Requirements in this section bind both approval types.

The referent has two halves, and the split is the position this document takes on AEF 1001 open question 3.

A9. Every approval assertion MUST carry: `referent`, the digest of the artifact approved, bound per A4 or A8; `presented`, the digest of the exact bytes presented to the approver; and `presentation`, an object naming `format`, `tool`, and `toolVersion`, declaring how the referent artifact became the presented bytes. Where the approver was shown the canonical artifact itself, `presented` equals `referent`, and that equality is the strongest claim this structure can carry.

What this converts, stated exactly. AEF 1100 threat 8.1 as written is fully conceded: the approval record states what was in front of the approving signer, and nothing checks it. After A9, the threat splits. The record's claim about the referent is now falsifiable: `referent` binds to an artifact the verifier holds, a `presented` digest that matches nothing retained is visible as unverifiable, and a claimed presentation context is at least a claim with named parts. A mismatch between the record's claimed referent and the stored artifact becomes detectable, which converts that half of 8.1 from fully conceded to bounded.

The honest limit, stated in the same breath. A mismatch between the stored bytes and what the approver's eyes saw does not become detectable, and never will from inside the record. The presentation context narrows the gap without closing it: a declared tool and version lets a reviewer re-render the referent and see what those bytes produce, and nothing establishes that the declared tool was the one actually used, or that its output on the reviewer's screen matches its output on the approver's. Rendering is a function of software, configuration, and a display, and the record captures a name for the first of these. Threat 8.1's rendering half is structural, and section 16 records the disposition delta as a split rather than a discharge.

9. What an approval signature asserts#

Requirements in this section bind an approval record, an acceptance envelope, and how implementations describe either.

A14. An approval signature asserts exactly the following, and nothing else.

For an authorization: that the party named as approving signer, to the strength of the key binding's mechanism per AEF 1101 section 9; at the recorded time, to the strength of the recorded time's source; was presented bytes with the stated `presented` digest, in the stated presentation context; authorized execution of a run bounded by the declaration whose sealed envelope the `referent` names; and held the disclosed relation to the operator.

For an acceptance: the same first three clauses, and then: accepted the sealed record the `referent` names as the account of the run, together with any outputs the `outputs` member names; and held the disclosed relation to the operator.

The list is closed. An approval signature does not assert that the work was correct, that the record is complete beyond its declaration, that the approver understood what they were shown, that the approver was competent or authorized by anyone to approve, that the declared scope was drawn honestly, or that the run should have been permitted. Every one of those is either a concession AEF 1100 carries or a judgment AEF 1000 section 5 places outside the framework, and an approval that appears to carry one of them has been over-read.

A15. A record, an acceptance envelope, and any implementation output describing either MUST NOT describe an approval as verification, review, validation, or endorsement of the work's correctness or of the record's completeness, and MUST NOT use "certified", "guaranteed", "proven", or "assured" of anything an approval establishes. This is AEF 1200 V42's constraint and AEF 1201 C4's, extended to the third artifact that will be read stronger than it is. The closed list in A14 is what an implementation may restate; restating more is non-conformance, not enthusiasm.

10. Standing and competence#

AEF 1100 threat 8.3 is approval routed to a party who cannot meaningfully evaluate the run, and its detection is None: whether the approver was competent or authorized is not in the record and not derivable from it. That disposition does not change here, and this section exists to say what little the record can carry and why it is little.

A12. An approval assertion MAY carry `basis`, free text in which the approver states what their approval rested on. The member is OPTIONAL, checkable as to presence and never as to substance.

Optional is the deliberate part. A required basis with no substance test manufactures boilerplate by the second record, which is the lesson AEF 1300 section 16 already recorded for R11's `reason` member: "Not applicable" satisfies any presence requirement. An absent basis is itself information a reviewer can weigh, in a way a mandatory platitude is not. What a stated basis buys is attributable specificity: an approver who wrote "reviewed the declared scope against the change ticket" has made a claim that can later embarrass them, which is the only enforcement this field will ever have. Threat 8.3 stays CONCEDED, and a reviewer weighing an approval still weighs the approver.

11. Automated approval#

A11. An approval MUST be attributable to a party in AEF 1001 section 7's sense: roles are functions of parties, and a signature requires a signer who can be named, contacted, or held to account. Software is not such a party. An approval produced by a machine under the operator's key is the operator approving, through tooling, and MUST carry relation `operator` per A10; the automation is an implementation detail of the operator's assertion, not a new kind of assertor.

This document does not define an agent-as-approver category, and the refusal is the position. AEF 1000 makes no doctrine under which software holds a role, an agent that approved its own run would collapse AEF 1001 section 7.1's independence analysis into recursion, and a category error written into a schema outlives every caveat attached to it. If agent-held roles ever enter this framework, they enter through AEF 1000's principles, not through a member this document adds.

The disclosure requirement, stated in full:

A10. Every approval assertion MUST carry `approverRelation`, either `operator` or `distinct`. The relation MUST be `operator` where the role disclosure names one party as both operator and approving signer, and MUST be `operator` where the approval's sealing key is the record's sealing key, because one key is one locus of control regardless of what the roles claim. The assertion's `approvingSigner` MUST equal the role disclosure's `approvingSigner`. A record whose relation contradicts its roles or its keys contradicts itself.

What the field does not close. AEF 1100 threat 8.2 is collusion, and disclosure is not defense there; AEF 1100 section 8.2 already says so and this document repeats it rather than improving on it. Beyond collusion, a `distinct` relation under distinct keys establishes distinct keys, not distinct parties: a wholly controlled subsidiary, a contractor paid by the operator, or the operator's second laptop all sign as `distinct` and none is independent. The verifier's honest report for every distinct relation is that independence was not established, and threat 8.2 stays CONCEDED with its boundary now marked from the inside.

12. The aer as subject matter, numbered at last#

AEF 1001 section 11 asked whether an aer can serve as subject matter for a professional attestation engagement, assigned it no number, and the question has floated unassigned ever since. It stops floating here, in two parts.

What an aer now supplies, and lacks, toward examinability. An examination engagement in the sense AEF 1001 section 8 invokes, the sense of professional assurance practice, has a known shape: an assertion by management, stated criteria, evidence testing by an independent practitioner, an opinion, and liability behind it. An aer supplies a sealed assertion with a named asserting party, a declared scope that bounds the subject matter, evidence hash-bound to the assertion, and now, with this document, an approval structure that separates who permitted from who accepted. What it lacks is exactly two of the five parts: stated criteria against which the assertions could be measured, and an independent practitioner with standing to examine and liability behind an opinion. The first is a record gap. The second is not the framework's to supply, per AEF 1000 section 5's boundary around the assurance professions, and no member this series adds can conjure it.

A13. The record gap gets its hook now: an approval assertion MAY carry `criteriaRef`, an object naming `ref`, where stated criteria can be obtained, and `digest`, binding their exact content. The member is OPTIONAL because no document in this series defines what suitable criteria are, and a required pointer to an undefined thing would be a mandatory empty gesture. What it buys today is narrow and real: an approver who approved against stated criteria can bind exactly which ones, and a practitioner arriving later finds the criteria question answered by digest instead of by interview.

The assignment. The remaining question, what an examination over an aer would require and what this framework must and must not say about it, is assigned to AEF 1302. The placement argument: every requirement the question can generate lands on the record and its companions, criteria references, assertion form, the shape of subject matter, which is the 1300 block's jurisdiction; the practitioner's independence, procedures, and opinion belong to the assurance professions and stay out of scope wherever the question lives; and the 1000 block is frozen while the 1900 block is for records about the framework, neither of which can host a specification. AEF 1000 section 9's document list cannot be updated to show 1302, because the charter file is bound by digest into the run-0001 record, per the constraint AEF 1201 section 14 recorded; the assignment is made here and the charter's cross-reference waits for a re-pinning run.

13. What a verifier reports#

Nothing in this section binds a verifier; every check here is a finding for AEF 1200 v0.2, listed in section 16, and implemented in the reference verifier so the fixtures in section 15 exercise real behavior. The proposed checks, named as the implementation names them:

`approval-form`, extended from AEF 1200 V27: an in-record approval carries A3's members and A2's type; malformed or wrongly typed is fatal; absence emits APPROVAL-ABSENT on both branches, because V29's emission obligation is unconditional and stays honored, and is additionally fatal where the declaration states an approval was required, per AEF 1300 R24's `approvalRequired`. The fatal branch diverges from AEF 1200 section 8.7's letter, which says absence is qualified without exception; that text predates the field that makes the requirement expressible, the divergence is filed as challenge-0002 in the challenge record rather than resolved by assertion here, and AEF 1200 v0.2 owns the resolution.

`approval-binding`: the authorization's own seal verifies, and its referent equals the record's `declarationSeal`, per A4 and A5. Fatal, because the record contradicts itself.

`approval-relation`: A10's consistency, against the roles and the visible keys. Contradiction is fatal. A consistent relation is reported with its honest qualification: APPROVAL-IS-SELF-ASSERTION for `operator`, and APPROVER-INDEPENDENCE-NOT-ESTABLISHED for `distinct`, because distinct keys do not establish distinct parties. Where an approval record is present, this check owns the self-assertion class and the role-disclosure reporting does not emit it again, so one condition carries the class once, which the self-approved fixture pins. Neither class is in AEF 1200's registry; both are emitted under OTHER with proposed names and both are listed among section 16's registry candidates.

`approval-timing`: A6's ordering, internal to the record. Violation is fatal as a self-contradiction; the times stay operator-asserted and TIME-OPERATOR-ASSERTED stays emitted.

`acceptance-binding`, where an acceptance envelope is supplied: the envelope's seal verifies, its type is `acceptance`, its referent is the sealed record's digest, its time is not before the seal's, its relation and signer satisfy A10's consistency conditions, which bind every approval assertion and not only the in-record one, and any `outputs` it names appear among the record's output artifacts, per A7, A8, and A10. Failure of any is fatal for the supplied acceptance. Where none is supplied, ACCEPTANCE-ABSENT is qualified, never fatal, per section 7's placement cost.

`PRESENTED-BYTES-UNVERIFIED`, a qualification wherever `presented` differs from `referent` and the presented bytes are not retained: the claim about what the approver saw compares against nothing.

The new qualification classes are emitted under OTHER with proposed names, per AEF 1200 V7's discipline, and each OTHER occurrence remains a finding against AEF 1200's registry.

14. Requirement count and classification#

Fifteen requirements, A1 through A15. By subject: A1, A9, A10, A12, A13, A14 bind every approval assertion; A2 through A6 bind an authorization and the record carrying it; A7 and A8 bind an acceptance envelope; A11 binds an implementation producing approvals; A15 binds records, envelopes, and implementation output.

By observer, applying AEF 1101 section 16's test:

Checkable by inspecting an artifact: twelve. A1 through A10, A12, and A13 are member, digest, enumeration, or ordering rules a program reads off the record, the envelope, or the pair.

Checkable only partially, flagged per the no-observer audit: three. A11's attribution rule is checkable where the machine signs with the operator's key, because A10's key test forces the disclosure, and unobservable where automation runs under a key nominally held by a human who never looked; nothing distinguishes a rubber stamp wired to a pipeline from a person, which section 17 carries. A14's closed list has no artifact vehicle at all: no member exists in which a record states what its signature asserts, so the list constrains readers and implementations rather than bytes, and its enforcement runs entirely through A15. A15's language rule is checkable over the record and envelope fields and binds judgment at its edges exactly as AEF 1200 V42 does; the classification counts it by its stated-terms half, per the discount AEF 1201 section 13 established.

Twelve of fifteen sit on the artifact side, and the three that carry discounts carry them in writing. A14's discount is the largest, and stating it plainly costs less than the alternative, which is a classification that counts a prose constraint as an inspection.

15. Applied immediately#

Everything in this section was produced in the same session as this document, under AEF 1201's suite discipline: pinned inputs, expected outcomes with the failing check named and qualifications pinned by class, a new coverage declaration, and a new suite version. The reference verifier's version moved from 0.1.0 to 0.2.0, because its behavior changed; the run-0001 verification result published on 14 August remains a correct artifact of 0.1.0.

The worked example, published at `/aef/examples/approval-0001/`: a sealed declaration with `approvalRequired` true, an authorization sealed by a distinct approver key before the first captured act, a sealed record carrying it, and an acceptance envelope sealed over the record's digest after its seal time. Verified with the acceptance supplied, the outcome is PASS WITH QUALIFICATIONS, sixteen checks, zero failed, and a twelve-entry qualification set pinned by class in the suite, the first fixture in this series to pin its complete set, closing that gap of AEF 1201 C6 for this input. The set includes APPROVER-INDEPENDENCE-NOT-ESTABLISHED twice, once per assertion: the emission convention is per assertion, following the precedent ELEMENT-UNSUPPORTED set in the same result, because two signed assertions with two referents are two conditions. A second positive fixture pins the self-approved case, operator and approver one party under one key, and pins that APPROVAL-IS-SELF-ASSERTION appears exactly once for it: the relation check owns the class where an approval record is present, and the role-disclosure reporting does not emit it again.

Required to fail, all pinned, each isolating: a referent that is not this record's declaration, failing `approval-binding` alone; a relation declared distinct under the operator's own key, failing `approval-relation` alone; an authorization postdating the first act, failing `approval-timing` alone; an approval with no type, and an acceptance placed inside the record, each failing `approval-form` alone; an approval required by the declaration and absent, failing `approval-form` alone as the only fatal failure, with `declared-elements` reporting the same absence non-fatally, and doubling as challenge-0002's input; an acceptance over some other record's digest, and an acceptance declared distinct under the operator's own key, each failing `acceptance-binding` alone. Eight pinned required-to-fail fixtures in all. With these, every approval check has at least one pinned required-to-fail fixture and at least one isolating fixture, which `approval-form` had never had in any form.

The published example, re-pinned. A new fixture pins run-0001's complete qualification set by class, now eleven entries: the ten verifier 0.1.0 emitted for this input with no artifact root, and ACCEPTANCE-ABSENT, which every verification of every record now carries unless an acceptance is supplied. Four requirements move to asserted by these pinnings: V14, V24, and V29 from the coverage declaration's occurring-unasserted category, and V27 from never-arises, since fixtures now carry approval records in four states. V25 moves to asserted in part, its class pinned and its reported interval still not.

Challenge-0002, filed. The required-and-absent fixture fails where AEF 1200 section 8.7's letter says qualify: "Malformed approval structure is fatal. Absence is qualified," written before AEF 1300 R24 existed and V29 itself recorded the missing field as a dependency. Two honest readings again, the disposition is again unresolved and published, and AEF 1200 v0.2 owns it. Unlike challenge-0001, no reading-independent defect rides along: V29's emission obligation is honored on both branches, and the fixture asserts it.

Challenge-0003, filed against this document's own transition. An approval in AEF 1300 R24's exact three-member form satisfies AEF 1200 V27's letter and fails this verifier's `approval-form`, because A3 extends the structure and a record's `aefVersion` can name only `1300/0.1`, so a record conformant to the version it declares is fatally non-conformant to a verifier applying this document, with no version string to tell the two forms apart. The input is pinned, the disputed behavior is pinned as a fixture that asserts what the verifier does rather than what it should, and the disposition is unresolved and published: AEF 1300 v0.2 owns versioning the approval structure, and AEF 1200 v0.2 owns saying which form V27 tests. The challenge record now carries three entries, all filed by the editor against the editor's own artifacts, which is either the mechanism working or the absence of anyone else looking, and section 17 declines to pick.

What did not change. No fixture published under the previous suite version was removed or altered, per AEF 1201 C12. The verifier still performs no self-test, so AEF 1201 C19 through C21 stay failed on the running list, joined by nothing new from this document.

16. Findings for earlier documents#

Recorded, not applied.

1. AEF 1200 v0.2 inherits the approval checks. Section 13's five checks with their fatality assignments, the V29 split that challenge-0002 forces (absence where the declaration required approval is fatal; absence otherwise stays qualified), and four registry candidates for section 7.4: ACCEPTANCE-ABSENT, APPROVER-INDEPENDENCE-NOT-ESTABLISHED, PRESENTED-BYTES-UNVERIFIED, and APPROVAL-IS-SELF-ASSERTION, which the reference implementation has carried in a code path since the worked example and which V30's self-assertion reporting implies without naming. The OTHER mechanism fired exactly as designed, again.
2. AEF 1300 v0.2: R24 is superseded, and the supersession is unversioned, which is challenge-0003. Its three members survive with their names; the approval record now carries A3's set, and R24 should state the full structure or defer to this document by id. The record's `aefVersion` member can name only one document, so nothing distinguishes an R24-form record from an A3-form record except inspection, and a verifier applying this document fatally rejects the former while V27's letter accepts it. AEF 1300 v0.2 should version the structure or let `aefVersion` carry more than one claim. Two further inheritances: R24's supersession should close the approval record's member set, because A3 lists members without a closure clause and an unclosed object inside the seal is the hiding place R1's rationale was written to eliminate, reintroduced one level down; and R1's letter is untouched, since `approvalRecord` remains one top-level member.
3. AEF 1100 v0.3: threat 8.1 splits. The artifact half, the record's claimed referent against the stored artifact, now has the shape of CONDITIONAL where the referent artifact is retained, per section 8; whether that warrants splitting the threat is AEF 1100's call, recorded as a candidate and not applied, per the formula AEF 1200 section 16 set. The rendering half, stored bytes against the approver's eyes, stays CONCEDED and is structural. Threats 8.2 and 8.3 keep their dispositions, with 8.2's boundary now marked by APPROVER-INDEPENDENCE-NOT-ESTABLISHED and 8.3's by the optional basis member.
4. AEF 1001's next version inherits terms, listed in section 20, and should resolve "approving signer" against this document's two types: the role name covers both the authorizing and the accepting party, and one party need not hold both.
5. AEF 1201's running list updates. C6's failure narrows: three inputs now pin complete qualification sets, and the remaining entries still do not. C7 and C8 narrow for the approval checks. C19 through C21 stand.

17. Requirements with no observer#

The audit every document since AEF 1000 carries, applied here.

A11's human is presumed, not observed. Automation under a distinct key held nominally by a person produces an approval indistinguishable from that person's considered act. The requirement binds the honest implementer; the field it forces, the relation, is observable, and the hand on the key never is. The residue sits between threat 8.2's collusion and threat 8.3's unqualified approver, and this document narrows neither; section 11's own limit, that distinct keys do not establish distinct parties, is the same fact seen from the key side.

A12's basis and A13's criteria are checkable as claims, never as facts. Presence is inspectable; that the approver read what the basis says they read, or measured anything against the criteria the digest binds, is not. Both are requirements that a claim be made, AEF 1300 section 12's category, counted with that discount.

The presentation context is a name, not a control. Nothing establishes that the declared tool rendered the presented bytes, or that any tool did. Section 8 states this as the honest limit; it is repeated here because it is also a no-observer entry in the strict sense: two honest readers cannot settle from the record what rendering occurred.

Acceptance existence has no observer, structurally. Section 7 states it as the placement's cost. It belongs on this list too: an acceptance that exists and is withheld, and an acceptance never sought, are one observation, and the external index that would split them remains undefined, now through five documents.

A6 and A8's orderings ride on the operator's clock. Both are internal-consistency checks, honest as such, and worth nothing against an operator who stamps times to order, per AEF 1100 threat 10.3. The fixtures exercise the orderings; nothing exercises the clock.

18. Weaknesses in this document#

The two-type model may be incomplete. Escalation, partial approval, approval with conditions, and revocation of a granted approval all exist in institutions and none has a type here. The closed enumeration in A1 was chosen over an open one for the same reason AEF 1200 section 7.4 closed its classes, and the first real workflow that needs a third type will find this document in its way. Open question 2 in section 19 records revocation as the most likely first casualty.

A single approver is assumed throughout. Quorum approval, countersignature, and separation-of-duty chains have no structure here: `approvingSigner` is one party and the role disclosure names one approving signer. The omission is deliberate scope control and is not argued for anywhere, which makes it the document's largest unargued choice. Open question 1 in section 19.

The worked example approves fixture work. The approval-0001 run reads two files and closes; its authorization and acceptance are real structures around a trivial run, signed by keys generated for the purpose. Nothing here has approved work anyone would litigate, so the semantics have been exercised and not yet stressed, the same limit AEF 1300 section 17 recorded for its own example.

The criteria hook points at a document that does not exist. A13 is only as good as AEF 1302, which is assigned and unwritten; until it exists, `criteriaRef` binds bytes whose suitability nothing in the series can assess. The member was specified anyway because the digest discipline costs nothing now and retrofitting it later would orphan every record sealed in between.

Bounding is not narrowing the threat count. All three of AEF 1100 section 8's threats remain CONCEDED, in whole or in part, after this document. A reader who wants this document to have fixed approval will not find that; what it fixed is the record's ability to say precisely which part is broken.

19. Open questions#

1. Multiple approvers. Quorum, countersignature, and separation-of-duty chains, none of which one `approvingSigner` and one relation can express. Section 18 records the omission as this document's largest unargued choice. AEF 1301 v0.2.
2. Revocation of a granted approval. An approver who withdraws an authorization before the run, or repudiates an acceptance after it, has no artifact here, and a withdrawn approval that leaves no trace is the record retaining only the exchanges that went somewhere, which AEF 1000 section 11 forbids for its own records. AEF 1301 v0.2.
3. Whether a declaration should state that an acceptance will be sought. `approvalRequired` covers authorization; nothing symmetric exists for acceptance, so an operator who never seeks one has omitted nothing the record promised. The asymmetry is a consequence of acceptance living outside the record and may still deserve a declared intent. AEF 1300 v0.2, since the member would live in the declaration.
4. Acceptance discovery. How a reviewer learns that an acceptance exists, which is the external index question, unassigned through six documents and now carrying this document's section 7 as well. No document assigned.
5. What AEF 1302 must contain. Assigned in section 12; its content is the open question it was assigned to answer.

20. Terms used here that AEF 1001 does not define#

Recorded rather than coined silently, following the practice of every document since AEF 1100.

• Authorization. The pre-execution approval type, section 5. AEF 1001 defines approving signer and approval record and does not split the act by time.
• Acceptance. The post-execution approval type, section 5.
• Acceptance envelope. The separately sealed artifact A7 defines.
• Approver relation. The disclosure member A10 defines.
• Presented bytes. The exact bytes shown to an approver, bound by the `presented` digest, section 8.
• Presentation context. The format, tool, and version triple declaring how the referent became the presented bytes, section 8.
• Basis. The optional stated ground of an approval, A12.
• Criteria reference. The optional binding of stated criteria, A13.

Still undefined from earlier documents and used here: external index, on which section 7's placement cost and section 17's acceptance entry both rest, undefined through five documents and counting, recorded per the precedent AEF 1101 section 15 set.

21. License and citation#

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

Cite as:

Stellmacher, G. (2026). AEF 1301: Approval and Signature Semantics, v0.1. 14 August 2026. https://grantstell.com/aef/1301

Cite the version and date, always.