centaur-lang

AXR — Agent Execution Receipt

HTTPS made web traffic verifiable. AXR does the same for automated decisions.

What is AXR?

AXR is an open protocol for producing tamper-evident, cryptographically signed records of what an automated workflow did on each execution.

It is not a chatbot. Not a workflow builder. Not a blockchain. Not an AI governance layer.

It is the accountability infrastructure that sits underneath AI agents, workflow engines, and autonomous systems — so that after the fact, anyone can verify exactly what happened.

The Problem

AI systems now book appointments, approve requests, reject customers, and trigger irreversible actions. Most leave no verifiable evidence behind.

After an automated decision, there is often no reliable way to answer:

Which agent made this decision?
What input did it receive?
What decision did it make, and on what basis?
Has the record been altered since?
Why was a customer told no?

Logs exist, but logs are mutable. Dashboards exist, but dashboards show summaries.

Neither provides cryptographic proof.

How AXR Works

Every decision-relevant step in a workflow produces a receipt — a signed JSON object.

Workflow executes
       |
       v
  [ Step 1 ] --> signed receipt --> chained
  [ Step 2 ] --> signed receipt --> chained
  [ Step 3 ] --> signed receipt --> chained
       |
       v
  [ Workflow receipt ] --> closes the chain
       |
       v
  Append-only log file (.jsonl)
       |
       v
  Independent verification (anyone with the public key)

Two types of receipts:

Step receipt — records a single node’s contribution:

{
  "axr_version": "0.2",
  "receipt_type": "step",
  "receipt_id": "uuid",
  "workflow_receipt_id": "uuid",
  "sequence": 3,
  "timestamp": "2026-05-15T07:13:18.123Z",
  "step": {
    "node_name": "The Brain (Logic)",
    "node_type": "n8n-nodes-base.code",
    "logic_version": "5.0 HU",
    "model": null,
    "deterministic": true
  },
  "io": {
    "input_hash": "sha256:...",
    "output_hash": "sha256:...",
    "input_summary": {
      "date": "2026-05-19",
      "duration_minutes": 85,
      "requested_slot_start": "14:00"
    },
    "decision": {
      "status": "ZONE_INCOMPATIBLE",
      "available": false,
      "reason": "DISTANCE_TOO_FAR"
    }
  },
  "previous_receipt_hash": "sha256:...",
  "signature": "base64 Ed25519"
}

Workflow receipt — ties the step chain together:

{
  "axr_version": "0.2",
  "receipt_type": "workflow",
  "receipt_id": "uuid",
  "workflow": {
    "workflow_id": "eco-clean-geo-cluster-booking-hu",
    "workflow_version": "5.0"
  },
  "actor": {
    "agent_id": "eco-clean-booking-hu",
    "operator": "Conen Digital",
    "on_behalf_of": "ECO Clean HU"
  },
  "outcome": {
    "final_status": "ZONE_INCOMPATIBLE",
    "available": false
  },
  "step_chain": ["uuid", "uuid", "uuid", "uuid", "uuid"],
  "chain_root_hash": "sha256:...",
  "previous_receipt_hash": "sha256:...",
  "signature": "base64 Ed25519"
}

Chains operate at two levels:

Within a run — step receipts link to each other via previous_receipt_hash
Across runs — workflow receipts link to each other, forming a continuous agent history

A deletion or alteration anywhere in either chain breaks verification.

Cryptographic Guarantees

Guarantee	Mechanism
Tamper-evidence	Changing any byte invalidates the Ed25519 signature and breaks the SHA-256 hash chain. Two independent mechanisms catch the same tampering.
Deletion-evidence	Removing a receipt from the middle of a chain breaks hash linkage at the gap. The `step_chain` ID list also stops matching.
Reproducibility	Canonical JSON serialization (lexicographic key sort at every level). Same input always produces same hash.
Version coexistence	0.1 and 0.2 receipts verify together in one log. The verifier branches on `axr_version`.

What AXR deliberately does not provide in 0.2:

Hardware-level key protection (operator-level PEM file)
Central agent identity registry (agent_id is self-declared)
Reproducibility for non-deterministic steps (step.model records the model, but replay is out of scope)

See SECURITY.md for the full threat model.

Quick Start

Generate a key pair

mkdir axr
openssl genpkey -algorithm ED25519 -out axr/signing-key.pem
openssl pkey -in axr/signing-key.pem -pubout -out axr/public-key.pem
chmod 600 axr/signing-key.pem

Verify a receipt log

node lib/axr-verify.js ./axr/receipts.jsonl ./axr/public-key.pem

Output:

------------------------------------------------------------------------
File:      ./axr/receipts.jsonl
Receipts:  20 total  (3 workflow, 17 step)
Versions:  0.1: 13, 0.2: 7
------------------------------------------------------------------------
  2026-05-14T07:13:18Z  v0.1    SLOT_TAKEN_ON_RECHECK     5 steps
  2026-05-14T09:45:22Z  v0.1    ANCHOR_BOOKING            6 steps
  2026-05-14T19:02:11Z  v0.2    SLOT_AVAILABLE            6 steps
