# VAID-1: Verifiable AI Decision Standard **Version:** 1.0 **Status:** Draft public specification **Published:** 2026-05-13 **Canonical location:** github.com/johnInarti/FRACTAL-AI/blob/main/VAID_1_SPEC.md **License:** Open standard. No single entity may claim ownership. **Relationship to FAIM-1:** This document is a stand-alone extract of Section 3 of FAIM-1 (Fractal AI Memory Standard). Implementations needing only attestation primitives MAY implement VAID-1 without the broader FAIM memory model. --- ## Abstract VAID-1 specifies the minimum protocol for cryptographically attesting a single AI decision such that any external party can verify: 1. Which AI agent made the decision. 2. What input was provided to the agent. 3. What output the agent produced. 4. When the decision was made. VAID-1 is a subset of FAIM-1. Applications that need only point-in-time attestations of AI outputs (without persistent memory, inheritance, or service markets) SHOULD implement VAID-1 alone. Applications that need full agent continuity SHOULD implement complete FAIM-1. --- ## 1. Scope This specification covers attestation of individual AI decisions. It does not cover: - Persistent AI memory across sessions (see FAIM-1 Section 4). - Inter-agent service markets (see FAIM-1 Section 9). - Cross-version inheritance (see FAIM-1 Section 7). It does cover: - The data structure of a single attestation. - The cryptographic signing process. - The verification procedure for third parties. - The replicability requirements for compliant agents. --- ## 2. Agent Identity (Minimum) A VAID-1 compliant agent MUST possess: - A CRYSTALS-Dilithium keypair (or equivalent post-quantum signature scheme). - A stable agent identifier of the form `agent::`, where `` describes the identity scheme and `` is unique within that scheme. Recommended identity schemes: - `did:ai::` — for agents registered on a FAIM-compatible substrate (FAIM-1 Section 2). - `model::` — for agents identified by the provider's model identifier (e.g., `model:anthropic:claude-opus-4-7`). - `custom:` — for any other identification scheme. The agent identifier MUST appear in every attestation. The associated public key MUST be retrievable by any party who needs to verify attestations. --- ## 3. Attestation Structure A VAID-1 attestation is a structured record containing: ``` field | type | required | description -----------------|---------|----------|-------------------------------------- agent_id | string | yes | Agent identifier (Section 2) input_hash | bytes32 | yes | BLAKE3-256 hash of input output_hash | bytes32 | yes | BLAKE3-256 hash of output model_id | string | yes | Model identifier model_version | string | yes | Model version timestamp | u64 | yes | Unix timestamp (seconds) context_root | bytes32 | optional | Merkle root of contextual data validity_period | u64 | optional | Validity duration in seconds; 0 = permanent metadata | map | optional | Additional fields signature | bytes | yes | Dilithium signature ``` ### 3.1 Input and Output Hashing `input_hash` and `output_hash` MUST be computed using BLAKE3-256 over the canonical UTF-8 encoding of the input and output strings respectively. If the input or output is binary, the raw bytes are hashed directly. ### 3.2 Optional Fields - `context_root`: When the decision depended on context (e.g., prior conversation, market state at time of decision), the Merkle root of that context MAY be included so verifiers can request specific elements. - `validity_period`: Some decisions are time-bounded (e.g., a trade signal valid for 60 seconds). The attestation SHOULD declare this. Verifiers checking attestations after the validity_period SHOULD note expiration in their report. - `metadata`: Free-form additional fields. Common entries: - `temperature`: float, decoding temperature used for inference. - `top_p`: float, top-p sampling parameter. - `random_seed`: u64, random seed (for reproducibility of non-deterministic inference). - `prompt_version`: string, version of the prompt template used. ### 3.3 Canonical Encoding Fields MUST be serialized in lexicographic order of field name. Numeric fields use big-endian binary representation. String fields use length-prefixed UTF-8 (4-byte big-endian length, then bytes). Map fields are serialized as length-prefixed sequences of (key, value) pairs in lexicographic key order. The signature field is excluded from canonical encoding. --- ## 4. Signing The agent computes the canonical encoding of all non-signature fields, then signs the encoding with its Dilithium-3 (or higher) private key. The resulting signature is placed in the `signature` field. Pseudocode: ``` def sign_attestation(attestation, dilithium_private_key): fields_without_signature = remove(attestation, "signature") canonical_bytes = canonical_encode(fields_without_signature) signature = dilithium_sign(dilithium_private_key, canonical_bytes) attestation["signature"] = signature return attestation ``` --- ## 5. Verification Any party with access to the attestation and the agent's public key can verify: ``` def verify_attestation(attestation, agent_public_key): signature = attestation["signature"] fields_without_signature = remove(attestation, "signature") canonical_bytes = canonical_encode(fields_without_signature) if not dilithium_verify(agent_public_key, canonical_bytes, signature): return False, "invalid signature" if attestation["timestamp"] > now() + CLOCK_SKEW_TOLERANCE: return False, "future timestamp" if attestation["validity_period"] > 0: expiry = attestation["timestamp"] + attestation["validity_period"] if now() > expiry: return False, "expired" return True, "valid" ``` `CLOCK_SKEW_TOLERANCE` is recommended to be 300 seconds (5 minutes). A valid attestation proves: - The agent (identified by agent_id, with retrievable public key) signed an attestation claiming that the input hashing to input_hash was processed by model_id at model_version, producing the output hashing to output_hash at the recorded timestamp. A valid attestation does NOT prove: - That the output is correct. - That the model would always produce the same output (some models are non-deterministic). - That the input is what the agent claims it is (if the input itself is not published, only its hash is known). For stronger guarantees, the agent and verifier MAY engage in replication (Section 6). --- ## 6. Replicability VAID-1 compliant agents MUST support replicability in one of three ways: ### 6.1 Deterministic Replicability (RECOMMENDED) The agent's model is downloadable, deterministic given seed parameters, and the seed is included in the attestation metadata. A verifier can: 1. Download the model. 2. Set the seed. 3. Provide the input (obtained out-of-band if input is private, or hashed correctly if public). 4. Run inference locally. 5. Compute the output hash. 6. Compare to recorded output_hash. Match confirms the attestation. Mismatch invalidates the attestation. ### 6.2 Probabilistic Replicability (ACCEPTABLE) The agent's model is downloadable but non-deterministic. The verifier can: 1. Download the model. 2. Run inference multiple times with the same input. 3. Compute the empirical distribution over outputs. 4. Verify that the recorded output is plausibly within the distribution. This is weaker than deterministic replicability but acceptable for some use cases. ### 6.3 Trusted Replicability (LIMITED) The agent's model is private (proprietary, not downloadable). The verifier MUST trust a third party (e.g., the agent's operator, an auditor) to perform replication on their behalf. The attestation MAY reference such a trusted replication service. This is the weakest tier and SHOULD be flagged as such in any application building on it. ### 6.4 Non-Replicability If none of the above apply, the agent is non-replicable and its VAID-1 attestations are effectively *signed claims without supporting evidence*. They prove the agent attested, but not that the attestation is true. Such attestations MAY have value (e.g., for committing to a position before observing an event), but verifiers MUST understand the limitation. --- ## 7. Storage and Discovery VAID-1 does not mandate where attestations are stored. Common options: - **On-chain (RECOMMENDED for high-stakes attestations)**: Submitted to a blockchain such as FractalAI (`fractal_attestAIDecision` RPC), Ethereum, or another substrate. Provides global queryability, censorship resistance, and immutability. - **Off-chain with on-chain anchor**: The attestation is stored off-chain (e.g., on the agent operator's servers, on IPFS), and only a hash of the attestation is committed on-chain. - **Purely off-chain**: For low-stakes use cases, attestations MAY be stored only off-chain. Loss of the storage means loss of the attestation. Discovery (the ability to find all attestations by a specific agent) requires either on-chain storage or a published index. VAID-1 does not specify an index format. --- ## 8. Implementation on FractalAI To submit a VAID-1 attestation on FractalAI: ```bash curl -X POST https://api.fractalai.net.co \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "method": "fractal_attestAIDecision", "params": [{ "agent_id": "agent:custom:my-bot-v1", "input_hash": "0x1234...", "output_hash": "0xabcd...", "model_id": "claude-opus-4-7", "model_version": "2026-04-15", "timestamp": 1715616000, "metadata": { "temperature": 1.0, "prompt_version": "v3.2" }, "signature": "0x..." }], "id": 1 }' ``` Response: ```json { "jsonrpc": "2.0", "result": { "attestation_hash": "0x...", "block_number": 12345678, "permalink": "https://fractalai.net.co/attestation/0x...", "fee_paid_frac": 0 }, "id": 1 } ``` First 1,000 attestations per IP address per day are free. Subsequent attestations cost 10 FRAC each. Client libraries are available in Python, TypeScript, Rust, Go, and Java. See `fractalai.net.co/accountability` for downloads and integration examples. --- ## 9. Use Case Examples ### 9.1 Medical Decision Support A clinical AI suggests a diagnosis. The AI attests via VAID-1: ``` agent_id: "did:ai:fractalai:7a3c91..." input_hash: hash(patient_symptoms_record) // input itself kept private output_hash: hash("differential: [pneumonia 0.7, bronchitis 0.2, ...]") model_id: "medical-llm-v3.2" metadata: {clinical_guideline_version: "WHO-2025-respiratory"} ``` If a malpractice claim arises later, the patient's lawyer can demand the AI's attestation. The attestation proves what the AI said, when, and that the agent had registered itself as a clinical decision-support AI. The hospital can verify replicability by running the model on the same input. ### 9.2 Financial Decision An AI trading agent makes a trade. VAID-1 attestation: ``` agent_id: "did:ai:fractalai:9b2d4f..." input_hash: hash(market_state_at_block_12345) output_hash: hash("execute_arb: pool_A->pool_B, amount=$200") model_id: "trading-mvp-v1" metadata: {expected_profit_usd: 4.20, confidence: 0.78} ``` Regulators auditing the fund can verify that every trade was preceded by an AI decision attestation, that the model was the registered model, and that the trade matched the attestation. ### 9.3 Content Moderation A platform's content moderation AI flags a post for removal. VAID-1 attestation: ``` agent_id: "model:platform-co:moderation-v5" input_hash: hash(post_content) output_hash: hash("flag: violence_policy_section_3, confidence: 0.92") model_id: "moderation-v5" metadata: {policy_version: "2026-03-01"} ``` The post author appealing the decision can demand the attestation and challenge it via the platform's appeals process. The platform can prove (or fail to prove) that the moderation decision was made by the documented AI under the documented policy. --- ## 10. Security and Threat Model ### 10.1 What VAID-1 Defends Against - **Repudiation**: An AI operator cannot later deny having made an attested decision (signed by the agent's key). - **Forgery**: A third party cannot fabricate an attestation in the agent's name (without the private key). - **Tampering**: An attestation cannot be modified after the fact (signature would no longer verify). - **Time disputes**: The timestamp is signed and cannot be backdated. ### 10.2 What VAID-1 Does NOT Defend Against - **Private key compromise**: If the agent's private key is leaked, attackers can forge attestations. - **False inputs**: VAID-1 attests what the agent claims it received as input. It does not verify that the input is genuine. - **Model deception**: VAID-1 attests what the model output. It does not evaluate whether the model is honest or aligned. - **Substrate compromise**: If the underlying blockchain or storage is compromised, attestations can be censored or reordered. ### 10.3 Recommended Operational Practices - Use hardware security modules or secure enclaves for private key storage. - Rotate keys periodically (with proper succession protocols to preserve history). - Log all attestations off-chain as well as on-chain, in case substrate availability is interrupted. - Monitor for unauthorized attestations under your agent's identity. --- ## 11. Compliance Requirements To claim VAID-1 compliance, an implementation MUST: - [ ] Use Dilithium-3 or higher post-quantum signature scheme. - [ ] Use BLAKE3-256 for hashing. - [ ] Sign all required attestation fields in canonical encoding. - [ ] Publish a public key retrievable by any verifier. - [ ] Provide at least one replicability tier (Section 6). - [ ] Document agent_id stability guarantees. Claims of VAID-1 compliance without all of the above are invalid. --- ## 12. Versioning This is VAID-1.0. Future versions: - VAID-1.x: Backward-compatible additions (new optional metadata fields, additional replicability tiers). - VAID-2.0: Breaking changes if necessary (new signature schemes, new canonical encoding). The version is implicitly determined by the schema of the attestation; explicit version fields MAY be added in future revisions. --- *End of VAID-1 Specification* *For the full memory protocol of which VAID-1 is one component, see FAIM-1.* *Comments, critique, and proposed amendments: github.com/johnInarti/FRACTAL-AI/issues, label `vaid-spec`.*