AEF 1400: Sealing, Time, and Re-verification

1. Status#

AEF 1400 v0.1 is an early draft and will change. It is the tenth document in the series, the first in the 1400 block, and the last document on AEF 1000 section 9's committed-and-unwritten list.

This document is normative throughout. Its requirements bind anchor evidence, a record and declaration that carry it, a renewal, what an implementation retains for re-verification, and what a re-verification result names. Requirements on what a verifier does are findings for AEF 1200 v0.2, listed in section 16 and implemented in the reference verifier so that pinned fixtures exercise them, under the rule AEF 1201 section 15 finding 1 established and this document depends on: every check is stated over supplied material, 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, AEF 1201, and AEF 1301 are cited by section and requirement id.

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

2. The debt arriving here#

Every recorded time in an aer is currently the operator's assertion. That single fact is the series' largest structural weakness, and this is the ledger of what rests on it, stated before anything is proposed.

AEF 1100 threat 10.3, the operator-controlled time source, CONDITIONAL where the time source is outside the operator's control, a condition no document had specified, which left it unrealizable: every recorded time inherits the clock's worth, which against a determined operator is none. Threat 10.4, seal-time delay, CONCEDED outright: the capture-to-seal window is the one lever that widens the entire pre-seal defeat surface at once, and nothing constrains it. Threat 7.3, scope amendment after execution, CONDITIONAL where the declaration is anchored before execution, another condition no document had specified: everything declaration buys rests on the declaration preceding execution, no one can check that it did in the ordinary implementation, and AEF 1001's central defense of declared boundaries has been unverifiable since AEF 1100 said so. Half of threat 10.1: a key compromise reaches backward through every record the key ever sealed, absent seal times the operator does not control, and the anchored half of its condition had no specification either. AEF 1300 R14, sealed before execution, is the requirement AEF 1300 section 12 classified as the one with no observer. AEF 1001 section 9's closing line assigns what a time source must be to this document. AEF 1101 section 10 requires key-history interval endpoints that do not depend on the operator's clock, and nothing yet says how such an endpoint exists. AEF 1101 section 12 and AEF 1200 section 9.4 left re-verification without its time semantics, and 1200 stated plainly that V35's first case, the anchored seal predating a deprecation, was unavailable because this document did not exist.

The success test for this document is that ledger, stated precisely: one disposition is CONCEDED outright and the others are conditional on mechanisms nobody had specified, so the test is how many unrealizable conditions become realizable, and at what price. Section 16 carries the answer as a table, and section 15 rewrites AEF 1100 section 13's honest floor to show what a reviewer can now say. The price turned out to include a discovery about the seal itself, made by this document's own hostile review and stated in section 7 before anything is built over it.

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 T1 through T12 and are collected with their classification in section 13.

4. What this document owes the series#

The ledger in section 2 names the debts; their dispositions land as follows. Threats 10.3, 10.4, 7.3, and 10.1's backward half each gain a realizable condition, argued in sections 7, 8, and 10 and recorded for AEF 1100 v0.3 in section 16, never applied here. R14's ordering gains a candidate observer in section 7, conditional on both seals being anchored, and 1300 rules on whether it counts. AEF 1001 section 9's assignment is answered in section 5: a time source a record can rely on is an anchor party, and what one must be is what section 5 defines and AEF 1101 section 7's tests measure. AEF 1101 section 10's interval endpoints gain a form an implementation could satisfy: an anchored moment is an endpoint that does not depend on the operator's clock. AEF 1101 section 12's remaining time semantics are supplied in section 10, and V35's first case becomes reachable, over supplied deprecations, for the first time.

5. What a time anchor is#

AEF 1101 section 9 solved key identity with a pattern: an assertion by a party other than the operator, plus a mechanism by which that party's own misbehavior is detectable. Assertion alone is a second operator; detection alone has nothing to detect against. This document applies the same pattern to time.

T1. A time anchor MUST comprise both halves: an assertion, by a party other than the operator, that a named digest existed at or before a stated moment; and a mechanism by which that party's fabrication or equivocation is detectable. An assertion with no detection mechanism MAY be carried, and it is a second party's word, which section 12's checks report as exactly that.

What an anchor asserts, exactly. Existence, bounded from above: the digest's preimage existed no later than the stated moment. An anchor does not establish when the content was created, does not establish the operator's recorded `sealedAt`, and does not narrow anything from below. Every property this document builds is built from that one bound, and section 7 states what each costs.