------------------------------------------------------------------------
RESULT: THE ENTIRE CHAIN IS VALID.
All signatures verify, all hash chains are continuous, nothing has been modified.

Exit codes: 0 valid, 1 problem found, 2 usage error.

Tamper detection

Modify a single character in any receipt:

  [ERROR] step a3f8...: INVALID SIGNATURE — receipt was modified after signing
  [ERROR] workflow 7b2c...: step 4 previous_receipt_hash does not match — chain broken

RESULT: 2 PROBLEM(S) FOUND. The chain is corrupted or tampered.

Two independent mechanisms catch the same edit. Signature failure proves the content changed. Chain breakage proves where.

Repository Structure

axr/
├── README.md               This file
├── AXR-SPEC-0.2.md         Protocol specification
├── ROADMAP.md               Protocol evolution plan (0.3 → 1.0)
├── WHY-AXR.md               Motivation and positioning
├── SECURITY.md              Threat model and disclosure policy
│
├── lib/
│   ├── axr-core.js          Canonical serialization, hashing, signing
│   ├── axr-generator.js     Reference receipt generator (library)
│   └── axr-verify.js        Standalone chain verifier (CLI)
│
├── integrations/
│   └── n8n/
│       └── axr-n8n-node.js  Code-node template for n8n workflows
│
├── examples/
│   ├── simple-agent/        Minimal receipt generation
│   ├── tamper-demo/         Tamper detection demonstration
│   └── eco-clean-hu/        Production pilot reference
│
├── demo/
│   ├── receipts/            Sample receipt logs
│   ├── screenshots/         Verification output
│   └── gifs/                Animated demos
│
├── docs/                    Extended documentation
├── scripts/                 Utility scripts
└── site/
    └── landing-page.tsx     Protocol landing page

Zero external dependencies. All code uses Node.js built-in crypto and fs modules.

n8n Integration

AXR ships with a reference Code-node template for n8n workflows. See integrations/n8n/axr-n8n-node.js.

The template is not a packaged n8n node — you paste it into a Code node at the end of your workflow, customize the configuration section, and the workflow starts producing signed receipts on every execution.

Requirements:

n8n 2.8.3+ (self-hosted, Docker)
NODE_FUNCTION_ALLOW_BUILTIN=crypto,fs environment variable
Bind-mounted directory for the receipt log and signing key

Steps:

Identify your receipt-bearing nodes (decisions and state changes only)
Add __axr_input markers to each receipt-bearing node
Paste the generator Code node at the end of your workflow
Customize the CONFIG section (agent identity, workflow ID, step nodes)
Add a Switch node to route by __axr.final_status

Full guide in the template file header.

Production Evidence

AXR 0.2 has been running in production since 2026-05-14 on a home-services booking workflow processing real customer requests.

During deployment, the protocol uncovered three pre-existing workflow bugs — none caused by AXR, all silently misinforming customers:

A workflow firing all response branches on every run (success + error + conflict simultaneously)
Rejected customers receiving {"error": "unknown_error"} instead of the actual rejection reason
Recheck conflicts producing HTTP 200 responses with empty bodies

All three were invisible without receipts. All three became visible because the receipts produced an honest record that contradicted what the workflow was telling customers.

Full details in AXR-SPEC-0.2.md section 8 and WHY-AXR.md.

Current Status

AXR 0.2 is suitable for:

Deterministic workflows (booking, pricing, eligibility, approval)
Single-operator, single-agent deployments
Audit trails where operator-level key protection is acceptable

AXR 0.2 is not yet suitable for:

Generative (LLM) steps where reproducibility matters
Cross-operator agent identity verification
Customer-facing key custody

See ROADMAP.md for the path from 0.3 to 1.0.

Contributing

AXR is early-stage and evolving. The protocol is open under MIT — adopt, adapt, fork, or build on it.

If you deploy AXR on your own workflow:

Open an issue with the workflow type and any rough edges. Real-world adoptions inform the 0.3 spec.
Verify your chain and share the result. Independent verification is the strongest evidence the protocol works beyond its reference implementation.

PRs welcome on: documentation clarity, additional integrations (non-n8n orchestrators), verifier improvements, and example workflows. Protocol-level changes (receipt schema, signing algorithm) are version-numbered and discussed in issues first.

Citation

Conen, C. and Claude (Anthropic). 2026.
"AXR — Agent Execution Receipt: Protocol Specification, Version 0.2."
https://github.com/Centaur-Lang/centaur-lang

Acknowledgements

AXR was designed and built collaboratively under the CENTAUR model — human and AI working as one engineering pair, where each side contributes what it does best.

The reference deployment runs on ECO Clean HU’s booking infrastructure, operated by Conen Digital.

This site is open source. Improve this page.