AXR Roadmap
AXR is evolving from a production-tested execution receipt system into a broader execution provenance protocol for autonomous systems.
This roadmap reflects the currently planned evolution of the protocol and ecosystem. It is intentionally ambitious — not all items are guaranteed, and the direction matters more than exact timelines.
Guiding Principle
AXR focuses on one foundational capability:
Proving what an autonomous system actually did.
Every roadmap decision should strengthen execution integrity, provenance, inspectability, cryptographic accountability, and operational truthfulness.
Where We Are: AXR 0.2
Shipped. Running in production. The current state:
- Ed25519 signatures + SHA-256 hash chains
- Two-level chaining (step-within-run, run-within-agent)
- Per-step input precision via
__axr_input marker convention
- Version-aware verification (0.1 + 0.2 coexist in one log)
- Standalone verifier, zero dependencies
- Reference n8n integration (Code-node template)
- Three production bugs discovered by the protocol itself (§8 in spec)
Known limitations (honest):
$('NodeName') fragility — cross-node access not guaranteed across n8n versions- Uniform timestamps — all steps in a run get the same timestamp
- No central identity, no generative coverage, no key hardening
- Append-only enforcement is by convention, not mechanism
These limitations are the starting point for what follows.
AXR 0.3 — Generative Awareness
Goal: Expand AXR beyond fully deterministic workflows.
Modern AI infrastructure increasingly includes LLM calls, probabilistic reasoning, agentic orchestration, dynamic tool execution, and runtime planning. AXR 0.2 only covers deterministic steps. 0.3 begins addressing generative reality.
Generative Step Support
Support receipts for non-deterministic AI steps:
- Model identity — exact model ID, version, and provider recorded on every generative step
- Prompt hashing — SHA-256 of the full prompt (system + user + tools), so the input to the model is provable
- Tool-call capture — structured record of which tools the model invoked and what they returned
- Generation metadata — temperature, top-p, token counts, stop reason
- Non-reproducibility flag — explicit acknowledgment that re-running the same input may produce different output; the receipt records what was produced, not what would be
LLM Execution Evidence
Introduce structured evidence fields for post-execution forensic analysis:
- Prompts and system instructions (hashed, not stored in cleartext on the receipt)
- Tool invocations with input/output hashes
- Intermediate reasoning metadata (if the model exposes chain-of-thought)
- Model outputs with completion metadata
The goal is not to make generative steps reproducible — that may be impossible. The goal is to make them inspectable after the fact.
Step-Level Timestamps
AXR 0.2 generates all receipts at workflow-finalization time. Every step receipt carries the same timestamp. 0.3 aims to support:
- Independent per-step timestamps via the
__axr_input marker (each marker records its own write time)
- Per-step temporal ordering in the verifier
- Improved execution replay and latency analysis
Improved Marker Propagation
Reduce dependence on runtime-specific node access patterns ($('NodeName').all()):
- Cleaner input propagation that doesn’t depend on node names at runtime
- Less fragile runtime coupling
- Improved compatibility across workflow engines (not just n8n)
This directly addresses known limitation §7.2 from the 0.2 spec.
Enhanced Verifier Diagnostics
Improve verifier output for debugging and audit:
- Chain visualizations (ASCII or structured output)
- Step-diff inspection (what changed between two runs)
- Tamper localization (which specific field was modified)
- Receipt lineage graphs
AXR 0.4 — Distributed Provenance
Goal: Move from isolated single-agent chains toward interconnected autonomous-system provenance.
Multi-Agent Chain Linking
Support provenance relationships across multiple agents, workflows, and runtimes:
- Agent A authorizes Agent B to execute a task → both execution histories become cryptographically linked
- Delegated actions carry a provenance reference back to the authorizing chain
- Cross-workflow receipt references (one workflow’s output triggers another; the receipt chains link)
Distributed Verification
Support independent verification across separate environments, organizations, and federated systems:
- Verifier works with partial chain segments (not just complete logs)
- Cross-organizational receipt exchange format
- Trust anchoring without requiring shared infrastructure
Transparency Log Compatibility
Research compatibility with existing transparency-log architectures:
- Certificate Transparency (RFC 6962) — append-only Merkle-tree logs
- SCITT (Supply Chain Integrity, Transparency and Trust) — IETF draft for signed statements
- Append-only trust ledgers — publicly auditable execution history
This is research, not committed. The question is whether AXR receipts can be anchored in existing transparency infrastructure without requiring AXR-specific infrastructure.
Remote Verifier APIs
Allow external systems to validate receipts, query chain integrity, and confirm receipt authenticity without direct filesystem access:
- REST API for single-receipt verification
- Chain-segment verification endpoint
- Receipt lookup by
workflow_receipt_id or customer_ref
AXR 0.5 — Runtime Independence
Goal: Make AXR runtime-agnostic. AXR should not depend on n8n, or any single orchestration engine.
Workflow Engine Integrations
- n8n (reference, already shipped)
- Temporal
- Airflow
- Prefect
Agent Framework Integrations
- LangGraph
- CrewAI
- OpenAI Agents SDK
- AutoGen
- Claude Agent SDK
Infrastructure Targets
- Kubernetes jobs
- Serverless runtimes (Lambda, Cloud Functions)
- Container workflows
- Edge execution environments
The protocol specification (receipt schema, hashing, signing) remains identical across all runtimes. Only the generator implementation varies per platform.
AXR 1.0 — Stable Protocol
Goal: Establish AXR as a mature, stable execution provenance protocol with a frozen specification.
Protocol Freeze
Stable, versioned specification for:
- Receipt schemas (step + workflow)
- Hashing rules (canonical serialization + SHA-256)
- Signing behavior (Ed25519)
- Verifier semantics (what constitutes a valid chain)
- Version negotiation (how old and new receipts coexist)
Breaking changes after 1.0 require a major version bump.
Reference compatibility suite that any generator or verifier implementation can run against:
- Canonical serialization test vectors
- Known-good receipt chains with expected verification results
- Known-bad chains (tampered, deleted, reordered) with expected error output
- Cross-version compatibility tests (0.1 + 0.2 + 1.0 in one log)
Independent Verifier Implementations
Encourage and validate verifier implementations in multiple languages:
- JavaScript (reference, already shipped)
- Rust
- Go
- Python
- Java
Single-implementation trust dependence is a vulnerability. A protocol is only credible if multiple independent implementations agree on verification results.
Cryptographic Hardening
- Key rotation — rotate signing keys without breaking chain continuity; the rotation event itself becomes a signed receipt
- HSM integration — hardware security module support for signing operations
- Vault support — HashiCorp Vault, AWS KMS, GCP KMS for key storage
- Remote signing — signing key never leaves a secure enclave; the generator sends the canonical form and receives the signature
- Threshold signatures — require N-of-M signers for high-stakes receipts (irreversible actions, large financial transactions)
Research Directions
These are active exploration areas, not committed roadmap items. They represent open problems that AXR may or may not address.
Probabilistic Replay
Can partially non-deterministic workflows become reproducible enough for forensic verification?
This is an open problem. Potential approaches:
- Prompt canonicalization (normalize prompt formatting so semantically identical prompts produce identical hashes)
- Tool execution capture (record every tool call’s input and output, enabling replay without re-calling external systems)
- Deterministic inference environments (fixed seeds, quantized models, controlled decoding)
- Inference transcript preservation (store the full model output alongside the receipt, not just its hash)
Agent Memory Provenance
Future AI systems will increasingly maintain persistent memory and context across sessions. Questions:
- How should memory mutations be recorded? (Each write is a state change that could earn a receipt)
- Can memory lineage be verified? (Which facts in an agent’s memory came from which execution?)
- Can autonomous memory systems remain auditable? (If the agent modifies its own memory, who watches the watcher?)
Autonomous Governance
Long-term possibility: cryptographically enforceable execution policy layers.
Example: certain irreversible actions (deleting a customer record, transferring funds above a threshold, sending a legal notice) require a provable approval chain before execution. The approval field on AXR receipts is reserved for this purpose — it is null in 0.2, but the schema slot exists.
Human Approval Evidence
Potential future support for human-in-the-loop accountability:
- Signed authorization checkpoints (a human approves an action; the approval itself becomes a receipt)
- Delegated authority verification (Agent A acts on behalf of Human B; the delegation is provable)
- Approval expiry (an approval is valid for N minutes; the receipt records whether the action occurred within the window)
Non-Goals
AXR does NOT aim to become:
- A blockchain or cryptocurrency protocol
- An AI governance bureaucracy layer
- A centralized identity authority
- A workflow orchestration platform
- A compliance checkbox product
AXR remains focused on execution provenance. The protocol proves what happened. It does not decide what should happen.
Strategic Direction
AXR evolves along three parallel tracks:
| Track |
Purpose |
Current State |
| Protocol |
Stable receipt and verification semantics |
0.2 shipped, production-tested |
| Tooling |
Generators, verifiers, integrations |
n8n reference implementation live |
| Ecosystem |
Community adoption and interoperability |
Pre-adoption; open-sourced |
The protocol layer remains the priority. Tooling follows the protocol. Ecosystem follows tooling.
Final Principle
AXR does not attempt to decide whether autonomous systems should act.
AXR attempts to ensure that if they do, their actions leave verifiable evidence behind.