6. The mechanisms, named#

No mechanism is invented here, and none is ranked above the others universally. Each is named with what it supplies, what it asks of the reviewer, and how it fares under AEF 1101 section 7's three externality tests. The choice belongs in the trust base statement, where AEF 1101 section 6 already requires the anchor party to appear as a dependency with its failure consequence stated.

RFC 3161 timestamp authorities. The assertion is supplied directly: a signed token binding a digest to the authority's clock. Detection is weak: nothing structural reveals a TSA that backdates or issues contradictory tokens, so the mechanism is assertion-heavy in exactly the way AEF 1101 section 9 warns about for bare certificate authorities. The reviewer must hold the authority's certificate chain and check the token against it. Externality: test one usually passes; test two often fails, since a subscriber relationship is withdrawable; test three passes where the token travels with the record, which this document requires.

Append-only transparency logs. Inclusion in the log bounds existence; consistency proofs make equivocation detectable, which is the full pattern rather than half of it. The costs are the ones AEF 1101 section 10 already recorded for logs as key history: the log operator is a traded dependency rather than a removed one, append-only is a property somebody must monitor for, and the monitoring party is itself a dependency the statement should name. The reviewer must check inclusion and consistency proofs against a tree head they trust.

Public blockchain anchoring. Existence proofs are strong: rewriting a widely replicated chain is the attack, and its cost is public. What it asks is stated honestly: transaction cost per anchor, confirmation latency, a proof format the reviewer's tooling must understand, and a dependency on the chain's continued operation and the reviewer's ability to evaluate a header chain, which for many reviewers routes through an index party who re-enters as a dependency.

T2. Anchor evidence MUST carry: `mechanism`, naming one of the mechanisms above; `statedAt`, a recorded time whose source is `external` and names the anchor party; `anchoredDigest`; `proof`, the mechanism's proof material, carried in full; and `proofFormat`, naming how the proof is to be checked. Evidence travels with the record, in the `evidence` member AEF 1300 R20 reserved, so that verification consumes supplied material and liveness is left to the reviewer's procedure and the trust base comparison.

7. Anchoring points, and what the seal member actually is#

The discovery this section is built around, found by this document's own hostile review. AEF 1300 R6 defines the sealed bytes as the canonical form with the seal member removed, and nothing else. The seal member contains `sealedAt`, `keyId`, `alg`, and, since R20, the anchor. Every one of them is therefore outside the signature: any holder of a record, with no key at all, can strip its anchor, substitute another, or rewrite its recorded seal time, and the seal still verifies. This is not a defect this document introduced; it has been the shape of every sealed record since AEF 1300 v0.1, and it went unnoticed until anchor evidence moved into that member and an adversarial reader asked what covers it. The record's authenticated fastenings are the signed content, including the key binding, and one thing more, stated at T10 because it is the reason renewals matter: every artifact that binds the digest of the whole sealed record as held, a renewal, an acceptance, a verification result, covers the seal member too, and is the only thing that does. The structural repair, a seal boundary that covers its own time and anchor, is filed for AEF 1300 v0.2 in section 16, priced honestly there: it breaks every existing seal.

T3. The anchored digest MUST bind the sealed bytes: the canonical form of the sealed object with its seal member removed, per AEF 1300 R6's boundary. This holds for a record's seal and a declaration's seal alike, and the declaration's is the stronger of the two, because a record binds its declaration envelope whole, seal and anchor included, so tampering with a declaration's anchor breaks `declaration-binding`, while the record's own anchor enjoys no such cover. What an anchor establishes is exactly section 5's bound: the content existed no later than the stated moment. It does not bind the signature, the recorded seal time, or the anchor member itself, and an in-record anchor is therefore the operator's to carry, remove, or replace until an external holder binds the whole record. The properties sections 8 and 10 build rest on content existence and on that external binding, and nothing here claims more. It is stated at this length because an unstated concession is how this series fails, and the first draft of this section stated a narrower one.

