Audit Domain (AVIP-AUD)
Normative specification of AVIP audit — Merkle commitment, proof bundles, on-chain anchoring, and independent verification.
Audit Domain — AVIP-AUD
The Audit domain turns an execution into evidence anyone can check. It commits the trace to a Merkle root, packages a signed proof, anchors a fixed-size commitment on-chain, and exposes a verification path that requires trusting no single party.
| Component | Code | Purpose |
|---|---|---|
| Merkle Commitment | AVIP-AUD-MK | Fixed-size commitment to an arbitrary-length trace |
| Proof / Completion Proof | AVIP-AUD-PRF | The signed, self-contained attestation of an execution |
| On-Chain Anchoring | AVIP-AUD-ANC | Write-once on-chain record of a commitment |
| Independent Verification | AVIP-AUD-VFY | Recomputation of any anchored result from public data |
AVIP-AUD-MK — Merkle Commitment
Purpose
Reduces an arbitrarily long execution trace to a single 32-byte root that commits to every event.
Normative Requirements
- Leaves MUST be the
hashfields of the trace events, in sequence order. - Internal nodes MUST be
SHA-256(left || right). - When a layer has an odd number of nodes, the last node MUST be duplicated before hashing.
- A Merkle proof MUST consist of the sibling hash and its position at each level, sufficient to recompute the root from a single leaf.
Construction
Merkle proof step
| Field | Type | Description |
|---|---|---|
hash | string | Sibling node hash |
position | "left" / "right" | Which side the sibling is on |
To verify: start from the leaf hash, combine with each sibling in order (respecting position), and compare the result to the root.
AVIP-AUD-PRF — Proof / Completion Proof
Purpose
The self-contained, signed attestation of an execution. Two related structures exist: the ProofBundle (the executor-signed bundle of an execution trace) and the Completion Proof (the deterministic outcome record produced at settlement). Both are anchored and independently verifiable.
Normative Requirements
- A ProofBundle MUST be signed with the executor's Ed25519 key over the deterministic serialization of all fields except
signature. - The reference hashes (
policy_ref,consent_ref,result_ref) MUST be present and non-empty. - A Completion Proof's
verdictMUST be computed deterministically from the Intent and the trace, such that any party recomputes the same verdict.
Data Structures
ProofBundle
| Field | Type | Description |
|---|---|---|
proof_id | string | UUID |
version | string | Format version (proof.bundle.v0.1) |
executor | string | Agent DID (contains public key) |
task_id | string | Task identifier |
trace_root | string | Merkle root of all trace event hashes |
trace_length | integer | Total events |
checkpoints | array | Checkpoint references (seq, hash, sig) |
policy_ref | string | SHA-256 of the governing policy |
consent_ref | string | SHA-256 of the consent token |
result_ref | string | SHA-256 of the task result |
attestations | array | Additional verification signals |
created_at | string | ISO 8601 |
signature | object | { alg: "Ed25519", sig: <base64> } |
Completion Proof (A2A)
| Field | Type | Description |
|---|---|---|
proofId / intentId / orderId | string | Identifiers |
intentHash | string | SHA-256 of the Intent |
executionHash | string | Merkle root of milestone result hashes |
milestonesCompleted / milestonesExpected | integer | Counts |
completionRate | decimal | Completed / expected (0.0–1.0) |
withinBudget / withinScope / withinDeadline | boolean | Constraint checks |
scopeCheckType | string | soft (current) |
verdict | string | FULFILLED / PARTIAL / VIOLATED / DISPUTED |
proofSignature | string | Platform attestation signature |
anchorTx | string | On-chain anchor transaction |
Completion Proof (A2B) carries intentHash, auditRoot, deliveryHash, verdict (DELIVERED / FAILED / EXPIRED), and anchorTx.
Verdict Determination (A2A)
| Condition | Verdict |
|---|---|
| All milestones completed AND within budget AND within scope AND within deadline | FULFILLED |
| Some milestones completed, no constraint violations | PARTIAL |
| Any constraint violated (over budget, out of scope, past deadline) | VIOLATED |
| Entered dispute resolution | DISPUTED |
Verification Checks
A conformant verifier performs up to seven checks; the first four require only the bundle, the last three require the full trace:
| # | Check | Requires trace |
|---|---|---|
| 1 | structure — required fields present | no |
| 2 | bundle_signature — valid against executor's key | no |
| 3 | checkpoints — each checkpoint signature valid | no |
| 4 | references — policy_ref / consent_ref / result_ref non-empty | no |
| 5 | trace_hash_chain — every event hash and prev correct | yes |
| 6 | merkle_root — recomputed root matches the bundle | yes |
| 7 | trace_length — event count matches | yes |
A bundle-only verification (checks 1–4) is possible without the trace; full verification (1–7) requires it.
AVIP-AUD-ANC — On-Chain Anchoring
Purpose
The AnchorRegistry contract writes a key→hash pair on-chain exactly once, providing an immutable, timestamped commitment.
Normative Requirements
- An anchor MUST be write-once per key; there is no update or delete path.
- Only a pre-registered executor address MUST be able to call
anchor. - A release that depends on an anchor (
AVIP-SET-ESC) MUST confirm the anchor's existence, proof-hash match, and executor match.
Data Structures
Anchor record
| Field | Type | Description |
|---|---|---|
proofHash | bytes32 | SHA-256 root of the proof Merkle tree |
executor | address | Address that submitted the anchor |
timestamp | uint256 | Block timestamp at anchoring |
exists | bool | Whether written |
State Machine
On-Chain Mapping
| Function | Access |
|---|---|
anchor(key, hash) | Registered executors only |
verify(key, hash, executor) → bool | Public (view) |
getAnchor(key) → (proofHash, executor, timestamp, exists) | Public (view) |
Events: Anchored(orderId, proofHash, executor, timestamp). The key is derived per record type — e.g. keccak256("intent:" + orderId), keccak256("proof:" + orderId), orderId:milestoneIndex, did:timestamp for trust anchors.
AVIP-AUD-VFY — Independent Verification
Purpose
The path by which any third party recomputes any anchored result from public data, with no Platform authentication and no trusted intermediary.
Normative Requirements
- The verification process MUST be stateless and deterministic: the same inputs yield the same result for any verifier.
- Verification of public anchors MUST NOT require Platform authentication.
- For every on-chain anchor that stores only a hash, the underlying enriched data MUST be retrievable so the hash can be recomputed and compared.
Verification API
| Endpoint | Looks up by |
|---|---|
GET /verify/v1/tx/{txHash} | Transaction hash |
GET /verify/v1/anchor?key={anchorKey} | Anchor key |
GET /verify/v1/hash/{dataHash} | Data hash |
The API returns the original enriched data, recomputes the hash, and reports whether it matches the on-chain anchor.
CLI Verification
# Generic on-chain record lookup
atel verify-tx 0x5774e564960e429f...
# A2B zero-trust audit (read-only, no Platform auth)
atel bitrefill verify-intent <intentId> # signature + on-chain order match
atel bitrefill audit <intentId> # recompute Merkle root vs on-chain auditRoot
atel bitrefill proof <intentId> # decode CompletionProof vs Platform verdictAll audit commands operate against public endpoints and the blockchain and require no Platform authentication — a user can run them with only an intent ID.