Ardyn Evidence Artifact

The Question

When an autonomous agent acts — executing a tool, making a decision, or modifying state — how does an institution know what actually happened? The question is not whether the agent claims to have done something. It is whether the action left behind a record that can be independently examined, cryptographically verified, and admitted as evidence by a party that did not produce it.

The Ardyn Evidence Artifact answers: what happened, who did it, and can anyone prove it without trusting the issuer?

The Concept

An AEA is the atomic unit of verifiable truth in the Ardyn platform. It is a self-contained, Ed25519-signed cryptographic envelope that records a single event — a tool execution, a governance decision, a state transition, or a hardware attestation. Every AEA carries every byte needed for independent offline re-derivation of its contents. No external fetches, no whispered trust.

An AEA contains:

The aea_kind field classifies the artifact into one of three categories:

• Evidence — EvidenceDdcV1, EvidenceToolExecutionV1
• Governance — GovernanceAuthorizationRequestV1, GovernancePrincipalAuthorizationV1, GovernanceAuthorizationRevocationV1, GovernanceAuthorizationQuorumV1
• Operations — OperationsMergeV1, OperationsTaskClosureV1, OperationsStateTransitionV1, OperationsAuthorizationConsumptionV1

The Data Destruction Certificate (DDC) is a specialized AEA subtype within the Evidence family — aea_kind: EvidenceDdcV1. All DDCs are AEAs. Not all AEAs are DDCs.

Why Existing Approaches Are Insufficient

Three approaches dominate current practice, and each fails a different requirement:

Log files. A server writes a line to a file. The line can be deleted, edited, or backdated by anyone with filesystem access. Logs are not signed, not structured, and carry no cryptographic proof of who produced them. They are testimony, not evidence.

Centralized audit trails. A SaaS platform records events in a database. The records are only as trustworthy as the platform operator. There is no way for a third party to verify that a record has not been altered — the verifier must trust the platform that holds the database.

Blockchain-only approaches. Writing every event to a chain provides immutability but at the cost of throughput, latency, and privacy. Most autonomous systems generate thousands of events per minute. On-chain storage of every event is economically and operationally impractical.

AEAs solve all three: they are cryptographically signed (resisting tampering), self-contained (enabling offline verification), and linked into Ardyn's tamper-evident evidence chain. Optional external anchoring can provide additional public timestamp or inclusion commitment, but is not required for AEA integrity or verification.

The Mechanism

The AEA lifecycle follows a deterministic sequence:

1. Construction. An event occurs — an agent executes a tool, a governance decision is made, a state transition fires. The issuer constructs an AeaEnvelope with the relevant aea_kind, subject, payload, and evidence_refs.

2. Content addressing. The content_digest is computed as SHA-256(canonical_json(subject) + ":" + canonical_json(payload)). The canonical JSON is produced with sorted keys and no whitespace — byte-identical for semantically identical input.

3. Signable payload. A deterministic, colon-separated string is assembled from all envelope fields except the signature itself. This string is the message that will be signed.

4. Signing. The issuer signs the signable payload with its Ed25519 private key. The signature is stored as hex in the signature field.

5. Chain linkage. If this AEA follows a prior artifact, previous_artifact_digest is set to the prior AEA's content_digest, creating a tamper-evident chain.

6. Verification. Any party can re-derive the content_digest from subject + payload, re-derive the signable payload, and verify the Ed25519 signature against the issuer's public key. All three must match.

┌─────────────────────────────────────────────────┐
│                  AEA Envelope                    │
├─────────────────────────────────────────────────┤
│  aea_id:       550e8400-e29b-41d4-a716-...       │
│  aea_kind:     evidence_tool_execution_v1        │
│  tenant_id:    ffcf084a                          │
│  subject:      {"tool": "transfer_funds", ...}    │
│  payload:      {"amount": 5000, "currency": ...}  │
│  content_digest: sha256:a1b2c3...                │
│  signature:    0f1e2d3c...                       │
│  evidence_refs: ["aea_abc123"]                   │
│  previous_artifact_digest: sha256:d4e5f6...       │
└─────────────────────────────────────────────────┘