T4. The seal is the load-bearing anchoring point: where a record carries one anchor, it is the seal's, which AEF 1300 R20's placement already enforces in the schema, making this requirement currently unviolable in form and binding on any future form that adds one. Capture times are not anchored, and this is a position, not an omission: anchoring every act log entry is not proposed, its cost scales with the log, and what it would buy is bounded by what chaining already buys. Capture times remain the operator's assertion, conceded plainly; chained entries fix their order relative to each other, and an anchored seal bounds the moment after which none of them could have been shaped. The concession's price is stated in section 15: within the window, when things happened stays the operator's word.

T5. An implementation that anchors its records SHOULD anchor the declaration's seal as well, and SHOULD have one party anchor both, because the pair is where the value is and the pair's comparison is only as good as its clocks are commensurable.

T6. Where both seals are anchored, the pair either establishes the before-relation or it does not, and a verifier reports which. Where the declaration's stated moment precedes the record's, the pair establishes that the declaration existed first, by a stated margin that is one party's word where one party anchored both and two unreconciled clocks' where two did. Where the declaration's stated moment postdates the record's, the pair establishes nothing about order, and that is a report, not a failure: an anchor bounds existence from above and says nothing from below, so a late anchor is fully consistent with an old declaration, and honest processes produce late declaration anchors, by retrofitting anchoring to existing declarations or by mixing mechanisms with different latencies. The first draft of this requirement called the late case a self-contradiction and made it fatal, which this document's own section 5 refutes, and the hostile review caught it before the fixture pinning the wrong expectation was ever published.

What the pair does not establish, stated before section 16 trades on it. An anchor commits to a digest, and a digest hides its preimage. An operator can anchor several candidate declarations before a run and publish whichever suits the outcome; each published record then carries a genuine early anchor and an excellent margin, and nothing in any record reveals the candidates not chosen. The margin bounds how late the published declaration was drawn. It does not bound the menu it was drawn from, and only an external index of the operator's anchoring activity, the kind a monitored transparency log provides and a timestamp authority does not, would make the menu's size observable. That difference between mechanisms is real and belongs in the trust base choice section 6 leaves open.

8. The interval#

T7. The capture-to-seal interval MUST be computable from the record alone. AEF 1300 R19's sourced times make it so, AEF 1200 V25 already requires a verifier to report it, and nothing here is new except the bound below.

T8. A declaration MAY state the operator's own maximum seal latency, as `sealLatency.maxSeconds`. Where stated, a verifier compares the actual interval against it, and an exceedance is a finding within a declared boundary, reported and not fatal. Where absent, the interval is reported with the qualification that nothing bounds it.

No universal bound is imposed, and the refusal is argued rather than asserted. A batch pipeline that seals nightly and an interactive session that seals per task differ by four orders of magnitude, and any number blessed here would be arbitrary for both, gamed by whoever it favors, and wrong in both directions at once. The declared-scope move is the series' answer to exactly this shape, per AEF 1000 principle 3: the operator states the boundary, the statement is sealed and attributable, absence of a statement is itself visible, and an exceedance converts from an unremarkable fact into a finding against a declared claim. The costs are stated. The bound is the operator's own, an operator can declare a generous bound and live inside it, and what the declaration buys is comparability across a series and a stated claim to hold them to, not a constraint they did not choose. The interval itself is computed from `sealedAt`, a member of the seal the signature does not cover, per section 7, so the finding is a finding about asserted times; the anchored outer bound is the version an operator cannot quietly rewrite. And the narrowed emission diverges from AEF 1200 V25's letter, which is unconditional. AEF 1200 section 8.6's own note said the qualification "becomes conditional on the bound" when this document exists, and this document imposed no bound of its own; whether an operator-declared bound satisfies that note's antecedent is a reading two honest parties resolve differently, so it is filed as challenge-0004 rather than claimed as pre-authorization, and AEF 1200 v0.2 owns it.

9. Sealing semantics across time#

What a seal covers is settled by AEF 1300 section 5 and is not restated: the canonical form, the seal-boundary rule, the number restrictions. This section adds what sealing means across years rather than at a moment.

T9. A sealed record MUST NOT be re-sealed. Correction is a new record that references the superseded record among its input state, with its declaration stating the supersession as its purpose. The old record stays at its path, unchanged, exactly as superseded document versions do under AEF 1000 section 1, and for the same reason: a record series that retains only its corrections is not a record series. The reference's digest is over the superseded record's retained bytes, which is the domain AEF 1300 R23's input state and the `artifact-binding` check already use; the record's canonical identity, the digest renewals and results bind, is a different domain, and one record having two names is a stated cost of this interim convention, not a feature of it. A dedicated supersession member, in one domain, with its verifier semantics, is filed for AEF 1300 v0.2 in section 16 rather than added here, because AEF 1300 R1 closes the record's member set and challenge-0003 already demonstrates what an unversioned structural extension costs. Until then the supersession relation is expressible as bytes and legible only to a reader, which falls short of AEF 1300 section 6.2's machine-comparable standard and says so.

The run-0001 lesson, generalized. The series' first record binds eight repository files as input state, and AEF 1201 section 14 recorded the consequence: those files are frozen, because an edit to any of them surfaces as artifact drift. That is the system working, and it is also a warning about what was bound: a record that binds mutable paths decays as the world moves, one edit at a time, until artifact-binding reports nothing but drift. The retention consequence is T12's enumerated list. The record-structure consequence, that artifact references should be content-addressed or immutable so that a record's bindings do not share fate with a working tree, is a finding for AEF 1300 v0.2, filed in section 16 and not smuggled in here.

10. Re-verification over time#

AEF 1101 section 12 distinguished a record that no longer verifies from a record whose verification is no longer meaningful, and assigned the comparison. This section completes the time semantics with the third case both documents saw coming.

Case one: cryptographic failure. The bytes do not check. Loud, and needing no help.

Case two: standing change. The record still checks, and a party a check rested on has changed standing: an authority distrusted, a log shut down, a key later compromised. AEF 1101 section 12's comparison surfaces it; the anchor party now joins the parties the comparison covers, because an anchor is a dependency like any other, and an anchor whose party has lost standing is case two exactly.

Case three: the sealing algorithm is deprecated. AEF 1200 section 9.4 posed the question precisely: not whether the algorithm is sound now, but whether the reviewer can place the record's existence, unchanged, before the point at which forging it became practical. The position the anchoring analysis supports:

T11. An anchor that predates the algorithm's public break preserves what the anchor covers: the content's existence before forging became practical. It does not preserve the seal's attribution, because section 7's discovery applies with full force here: the signature and its recorded time sit outside both the signed bytes and the anchored digest, so a broken signature algorithm lets an adversary forge exactly the part no anchor covers, and what survives the break is the content and its anchored moment, not the operator's claim to have sealed it then. That narrower survival is still worth having, and it is worth exactly as far as the anchor's own algorithm and party still stand: the record's standing has moved from its seal to its anchor, and the anchor is itself an artifact with an algorithm, a party, and a lifetime, which is why T2's evidence names its `alg`. Anchors therefore chain, and renewal is the practice, not an emergency measure. A verifier evaluates this over a supplied deprecation list, naming algorithms and the moments they became unreliable, because a deprecation registry is a liveness dependency this document refuses for the same reason it refuses all of them; whose list is right is the reviewer's problem, flagged in section 17.

T10. A renewal is fresh anchor evidence, in T2's form, over the digest of the sealed record as held, the same identity a verification result and an acceptance bind. That identity includes the seal member, which makes renewals the counterweight to section 7's discovery: a renewal is an external holder's binding of the record's unauthenticated margin, and the only artifact in this series that covers it. Renewals postdate the record and are supplied to a verifier like artifacts. A renewal MUST bind that digest exactly, and it extends the chain only where its own named algorithms are undeprecated and its stated moment precedes the deprecations it renews across. A record whose standing rests on a deprecated algorithm, with no such renewal supplied, carries a lapsed chain, reported as a qualification and never silently.

V35's first case is now reachable. AEF 1200 section 9.4 stated that every deprecated-algorithm qualification would land in the corrosive case until this document existed. With anchors specified over supplied evidence and deprecations supplied rather than fetched, both cases are expressible, both are implemented, and both are pinned in the suite, which moves V35 out of the coverage declaration's never-arises bucket for the first time.

11. Retention for re-verification#

AEF 1100 threat 11.2 keeps storage practice out of scope, and that boundary holds. What is in scope is the list of what re-verification needs, because a re-verification that silently proceeds without one of these is a second verification with less memory than it reports.

T12. Re-verification requires: the record; the separately sealed declaration; the anchor proofs and every renewal; the trust base statement in force at each prior verification; the key history; and the prior verification results being compared against. An implementation MUST retain these, unchanged, for as long as re-verification is contemplated, and a re-verification result missing any of them MUST name the absence as a qualification, not a silent pass and not a refusal to proceed, per the disposition AEF 1200 section 8.4 established for absent artifacts: a mismatch is fatal, an absence is named. The retention half binds an implementation and the naming half binds a result, the same split AEF 1101 section 11 uses, and section 1's subject list carries both.

12. What a verifier reports#

Nothing in this section binds a verifier; every check is a finding for AEF 1200 v0.2, and the reference verifier implements them so the fixtures in section 14 exercise real behavior.

`anchor-form`: absent anchors, qualified with SEAL-TIME-UNANCHORED, as today. Carried anchor evidence, on the record's seal or the declaration's, whichever is present: T2's members checked, the stated moment's source external and naming the anchor party, and the anchored digest recomputed against the sealed bytes; malformed evidence or a digest mismatch is fatal, because an anchor binding different bytes contradicts the record carrying it. A well-formed anchor is reported with the qualification that names this verifier's own limit: ANCHOR-PROOF-UNVERIFIED, emitted once however many anchors are carried, because the reference verifier checks bindings and implements no mechanism's proof verification, which section 14 puts on the running failure list rather than behind a vague check name.

`anchor-ordering`: T6, where both seals are anchored and their evidence checks. The established case is held, with the margin and the claimed capture window reported side by side; the late case is reported, not failed, with ANCHOR-ORDER-NOT-ESTABLISHED emitted, because a late anchor establishes nothing rather than contradicting something.

`seal-latency`: T7 and T8. Declared and met, held; declared and exceeded, failed and not fatal, a finding inside a declared boundary; absent, qualified with CAPTURE-TO-SEAL-INTERVAL-UNBOUNDED, an emission narrowing filed as challenge-0004 per section 8. The check reads the seal member's asserted time, per section 7's discovery, and its detail says so.

`anchor-renewal`: T10, where renewals are supplied. A renewal binding a different digest is fatal; well-formed renewals are reported, with the proof-unverified qualification shared with anchor-form rather than emitted twice for one condition.

`algorithm-standing`: T11 over the supplied deprecation list, reporting which of V35's two cases applies and deciding nothing. Algorithms are read from the signed content, the key binding and the hash algorithm, never from the seal member the signature does not cover, and the anchor's own algorithm joins the set where an anchor is carried. ALGORITHM-DEPRECATED is emitted from AEF 1200's existing registry, and ANCHOR-RENEWAL-LAPSED where the chain was not extended per T10's rule. This check and anchor-ordering have no failing state by design: both report, neither decides, and AEF 1201 C7's required-to-fail obligation cannot be discharged for a check with nothing to fail, which the coverage declaration states rather than hides.

Three new qualification classes, ANCHOR-PROOF-UNVERIFIED, ANCHOR-ORDER-NOT-ESTABLISHED, and ANCHOR-RENEWAL-LAPSED, are emitted under OTHER with proposed names per AEF 1200 V7, and join section 16's registry candidates.

13. Requirement count and classification#

Twelve requirements, T1 through T12. By subject: T1 through T3 bind anchor evidence, T4 through T6 bind an anchored record and its declaration, T7 and T8 bind the interval and its declaration, T9 binds correction practice, T10 and T11 bind renewals and standing evaluation, and T12 binds retention and its reporting.

By observer, applying AEF 1101 section 16's test, with every requirement in exactly one bucket:

Checkable by inspecting an artifact: seven. T2, T3, T4, T7, T8, and T10 are member, digest, and ordering rules read off the record, the declaration, or a renewal, with T4 currently unviolable in form since AEF 1300 R20 places anchors only on seals. T6 is read off the pair of anchors, discounted in writing: its cross-party form compares two clocks nobody reconciled, per section 17.

Checkable with a stated discount: three. T1's assertion half is checkable through T2's form and its detection half is a property of mechanisms and monitors the trust base names, not of any artifact the record carries. T11 is evaluated over a reviewer-supplied deprecation list with no curator, so the check is checkable and its premise is an input, the distinction AEF 1300 section 12 drew between form and substance. T12's naming half is read off a re-verification result and its retention half is a property of the future, C2's shape from AEF 1201.

Not artifact-checkable: two. T9's prohibition has the external-index shape: two validly sealed versions of one record are each unimpeachable alone, and only a holder of both can see the re-seal, which no artifact this series defines reveals. T5 is a SHOULD on practice and binds nobody.

