Direct answer

AER-1 and SCITT

AER-1 and SCITT fit together; they are not two answers to the same question. AER-1 records one agent tool call as a portable, checkable receipt. SCITT is a transparency-service architecture: a service design for registering statements so they can be checked against a transparency record. AER-1 names the connection directly: since draft -18, a receipt can carry an external anchor of type scitt, meaning the receipt was registered with a SCITT transparency service, and that registration is what later checkers can evaluate.

AER-1 reference: draft-zambo-aer1 on the IETF Datatracker. SCITT reference: the IETF SCITT working group. Kit and anchor vectors: the AER-1 kit repository.

Updated October 20, 2026.

The scope of each

AER-1: the record of one call

AER-1, IETF Internet-Draft draft-zambo-aer1 by Brennan Zambo, current revision -24, defines the receipt itself: core fields for one tool call, canonical bytes, an output hash, and a verification procedure anyone can run. Its question is narrow: can a stranger check that this saved result is the result that was saved? The receipt is portable: it travels with the work and verifies wherever it lands, with no service involved.

SCITT: the transparency service

SCITT, developed in the IETF SCITT working group, is an architecture for transparency services: how statements are registered, how a service records them, and how checkers consult that record. Its question is about the service and its guarantees: what does registration in this transparency record establish, and how does a checker evaluate it? SCITT does not define the AER-1 receipt for an agent tool call; AER-1 does not define a transparency service.

The anchor type: scitt

Draft -18 and later permit AER-1 anchor types including SCITT registration and RFC 3161 timestamps. An anchor is an external reference attached to a receipt: evidence held outside the producer's own record. A receipt anchored with type scitt points at its registration in a SCITT transparency service. The receipt still verifies on its own, by hash recompute over its canonical bytes. The anchor adds a second, external thing a checker can evaluate.

Anchor outcomes under draft -24

Draft -24, Section 6, governs how evaluating that anchor gets reported. If a checker evaluates the SCITT registration, it reports the real outcome: verified, verification failed, or rejected: unresolvable record. If it does not evaluate the registration, it reports not checked, and it must never report an evaluated outcome for an unevaluated anchor. If the receipt carries no anchor, the anchor state is absent. This vocabulary is what keeps an anchored receipt honest in the hands of a checker that only ran part of the procedure.

When to use both

Cite this draft

Cite AER-1 as the IETF Internet-Draft draft-zambo-aer1, current revision -24, posted October 20, 2026 and expiring April 23, 2027, at datatracker.ietf.org/doc/draft-zambo-aer1.

@misc{zambo-aer1,
  author = {Brennan Zambo},
  title = {AER-1: Agent Execution Receipt, version 1},
  howpublished = {IETF Internet-Draft draft-zambo-aer1-24},
  year = {2026},
  url = {https://datatracker.ietf.org/doc/draft-zambo-aer1/}
}

Honest limits

This page describes the fit as the AER-1 draft states it: SCITT appears in AER-1 as an anchor type, and the SCITT working group drafts govern the service side. It does not summarize SCITT's full architecture, and it claims no conformance for any service. And the standing limit applies to the combination too: a receipt, anchored or not, proves the saved result was not changed after the fact. It never proves the work was correct.

Frequently asked questions

What is the difference between AER-1 and SCITT?

They answer different questions. AER-1 records one agent tool call as a portable, checkable receipt: core fields, canonical bytes, an output hash, and a verification procedure anyone can run. SCITT is a transparency-service architecture from the IETF SCITT working group: how statements are registered with a transparency service and how checkers evaluate that registration. AER-1 defines the receipt; SCITT defines the service.

How do AER-1 and SCITT fit together?

Through an anchor. Since draft -18, an AER-1 receipt can carry an external anchor of type scitt, meaning the receipt was registered with a SCITT transparency service. The receipt still verifies on its own by hash recompute. The anchor adds an external registration a checker can also evaluate, reported under the draft -24 Section 6 vocabulary.

When should I use both AER-1 and SCITT?

Use the receipt alone when checkers can recompute the hash and the question is whether the saved result changed. Add a SCITT anchor when the record also needs standing in a transparency service others consult, for example when a checker who never received the receipt directly needs to evaluate its registration. The anchor is an addition to the receipt, never a replacement for it.

What does a scitt anchor outcome of not checked mean?

It means the receipt carries a scitt anchor and the verifier did not evaluate the registration. Under draft -24 Section 6, not checked is the only honest report for an unevaluated anchor. Verified, verification failed, and rejected: unresolvable record are reports for an evaluated anchor, and absent means the receipt carries no anchor at all.

Where are AER-1 and SCITT specified?

AER-1 is IETF Internet-Draft draft-zambo-aer1 by Brennan Zambo, current revision -24, at datatracker.ietf.org/doc/draft-zambo-aer1/. SCITT is developed in the IETF SCITT working group, at datatracker.ietf.org/wg/scitt/. AER-1 is a draft, not a finalized standard, and a receipt proves the saved result was not changed after the fact, never that the work was correct.

Related