Attested Execution Framework
What an aer proves
non-normativeThis page is an entrance, not a specification. Where it disagrees with the documents, the documents govern.
A verified attested execution record establishes what a signed archive cannot: not that the work was done right, but that its operator sealed a declared scope for it, that the sealed record of what ran is internally consistent with that scope, and that the result names, item by item, what was not established.
That is deliberately less than “proof the work was done right.” No record format can supply that, and the ones that appear to are asserting it rather than establishing it. What a record can do is make the operator's claims specific, sealed, and checkable for internal consistency, and make the verifier say out loud what it could not check.
The honest floor
What a reviewer holding a verified record can safely say, and what they cannot. This is the framework's most important content, quoted from AEF 1100 section 13 as restated in AEF 1400 section 15.
For a record that is not anchored
“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
“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.”
What neither sentence says
- 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
- whether other records exist
Produce your first record
Five steps against the reference implementation. The current published example verifies as PASS_WITH_QUALIFICATIONS with 12 qualifications, and yours will look the same.
- Clone and install.
git clone https://github.com/0xGrainzy/grantstell-com.git, thennpm install. The reference implementation lives atpackages/aef: producing, sealing, and verifying are about 1,500 lines of TypeScript with no cryptography beyond ed25519 and sha-256. There is a recorded terminal session of exactly this path. - Read what you are about to produce. AEF 1300 defines the record: a declaration sealed before work begins, a digest-chained act log, input and output digests, a role disclosure, and a seal whose boundary covers its own time and anchor. The published example, run-0001, is that structure with real work inside it.
- Produce a record.
npm run aef:runperforms a small real run, reading the published documents and writing a digest manifest, and produces the record of it: the declaration is sealed first, acts are captured, the record is sealed last. Re-running regenerates the example in your clone with new times and a new seal, which is itself instructive: the manifest is byte-identical, the record is not. - Verify it, and read the qualifications.
npm run aef:verifychecks the record, its tampered copy, and the withheld-declaration case. Expect no unqualified pass: the realistic outcome carries qualifications, each naming one thing the verification did not establish. Reading them is the point; they are the framework being honest about itself. The same verifier runs in your browser. - Try to cheat it. Change one character anywhere in
standards/aef/examples/run-0001/aer.jsonand verify again: FAIL at seal-integrity. Then adapt the pattern to your own pipeline, declare, seal the declaration, capture, seal the record, and if you find an input the verifier handles wrongly, file it: the challenge mechanism in AEF 1201 section 8 exists for exactly that, and a confirmed miss becomes a permanent fixture with your name on the entry.
Three ways in, depending on why you came
| You rely on records others produce | Read AEF 1100 section 13, the honest floor above in its original setting, and stop. Everything else in the series exists to make those two sentences true; if they are not enough for your purpose, the framework is not enough for your purpose, and it says so. |
|---|---|
| You build systems that should produce records | Read AEF 1300 for what a record is, then AEF 1200 for what a verifier will do to it. 1301 when a human signs anything, 1400 when records must outlive their keys. The cost page states what producing one actually costs, measured. |
| You review frameworks for a living | Read AEF 1000, the charter, including section 12, the conditions under which this is wrong or unnecessary. Then the challenge record to see how disagreement is handled in practice, and AEF 1900 for the two occasions the series overclaimed and what happened next. The most useful thing you can send back is the input this framework mishandles. |
Where things stand
Ten documents, one published record, a verifier you can run in your browser, and no conformance claim yet: the suite's own coverage declaration states why one cannot honestly be made. The derived state of everything is at /aef/status, and a review freeze is in effect: no new numbered document ships until three external reviewers have responded or 90 days elapse.