Seven of twelve on the artifact side, three more with their discounts stated in the bucket they sit in, and two off it entirely. The first draft of this section counted nine by double-counting two halves and omitting T4, which the hostile review caught; the corrected count is smaller and true.

14. Applied immediately#

Produced in the same session, under AEF 1201's suite discipline. The verifier moves to 0.3.0; the suite moves to its third version; nothing pinned was removed or altered.

The worked example, published at `/aef/examples/anchor-0001/`: a declaration whose seal carries fabricated but well-formed RFC 3161 anchor evidence, a record anchored five seconds later on the anchor party's stated clock, and a declared seal latency bound of an hour, met. The fabricated evidence is the expressibility rule working as designed: the proofs were issued by no one and verify against nothing, ANCHOR-PROOF-UNVERIFIED says so on every result, and the branches the fixtures exercise are enumerated in the coverage declaration rather than claimed universally, because several branches remain unexercised, including malformed-member evidence, a defective declaration anchor, and non-RFC-3161 mechanisms as primary anchors. Verified, the record yields PASS WITH QUALIFICATIONS with its complete qualification set pinned by class, the suite's fourth: SEAL-TIME-UNANCHORED and CAPTURE-TO-SEAL-INTERVAL-UNBOUNDED are gone, retired by the anchor and the declared bound, and ANCHOR-PROOF-UNVERIFIED stands in their place, which is the honest trade this document makes: two operator-assertion qualifications for one about the verifier's own reach.

Pinned, and what the hostile review changed before publication. Two required-to-fail fixtures isolate the two fatal anchor checks: anchor evidence binding a different digest than the sealed bytes, failing `anchor-form` alone, and a renewal over some other record's digest, failing `anchor-renewal` alone. The late-declaration-anchor input was drafted as a third required-to-fail fixture and the draft was wrong, per T6's correction; it is pinned instead under its true expectation, the before-relation reported as not established, no failure anywhere. Because the correction landed before any fixture was published, no retirement under AEF 1201 C12 was needed, and this note is the record of how close it came. A fourth fixture pins the finding-not-failure shape: a declared one-second bound exceeded by an hour reports `seal-latency` failed, not fatal, outcome unchanged, over a `sealedAt` the signature does not cover, which the fixture's own note states. Three more pin V35 and the chain: the anchored record with the pinned deprecation list lands in the first case, its unextended chain named by ANCHOR-RENEWAL-LAPSED; the unanchored record lands in the second, unable to be placed before the break; and the renewal that predates the deprecation under undeprecated algorithms extends the chain and retires the lapse. The deprecation list is a pinned file, not a regenerated literal, so the V35 entries are pinned in every input except the wall-clock option that every entry in this suite still carries.

The running failure list, extended. The reference verifier implements no mechanism's proof verification: not RFC 3161 token checking, not inclusion or consistency proofs, not header chains. Every anchored result says so via ANCHOR-PROOF-UNVERIFIED, and the coverage declaration carries the entry. Deeper: the reference implementation's own tooling anchors nothing. run-0001, approval-0001, and every generated record carry unanchored seals stamped by the wall clock, exactly as AEF 1201 section 14 flagged; the only anchored records in existence are these fixtures, whose anchors are fabricated. This document specifies a practice with zero real instances, and says so here rather than in a footnote.

V35 moves. Both cases pinned over a pinned deprecation list; the requirement leaves never-arises for asserted in the coverage declaration, escaping by implementation as V27 did before it under AEF 1301.

15. The honest floor, revisited#

AEF 1100 section 13 gave the reviewer one safe sentence. After this document there are two, and the difference between them is what an anchor buys.

For a record that is not anchored, the floor is unchanged, and restating it unchanged is the point: 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. Every recorded time in it is the operator's assertion, including the seal time the sentence leans on.

For a record whose seals are anchored, and whose whole digest an external holder binds, the reviewer can say: this record's content existed no later than a stated moment, on the assertion of a named party outside the operator whose standing the trust base states and whose proof I have not necessarily verified; where the declaration's anchor precedes the record's, the declaration existed first, by a margin worth what the anchor clocks are worth; the content has not changed since sealing; and it is internally consistent with a scope its operator declared. The gains are real, enumerated, and conditioned: content anchored before a key compromise cannot have been fabricated after it, though the compromise still reaches signatures, which no anchor covers, per T3; the shaping window has an anchored outer edge, though the anchor itself rides in the record's unauthenticated margin until a renewal, an acceptance, or a result binds the whole, per section 7; and the published declaration's lateness is bounded, though not the menu of candidates it may have been chosen from.

What neither sentence says, unchanged from AEF 1100 and repeated so the anchored sentence is not over-read: what happened inside the window and when, whether anything outside the record occurred, whether the scope was honestly drawn, whether the approver saw what the record claims, whether this is the record the reviewer asked for, and whether other records exist. The anchor moves one boundary, conditionally. The concessions of AEF 1100 section 12 otherwise stand where they stood.

16. Findings for earlier documents#

Recorded, not applied.

1. AEF 1100 v0.3: the disposition delta table. Each entry is a candidate under the formula AEF 1200 section 16 set; whether the conditions warrant the moves is 1100's call. Realizable throughout means the condition's mechanism is now specified, not that anyone operates it: zero real anchors exist, per section 14.

1. AEF 1300 v0.2 inherits the seal boundary itself, the largest finding this document produces. R6's removal of the whole seal member leaves `sealedAt`, `keyId`, `alg`, and the anchor outside the signature, per section 7: unauthenticated since v0.1, load-bearing since R20 gave the member an anchor to carry, and read by checks as old as V26's capture-after-seal comparison. The repair, a boundary that covers the seal's own time and anchor or a countersignature over them, breaks every existing seal and must be versioned as the breaking change it is. Three smaller findings ride along: `sealLatency` extends R7's declaration member list, the same unversioned-extension shape challenge-0003 documents; artifact references should admit content-addressed or immutable forms, per section 9's decay lesson; and a dedicated supersession member should replace T9's two-domain interim convention, with its verifier semantics stated.
2. AEF 1200 v0.2 inherits the five checks of section 12, the narrowed emission of V25's qualification filed as challenge-0004, V35 restated over a supplied deprecation list, and three registry candidates: ANCHOR-PROOF-UNVERIFIED, ANCHOR-ORDER-NOT-ESTABLISHED, and ANCHOR-RENEWAL-LAPSED.
3. AEF 1101's next version gains the anchor party as a worked dependency class: section 6's form fits it without change, and section 10's key-history endpoints can now cite T2 for what an anchored endpoint is.
4. AEF 1001's next version inherits terms, listed in section 20, including the one this series has now leaned on through six documents without defining, which this document also fails to define: the external index, on which T9's re-seal detection and every whole-record substitution threat still rest.

17. Requirements with no observer#

The audit every document since AEF 1000 carries.

The anchor party's honesty has no observer inside the record, by design. T1's detection half lives in mechanisms and monitors the trust base names. A TSA that backdates produces evidence indistinguishable from honest evidence, and only the mechanism's own detection story, weak for TSAs, real for logs with monitors, public for chains, stands between the reviewer and a second operator. The fixtures demonstrate form, not truth: fabricated evidence passes every form check, which is exactly what they demonstrate and exactly the limit.

The seal member is an unauthenticated margin, and every check that reads it reads assertions. Section 7's discovery, carried here as the audit entry it also is: `sealedAt`, `keyId`, `alg`, and the anchor can be rewritten by any holder without a key, so `seal-latency`, the capture-after-seal comparison, and the anchor checks all operate on material nothing signs. The observers that exist are external: whoever holds a renewal, an acceptance, or a result binding the whole record's digest can detect the rewrite, and nobody is designated to hold one.

The candidate menu has no observer. An operator who anchors several declarations and publishes one leaves no trace in any published record, per section 7. A monitored transparency log would make the anchoring volume observable in principle; nothing requires that mechanism, and no party is designated to monitor.

T9's re-seal prohibition is unobservable from one artifact. Stated in section 13 and carried here: the external index remains undefined, and without it, a re-sealed record is detected only by a holder of the original.

The deprecation list has no curator. T11 evaluates over what the reviewer supplies, which was the expressibility rule's price: two reviewers with two lists get two answers, and nothing in the series says whose list is right. The alternative, a live registry, was refused for reasons this document stands by; the cost is a judgment relocated to the reviewer, flagged as such.

T5 binds nobody, as every SHOULD does; an implementation that anchors records and not declarations satisfies the letter and forfeits the pair's entire value, and only section 16's table tells them what they forfeited.

Anchor clock commensurability is assumed, not established. T6 compares moments stated by anchor parties, and where the declaration and record are anchored by different parties, the comparison trusts two clocks nobody reconciled. Section 18 carries it as a weakness; it sits here too because no artifact records what one party's moment means on another's clock.

18. Weaknesses in this document#

The load-bearing concession was found by the audit, not the author. The first draft of section 7 conceded that the signature is not anchored, an argument scoped to key holders; the hostile review showed the true shape is larger, that the whole seal member is outside the signature and needs no key to rewrite. The correction is in the text, the structural repair is filed for AEF 1300 v0.2, and the pattern is AEF 1900 finding one's: the gap was invisible from where the author stood. What else in this design has that property is exactly what a second reviewer would find, and there has been one, once.

Zero real anchors exist. Every anchored record in the ecosystem is a fixture with fabricated evidence. The mechanisms are named from their literature, not from operating experience inside this framework, and the first real TSA token or inclusion proof will find gaps in T2's evidence form the way run-0001 found gaps in every document it touched. One such gap is already visible from the armchair: T2 carries one `alg` for a mechanism whose real artifacts involve several.

The declared latency bound is the operator bounding the operator. Section 8 says so, and the weakness is that a reader of a met bound may still read more than comparability into it.

Different-party anchor ordering rests on unreconciled clocks. T6's comparison is clean when one party anchors both seals and soft when two do; the document does not quantify the softness and no mechanism here reconciles it. The check is non-fatal partly for this reason, and the residue is that a report a reviewer must interpret replaced a failure a reviewer could trust.

The retention list is enumerable and its enforcement is not. T12 says what re-verification needs and reporting absences is the only tooth; an implementation that retains nothing produces, years later, a re-verification that is all qualifications, which is honest and useless, and this document chose honest.

19. Open questions#

1. Anchor clock commensurability across parties. Whether T6's ordering needs a stated tolerance, or a single-party requirement, when declaration and record anchors differ. AEF 1400 v0.2.
2. Batched capture anchoring. T4 declines to anchor entries; a periodic anchor over the chain head would bound segments of the log at stated cost, and nothing here evaluates that trade. AEF 1400 v0.2.
3. The supersession member and its verifier semantics. Filed for AEF 1300 v0.2 in section 16; what a verifier reports about a superseded record, and whether a superseding record's claims about the old one are checked, is unassigned.
4. Who curates a deprecation list. Section 17's relocated judgment; whether the series should name a form for shared deprecation statements, as it did for trust bases, so two reviewers can at least compare lists. No document assigned.
5. The external index, sixth appearance. T9's detection, whole-record substitution, deletion, acceptance discovery, and claim retention all want it; no document owns it, and the pattern of every document listing it and none taking it is now itself a finding about the series' roadmap. No document assigned, deliberately visible.

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

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

• Time anchor. T1's pair: assertion plus detection, about a digest and a moment.
• Anchor party. The party other than the operator making the assertion; the controlling party of the anchor dependency in AEF 1101 section 6's sense.
• Anchor evidence. The artifact T2 defines, carried in AEF 1300 R20's reserved member.
• Anchoring point. The sealable object an anchor attaches to; T4 makes it the seal, and open question 2 revisits the entries.
• Anchor chain. An original anchor and the renewals over its record, per T11; T10's rule says what extends it, and a lapse is the chain left resting on a deprecated link.
• Renewal. Fresh anchor evidence over the digest of a sealed record as held, per T10.
• Seal latency. The capture-to-seal interval, and the declared bound T8 allows over it.
• Supersession. T9's correction relationship: a new record referencing the superseded one among its input state.
• Deprecation list. The supplied statement T11 evaluates against, naming algorithms and the moments they became unreliable.
• Unauthenticated margin. The seal member's own contents, outside the signed bytes under AEF 1300 R6, per section 7's discovery.

Still undefined from earlier documents and used here: time source, which AEF 1100 section 16 recorded first and which this document narrows without defining, since an anchor party is a time source a record can cite and the host clock remains one it cannot; key history; and external index, per section 19's fifth entry.

21. License and citation#

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

Cite as:

Stellmacher, G. (2026). AEF 1400: Sealing, Time, and Re-verification, v0.1. 14 August 2026. https://grantstell.com/aef/1400

Cite the version and date, always.