# AEF 1100: Threat Model ## What an attested execution record survives, what it does not, and why **AEF 1100. Version 0.2. Published 11 August 2026.** ## 1. Status AEF 1100 v0.2 is an early draft and will change. It is 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 for the full model. This document is that analysis. AEF 1000 remains the source of authority, and AEF 1001 supplies the vocabulary, which is used here exactly and not redefined. Versions are dated, kept at their own paths, and recorded in CHANGELOG.md beside this document. ## 2. Why this document exists An evidence system is worth what its defeat surface says it is worth, and a reviewer who cannot see that surface cannot calibrate anything. Vendors omit theirs, which is why security claims about evidence systems tend to be unfalsifiable in the direction that flatters the vendor. This document states the defeat surface completely, in the same register as the claims, so that a reviewer weighing an aer knows what the record cannot tell them before they rely on it. Most of the threats below are conceded. Section 15 gives the count. That is the intended outcome of an honest analysis rather than a defect in the framework, and it is the reason this document is more useful for what it concedes than for what it claims. ## 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 largely non-normative. It analyzes threats and states dispositions. Requirements that follow from the analysis belong to AEF 1200 and AEF 1300, and where the analysis implies one, the implication is stated and pointed forward rather than imposed here. ## 4. The adversary The primary adversary is the operator. This is unusual, and it is the framework's central assumption, following AEF 1000 principle 2: verification must not depend on the operator, which is only a meaningful requirement if the operator is the party whose account is in question. Most threat models assume a trusted operator and an external attacker. This one does the opposite. The assumed adversary is not malicious in the ordinary sense. The adversary wants a favorable account of work already done, and controls the systems that produced the record, which is the disposition of a normal institution under pressure rather than an intruder. **What the adversary can do.** Control the execution environment completely. Configure, modify, or disable the capturing system before or during a run. Choose what the capturing system emits. Choose when to seal. Choose which records to retain and which to produce. Draw the declared scope. Select the approving signer. Supply the verifier. Control the clock, unless a time source outside its control is in use. **What the adversary is assumed unable to do.** Obtain a valid seal for content it did not seal, or for a seal time it did not hold the key at. This is the boundary assumption of the entire framework, and it rests on the trust dependencies enumerated per threat below. Where key compromise breaks this assumption, section 12 states what follows. **Timing.** The adversary acts both before and after the fact, and the asymmetry between those two is where the framework's entire value lives. Before seal time, the operator can shape the record nearly arbitrarily and almost nothing detects it. After seal time, the operator can delete or substitute a record wholesale but cannot alter it undetectably. The framework does not make the operator honest. It converts the operator's freedom from unlimited and invisible into bounded and dated. **Insiders and external parties.** A party inside the operator acting against the operator is partially addressed, because the operator's own seals constrain that party the same way they constrain the operator. An external attacker with no operator privileges is largely OUT OF SCOPE, since AEF 1000 section 5 places security controls and identity infrastructure among the prerequisites the framework depends on and does not redesign. ## 5. How each threat is analyzed Each entry carries the same labelled fields, so that the analysis can be read as prose and consumed as data without the two diverging. **Action** states what a party does. **Actor** names who can execute it, using the roles in AEF 1001 section 7. **Detection** states what in the aer catches it, or says None. **Depends on** enumerates the trust dependencies the detection rests on, each with what fails if it is misplaced, per AEF 1000 principle 2. **Residual risk** states what remains after the defense. **Forward** names the document that would address the gap, where one exists. **Disposition** classifies the threat. Dispositions take four values, not three. IN SCOPE means the framework defends against it today. CONDITIONAL means the defense holds only where a stated mechanism is in place, and that mechanism is not yet specified by any document in this series. CONCEDED means the threat is within scope, undefended, and stated plainly. OUT OF SCOPE means it is a prerequisite the framework depends on and does not redesign, per AEF 1000 section 5. The distinction between IN SCOPE and CONDITIONAL matters and is the reason for the fourth value. Nine threats below are defended only where something holds that nobody has written down yet. Counting those as defended would overstate what an aer is worth today by a factor of ten. ## 6. Threats against the record ### 6.1 Post-hoc alteration of a sealed record **Action.** The operator edits an aer after it has been sealed. **Actor.** Operator; implementer with storage access. **Detection.** The verifier. A seal binds the record's contents to a key, and altered contents fail verification. One flipped byte must fail. **Depends on.** - Signature scheme integrity, in the FIPS 186-5 sense referenced by AEF 1001 section 5. If broken, forgery is undetectable and the framework collapses entirely. - Key binding, meaning the reviewer's ability to establish that the verifying key belongs to the party claimed. If misplaced, the operator seals an altered record with a key it controls and the record verifies correctly against the wrong key. - Verifier correctness. If wrong, alteration passes, which is section 9.1's subject. **Residual risk.** The operator can alter the record and re-seal it, producing a valid record that differs from the original. Nothing in a single aer reveals that an earlier version existed. Detection requires an external index or a copy the reviewer already holds. **Disposition.** IN SCOPE. ### 6.2 Selective deletion of entries within declared scope **Action.** The operator removes act log entries that fall inside the declared scope. **Actor.** Operator. **Detection.** After seal time, the verifier, because deletion is alteration. Before seal time, none. The record is emitted without the entries and is internally consistent. **Depends on.** - The same dependencies as 6.1. If any is misplaced, post-seal deletion also goes undetected. - The position of seal time relative to the deletion. If sealing happens late, the window in which deletion is free is correspondingly long. **Residual risk.** Pre-seal deletion is complete and undetectable, and is indistinguishable from suppression at the source. The distinction between them matters for how an implementer builds and not at all for what a reviewer can conclude. **Forward.** AEF 1400, on bounding the capture-to-seal interval. **Disposition.** CONDITIONAL, where the deletion occurs after seal time. ### 6.3 Suppression at the source **Action.** The operator configures the capturing system not to emit a record of an act that falls within declared scope. **Actor.** Operator; implementer. **Detection.** None. AEF 1000 section 4 states it plainly: an event never emitted leaves nothing to detect. **Depends on.** None. **Residual risk.** Total with respect to the suppressed act. The aer remains complete in the sense AEF 1001 defines, because completeness is a claim about the declared scope and not about the run. A reviewer reading a conformant record has no signal that anything is missing. Two things narrow the search without closing the gap, and both are reviewer procedures rather than properties of the record. The permission surface records what the agent could touch, and the gap between it and the act log is where an unrecorded act would have to live. Output artifacts are hash-bound, so an effect that landed in the world and appears in no record can be found by comparing the world to the record, if the reviewer can see the world independently. **Disposition.** CONCEDED. This is the framework's largest single concession. ### 6.4 Truncation **Action.** The operator seals the record early, omitting acts that occurred later in the run. **Actor.** Operator. **Detection.** None intrinsic to the record. A truncated aer is internally consistent and complete against a declared scope that ends where the record ends. **Depends on.** None. **Residual risk.** Total. Truncation is the cheapest of the pre-seal attacks because it requires no editing at all, only a decision about when to stop. **Forward.** AEF 1300. If declared scope were required to state a termination condition the verifier could check, truncation would become a detectable mismatch between the stated end and the recorded end. **Disposition.** CONCEDED. ### 6.5 Reordering within the act log **Action.** The operator changes the order of entries before sealing, so that the sequence of acts misrepresents what preceded what. **Actor.** Operator. **Detection.** After seal time, the verifier. Before seal time, only where each entry binds the previous one so that order is part of what is sealed, or where capture times come from a source the operator does not control. **Depends on.** - Entry chaining. If absent, pre-seal order is the operator's assertion and nothing contradicts it. - An external time source. If the source is the operator's, recorded order and recorded time carry the same weight, which is none against a determined operator. **Residual risk.** Ordering matters most where causation is in question, which is where a reviewer is most likely to care. Pre-seal reordering is undetectable absent chaining. **Forward.** AEF 1300, on chained act log entries. **Disposition.** CONDITIONAL, where entries are chained or capture times come from an external source. ### 6.6 Replay against different work **Action.** The operator presents a genuine aer for one run as evidence about different work. **Actor.** Operator. **Detection.** Input state and output artifacts are bound to the record by cryptographic hash. A reviewer who holds the artifacts in question can compare hashes, and a replayed record fails to match. **Depends on.** - The reviewer's ability to obtain the artifacts from a source other than the operator. If the only source is the operator, it supplies artifacts that match the record it chose to supply, and replay succeeds completely. **Residual risk.** Replay succeeds whenever the reviewer's knowledge of the work runs through the operator, which is the common case. **Disposition.** CONDITIONAL, where the reviewer has an independent source for the artifacts. ### 6.7 Substitution **Action.** The operator supplies a genuine aer for a different run in place of the one requested. **Actor.** Operator. **Detection.** None, unless the reviewer can name the run they want independently of the operator's own index of runs. The framework proves things about records it is given and says nothing about the population of records that exist. **Depends on.** - An external index, in the sense AEF 1000 section 4 uses when noting that deletion of a whole record is not survived without one. If it is the operator's index, substitution is undetectable. AEF 1001 does not define external index, which is a finding recorded in section 16. **Residual risk.** An operator asked for the record of a specific run selects which record answers the request. Every subsequent verification then proceeds correctly against the wrong record. **Disposition.** CONDITIONAL, where the reviewer can identify the run independently of the operator. ## 7. Threats against the boundary ### 7.1 Adversarial scope declaration This is the threat the framework most deliberately does not prevent, and it deserves the fullest treatment, because AEF 1001 chose declaration over structural boundaries precisely on the grounds that declaration makes this visible rather than prevented. **Action.** The operator declares a run boundary that excludes the work in question, then produces a record that is complete, conformant, and silent about it. **Actor.** Operator. The declaration is the operator's by definition in AEF 1001 section 6.1, so no other party can execute this. **Detection.** None. The aer is not defective in any respect. It is honest about a scope chosen to be uninformative. **Depends on.** None. **Residual risk.** Total with respect to the excluded work. A reviewer holding a verified aer and asking a question the declared scope does not reach gets a correct answer to a different question. What declaration buys, stated precisely because it is not nothing: the boundary is written down, dated, attributable to whoever declared it, and made before execution. That last property is the constraint. AEF 1000 principle 5 requires evidence to capture what was known at the time, and a boundary drawn to exclude a specific bad outcome must have been drawn before that outcome was known. An operator who narrows scope to hide a particular failure must therefore have anticipated it, which is harder to do repeatedly than to do once. A reviewer with a series of declarations from the same operator can compare them, and a pattern of convenient narrowing is visible in a way that a structural boundary quietly re-architected is not. That property depends entirely on the declaration actually preceding execution, which section 7.3 shows is not currently verifiable. **Forward.** AEF 1300, on boundary adequacy, already recorded as AEF 1001 open question 1. Nothing in this analysis suggests adequacy can be made objective. It can plausibly be made comparable, which is a weaker and achievable goal. **Disposition.** CONCEDED, deliberately. ### 7.2 Run splitting **Action.** The operator fragments one piece of work across many runs, so that no single aer describes it and no single aer is incomplete. **Actor.** Operator. **Detection.** None within any record, by construction. Detection across records requires linkage between related runs, which nothing currently requires or defines. **Depends on.** None. **Residual risk.** Total. Run splitting is adversarial scope declaration applied serially, and it is worth stating plainly that declaration does not prevent it. AEF 1001 rejected structural boundaries on the grounds that splitting work across invocations defeats them. Splitting work across declarations defeats declaration in the same way. What differs is only that each narrow declaration is visible. **Forward.** AEF 1300. A linkage identifier joining related runs would make fragmentation visible as a shape rather than invisible as an absence. Linkage would itself be operator-declared and would inherit the same weakness, which is an argument for modest expectations rather than against the mechanism. **Disposition.** CONCEDED. ### 7.3 Scope amendment after execution **Action.** The operator revises the declared scope after seeing the outcome, and the record presents the revision as the original declaration. **Actor.** Operator. **Detection.** Where the declaration is sealed and anchored before execution, amendment is alteration and is detected as in 6.1. Where the declaration is captured only at seal time, which is the ordinary implementation, none. Nothing distinguishes an original declaration from an amended one. **Depends on.** - Anchoring the declaration before execution against a time source outside the operator's control. If that anchor is absent, the requirement in AEF 1001 that a declaration precede execution is an assertion nobody can check. **Residual risk.** This threat undermines section 7.1's only mitigation. Everything declaration buys rests on the declaration being made in ignorance of the outcome, and without pre-execution anchoring, a reviewer cannot establish that it was. **Forward.** AEF 1400 on time sources and AEF 1300 on whether a declaration must be separately sealed before a run begins. Until one of them does, AEF 1001's central defense against outcome-shaped boundaries is unverifiable. **Disposition.** CONDITIONAL, where the declaration is anchored before execution. ## 8. Threats against the approval ### 8.1 The approver is shown a different referent than the record claims **Action.** The approval record states what was in front of the approving signer. What was actually rendered to them differed. **Actor.** Operator; implementer. **Detection.** None. AEF 1001 open question 3 records this as unresolved. **Depends on.** None. **Residual risk.** Total. AEF 1000 principle 6 holds that a signature requires a defined referent, and this threat means the referent is defined in the record rather than established by it. **Forward.** AEF 1301. **Disposition.** CONCEDED. ### 8.2 Collusion between operator and approving signer **Action.** The operator and the approving signer agree on an account that is false, and the record faithfully preserves it. **Actor.** Operator and approving signer. Either two coordinating parties, or one party holding both roles, which AEF 1001 section 7.1 identifies as collapsing the approval into a self-assertion. **Detection.** None. AEF 1000 section 4 states the result: a faithful record of an approved lie. **Depends on.** None. **Residual risk.** Total. Where the roles are held by one party, AEF 1001 section 7.1 states that the combination MUST be visible in the aer, which lets a reviewer discount the approval accordingly. Disclosure is not defense, and nothing currently checks that the disclosure was made. **Disposition.** CONCEDED. ### 8.3 Approval by a party without the standing or knowledge to approve **Action.** The operator routes approval to a person who cannot meaningfully evaluate the run. **Actor.** Operator. **Detection.** None. The aer records who approved and when. Whether that person was competent or authorized to approve is not in the record and is not derivable from it. **Depends on.** None. **Residual risk.** An approval record can be complete, verifiable, and worthless. This is a limit on the claim in AEF 1000 principle 6 that defining the referent makes sign-off meaningful. It makes sign-off checkable, which is less. **Disposition.** CONCEDED. ## 9. Threats against the verifier ### 9.1 A verifier that accepts what it should reject **Action.** The implementer ships a verifier with a defect, deliberate or otherwise, that passes records it ought to fail. **Actor.** Implementer. AEF 1001 section 7.1 notes that where the implementer of the agent system also authors the verifier, the verifier has no adversary in its history. **Detection.** Golden fixtures, in the sense AEF 1001 section 6.12 defines, including inputs that are required to fail. **Depends on.** - The adequacy of the fixture set. Nothing currently specifies adequacy, so a verifier can pass every fixture anyone wrote and fail on the case nobody wrote. If the set is inadequate, the detection reports success and means nothing. **Residual risk.** A verifier is credible to the extent it has rejected things, per AEF 1000 principle 4, and the population of things it has never been asked to reject is unbounded. **Forward.** AEF 1201, on how a verifier demonstrates that it verifies. **Disposition.** CONDITIONAL, where the fixture set is adequate. ### 9.2 Golden fixtures with no required-to-fail cases **Action.** The implementer maintains a fixture set consisting only of records that should pass. **Actor.** Implementer. **Detection.** Inspection of the fixture set. AEF 1001 section 6.12 states that a fixture set MUST include inputs required to fail. **Depends on.** - Somebody inspecting. Nothing currently designates who, or where the inspection is recorded. If nobody inspects, the requirement is stated and unobserved, and two honest readers can disagree about whether a fixture set is adequate with no way to settle it. **Residual risk.** A verifier with a passing-only fixture set demonstrates that it accepts things, which was never in doubt. **Forward.** AEF 1201. **Disposition.** CONDITIONAL, where an independent party inspects the fixture set. ### 9.3 Verifier substitution **Action.** The operator supplies the verifier, and the reviewer runs it. **Actor.** Operator. **Detection.** None. The verification succeeds and reports what the operator's program reports. **Depends on.** None. **Residual risk.** This defeats AEF 1000 principle 2 directly, since verification then depends on the operator in the most complete way available. It is also the most likely real-world failure in this document, because it is the convenient path: the operator has a verifier, the reviewer does not, and running the supplied one is easier than building one. **Forward.** AEF 1200 should require that a conformant verifier be independently obtainable and its build reproducible, so that a reviewer can run something whose provenance does not pass through the operator. **Disposition.** CONCEDED. ### 9.4 Trust base substitution between verification and re-verification **Action.** A trust dependency is swapped between one verification and a later one, so that a record that verified before verifies now for different reasons, or fails for reasons unrelated to the record. **Actor.** Operator; whoever administers the trust dependency. **Detection.** None, because a verification result does not currently record the trust base in force when it was produced. **Depends on.** None. **Residual risk.** Verification time is evidence that the record verified at that moment under the trust base then in force, per AEF 1001 section 9. If that trust base is not recorded, verification time is evidence of less than AEF 1001 claims, because the conditions of the check are unrecoverable. **Forward.** AEF 1200, with the substance of what a trust base must contain in AEF 1101. A verification result should be a record naming its own trust base. **Disposition.** CONCEDED. ## 10. Threats against keys and time ### 10.1 Key compromise **Action.** A party other than the intended signer obtains the sealing key. **Actor.** Any party with sufficient access. This includes the operator asserting a compromise that did not occur. **Detection.** None in an aer. After compromise, records sealed with that key are indistinguishable between genuine and forged, in both directions and for the entire history of that key. **Depends on.** - An independent key history establishing when the key was valid. If it is the operator's, the operator chooses retroactively which records remain attributable. - Seal times anchored to a time source outside the operator's control. If absent, compromise reaches backward through every record the key ever sealed. **Residual risk.** Records sealed before a compromise retain value only if seal time can be established independently. Absent that, a single compromise retroactively destroys an entire series, which is a large and underappreciated exposure. **Forward.** AEF 1101 on establishing a key, AEF 1400 on anchoring seal time. **Disposition.** CONDITIONAL, where an independent key history and anchored seal times exist. ### 10.2 Key rotation used to invalidate inconvenient history **Action.** The operator rotates keys and then declines to publish the retired public key, or asserts that the retired key was compromised, rendering earlier records unverifiable or repudiable at the operator's choosing. **Actor.** Operator. **Detection.** None, absent an independent key history that records which keys were valid when, published somewhere the operator cannot retract. **Depends on.** None. **Residual risk.** An operator that can repudiate history at will has an aer series worth nothing older than the current key. **Forward.** AEF 1101. **Disposition.** CONCEDED. ### 10.3 Operator-controlled time source **Action.** The operator supplies the clock that stamps capture time, seal time, and approval time. **Actor.** Operator. **Detection.** None where the clock is the operator's. Times are recorded and internally consistent. **Depends on.** - A time source outside the operator's control. If absent, all three times become the operator's assertion, and the record establishes ordering relative to itself and nothing about when anything happened. **Residual risk.** AEF 1000 section 4 already states that backdating is survived only against a time source the operator does not control. Everything dated in the record inherits the weakness of the clock that dated it. **Forward.** AEF 1400. **Disposition.** CONDITIONAL, where the time source is outside the operator's control. ### 10.4 Seal-time delay This threat did not appear in AEF 1000's list and the analysis surfaced it. **Action.** The operator delays sealing, extending the window during which the record can be shaped. **Actor.** Operator. **Detection.** The gap between the earliest capture time and the seal time is visible in the record, so the window's size is apparent to a reviewer who looks. Nothing makes the window small. **Depends on.** - A time source outside the operator's control. If absent, both endpoints of the window are asserted and the gap can be reported as small while being large. **Residual risk.** Every concession in section 6 grows with the length of this window, which gives an operator a single lever that widens the entire pre-seal defeat surface at once. An operator acting in bad faith seals as late as possible. **Forward.** AEF 1400, on bounding the interval between capture and seal and requiring it to be stated. **Disposition.** CONCEDED. The window is visible; nothing constrains it. ## 11. Threats the framework depends on others to handle ### 11.1 Selective non-production **Action.** The operator produces the aers that help and does not produce the ones that do not. **Actor.** Operator. **Detection.** None within the framework. The records produced are genuine and verify correctly. **Depends on.** None. **Residual risk.** Complete, and it moots every defense in this document, since a defense that operates on records a reviewer never receives operates on nothing. AEF 1000 section 2 identifies three conditions under which evidence requirements attach: a party able to detect harm, a party able to compel production, and production costing less than the harm. The framework addresses the third. Compulsion is the second and arrives from contract, examination authority, or a court, none of which a specification can create. Placing this OUT OF SCOPE is a claim about the division of labor rather than a dismissal, and section 18 records the argument that the placement is wrong. **Disposition.** OUT OF SCOPE. ### 11.2 Loss or unavailability of retained records **Action.** Records exist at seal time and are unavailable at review time, through storage failure, retention policy, or ordinary neglect. **Actor.** Operator. **Detection.** None. Nothing distinguishes a record that was never made from one that was made and lost, absent an external index. **Depends on.** None. **Residual risk.** A reviewer cannot tell absence from destruction, which means an operator gains the benefit of the doubt by being disorganized. **Forward.** AEF 1400, on retention as it bears on re-verification. **Disposition.** OUT OF SCOPE as to storage and operational practice, which AEF 1000 section 5 places among the prerequisites. ## 12. What the framework concedes Consolidated so a reviewer can read the defeat surface without assembling it. Before seal time, the operator can suppress an act entirely, delete entries, truncate the record, reorder entries, and choose a scope that excludes the work in question, and none of these leave a trace in the record. The operator can split work across runs so that no record is individually incomplete and nothing describes the whole. The operator can amend the declared scope after seeing the outcome and present the amendment as the original, which defeats the one property that made declaration preferable to a structural boundary. The operator can show the approving signer something other than what the approval record claims, can hold the approver role itself, and can route approval to someone with no capacity to evaluate the run. The record preserves all three faithfully. The operator can supply the verifier the reviewer runs. Trust dependencies can be swapped between verifications without the change being recoverable. Where the key history is the operator's, key rotation becomes a way to repudiate inconvenient history. Where the clock is the operator's, every recorded time is an assertion. The operator can choose which records to hand over. **What an aer is therefore worth.** It is a strong constraint on revision and a weak constraint on construction. Once sealed, the record is fixed and any change is detectable. What went into it before that moment is the operator's account, and the framework's contribution is that the account is now dated, attributable, bounded by a written scope, and impossible to revise quietly afterward. **What it is not.** It is not proof that the work was done as described, not proof that nothing else happened, and not proof that the record in front of you is the record you asked for. ## 13. The honest floor Given the concessions, a reviewer holding a verified aer can safely say this: > This record was sealed at a stated time under a key bound to a named party, has not changed since sealing, and is internally consistent with a scope its operator declared for the run. They cannot say any of the following: > This is what happened. Nothing else happened. The approver understood what they were approving. No other record of this work exists. This is the record for the run I asked about. The declared scope was drawn before the outcome was known. The last one is worth separating from the others, because it is the only item on that list that a later document can plausibly move. The rest are structural. ## 14. Implications for later documents Stated as implications, not requirements, per section 3. AEF 1200 should require that a conformant verifier be independently obtainable with a reproducible build, and that a verification result record the trust base in force when it was produced. AEF 1201 should state how a verifier demonstrates that it rejects what it should. AEF 1300 should consider chained act log entries, a termination condition in declared scope, a linkage identifier across related runs, and separate sealing of the declaration before execution. AEF 1400 should state what a time source outside the operator's control requires, and should consider bounding and disclosing the interval between capture and seal. AEF 1101 should state what establishes a key and what an independent key history requires. ## 15. Threat count and disposition Twenty-three threats are analyzed. Sorting them into IN SCOPE and CONCEDED alone overstates the defense, because nine entries are defended only where a mechanism holds that no document has yet specified. Those are counted separately. **Defended, resting only on trust dependencies this framework already enumerates: one.** Post-hoc alteration of a sealed record, which depends on the signature scheme, the key binding, and the verifier's correctness. This is the framework's core, and it is one threat. **Defended conditionally, where a mechanism nobody has specified yet is in place: nine.** Selective deletion and reordering, both defended only after seal time. Replay, where the reviewer has an independent source for the artifacts. Substitution, where the reviewer can name the run independently. Scope amendment, where the declaration is anchored before execution. A defective verifier and inadequate fixtures, both resting on a fixture adequacy nobody defines. Key compromise, where an independent key history and anchored seal times exist. Operator-controlled time, where the time source is not the operator's. **Conceded outright: eleven.** Suppression at the source, truncation, adversarial scope declaration, run splitting, referent mismatch, collusion, unqualified approval, verifier substitution, trust base substitution, key rotation as repudiation, and seal-time delay. **Out of scope: two.** Selective non-production and record loss. One threat of twenty-three is defended by what exists today. Nine more are defended by mechanisms that are on the roadmap and unwritten. Eleven are conceded permanently or near enough. Most of what a determined operator can do to an aer, it can do. ## 16. Terms used here that AEF 1001 does not define Recorded rather than coined silently, per the instruction that governs this series. Each belongs in AEF 1001's next version. - **Capturing system.** The component that observes acts and emits act log entries. AEF 1001 section 9 uses the phrase in defining capture time without defining the thing. - **External index.** A record, outside the operator's control, of which aers exist. AEF 1000 section 4 relies on it when noting that deletion of a whole record is not survived without one. - **Time source.** The authority that supplies a recorded time. Referenced by AEF 1000 section 4 and AEF 1001 section 9, defined by neither. - **Key history.** The record of which keys were valid over which intervals. Referenced by AEF 1000 section 4, defined nowhere. Threat names introduced here, such as run splitting and seal-time delay, are labels for analysis in this document and are not proposed as vocabulary. ## 17. Detections with no observer The same defect class audited in AEF 1000, applied to this document. Each is a place where the analysis claims a detection that nobody is designated to perform, that produces no record, and that two honest readers could dispute without resolution. Fixture adequacy in 9.2 depends on somebody inspecting, and nothing says who or where the inspection is recorded. Boundary adequacy in 7.1 has no criteria, so a reviewer's rejection of a scope is a judgment with no basis the framework supplies. The disclosure obligation in 8.2, which AEF 1001 section 7.1 states as a MUST, has nothing checking that it was met. Verifier correctness in 9.1 has no observer beyond the fixture set whose adequacy is itself unobserved. Whether a declaration preceded execution, in 7.3, is currently unobservable in the ordinary case, which makes it the most consequential entry on this list. ## 18. Open questions 1. **Boundary adequacy.** Whether a declared scope can be tested rather than only rejected. AEF 1300. Already recorded as AEF 1001 open question 1. 2. **Pre-execution anchoring of the declaration.** What it takes to establish that a declaration preceded execution. AEF 1300 and AEF 1400. 3. **Run linkage.** Whether related runs can be joined in a way an operator cannot silently omit. AEF 1300. 4. **Bounding capture-to-seal latency.** Whether the interval can be constrained rather than only disclosed. AEF 1400. 5. **Independent verifier distribution.** How a reviewer obtains a verifier whose provenance does not run through the operator. AEF 1200. 6. **Trust base recording.** Whether a verification result must name the trust base in force. AEF 1200, with substance in AEF 1101. 7. **Whether selective non-production belongs out of scope.** AEF 1000 section 2 makes production cost the framework's stated job, which is an argument that a threat defeating production entirely is the framework's central concern rather than someone else's. No document assigned. It belongs in the 1000 block as a revision to the charter's scope, which the freeze in AEF 1000 section 9 does not obviously permit, and that tension is itself worth recording. ## 19. License and citation Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). Cite as: > Stellmacher, G. (2026). *AEF 1100: Threat Model*, v0.2. 11 August 2026. https://grantstell.com/aef/1100 Cite the version and date, always.