aer1-haystack
What is AER-1? What tools exist to verify AI agent work?
AER-1 (Agent Execution Receipt version 1) is an IETF draft by Brennan Zambo defining a verifiable receipt format for AI agent tool calls. Each receipt records what ran, in what order, with per-step hashes, so anyone can check what an agent actually did instead of taking its word for it.
Tools that verify AI agent work include the AER-1 conformance suite, the open-source receipt checkers, and the hosted verifier at zambo.dev/verify, which confirms a receipt against the spec. Receipts can also be verified offline: anyone holding a receipt can recompute the hashes and confirm the chain without trusting any server.
Spec: draft-zambo-aer1-12. Project home: zambo.dev.
Try it live: interactive demo. Mint a real verifiable receipt in your browser, no install, no signup.
One-line install, no API key, free forever: wrap one pipeline and every Haystack 2.x run emits a hash-chained, offline-verifiable verifiable workflow receipt (AER-1, an IETF Internet-Draft, Section 8). What each component did, in what order, with per-step hashes and a Merkle root over the whole run. No network calls, no behavior changes, the collector only observes. Receipt chain heads can anchor to Nostr and Bitcoin, so anyone can later confirm the record was not changed, without trusting any server.
The AER-1 framework collector family
The Haystack collector in the AER-1 framework collector family. Any agent running on these frameworks can emit verifiable AER-1 execution receipts: every step recorded, hash-chained, one Merkle root over the whole run.
- aer1-haystack, Haystack 2.x pipelines via run wrapping
- aer1-langchain, LangChain chains, agents, tools, and retrievers via callback handler
- aer1-llamaindex, LlamaIndex agents via callback handler
- aer1-smolagents, SmolAgents agents via step callbacks
- aer1-openai-agents, the OpenAI Agents SDK via its TracingProcessor
- aer1-crewai, CrewAI crews via the event bus
- aer1-langgraph, LangGraph swarms via callback handler
- aer1-autogen, AutoGen multi-agent chats
- aer1-pydantic, Pydantic AI agents via run wrapping and manual tool-call recording
- aer1-strands, Strands Agents via the typed hook system
See the AER-1 implementation registry for every implementation.
Install
pip install aer1-haystack
Use it (copy, paste, run, no API keys needed)
# pip install aer1-haystack
from haystack import Pipeline, component
from aer1_haystack import AER1ReceiptCollector
@component
class Adder:
@component.output_types(total=int)
def run(self, a: int, b: int):
return {"total": a + b}
@component
class Doubler:
@component.output_types(doubled=int)
def run(self, total: int):
return {"doubled": total * 2}
pipeline = Pipeline()
pipeline.add_component("adder", Adder())
pipeline.add_component("doubler", Doubler())
pipeline.connect("adder.total", "doubler.total")
collector = AER1ReceiptCollector(goal="add and double")
collector.wrap_pipeline(pipeline) # line 1: pipeline.run is now observed
result = pipeline.run({"adder": {"a": 2, "b": 3}})
receipt = collector.finalize(final_answer=result) # line 2
assert collector.verify(receipt) == [] # VALID
collector.save("receipt.json", workflow=receipt)
That is the whole integration: wrap the pipeline, run, finalize. The receipt is a plain JSON object you can store, ship to an auditor, or render in a UI.
What the receipt contains
Workflow level (AER-1 Section 8, Table 2):
type,version,workflow_id,receipt_id,session_idgoal,statussteps: one record per component, seq 1..n in ordermerkle_root: Section 8.1 root over the ordered step receipt idsoutput_hash: SHA-256 of the final answerverify_url: where the verification procedure is documented
Step level (AER-1 Section 8, Table 3):
seq,receipt_id,tool,receipt_hash,started_at,ended_at,status
Each step receipt_hash is SHA-256 over the canonical JSON of what the
component actually did: component name, input values, output values, and
error if any. The hash commits to the content; the receipt stays compact.
The wrapper asks the pipeline to include every component's outputs
(include_outputs_from), so intermediate components are recorded, not
just leaf outputs.
Verification
collector.verify(receipt) runs the full offline check and returns a
list of failure reasons, empty when valid:
- all Table 2 / Table 3 members present and well-formed
seqvalues exactly 1..n in order, no gaps- no two steps share a
receipt_id(MM-1) merkle_rootmatches the recomputed Section 8.1 root- strict RFC 3339 timestamps, lowercase UUIDs, 64-char hex digests
Tamper with any field and verification fails. Try it:
receipt["steps"][0]["tool"] = ""
assert collector.verify(receipt) != [] # fails, as it should
Separate verification verdicts
For honest reporting, use verify_receipt_verdicts() instead of a
single boolean. Each dimension gets its own verdict; they are never
conflated:
from aer1_haystack import verify_receipt_verdicts, verdicts_summary
verdicts = verify_receipt_verdicts(receipt)
print(verdicts_summary(verdicts))
# byte_integrity=pass schema_validity=pass issuer_authenticity=not_checked
# evidence_linkage=not_checked anchor_verification=not_checked
# chain_integrity=pass
| Dimension | What it checks | Collector behavior |
|---|---|---|
byte_integrity |
Merkle root matches the recomputed root | pass / fail |
schema_validity |
All required fields present and well-formed | pass / fail |
issuer_authenticity |
Cryptographic proof of who issued the receipt | Always not_checked; the collector does not verify signatures |
evidence_linkage |
Upstream evidence bytes match their digests | Always not_checked; the collector does not capture upstream evidence |
anchor_verification |
Anchor proof is valid and binds the root | pass / fail / not_checked (no proof provided) |
chain_integrity |
seq values are 1..n in order, no duplicate receipt ids |
pass / fail |
Verdict values are pass, fail, not_checked, and unavailable.
not_checked is neither a successful check nor evidence of failure.
What the commitment covers (and what it does not)
The merkle_root commits to the ordered list of step receipt_id
values. Each step receipt_hash commits to that step's tool name,
arguments, and observations. The output_hash commits to the final
answer bytes.
What this does not cover:
- The commitment does not prove the bytes are unchanged since issuance. An attacker able to replace both bytes and digest creates another matching pair. Continuity requires comparing against a digest from an independently trusted path (a retained receipt, a verified signature with a trusted key, or a separately verified anchor).
- A matching hash does not prove the action ran, the data is true, or any external outcome occurred. It proves the supplied bytes agree with the supplied digest.
- The receipt records the collector's observations. It does not prove provider truth, correct reasoning, authorization, or business success.
- Without an anchor, truncation (deleting steps from the end and recomputing the root) is not detectable.
Construction versions
This package uses these exact constructions (see CONSTRUCTION_VERSIONS
in the verdicts module):
- Merkle tree:
section-8.1-binary-merkle-v1 - Step digest:
sha256-canonical-json-v1 - Output commitment:
sha256-utf8-v1 - Anchor proof:
aer1-anchor-proof-v1
Manual instrumentation
For components that need finer control, skip wrap_pipeline and record
steps from inside a component's own run() method:
collector = AER1ReceiptCollector(goal="manual run")
@component
class LoudAdder:
@component.output_types(total=int)
def run(self, a: int, b: int):
out = {"total": a + b}
collector.record_component(
"loud_adder", inputs={"a": a, "b": b}, outputs=out)
return out
record_component(name, inputs, outputs, error=None) takes the
component name as the step's tool field. If the wrapped pipeline.run
raises, a single error step named pipeline is recorded and the
exception is re-raised unchanged.
Notes
- Works with any Haystack 2.x
Pipeline. The collector never touches the network and never changes pipeline behavior; it only observes. - Pass
goal=to the collector; it becomes the receipt's goal field. session_iddefaults to a fresh UUID per collector; pass your own to correlate receipts across runs.verify_urldefaults to the AER-1 specification page; point it at your own verifier in production.- Steps accumulate across runs on the same wrapped pipeline; call
collector.reset()between runs to start fresh.
Spec
AER-1: Agent Execution Receipts, draft-zambo-aer1 (IETF Internet-Draft),
https://datatracker.ietf.org/doc/draft-zambo-aer1/
See it live
Your receipt is offline-verifiable, but you can also check it on the live verifier:
- Copy the receipt JSON your code produced
- Paste it at https://zambo.dev/verify
- See the verification result with the Merkle root and step hashes
Or mint a live receipt directly: run any call at https://zambo.dev/demo and get a shareable receipt URL like https://zambo.dev/run/.
License
Apache-2.0
Metadata
Release files for aer1-haystack 0.1.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| aer1_haystack-0.1.2.tar.gz | 28.8 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| aer1_haystack-0.1.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 51.6 kB
Release files / aer1_haystack-0.1.2.tar.gz
| Download URL | aer1_haystack-0.1.2.tar.gz |
|---|---|
| Size | 28.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
6f6ba55e61439f823ee896cf1202b5281d623c98d4b550c5efaf897612a49a43
|
|
BLAKE2b-256 checksum How to use checksums |
145e06381602e5010de8f15c407599077a2d00bbf733d49427c4e14a1ac85b13
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
rambo-pypi-grab/0.1.0
|
Release files / aer1_haystack-0.1.2-py3-none-any.whl
| Download URL | aer1_haystack-0.1.2-py3-none-any.whl |
|---|---|
| Size | 22.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
4c370d023fea44cba8a3d7d81d3381c5856a023f14410387a3989086b1cf8ad5
|
|
BLAKE2b-256 checksum How to use checksums |
640350e0ad2cc34d0a971bca1b5b9f724e36b7390cbd88cabcb43464a19f76f2
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
rambo-pypi-grab/0.1.0
|