ProofLink Receipt Standard
An open schema for cryptographically verifiable receipts of autonomous IT actions — so an AI system can prove what it did, not just log it.
v0.1 draft · proposed for community and auditor review · published live receipts at verify.itechsmart.dev
Receipt Schema
{
"receipt_id": "sha256:...",
"timestamp": "ISO 8601",
"actor": "agent-identity:...",
"action": "incident_remediated",
"input": { "alert_id": "...", "severity": "HIGH" },
"policy_decision": {
"arbiter": "approved",
"policy": "HIPAA-minimum-scope"
},
"execution_trace": {
"commands": [...],
"files_modified": [...]
},
"verification_result": { "tests_passed": 3, "tests_failed": 0 },
"rollback_path": "revert:commit:abc123",
"compliance_mappings": ["NIST-AI-RMF-MG-2.2", "HIPAA-164.312(b)"],
"prev_hash": "sha256:...",
"bitcoin_anchor": "opentimestamps:..."
}Fields & Conformance Levels
Core fields are required and present in production receipts today. Extended fields are recommended and roll out across the v0.1 → v1.0 path. A receipt is conformant if it carries all Core fields and a valid prev_hash chain.
receipt_idCoreSHA-256 of the receipt body. Stable, content-addressed identity.timestampCoreISO 8601 UTC instant the action completed.actorCoreIdentity of the agent or service that took the action.actionCoreCanonical action category (e.g. incident_remediated).inputCoreThe trigger: alert id, severity, and originating signal.prev_hashCoreHash of the prior receipt — the tamper-evident chain link.policy_decisionExtendedThe governing policy and its approve/deny verdict before execution.execution_traceExtendedCommands run and files modified — the auditable "what happened".verification_resultExtendedPost-action checks: tests passed/failed proving the fix held.rollback_pathExtendedA concrete revert handle, so any action is reversible.compliance_mappingsExtendedControl identifiers this action satisfies, for auditor mapping.bitcoin_anchorExtendedOpenTimestamps proof — vendor-neutral Bitcoin timestamping of the receipt hash.Tamper-evident chain
Each receipt embeds the prev_hash of the one before it. Altering any historical receipt breaks every hash after it — so the ledger is verifiable by recomputation, not trust.
Independent timestamping
The bitcoin_anchor field carries an OpenTimestamps proof, submitting the receipt hash to decentralized calendars for Bitcoin timestamping — independent of any single vendor, including iTechSmart.
Designed to Map To
The schema is designed so a single receipt provides evidence auditors can map to established controls. Listed alignments describe design intent, not third-party certification.