Portable Evidence Artifacts for AI Validation

When an auditor asks for proof that your AI validation ran correctly on April 12 at 14:03 UTC, handing them a log line is not an answer. A log line is what you wrote. A portable evidence artifact is what anyone can verify.

The distinction matters under EU AI Act Article 12, which requires "automatically recorded events (logs) during the lifetime" of a high-risk AI system to be kept for a period appropriate for the system. "Appropriate" in practice means the records are still admissible years later, across changes of staff, tooling, and provider. Logs alone fail all three admissibility questions:

• Can a third party verify these were not altered since creation?
• Can they be read without the tooling that produced them?
• Can they be trusted even when the producer refuses to cooperate?

This problem is not unique to AI. The legal profession solved it with signed affidavits, the software supply chain solved it with SBOMs and in-toto attestations, the crypto world solved it with Merkle proofs. AI validation needs the same structural move: stop treating logs as evidence, start emitting signed, portable records.

What portable actually means

Three properties make an artifact portable:

1. Tamper-evident. If anyone changes one byte after creation, verification fails. Hash chains, digital signatures, timestamping services all satisfy this.
2. Self-describing. An outside reader can decode the record without the producer's SDK. JSON with a declared schema plus a public key beats a protobuf only the producing library understands.
3. Verifiable offline or by a third party. The record carries everything needed to verify it. The auditor does not have to call your API, log into your dashboard, or trust your server clock.

A tamper-evident log is only one of three. A signed log is closer. A signed log with a timestamped anchor and a public schema is the artifact.

What the artifact looks like

This is the shape of an Asqav signature record. Every AI agent action (tool call, approval decision, guardrail verdict) produces one of these. No Asqav account required to verify:

{
  "type": "signature",
  "signature_id": "sig_01HVZ...",
  "agent_id": "agt_db_router_prod",
  "agent_name": "database-router",
  "action_id": "act_01HVZ...",
  "action_type": "tools:call",
  "payload": {
    "tool": "database.write",
    "args_hash": "sha256:9f2e...",
    "policy_decision": "approved",
    "approver": "ops-oncall@example.com"
  },
  "signature": "MIIC...",          // ML-DSA-65 over canonical message
  "algorithm": "ML-DSA-65",
  "signed_at": "2026-04-12T14:03:07Z",
  "verified": true,
  "verification_url": "https://api.asqav.com/api/v1/verify/sig_01HVZ...",
  "bitcoin_anchor": {
    "status": "confirmed",
    "bitcoin_tx": "b4a2...",
    "bitcoin_block": 906421
  }
}

Three properties from the list, made concrete:

• Tamper-evident via the ML-DSA-65 signature (NIST FIPS 204) plus the Bitcoin anchor (OpenTimestamps) that puts a commitment of the record into a Bitcoin block. After confirmation, even the producer cannot rewrite the past.
• Self-describing as plain JSON with documented fields, a standard algorithm, and a resolvable verification_url.
• Verifiable offline. Anyone with liboqs or an equivalent ML-DSA library and the agent's public key can verify the signature. The Bitcoin block height is checkable against any public Bitcoin node.

Why Bitcoin, and why not only Bitcoin

OpenTimestamps anchors a Merkle root of many records into one Bitcoin transaction roughly daily. That is cheap, decentralized, and survives as long as Bitcoin does. For EU AI Act retention that spans decades, it removes a single point of failure: no vendor gets to decide that 2029-vintage records can be rewritten.

For industries that also expect a classical Timestamping Authority signature alongside the Bitcoin anchor, Asqav Enterprise adds an RFC 3161 timestamp signed locally with ML-DSA-65 per RFC 9882. Belt-and-braces: your record is verifiable against a Bitcoin block height AND a TSA signature.

Evidence bundles for auditors

One signature record is a single action. An audit covers a session, a day, a framework like Article 12 or DORA Chapter II. The SDK assembles these on demand via asqav.export_bundle(signatures, framework): every signature record in scope, packaged with the framework mapping, per-receipt hashes, and a Merkle root over the set. Auditors receive a JSON bundle they can verify offline.

The same bundle feeds Article 12 traceability, DORA Chapter II evidence, SOC 2 CC7 system monitoring, and ISO 42001 AIMS artifact requirements without reshaping the data per framework.

What this replaces

Three patterns this retires:

• Internal logs with no cryptographic binding. Every log line is a statement of trust in whoever wrote it. Regulators treat these as weak evidence at best.
• Vendor-proprietary audit formats. If only the vendor's SDK can read the record, the evidence dies with the vendor contract.
• Periodic signed snapshots. Snapshots attest to state at a moment. They do not attest to individual actions, which is what regulators actually ask about.

Try it

Create a test agent and verify a signature end to end:

pip install asqav
asqav demo          # produces 4 signed actions against a local dashboard
curl https://api.asqav.com/api/v1/verify/<signature_id>

The verify endpoint is unauthenticated by design. Any auditor, partner, or insurer can hit it with only the signature id. That is what portable looks like.

Deeper reading: Proofs for how the signing pipeline works, Compliance Reports for framework-specific bundles, MCP Governance for MCP-specific evidence patterns.