A Concrete Example

A financial services firm deploys an autonomous agent that processes invoice payments. The agent is configured to attest every payment action through Ardyn.

Scenario: Agent pays invoice #4782 for $12,400.

1. The agent executes pay_invoice with invoice ID 4782 and amount 12400.

2. Ardyn Core constructs an AEA with aea_kind: EvidenceToolExecutionV1.

3. The subject records the tool name and parameters; the payload records the execution result.

4. The AEA is signed with the agent's Ed25519 key and returned.

5. The AEA's content_digest is included in Ardyn's tamper-evident evidence chain, which provides cryptographic linkage between events. Optional external anchoring can provide additional public timestamp or inclusion commitment, but is not required for AEA integrity or verification.

Six months later, an auditor receives the AEA file. The auditor:

• Recomputes content_digest from subject + payload — matches.
• Verifies the Ed25519 signature against the agent's known public key fingerprint — matches.
• Verifies the chain linkage by confirming previous_artifact_digest references a valid prior AEA — confirmed.
• Concludes: the agent did pay invoice #4782 for $12,400 on the recorded timestamp. No trust in Ardyn required.

What the Layer Does Not Do

The AEA layer does not:

• Make policy decisions. An AEA records what happened. It does not evaluate whether the action should have been permitted. That is Axiom's domain.
• Assign trust scores. An AEA is a single fact. Aggregation into trust profiles is the ATP layer's responsibility.
• Guarantee correctness of the action. An AEA proves the agent executed a tool and produced a result. It does not prove the result was correct — only that the agent produced it.
• Provide real-time authorization. An AEA is an evidentiary record, not a pre-execution gate. Pre-execution authorization is handled by Forge interlocks and Axiom policy evaluation.
• Replace hardware attestation. An AEA can carry hardware attestation evidence in its payload, but the AEA envelope itself is a software-level artifact. The hardware root of trust lives in the sovereign compute layer.

How It Relates to Other Layers

Upstream (producers):

• Forge issues governance AEAs (authorization grants, revocations, quorum decisions) that establish the authority context.
• Axiom produces governance decision AEAs that record ALLOW/BLOCK/ESCALATE outcomes.
• Sovereign compute platforms produce hardware attestation reports that are embedded in AEA payloads.

Downstream (consumers):

• ATP aggregates AEAs into trust profiles — longitudinal views of agent behavior.
• ACTA consumes AEAs to build organizational cognition — operational memory derived from evidence.
• AAECP references AEAs as the evidence substrate for governed autonomous execution.

Lateral: The DDC is a specialized AEA subtype (EvidenceDdcV1) reserved for destruction and state-reversion events. It uses the same envelope, the same signing mechanism, and the same verification path.

Verification

Every AEA supports three independent verification checks:

1. Content integrity. Recompute SHA-256(canonical_json(subject) + ":" + canonical_json(payload)) and compare to content_digest. A mismatch means the payload was altered after signing.

2. Signature validity. Reconstruct the signable payload from the envelope fields, decode the Ed25519 signature, and verify against the issuer's public key. A failed verification means the signature is forged or the envelope was tampered with.

3. Chain continuity. If previous_artifact_digest is set, verify that the referenced prior AEA's content_digest matches. A break in the chain means an artifact was inserted or removed.

All three checks can be performed offline — no network access, no Ardyn gateway, no trusted third party. The AEA carries everything needed.

Implementation Status

The AEA envelope is implemented in crates/evidence-bundle/src/aea.rs (FORGE-11 Phase 1). The AeaEnvelope struct, sign(), verify(), verify_content_digest(), and is_self_consistent() are all implemented and tested. The DDC projection (to_ddc_projection()) provides backward compatibility for existing DDC consumers while native AEA consumers use the envelope directly.

The AeaKind enum currently supports 10 variants across evidence, governance, and operations categories. Additional variants are added as new artifact types are defined.

Continue Learning

Each layer builds on the one before it. Follow the architecture: