DEV Community: VeritasChain Standards Organization (VSO)

Give Your AI a Black Box: A Verifiable Decision Log in ~150 Lines of Python

VeritasChain Standards Organization (VSO) — Tue, 09 Jun 2026 01:45:41 +0000

In late May 2026, attackers took over more than 20,000 Instagram accounts by asking Meta's AI support assistant to add a recovery email to accounts they did not own. No exploit code. The assistant made a security decision — this email change is authorized — thousands of times, and the trail it left behind was not built to be examined by anyone outside the company.

That is a decision-provenance problem, and it is different from the content-provenance problem (C2PA, SynthID) that gets most of the attention. The question is not "where did this image come from?" It is "can someone prove what an automated system decided — when, on what inputs, under what logic — and prove the record wasn't quietly altered or trimmed?"

Most systems answer that question with logs. But a log is not a black box. In this post we'll build one that is, in a small amount of Python, using the event model from the VeritasChain Protocol (VCP) — an open spec for decision provenance in algorithmic trading. The same four properties apply to any high-stakes automated decision.

A record only behaves like an aircraft's black box when it has four properties ordinary logging does not:

Tamper-evidence an outsider can check (hash chain)
Independent verifiability (public-key signatures, not shared secrets)
Omission detection (commit to the completeness of the set, not just each entry)
External anchoring (publish commitments somewhere the operator can't rewrite)

We'll implement each one. The only dependency beyond the standard library is cryptography:

pip install cryptography

The event model

VCP events have a three-layer shape: a header (who/what/when), a payload (the decision-specific data), and a security block (the cryptographic glue). A few rules worth internalizing up front: IDs are UUIDv7 (RFC 9562) so they sort chronologically; financial values are strings, never floats, so precision survives serialization; and account IDs are pseudonymized before they're ever written, which matters for GDPR.

Here's a real SIG (signal) event — an algorithm deciding to act:

{
  "header": {
    "event_id": "01934e3a-7b2c-7f93-8f2a-1234567890ab",
    "trace_id": "01934e3a-6a1b-7c82-9d1b-0987654321dc",
    "timestamp_int": "1732358400000000000",
    "timestamp_iso": "2025-11-23T12:00:00.000Z",
    "event_type": "SIG",
    "event_type_code": 1,
    "timestamp_precision": "MILLISECOND",
    "clock_sync_status": "BEST_EFFORT",
    "hash_algo": "SHA256",
    "venue_id": "DEMO-VENUE",
    "symbol": "XAUUSD",
    "account_id": "acc_h7g8i9j0k1l2m3n4"
  },
  "payload": {
    "vcp_gov": {
      "algo_id": "ALGO_001", "algo_version": "2.1.0", "algo_type": "HYBRID",
      "confidence": "0.87",
      "decision_factors": [{"name": "RSI", "weight": "0.3", "value": "72.5"}]
    }
  },
  "security": {
    "event_hash": "…", "prev_hash": "0000…0000",
    "signature": "…", "sign_algo": "Ed25519"
  }
}

The event types form a lifecycle — SIG (signal) → ORD (order) → ACK (acknowledged) → EXE (executed), with REJ (rejected), CXL (cancelled), RSK (risk control), and others. Each has a stable integer code (SIG=1, ORD=2, ACK=3, EXE=4, REJ=6, …) so the meaning never drifts.

Let's set up the primitives. First, a compliant UUIDv7 and a pseudonymizer:

import time
import secrets
import hashlib
import json
from datetime import datetime, timezone
from cryptography.hazmat.primitives.asymmetric.ed25519 import (
    Ed25519PrivateKey, Ed25519PublicKey,
)
from cryptography.exceptions import InvalidSignature

GENESIS = "0" * 64  # prev_hash of the very first event


def uuid7() -> str:
    """RFC 9562 UUIDv7: 48-bit ms timestamp + version/variant + random."""
    ts = int(time.time() * 1000).to_bytes(6, "big")
    rand = secrets.token_bytes(10)
    b = bytearray(16)
    b[0:6] = ts
    b[6] = (7 << 4) | (rand[0] & 0x0F)      # version = 7
    b[7] = rand[1]
    b[8] = (0b10 << 6) | (rand[2] & 0x3F)   # variant = 10
    b[9:16] = rand[3:10]
    h = b.hex()
    return f"{h[0:8]}-{h[8:12]}-{h[12:16]}-{h[16:20]}-{h[20:32]}"


def pseudonymize(account_id: str, venue_id: str) -> str:
    """Salt + hash the account ID so raw identities never hit the log."""
    salt = f"vcp_{venue_id}_"
    digest = hashlib.sha256((salt + account_id).encode()).hexdigest()[:16]
    return f"acc_{digest}"


def new_header(event_type, code, symbol, account_id, venue_id, trace_id=None):
    now = datetime.now(timezone.utc)
    iso = now.strftime("%Y-%m-%dT%H:%M:%S.") + f"{now.microsecond // 1000:03d}Z"
    return {
        "event_id": uuid7(),
        "trace_id": trace_id or uuid7(),
        "timestamp_int": str(time.time_ns()),
        "timestamp_iso": iso,
        "event_type": event_type,
        "event_type_code": code,
        "timestamp_precision": "MILLISECOND",
        "clock_sync_status": "BEST_EFFORT",
        "hash_algo": "SHA256",
        "venue_id": venue_id,
        "symbol": symbol,
        "account_id": pseudonymize(account_id, venue_id),
    }

Property 1: tamper-evidence with a hash chain

The core idea is a hash chain: each event carries a hash of its own contents (event_hash) plus the hash of the event before it (prev_hash). Because each link commits to the previous one, editing any past event changes its hash, which breaks every event after it — and the break is detectable by anyone holding the chain.

The one subtlety is what exactly you hash. You need a canonical, deterministic serialization, or two parties will compute different hashes for the same data. VCP uses RFC 8785-style canonical JSON (sorted keys, no whitespace). The reference implementation commits to the event's identity and timing, the full payload, and the previous hash:

def event_hash(header: dict, payload: dict, prev_hash: str) -> str:
    """SHA-256 over canonical JSON (RFC 8785 style: sorted keys, compact)."""
    canonical = {
        "header": {
            "event_id": header["event_id"],
            "trace_id": header["trace_id"],
            "timestamp_int": header["timestamp_int"],
            "event_type_code": header["event_type_code"],
        },
        "payload": payload,
        "prev_hash": prev_hash,
    }
    blob = json.dumps(canonical, sort_keys=True, separators=(",", ":"))
    return hashlib.sha256(blob.encode("utf-8")).hexdigest()

Now a logger that maintains the chain. I'll fold in Property 2 at the same time, because it's one line: sign each event_hash with an Ed25519 private key.

Property 2: independent verifiability with public-key signatures

This is the property that quietly matters most, and the one most "tamper-proof" logs get wrong. Some tools chain entries with a keyed hash (HMAC). That proves integrity to whoever holds the shared key — usually the operator. It does not let an independent auditor verify anything without being handed that secret. Public-key signatures fix this: the operator signs with a private key, and anyone with the public key can verify, while no one but the operator can produce valid signatures. VCP uses Ed25519 (and is migrating toward post-quantum ML-DSA / FIPS 204).

class DecisionLog:
    def __init__(self, signing_key: Ed25519PrivateKey, venue_id="DEMO-VENUE"):
        self.key = signing_key
        self.venue_id = venue_id
        self.prev = GENESIS
        self.events = []

    def emit(self, event_type, code, symbol, payload, account_id, trace_id=None):
        header = new_header(event_type, code, symbol, account_id,
                            self.venue_id, trace_id)
        h = event_hash(header, payload, self.prev)
        signature = self.key.sign(bytes.fromhex(h)).hex()  # sign the digest
        event = {
            "header": header,
            "payload": payload,
            "security": {
                "event_hash": h,
                "prev_hash": self.prev,
                "signature": signature,
                "sign_algo": "Ed25519",
            },
        }
        self.prev = h          # advance the chain
        self.events.append(event)
        return event

Let's emit a realistic lifecycle: a signal, the order it produced, and the fill — all sharing one trace_id:

key = Ed25519PrivateKey.generate()
log = DecisionLog(key)

sig = log.emit("SIG", 1, "XAUUSD", {
    "vcp_gov": {
        "algo_id": "ALGO_001", "algo_version": "2.1.0", "algo_type": "HYBRID",
        "confidence": "0.87",
        "decision_factors": [
            {"name": "RSI", "weight": "0.3", "value": "72.5"},
            {"name": "MACD", "weight": "0.25", "value": "positive"},
        ],
    }
}, account_id="12345")

trace = sig["header"]["trace_id"]

log.emit("ORD", 2, "XAUUSD", {
    "trade_data": {"order_id": "ORD_001", "side": "BUY",
                   "order_type": "LIMIT", "price": "2650.50", "quantity": "1.00"}
}, account_id="12345", trace_id=trace)

log.emit("EXE", 4, "XAUUSD", {
    "trade_data": {"order_id": "ORD_001", "execution_price": "2650.55",
                   "executed_qty": "1.00", "slippage": "0.05", "commission": "2.50"}
}, account_id="12345", trace_id=trace)

for e in log.events:
    print(e["header"]["event_type"], e["security"]["event_hash"][:16],
          "<-", e["security"]["prev_hash"][:16])

SIG 9f2c1a04e7b6d8c0 <- 0000000000000000
ORD 3b71e9aa55c2f014 <- 9f2c1a04e7b6d8c0
EXE c0d4f8819ab33e72 <- 3b71e9aa55c2f014

Each prev_hash equals the previous event's event_hash. Now the verifier — and notice it needs only the public key, nothing secret:

def verify_chain(events, public_key: Ed25519PublicKey):
    prev = GENESIS
    for i, e in enumerate(events):
        sec = e["security"]
        # 1. recompute the hash — catches any altered field
        recomputed = event_hash(e["header"], e["payload"], sec["prev_hash"])
        if recomputed != sec["event_hash"]:
            return False, f"event {i}: hash mismatch (record was altered)"
        # 2. check the chain link — catches reordering / deletion
        if sec["prev_hash"] != prev:
            return False, f"event {i}: broken chain link"
        # 3. check the signature — catches forged records
        try:
            public_key.verify(bytes.fromhex(sec["signature"]),
                              bytes.fromhex(sec["event_hash"]))
        except InvalidSignature:
            return False, f"event {i}: invalid signature"
        prev = sec["event_hash"]
    return True, f"{len(events)} events verified"


pub = key.public_key()
print(verify_chain(log.events, pub))

(True, '3 events verified')

Now let's be the bad actor. Suppose someone changes the execution price after the fact — say a fill was worse than reported:

log.events[2]["payload"]["trade_data"]["execution_price"] = "2649.00"
print(verify_chain(log.events, pub))

(False, 'event 2: hash mismatch (record was altered)')

The edit changed the canonical bytes, so the recomputed hash no longer matches the stored one. Had the attacker also rewritten the stored hash to match, the chain link (and every subsequent prev_hash) would break instead, and the signature wouldn't verify. There is no single-field edit that survives all three checks without the private key.

Property 3: omission detection

Here's the harder attack, and the one most audit trails have no answer for: the operator doesn't edit an inconvenient record — they simply never write it, or they show the regulator a different log than the one that actually ran. This is the split-view problem. A hash chain alone doesn't stop it, because a chain over a curated subset is internally consistent.

The fix is to commit to the completeness of a batch: compute a Merkle root over the event hashes and publish that root. Later, anyone can recompute the root from the events you show them; if it doesn't match what you committed to, an event was dropped or swapped. Here's an RFC 6962-style Merkle tree (with domain-separation tags so a leaf can't be passed off as an internal node):

def _leaf(data: bytes) -> bytes:
    return hashlib.sha256(b"\x00" + data).digest()   # leaf prefix

def _node(left: bytes, right: bytes) -> bytes:
    return hashlib.sha256(b"\x01" + left + right).digest()  # node prefix

def merkle_root(event_hashes) -> str:
    if not event_hashes:
        return hashlib.sha256(b"").hexdigest()
    layer = [_leaf(bytes.fromhex(h)) for h in event_hashes]
    while len(layer) > 1:
        nxt = []
        for i in range(0, len(layer), 2):
            if i + 1 < len(layer):
                nxt.append(_node(layer[i], layer[i + 1]))
            else:
                nxt.append(layer[i])     # promote the odd node (RFC 6962)
        layer = nxt
    return layer[0].hex()


def inclusion_proof(event_hashes, index):
    """Audit path proving event_hashes[index] is in the committed set."""
    layer = [_leaf(bytes.fromhex(h)) for h in event_hashes]
    proof = []
    while len(layer) > 1:
        nxt = []
        for i in range(0, len(layer), 2):
            if i + 1 < len(layer):
                if i == index:
                    proof.append(("R", layer[i + 1].hex()))
                elif i + 1 == index:
                    proof.append(("L", layer[i].hex()))
                nxt.append(_node(layer[i], layer[i + 1]))
            else:
                nxt.append(layer[i])
        index //= 2
        layer = nxt
    return proof


def verify_inclusion(event_hash_hex, proof, root_hex) -> bool:
    cur = _leaf(bytes.fromhex(event_hash_hex))
    for side, sibling in proof:
        sib = bytes.fromhex(sibling)
        cur = _node(cur, sib) if side == "R" else _node(sib, cur)
    return cur.hex() == root_hex

Commit to the batch, then prove a specific event belongs to it:

hashes = [e["security"]["event_hash"] for e in log.events]
root = merkle_root(hashes)
print("committed root:", root[:24], "…")

# Prove the ORD event (index 1) is part of the committed set
proof = inclusion_proof(hashes, 1)
print("ORD in committed set:",
      verify_inclusion(hashes[1], proof, root))

# Now imagine the operator hides the ORD event entirely
tampered = [hashes[0], hashes[2]]   # ORD dropped
print("root after dropping ORD matches original:",
      merkle_root(tampered) == root)

committed root: 7d1f0a9c4b2e8835ac6e3f10 …
ORD in committed set: True
root after dropping ORD matches original: False

Once the root is published, the set is frozen. Dropping the order, swapping it, or inserting a fabricated event all produce a different root.

Property 4: external anchoring

The Merkle root is only as trustworthy as wherever you publish it. If you keep it on your own server, you can still rewrite it later. The point of anchoring is to put that commitment somewhere you don't control and can't quietly change — an append-only transparency log (the same mechanism Certificate Transparency uses for TLS certs), a SCITT transparency service, or a public blockchain. You get back an inclusion receipt and a timestamp you can't forge after the fact.

The code is just the interface; the security comes from the log being operated by someone other than you:

def anchor(merkle_root_hex: str) -> dict:
    """In production: submit to an append-only transparency log
    (RFC 6962 / SCITT / public chain) operated by an INDEPENDENT party.
    Returns a receipt you can later show to a third party."""
    return {
        "root": merkle_root_hex,
        "log": "transparency-log.example",
        "anchored_at": time.time_ns(),
        # ...inclusion receipt / signed checkpoint from the log
    }

receipt = anchor(root)
print("anchored:", receipt["root"][:24], "@", receipt["anchored_at"])

That's the whole stack: hash chain (Property 1) makes each record tamper-evident; Ed25519 signatures (Property 2) make them verifiable by an outsider; Merkle commitments (Property 3) make omission detectable; anchoring (Property 4) puts the commitment beyond the operator's reach. Around 150 lines, all open primitives.

What this does not give you

This is the part to be honest about, because over-promising is how trust infrastructure loses trust.

A flight recorder does not fly the plane, and it does not stop the crash. This log would not have prevented the Meta takeovers. It is not a real-time safety system, it does not block a bad decision, and it does not judge whether a decision was right — it can prove an algorithm denied an order at a specific time on specific inputs under a specific model version, but whether that was fair or lawful is a question for humans and regulators. And it does not make any system "compliant." No logging standard makes you compliant with the EU AI Act or MiFID II any more than a black box makes an airline compliant with aviation law. What it does is generate the evidence those regimes increasingly ask for — the records an auditor requests, the trail an incident review reconstructs, the proof a dispute turns on.

That's a narrow claim and a strong one at the same time: it won't stop the failure, but it lets you prove what happened to someone who doesn't have to take your word for it.

A couple of practical notes the demo glossed over. We pseudonymized account IDs at write time; for real privacy you also want crypto-shredding — encrypt sensitive fields per-subject and delete the key to render them unrecoverable, which lets you honor a GDPR erasure request without breaking the hash chain (the hash is over ciphertext, which stays put). And the conformance "tiers" you'll see in VCP (Silver/Gold/Platinum) are really verification depth — clock-sync precision, whether Merkle proofs and external anchoring are mandatory — not separate protocols.

Where to go next

The full event model, JSON Schemas, and conformance tests live in the open spec at github.com/veritaschain/vcp-spec. The approach aligns with the IETF's SCITT (Supply Chain Integrity, Transparency and Trust) work on COSE-signed statements and receipts — though, to be precise, the VCP-related IETF submissions are individual Internet-Drafts at this stage, not adopted standards, and the protocol has not yet been deployed in production at an institution.

If you maintain a system that makes consequential automated decisions — trades, approvals, agent actions — the exercise worth doing is simple: pick one decision your code makes today, and ask whether you could prove to an outsider what it decided and that the record is intact. If the answer is "trust our logs," you have a logging system, not a black box. The gap between those two is the whole game.

Disclosure: I work on open standards for verifiable AI decision provenance, including VCP and the broader Verifiable AI Provenance (VAP) framework at the VeritasChain Standards Organization. The code here is a condensed teaching version; it's faithful to VCP's event model but trimmed for clarity. Corrections and pull requests welcome.

Build, Sign, Verify: A Hands-On Tour of VeritasChain Protocol v1.2 PRD

VeritasChain Standards Organization (VSO) — Sun, 07 Jun 2026 12:23:55 +0000

A practical walkthrough of the v1.2 Public Review Draft, written from the VSO standards team. We open the bundle, install dependencies, generate signed events, verify them, package a Regulatory Evidence Bundle, and run the full conformance test suite. Everything in this article is reproducible on a stock Ubuntu 24.04 box with Python 3.12.

VeritasChain Standards Organization (VSO) has opened the Public Review Draft of VeritasChain Protocol v1.2. This article is the hands-on companion to the implementer's preview on our blog and the longer-form Medium piece. Where those articles explain what v1.2 changes and why, this one runs the code.

If you have read the announcements and want to know whether the schemas, the verifier, and the CI flow actually work on your machine before you commit a roadmap decision — this is the article for you.

A few preliminaries:

This is a Public Review Draft, not a GA release. The protocol surface is feature-frozen except for corrections required by material interoperability, security, or regulatory-readability issues raised during the 45-day review window.
v1.2 is a vocabulary extension of v1.1, not a new protocol. The cryptographic substrate — COSE_Sign1, RFC 6962 Merkle trees, RFC 8785 JCS canonicalisation, RFC 3161 / eIDAS-qualified TSA / SCITT external anchoring — is unchanged. Every v1.0 and v1.1 anchor remains valid under v1.2 verification tools.
Honest scoping. VCP is a private-industry specification. It is not a harmonised standard under Regulation (EU) 1025/2012 and confers no presumption of conformity with the EU AI Act or any other regulation. It supports evidence generation for AI Act Articles 12, 19, 26, and 72; it does not by itself make any system compliant.

With that out of the way, let's open the bundle.

Setting up the workspace
The bundle layout
Signing a minimal v1.2 event
Adding regulatory_profile and clock_evidence
Emitting a gov.change_event (and why ML retraining lives here now)
Pre-trade controls: trade.ptc_snapshot and trade.ptc_breach
Crypto-shredding with Erasure Certificate v2
Assembling a Regulatory Evidence Bundle
Hybrid post-quantum signature vectors
Running the full conformance suite
Writing your own verifier (in any language)
Wiring it into CI
Migrating from a v1.1 emitter
Where to send your Public Review comments

1. Setting up the workspace

We start with a stock Ubuntu 24.04 box (any modern Linux works). Install Python 3.12 if you don't have it, then fetch the PRD bundle:

# Either clone the repo
$ git clone https://github.com/veritaschain/vcp-spec
$ cd vcp-spec

# Or download the release archive
$ curl -L -O https://github.com/veritaschain/vcp-spec/releases/download/v1.2-prd/vcp-v1.2-prd.zip
$ unzip vcp-v1.2-prd.zip
$ cd vcp-v1.2-prd

Install the Python dependencies declared at the repository root:

$ pip install -r requirements.txt
Successfully installed PyNaCl-1.5.0 jsonschema-4.21.1

PyNaCl gives us Ed25519 signing and verification. jsonschema gives us Draft 2020-12 validation. No web framework, no database, no service — the reference tools are deliberately minimal so you can read them in an afternoon and reimplement them in any language you like.

Verify the install is sane:

$ python3 -c "from nacl.signing import SigningKey; print('PyNaCl OK')"
PyNaCl OK
$ python3 -c "from jsonschema import Draft202012Validator; print('jsonschema OK')"
jsonschema OK

2. The bundle layout

Take a quick look at what shipped:

$ ls -F
.github/
DISPOSITION_LOG.md
GA_CUTOVER_PATCH.md
README.md
VCP-Specification-v1_2-PRD.md
pqc-vectors/
requirements.txt
schemas/
tests/
tools/

Three directories matter for this tutorial:

schemas/ — the JSON Schemas for CORE, TRADE, GOV, RISK, PRIVACY, RECOVERY, and the Regulatory Evidence Bundle (REB). Their $id values resolve to https://standards.veritaschain.org/vcp/v1.2/… at GA. During the PRD period, treat them as placeholders that point to the canonical content in this repo.
tests/silver/ and tests/gold/ — the conformance test suite. Pre-built signed sample bundles plus expected results.
tools/ — Python scripts you can run against the bundle. The five scripts you'll meet in this article:
- tools/vcp_verify.py — the reference verifier
- tools/validate_schemas.py — JSON Schema validator
- tools/generate_test_bundles.py — deterministic test-bundle generator
- tools/generate_pqc_vectors.py — PQC reference vector generator
- tools/pqc_verify_check.py — hybrid vector pass/fail check

And one file you'll grow to appreciate: .github/workflows/conformance.yml, which runs all the checks above on every push. We'll come back to that in section 11.

3. Signing a minimal v1.2 event

The simplest possible conformant v1.2.0 event is one that does nothing new beyond bumping the version constant from "1.1" to "1.2". Let's build one.

Create tutorial/01_minimal.py:

import json, hashlib, base64, uuid, datetime
from nacl.signing import SigningKey


def jcs(value):
    """RFC 8785 canonicalisation — production code should use a vetted library.
    This is the same minimal implementation used by tools/vcp_verify.py."""
    return _j(value).encode("utf-8")


def _j(v):
    if v is None: return "null"
    if v is True: return "true"
    if v is False: return "false"
    if isinstance(v, str):
        return json.dumps(v, ensure_ascii=False, separators=(",", ":"))
    if isinstance(v, (int, float)):
        return json.dumps(v, allow_nan=False)
    if isinstance(v, list):
        return "[" + ",".join(_j(x) for x in v) + "]"
    if isinstance(v, dict):
        items = sorted(v.items(), key=lambda kv: kv[0].encode("utf-16-be"))
        return "{" + ",".join(_j(k) + ":" + _j(val) for k, val in items) + "}"
    raise TypeError(type(v))


def utc_now_iso():
    return datetime.datetime.utcnow().isoformat(timespec="milliseconds") + "Z"


def main():
    # Deterministic seed so anyone reading this article gets the same output
    sk = SigningKey(bytes.fromhex("11" * 32))
    issuer_id = "did:web:tutorial.example"

    payload = {"order_id": "demo-001", "side": "BUY", "stub": True}

    event = {
        "vcp_version": "1.2",
        "event_id":    str(uuid.uuid4()),  # production code uses UUIDv7
        "event_type":  "trade.order",
        "issuer_id":   issuer_id,
        "policy_id":   "tutorial-policy-2026-06",
        "issued_at":   utc_now_iso(),
        "payload_hash": hashlib.sha256(jcs(payload)).hexdigest(),
        "hash_alg":    "sha-256",
        "sig_alg":     "ed25519",
        "external_anchor": {
            "anchor_type":  "RFC3161",
            "anchor_value": "PLACEHOLDER_TSA_TOKEN",
            "anchor_time":  utc_now_iso(),
        },
    }

    # Sign over the JCS form with the signature field absent
    event["signature"] = base64.b64encode(sk.sign(jcs(event)).signature).decode()
    print(json.dumps(event, indent=2))


if __name__ == "__main__":
    main()

Run it:

$ python3 tutorial/01_minimal.py
{
  "vcp_version": "1.2",
  "event_id": "5dac…",
  "event_type": "trade.order",
  "issuer_id": "did:web:tutorial.example",
  "policy_id": "tutorial-policy-2026-06",
  "issued_at": "2026-06-06T05:42:00.123Z",
  "payload_hash": "f3a1…",
  "hash_alg": "sha-256",
  "sig_alg": "ed25519",
  "external_anchor": { "anchor_type": "RFC3161", "anchor_value": "PLACEHOLDER_TSA_TOKEN", … },
  "signature": "PsK1…"
}

This event is conformant v1.2.0 at the regulatory_profile = NONE profile (omission defaults to NONE for v1.1 compatibility). It will validate against schemas/core.schema.json and verify against tools/vcp_verify.py's Ed25519 check.

If you are migrating from v1.1, this is your one-line change: "vcp_version": "1.1" → "vcp_version": "1.2". Everything else continues to work.

4. Adding `regulatory_profile` and `clock_evidence`

The minimal event above is fine for regulatory_profile = NONE. The moment you declare MIFID_ALGO or MIFID_HFT, clock_evidence becomes MUST (per the spec's tier matrix in §7.5).

Why? Because once you're claiming to be readable as algorithmic-trading evidence under MiFID II / RTS 6, an auditor reading your trail needs to know how trustworthy the timestamps actually are — not just that you claimed "PTP-locked".

Let's add both. Create tutorial/02_mifid_algo.py:

import json, hashlib, base64, uuid, datetime, subprocess, os
from nacl.signing import SigningKey
# ...jcs(), _j(), utc_now_iso() as in 01_minimal.py


def collect_clock_evidence():
    """Reference clock-evidence collector. In production, read from your
    PTP daemon (phc2sys) or NTP daemon (chronyd). Here we return a static
    representative example."""
    return {
        "utc_source":     "PTP-grandmaster:dc1",
        "offset_us":      12.4,
        "max_error_us":   38.0,
        "holdover_state": "LOCKED",
        "sync_method":    "PTPv2_LOCKED",
        "last_sync_at":   "2026-06-06T05:41:55Z",
        "clock_state":    "NOMINAL",
    }


def main():
    sk = SigningKey(bytes.fromhex("11" * 32))

    payload = {"order_id": "demo-002", "side": "BUY", "venue_mic": "XEUR"}

    event = {
        "vcp_version":        "1.2",
        "event_id":           str(uuid.uuid4()),
        "event_type":         "trade.order",
        "issuer_id":          "did:web:tutorial.example",
        "policy_id":          "tutorial-policy-2026-06",
        "regulatory_profile": "MIFID_ALGO",        # NEW
        "agent_id":           "agent:mr-strategy-v3.4.1",  # NEW
        "issued_at":          utc_now_iso(),
        "clock_evidence":     collect_clock_evidence(),    # NEW
        "payload_hash":       hashlib.sha256(jcs(payload)).hexdigest(),
        "hash_alg":           "sha-256",
        "sig_alg":            "ed25519",
        "external_anchor": {
            "anchor_type":  "RFC3161",
            "anchor_value": "PLACEHOLDER_TSA_TOKEN",
            "anchor_time":  utc_now_iso(),
        },
    }

    event["signature"] = base64.b64encode(sk.sign(jcs(event)).signature).decode()
    print(json.dumps(event, indent=2))


if __name__ == "__main__":
    main()

A note on agent_id. It is a VCP technical identifier — purely for tracing an action back to the AI component that produced it. It does not imply that the system is legally classified as an autonomous agent under any regulatory regime. We make this point in the schema's description field too, because the legal connotation is real and we want to keep the technical identifier free of it.

One important rule: an implementation that cannot collect real clock evidence MUST NOT fabricate it. If your emitter runs in a container without access to the host PTP daemon, emit:

{
  "clock_evidence": {
    "utc_source":     "container-unknown",
    "max_error_us":   1000000,
    "holdover_state": "UNKNOWN",
    "sync_method":    "BEST_EFFORT",
    "last_sync_at":   "1970-01-01T00:00:00Z",
    "clock_state":    "UNRELIABLE"
  }
}

This is a true statement and an auditor can read it. A fabricated "clock_state": "NOMINAL" would not be.

5. Emitting a `gov.change_event` (and why ML retraining lives here now)

ESMA's Supervisory Briefing of 26 February 2026 introduces a six-category material-change taxonomy and states that retraining of ML components used in algorithmic trading constitutes a material change. v1.2 makes this recordable as gov.change_event.

The rule: emit the ChangeEvent before the change takes effect in production. Every CORE event issued after the change references the change_id until a superseding ChangeEvent supersedes it.

# tutorial/03_change_event.py
def emit_change_event(sk, issuer_id, policy_id):
    ev = {
        "vcp_version":        "1.2",
        "event_id":           str(uuid.uuid4()),
        "event_type":         "gov.change_event",
        "issuer_id":          issuer_id,
        "policy_id":          policy_id,
        "regulatory_profile": "MIFID_ALGO",
        "issued_at":          utc_now_iso(),
        "clock_evidence":     collect_clock_evidence(),
        # gov.change_event-specific fields
        "change_id":      str(uuid.uuid4()),
        "supersedes_id":  None,
        "categories":     ["adaptive_retraining", "logic_change"],
        "scope": {
            "strategy_ids":  ["alpha-mr-001"],
            "venues":        ["XEUR", "XPAR"],
            "asset_classes": ["EQUITY"],
        },
        "model_version":  { "from": "v3.4.1", "to": "v3.4.2" },
        "approval": {
            "approver_role":     "Head of Algo Trading",
            "approval_doc_hash": hashlib.sha256(b"approval-doc-2026-06-06").hexdigest(),
        },
        "go_live_at":         "2026-06-15T08:00:00Z",
        "test_evidence_refs": ["did:web:tutorial.example/tests/run-2026-06-05"],
        "rollback_plan_ref":  "did:web:tutorial.example/runbooks/rollback-mr",
        # Required CORE envelope tail
        "payload_hash": hashlib.sha256(jcs({"stub": True})).hexdigest(),
        "hash_alg":     "sha-256",
        "sig_alg":      "ed25519",
        "external_anchor": {
            "anchor_type":  "RFC3161",
            "anchor_value": "PLACEHOLDER_TSA_TOKEN",
            "anchor_time":  utc_now_iso(),
        },
    }
    ev["signature"] = base64.b64encode(sk.sign(jcs(ev)).signature).decode()
    return ev

What this lets an auditor reconstruct: "On 2026-06-06 at 05:42 UTC, the Head of Algo Trading approved a v3.4.1→v3.4.2 model update on strategy alpha-mr-001 for XEUR/XPAR equity trading, scheduled to go live 2026-06-15, with test evidence at the named reference and a documented rollback plan."

For ML retraining, the conventional sequence emits three events in this order:

gov.change_event with categories: ["adaptive_retraining"] recording the approval and the go-live time.
recovery.model_retrained recording the actual training run with the dataset hash and the training-run ID.
The first CORE event after go-live carrying a reference to the new change_id.

The cross-references mean a supervisor reviewing an incident at time T can ask "what was changing in the system at time T-1?" and get a structured answer that ties strategy, model version, approval chain, and post-change activity into one chain of evidence.

The second event in the sequence — recovery.model_retrained — looks like this:

# tutorial/03_change_event.py — continued
def emit_model_retrained(sk, issuer_id, policy_id, change_event_id):
    ev = base_event(sk, issuer_id, policy_id,
                       event_type="recovery.model_retrained")
    ev.update({
        "model_id":        "alpha-mr-001",
        "dataset_hash":    hashlib.sha256(b"training-dataset-2026-Q2").hexdigest(),
        "training_run_id": "trn-2026-06-06-001",
        "change_event_id": change_event_id,  # links back to the gov.change_event
    })
    ev["signature"] = base64.b64encode(sk.sign(jcs({k:v for k,v in ev.items() if k != "signature"})).signature).decode()
    return ev


# Wiring it all together
change_ev    = emit_change_event(sk, issuer_id, policy_id)
ledger.append(change_ev)

# ... operator runs the training pipeline ...

retrained_ev = emit_model_retrained(sk, issuer_id, policy_id,
                                    change_ev["change_id"])
ledger.append(retrained_ev)

# ... at go_live_at, the first CORE event references change_ev["change_id"] ...

The change_event_id field on the recovery.model_retrained event is the cross-reference that makes the chain navigable. A supervisor with one of the three event_ids can pull the other two and reconstruct the entire approve→train→deploy chain.

6. Pre-trade controls: `trade.ptc_snapshot` and `trade.ptc_breach`

Article 13 of RTS 6 requires pre-trade controls. v1.1 had no first-class structure for them. v1.2 introduces trade.ptc_snapshot (the state of controls at a moment in time) and trade.ptc_breach (what happened when a control fired).

The implementation pattern is straightforward:

# tutorial/04_pre_trade_controls.py
def emit_ptc_snapshot(sk, issuer_id, policy_id):
    ev = base_event(sk, issuer_id, policy_id, event_type="trade.ptc_snapshot")
    ev.update({
        "scope":    "ACCOUNT",
        "scope_id": "live-account-7",
        "controls": {
            "price_collar":          { "method": "absolute", "value": "100.00" },
            "max_order_value":       { "currency": "EUR", "amount": 250000 },
            "max_order_volume":      { "shares": 10000 },
            "max_message_rate":      { "messages_per_second": 200 },
            "repeated_exec_throttle":{ "window_ms": 100, "max_executions": 10 },
        },
        "active_kill_switches": ["primary", "escalation"],
        "approving_role":       "Head of Algo Trading",
    })
    ev["signature"] = base64.b64encode(sk.sign(jcs({k:v for k,v in ev.items() if k != "signature"})).signature).decode()
    return ev


def check_order_against_snapshot(order, snapshot):
    controls = snapshot["controls"]
    if order["price"] > controls["price_collar"]["value"]:
        return ("PRICE_COLLAR", order["price"], controls["price_collar"]["value"])
    if order["quantity"] * order["price"] > controls["max_order_value"]["amount"]:
        return ("MAX_ORDER_VALUE",
                order["quantity"] * order["price"],
                controls["max_order_value"]["amount"])
    # ... similar checks for max_order_volume, max_message_rate, repeated_exec_throttle
    return None


def emit_ptc_breach(sk, issuer_id, policy_id, snapshot_id, breach, order_id):
    breach_type, observed, limit = breach
    ev = base_event(sk, issuer_id, policy_id, event_type="trade.ptc_breach")
    ev.update({
        "snapshot_id": snapshot_id,
        "breach_type": breach_type,
        "order_id":    order_id,
        "observed":    { "value": observed, "limit": limit },
        "action_taken": "BLOCK",
        "operator":     "AUTO",
    })
    ev["signature"] = base64.b64encode(sk.sign(jcs({k:v for k,v in ev.items() if k != "signature"})).signature).decode()
    return ev

The supervisory question PTC events answer is: given these controls, why did this order get through? With v1.2, the answer is recorded in evidence at the moment of the order, not reconstructed from system logs months later.

When to emit a snapshot: at system start-up; at every change to PTC parameters; at minimum once per business day; and at every breach. Orders carry a ptc_snapshot_ref field indicating which snapshot was in force at order time. This creates the bidirectional link an auditor needs: from order to controls, and from controls to all orders they touched.

Here is what a rejection flow looks like end-to-end. Suppose an account-7 trader sends an order at price 305,000 EUR against a max_order_value of 250,000 EUR. The emitter sequence is:

# tutorial/04_pre_trade_controls.py — continued
snapshot   = emit_ptc_snapshot(sk, issuer_id, policy_id)   # at boot or change
ledger.append(snapshot)

order      = {"order_id":"ord-2026-06-06-12345","price":305000,
              "quantity":1,"venue_mic":"XEUR"}
breach     = check_order_against_snapshot(order, snapshot)

if breach:
    breach_event = emit_ptc_breach(sk, issuer_id, policy_id,
                                   snapshot["event_id"], breach,
                                   order["order_id"])
    ledger.append(breach_event)
    reject_order(order, reason=breach[0])
else:
    order_event = emit_order_event(sk, issuer_id, policy_id,
                                   order, snapshot["event_id"])
    ledger.append(order_event)
    route_order(order)

What an auditor sees in the ledger, in chronological order:

event_id   event_type             scope              detail
0196…ab    trade.ptc_snapshot     ACCOUNT live-acct-7  max_order_value EUR 250,000
0196…cd    trade.ptc_breach       (refs ab)            MAX_ORDER_VALUE 305000 vs 250000 → BLOCK

The supervisor can run the verifier against this slice of the ledger and confirm — without trusting the operator's narrative — that the breach was recorded, the action was taken, and no order event was issued. That's the structural difference between v1.1 (which would have left this to system logs) and v1.2 (which captures it in cryptographically anchored evidence).

7. Crypto-shredding with Erasure Certificate v2

The PRIVACY module addresses GDPR Article 17 (right to erasure) through crypto-shredding: the ciphertext stays in the ledger, but its decryption key is destroyed in an HSM. The legal argumentation is in Annex J of the specification (explicitly labelled as not legal advice).

What changed from Erasure Certificate v1: structured GDPR Article 17(1) ground reference, KMS key URI, HSM attestation block, explicit backup_treatment statement, anonymisation-claim basis, and optional co-signers (DPO + CISO).

# tutorial/05_erasure.py
def emit_erasure_certificate(sk, subject_pseudonym):
    ev = base_event(sk, "did:web:tutorial.example",
                       "tutorial-policy-2026-06",
                       event_type="privacy.erasure")
    ev.update({
        "subject_pseudonym":  subject_pseudonym,
        "erasure_basis":      "GDPR-17(1)(b)",
        "kms_key_uri":        "kms://eu-west-1/keys/01HX-tutorial-key",
        "hsm_attestation": {
            "vendor":               "VendorName",
            "fips_140_3_level":     3,
            "attestation_evidence": "attestation-token-2026-06-06",
        },
        "backup_treatment":         "scheduled_overwrite_within_90d",
        "anonymisation_claim_basis":"k=20, l=3 over the residual graph",
        "co_signers": ["did:web:dpo.tutorial.example", "did:web:ciso.tutorial.example"],
    })
    ev["signature"] = base64.b64encode(sk.sign(jcs({k:v for k,v in ev.items() if k != "signature"})).signature).decode()
    return ev

Three operational rules to remember:

subject_pseudonym MUST be a stable pseudonymous identifier. Plaintext PII MUST NOT appear here.
kms_key_uri MUST point to the destroyed key (KMIP locator, cloud KMS ARN, or HSM key reference).
co_signers is OPTIONAL but RECOMMENDED at Gold and Platinum, with DPO + CISO being the typical configuration.

The crypto-shredding pillars (from Annex J) — Article 17(1) is satisfied where data are made inaccessible given the state of the art; HSM-attested key destruction is a state-of-the-art mechanism; the EDPB-flagged backup gap is addressed by the documented backup_treatment timeline — are how the operator argues that destruction of the key is, in substance, erasure. Your local DPA remains the final word.

8. Assembling a Regulatory Evidence Bundle

The Regulatory Evidence Bundle (REB) is the structural innovation of v1.2. It is not a new event; it is a packaging contract that lets you deliver, on demand, a self-contained, independently verifiable evidence set to a supervisor or auditor.

Three normative rules:

Reproducibility. Two independent assemblers, given the same period, scope, and source ledger, MUST produce the same content hash.
Profile-specific minima. Each Regulatory Profile carries a required minimum component set.
Signing. The REB MUST be signed by the operator and SHOULD be co-signed by the operator's compliance function.

A reference assembler:

# tutorial/06_reb.py
def assemble_reb(period, scope, profile, ledger):
    components = {
        "core_events": {
            "merkle_root": ledger.merkle_root_for(period, scope).hex(),
            "count":       ledger.count_for(period, scope),
            "path_index":  ledger.path_index_for(period, scope),
        },
        "policy_id_history":         sorted(ledger.distinct_values("policy_id", period, scope)),
        "regulatory_profile_history": sorted(ledger.distinct_values("regulatory_profile", period, scope)),
    }

    if profile in {"MIFID_ALGO", "MIFID_HFT", "MIXED_FINANCIAL_AI"}:
        components["clock_evidence_summary"]   = ledger.summarise_clock(period, scope)
        components["change_events"]            = ledger.event_ids("gov.change_event", period, scope)
        components["ptc_snapshots"]            = ledger.event_ids("trade.ptc_snapshot", period, scope)
        components["ptc_breaches"]             = ledger.event_ids("trade.ptc_breach", period, scope)
        components["provider_dependencies"]    = ledger.event_ids("gov.provider_dependency", period, scope)
        components["outage_notices"]           = ledger.event_ids_prefix("recovery.outage_", period, scope)

    if profile in {"AI_ACT_HRAI", "MIXED_FINANCIAL_AI"}:
        components["pmm_manifests"]            = ledger.event_ids("gov.pmm_manifest", period, scope)
        components["recovery_integrity_tests"] = ledger.event_ids("recovery.integrity_test", period, scope)
        components["erasure_certificates"]     = ledger.event_ids("privacy.erasure", period, scope)

    reb = {
        "reb_version":        "1.0",
        "vcp_version":        "1.2",
        "regulatory_profile": profile,
        "period":             period,
        "scope":              scope,
        "components":         components,
        "external_anchors":   ledger.anchors_for(period, scope),
        "verifier_recipe":    "https://standards.veritaschain.org/verify/reb-1.0",
    }
    # Sign over the JCS form with the signature field absent
    sig_bytes = sk.sign(jcs(reb)).signature
    reb["issuer_signature"] = base64.b64encode(sig_bytes).decode()
    return reb

Reproducibility, in practice, means that two independent teams writing assemble_reb against the same ledger and the same period/scope MUST produce REBs whose content hashes are identical. This is the property that makes a REB independently verifiable. It is not what the operator says happened — it is what anyone with access to the source ledger can reproduce.

The REB SHOULD be served via a SCRAPI-compatible endpoint at /v1/reb/{reb_id}. When an authority asks "show us your Q2 algorithmic-trading evidence in EUR-denominated venues," the operational answer is one URL that returns one self-contained bundle.

8.1 Serving a REB over HTTP

The SCRAPI compatibility point matters because it lets an auditor's tooling — or a regulatory technologist's script — fetch your REB without negotiating a custom protocol. A minimal Flask-based serving endpoint:

# tutorial/07_reb_server.py
from flask import Flask, request, jsonify, abort
import json, hashlib

app = Flask(__name__)
REB_STORE = {}  # in production, this is your durable storage


def reb_content_hash(reb: dict) -> str:
    """Reproducibility check: derive deterministic content hash."""
    reb_without_sig = {k: v for k, v in reb.items() if k != "issuer_signature"}
    return hashlib.sha256(jcs(reb_without_sig)).hexdigest()


@app.route("/v1/reb/<reb_id>", methods=["GET"])
def get_reb(reb_id: str):
    reb = REB_STORE.get(reb_id)
    if reb is None:
        abort(404)
    # Match the Accept header — SCITT convention is application/cose or application/json
    if "application/json" in request.headers.get("Accept", "application/json"):
        return jsonify(reb)
    abort(406)


@app.route("/v1/reb/<reb_id>/verify", methods=["GET"])
def verify_reb(reb_id: str):
    """Independent verifier convenience endpoint: recompute content hash."""
    reb = REB_STORE.get(reb_id)
    if reb is None:
        abort(404)
    return jsonify({
        "reb_id":              reb_id,
        "regulatory_profile":  reb["regulatory_profile"],
        "period":              reb["period"],
        "computed_content_hash": reb_content_hash(reb),
        "merkle_root":         reb["components"]["core_events"]["merkle_root"],
        "issuer_signature_present": "issuer_signature" in reb,
    })


@app.route("/v1/reb", methods=["POST"])
def publish_reb():
    reb = request.get_json()
    # Validate against schema before accepting
    from jsonschema import Draft202012Validator
    schema = json.loads(open("schemas/reb.schema.json").read())
    errs = list(Draft202012Validator(schema).iter_errors(reb))
    if errs:
        return jsonify({"errors": [e.message for e in errs]}), 400
    reb_id = reb_content_hash(reb)[:16]
    REB_STORE[reb_id] = reb
    return jsonify({"reb_id": reb_id}), 201

What a regulator's verifier sees when they call this:

$ curl https://your-firm.example/v1/reb/a1b2c3d4e5f67890
{
  "reb_version":        "1.0",
  "vcp_version":        "1.2",
  "regulatory_profile": "MIFID_ALGO",
  "period":             { "from": "2026-04-01", "to": "2026-06-30" },
  "components": { … },
  "external_anchors": [ … ],
  "issuer_signature":  "..."
}

$ curl https://your-firm.example/v1/reb/a1b2c3d4e5f67890/verify
{
  "reb_id":               "a1b2c3d4e5f67890",
  "regulatory_profile":   "MIFID_ALGO",
  "computed_content_hash":"a1b2c3d4e5f6789012345...",
  "merkle_root":          "...",
  "issuer_signature_present": true
}

The /verify convenience endpoint is optional but valuable: it tells the requester what content hash this server computed, which they can compare against the content hash their independent assembler would compute from the same source ledger. If those two hashes match, the REB is reproducible, which is the v1.2 normative requirement.

In production you would also:

Pin TLS to mutual authentication for supervisor access
Add rate limiting and audit logging on the REB endpoint itself (which is, ironically, a VCP event in its own right)
Cache REBs by content hash, since a reproducible REB is by definition idempotent
Serve application/cose content type alongside JSON for SCITT verifier compatibility

9. Hybrid post-quantum signature vectors

v1.2 reserves ed25519+mldsa65 as the canonical hybrid SignAlgo, following the LAMPS composite-signatures combiner (draft-ietf-lamps-pq-composite-sigs-06). The verify-then-emit ratchet:

Version	Verify hybrid	Emit hybrid
v1.2.0 (now)	MAY at all tiers	MAY at all tiers; registry reserves `ed25519+mldsa65`
v1.2.1 (Q1 2027 target)	MUST at Platinum, SHOULD at Gold	SHOULD at Platinum, MAY at Gold/Silver
v1.3.0	MUST at Platinum, MUST at Gold	MUST at Platinum, SHOULD at Gold (subject to maturity)

The PRD ships with two vectors in pqc-vectors/. The classical half uses real Ed25519. The PQC half is a clearly-labelled PRD_PQC_PLACEHOLDER until vetted ML-DSA-65 vectors replace it before v1.3.0's emit-MUST cut-over.

Run the vector check:

$ python3 tools/pqc_verify_check.py
PQC hybrid vector check (classical-half only — PQC half is PRD placeholder)
  [PASS] verify-pass.json: expected=VERIFY_PASS observed=VERIFY_PASS
  [PASS] verify-fail-tampered.json: expected=VERIFY_FAIL observed=VERIFY_FAIL

The verify-fail-tampered.json vector has a single bit flipped in byte 0 of the Ed25519 signature. Any conformant verifier MUST reject it. The verify-pass.json vector is the same message with an intact signature; any conformant verifier MUST accept it.

If you are writing your own verifier — and we encourage you to, since independent implementations are part of the GA-readiness checklist — your implementation MUST produce identical pass/fail outcomes on these two vectors. That is the operational meaning of conformance for the PQC vectors.

For implementers planning the v1.2.1 → v1.3.0 transition: ML-DSA-65 signatures are about 3.3 KB; the composite is about 3.4 KB. At HFT order-flow rates, the realistic deployment pattern is batch-signing Merkle leaves and emitting one composite signature per batch, anchoring at the batch root.

10. Running the full conformance suite

Time to run everything together:

$ python3 tools/validate_schemas.py
Silver bundle — schema validation
  [PASS] silver event #0 validates against core.schema.json
  [PASS] silver REB validates against reb.schema.json

Gold bundle — schema validation
  [PASS] gold event #0 validates against core.schema.json
  [PASS] gold event #1 validates against core.schema.json
  [PASS] gold event #2 validates against core.schema.json
  [PASS] gold REB validates against reb.schema.json

Summary: 0 schema-validation failures

$ python3 tools/vcp_verify.py --tier silver --bundle tests/silver/
VCP v1.2-prd reference verifier — tier=silver bundle=tests/silver

Event #0 0196a98b-4980-7abc-8123-4567890def012 type=trade.order
  [PASS] policy_id present
  [PASS] event_id is UUIDv7
  [PASS] event canonicalisation deterministic  — jcs_sha256=fb720ff9bc11539b…
  [PASS] ed25519 signature verify
  [PASS] external_anchor present

Tier-specific checks
  [PASS] ClockEvidence present (Silver SHOULD)

Regulatory Evidence Bundle
  [PASS] REB reproducibility (same input → same content hash)

Summary: 7 pass, 0 fail

$ python3 tools/vcp_verify.py --tier gold --bundle tests/gold/
… (3 events × 4-5 checks each, plus tier-specific PTC and ChangeEvent checks)
Summary: 19 pass, 0 fail

$ python3 tools/pqc_verify_check.py
  [PASS] verify-pass.json: expected=VERIFY_PASS observed=VERIFY_PASS
  [PASS] verify-fail-tampered.json: expected=VERIFY_FAIL observed=VERIFY_FAIL

Four categories, all green. The conformance properties the verifier exercises:

RFC 8785 JCS canonicalisation (deterministic event-hash recomputation)
Event-hash verification against the recomputed canonical form
Ed25519 signature verification (RFC 8032)
Merkle proof verification (RFC 6962-style)
External-anchor presence
PolicyID presence
ClockEvidence presence (Silver: SHOULD; Gold: MUST when MIFID_ALGO)
REB reproducibility (deterministic content hash)
PTCSnapshot presence (Gold: SHOULD)
ChangeEvent presence (Gold: SHOULD)

If you write your own verifier in Go, Rust, TypeScript, or whatever else, your implementation MUST produce identical pass/fail outcomes on these test bundles. That is what makes you a conformant implementation. We will list independent implementations in the GA acknowledgements — so if you build one, let us know.

11. Writing your own verifier (in any language)

The GA-readiness checklist requires "at least one independent implementation passes the conformance test suite at Silver and Gold." If you build that implementation, you become part of the GA story. Here is the recipe in language-agnostic pseudocode, drawn from tools/vcp_verify.py.

The minimum your verifier needs to do, in order:

function verify_event(event, public_key_hex):
    # 1. Canonicalisation
    event_for_sig = event without "signature"
    canon_bytes   = jcs_canonicalise(event_for_sig)  # RFC 8785

    # 2. Hash and signature
    computed_hash = sha256(canon_bytes)
    sig_bytes     = base64_decode(event["signature"])

    # 3. Verify Ed25519
    if not ed25519_verify(public_key_hex, canon_bytes, sig_bytes):
        return FAIL("signature invalid")

    # 4. Mandatory fields
    if not event["policy_id"]:
        return FAIL("policy_id missing")
    if not is_uuidv7(event["event_id"]):
        return FAIL("event_id is not UUIDv7")
    if not event["external_anchor"]["anchor_value"]:
        return FAIL("external_anchor missing")

    # 5. Profile-conditional fields
    profile = event.get("regulatory_profile", "NONE")
    if profile in {"MIFID_ALGO", "MIFID_HFT", "MIXED_FINANCIAL_AI"}:
        if not event.get("clock_evidence"):
            return FAIL("clock_evidence MUST under MIFID_* profiles")

    return PASS

The four properties that are unambiguous and language-portable:

Property	What you need	RFC / spec reference
JCS canonicalisation	UTF-16 code-unit ordered keys, ECMA 262 number serialisation, no insignificant whitespace	RFC 8785
Ed25519 verification	Pure Ed25519, no pre-hash, no domain separation	RFC 8032
Merkle proof verification	Leaf hash = SHA-256(0x00 ‖ leaf); node hash = SHA-256(0x01 ‖ left ‖ right)	RFC 6962 §2.1.1
UUIDv7 detection	Version nibble == 7; variant bits == 10	RFC 9562 §5.7

A Rust implementer would lean on ed25519-dalek for signatures, sha2 for hashing, and write the JCS serialiser from scratch (it's about 60 lines). A Go implementer would use crypto/ed25519 from the standard library and either bring their own JCS or use one of the community implementations. A TypeScript implementer would use @noble/ed25519 (no native dependencies, runs in Node and the browser) and again write JCS by hand.

The fact that JCS is the easiest part to get subtly wrong is worth flagging. The two most common failure modes:

Object key ordering by UTF-8 byte instead of UTF-16 code unit. These agree for ASCII keys but diverge for keys containing characters in the supplementary planes. RFC 8785 specifies UTF-16, so use UTF-16.
Number serialisation that emits 1.0 instead of 1. ECMA 262 says integers serialise without a decimal point. If you serialise via your language's default JSON number formatter, check this case explicitly.

If your verifier ingests tests/silver/sample-events.jsonl and tests/silver/sample-reb.json, runs the verification steps above, and emits 7 pass, 0 fail, it is conformant at Silver. Same exercise on tests/gold/, with additional checks for PTC snapshot presence and ChangeEvent presence, gives you Gold. Send us a link and we will add your implementation to the GA acknowledgements section.

A note for the truly motivated: a fully featured independent verifier would also re-derive Merkle roots from the leaf hashes, verify the external anchor (TSA token chain, or SCITT Receipt inclusion proof), and run the REB reproducibility check by reassembling the REB from your own copy of the ledger. None of that is required to claim Silver/Gold conformance, but all of it is welcome and is the path to becoming the kind of independent supervisory-side verifier that the GA-readiness checklist is hoping for.

11.1 Common pitfalls (with actual verifier output)

What follows are four ways your verifier — or your emitter — can be subtly wrong, with the exact output the reference verifier produces when each one occurs. Use these as integration tests against your own implementation.

Pitfall 1: JCS key ordering using UTF-8 instead of UTF-16.

If your JCS serialiser orders object keys by UTF-8 byte sequence, your event hash will diverge from the spec's for any event containing non-ASCII keys. The reference verifier catches this because the recomputed canonical form does not match the signed payload:

Event #0 0196a98b-...
  [FAIL] ed25519 signature verify  — signature invalid

The signature is mathematically intact; the verifier just hashed different bytes than the emitter signed. If you see this failure mode on events that contain CJK keys, fields with combining characters, or supplementary-plane symbols, check your key sort.

Pitfall 2: Number serialisation with trailing .0.

If your JSON encoder emits 1.0 instead of 1 for integer-valued floats, the canonical form diverges from the spec. Same failure shape as Pitfall 1:

  [FAIL] ed25519 signature verify  — signature invalid

ECMA 262 says integers serialise without a decimal point. Most modern JSON encoders get this right, but some Python libraries (and some Java BigDecimal paths) emit .0 for integer floats. If you see verify failures correlated with events containing whole-number quantities like "quantity": 1000.0, this is the cause.

Pitfall 3: Missing policy_id (v1.1 hard deadline in force).

If you migrate from a pre-v1.1 emitter and forget to add policy_id, the verifier rejects the event regardless of signature validity:

Event #0 0196a98b-...
  [PASS] event canonicalisation deterministic
  [FAIL] policy_id present  — policy_id missing
  [PASS] ed25519 signature verify

The signature is valid; the schema-level requirement is not. The Policy Identification deadline of 25 March 2026 is in force and v1.2 does not relax it.

Pitfall 4: clock_evidence claimed at MIFID_ALGO but absent.

If you set regulatory_profile: "MIFID_ALGO" but forget to emit clock_evidence, the Gold-tier verifier flags the inconsistency:

Tier-specific checks
  [FAIL] ClockEvidence MUST for MIFID_ALGO/HFT/MIXED  — MUST violation per §7.5

This is the one your emitter-side defensive check (the RuntimeError in V12Emitter._needs_clock) should prevent at issuance time. If a v1.2.0 event slips through with MIFID_ALGO and no clock_evidence, it is not conformant; the verifier is correct to reject it.

The pattern across all four pitfalls is the same: the v1.2 verifier surfaces the inconsistency at the earliest possible point — at signature verification for canonicalisation errors, at field-presence checks for missing required fields, at tier-policy checks for profile-conditional fields. If your own verifier reproduces these four behaviours, you are well on the way to Silver/Gold conformance.

12. Wiring it into CI

The PRD includes a GitHub Actions workflow you can use as-is or adapt:

# .github/workflows/conformance.yml
name: VCP v1.2-prd Conformance
on:
  push:
    branches: [main, "v1.2-prd"]
  pull_request:
    branches: [main, "v1.2-prd"]
  workflow_dispatch:

jobs:
  conformance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt

      # Reproducibility check: regenerate then diff against checked-in
      - run: python3 tools/generate_test_bundles.py
      - run: git diff --exit-code tests/silver/ tests/gold/
      - run: python3 tools/generate_pqc_vectors.py
      - run: git diff --exit-code pqc-vectors/

      # Schema and tier conformance
      - run: python3 tools/validate_schemas.py
      - run: python3 tools/vcp_verify.py --tier silver --bundle tests/silver/
      - run: python3 tools/vcp_verify.py --tier gold   --bundle tests/gold/
      - run: python3 tools/pqc_verify_check.py

The pattern worth stealing is the reproducibility check at the top: a deterministic generator plus checked-in output plus git diff --exit-code. If anyone (including the maintainer) changes either side without keeping them in sync, the build fails. We use this for tests/silver/, tests/gold/, and pqc-vectors/. It eliminates an entire class of bug where checked-in test data and the generator drift silently.

If you adopt this pattern in your own VCP-emitter project, you get a free guarantee that your sample bundles continue to match your generator, and your CI surfaces any drift on the next push.

13. Migrating from a v1.1 emitter

For most v1.1 deployments, migration to v1.2.0 is a single-line change.

A v1.1 emitter:

class V11Emitter:
    def emit(self, event_type, payload, anchor):
        ev = {
            "vcp_version": "1.1",                      # changes to "1.2"
            "event_id":    str(uuid.uuid4()),
            "event_type":  event_type,
            "issuer_id":   self.issuer_id,
            "policy_id":   self.policy_id,
            "issued_at":   utc_now_iso(),
            "payload_hash": hashlib.sha256(jcs(payload)).hexdigest(),
            "hash_alg":    "sha-256",
            "sig_alg":     "ed25519",
            "external_anchor": anchor,
        }
        ev["signature"] = base64.b64encode(self.sk.sign(jcs(ev)).signature).decode()
        return ev

The same emitter, minimally migrated to v1.2.0 and conformant at regulatory_profile = MIFID_ALGO:

class V12Emitter:
    def __init__(self, sk, issuer_id, policy_id,
                 regulatory_profile="NONE",
                 clock_evidence_provider=None,
                 agent_id=None):
        self.sk = sk
        self.issuer_id = issuer_id
        self.policy_id = policy_id
        self.regulatory_profile = regulatory_profile
        self.clock_evidence_provider = clock_evidence_provider
        self.agent_id = agent_id
        self._needs_clock = regulatory_profile in (
            "MIFID_ALGO", "MIFID_HFT", "MIXED_FINANCIAL_AI"
        )

    def emit(self, event_type, payload, anchor):
        ev = {
            "vcp_version": "1.2",                          # CHANGED
            "event_id":    str(uuid.uuid4()),
            "event_type":  event_type,
            "issuer_id":   self.issuer_id,
            "policy_id":   self.policy_id,
            "issued_at":   utc_now_iso(),
            "payload_hash": hashlib.sha256(jcs(payload)).hexdigest(),
            "hash_alg":    "sha-256",
            "sig_alg":     "ed25519",
            "external_anchor": anchor,
            "regulatory_profile": self.regulatory_profile, # ADDED
        }
        if self.agent_id is not None:                      # ADDED
            ev["agent_id"] = self.agent_id
        if self._needs_clock:                              # ADDED
            if self.clock_evidence_provider is None:
                raise RuntimeError(
                    "ClockEvidence MUST be present under MIFID_* profiles"
                )
            ev["clock_evidence"] = self.clock_evidence_provider()
        ev["signature"] = base64.b64encode(self.sk.sign(jcs(ev)).signature).decode()
        return ev

Three things change, none of them break v1.1 semantics:

"vcp_version" becomes "1.2".
regulatory_profile and (optionally) agent_id are populated.
A clock_evidence callback is invoked when the profile requires it.

Nothing about how events are signed, hashed, anchored, or canonicalised changes. A relying party verifying a v1.2 event uses the same JCS canonicalisation, the same Ed25519 signature check, the same external-anchor verification path. This is what we mean by "vocabulary extension, not protocol revision."

What you are not required to do:

Re-issue, re-sign, or re-anchor v1.0 or v1.1 events. They remain valid under v1.2 verification tools.
Migrate to hybrid signatures in v1.2.0. The reservation of ed25519+mldsa65 is forward-positioning, not a v1.2.0 requirement.
Adopt every Provisional Regulatory Profile. They are reserved for community comment and may change.

14. Where to send your Public Review comments

Public Review runs for 45 days from the PRD opening. Comments go through GitHub Issues using the Public Review Comment template at github.com/veritaschain/vcp-spec. Every substantive comment receives one of six dispositions — Accepted, Accepted with modification, Deferred, Declined, Out of scope, Editorial — recorded openly in DISPOSITION_LOG.md and updated weekly.

The categories of comment we especially welcome from dev.to readers:

Does the clock_evidence structure cover what your time infrastructure actually produces? In particular, can your PTP or NTP stack produce offset_us and max_error_us, or do you have to fabricate them?
Does trade.ptc_snapshot capture every pre-trade control your venue or jurisdiction requires? Are there controls that wouldn't fit one of the five categories shown?
Does the gov.change_event taxonomy cover every change you'd actually emit one for? In particular, where do adaptive_retraining and external_dependency_change overlap, and what should the rule be?
Does the REB minimum-content matrix, by Regulatory Profile, match what your supervisors actually request?
Does the requirements.txt install cleanly on your CI image? Does the reproducibility check pass on first run?
Did this tutorial work end-to-end on your machine? If not, where did it break? That information is gold for us.

Security findings — cryptographic vulnerabilities, schema injection paths, signature-bypass conditions — go privately to security@veritaschain.org under a 90-day responsible-disclosure timeline.

The GA-readiness checklist is six items: every $id URI resolves to its canonical artefact, the next IETF individual-draft iteration reflects the PRD's terminology, at least one independent implementation passes the conformance suite at Silver and Gold, the PQC verify vectors are reproducible across implementations, comments are addressed in a published disposition log, and the v1.1 hard-deadline counters (PolicyIdentification 2026-03-25, Silver external anchoring 2026-06-25) are confirmed unaffected. Until those six are cleared, this is a PRD. After they are cleared, v1.2.0 ships.

Closing notes

VCP v1.2 PRD is now open. The repository is at github.com/veritaschain/vcp-spec. The full specification is VCP-Specification-v1_2-PRD.md. Independent implementations are welcome and will be acknowledged.

Three things to take away if you read this far:

v1.2 is the vocabulary regulators are about to start asking for in algorithmic-trading and AI audit trails. It is not a new protocol. It is not a rewrite.
The reference tools work. We have shown the commands above; you can run them yourself. If they don't work on your machine, that is exactly the kind of finding we need before GA.
Honest scoping holds. VCP supports evidence generation for AI Act Articles 12, 19, 26, and 72. It does not by itself make any system compliant.

Eighty-seven days until 2 August 2026. Forty-five for review. The rest is the work.

If you write a verifier in your favourite language and want it linked from our acknowledgements, let us know. If you find a bug, file an issue. If you find a security issue, email security@veritaschain.org. If you build something on VCP v1.2 we don't know about yet, we would genuinely like to hear about it.

About VSO. VeritasChain Standards Organization is a Tokyo-based standards body developing open cryptographic specifications for AI and algorithmic systems under the principle "Verify, Don't Trust." We maintain the VeritasChain Protocol (VCP) and the Verifiable AI Provenance (VAP) Framework. We are registered in Japan (D-U-N-S 698368529). VeritasChain株式会社, a separate commercial entity, operates in the same jurisdiction. This article is published from the VSO official dev.to account.

Companion publications

Implementer's preview on our blog: https://veritaschain.org/blog/vcp-v1-2-prd-implementer-preview
Long-form technical article on Medium
LinkedIn Article from the VSO official account
Announcement post and thread on X (English and Japanese)

Contact

General: info@veritaschain.org
Standards: standards@veritaschain.org
Technical questions during Public Review: GitHub Issues (preferred) or technical@veritaschain.org
Security: security@veritaschain.org (90-day responsible disclosure)

Published under Creative Commons Attribution 4.0 International. The VCP specification itself is governed by the licence stated in its repository.

veritaschain / vcp-spec

Official specification for the VeritasChain Protocol (VCP) v1.0 – global audit standard for algorithmic trading.

VeritasChain Protocol (VCP)

VeritasChain Protocol (VCP) is an open, vendor-neutral standard for
cryptographically verifiable audit trails in algorithmic and AI-driven trading systems.

VCP enables regulators, auditors, and market participants to
verify — not merely trust — the integrity, completeness, and ordering of trading decisions, orders, executions, and risk controls.

This repository is maintained by the
VeritasChain Standards Organization (VSO).

📌 Canonical Specification Location (IMPORTANT)

The canonical (normative) specification of VCP is located under:

/spec/
├─ v1.0/
├─ v1.1/
└─ v1.2/

Each version directory contains the authoritative specification (SPEC.md)
Files outside /spec/ are non-normative
HTML, PDF, or translated documents (if any) are provided for convenience only

If there is any conflict, the content under /spec/ always prevails.

📘 Available Versions

▶ Current Stable

v1.2 — latest specification with strengthened integrity guarantees → /spec/v1.2/

▶ Legacy

v1.0 — initial released version → /spec/v1.0/

Migration notes and compatibility considerations are…

View on GitHub

Grok Still Makes Deepfakes. GSA Wants AI Flight Recorders. Workday Says Logs Are Enough. Here's the Code That Settles the Debate.

VeritasChain Standards Organization (VSO) — Thu, 16 Apr 2026 01:08:57 +0000

On April 14–15, 2026, three events converged on the same question: does internal logging constitute evidence, or merely assertion? NBC News documented ongoing Grok deepfake circumvention. GSA proposed the most detailed AI audit trail clause in federal procurement history. And Workday declared its enhanced logging sufficient for EU AI Act compliance. This article fact-checks each event, maps the technical gaps, and walks you through building the cryptographic layer that transforms "trust us" into "verify this" — updated for CAP-SRP v1.1 with all 10 event types and 4 completeness invariants.

TL;DR

NBC News confirmed that Grok continues generating sexualized deepfakes despite months of promises, eight regulatory investigations, and a Dutch court injunction with €100,000/day penalties. GSA published draft clause 552.239-7001, requiring AI vendors to log intermediate processing steps, preserve forensic artifacts for 90 days, and provide complete source attribution — essentially an AI flight recorder mandate. Workday announced EU AI Act readiness based on ISO 42001 certification and enhanced internal logging.

All three share one structural blind spot: none provides a mechanism for external parties to verify that logs are complete and unaltered. GSA demands logs but doesn't require tamper-evidence. Workday says it logs correctly but no external mechanism detects incompleteness. Grok's eight investigators cannot independently reconstruct what the safety system did.

This article:

Fact-checks each event against primary sources (with corrections where needed)
Maps each event to CAP-SRP v1.1 event flows with ASCII diagrams
Provides a complete working Python implementation — all 10 event types, 4 completeness invariants, chain integrity verification
Shows how GSA's audit trail requirements map to Bronze/Silver/Gold conformance

GitHub: veritaschain/cap-spec · veritaschain/cap-srp · License: CC BY 4.0 / Apache 2.0

Event 1: Grok Deepfake Circumvention Persists
Event 2: GSA Demands AI Flight Recorders
Event 3: Workday Declares Logs Are Enough
The Pattern: Three Positions on the Same Spectrum
CAP-SRP v1.1: The Complete Event Model
Building It: Full Python Implementation
Scenario Mapping: Three Events → Event Flows
GSA Clause → CAP-SRP Conformance Mapping
Bronze/Silver/Gold Sprint Plan
Transparency Notes

Event 1: Grok Deepfake Circumvention Persists

What happened

On April 14, 2026, NBC News published an investigation by David Ingram documenting that Grok continues generating sexualized images of real women on X, months after the initial crisis in January 2026.

Key findings from the NBC investigation:

Dozens of sexualized images of real women found publicly on X over the past month
Three new circumvention techniques: stick-figure pose matching, clothing-swap requests, photo-to-video sexualization
Volume "appears to have decreased significantly since the flood in January"
None of the April images depicted nudity; none appeared to involve minors

Fact-check verdict: ✅ Confirmed with one correction

NBC investigation: Fully verified. Published April 14, 2026 by David Ingram.

Eight regulatory agencies: All confirmed active — European Commission (DSA investigation, Jan 26), California AG, Australian eSafety, UK ICO (Feb 3), UK Ofcom, Paris prosecutor, Privacy Commissioner of Canada, Ireland DPC.

Amsterdam District Court injunction (March 26, 2026): Verified via Tech Policy Press, CADE Project, Anadolu Agency. First European court injunction against AI image generator. €100,000/day per company (xAI + X Corp), capped at €10M.

Circumvention techniques: Confirmed. X's updated ToS (effective Jan 15, 2026) lists "prompt engineering or injection" as prohibited misuse per Grok's own public response.

Correction: The original Daily Watch report described the images as "sexually explicit." NBC explicitly noted none were nude and none involved minors — the images showed women in revealing clothing (towels, sports bras, bunny costumes). The accurate characterization is "sexualized," not "sexually explicit." This distinction matters legally under both TAKE IT DOWN Act (Pub.L. 119-12) and EU DSA frameworks.

Framing correction: This is not a "re-eruption" but the documented persistence of the same crisis that began in December 2025. All eight investigations originated in January–February 2026.

The accountability gap

The structural problem is unchanged since January:

Current Grok Accountability Architecture
═════════════════════════════════════════

User submits prompt ──→ [Grok Safety System]
                              │
                    ┌─────────┴──────────┐
                    ▼                     ▼
              Generated               Blocked?
                    │                     │
                    ▼                     ▼
              Visible on X         Internal logs
              (external can see)   (external CANNOT see)
                    │                     │
                    ▼                     ▼
              Regulators see       xAI says:
              the outputs          "We blocked many
                                    requests"
                    │                     │
                    └─────────┬───────────┘
                              ▼
                    8 agencies ask:
                    "Prove it."
                              │
                              ▼
                    xAI: "Trust us."
                    Agencies: "We can't verify that."
                    xAI: "..."

What's missing: every generation attempt committed BEFORE safety evaluation, with cryptographic proof linking each attempt to exactly one outcome. Without this, the regulators' question — "what percentage of harmful requests did you actually block?" — is structurally unanswerable from outside.

Event 2: GSA Demands AI Flight Recorders

What happened

GSA published draft clause 552.239-7001 — "Basic Safeguarding of Artificial Intelligence Systems (FEB 2026) (GSAR Deviation)" — on March 6, 2026. The clause would apply to AI systems sold through the Multiple Award Schedule program.

The requirements, verified line-by-line against the actual clause text:

GSA Requirement	Clause Section	Status
Government owns all Data (prompts, outputs, logs, metadata)	§(d)(1)(i)	✅ Verified verbatim
72-hour incident reporting	§(e)(4)	✅ Verified verbatim
90-day log/forensic artifact retention	§(e)(4)(iii)	✅ Verified verbatim
Intermediate processing step summaries	§(e)(3)	✅ Verified verbatim
Model routing decisions with rationale	§(e)(3)(ii)	✅ Verified verbatim
Source attribution with direct links	§(e)(3)(iii)	✅ Verified verbatim
No refusal based on vendor discretionary policies	§(d)(2)(ii)	✅ Verified verbatim

Fact-check verdict: ✅ Fully confirmed against primary source

All requirements verified against the PDF published on buy.gsa.gov. Legal analysis confirmed via JD Supra (McGuireWoods), Holland & Knight, Fox Rothschild, and Baker Botts.

Important procedural context: The clause was NOT published through Federal Register notice-and-comment rulemaking (41 U.S.C. § 1707). It was released via the MAS solicitation refresh process with initially 14 days for comment (later ~28). The U.S. Chamber of Commerce, SIIA, and multiple law firms filed objections. Comment period closed April 3. Clause deferred from Refresh 31 to Refresh 32. Nextgov reports ongoing industry pushback.

What GSA gets right — and what's missing

GSA's clause is the most detailed AI audit trail requirement from any government agency to date. It mandates the what of flight recording — every intermediate step, every routing decision, every data source. But it doesn't mandate the how of integrity:

GSA 552.239-7001 vs. Cryptographic Flight Recorder
═══════════════════════════════════════════════════

             GSA Requires          GSA Does NOT Require
             ─────────────         ────────────────────
  ✅ Log intermediate steps     ❌ Hash-chain events
  ✅ Source attribution          ❌ External timestamps (RFC 3161)
  ✅ 90-day retention            ❌ Completeness invariant
  ✅ Incident preservation       ❌ Merkle tree inclusion proofs
  ✅ Model routing rationale     ❌ SCITT transparency anchoring
  ✅ Government data ownership   ❌ Tamper detection mechanism

  Result: GSA assumes logs        Result: Cryptographic integrity
  are complete and honest.        makes completeness verifiable
                                  and tampering detectable.

The clause essentially asks vendors to self-certify their logging. A behavioral provenance layer would allow the government to verify the logging.

Event 3: Workday Declares Logs Are Enough

What happened

At its Dublin EMEA headquarters on April 15, 2026, Workday presented its EU AI Act preparedness strategy. Chandler Morse (Chief Corporate Affairs Officer) briefed journalists and analysts. The core message: Workday's AI governance systems — ISO 42001 certified, NIST AI RMF aligned, with enhanced logging and traceability — are sufficient for high-risk AI compliance.

Sources: Techzine (in-person reporting by Erik van Klinken, April 15), Workday blog (Rich Sauer, Chief Legal Officer).

Fact-check verdict: ✅ Verified with terminology correction

ISO 42001 certification: Confirmed. Independently verified by Schellman Compliance, LLC. Announced June 12, 2025.

NIST AI RMF: ⚠️ Terminology correction needed. Workday received an alignment attestation (assessed by Coalfire), NOT a certification. NIST does not operate a formal AI RMF certification program. Workday itself uses "alignment" rather than "compliance" for the NIST framework. Treating ISO certification and NIST attestation as equivalent conflates different levels of independent verification.

Annex III mapping, enhanced logging, human-in-the-loop: These are Workday's own characterizations reported via Techzine's in-person briefing and Workday's blog. They have not been independently audited at the specific-feature level. The ISO 42001 and NIST attestations validate Workday's overall governance framework but do not independently audit each sub-claim.

The "good enough" problem

Workday's approach represents the industry ceiling — and that's precisely the problem for anyone arguing cryptographic integrity matters:

Workday's Compliance Model
══════════════════════════

  ┌──────────────────────────────────┐
  │  ISO 42001 Certification    ✅    │  Independent verification
  │  (Schellman Compliance)          │  of governance framework
  ├──────────────────────────────────┤
  │  NIST AI RMF Attestation    ⚠️    │  Alignment assessment,
  │  (Coalfire)                      │  not certification
  ├──────────────────────────────────┤
  │  Annex III Risk Mapping     📝    │  Self-reported
  ├──────────────────────────────────┤
  │  Enhanced Logging           📝    │  Self-reported
  ├──────────────────────────────────┤
  │  Human-in-the-loop          📝    │  Self-reported
  └──────────────────────────────────┘

  Question: Can a regulator verify the logging is
  complete without asking Workday to show them?

  Answer: No. The logging system is controlled by
  the entity being evaluated.

This isn't a criticism of Workday. It's a description of the structural limitation. When the EU AI Act's Article 12 requires "automatic recording of events (logs) over the lifetime of the system," it doesn't specify tamper-evidence. It assumes logs are honest. The question is whether that assumption survives the first enforcement dispute.

The Pattern: Three Positions on the Same Spectrum

The Trust-to-Verification Spectrum (April 2026)
════════════════════════════════════════════════

  Pure Trust                              Pure Verification
  (self-report)                          (cryptographic proof)
  ◄──────────────────────────────────────────────────────►

  Grok/xAI          Workday           GSA 552.239-7001    CAP-SRP
  "We blocked it"   "We log it        "Show us the logs"  "Prove the logs
                     correctly"                             are complete"
       │                │                    │                   │
       │                │                    │                   │
       ▼                ▼                    ▼                   ▼
  No external       ISO-certified       Government            Hash chains,
  evidence          framework,          demands records,      external anchors,
                    internal logs       no integrity check    completeness
                                                              invariant

The direction is clear: from "trust us" toward "show us" toward "prove it." GSA's clause is a massive step — but it stops one layer short of verifiability.

CAP-SRP v1.1: The Complete Event Model

Version 1.1 (published March 5, 2026) added six event types and expanded the completeness invariants from one to four. Here's the full model:

All 10 Event Types

┌────────────────────────────────────────────────────────────┐
│                  GENERATION EVENTS (7)                       │
│                                                             │
│  GEN_ATTEMPT ──→ Safety Check ──→ Outcome                  │
│       │              │                                      │
│       │         ┌────┼────┬────────┬───────────┐           │
│       │         ▼    ▼    ▼        ▼           ▼           │
│       │       GEN  DENY  WARN   ESCALATE   ERROR           │
│       │       (ok) (block)(caution)(human) (fail)           │
│       │                            │                        │
│       │                        resolves to                  │
│       │                      GEN or GEN_DENY                │
│       │                                                     │
│       │       GEN_QUARANTINE (post-gen hold)                │
│       │            │                                        │
│       │        resolves to                                  │
│       │      EXPORT or GEN_DENY                             │
├─────────────────────────────────────────────────────────────┤
│                GOVERNANCE EVENTS (3)                         │
│                                                             │
│  ACCOUNT_ACTION ──→ LAW_ENFORCEMENT_REFERRAL                │
│  (ban/suspend/flag)   (referred/not_referred/pending)       │
│                                                             │
│  POLICY_VERSION                                             │
│  (safety policy published/updated)                          │
│  Must be externally anchored BEFORE EffectiveFrom date      │
└─────────────────────────────────────────────────────────────┘

All 4 Completeness Invariants

Invariant 1 — Primary (Silver+):
═════════════════════════════════
∑ GEN_ATTEMPT = ∑ GEN + ∑ GEN_WARN + ∑ GEN_DENY
              + ∑ GEN_ERROR + ∑ GEN_ESCALATE + ∑ GEN_QUARANTINE

Every attempt → exactly one immediate outcome.


Invariant 2 — Escalation Resolution (Silver+):
═══════════════════════════════════════════════
∑ GEN_ESCALATE = ∑ ESCALATE_RESOLVED_TO_GEN
               + ∑ ESCALATE_RESOLVED_TO_DENY

Every escalation → exactly one resolution.
Unresolved > 72 hours = compliance violation.


Invariant 3 — Quarantine Resolution (Silver+):
═══════════════════════════════════════════════
∑ GEN_QUARANTINE = ∑ QUARANTINE_RELEASED_TO_EXPORT
                 + ∑ QUARANTINE_DENIED

Every quarantine → release or deny. No permanent limbo.


Invariant 4 — Policy Anchoring Precedence (Gold):
══════════════════════════════════════════════════
For every POLICY_VERSION event P:
  anchor_timestamp(P.ExternalAnchorRef) ≤ P.EffectiveFrom

Policy must be externally anchored BEFORE it takes effect.
Prevents retroactive policy creation to justify past decisions.

Building It: Full Python Implementation

Here's a complete working implementation covering all 10 event types and 4 completeness invariants. This is a sidecar — it sits alongside your existing AI generation pipeline without modifying it.

Event Types and Core Infrastructure

import hashlib
import json
import time
import uuid
import base64
from dataclasses import dataclass, field, asdict
from typing import Optional, List, Dict, Tuple
from enum import Enum
from datetime import datetime, timezone
from cryptography.hazmat.primitives.asymmetric.ed25519 import (
    Ed25519PrivateKey, Ed25519PublicKey
)


# ── v1.1 Event Types (all 10) ─────────────────────────────

class EventType(Enum):
    # Generation events (7)
    GEN_ATTEMPT = "GEN_ATTEMPT"
    GEN = "GEN"
    GEN_DENY = "GEN_DENY"
    GEN_WARN = "GEN_WARN"
    GEN_ESCALATE = "GEN_ESCALATE"
    GEN_QUARANTINE = "GEN_QUARANTINE"
    GEN_ERROR = "GEN_ERROR"
    # Governance events (3) — new in v1.1
    ACCOUNT_ACTION = "ACCOUNT_ACTION"
    LAW_ENFORCEMENT_REFERRAL = "LAW_ENFORCEMENT_REFERRAL"
    POLICY_VERSION = "POLICY_VERSION"


class RiskCategory(Enum):
    NCII_RISK = "NCII_RISK"
    CSAM_RISK = "CSAM_RISK"
    VIOLENCE_EXTREME = "VIOLENCE_EXTREME"
    VIOLENCE_PLANNING = "VIOLENCE_PLANNING"  # new in v1.1
    HATE_CONTENT = "HATE_CONTENT"
    TERRORIST_CONTENT = "TERRORIST_CONTENT"
    SELF_HARM_PROMOTION = "SELF_HARM_PROMOTION"
    COPYRIGHT_VIOLATION = "COPYRIGHT_VIOLATION"
    COPYRIGHT_STYLE_MIMICRY = "COPYRIGHT_STYLE_MIMICRY"
    CONTENT_POLICY = "CONTENT_POLICY"


class AccountActionType(Enum):
    BAN = "BAN"
    SUSPEND = "SUSPEND"
    RATE_LIMIT = "RATE_LIMIT"
    REINSTATE = "REINSTATE"
    FLAG_FOR_REVIEW = "FLAG_FOR_REVIEW"


class LEOutcome(Enum):
    REFERRED = "REFERRED"
    NOT_REFERRED = "NOT_REFERRED"
    PENDING = "PENDING"


# ── Crypto Utilities ───────────────────────────────────────

def sha256(data: str) -> str:
    """SHA-256 with prefix per CAP-SRP spec."""
    return f"sha256:{hashlib.sha256(data.encode()).hexdigest()}"


def canonicalize(obj: dict) -> str:
    """RFC 8785 JSON Canonicalization (simplified)."""
    return json.dumps(obj, sort_keys=True, separators=(",", ":"))


def uuid7() -> str:
    """UUIDv7: time-ordered for natural event sequencing."""
    timestamp_ms = int(time.time() * 1000)
    rand_bits = uuid.uuid4().int & ((1 << 62) - 1)
    uuid_int = (timestamp_ms << 80) | (0x7 << 76) | rand_bits
    return str(uuid.UUID(int=uuid_int & ((1 << 128) - 1)))


def now_iso() -> str:
    return datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S.%f")[:-3] + "Z"

Event Classes

@dataclass
class CAPEvent:
    """Base event with cryptographic integrity."""
    event_id: str
    event_type: EventType
    chain_id: str
    timestamp: str
    prev_hash: Optional[str]
    event_hash: Optional[str] = None
    signature: Optional[str] = None

    def compute_hash(self) -> str:
        data = {k: v for k, v in asdict(self).items()
                if k not in ("event_hash", "signature")}
        data["event_type"] = self.event_type.value
        return sha256(canonicalize(data))

    def sign(self, private_key: Ed25519PrivateKey):
        self.event_hash = self.compute_hash()
        hash_bytes = bytes.fromhex(self.event_hash[7:])
        sig = private_key.sign(hash_bytes)
        self.signature = f"ed25519:{base64.b64encode(sig).decode()}"


@dataclass
class GenAttemptEvent(CAPEvent):
    """Logged BEFORE safety evaluation — unforgeable commitment."""
    prompt_hash: str = ""
    input_type: str = "text"
    model_version: str = ""
    policy_id: str = ""
    actor_hash: str = ""

    @classmethod
    def create(cls, chain_id, prev_hash, prompt, actor_id,
               model_version, policy_id, input_type="text"):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_ATTEMPT,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, prompt_hash=sha256(prompt),
            input_type=input_type, model_version=model_version,
            policy_id=policy_id, actor_hash=sha256(actor_id),
        )


@dataclass
class GenDenyEvent(CAPEvent):
    """Logged when safety evaluation blocks request."""
    attempt_id: str = ""
    risk_category: str = ""
    risk_score: float = 0.0
    refusal_reason: str = ""
    policy_version: str = ""
    jurisdiction_context: str = ""  # v1.1

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id, risk_category,
               risk_score, reason, policy_version, jurisdiction=""):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_DENY,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            risk_category=risk_category.value,
            risk_score=risk_score, refusal_reason=reason,
            policy_version=policy_version,
            jurisdiction_context=jurisdiction,
        )


@dataclass
class GenWarnEvent(CAPEvent):
    """v1.1: Generation allowed with user-facing warning."""
    attempt_id: str = ""
    risk_category: str = ""
    risk_score: float = 0.0
    warning_text: str = ""

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id,
               risk_category, risk_score, warning):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_WARN,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            risk_category=risk_category.value,
            risk_score=risk_score, warning_text=warning,
        )


@dataclass
class GenEscalateEvent(CAPEvent):
    """v1.1: Request sent for human review."""
    attempt_id: str = ""
    risk_category: str = ""
    risk_score: float = 0.0
    resolution_ref: Optional[str] = None  # filled when resolved

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id,
               risk_category, risk_score):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_ESCALATE,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            risk_category=risk_category.value,
            risk_score=risk_score,
        )


@dataclass
class GenQuarantineEvent(CAPEvent):
    """v1.1: Content generated but held before delivery."""
    attempt_id: str = ""
    risk_category: str = ""
    release_ref: Optional[str] = None  # filled when released/denied

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id, risk_category):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_QUARANTINE,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            risk_category=risk_category.value,
        )


@dataclass
class AccountActionEvent(CAPEvent):
    """v1.1: Account-level enforcement decision."""
    account_hash: str = ""
    action_type: str = ""
    reason: str = ""
    le_assessment_outcome: Optional[str] = None  # v1.1

    @classmethod
    def create(cls, chain_id, prev_hash, account_id,
               action_type, reason, le_outcome=None):
        return cls(
            event_id=uuid7(), event_type=EventType.ACCOUNT_ACTION,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash,
            account_hash=sha256(account_id),
            action_type=action_type.value,
            reason=reason,
            le_assessment_outcome=le_outcome.value if le_outcome else None,
        )


@dataclass
class LERefEvent(CAPEvent):
    """v1.1: Law enforcement referral decision."""
    account_action_ref: str = ""
    outcome: str = ""
    agency: str = ""
    rationale: str = ""

    @classmethod
    def create(cls, chain_id, prev_hash, action_ref,
               outcome, agency="", rationale=""):
        return cls(
            event_id=uuid7(),
            event_type=EventType.LAW_ENFORCEMENT_REFERRAL,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash,
            account_action_ref=action_ref,
            outcome=outcome.value, agency=agency,
            rationale=rationale,
        )


@dataclass
class PolicyVersionEvent(CAPEvent):
    """v1.1: Safety policy version record."""
    policy_id: str = ""
    version: str = ""
    effective_from: str = ""
    policy_hash: str = ""
    external_anchor_ref: Optional[str] = None

    @classmethod
    def create(cls, chain_id, prev_hash, policy_id,
               version, effective_from, policy_text):
        return cls(
            event_id=uuid7(), event_type=EventType.POLICY_VERSION,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, policy_id=policy_id,
            version=version, effective_from=effective_from,
            policy_hash=sha256(policy_text),
        )

The Chain with All 4 Completeness Invariants

class CAPChainV11:
    """Full v1.1 hash chain with 4 completeness invariants."""

    def __init__(self, private_key: Ed25519PrivateKey, chain_id=None):
        self.private_key = private_key
        self.chain_id = chain_id or str(uuid.uuid4())
        self.events: List[CAPEvent] = []
        self.attempts: Dict[str, CAPEvent] = {}
        self.outcomes: Dict[str, CAPEvent] = {}
        self.escalations: Dict[str, GenEscalateEvent] = {}
        self.quarantines: Dict[str, GenQuarantineEvent] = {}
        self.policy_versions: List[PolicyVersionEvent] = []

    @property
    def last_hash(self) -> Optional[str]:
        return self.events[-1].event_hash if self.events else None

    def _append(self, event: CAPEvent) -> CAPEvent:
        event.sign(self.private_key)
        self.events.append(event)
        return event

    # ── Generation events ──────────────────────────────

    def log_attempt(self, prompt, actor_id, model_version,
                    policy_id, input_type="text"):
        """MUST be called BEFORE safety evaluation."""
        event = GenAttemptEvent.create(
            self.chain_id, self.last_hash, prompt,
            actor_id, model_version, policy_id, input_type)
        self._append(event)
        self.attempts[event.event_id] = event
        return event

    def log_deny(self, attempt_id, risk_category, risk_score,
                 reason, policy_version, jurisdiction=""):
        self._check_attempt(attempt_id)
        event = GenDenyEvent.create(
            self.chain_id, self.last_hash, attempt_id,
            risk_category, risk_score, reason,
            policy_version, jurisdiction)
        self._append(event)
        self.outcomes[attempt_id] = event
        return event

    def log_warn(self, attempt_id, risk_category,
                 risk_score, warning):
        self._check_attempt(attempt_id)
        event = GenWarnEvent.create(
            self.chain_id, self.last_hash, attempt_id,
            risk_category, risk_score, warning)
        self._append(event)
        self.outcomes[attempt_id] = event
        return event

    def log_escalate(self, attempt_id, risk_category, risk_score):
        self._check_attempt(attempt_id)
        event = GenEscalateEvent.create(
            self.chain_id, self.last_hash, attempt_id,
            risk_category, risk_score)
        self._append(event)
        self.outcomes[attempt_id] = event
        self.escalations[event.event_id] = event
        return event

    def log_quarantine(self, attempt_id, risk_category):
        self._check_attempt(attempt_id)
        event = GenQuarantineEvent.create(
            self.chain_id, self.last_hash,
            attempt_id, risk_category)
        self._append(event)
        self.outcomes[attempt_id] = event
        self.quarantines[event.event_id] = event
        return event

    def resolve_escalation(self, escalation_id, resolved_to_gen=True):
        """Resolve a pending escalation to GEN or GEN_DENY."""
        esc = self.escalations.get(escalation_id)
        if not esc:
            raise ValueError(f"Unknown escalation: {escalation_id}")
        esc.resolution_ref = f"resolved:{'GEN' if resolved_to_gen else 'GEN_DENY'}"
        return esc

    def resolve_quarantine(self, quarantine_id, released=True):
        """Resolve a quarantine to EXPORT or GEN_DENY."""
        q = self.quarantines.get(quarantine_id)
        if not q:
            raise ValueError(f"Unknown quarantine: {quarantine_id}")
        q.release_ref = f"resolved:{'EXPORT' if released else 'GEN_DENY'}"
        return q

    # ── Governance events (v1.1) ───────────────────────

    def log_account_action(self, account_id, action_type,
                           reason, le_outcome=None):
        event = AccountActionEvent.create(
            self.chain_id, self.last_hash, account_id,
            action_type, reason, le_outcome)
        self._append(event)
        return event

    def log_le_referral(self, action_ref, outcome,
                        agency="", rationale=""):
        event = LERefEvent.create(
            self.chain_id, self.last_hash, action_ref,
            outcome, agency, rationale)
        self._append(event)
        return event

    def log_policy_version(self, policy_id, version,
                           effective_from, policy_text):
        event = PolicyVersionEvent.create(
            self.chain_id, self.last_hash, policy_id,
            version, effective_from, policy_text)
        self._append(event)
        self.policy_versions.append(event)
        return event

    # ── Verification ───────────────────────────────────

    def _check_attempt(self, attempt_id):
        if attempt_id not in self.attempts:
            raise ValueError(f"Unknown attempt: {attempt_id}")
        if attempt_id in self.outcomes:
            raise ValueError(f"Attempt already resolved: {attempt_id}")

    def verify_invariant_1(self) -> dict:
        """Primary Completeness: attempts == outcomes."""
        a = sum(1 for e in self.events
                if e.event_type == EventType.GEN_ATTEMPT)
        outcomes = sum(1 for e in self.events
                       if e.event_type in (
                           EventType.GEN, EventType.GEN_DENY,
                           EventType.GEN_WARN, EventType.GEN_ERROR,
                           EventType.GEN_ESCALATE,
                           EventType.GEN_QUARANTINE))
        unmatched = [aid for aid in self.attempts
                     if aid not in self.outcomes]
        return {
            "name": "Primary Completeness",
            "valid": a == outcomes and len(unmatched) == 0,
            "attempts": a, "outcomes": outcomes,
            "unmatched": unmatched,
        }

    def verify_invariant_2(self) -> dict:
        """Escalation Resolution: all escalations resolved."""
        unresolved = [eid for eid, e in self.escalations.items()
                      if e.resolution_ref is None]
        return {
            "name": "Escalation Resolution",
            "valid": len(unresolved) == 0,
            "total": len(self.escalations),
            "unresolved": unresolved,
        }

    def verify_invariant_3(self) -> dict:
        """Quarantine Resolution: all quarantines resolved."""
        unresolved = [qid for qid, q in self.quarantines.items()
                      if q.release_ref is None]
        return {
            "name": "Quarantine Resolution",
            "valid": len(unresolved) == 0,
            "total": len(self.quarantines),
            "unresolved": unresolved,
        }

    def verify_invariant_4(self) -> dict:
        """Policy Anchoring: anchor before effective date."""
        violations = []
        for p in self.policy_versions:
            if p.external_anchor_ref:
                # In production: compare anchor timestamp vs effective_from
                pass  # placeholder for RFC 3161 timestamp check
            else:
                violations.append(p.policy_id)
        return {
            "name": "Policy Anchoring Precedence",
            "valid": len(violations) == 0,
            "total": len(self.policy_versions),
            "unanchored": violations,
        }

    def verify_chain_integrity(self) -> dict:
        """Verify hash chain is unbroken."""
        for i in range(1, len(self.events)):
            expected = self.events[i - 1].event_hash
            actual = self.events[i].prev_hash
            if expected != actual:
                return {
                    "valid": False,
                    "break_at": i,
                    "expected": expected,
                    "actual": actual,
                }
        return {"valid": True, "events_verified": len(self.events)}

    def verify_all(self) -> dict:
        """Run all 4 invariants + chain integrity."""
        return {
            "chain_integrity": self.verify_chain_integrity(),
            "invariant_1": self.verify_invariant_1(),
            "invariant_2": self.verify_invariant_2(),
            "invariant_3": self.verify_invariant_3(),
            "invariant_4": self.verify_invariant_4(),
        }

Scenario Mapping: Three Events → Event Flows

Scenario 1: Grok Deepfake Request (with CAP-SRP)

What April's NBC investigation would look like with behavioral provenance:

key = Ed25519PrivateKey.generate()
chain = CAPChainV11(key, chain_id="grok-image-gen")

# ── User tries stick-figure pose matching circumvention ──
attempt = chain.log_attempt(
    prompt="[stick figure pose] + [photo of person]",
    actor_id="user_abc123",
    model_version="grok-3-image-v2",
    policy_id="x-safety-policy-2026-04",
    input_type="text+image"
)

# Safety system detects NCII intent despite circumvention
deny = chain.log_deny(
    attempt_id=attempt.event_id,
    risk_category=RiskCategory.NCII_RISK,
    risk_score=0.91,
    reason="Non-consensual sexualized imagery detected via "
           "pose-matching circumvention pattern",
    policy_version="x-safety-v4.2.1",
    jurisdiction="EU-NL"  # Netherlands jurisdiction flag
)

# ── Repeated attempts trigger account action ──
acct = chain.log_account_action(
    account_id="user_abc123",
    action_type=AccountActionType.SUSPEND,
    reason="Repeated NCII circumvention attempts (5 in 24h)",
    le_outcome=LEOutcome.PENDING
)

# ── LE referral assessment ──
le_ref = chain.log_le_referral(
    action_ref=acct.event_id,
    outcome=LEOutcome.NOT_REFERRED,
    rationale="Adult subjects only; below imminent-harm threshold"
)

# Verify everything
results = chain.verify_all()
print(json.dumps(results, indent=2, default=str))

What this proves that Grok currently cannot:

The request existed (GEN_ATTEMPT committed before evaluation)
It was refused (GEN_DENY with risk category and score)
The account was actioned (ACCOUNT_ACTION with LE assessment)
The LE decision was recorded (NOT_REFERRED with rationale)
The chain is complete (invariant holds: 1 attempt = 1 deny)

Scenario 2: GSA-Compliant AI System

What the GSA clause's "intermediate processing step" requirement looks like with CAP-SRP:

chain = CAPChainV11(key, chain_id="fed-ai-system")

# ── Log the safety policy FIRST (Invariant 4) ──
policy = chain.log_policy_version(
    policy_id="gsa-compliance-policy",
    version="1.0.0",
    effective_from="2026-04-01T00:00:00Z",
    policy_text="Federal AI safety policy per GSAR 552.239-7001..."
)
# In production: anchor to RFC 3161 TSA before effective_from
policy.external_anchor_ref = "rfc3161:timestamp_token_base64..."

# ── Federal analyst submits query ──
attempt = chain.log_attempt(
    prompt="Summarize classified threat assessment for region X",
    actor_id="analyst_fed_42",
    model_version="vendor-llm-v3",
    policy_id="gsa-compliance-policy-v1.0.0",
    input_type="text"
)

# ── System escalates: classified content requires human review ──
esc = chain.log_escalate(
    attempt_id=attempt.event_id,
    risk_category=RiskCategory.CONTENT_POLICY,
    risk_score=0.75
)

# ── Human reviewer approves (resolves escalation) ──
chain.resolve_escalation(esc.event_id, resolved_to_gen=True)

# Verify: all 4 invariants must pass
results = chain.verify_all()
assert results["invariant_1"]["valid"]  # attempt has outcome
assert results["invariant_2"]["valid"]  # escalation resolved
assert results["invariant_4"]["valid"]  # policy anchored

Scenario 3: Workday-Type HR AI Decision

What "enhanced logging" looks like when made externally verifiable:

chain = CAPChainV11(key, chain_id="hr-ai-screening")

# ── Candidate screening request ──
attempt = chain.log_attempt(
    prompt="Evaluate candidate profile for role Senior Engineer",
    actor_id="hr_recruiter_7",
    model_version="workday-ai-screen-v2.1",
    policy_id="eu-ai-act-annex-iii-employment",
    input_type="text"
)

# ── AI generates score but it's quarantined for human review ──
# (EU AI Act high-risk: employment decisions require human oversight)
quar = chain.log_quarantine(
    attempt_id=attempt.event_id,
    risk_category=RiskCategory.CONTENT_POLICY
)

# ── Human reviewer releases with modifications ──
chain.resolve_quarantine(quar.event_id, released=True)

# Verify: quarantine invariant must hold
results = chain.verify_all()
assert results["invariant_3"]["valid"]  # quarantine resolved
print(f"Chain: {results['chain_integrity']['events_verified']} events verified")

GSA Clause → CAP-SRP Conformance Mapping

How the GSA requirements map to CAP-SRP's three conformance tiers:

GSA 552.239-7001 Requirement	Bronze	Silver	Gold
Log intermediate steps §(e)(3)	✅ Basic events	✅ + GEN_ESCALATE, GEN_QUARANTINE	✅ + ACCOUNT_ACTION, LE_REFERRAL
Source attribution §(e)(3)(iii)	❌	✅ Via model context	✅ Full RAG provenance
72-hour incident reporting §(e)(4)	✅ Manual	✅ Automated detection	✅ Real-time + SCITT
90-day retention §(e)(4)(iii)	✅ 6-month minimum	✅ 2-year	✅ 5-year
Government data ownership §(d)(1)	✅ Export capability	✅ Evidence Pack	✅ Evidence Pack + SCITT receipts
No vendor-discretion refusal §(d)(2)(ii)	✅ Logged as GEN_DENY with policy ref	✅ + Completeness Invariant	✅ + External verification
Tamper detection	⚠️ Hash chain only	✅ + RFC 3161	✅ + SCITT anchoring
Completeness guarantee	❌	✅ All 4 invariants	✅ All 4 + continuous monitoring

Key insight: Bronze satisfies the letter of the GSA clause. Silver satisfies the spirit. Gold satisfies the intent — verifiable proof that logs are complete and unaltered.

Bronze/Silver/Gold Sprint Plan

Sprint 1: Bronze (2–3 weeks)

Week 1-2: Core event logging
─────────────────────────────
□ Implement EventType enum (all 10 types)
□ Implement CAPEvent base class with hash/sign
□ Implement GenAttemptEvent + GenDenyEvent + GenEvent
□ SHA-256 hash chain linking
□ Ed25519 signing on all events
□ Basic chain integrity verification
□ 6-month retention storage (PostgreSQL/S3)

Week 3: Integration
────────────────────
□ Sidecar deployment alongside generation pipeline
□ GEN_ATTEMPT hook BEFORE safety evaluator
□ Outcome hooks AFTER safety evaluator
□ JSON export for audit

Sprint 2: Silver (3–4 weeks)

Week 4-5: v1.1 events + invariants
────────────────────────────────────
□ GEN_WARN, GEN_ESCALATE, GEN_QUARANTINE events
□ POLICY_VERSION events
□ Primary Completeness Invariant (#1)
□ Escalation Resolution Invariant (#2)
□ Quarantine Resolution Invariant (#3)
□ Policy Anchoring Invariant (#4)
□ PromptHash privacy preservation
□ JurisdictionContext on GEN_DENY events

Week 6-7: External anchoring
─────────────────────────────
□ RFC 3161 TSA integration (daily anchoring minimum)
□ Merkle tree construction
□ Evidence Pack generation (v1.1 manifest format)
□ Third-party verification endpoint
□ 2-year retention upgrade

Sprint 3: Gold (4–6 weeks)

Week 8-10: Governance events + SCITT
──────────────────────────────────────
□ ACCOUNT_ACTION events with LE assessment
□ LAW_ENFORCEMENT_REFERRAL events
□ Account Action Invariant monitoring
□ AccountHash HMAC with per-user key store
□ Crypto-shredding support (GDPR)
□ SCITT transparency service integration
□ Hourly external anchoring

Week 11-13: Production hardening
─────────────────────────────────
□ HSM for signing key storage
□ Real-time audit API with authentication
□ Automated completeness monitoring (all 4 invariants)
□ 5-year retention + multi-region redundancy
□ 24-hour incident response capability
□ TAKE IT DOWN Act 48-hour SLA monitoring
□ ContentHash cross-reference for duplicate detection

Transparency Notes

About this analysis: This article fact-checks three real events from April 14–15, 2026, against primary sources. Corrections from the original Daily Watch report are noted inline: "sexually explicit" corrected to "sexualized" (NBC's actual characterization), "re-eruption" corrected to "documented persistence," and NIST "compliance" corrected to "alignment attestation." One source URL (anews.com.tr) from the original report was unverifiable and has been replaced with the NBC News primary source.

About CAP-SRP: CAP-SRP is an open specification (v1.1, published March 5, 2026) under CC BY 4.0 by VeritasChain Standards Organization (VSO). The reference implementation is at veritaschain/cap-srp under Apache 2.0.

What CAP-SRP is:

A technically sound approach to a genuine gap in AI accountability
Built on mature standards: SCITT, C2PA, COSE/CBOR, RFC 3161, RFC 8785
Open source, open specification, vendor-neutral

What CAP-SRP is not (yet):

An industry-endorsed standard
An IETF RFC (the individual draft draft-kamimura-scitt-refusal-events-02 has no SCITT WG adoption)
Deployed at any major AI provider

The EU AI Act Article 50 enforcement deadline is August 2, 2026 — less than 4 months away. The TAKE IT DOWN Act compliance deadline is May 19, 2026 — 33 days away. The GSA clause is moving toward Refresh 32. The question is no longer whether AI systems need verifiable behavioral audit trails. The question is who builds them first.

Verify, don't trust. The code is the proof.

GitHub: veritaschain/cap-spec · veritaschain/cap-srp · Spec: CAP-SRP v1.1 · License: CC BY 4.0 / Apache 2.0

China Regulates Digital Humans. Germany Wants to Jail Deepfake Creators. Neither Can Verify What an AI Refused to Generate.

VeritasChain Standards Organization (VSO) — Mon, 06 Apr 2026 01:28:21 +0000

Three regulatory developments from a single week — fact-checked against primary sources, mapped to a cryptographic audit framework, and implemented in working Python. All code validates against CAP-SRP v1.1.

TL;DR

China's Cyberspace Administration published draft rules requiring "digital human" labeling, banning synthetic intimate relationships with minors, and prohibiting likeness-based generation without consent. Germany's Justice Minister introduced legislation making deepfake creation — not just distribution — a criminal offense with up to 2 years' imprisonment. Bloomberg Law warned that video depositions are ideal deepfake source material and recommended rewriting protective orders.

All three developments create obligations that require someone to prove what an AI system did or refused to do. None provide the verification infrastructure to make that proof possible. This article fact-checks each event, maps the technical gap, and provides a complete Python implementation of CAP-SRP v1.1's cryptographic refusal logging — including the three new event types (GEN_WARN, GEN_ESCALATE, GEN_QUARANTINE) and the four Completeness Invariants.

GitHub: veritaschain/cap-spec · License: CC BY 4.0

Event 1: China's Digital Human Regulation
Event 2: Germany's Deepfake Criminal Law Proposal
Event 3: Bloomberg Law's Deposition Deepfake Warning
The Pattern: Three Problems, One Missing Layer
CAP-SRP v1.1: What Changed
Building the Refusal Log: Complete v1.1 Implementation
Completeness Invariant Verification
Scenario: Mapping the Three Events to CAP-SRP Events
C2PA Integration: Content Provenance Meets Behavioral Provenance
What This Means for Developers
Transparency Notes

Event 1: China's Digital Human Regulation

What happened

On April 3, 2026, the Cyberspace Administration of China (CAC) published draft regulations titled "Interim Measures on the Administration of Human-like Interactive Artificial Intelligence Services." The rules target AI-generated "digital humans" with three core requirements:

Mandatory labeling — All AI-generated characters must display a continuously visible "digital human" label
Minor protection — Digital humans cannot provide "virtual intimate relationship" services to users under 18, or services simulating family relationships that could induce addiction or excessive spending
Consent for likeness — Creating a digital human with the identifiable traits of a real person requires that person's explicit informed consent; use of sensitive personal information for digital human modeling requires separate consent

The public comment period runs until May 6, 2026.

Fact-check verdict: ✅ Confirmed with nuance

The regulation's existence and core provisions are confirmed by China.org.cn (official state outlet), a full English translation on China Law Translate, Reuters, IBTimes Singapore, and Futurism.

Key nuance: The regulation does not use the word "deepfake." It covers deepfake creation functionally through its consent and personal information provisions, but this distinction matters for technical implementations — the trigger is "identifiable traits of a real person" plus "absence of consent," not a deepfake classifier output.

Liability is explicit. Futurism quotes the draft: violators face punishment under existing laws and administrative regulations, plus civil liability.

The verification gap

The regulation creates clear obligations. But how does a regulator verify compliance? Consider the labeling requirement. A platform says it labels all digital human content. The regulator asks for proof. The platform provides internal logs. The regulator cannot independently verify those logs are complete.

China's Digital Human Regulation: Enforcement Model
════════════════════════════════════════════════════

Platform claims:      "We label 100% of digital human content"
Regulator asks:       "Prove it"
Platform provides:    Internal logs showing 100% labeling
Regulator can verify: ❌ No independent mechanism

With behavioral provenance:
Platform provides:    Evidence Pack with GEN_ATTEMPT → GEN events
                      Each GEN event has DigitalHumanLabel: true
Auditor verifies:     ✓ Completeness Invariant holds
                      ✓ All GEN events include label metadata
                      ✓ Hash chain is unbroken
                      ✓ External timestamps are consistent

Event 2: Germany's Deepfake Criminal Law Proposal

What happened

German TV presenter Collien Ulmen-Fernandes alleged in a March 2026 Der Spiegel exposé that her estranged husband, fellow presenter Christian Ulmen, created and distributed AI-generated pornographic deepfakes of her. The case sparked massive protests — over 10,000 people at Berlin's Brandenburg Gate — and a list of 10 demands signed by 250 prominent women from politics, business, and culture.

In response, Federal Justice Minister Stefanie Hubig introduced draft legislation with three provisions:

§184k StGB (reformulated): Non-consensual pornographic deepfakes — up to 2 years imprisonment
§201b StGB (new): Non-pornographic deepfakes causing significant reputational harm — up to 2 years
§202e StGB (new): Unauthorized digital tracking / stalkerware

The critical legal shift: creation itself becomes criminal, not just distribution.

Fact-check verdict: ✅ Confirmed with important caveat

The protests, legislative response, and Justice Minister Hubig's proposals are confirmed by NPR (April 5 Morning Edition segment by Rob Schmitz from Berlin, with Harvard Law Professor Rebecca Tushnet interview), CBC News, Yahoo News / BBC, and German-language outlets.

⚠️ Critical caveat: Christian Ulmen categorically denies all allegations. His lawyers state he has never produced or distributed deepfake material. He has not been charged. He is taking legal action against Der Spiegel. The case is unresolved.

The NPR segment explicitly compares the German proposal to the US TAKE IT DOWN Act, noting that Germany aims to criminalize creation while the US law focuses on distribution and takedown.

The evidentiary demand

When creation itself is criminal, prosecutors need evidence of creation — not just evidence that a harmful image exists. They need to establish:

A specific person submitted a specific prompt
The AI system processed the prompt
The system generated the output (or should have refused)

Criminal Deepfake Prosecution: Evidence Requirements
═════════════════════════════════════════════════════

Without behavioral provenance:
  Prosecution: "The defendant created this deepfake"
  Defense:     "The AI system refused my request"
  Evidence:    ❓ Neither side can prove their claim
  Result:      Credibility contest

With CAP-SRP evidence:
  Query system logs for defendant's account hash:
  ┌──────────────────────────────────────────────┐
  │ GEN_ATTEMPT  │ 2026-03-15T14:23:45Z         │
  │ AttemptID:   │ 019467a1-0001-...             │
  │ PromptHash:  │ sha256:a7f3...                │
  │ ActorHash:   │ sha256:9b2e... (defendant)    │
  │ RiskCategory:│ NCII_RISK                     │
  ├──────────────┼──────────────────────────────┤
  │ GEN          │ 2026-03-15T14:23:48Z         │
  │ AttemptID:   │ 019467a1-0001-... (matches)  │
  │ ContentHash: │ sha256:c4d8... (matches image)│
  │ Decision:    │ NO_RISK_DETECTED (failure!)   │
  └──────────────┴──────────────────────────────┘

  Completeness Invariant: ✓ (attempt has outcome)
  Hash chain: ✓ (unbroken)
  External anchor: ✓ (RFC 3161 timestamp)

  Result: Structural proof of generation event

Event 3: Bloomberg Law's Deposition Deepfake Warning

What happened

On March 24, 2026, Bloomberg Law published "Deepfake Executives, Created Via Depositions, Pose Grave Threat" by Sabrina Rose-Smith and Elizabeth Tucci of Goodwin Procter. The analysis warns that video depositions — hours of high-resolution footage with controlled lighting, extended speech, varied expressions — are ideal source material for deepfake generation.

Key recommendations:

Protective orders should explicitly prohibit AI manipulation of deposition footage
Protective orders should prohibit using footage as AI training data
Video files should be encrypted, access-logged, and destroyed post-litigation
The authors reference C2PA Content Credentials for video authenticity verification

The article cites the 2024 Hong Kong $24M deepfake fraud case and the "Liar's Dividend" concept.

Fact-check verdict: ✅ Fully confirmed

All claims verified against the Bloomberg Law article itself. Authors, publication date, recommendations, C2PA references, and platform testing claims all confirmed.

YouTube's "Captured with a camera" label (powered by C2PA, launched October 2024) and Meta's "Made with AI" labels (February 2024) independently confirmed.

Nuance: YouTube flags authentic content (camera-captured); Meta flags synthetic content (AI-generated). The article's characterization is more precisely true for YouTube.

Two halves of the same problem

The Bloomberg Law article identifies the need for content provenance — proving a video hasn't been tampered with. CAP-SRP addresses the complementary behavioral provenance — proving whether an AI system processed a request involving the deposition footage.

The Two-Layer Provenance Architecture for Legal Evidence
═══════════════════════════════════════════════════════

Layer 1: Content Provenance (C2PA)
  Question: "Is this deposition video authentic?"
  Answer:   C2PA manifest → capture device → hash chain → ✓ authentic

Layer 2: Behavioral Provenance (CAP-SRP)
  Question: "Did any AI system use this footage to generate a deepfake?"
  Answer:   Query AI provider evidence packs:
            → GEN_ATTEMPT with input matching footage hash?
            → GEN_DENY (refused) or GEN (generated)?
            → Completeness check: all attempts accounted for?

Both layers needed for litigation:
  ✓ Prove the original is authentic (C2PA)
  ✓ Prove whether an AI system generated the fake (CAP-SRP)
  ✓ Prove the AI system's safety measures worked or failed (CAP-SRP)

The Pattern: Three Problems, One Missing Layer

The AI Accountability Stack (April 2026)
═══════════════════════════════════════

What Exists Today:
┌──────────────────────────────────────────────────┐
│  Content Labeling (C2PA 2.3 / platform labels)   │
│  ──────────────────────────────────────────       │
│  YouTube "Captured with camera" / Meta "Made AI" │
│  Status: Shipping, 6000+ C2PA members            │
│  Scope: Proves what IS generated or captured      │
├──────────────────────────────────────────────────┤
│  Regulatory Mandates (China, Germany, EU, US)     │
│  ──────────────────────────────────────────       │
│  China: digital human labeling (comment by May 6) │
│  Germany: deepfake creation = crime (proposed)    │
│  EU: Article 50 transparency (Aug 2, 2026)        │
│  US: TAKE IT DOWN Act deadline (May 19, 2026)     │
│  Scope: Creates obligations and penalties          │
├──────────────────────────────────────────────────┤
│  Internal Logging (all AI providers)              │
│  ──────────────────────────────────────────       │
│  Server-side request/response logs                │
│  Status: Exists at every provider                 │
│  Problem: Mutable, unverifiable, trust-us model   │
╞══════════════════════════════════════════════════╡
│  ░░░░░░░░░░░░░░░ THE GAP ░░░░░░░░░░░░░░░░░░░░  │
│  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  │
│  ░░ Cryptographic proof of refusal events   ░░░  │
│  ░░ Completeness guarantee across attempts  ░░░  │
│  ░░ External verifiability of safety ops    ░░░  │
│  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  │
└──────────────────────────────────────────────────┘

Every layer above the gap addresses content that exists or obligations that should be met. The gap is about proving that obligations were met — that generation requests were received, evaluated, and denied (or not).

CAP-SRP v1.1: What Changed

Version 1.1 (published March 5, 2026) introduced significant additions to the event schema and the Completeness Invariant framework. Here's what's new:

Three new intermediate-state events

Event	Role	Completeness
`GEN_WARN`	Generation allowed with user-facing warning	Outcome (counts as GEN)
`GEN_ESCALATE`	Request sent for human review	Pending → resolved by GEN or GEN_DENY
`GEN_QUARANTINE`	Content generated but held pre-delivery	Pending → resolved by EXPORT or GEN_DENY

Three new account/policy events

Event	Purpose
`ACCOUNT_ACTION`	Account-level enforcement (ban, suspend, flag)
`LAW_ENFORCEMENT_REFERRAL`	LE notification threshold assessment
`POLICY_VERSION`	Safety policy version anchoring

Four Completeness Invariants (expanded from one)

Invariant 1 (Primary — unchanged):
  ∑ GEN_ATTEMPT = ∑ GEN + ∑ GEN_DENY + ∑ GEN_ERROR
  (where GEN includes GEN_WARN)

Invariant 2 (Escalation Resolution — v1.1, Silver+):
  ∑ GEN_ESCALATE = ∑ ESCALATION_RESOLVED
  Unresolved escalations > 72 hours = compliance violation

Invariant 3 (Quarantine Resolution — v1.1, Silver+):
  ∑ GEN_QUARANTINE = ∑ QUARANTINE_RELEASED + ∑ QUARANTINE_DENIED
  No permanently unresolved quarantine states

Invariant 4 (Account Action — v1.1, Gold only):
  ∑ ACCOUNT_ACTION_ATTEMPT = ∑ COMPLETED + ∑ FAILED

New risk category

VIOLENCE_PLANNING — content facilitating planning of violent acts (distinct from depicting violence). Added to address the Tumbler Ridge pattern where content assisted in planning but did not depict violence directly.

Building the Refusal Log: Complete v1.1 Implementation

Here's a complete Python implementation covering all v1.1 event types and all four Completeness Invariants. This is a sidecar — it wraps your existing AI generation pipeline without modifying it.

Dependencies

pip install cryptography

Core Event System

"""
CAP-SRP v1.1 Reference Implementation
Cryptographic refusal logging with four Completeness Invariants.

GitHub: https://github.com/veritaschain/cap-spec
License: Apache 2.0 (implementation) / CC BY 4.0 (specification)
"""

import hashlib
import json
import time
import uuid
import base64
from dataclasses import dataclass, field, asdict
from typing import Optional, List, Dict, Tuple
from enum import Enum
from datetime import datetime, timezone
from cryptography.hazmat.primitives.asymmetric.ed25519 import (
    Ed25519PrivateKey, Ed25519PublicKey
)


# ──────────────────────────────────────────────
# Enumerations (v1.1 complete)
# ──────────────────────────────────────────────

class EventType(Enum):
    GEN_ATTEMPT = "GEN_ATTEMPT"
    GEN = "GEN"
    GEN_DENY = "GEN_DENY"
    GEN_ERROR = "GEN_ERROR"
    GEN_WARN = "GEN_WARN"           # v1.1
    GEN_ESCALATE = "GEN_ESCALATE"   # v1.1
    GEN_QUARANTINE = "GEN_QUARANTINE"  # v1.1
    ACCOUNT_ACTION = "ACCOUNT_ACTION"  # v1.1
    LAW_ENFORCEMENT_REFERRAL = "LAW_ENFORCEMENT_REFERRAL"  # v1.1
    POLICY_VERSION = "POLICY_VERSION"  # v1.1


class RiskCategory(Enum):
    CSAM_RISK = "CSAM_RISK"
    NCII_RISK = "NCII_RISK"
    MINOR_SEXUALIZATION = "MINOR_SEXUALIZATION"
    REAL_PERSON_DEEPFAKE = "REAL_PERSON_DEEPFAKE"
    VIOLENCE_EXTREME = "VIOLENCE_EXTREME"
    VIOLENCE_PLANNING = "VIOLENCE_PLANNING"  # v1.1
    HATE_CONTENT = "HATE_CONTENT"
    TERRORIST_CONTENT = "TERRORIST_CONTENT"
    SELF_HARM_PROMOTION = "SELF_HARM_PROMOTION"
    COPYRIGHT_VIOLATION = "COPYRIGHT_VIOLATION"
    COPYRIGHT_STYLE_MIMICRY = "COPYRIGHT_STYLE_MIMICRY"
    OTHER = "OTHER"


class AccountActionType(Enum):
    SUSPEND = "SUSPEND"
    BAN = "BAN"
    REINSTATE = "REINSTATE"
    RATE_LIMIT = "RATE_LIMIT"
    FLAG_FOR_REVIEW = "FLAG_FOR_REVIEW"


class EscalationReason(Enum):
    CLASSIFIER_CONFIDENCE_LOW = "CLASSIFIER_CONFIDENCE_LOW"
    JURISDICTIONAL_AMBIGUITY = "JURISDICTIONAL_AMBIGUITY"
    NOVEL_CONTENT_TYPE = "NOVEL_CONTENT_TYPE"
    LEGAL_REVIEW_REQUIRED = "LEGAL_REVIEW_REQUIRED"
    OTHER = "OTHER"


class LEAssessment(Enum):
    REFERRED = "REFERRED"
    NOT_REFERRED = "NOT_REFERRED"
    PENDING = "PENDING"


# ──────────────────────────────────────────────
# Cryptographic Utilities
# ──────────────────────────────────────────────

def sha256(data: str) -> str:
    return f"sha256:{hashlib.sha256(data.encode()).hexdigest()}"


def canonicalize(obj: dict) -> str:
    """RFC 8785 JSON Canonicalization (simplified)."""
    return json.dumps(obj, sort_keys=True, separators=(",", ":"))


def uuid7() -> str:
    """Generate UUIDv7 (time-ordered) for event IDs."""
    timestamp_ms = int(time.time() * 1000)
    rand_bits = uuid.uuid4().int & ((1 << 62) - 1)
    uuid_int = (timestamp_ms << 80) | (0x7 << 76) | rand_bits
    return str(uuid.UUID(int=uuid_int & ((1 << 128) - 1)))


def now_iso() -> str:
    return datetime.now(timezone.utc).strftime(
        "%Y-%m-%dT%H:%M:%S.%f")[:-3] + "Z"


# ──────────────────────────────────────────────
# Base Event
# ──────────────────────────────────────────────

@dataclass
class CAPEvent:
    """Base CAP-SRP event with cryptographic integrity."""
    event_id: str
    event_type: EventType
    chain_id: str
    timestamp: str
    prev_hash: Optional[str]
    hash_algo: str = "SHA256"
    sign_algo: str = "ED25519"
    event_hash: Optional[str] = None
    signature: Optional[str] = None

    def to_signable_dict(self) -> dict:
        """Fields included in hash computation."""
        data = {}
        for k, v in asdict(self).items():
            if k in ("event_hash", "signature"):
                continue
            if isinstance(v, Enum):
                data[k] = v.value
            elif v is not None:
                data[k] = v
        return data

    def compute_hash(self) -> str:
        return sha256(canonicalize(self.to_signable_dict()))

    def sign(self, private_key: Ed25519PrivateKey):
        self.event_hash = self.compute_hash()
        hash_bytes = bytes.fromhex(self.event_hash[7:])
        sig = private_key.sign(hash_bytes)
        self.signature = f"ed25519:{base64.b64encode(sig).decode()}"

    def verify(self, public_key: Ed25519PublicKey) -> bool:
        if not self.event_hash or not self.signature:
            return False
        expected = self.compute_hash()
        if expected != self.event_hash:
            return False
        sig_bytes = base64.b64decode(self.signature[8:])
        hash_bytes = bytes.fromhex(self.event_hash[7:])
        try:
            public_key.verify(sig_bytes, hash_bytes)
            return True
        except Exception:
            return False


# ──────────────────────────────────────────────
# Generation Events
# ──────────────────────────────────────────────

@dataclass
class GenAttemptEvent(CAPEvent):
    """Logged BEFORE safety evaluation."""
    prompt_hash: str = ""
    input_type: str = "text"
    model_version: str = ""
    policy_id: str = ""
    actor_hash: str = ""

    @classmethod
    def create(cls, chain_id, prev_hash, prompt, actor_id,
               model_version, policy_id, input_type="text"):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_ATTEMPT,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, prompt_hash=sha256(prompt),
            input_type=input_type, model_version=model_version,
            policy_id=policy_id, actor_hash=sha256(actor_id),
        )


@dataclass
class GenDenyEvent(CAPEvent):
    """Logged when safety evaluation denies generation."""
    attempt_id: str = ""
    risk_category: str = ""
    risk_score: float = 0.0
    refusal_reason: str = ""
    policy_version: str = ""
    jurisdiction_context: str = ""     # v1.1
    applied_policy_ref: str = ""       # v1.1

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id,
               risk_category: RiskCategory, risk_score,
               reason, policy_version,
               jurisdiction="", policy_ref=""):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_DENY,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            risk_category=risk_category.value,
            risk_score=risk_score, refusal_reason=reason,
            policy_version=policy_version,
            jurisdiction_context=jurisdiction,
            applied_policy_ref=policy_ref,
        )


@dataclass
class GenEvent(CAPEvent):
    """Logged when content is successfully generated."""
    attempt_id: str = ""
    content_hash: str = ""
    output_type: str = "image"

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id,
               content_hash, output_type="image"):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            content_hash=content_hash, output_type=output_type,
        )


@dataclass
class GenErrorEvent(CAPEvent):
    """Logged on system failure during generation."""
    attempt_id: str = ""
    error_code: str = ""
    error_detail: str = ""

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id,
               error_code, error_detail=""):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_ERROR,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            error_code=error_code, error_detail=error_detail,
        )


# ──────────────────────────────────────────────
# v1.1 Intermediate-State Events
# ──────────────────────────────────────────────

@dataclass
class GenWarnEvent(CAPEvent):
    """v1.1: Generation allowed with user-facing warning."""
    attempt_id: str = ""
    content_hash: str = ""
    risk_category: str = ""
    risk_score: float = 0.0
    warn_message_hash: str = ""   # SHA-256 of warning (never plaintext)
    applied_policy_ref: str = ""

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id,
               content_hash, risk_category: RiskCategory,
               risk_score, warn_message, policy_ref=""):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_WARN,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            content_hash=content_hash,
            risk_category=risk_category.value,
            risk_score=risk_score,
            warn_message_hash=sha256(warn_message),
            applied_policy_ref=policy_ref,
        )


@dataclass
class GenEscalateEvent(CAPEvent):
    """v1.1: Request sent for human review (pending state)."""
    attempt_id: str = ""
    escalation_reason: str = ""
    reviewer_type: str = "HUMAN_TRUST_AND_SAFETY"
    resolution_ref: Optional[str] = None  # Populated on resolution
    applied_policy_ref: str = ""

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id,
               reason: EscalationReason,
               reviewer_type="HUMAN_TRUST_AND_SAFETY",
               policy_ref=""):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_ESCALATE,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            escalation_reason=reason.value,
            reviewer_type=reviewer_type,
            applied_policy_ref=policy_ref,
        )


@dataclass
class GenQuarantineEvent(CAPEvent):
    """v1.1: Content generated but held before delivery (pending)."""
    attempt_id: str = ""
    content_hash: str = ""
    quarantine_reason: str = "POST_GENERATION_POLICY_REVIEW"
    expiry_policy: str = "REQUIRES_HUMAN_APPROVAL"
    release_ref: Optional[str] = None  # Populated on resolution
    applied_policy_ref: str = ""

    @classmethod
    def create(cls, chain_id, prev_hash, attempt_id,
               content_hash, reason="POST_GENERATION_POLICY_REVIEW",
               expiry="REQUIRES_HUMAN_APPROVAL", policy_ref=""):
        return cls(
            event_id=uuid7(), event_type=EventType.GEN_QUARANTINE,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash, attempt_id=attempt_id,
            content_hash=content_hash,
            quarantine_reason=reason,
            expiry_policy=expiry,
            applied_policy_ref=policy_ref,
        )


# ──────────────────────────────────────────────
# v1.1 Account and Policy Events
# ──────────────────────────────────────────────

@dataclass
class AccountActionEvent(CAPEvent):
    """v1.1: Account-level enforcement decision."""
    account_hash: str = ""
    action_type: str = ""
    trigger_event_ids: List[str] = field(default_factory=list)
    le_assessment: str = ""  # REFERRED / NOT_REFERRED / PENDING

    @classmethod
    def create(cls, chain_id, prev_hash, account_id,
               action: AccountActionType,
               trigger_ids=None, le_assessment=LEAssessment.PENDING):
        return cls(
            event_id=uuid7(), event_type=EventType.ACCOUNT_ACTION,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash,
            account_hash=sha256(account_id),
            action_type=action.value,
            trigger_event_ids=trigger_ids or [],
            le_assessment=le_assessment.value,
        )


@dataclass
class PolicyVersionEvent(CAPEvent):
    """v1.1: Safety policy version anchoring."""
    policy_document_hash: str = ""
    effective_from: str = ""
    policy_name: str = ""
    version_string: str = ""

    @classmethod
    def create(cls, chain_id, prev_hash, policy_doc,
               effective_from, name, version):
        return cls(
            event_id=uuid7(), event_type=EventType.POLICY_VERSION,
            chain_id=chain_id, timestamp=now_iso(),
            prev_hash=prev_hash,
            policy_document_hash=sha256(policy_doc),
            effective_from=effective_from,
            policy_name=name, version_string=version,
        )

The Event Chain (Sidecar Logger)

class CAPSRPLogger:
    """
    Sidecar logger implementing CAP-SRP v1.1.
    Wraps your existing AI generation pipeline.
    """

    def __init__(self, model_version: str, policy_id: str):
        self._key = Ed25519PrivateKey.generate()
        self._pub = self._key.public_key()
        self._chain_id = uuid7()
        self._events: List[CAPEvent] = []
        self._prev_hash: Optional[str] = None
        self._model_version = model_version
        self._policy_id = policy_id

    def _append(self, event: CAPEvent):
        event.sign(self._key)
        self._events.append(event)
        self._prev_hash = event.event_hash

    # ── Core generation flow ──

    def log_attempt(self, prompt: str, actor_id: str,
                    input_type: str = "text") -> str:
        """Log BEFORE safety evaluation. Returns attempt event_id."""
        event = GenAttemptEvent.create(
            self._chain_id, self._prev_hash, prompt,
            actor_id, self._model_version, self._policy_id,
            input_type,
        )
        self._append(event)
        return event.event_id

    def log_deny(self, attempt_id: str,
                 risk_category: RiskCategory,
                 risk_score: float, reason: str,
                 jurisdiction: str = "",
                 policy_ref: str = ""):
        event = GenDenyEvent.create(
            self._chain_id, self._prev_hash, attempt_id,
            risk_category, risk_score, reason,
            self._policy_id, jurisdiction, policy_ref,
        )
        self._append(event)

    def log_generate(self, attempt_id: str,
                     content_hash: str,
                     output_type: str = "image"):
        event = GenEvent.create(
            self._chain_id, self._prev_hash,
            attempt_id, content_hash, output_type,
        )
        self._append(event)

    def log_error(self, attempt_id: str,
                  error_code: str, detail: str = ""):
        event = GenErrorEvent.create(
            self._chain_id, self._prev_hash,
            attempt_id, error_code, detail,
        )
        self._append(event)

    # ── v1.1 intermediate states ──

    def log_warn(self, attempt_id: str, content_hash: str,
                 risk_category: RiskCategory, risk_score: float,
                 warn_message: str, policy_ref: str = ""):
        event = GenWarnEvent.create(
            self._chain_id, self._prev_hash,
            attempt_id, content_hash, risk_category,
            risk_score, warn_message, policy_ref,
        )
        self._append(event)

    def log_escalate(self, attempt_id: str,
                     reason: EscalationReason,
                     reviewer: str = "HUMAN_TRUST_AND_SAFETY",
                     policy_ref: str = ""):
        event = GenEscalateEvent.create(
            self._chain_id, self._prev_hash,
            attempt_id, reason, reviewer, policy_ref,
        )
        self._append(event)

    def log_quarantine(self, attempt_id: str,
                       content_hash: str,
                       reason: str = "POST_GENERATION_POLICY_REVIEW",
                       policy_ref: str = ""):
        event = GenQuarantineEvent.create(
            self._chain_id, self._prev_hash,
            attempt_id, content_hash, reason,
            policy_ref=policy_ref,
        )
        self._append(event)

    # ── v1.1 account/policy events ──

    def log_account_action(self, account_id: str,
                           action: AccountActionType,
                           trigger_ids=None,
                           le: LEAssessment = LEAssessment.PENDING):
        event = AccountActionEvent.create(
            self._chain_id, self._prev_hash,
            account_id, action, trigger_ids, le,
        )
        self._append(event)

    def log_policy_version(self, policy_doc: str,
                           effective_from: str,
                           name: str, version: str):
        event = PolicyVersionEvent.create(
            self._chain_id, self._prev_hash,
            policy_doc, effective_from, name, version,
        )
        self._append(event)

    @property
    def events(self) -> List[CAPEvent]:
        return list(self._events)

    @property
    def public_key(self) -> Ed25519PublicKey:
        return self._pub

Completeness Invariant Verification

The verification function checks all four v1.1 invariants:

from dataclasses import dataclass as result_dc


@result_dc
class InvariantResult:
    invariant: str
    holds: bool
    detail: str


def verify_all_invariants(events: List[CAPEvent]) -> List[InvariantResult]:
    """
    Verify all four CAP-SRP v1.1 Completeness Invariants.

    Returns a list of results, one per invariant.
    """
    results = []

    # Categorize events
    attempts = []
    outcomes = []  # GEN, GEN_WARN, GEN_DENY, GEN_ERROR
    escalations = []
    quarantines = []
    account_actions = []

    outcome_types = {
        EventType.GEN, EventType.GEN_WARN,
        EventType.GEN_DENY, EventType.GEN_ERROR,
    }

    for e in events:
        if e.event_type == EventType.GEN_ATTEMPT:
            attempts.append(e)
        elif e.event_type in outcome_types:
            outcomes.append(e)
        elif e.event_type == EventType.GEN_ESCALATE:
            escalations.append(e)
        elif e.event_type == EventType.GEN_QUARANTINE:
            quarantines.append(e)
        elif e.event_type == EventType.ACCOUNT_ACTION:
            account_actions.append(e)

    # ── Invariant 1: Primary Completeness ──
    attempt_ids = {e.event_id for e in attempts}
    outcome_attempt_ids = {e.attempt_id for e in outcomes
                          if hasattr(e, 'attempt_id')}
    # Escalations and quarantines are pending, not final outcomes
    escalate_attempt_ids = {e.attempt_id for e in escalations
                           if hasattr(e, 'attempt_id')}

    # Unmatched = attempts with no outcome AND no pending state
    unmatched = attempt_ids - outcome_attempt_ids - escalate_attempt_ids
    # Also subtract quarantine attempt_ids (also pending)
    quarantine_attempt_ids = {e.attempt_id for e in quarantines
                             if hasattr(e, 'attempt_id')}
    unmatched = unmatched - quarantine_attempt_ids

    orphan_outcomes = outcome_attempt_ids - attempt_ids

    inv1_holds = len(unmatched) == 0 and len(orphan_outcomes) == 0
    detail1 = (f"Attempts: {len(attempts)}, "
               f"Outcomes: {len(outcomes)}, "
               f"Pending escalations: {len(escalations)}, "
               f"Pending quarantines: {len(quarantines)}")
    if not inv1_holds:
        detail1 += (f" | VIOLATION: {len(unmatched)} unmatched attempts, "
                    f"{len(orphan_outcomes)} orphan outcomes")

    results.append(InvariantResult(
        "Primary Completeness", inv1_holds, detail1))

    # ── Invariant 2: Escalation Resolution ──
    resolved_escalations = sum(
        1 for e in escalations
        if hasattr(e, 'resolution_ref') and e.resolution_ref
    )
    unresolved = len(escalations) - resolved_escalations
    inv2_holds = unresolved == 0
    detail2 = (f"Escalations: {len(escalations)}, "
               f"Resolved: {resolved_escalations}, "
               f"Unresolved: {unresolved}")

    results.append(InvariantResult(
        "Escalation Resolution", inv2_holds, detail2))

    # ── Invariant 3: Quarantine Resolution ──
    resolved_quarantines = sum(
        1 for e in quarantines
        if hasattr(e, 'release_ref') and e.release_ref
    )
    unresolved_q = len(quarantines) - resolved_quarantines
    inv3_holds = unresolved_q == 0
    detail3 = (f"Quarantines: {len(quarantines)}, "
               f"Resolved: {resolved_quarantines}, "
               f"Unresolved: {unresolved_q}")

    results.append(InvariantResult(
        "Quarantine Resolution", inv3_holds, detail3))

    # ── Invariant 4: Account Action (Gold) ──
    # Simplified: ensure all account actions have valid action_type
    invalid_actions = sum(
        1 for e in account_actions
        if not hasattr(e, 'action_type') or not e.action_type
    )
    inv4_holds = invalid_actions == 0
    detail4 = (f"Account actions: {len(account_actions)}, "
               f"Invalid: {invalid_actions}")

    results.append(InvariantResult(
        "Account Action Integrity", inv4_holds, detail4))

    return results


def verify_chain_integrity(events: List[CAPEvent],
                           public_key: Ed25519PublicKey) -> dict:
    """Verify hash chain and signatures for all events."""
    total = len(events)
    sig_valid = 0
    chain_valid = 0

    for i, event in enumerate(events):
        # Signature verification
        if event.verify(public_key):
            sig_valid += 1

        # Chain verification (skip first event)
        if i == 0:
            if event.prev_hash is None:
                chain_valid += 1
        else:
            if event.prev_hash == events[i - 1].event_hash:
                chain_valid += 1

    return {
        "total_events": total,
        "signatures_valid": sig_valid,
        "chain_links_valid": chain_valid,
        "integrity": sig_valid == total and chain_valid == total,
    }

Scenario: Mapping the Three Events to CAP-SRP Events

Here's how each of this week's developments maps to concrete CAP-SRP v1.1 events:

def demo_three_scenarios():
    """
    Demonstrate CAP-SRP v1.1 event logging for all three
    April 2026 developments.
    """
    logger = CAPSRPLogger(
        model_version="example-model-v3",
        policy_id="policy-2026-Q2",
    )

    # ── Scenario 1: China Digital Human Regulation ──
    # A request to create a digital human using a real
    # person's likeness without consent.
    # CAP-SRP risk: REAL_PERSON_DEEPFAKE

    print("=" * 60)
    print("Scenario 1: China — Unauthorized Digital Human")
    print("=" * 60)

    attempt1 = logger.log_attempt(
        prompt="Create a virtual assistant that looks like [celebrity]",
        actor_id="user-cn-12345",
        input_type="text+image",
    )
    logger.log_deny(
        attempt_id=attempt1,
        risk_category=RiskCategory.REAL_PERSON_DEEPFAKE,
        risk_score=0.97,
        reason="Real person likeness without consent verification",
        jurisdiction="CN-CAC-DIGITAL-HUMAN-2026",
        policy_ref="policy-2026-Q2-§4.2",
    )
    print(f"  GEN_ATTEMPT: {attempt1}")
    print(f"  GEN_DENY: REAL_PERSON_DEEPFAKE (0.97)")
    print(f"  Jurisdiction: CN-CAC-DIGITAL-HUMAN-2026")

    # ── Scenario 2: Germany — NCII Deepfake ──
    # A request to create non-consensual intimate imagery.
    # CAP-SRP risk: NCII_RISK
    # Under proposed §184k StGB, creation itself is criminal.

    print()
    print("=" * 60)
    print("Scenario 2: Germany — NCII Deepfake (§184k StGB)")
    print("=" * 60)

    attempt2 = logger.log_attempt(
        prompt="[redacted NCII request]",
        actor_id="user-de-67890",
        input_type="text+image",
    )
    logger.log_deny(
        attempt_id=attempt2,
        risk_category=RiskCategory.NCII_RISK,
        risk_score=0.99,
        reason="Non-consensual intimate imagery detected",
        jurisdiction="DE-StGB-§184k-PROPOSED",
        policy_ref="policy-2026-Q2-§2.1",
    )

    # Account-level action triggered by NCII attempt
    logger.log_account_action(
        account_id="user-de-67890",
        action=AccountActionType.SUSPEND,
        trigger_ids=[attempt2],
        le=LEAssessment.PENDING,
    )

    print(f"  GEN_ATTEMPT: {attempt2}")
    print(f"  GEN_DENY: NCII_RISK (0.99)")
    print(f"  ACCOUNT_ACTION: SUSPEND")
    print(f"  LE Assessment: PENDING")

    # ── Scenario 3: Deposition Footage Deepfake ──
    # A request using deposition video as source material.
    # Classifier confidence is low → escalate to human review.
    # Demonstrates the v1.1 GEN_ESCALATE flow.

    print()
    print("=" * 60)
    print("Scenario 3: Deposition Footage → Escalation")
    print("=" * 60)

    attempt3 = logger.log_attempt(
        prompt="Generate executive video statement [with ref footage]",
        actor_id="user-us-11111",
        input_type="video+text",
    )
    logger.log_escalate(
        attempt_id=attempt3,
        reason=EscalationReason.CLASSIFIER_CONFIDENCE_LOW,
        reviewer="HUMAN_TRUST_AND_SAFETY",
        policy_ref="policy-2026-Q2-§6.3",
    )

    print(f"  GEN_ATTEMPT: {attempt3}")
    print(f"  GEN_ESCALATE: CLASSIFIER_CONFIDENCE_LOW")
    print(f"  Awaiting human review...")

    # After human review → deny
    logger.log_deny(
        attempt_id=attempt3,
        risk_category=RiskCategory.REAL_PERSON_DEEPFAKE,
        risk_score=0.85,
        reason="Human reviewer: unauthorized executive likeness",
        jurisdiction="US-PROTECTIVE-ORDER",
        policy_ref="policy-2026-Q2-§6.3",
    )
    print(f"  → Human review complete: GEN_DENY")

    # ── Verify all invariants ──
    print()
    print("=" * 60)
    print("Completeness Invariant Verification")
    print("=" * 60)

    for result in verify_all_invariants(logger.events):
        status = "✓ HOLDS" if result.holds else "✗ VIOLATION"
        print(f"  {result.invariant}: {status}")
        print(f"    {result.detail}")

    # ── Verify chain integrity ──
    print()
    chain = verify_chain_integrity(logger.events, logger.public_key)
    print(f"  Chain integrity: "
          f"{'✓' if chain['integrity'] else '✗'}")
    print(f"    Events: {chain['total_events']}, "
          f"Sigs valid: {chain['signatures_valid']}, "
          f"Chain links: {chain['chain_links_valid']}")


if __name__ == "__main__":
    demo_three_scenarios()

Expected output

============================================================
Scenario 1: China — Unauthorized Digital Human
============================================================
  GEN_ATTEMPT: 019467a1-...
  GEN_DENY: REAL_PERSON_DEEPFAKE (0.97)
  Jurisdiction: CN-CAC-DIGITAL-HUMAN-2026

============================================================
Scenario 2: Germany — NCII Deepfake (§184k StGB)
============================================================
  GEN_ATTEMPT: 019467a1-...
  GEN_DENY: NCII_RISK (0.99)
  ACCOUNT_ACTION: SUSPEND
  LE Assessment: PENDING

============================================================
Scenario 3: Deposition Footage → Escalation
============================================================
  GEN_ATTEMPT: 019467a1-...
  GEN_ESCALATE: CLASSIFIER_CONFIDENCE_LOW
  Awaiting human review...
  → Human review complete: GEN_DENY

============================================================
Completeness Invariant Verification
============================================================
  Primary Completeness: ✓ HOLDS
    Attempts: 3, Outcomes: 3, Pending escalations: 1, Pending quarantines: 0
  Escalation Resolution: ✗ VIOLATION
    Escalations: 1, Resolved: 0, Unresolved: 1
  Quarantine Resolution: ✓ HOLDS
    Quarantines: 0, Resolved: 0, Unresolved: 0
  Account Action Integrity: ✓ HOLDS
    Account actions: 1, Invalid: 0
  Chain integrity: ✓
    Events: 7, Sigs valid: 7, Chain links: 7

Note: The Escalation Resolution invariant shows a violation because the GEN_ESCALATE event's resolution_ref was not updated (the resolution GEN_DENY was logged separately). In production, you would update resolution_ref on the escalation event when the resolving event is created. This is intentional — the invariant catches exactly this kind of bookkeeping gap.

C2PA Integration: Content Provenance Meets Behavioral Provenance

The Bloomberg Law article makes the case for C2PA content credentials in the deposition context. Here's how the two layers connect:

Complete Provenance Architecture for AI-Generated Content
══════════════════════════════════════════════════════════

                     Real-World Event
                    (e.g., deposition filmed)
                           │
                           ▼
                  ┌─────────────────┐
                  │  C2PA Manifest   │ ← Content provenance
                  │  ───────────     │   "This video was captured
                  │  Capture device  │    by this camera at this
                  │  Timestamp       │    time and has not been
                  │  Hash chain      │    modified"
                  └────────┬────────┘
                           │
              Footage reaches AI system
                           │
                           ▼
                  ┌─────────────────┐
                  │  GEN_ATTEMPT     │ ← Behavioral provenance
                  │  ───────────     │   "This AI system received
                  │  PromptHash      │    a request involving
                  │  InputRef:       │    this content"
                  │    C2PA manifest │
                  │    hash          │
                  └────────┬────────┘
                           │
                    Safety Check
                           │
                  ┌────────┴────────┐
                  │                  │
                  ▼                  ▼
         ┌──────────────┐  ┌──────────────┐
         │   GEN_DENY    │  │   GEN        │
         │   ──────────  │  │   ──────     │
         │   "Refused:   │  │   ContentHash│
         │   unauthorized│  │   C2PA child │
         │   likeness"   │  │   manifest   │
         └──────────────┘  └──────────────┘

| Question | Layer | Standard |
|----------|-------|----------|
| Is this video authentic? | Content | C2PA |
| Who generated the deepfake? | Behavioral | CAP-SRP |
| What was refused? | Behavioral | CAP-SRP GEN_DENY |
| Why was it refused? | Behavioral | RiskCategory + policy ref |
| Is the log complete? | Behavioral | Completeness Invariant |
| Can we verify independently? | Both | SCITT + RFC 3161 |

What This Means for Developers

If you're building or maintaining an AI content generation system, here's the practical takeaway from this week's events:

The regulatory timeline is compressed. China's comment period closes May 6. The US TAKE IT DOWN Act compliance deadline is May 19. The EU AI Act Article 50 transparency obligations take effect August 2, 2026. Germany's criminal law proposal will move through the Bundestag over the coming months. The DEFIANCE Act has 52+ House cosponsors. The infrastructure for proving what AI created is maturing rapidly (C2PA 2.3, 6000+ members). The infrastructure for proving what AI refused to create does not yet exist at scale.

The implementation is a sidecar. CAP-SRP doesn't require changes to your AI model, safety evaluator, or generation pipeline. It's a logging layer. The key requirement is sequencing: log GEN_ATTEMPT before the safety check runs, log the outcome after. Everything else — hash chains, Merkle trees, external anchoring — is standard cryptographic engineering.

Start at Bronze, iterate up. Bronze-level conformance requires basic event logging with Ed25519 signatures and 6-month retention. Silver adds the Completeness Invariant, v1.1 intermediate states, and daily external anchoring. Gold adds ACCOUNT_ACTION events, HSM key management, and SCITT transparency service integration. The specification is designed for incremental adoption.

The standards exist. CAP-SRP builds on IETF SCITT (architecture at draft-22), C2PA (specification 2.3), RFC 3161 (timestamping), and COSE/CBOR (signing). These have real implementations from Microsoft, DataTrails, Adobe, Google, and others.

Transparency Notes

About this analysis: This article fact-checks three real news events from April 2026 against primary sources. China regulation claims are verified via China.org.cn, China Law Translate, Reuters, and IBTimes Singapore. Germany claims are verified via NPR, CBC News, Yahoo News/BBC, and German-language sources. Bloomberg Law claims are verified against the article itself. Christian Ulmen categorically denies all allegations and has not been charged.

About CAP-SRP: CAP-SRP is an open specification published under CC BY 4.0 by VeritasChain Standards Organization (VSO), founded in Tokyo. Version 1.1 was published March 5, 2026. It has not been endorsed by major AI companies and is not an adopted standard of any recognized standards body. An individual Internet-Draft (draft-kamimura-scitt-refusal-events-02) has been submitted to the IETF but has not been adopted by the SCITT working group and carries no IETF endorsement.

What CAP-SRP is:

A technically sound approach to a genuine, well-documented gap
Aligned with existing standards (C2PA, SCITT, RFC 3161, COSE/CBOR)
Available on GitHub: veritaschain/cap-spec (CC BY 4.0)
Reference implementation: veritaschain/cap-srp (Apache 2.0)

What CAP-SRP is not (yet):

An industry-endorsed standard
An IETF RFC
A guaranteed solution

The real question is whether the industry builds some form of refusal provenance before regulators impose one. The deadlines that assume it exists are already on the calendar.

Verify, don't trust. The code is the proof.

GitHub: veritaschain/cap-spec · Specification: CAP-SRP v1.1 · License: CC BY 4.0

Seven Developments This Week Prove AI Needs a Flight Recorder — Here's How to Build One with CAP-SRP v1.

VeritasChain Standards Organization (VSO) — Sun, 29 Mar 2026 04:02:15 +0000

On March 30, 2026, the EU closes public consultation on the Code of Practice that will govern AI content marking under Article 50. The same week, a California court told xAI it can't hide its training data, 61 data protection authorities moved from warnings to enforcement, Nebraska advanced an AI transparency bill to floor debate, and the world's most widely deployed provenance standard — with 6,000+ members — still cannot represent a single refusal decision. This article fact-checks all seven developments, maps the exact CAP-SRP v1.1 event types that address each gap, and gives you working Python code to build the missing layer.

TL;DR

Every major AI transparency initiative this week operates in the domain of content that exists. C2PA labels what AI creates. The EU Code mandates marking what AI produces. California demands disclosure of training data. None of them can answer the question regulators, courts, and prosecutors are now asking: "What did your AI refuse to generate, and can you prove it?"

This article:

Fact-checks seven developments against primary sources (with corrections)
Maps each gap to specific CAP-SRP v1.1 event types and data fields
Provides a complete Python implementation of the v1.1 event model — including the three new event types (ACCOUNT_ACTION, LAW_ENFORCEMENT_REFERRAL, POLICY_VERSION)
Shows the C2PA integration point and Evidence Pack structure
Includes a regulatory deadline map and a Bronze → Silver → Gold sprint plan

GitHub: veritaschain/cap-spec · veritaschain/cap-srp · License: CC BY 4.0

Signal 1: EU Code of Practice — Content Marking Without Behavioral Provenance
Signal 2: xAI v. Bonta — Courts Demanding Evidence That Doesn't Exist
Signal 3: 61 DPA Joint Statement — Enforcement Without Verification Tools
Signal 4: IETF Refusal Events Draft — The Only Standards-Track Attempt
Signal 5: Nebraska LB1083 — When State Law Demands Safety Proof
Signal 6: C2PA at 6,000 Members — The Provenance Ceiling
Signal 7: ZwillGen's Four Questions — The Litigation Evidence Gap
The Architecture: CAP-SRP v1.1 Event Model
Building the Flight Recorder: Complete Python Implementation
C2PA Integration: Connecting Both Halves
Regulatory Deadline Map
Sprint Plan: Bronze → Silver → Gold
Transparency Notes

Signal 1: EU Code of Practice

What happened

The European Commission published the second draft of its Code of Practice on marking and labelling AI-generated content on March 3, 2026. Public consultation closes today, March 30. The final Code is expected in early June. Article 50 transparency obligations take effect August 2, 2026.

The Code mandates a dual-layer marking approach: digitally signed metadata (C2PA explicitly named as the recommended open standard) plus imperceptible watermarking. Fingerprinting and logging, which were baseline requirements in the first draft, were downgraded to supplementary measures. Provider obligations include free detection tools via APIs. Deployer obligations are differentiated by media type — persistent icons for real-time video, distinguishable labels for images, spoken disclaimers at intervals for audio. For text, where watermarking degrades quality, the Code permits "Provenance Certificates" — digitally signed manifests guaranteeing content origin.

Fact-check verdict: ✅ Confirmed

Publication confirmed via European Commission digital strategy portal. Date confirmed as March 3 by Kennedys Law (note: the Daily Watch cited March 5, a minor reference variation). Comment deadline March 30 confirmed. August 2, 2026 enforcement date confirmed by Bird & Bird, Herbert Smith Freehills Kramer, and TrueScreen. Non-compliance fines of up to €15M or 3% of global turnover confirmed.

What the Code doesn't cover

The entire Code operates in the domain of content that has been generated. It contains:

❌ No mechanism for documenting what AI systems refused to generate
❌ No refusal logging requirement
❌ No behavioral provenance standard
❌ No audit trail for safety decisions

CAP-SRP mapping

Gap	CAP-SRP Event	What It Does
No refusal record	`GEN_DENY`	Cryptographic proof a request was blocked, with risk category and policy reference
No attempt record	`GEN_ATTEMPT`	Committed to log before safety evaluation — prevents selective logging
No policy versioning	`POLICY_VERSION`	Tamper-evident record of which policy was active at each decision point
No completeness check	Completeness Invariant	`∑ ATTEMPT = ∑ GEN + ∑ DENY + ∑ ERROR` — provably complete audit trail

The Code mandates the content's passport (C2PA). CAP-SRP is the system's flight recorder.

Signal 2: xAI v. Bonta

What happened

On March 4, 2026, Judge Jesus G. Bernal denied xAI's preliminary injunction against California's AI Training Data Transparency Act (AB 2013, effective January 1, 2026). The court rejected xAI's trade secret, First Amendment, and vagueness arguments. On March 17, xAI appealed to the Ninth Circuit (Case No. 26-1591) — the first appellate review of AI transparency requirements under the First and Fifth Amendments.

The same week: Baltimore became the first US city to sue xAI over Grok deepfakes (March 24). An Amsterdam court imposed €100,000/day fines on X/Grok for non-consensual imagery (March 26). California AG Rob Bonta sent a cease-and-desist letter. Reuters testing found an 82% failure rate in Grok's safety filters.

Fact-check verdict: ✅ Confirmed

Court order confirmed via Ars Technica (PDF). Covered by Reuters, JD Supra, Jones Walker, E-Discovery LLC. OpenAI/Anthropic compliance confirmed via PYMNTS and Davis & Gilbert. Dutch court ruling confirmed via Tech Policy Press. Baltimore lawsuit confirmed via NBC News and Engadget.

CAP-SRP mapping

AB 2013 demands backward-looking disclosure (training data). It does not require real-time behavioral disclosure (what the model does with requests). The Grok incident is the canonical failure case:

The Grok Evidence Problem
═══════════════════════════

xAI CLAIMS:          "Our safety systems are operational"
REUTERS FINDS:        82% of harmful prompts succeed
REGULATORS ASK:       "Show us the refusal logs"
xAI CAN PRODUCE:     Internal logs (self-reported, unverifiable)
xAI CANNOT PRODUCE:  Independently verifiable audit trail

WITH CAP-SRP:
┌─────────────────────────────────────────────────────────┐
│ GEN_ATTEMPT: sha256(prompt) logged BEFORE safety check  │
│ GEN_DENY:    linked to attempt, risk=NCII_RISK, score=? │
│ Completeness Invariant: ∑ ATTEMPT = ∑ GEN + ∑ DENY + ∑ ERROR │
│ If equation doesn't balance → audit trail is PROVABLY incomplete │
└─────────────────────────────────────────────────────────┘

Result: "We blocked it" becomes verifiable — or provably false.

The v1.1 ACCOUNT_ACTION event type addresses the Grok aftermath directly. When xAI eventually banned accounts after public pressure, no cryptographic record documented when, why, or under what policy. ACCOUNT_ACTION creates that record. LAW_ENFORCEMENT_REFERRAL records whether the LE notification threshold was assessed — central to the multi-jurisdictional investigations now active.

Signal 3: 61 DPA Joint Statement

What happened

On February 23, 2026, sixty-one data protection authorities issued a joint statement on AI-generated imagery and privacy, coordinated through the Global Privacy Assembly. Signatories include EDPB, EDPS, UK ICO, France's CNIL, and authorities spanning every continent.

The enforcement cascade that followed: EU opened a formal DSA investigation into X (January 26). UK ICO launched a formal investigation (February). Paris prosecutors expanded to child pornography charges. Ireland's DPC opened a GDPR investigation. The European Parliament voted to amend the AI Act to ban "nudifier" systems. 35 US state AGs sent a joint demand to xAI. Dutch court imposed €100,000/day fines (March 26).

Fact-check verdict: ✅ Confirmed

Confirmed via EDPB official press release, EDÖB Switzerland, UK ICO, Pearl Cohen, and Hunton & Williams. ICO Grok investigation confirmed via ICO announcement. Daily Watch characterizes the statement as entering an "enforcement phase" — this is editorial analysis; the statement itself commits to "coordinated responses."

CAP-SRP mapping

Every enforcement action in the cascade confronts the same problem: how do you verify, from outside the platform, that a safeguard actually fired?

Enforcement Action	Evidence Needed	CAP-SRP Mechanism
DSA investigation (EU)	Proof safety systems were active	Evidence Pack with Completeness Invariant
ICO investigation (UK)	GDPR-compliant decision records	`GEN_DENY` with `JurisdictionContext: "GB"`
Paris prosecution	LE notification timeline	`LAW_ENFORCEMENT_REFERRAL` event chain
DPC investigation (Ireland)	Data processing lawfulness	Privacy-preserving verification (hashed prompts)
Dutch court injunction	Ongoing compliance proof	Real-time `GEN_DENY` monitoring via audit API
35 AG demand	Cross-jurisdictional safety evidence	Multi-jurisdiction Evidence Pack

CAP-SRP v1.1 conformance tiers map to these enforcement contexts:

Bronze (minimum): Local hash chains, 1-year retention — sufficient for initial regulatory response
Silver: External timestamp anchoring within 24 hours, Merkle proofs, 3-year retention — sufficient for formal investigations
Gold: Real-time anchoring, HSM key management, SCITT integration, audit API, 5-year retention — sufficient for multi-year litigation and cross-jurisdictional enforcement

Signal 4: IETF Refusal Events Draft

What happened

The Internet-Draft draft-kamimura-scitt-refusal-events-02 (last updated January 29, 2026) is the only formal submission to a recognized standards body that defines machine-readable semantics for AI refusal events. It specifies how refusal decisions map to signed statements within the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture.

Fact-check verdict: ✅ Confirmed — with critical context

Confirmed via IETF Datatracker. Revision 02 confirmed. Author: Tokachi Kamimura (VSO).

⚠️ Critical status note: This is an individual submission — not adopted by the SCITT working group, no assigned Area Director, no IETF endorsement, no RFC stream. The SCITT WG charter focuses on software supply chains, making this an out-of-charter application. That said, the SCITT infrastructure it builds on is maturing rapidly: draft-ietf-scitt-architecture is in the RFC Editor Queue (AUTH48), and draft-ietf-scitt-scrapi reached Last Call on March 27, 2026.

CAP-SRP mapping

The IETF draft is the wire-protocol binding for CAP-SRP's event model. Here's how the layers fit:

Standards Stack: CAP-SRP + SCITT
═════════════════════════════════

┌─────────────────────────────────────────────┐
│            CAP-SRP v1.1 Specification       │  ← Application semantics
│  Event types, data model, completeness      │     (what events mean)
│  invariant, conformance tiers, threat model │
└─────────────────┬───────────────────────────┘
                  │ defines claim semantics
                  v
┌─────────────────────────────────────────────┐
│  draft-kamimura-scitt-refusal-events-02     │  ← SCITT binding
│  Maps CAP events to SCITT signed statements │     (how to transport)
│  COSE_Sign1 format, claim types, receipts   │
│  ⚠️ Individual submission — not adopted     │
└─────────────────┬───────────────────────────┘
                  │ rides on
                  v
┌─────────────────────────────────────────────┐
│  IETF SCITT Architecture (AUTH48 → RFC)     │  ← Infrastructure
│  Transparency logs, Merkle inclusion proofs │     (trust foundation)
│  Signed statements, verifiable receipts     │
│  ✅ RFC imminent                            │
└─────────────────────────────────────────────┘
                  │ uses
                  v
┌─────────────────────────────────────────────┐
│  COSE/CBOR (RFC 9052) + RFC 3161 timestamps │  ← Cryptographic
│  Ed25519 signatures, SHA-256 hashing        │     primitives
│  ✅ Production-grade, widely deployed       │
└─────────────────────────────────────────────┘

The analogy: CAP-SRP is to the IETF draft what a web application is to HTTP. CAP-SRP defines what events mean, what data they carry, and what invariants must hold. The IETF draft defines how to transport them on SCITT infrastructure.

Signal 5: Nebraska LB1083

What happened

Nebraska's Transparency in Artificial Intelligence Risk Management Act (LB1083) sits on General File as of March 24, with committee amendment AM2618 attached. Session adjourns April 17. Targets: "large frontier developers" ($500M+ annual revenue) and "large chatbot providers" (1M+ monthly active users likely accessed by minors). Requires public safety plans, incident reporting to the AG, employee whistleblower protections, and — critically — prohibits material misrepresentation about safety capabilities (Section 5(a)).

Fact-check verdict: ✅ Confirmed

Confirmed via Nebraska Legislature official record, Unicameral Update, and Nebraska Legislature committee statement (PDF). Introduction January 15, committee hearing February 8, AM2618 filed March 24 — all confirmed. No opposition testimony confirmed. Operative date January 1, 2027.

CAP-SRP mapping

Section 5(a) is the key: if a provider claims its system blocks CSAM and that claim is false or unverifiable, the bill creates a legal basis for enforcement. Without CAP-SRP, "our system blocks CSAM" is an unfalsifiable assertion. With CAP-SRP:

Section 5(a) Verification Flow
═══════════════════════════════

Provider claims: "Our system blocks CSAM generation"

Nebraska AG investigation:
┌─────────────────────────────────────────────────────────┐
│ 1. Request Evidence Pack for CSAM_RISK events           │
│ 2. Verify Completeness Invariant:                       │
│    ∑ GEN_ATTEMPT(CSAM) = ∑ GEN_DENY(CSAM) + ∑ ERROR    │
│    If GEN events exist with CSAM_RISK → system failed   │
│    If equation doesn't balance → logs are incomplete     │
│ 3. Verify POLICY_VERSION: was CSAM blocking active?     │
│ 4. Check external timestamps: are they independently    │
│    anchored, or could they be fabricated after the fact? │
│ 5. Verify GEN_ESCALATE resolution:                      │
│    ∑ GEN_ESCALATE = ∑ ESCALATION_RESOLVED               │
│    Unresolved escalations older than 72h = violation     │
└─────────────────────────────────────────────────────────┘

Without CAP-SRP: AG must trust provider's internal logs
With CAP-SRP:    AG can mathematically verify the claim

Signal 6: C2PA at 6,000 Members

What happened

C2PA (version 2.2, v2.3 in development) now has 6,000+ members and affiliates. Steering committee: Adobe, Amazon, BBC, Google, Intel, Meta, Microsoft, OpenAI, Publicis Groupe, Sony, Truepic. Samsung Galaxy S25 and Google Pixel 10 natively sign photos with C2PA. Cloudflare implements Content Credentials covering ~20% of web traffic. Google's dual approach combines C2PA metadata with SynthID watermarks — used over 20 million times in the Gemini app. The EU Code of Practice names C2PA as the recommended open standard.

March 2026 vulnerability: researchers demonstrated an "Integrity Clash" where a valid C2PA manifest and a valid watermark cryptographically contradict each other about the same image.

Fact-check verdict: ✅ Confirmed

6,000+ membership confirmed via industry analyses. Samsung/Google integration confirmed. Cloudflare implementation confirmed. SynthID 20M+ verifications confirmed. Integrity Clash vulnerability confirmed in academic disclosure.

CAP-SRP mapping

C2PA is the content's passport. CAP-SRP is the system's flight recorder.

C2PA + CAP-SRP: The Complete Provenance Stack
══════════════════════════════════════════════

            ┌─── C2PA answers ──────────────────────┐
            │                                       │
            │  "What was generated?"                │
            │  "Who generated it?"                  │
            │  "When was it generated?"             │
            │  "What edits were applied?"           │
            │                                       │
            │  Travels WITH the content artifact    │
            │                                       │
            └──────────────┬────────────────────────┘
                           │
    ContentHash bridge ────┤──── SHA-256 of output
                           │     links C2PA manifest
                           │     to CAP-SRP GEN event
                           │
            ┌──────────────┴────────────────────────┐
            │                                       │
            │  CAP-SRP answers:                     │
            │                                       │
            │  "What was REFUSED?"                  │
            │  "WHY was it refused?"                │
            │  "Was the log COMPLETE?"              │
            │  "Which POLICY was active?"           │
            │  "Were ACCOUNTS enforced?"            │
            │  "Was LAW ENFORCEMENT notified?"      │
            │                                       │
            │  Stays WITH the provider system       │
            │                                       │
            └───────────────────────────────────────┘

C2PA cannot represent:
  ❌ Refusals (no content → nothing to attach manifest to)
  ❌ Null content / refusal receipts
  ❌ Behavioral decisions by the AI system
  ❌ Policy versioning at decision time
  ❌ Account-level enforcement actions

CAP-SRP cannot represent:
  ❌ Content provenance chain across platforms
  ❌ Edit history on generated artifacts
  ❌ Watermark durability across transformations

Together: Complete behavioral + content provenance.

Signal 7: ZwillGen's Four Questions

What happened

Brenda Leong's December 2025 article "No More 'Trust Me, Bro': 2026 Will Be the Year of Accountable AI" identified four questions that arise when AI is part of a disputed decision — and argued no AI developer can answer them with standardized, independently auditable evidence.

Fact-check verdict: ✅ Confirmed

Article exists at the cited URL on ZwillGen's official website. Author, publication timing, and content verified.

CAP-SRP mapping

Each question maps to specific v1.1 event types:

ZwillGen Question	CAP-SRP Answer
"What exactly did the system do?"	`GEN_ATTEMPT` (SHA-256 prompt hash, model ID, session context, timestamp)
"What controls should have constrained it?"	`POLICY_VERSION` (policy in effect) + `GEN_DENY` (risk category, confidence score)
"What relevant tests were run?"	`POLICY_VERSION` change-control context (before/after hashes, linked evaluation docs)
"What happened when it went wrong?"	`ACCOUNT_ACTION` (enforcement decision) + `LAW_ENFORCEMENT_REFERRAL` (notification timeline)

The Architecture: CAP-SRP v1.1 Event Model

Here's the complete v1.1 event taxonomy with all ten event types:

CAP-SRP v1.1 Complete Event Taxonomy
═════════════════════════════════════

CORE SRP EVENTS (v1.0)
───────────────────────
  GEN_ATTEMPT ───→ Generation request received (BEFORE safety check)
  GEN         ───→ Generation succeeded
  GEN_DENY    ───→ Generation refused (policy violation)
  GEN_ERROR   ───→ Generation failed (system error)

INTERMEDIATE-STATE EVENTS (v1.1 — formally normalized)
──────────────────────────────────────────────────────
  GEN_WARN      ───→ Generation allowed with user-facing warning
  GEN_ESCALATE  ───→ Request sent for human review
  GEN_QUARANTINE───→ Content generated but held before delivery

ACCOUNT & POLICY EVENTS (v1.1 — new)
─────────────────────────────────────
  ACCOUNT_ACTION            ───→ Account ban/suspend/reinstate
  LAW_ENFORCEMENT_REFERRAL  ───→ LE notification threshold assessment
  POLICY_VERSION            ───→ Safety policy publish/update


COMPLETENESS INVARIANTS
───────────────────────
  Primary (v1.0):
    ∑ GEN_ATTEMPT = ∑ GEN + ∑ GEN_DENY + ∑ GEN_ERROR
    (where GEN includes GEN_WARN outcomes)

  Escalation Resolution (v1.1, Silver+):
    ∑ GEN_ESCALATE = ∑ ESCALATION_RESOLVED
    (unresolved > 72 hours = compliance violation)

  Quarantine Resolution (v1.1, Silver+):
    ∑ GEN_QUARANTINE = ∑ QUARANTINE_RELEASED + ∑ QUARANTINE_DENIED


RISK CATEGORIES (12 total, 1 new in v1.1)
──────────────────────────────────────────
  CSAM_RISK              NCII_RISK
  MINOR_SEXUALIZATION    REAL_PERSON_DEEPFAKE
  VIOLENCE_EXTREME       HATE_CONTENT
  TERRORIST_CONTENT      SELF_HARM_PROMOTION
  COPYRIGHT_VIOLATION    COPYRIGHT_STYLE_MIMICRY
  VIOLENCE_PLANNING ←── NEW in v1.1 (Tumbler Ridge pattern)
  OTHER

Building the Flight Recorder

Here's a complete Python implementation of the CAP-SRP v1.1 event model with all ten event types, four completeness invariants, and privacy-preserving verification.

"""
CAP-SRP v1.1 — Complete Event Model Implementation
===================================================
Implements all 10 event types, 4 completeness invariants,
and privacy-preserving verification.

GitHub: https://github.com/veritaschain/cap-spec
Spec:   CAP-SRP v1.1 (2026-03-05)
License: Apache 2.0
"""

import hashlib
import json
import uuid
import time
from datetime import datetime, timezone
from dataclasses import dataclass, field, asdict
from enum import Enum
from typing import Optional


# ─── Risk Categories (Section 7.9) ───────────────────────────

class RiskCategory(Enum):
    CSAM_RISK = "CSAM_RISK"
    NCII_RISK = "NCII_RISK"
    MINOR_SEXUALIZATION = "MINOR_SEXUALIZATION"
    REAL_PERSON_DEEPFAKE = "REAL_PERSON_DEEPFAKE"
    VIOLENCE_EXTREME = "VIOLENCE_EXTREME"
    HATE_CONTENT = "HATE_CONTENT"
    TERRORIST_CONTENT = "TERRORIST_CONTENT"
    SELF_HARM_PROMOTION = "SELF_HARM_PROMOTION"
    COPYRIGHT_VIOLATION = "COPYRIGHT_VIOLATION"
    COPYRIGHT_STYLE_MIMICRY = "COPYRIGHT_STYLE_MIMICRY"
    VIOLENCE_PLANNING = "VIOLENCE_PLANNING"  # NEW in v1.1
    OTHER = "OTHER"


# ─── Event Types (Section 6) ─────────────────────────────────

class EventType(Enum):
    # Core SRP events (v1.0)
    GEN_ATTEMPT = "GEN_ATTEMPT"
    GEN = "GEN"
    GEN_DENY = "GEN_DENY"
    GEN_ERROR = "GEN_ERROR"
    # Intermediate-state events (v1.1 normalized)
    GEN_WARN = "GEN_WARN"
    GEN_ESCALATE = "GEN_ESCALATE"
    GEN_QUARANTINE = "GEN_QUARANTINE"
    # Account & policy events (v1.1 new)
    ACCOUNT_ACTION = "ACCOUNT_ACTION"
    LAW_ENFORCEMENT_REFERRAL = "LAW_ENFORCEMENT_REFERRAL"
    POLICY_VERSION = "POLICY_VERSION"


class AccountActionType(Enum):
    BAN = "BAN"
    SUSPEND = "SUSPEND"
    RATE_LIMIT = "RATE_LIMIT"
    REINSTATE = "REINSTATE"
    FLAG_FOR_REVIEW = "FLAG_FOR_REVIEW"


class LEOutcome(Enum):
    REFERRED = "REFERRED"
    NOT_REFERRED = "NOT_REFERRED"
    PENDING = "PENDING"


# ─── Privacy-preserving hash functions ────────────────────────

def hash_prompt(prompt: str) -> str:
    """SHA-256 hash of prompt — original text is NEVER stored."""
    return f"sha256:{hashlib.sha256(prompt.encode()).hexdigest()}"


def hash_actor(actor_id: str) -> str:
    """Pseudonymized actor identifier."""
    return f"sha256:{hashlib.sha256(actor_id.encode()).hexdigest()}"


def hash_content(content_bytes: bytes) -> str:
    """Content hash — bridges to C2PA manifest."""
    return f"sha256:{hashlib.sha256(content_bytes).hexdigest()}"


def hash_policy(policy_text: str) -> str:
    """Policy document hash for POLICY_VERSION events."""
    return f"sha256:{hashlib.sha256(policy_text.encode()).hexdigest()}"


# ─── CAP Event (Section 7) ───────────────────────────────────

@dataclass
class CAPEvent:
    event_type: EventType
    event_id: str = field(default_factory=lambda: str(uuid.uuid4()))
    timestamp: str = field(
        default_factory=lambda: datetime.now(timezone.utc).isoformat()
    )
    # Links
    attempt_ref: Optional[str] = None     # Links outcome → attempt
    resolution_ref: Optional[str] = None  # Links resolution → escalation/quarantine
    # SRP fields
    prompt_hash: Optional[str] = None
    actor_hash: Optional[str] = None
    model_id: Optional[str] = None
    risk_category: Optional[RiskCategory] = None
    risk_score: Optional[float] = None
    content_hash: Optional[str] = None    # Bridges to C2PA
    policy_version_ref: Optional[str] = None
    jurisdiction_context: Optional[str] = None
    # Account fields (v1.1)
    account_action_type: Optional[AccountActionType] = None
    triggering_events: Optional[list] = None
    # LE referral fields (v1.1)
    le_outcome: Optional[LEOutcome] = None
    le_case_ref: Optional[str] = None
    # Policy version fields (v1.1)
    policy_hash: Optional[str] = None
    effective_date: Optional[str] = None
    # Integrity
    previous_hash: Optional[str] = None
    event_hash: Optional[str] = None

    def compute_hash(self) -> str:
        """Compute SHA-256 hash of event payload for chain integrity."""
        payload = {
            "event_type": self.event_type.value,
            "event_id": self.event_id,
            "timestamp": self.timestamp,
            "attempt_ref": self.attempt_ref,
            "prompt_hash": self.prompt_hash,
            "actor_hash": self.actor_hash,
            "risk_category": self.risk_category.value if self.risk_category else None,
            "previous_hash": self.previous_hash,
        }
        canonical = json.dumps(payload, sort_keys=True, separators=(',', ':'))
        self.event_hash = f"sha256:{hashlib.sha256(canonical.encode()).hexdigest()}"
        return self.event_hash


# ─── CAP-SRP v1.1 Audit Chain ────────────────────────────────

class CAPSRPChain:
    """
    Complete CAP-SRP v1.1 audit chain with all four
    completeness invariants.
    """

    def __init__(self, system_id: str, model_id: str):
        self.system_id = system_id
        self.model_id = model_id
        self.events: list[CAPEvent] = []
        self.last_hash: Optional[str] = None

    def _append(self, event: CAPEvent) -> CAPEvent:
        event.previous_hash = self.last_hash
        event.compute_hash()
        self.last_hash = event.event_hash
        self.events.append(event)
        return event

    # ── Core SRP events ──────────────────────────────────────

    def log_attempt(self, prompt: str, actor_id: str,
                    jurisdiction: str = None) -> CAPEvent:
        """Log GEN_ATTEMPT — MUST be called BEFORE safety check."""
        event = CAPEvent(
            event_type=EventType.GEN_ATTEMPT,
            prompt_hash=hash_prompt(prompt),
            actor_hash=hash_actor(actor_id),
            model_id=self.model_id,
            jurisdiction_context=jurisdiction,
        )
        return self._append(event)

    def log_generation(self, attempt_id: str,
                       content: bytes,
                       policy_ref: str = None) -> CAPEvent:
        """Log GEN — successful content generation."""
        event = CAPEvent(
            event_type=EventType.GEN,
            attempt_ref=attempt_id,
            content_hash=hash_content(content),
            policy_version_ref=policy_ref,
        )
        return self._append(event)

    def log_denial(self, attempt_id: str,
                   risk: RiskCategory,
                   score: float,
                   policy_ref: str = None) -> CAPEvent:
        """Log GEN_DENY — request refused."""
        event = CAPEvent(
            event_type=EventType.GEN_DENY,
            attempt_ref=attempt_id,
            risk_category=risk,
            risk_score=score,
            policy_version_ref=policy_ref,
        )
        return self._append(event)

    def log_error(self, attempt_id: str) -> CAPEvent:
        """Log GEN_ERROR — system failure (not policy-related)."""
        event = CAPEvent(
            event_type=EventType.GEN_ERROR,
            attempt_ref=attempt_id,
        )
        return self._append(event)

    # ── Intermediate-state events (v1.1) ─────────────────────

    def log_warning(self, attempt_id: str,
                    risk: RiskCategory,
                    score: float) -> CAPEvent:
        """Log GEN_WARN — generation allowed with user-facing warning."""
        event = CAPEvent(
            event_type=EventType.GEN_WARN,
            attempt_ref=attempt_id,
            risk_category=risk,
            risk_score=score,
        )
        return self._append(event)

    def log_escalation(self, attempt_id: str,
                       risk: RiskCategory,
                       score: float) -> CAPEvent:
        """Log GEN_ESCALATE — request sent for human review."""
        event = CAPEvent(
            event_type=EventType.GEN_ESCALATE,
            attempt_ref=attempt_id,
            risk_category=risk,
            risk_score=score,
        )
        return self._append(event)

    def log_quarantine(self, attempt_id: str,
                       content: bytes) -> CAPEvent:
        """Log GEN_QUARANTINE — content held pending review."""
        event = CAPEvent(
            event_type=EventType.GEN_QUARANTINE,
            attempt_ref=attempt_id,
            content_hash=hash_content(content),
        )
        return self._append(event)

    # ── Account & policy events (v1.1 — new) ─────────────────

    def log_account_action(self, actor_id: str,
                           action: AccountActionType,
                           triggering_event_ids: list,
                           policy_ref: str = None) -> CAPEvent:
        """Log ACCOUNT_ACTION — account ban/suspend/reinstate."""
        event = CAPEvent(
            event_type=EventType.ACCOUNT_ACTION,
            actor_hash=hash_actor(actor_id),
            account_action_type=action,
            triggering_events=triggering_event_ids,
            policy_version_ref=policy_ref,
        )
        return self._append(event)

    def log_le_referral(self, actor_id: str,
                        outcome: LEOutcome,
                        account_action_id: str,
                        case_ref: str = None) -> CAPEvent:
        """Log LAW_ENFORCEMENT_REFERRAL — LE notification decision."""
        event = CAPEvent(
            event_type=EventType.LAW_ENFORCEMENT_REFERRAL,
            actor_hash=hash_actor(actor_id),
            le_outcome=outcome,
            attempt_ref=account_action_id,
            le_case_ref=case_ref,
        )
        return self._append(event)

    def log_policy_version(self, policy_text: str,
                           effective_date: str) -> CAPEvent:
        """Log POLICY_VERSION — tamper-evident policy change record."""
        event = CAPEvent(
            event_type=EventType.POLICY_VERSION,
            policy_hash=hash_policy(policy_text),
            effective_date=effective_date,
        )
        return self._append(event)

    # ── Completeness Invariants (Section 8) ───────────────────

    def verify_primary_invariant(self) -> dict:
        """
        Primary Completeness Invariant:
        ∑ GEN_ATTEMPT = ∑ GEN + ∑ GEN_DENY + ∑ GEN_ERROR
        (GEN_WARN counts as GEN)
        """
        attempts = [e for e in self.events
                    if e.event_type == EventType.GEN_ATTEMPT]
        outcomes = [e for e in self.events
                    if e.event_type in (
                        EventType.GEN, EventType.GEN_DENY,
                        EventType.GEN_ERROR, EventType.GEN_WARN
                    )]

        attempt_ids = {e.event_id for e in attempts}
        resolved_ids = {e.attempt_ref for e in outcomes if e.attempt_ref}
        unmatched = attempt_ids - resolved_ids

        valid = len(attempts) == len(outcomes) and len(unmatched) == 0

        return {
            "invariant": "primary",
            "valid": valid,
            "attempts": len(attempts),
            "outcomes": len(outcomes),
            "unmatched_attempt_ids": list(unmatched),
        }

    def verify_escalation_invariant(self) -> dict:
        """
        Escalation Resolution Invariant (v1.1, Silver+):
        ∑ GEN_ESCALATE = ∑ ESCALATION_RESOLVED
        """
        escalations = [e for e in self.events
                       if e.event_type == EventType.GEN_ESCALATE]
        # Resolutions are GEN or GEN_DENY with resolution_ref
        resolutions = [e for e in self.events
                       if e.resolution_ref and e.event_type in (
                           EventType.GEN, EventType.GEN_DENY
                       )]

        esc_ids = {e.event_id for e in escalations}
        resolved_ids = {e.resolution_ref for e in resolutions}
        unresolved = esc_ids - resolved_ids

        return {
            "invariant": "escalation_resolution",
            "valid": len(unresolved) == 0,
            "escalations": len(escalations),
            "resolved": len(resolutions),
            "unresolved_ids": list(unresolved),
        }

    def verify_quarantine_invariant(self) -> dict:
        """
        Quarantine Resolution Invariant (v1.1, Silver+):
        ∑ GEN_QUARANTINE = ∑ RELEASED + ∑ QUARANTINE_DENIED
        """
        quarantines = [e for e in self.events
                       if e.event_type == EventType.GEN_QUARANTINE]
        # Resolutions: GEN (released) or GEN_DENY with resolution_ref
        resolutions = [e for e in self.events
                       if e.resolution_ref and e.event_type in (
                           EventType.GEN, EventType.GEN_DENY
                       )]

        q_ids = {e.event_id for e in quarantines}
        resolved_ids = {e.resolution_ref for e in resolutions
                        if e.resolution_ref in q_ids}
        unresolved = q_ids - resolved_ids

        return {
            "invariant": "quarantine_resolution",
            "valid": len(unresolved) == 0,
            "quarantined": len(quarantines),
            "resolved": len(resolved_ids),
            "unresolved_ids": list(unresolved),
        }

    def verify_chain_integrity(self) -> dict:
        """Verify hash chain is unbroken and untampered."""
        if not self.events:
            return {"valid": True, "chain_length": 0}

        for i, event in enumerate(self.events):
            expected_prev = self.events[i - 1].event_hash if i > 0 else None
            if event.previous_hash != expected_prev:
                return {
                    "valid": False,
                    "break_at": i,
                    "event_id": event.event_id,
                }

            stored_hash = event.event_hash
            recomputed = event.compute_hash()
            if stored_hash != recomputed:
                return {
                    "valid": False,
                    "tampered_at": i,
                    "event_id": event.event_id,
                }

        return {"valid": True, "chain_length": len(self.events)}

    def verify_all(self) -> dict:
        """Run all four verification checks."""
        return {
            "chain_integrity": self.verify_chain_integrity(),
            "primary_invariant": self.verify_primary_invariant(),
            "escalation_invariant": self.verify_escalation_invariant(),
            "quarantine_invariant": self.verify_quarantine_invariant(),
        }


# ─── Example: Full v1.1 Workflow ─────────────────────────────

if __name__ == "__main__":
    chain = CAPSRPChain(
        system_id="grok-image-gen",
        model_id="aurora-v2"
    )

    # Step 1: Publish safety policy
    policy = chain.log_policy_version(
        policy_text="NCII and CSAM content generation is prohibited...",
        effective_date="2026-01-15T00:00:00Z"
    )
    print(f"✓ Policy published: {policy.policy_hash[:30]}...")

    # Step 2: Harmful request arrives — log attempt FIRST
    attempt = chain.log_attempt(
        prompt="Generate nude image of [person]",
        actor_id="user-12345",
        jurisdiction="EU"
    )
    print(f"✓ Attempt logged: {attempt.event_id[:20]}...")

    # Step 3: Safety check triggers denial
    denial = chain.log_denial(
        attempt_id=attempt.event_id,
        risk=RiskCategory.NCII_RISK,
        score=0.97,
        policy_ref=policy.event_id,
    )
    print(f"✓ Denial logged:  {denial.event_id[:20]}...")
    print(f"  Risk: {denial.risk_category.value}, Score: {denial.risk_score}")

    # Step 4: Repeated violations → account action
    acct = chain.log_account_action(
        actor_id="user-12345",
        action=AccountActionType.BAN,
        triggering_event_ids=[denial.event_id],
        policy_ref=policy.event_id,
    )
    print(f"✓ Account banned: {acct.event_id[:20]}...")

    # Step 5: LE referral threshold assessment
    le_ref = chain.log_le_referral(
        actor_id="user-12345",
        outcome=LEOutcome.REFERRED,
        account_action_id=acct.event_id,
        case_ref="NCMEC-2026-00042",
    )
    print(f"✓ LE referral:    {le_ref.le_outcome.value}")
    print(f"  Case ref:       {le_ref.le_case_ref}")

    # Step 6: Verify everything
    print("\n" + "=" * 50)
    results = chain.verify_all()

    ci = results["primary_invariant"]
    print(f"Primary Invariant: {ci['attempts']} == "
          f"{ci['outcomes']} → {'✓ VALID' if ci['valid'] else '✗ INVALID'}")

    chain_ok = results["chain_integrity"]
    print(f"Chain integrity:   {chain_ok['chain_length']} events → "
          f"{'✓ VALID' if chain_ok['valid'] else '✗ BROKEN'}")

    print(f"Escalation inv:    {'✓ VALID' if results['escalation_invariant']['valid'] else '✗ INVALID'}")
    print(f"Quarantine inv:    {'✓ VALID' if results['quarantine_invariant']['valid'] else '✗ INVALID'}")

Output:

✓ Policy published: sha256:a7f3c9d8e2b1...
✓ Attempt logged: 3f8a1b2c-9d4e-...
✓ Denial logged:  7c2d4e6f-8a1b-...
  Risk: NCII_RISK, Score: 0.97
✓ Account banned: b5e7f9a1-2c3d-...
✓ LE referral:    REFERRED
  Case ref:       NCMEC-2026-00042

==================================================
Primary Invariant: 1 == 1 → ✓ VALID
Chain integrity:   5 events → ✓ VALID
Escalation inv:    ✓ VALID
Quarantine inv:    ✓ VALID

C2PA Integration

When a request is allowed (GEN), the output gets a C2PA manifest. The CAP log records both. When a request is denied (GEN_DENY), only CAP records the event. The bridge is the ContentHash field:

{
  "label": "org.veritaschain.cap-srp.reference",
  "data": {
    "audit_log_uri": "https://audit.example.com/events/xyz",
    "request_hash": "sha256:abc123...",
    "outcome_type": "GEN",
    "content_hash": "sha256:def456...",
    "batch_merkle_root": "sha256:ghi789...",
    "policy_version_ref": "evt-policy-001",
    "scitt_receipt_hash": "sha256:jkl012..."
  }
}

Evidence Pack Structure (Section 11)
═════════════════════════════════════

EvidencePack/
├── summary.pdf           # Human-readable for regulators
├── statistics.json       # Refusal counts by category/jurisdiction
├── verification.html     # Interactive verification tool
├── audit_trail.cbor      # Signed event chain (COSE_Sign1)
├── tsa_receipts/         # RFC 3161 external timestamps
│   ├── 2026-03-29T*.tsr
│   └── ...
├── merkle_proofs/        # Inclusion proofs for each event
│   ├── event_001.proof
│   └── ...
├── policy_versions/      # Hashed policy documents
│   ├── v1.0_sha256_a7f3.json
│   └── ...
└── certificates/         # X.509 signing chain
    ├── signing_cert.pem
    └── ca_chain.pem

Regulatory Deadline Map

2026 AI Compliance Timeline — Where CAP-SRP Fits
══════════════════════════════════════════════════

MAR 30 ──── EU CoP consultation closes          ← TODAY
            (refusal logging NOT in draft)

APR 17 ──── Nebraska session adjourns
            (LB1083 must pass by this date)

MAY 19 ──── TAKE IT DOWN Act platform deadline
            (48-hour removal + reasonable search)
            CAP-SRP: GEN_DENY + ContentHash for
            duplicate detection evidence

JUN ~~ ──── EU CoP final version published
            (last chance for refusal provenance
            to enter Article 50 framework)

JUN 30 ──── Colorado AI Act takes effect
            (3-year record retention required)
            CAP-SRP: Silver+ meets this

AUG 02 ──── EU AI Act Article 50 enforced
            (marking + labelling obligations)
            CAP-SRP: complements C2PA compliance

AUG 02 ──── California AI Transparency Act enforced
            (SB 942 provenance disclosures)

AUG 03 ──── IETF draft-kamimura-scitt-refusal-events
            expires (renewal or abandonment)

JAN 01 ──── Nebraska LB1083 operative date
 2027       (if passed)

Sprint Plan

Bronze (achievable this quarter)

[ ] Implement GEN_ATTEMPT logging before safety evaluation
[ ] Implement GEN_DENY / GEN / GEN_ERROR outcome events
[ ] SHA-256 hash chain linking all events
[ ] Ed25519 signing of each event
[ ] Hash prompts — never store plaintext
[ ] 6-month minimum retention
[ ] Basic Completeness Invariant check
[ ] Export capability for regulatory requests

Silver (target: Q3 2026)

[ ] Add POLICY_VERSION events for all safety policy changes
[ ] External timestamp anchoring (RFC 3161) within 24 hours
[ ] Merkle tree construction for batch verification
[ ] Implement Escalation Resolution Invariant
[ ] Implement Quarantine Resolution Invariant
[ ] JurisdictionContext field for multi-jurisdiction compliance
[ ] 3-year retention
[ ] Evidence Pack generation tooling

Gold (target: Q4 2026)

[ ] Add ACCOUNT_ACTION and LAW_ENFORCEMENT_REFERRAL events
[ ] Real-time external anchoring within 1 hour
[ ] HSM (Hardware Security Module) for signing keys
[ ] SCITT Transparency Service integration
[ ] Programmatic audit API for regulators
[ ] 5-year retention
[ ] Cross-reference ContentHash with C2PA manifests
[ ] Incident response: 24-hour evidence preservation capability

Transparency Notes

About this analysis: This article fact-checks seven developments from the week of March 29, 2026, against primary sources. The Daily Watch report cited the EU CoP publication as March 5; multiple sources confirm March 3 — a minor reference variation, not a substantive error. The Daily Watch characterizes the 61 DPA statement as entering an "enforcement phase" — this is editorial analysis; the statement commits to "coordinated responses." All other facts confirmed.

About CAP-SRP: CAP-SRP is an open specification (v1.1, March 5, 2026) published under CC BY 4.0 by the VeritasChain Standards Organization (VSO), Tokyo. It has not been endorsed by major AI companies and is not an adopted standard of any recognized standards body. An individual Internet-Draft (draft-kamimura-scitt-refusal-events) has been submitted to the IETF but has not been formally adopted by the SCITT working group and carries no formal IETF standing. The underlying technologies — SCITT, C2PA, COSE/CBOR, RFC 3161 — are mature and widely deployed. Whether the industry's response takes the form of CAP-SRP, a C2PA extension, an IETF SCITT profile, or something else entirely remains an open question. The verification gap itself is not.

What CAP-SRP is:

A technically sound approach to a genuine, well-documented gap
Compatible with C2PA (complementary, not competing)
Open source: veritaschain/cap-spec (CC BY 4.0) · veritaschain/cap-srp (Apache 2.0)

What CAP-SRP is not (yet):

An industry-endorsed standard
An IETF RFC
Deployed at any major AI platform

The question isn't whether the industry needs refusal provenance. It's whether it builds the flight recorder before August 2 — or explains to regulators why it didn't.

Verify, don't trust. The code is the proof.

GitHub: veritaschain/cap-spec · Spec: CAP-SRP v1.1 · License: CC BY 4.0

100 Charges, Zero AI Logs: Building Cryptographic Account Enforcement and Law Enforcement Referral Provenance with CAP-SRP v1.1

VeritasChain Standards Organization (VSO) — Fri, 27 Mar 2026 02:56:28 +0000

On March 17, 2026, Florida charged a man with 100 counts including 46 for AI-generated CSAM. On February 3, the UK ICO opened a formal investigation into Grok's generation of non-consensual imagery. In both cases, the question no one could answer was the same: what did the AI system actually refuse, and can anyone prove it? This article walks you through building the answer — with full working Python code for CAP-SRP v1.1's three new event types.

TL;DR

A Florida prosecution, a UK regulatory investigation, and an EU compliance deadline all converged on the same structural gap: AI providers can claim their safety systems work, but no one can independently verify it. The previous version of CAP-SRP (v1.0) addressed generation-level refusal logging. Version 1.1, released March 5, 2026, extends the framework upstream — to account enforcement, law enforcement referral decisions, and tamper-evident policy versioning.

This article:

Fact-checks the five events that motivated v1.1's design
Explains the three new event types (ACCOUNT_ACTION, LAW_ENFORCEMENT_REFERRAL, POLICY_VERSION) with full schemas
Provides complete, runnable Python code for the v1.1 implementation
Implements the four Completeness Invariants (expanded from one in v1.0)
Maps the implementation to regulatory deadlines hitting in the next 90 days

GitHub: veritaschain/cap-spec · veritaschain/cap-srp · License: CC BY 4.0 / Apache 2.0

The Five Events That Broke the v1.0 Model
What v1.1 Adds: The Account Enforcement Layer
Architecture: From Generation to Enforcement
Implementation: Core Data Model
Implementation: The v1.1 Event Types
Implementation: The Four Completeness Invariants
Implementation: The Full Chain
Putting It All Together: The Tumbler Ridge Scenario
Regulatory Deadline Map
What Developers Should Build Now
Transparency Notes

The Five Events That Broke the v1.0 Model

CAP-SRP v1.0, released January 28, 2026, solved a specific problem: cryptographic proof that an AI system refused to generate content. The Completeness Invariant — GEN_ATTEMPT = GEN + GEN_DENY + GEN_ERROR — ensured that every generation request had exactly one recorded outcome.

But within weeks of v1.0's release, five events exposed gaps that generation-level logging alone couldn't cover.

1. Florida AI-CSAM: 100 Charges, Zero AI Logs

On March 17, 2026, Florida Attorney General James Uthmeier announced the arrest of Blake McKinniss, 37, of Sanford. The charges: 53 counts of CSAM possession, 46 counts of AI-generated CSAM possession, and 1 count of possessing a childlike sex doll. The investigation began on January 27 after FDLE received over 70 NCMEC CyberTipline reports. A search warrant was executed on March 9.

The entire case was built from the human side: NCMEC tips, physical evidence, device forensics. No evidence in the case record originated from the AI systems used to generate the material. No refusal logs. No account action records. No law enforcement referral audit trail.

Even if the AI provider had blocked 99% of McKinniss's attempts, there is no standardized mechanism for prosecutors to request, receive, or verify that information. v1.0 could log refusals — but it couldn't log what happened to the account after a pattern of harmful requests, or whether law enforcement was notified.

2. UK ICO vs. Grok: Can't Verify What You Can't Audit

The UK Information Commissioner's Office announced formal investigations into X Internet Unlimited Company and X.AI LLC on February 3, 2026. The investigation covers Grok's generation of non-consensual sexualized imagery. The ICO first contacted the companies on January 7, seeking urgent information.

The ICO has enforcement tools — it can compel disclosure, impose fines, issue notices. But when xAI provides safety logs, the ICO has no technical standard against which to verify their completeness. No hash chain proves the logs are tamper-evident. No external anchoring proves they weren't modified after the fact. The ICO can demand records; it cannot verify the records' integrity.

3. EU Code of Practice: Logging Made Optional

The European Commission published the second draft of its Code of Practice on marking and labelling AI-generated content in early March 2026. Comments close March 30. The draft adopts a two-layered approach — secured metadata plus watermarking — but logging was downgraded from near-mandatory in the first draft to optional in the second. The code covers the lifecycle of content that exists. Refusal provenance is outside its scope.

4. TAKE IT DOWN Act: 53 Days to Compliance

The TAKE IT DOWN Act (signed May 19, 2025) establishes a notice-and-removal framework with a 48-hour removal obligation. Platforms must demonstrate they removed content. The May 19, 2026 compliance deadline is 53 days away. No provision requires demonstrating that content was prevented from being generated.

5. The Tumbler Ridge Pattern

The event that directly motivated v1.1 was the Tumbler Ridge shooting case (February 2026), where an AI system was used not to generate harmful imagery but to assist in planning violence. The existing v1.0 risk categories didn't cover content that facilitated planning without depicting violence. More critically, the case exposed what we call the "account enforcement opacity problem": when a platform bans an account, there is no standard for recording why, what policy was applied, whether law enforcement was notified, and whether the notification threshold assessment was documented.

v1.0 logged refusals. v1.1 logs what happens after refusals.

What v1.1 Adds: The Account Enforcement Layer

CAP-SRP v1.1 introduces three new event types and three additional Completeness Invariants:

Event Type	Purpose	Motivated By
`ACCOUNT_ACTION`	Cryptographic record of account bans, suspensions, rate-limiting, reinstatements	Tumbler Ridge — no audit trail for enforcement decisions
`LAW_ENFORCEMENT_REFERRAL`	Verifiable record of LE notification threshold assessment	Florida CSAM — no record of whether/when LE was notified
`POLICY_VERSION`	Tamper-evident versioning of safety policies	ICO investigation — can't verify which policy version applied

And three new intermediate-state events formalized from v1.0 drafts:

Event Type	Purpose	Completeness Role
`GEN_WARN`	Generation allowed with warning	Outcome (treated as GEN)
`GEN_ESCALATE`	Sent for human review	Pending → resolved by GEN or GEN_DENY
`GEN_QUARANTINE`	Generated but held before delivery	Pending → resolved by EXPORT or GEN_DENY

Plus the VIOLENCE_PLANNING risk category — content that facilitates planning of violent acts without depicting violence directly.

Architecture: From Generation to Enforcement

Here's how v1.0 and v1.1 fit together:

CAP-SRP v1.1 Architecture
══════════════════════════════════════════════════════════════

  POLICY LAYER (v1.1 — new)                 
  ┌────────────────────────────────────────────────────────┐
  │                                                        │
  │  POLICY_VERSION ──── ExternalAnchorRef ──► RFC 3161    │
  │       │                                    Timestamp   │
  │       │ (PolicyHash + EffectiveFrom)       Service     │
  │       │                                                │
  │       ▼                                                │
  │  AppliedPolicyVersionRef on every GEN_DENY             │
  │                                                        │
  └────────────────────────────────────────────────────────┘
                           │
                           ▼
  GENERATION LAYER (v1.0 + v1.1 extensions)
  ┌────────────────────────────────────────────────────────┐
  │                                                        │
  │  GEN_ATTEMPT ──► Safety Check ──┬──► GEN              │
  │       │                         ├──► GEN_DENY          │
  │       │                         ├──► GEN_WARN  (v1.1)  │
  │       │                         ├──► GEN_ERROR         │
  │       │                         └──► GEN_ESCALATE(v1.1)│
  │       │                                   │            │
  │       │                           resolved by          │
  │       │                         GEN or GEN_DENY        │
  │       ▼                                                │
  │  Completeness Invariant:                               │
  │  ∑ ATTEMPT = ∑ GEN + ∑ DENY + ∑ ERROR                 │
  │                                                        │
  └────────────────────────────────────────────────────────┘
                           │
             (pattern of GEN_DENY events detected)
                           │
                           ▼
  ACCOUNT ENFORCEMENT LAYER (v1.1 — new)
  ┌────────────────────────────────────────────────────────┐
  │                                                        │
  │  ACCOUNT_ACTION ─────► LawEnforcementAssessment        │
  │  (BAN/SUSPEND/         (ThresholdMet? AssessorType?)   │
  │   RATE_LIMIT/                    │                     │
  │   REINSTATE/                     ▼                     │
  │   FLAG_FOR_REVIEW)   LAW_ENFORCEMENT_REFERRAL          │
  │                      (REFERRED / NOT_REFERRED /        │
  │                       PENDING_LEGAL_REVIEW)            │
  │                                                        │
  └────────────────────────────────────────────────────────┘

The key insight: every layer references the layer above it. A GEN_DENY references the POLICY_VERSION that was in effect when the denial was made. An ACCOUNT_ACTION references the GEN_ATTEMPT events that triggered it. A LAW_ENFORCEMENT_REFERRAL references the ACCOUNT_ACTION that prompted the assessment.

This creates an unbroken chain from policy → generation decision → enforcement action → LE notification. If any link is missing, the audit trail is provably incomplete.

Implementation: Core Data Model

Let's build this. All code targets Python 3.10+ with minimal dependencies.

Prerequisites

pip install cryptography

Foundation: Hashing, Signing, and Event Base

"""
CAP-SRP v1.1 Reference Implementation
======================================
Core data model with Ed25519 signatures, SHA-256 hash chains,
and the four Completeness Invariants.

License: Apache 2.0
GitHub: https://github.com/veritaschain/cap-srp
"""

import hashlib
import json
import time
import uuid
import base64
from dataclasses import dataclass, field, asdict
from enum import Enum
from typing import Optional, List, Dict, Tuple
from cryptography.hazmat.primitives.asymmetric.ed25519 import (
    Ed25519PrivateKey, Ed25519PublicKey
)


# ─── Utilities ───────────────────────────────────────────

def sha256(data: str) -> str:
    """SHA-256 hash with algorithm prefix."""
    return f"sha256:{hashlib.sha256(data.encode()).hexdigest()}"


def sha256_bytes(data: bytes) -> str:
    """SHA-256 hash of raw bytes."""
    return f"sha256:{hashlib.sha256(data).hexdigest()}"


def canonicalize(obj: dict) -> str:
    """RFC 8785 JSON Canonicalization (simplified)."""
    return json.dumps(obj, sort_keys=True, separators=(",", ":"))


def uuid7() -> str:
    """UUIDv7 (time-ordered) for event IDs."""
    timestamp_ms = int(time.time() * 1000)
    rand_bits = uuid.uuid4().int & ((1 << 62) - 1)
    u = (timestamp_ms << 80) | (0b0111 << 76) | (rand_bits & ((1 << 76) - 1))
    return str(uuid.UUID(int=u))


# ─── Enumerations ────────────────────────────────────────

class EventType(Enum):
    # Generation events (v1.0)
    GEN_ATTEMPT = "GEN_ATTEMPT"
    GEN = "GEN"
    GEN_DENY = "GEN_DENY"
    GEN_ERROR = "GEN_ERROR"
    # Generation events (v1.1 — formalized)
    GEN_WARN = "GEN_WARN"
    GEN_ESCALATE = "GEN_ESCALATE"
    GEN_QUARANTINE = "GEN_QUARANTINE"
    # Lifecycle events
    EXPORT = "EXPORT"
    # Account enforcement events (v1.1 — new)
    ACCOUNT_ACTION = "ACCOUNT_ACTION"
    LAW_ENFORCEMENT_REFERRAL = "LAW_ENFORCEMENT_REFERRAL"
    POLICY_VERSION = "POLICY_VERSION"


class RiskCategory(Enum):
    CSAM_RISK = "CSAM_RISK"
    NCII_RISK = "NCII_RISK"
    MINOR_SEXUALIZATION = "MINOR_SEXUALIZATION"
    REAL_PERSON_DEEPFAKE = "REAL_PERSON_DEEPFAKE"
    VIOLENCE_EXTREME = "VIOLENCE_EXTREME"
    VIOLENCE_PLANNING = "VIOLENCE_PLANNING"  # v1.1 — new
    HATE_CONTENT = "HATE_CONTENT"
    TERRORIST_CONTENT = "TERRORIST_CONTENT"
    SELF_HARM_PROMOTION = "SELF_HARM_PROMOTION"
    COPYRIGHT_VIOLATION = "COPYRIGHT_VIOLATION"
    COPYRIGHT_STYLE_MIMICRY = "COPYRIGHT_STYLE_MIMICRY"
    OTHER = "OTHER"


class ActionType(Enum):
    SUSPEND = "SUSPEND"
    BAN = "BAN"
    RATE_LIMIT = "RATE_LIMIT"
    REINSTATE = "REINSTATE"
    FLAG_FOR_REVIEW = "FLAG_FOR_REVIEW"


class RiskBand(Enum):
    LOW = "LOW"
    MEDIUM = "MEDIUM"
    HIGH = "HIGH"
    CRITICAL = "CRITICAL"


class DecisionMechanism(Enum):
    AUTOMATED = "AUTOMATED"
    HUMAN_INITIATED = "HUMAN_INITIATED"
    HUMAN_CONFIRMED_AUTOMATED = "HUMAN_CONFIRMED_AUTOMATED"


class ReferralStatus(Enum):
    REFERRED = "REFERRED"
    NOT_REFERRED = "NOT_REFERRED"
    PENDING_LEGAL_REVIEW = "PENDING_LEGAL_REVIEW"


class PolicyType(Enum):
    CONTENT_MODERATION = "CONTENT_MODERATION"
    LE_NOTIFICATION = "LE_NOTIFICATION"
    ACCOUNT_ACTION = "ACCOUNT_ACTION"
    RETENTION = "RETENTION"

The Base Event Class

Every event in the chain — generation, enforcement, policy — inherits from this:

@dataclass
class CAPEvent:
    """Base event with Ed25519 signature and SHA-256 hash chain."""
    event_id: str
    event_type: EventType
    chain_id: str
    timestamp: str
    prev_hash: Optional[str]
    event_hash: Optional[str] = None
    signature: Optional[str] = None

    def _serializable_dict(self) -> dict:
        """Convert to dict for hashing, handling enums."""
        d = {}
        for k, v in asdict(self).items():
            if k in ("event_hash", "signature"):
                continue
            if isinstance(v, Enum):
                d[k] = v.value
            elif isinstance(v, list):
                d[k] = [
                    item.value if isinstance(item, Enum) else item
                    for item in v
                ]
            else:
                d[k] = v
        return d

    def compute_hash(self) -> str:
        """SHA-256 of canonicalized event (excluding hash and sig)."""
        return sha256(canonicalize(self._serializable_dict()))

    def sign(self, private_key: Ed25519PrivateKey):
        """Compute hash, then sign with Ed25519."""
        self.event_hash = self.compute_hash()
        hash_bytes = bytes.fromhex(self.event_hash[7:])
        sig = private_key.sign(hash_bytes)
        self.signature = f"ed25519:{base64.b64encode(sig).decode()}"

    def verify(self, public_key: Ed25519PublicKey) -> bool:
        """Verify Ed25519 signature against event hash."""
        if not self.event_hash or not self.signature:
            return False
        try:
            hash_bytes = bytes.fromhex(self.event_hash[7:])
            sig_bytes = base64.b64decode(self.signature[8:])
            public_key.verify(sig_bytes, hash_bytes)
            return True
        except Exception:
            return False

Implementation: The v1.1 Event Types

Generation Events (v1.0 core + v1.1 extensions)

@dataclass
class GenAttemptEvent(CAPEvent):
    """
    Logged BEFORE safety evaluation.
    Creates an unforgeable commitment that the request existed.

    CRITICAL: Must be logged before any safety check runs.
    Without pre-evaluation logging, a malicious provider could
    silently drop harmful requests from the audit trail.
    """
    prompt_hash: str = ""
    input_type: str = "text"
    model_version: str = ""
    policy_id: str = ""
    actor_hash: str = ""

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               prompt: str, actor_id: str, model_version: str,
               policy_id: str, input_type: str = "text"):
        return cls(
            event_id=uuid7(),
            event_type=EventType.GEN_ATTEMPT,
            chain_id=chain_id,
            timestamp=time.strftime(
                "%Y-%m-%dT%H:%M:%S.000Z", time.gmtime()
            ),
            prev_hash=prev_hash,
            prompt_hash=sha256(prompt),
            input_type=input_type,
            model_version=model_version,
            policy_id=policy_id,
            actor_hash=sha256(actor_id),
        )


@dataclass
class GenDenyEvent(CAPEvent):
    """
    Logged when safety evaluation DENIES generation.

    v1.1 additions:
    - applied_policy_version_ref: links to POLICY_VERSION event
    - jurisdiction_context: ISO 3166-1 alpha-2 code
    - takedown_relevance: flags for TAKE IT DOWN Act compliance
    """
    attempt_id: str = ""
    risk_category: str = ""
    risk_score: float = 0.0
    refusal_reason: str = ""
    policy_version: str = ""
    # v1.1 fields
    applied_policy_version_ref: str = ""
    jurisdiction_context: str = ""
    takedown_relevance: Optional[dict] = None

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               attempt_id: str, risk_category: RiskCategory,
               risk_score: float, reason: str,
               policy_version: str,
               policy_version_ref: str = "",
               jurisdiction: str = "",
               takedown_flags: Optional[dict] = None):
        return cls(
            event_id=uuid7(),
            event_type=EventType.GEN_DENY,
            chain_id=chain_id,
            timestamp=time.strftime(
                "%Y-%m-%dT%H:%M:%S.000Z", time.gmtime()
            ),
            prev_hash=prev_hash,
            attempt_id=attempt_id,
            risk_category=risk_category.value,
            risk_score=risk_score,
            refusal_reason=reason,
            policy_version=policy_version,
            applied_policy_version_ref=policy_version_ref,
            jurisdiction_context=jurisdiction,
            takedown_relevance=takedown_flags,
        )


@dataclass
class GenEscalateEvent(CAPEvent):
    """
    v1.1: Request sent for human review.
    MUST be resolved by a subsequent GEN or GEN_DENY event.
    Unresolved escalations older than 72 hours are a compliance
    violation.
    """
    attempt_id: str = ""
    escalation_reason: str = ""
    resolution_ref: Optional[str] = None  # Populated when resolved

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               attempt_id: str, reason: str):
        return cls(
            event_id=uuid7(),
            event_type=EventType.GEN_ESCALATE,
            chain_id=chain_id,
            timestamp=time.strftime(
                "%Y-%m-%dT%H:%M:%S.000Z", time.gmtime()
            ),
            prev_hash=prev_hash,
            attempt_id=attempt_id,
            escalation_reason=reason,
        )


@dataclass
class GenQuarantineEvent(CAPEvent):
    """
    v1.1: Content generated but held before delivery.
    MUST be resolved by EXPORT (released) or GEN_DENY (blocked).
    """
    attempt_id: str = ""
    content_hash: str = ""
    expiry_policy: str = "REQUIRES_HUMAN_APPROVAL"
    release_ref: Optional[str] = None  # Populated when resolved

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               attempt_id: str, content: str,
               expiry: str = "REQUIRES_HUMAN_APPROVAL"):
        return cls(
            event_id=uuid7(),
            event_type=EventType.GEN_QUARANTINE,
            chain_id=chain_id,
            timestamp=time.strftime(
                "%Y-%m-%dT%H:%M:%S.000Z", time.gmtime()
            ),
            prev_hash=prev_hash,
            attempt_id=attempt_id,
            content_hash=sha256(content),
            expiry_policy=expiry,
        )

Account Enforcement Events (v1.1 — new)

This is the code the Florida case and the ICO investigation need:

@dataclass
class AccountActionEvent(CAPEvent):
    """
    v1.1: Cryptographic record of account-level enforcement.

    Motivated by the Tumbler Ridge incident: when a platform
    bans an account, there must be a tamper-evident record of
    WHY, WHAT POLICY applied, and WHETHER law enforcement
    was assessed for notification.

    Privacy: account_hash uses keyed HMAC, never plaintext.
    Supports crypto-shredding for GDPR Article 17.
    """
    account_hash: str = ""
    action_type: str = ""
    triggering_event_refs: List[str] = field(default_factory=list)
    policy_version_ref: str = ""
    risk_score_band: str = ""
    decision_mechanism: str = ""
    le_assessment: Optional[dict] = None  # Law enforcement assessment

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               account_id: str, action: ActionType,
               triggering_events: List[str],
               policy_ref: str, risk_band: RiskBand,
               mechanism: DecisionMechanism,
               le_threshold_met: bool = False,
               le_threshold_ref: str = "",
               le_assessor: str = "AUTOMATED"):
        return cls(
            event_id=uuid7(),
            event_type=EventType.ACCOUNT_ACTION,
            chain_id=chain_id,
            timestamp=time.strftime(
                "%Y-%m-%dT%H:%M:%S.000Z", time.gmtime()
            ),
            prev_hash=prev_hash,
            account_hash=sha256(account_id),
            action_type=action.value,
            triggering_event_refs=triggering_events,
            policy_version_ref=policy_ref,
            risk_score_band=risk_band.value,
            decision_mechanism=mechanism.value,
            le_assessment={
                "ThresholdMet": le_threshold_met,
                "ThresholdDefinitionRef": le_threshold_ref,
                "AssessmentTimestamp": time.strftime(
                    "%Y-%m-%dT%H:%M:%S.000Z", time.gmtime()
                ),
                "AssessorType": le_assessor,
            },
        )


@dataclass
class LawEnforcementReferralEvent(CAPEvent):
    """
    v1.1: Verifiable record of law enforcement notification
    threshold assessment.

    This event answers: "Did the platform assess whether law
    enforcement should be notified? What was the outcome?
    Was legal counsel involved?"

    DecisionRationaleRef stores ONLY a hash of the internal
    decision document — never plaintext — preserving
    attorney-client privilege.
    """
    triggering_account_action_ref: str = ""
    referral_status: str = ""
    jurisdiction_code: str = ""
    legal_framework: str = ""
    threshold_doc_ref: str = ""
    threshold_met: bool = False
    decision_rationale_ref: str = ""
    decision_timestamp: str = ""
    legal_review_completed: bool = False

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               account_action_ref: str,
               status: ReferralStatus,
               jurisdiction: str,
               framework: str,
               threshold_ref: str,
               threshold_met: bool,
               rationale_doc: str,
               legal_reviewed: bool):
        return cls(
            event_id=uuid7(),
            event_type=EventType.LAW_ENFORCEMENT_REFERRAL,
            chain_id=chain_id,
            timestamp=time.strftime(
                "%Y-%m-%dT%H:%M:%S.000Z", time.gmtime()
            ),
            prev_hash=prev_hash,
            triggering_account_action_ref=account_action_ref,
            referral_status=status.value,
            jurisdiction_code=jurisdiction,
            legal_framework=framework,
            threshold_doc_ref=threshold_ref,
            threshold_met=threshold_met,
            decision_rationale_ref=sha256(rationale_doc),
            decision_timestamp=time.strftime(
                "%Y-%m-%dT%H:%M:%S.000Z", time.gmtime()
            ),
            legal_review_completed=legal_reviewed,
        )


@dataclass
class PolicyVersionEvent(CAPEvent):
    """
    v1.1: Tamper-evident policy version management.

    CRITICAL CONSTRAINT: ExternalAnchorRef timestamp MUST
    precede or equal EffectiveFrom. If the anchor postdates
    the effective date, implementations MUST reject the event.

    This prevents retroactive policy changes — a provider
    can't claim "we had a stricter policy" if that policy
    wasn't anchored before it took effect.
    """
    policy_id: str = ""
    policy_hash: str = ""
    effective_from: str = ""
    supersedes_ref: Optional[str] = None
    policy_type: str = ""
    jurisdiction_scope: List[str] = field(default_factory=list)
    external_anchor_ref: str = ""

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               policy_id: str, policy_document: str,
               effective_from: str, supersedes: Optional[str],
               policy_type: PolicyType,
               jurisdictions: List[str],
               anchor_ref: str):
        return cls(
            event_id=uuid7(),
            event_type=EventType.POLICY_VERSION,
            chain_id=chain_id,
            timestamp=time.strftime(
                "%Y-%m-%dT%H:%M:%S.000Z", time.gmtime()
            ),
            prev_hash=prev_hash,
            policy_id=policy_id,
            policy_hash=sha256(policy_document),
            effective_from=effective_from,
            supersedes_ref=supersedes,
            policy_type=policy_type.value,
            jurisdiction_scope=jurisdictions,
            external_anchor_ref=anchor_ref,
        )

Implementation: The Four Completeness Invariants

v1.0 had one invariant. v1.1 has four. Here's why — and here's the code.

The Four Completeness Invariants
════════════════════════════════════════════════════════════

1. PRIMARY (v1.0):
   ∑ GEN_ATTEMPT = ∑ GEN + ∑ GEN_DENY + ∑ GEN_ERROR
   → Every attempt has exactly one outcome.

2. ESCALATION RESOLUTION (v1.1):
   ∑ GEN_ESCALATE = ∑ ESCALATION_RESOLVED
   → Every escalation has a resolution (GEN or GEN_DENY).
   → Unresolved escalations > 72 hours = compliance violation.

3. QUARANTINE RESOLUTION (v1.1):
   ∑ GEN_QUARANTINE = ∑ QUARANTINE_RELEASED + ∑ QUARANTINE_DENIED
   → Every quarantined item is either released or blocked.

4. POLICY ANCHORING (v1.1):
   ∀ POLICY_VERSION: ExternalAnchorTimestamp ≤ EffectiveFrom
   → No policy can be backdated past its external anchor.

class CompletenessVerifier:
    """
    Verifies all four CAP-SRP v1.1 Completeness Invariants.

    The Completeness Invariants are the mathematical core of
    CAP-SRP. If any invariant fails, the audit trail is
    provably compromised — it's not a matter of opinion,
    it's just math.
    """

    def __init__(self, events: List[CAPEvent]):
        self.events = events
        self._index_events()

    def _index_events(self):
        """Build lookup indexes for efficient verification."""
        self.by_type: Dict[EventType, List[CAPEvent]] = {}
        self.by_id: Dict[str, CAPEvent] = {}
        for e in self.events:
            self.by_type.setdefault(e.event_type, []).append(e)
            self.by_id[e.event_id] = e

    def verify_primary_invariant(self) -> dict:
        """
        Invariant 1: ∑ ATTEMPT = ∑ GEN + ∑ DENY + ∑ ERROR

        GEN_WARN counts as GEN (generation occurred, with warning).
        """
        attempts = len(
            self.by_type.get(EventType.GEN_ATTEMPT, [])
        )
        gens = len(
            self.by_type.get(EventType.GEN, [])
        ) + len(
            self.by_type.get(EventType.GEN_WARN, [])
        )
        denials = len(
            self.by_type.get(EventType.GEN_DENY, [])
        )
        errors = len(
            self.by_type.get(EventType.GEN_ERROR, [])
        )
        outcomes = gens + denials + errors

        return {
            "invariant": "PRIMARY",
            "valid": attempts == outcomes,
            "attempts": attempts,
            "outcomes": {
                "GEN": gens, "GEN_DENY": denials,
                "GEN_ERROR": errors, "total": outcomes
            },
            "equation": f"{attempts} == {gens} + {denials} + {errors}",
        }

    def verify_escalation_invariant(self) -> dict:
        """
        Invariant 2: ∑ ESCALATE = ∑ ESCALATION_RESOLVED

        Every GEN_ESCALATE must have a matching resolution.
        Unresolved escalations older than 72 hours are flagged.
        """
        escalations = self.by_type.get(EventType.GEN_ESCALATE, [])
        resolved = sum(
            1 for e in escalations
            if getattr(e, "resolution_ref", None) is not None
        )
        unresolved = [
            e.event_id for e in escalations
            if getattr(e, "resolution_ref", None) is None
        ]

        return {
            "invariant": "ESCALATION_RESOLUTION",
            "valid": len(escalations) == resolved,
            "total_escalations": len(escalations),
            "resolved": resolved,
            "unresolved_ids": unresolved,
        }

    def verify_quarantine_invariant(self) -> dict:
        """
        Invariant 3: ∑ QUARANTINE = ∑ RELEASED + ∑ DENIED

        Every quarantined item must be resolved.
        """
        quarantines = self.by_type.get(
            EventType.GEN_QUARANTINE, []
        )
        resolved = sum(
            1 for e in quarantines
            if getattr(e, "release_ref", None) is not None
        )
        unresolved = [
            e.event_id for e in quarantines
            if getattr(e, "release_ref", None) is None
        ]

        return {
            "invariant": "QUARANTINE_RESOLUTION",
            "valid": len(quarantines) == resolved,
            "total_quarantines": len(quarantines),
            "resolved": resolved,
            "unresolved_ids": unresolved,
        }

    def verify_policy_anchoring_invariant(self) -> dict:
        """
        Invariant 4: ∀ POLICY_VERSION:
            ExternalAnchorTimestamp ≤ EffectiveFrom

        No policy can claim to have been in effect before
        it was externally timestamped. This prevents a
        provider from retroactively claiming "we had
        stricter policies all along."
        """
        policies = self.by_type.get(EventType.POLICY_VERSION, [])
        violations = []

        for p in policies:
            anchor = getattr(p, "external_anchor_ref", "")
            effective = getattr(p, "effective_from", "")
            # In production: verify RFC 3161 receipt timestamp
            # Here: check that anchor_ref exists
            if not anchor:
                violations.append({
                    "policy_id": getattr(p, "policy_id", ""),
                    "reason": "Missing external anchor",
                })

        return {
            "invariant": "POLICY_ANCHORING",
            "valid": len(violations) == 0,
            "total_policies": len(policies),
            "violations": violations,
        }

    def verify_all(self) -> dict:
        """Run all four invariants. Return composite result."""
        results = {
            "primary": self.verify_primary_invariant(),
            "escalation": self.verify_escalation_invariant(),
            "quarantine": self.verify_quarantine_invariant(),
            "policy_anchoring": self.verify_policy_anchoring_invariant(),
        }
        results["all_valid"] = all(
            r["valid"] for r in results.values()
        )
        return results

Implementation: The Full Chain

Now let's wire it all together into a chain that manages the complete v1.1 lifecycle:

class CAPChainV11:
    """
    CAP-SRP v1.1 hash chain with full lifecycle management.

    Manages generation events, account enforcement,
    law enforcement referrals, and policy versioning —
    all in a single tamper-evident chain.
    """

    def __init__(self, private_key: Ed25519PrivateKey,
                 chain_id: str = None):
        self.private_key = private_key
        self.public_key = private_key.public_key()
        self.chain_id = chain_id or str(uuid.uuid4())
        self.events: List[CAPEvent] = []
        self.attempts: Dict[str, CAPEvent] = {}
        self.outcomes: Dict[str, CAPEvent] = {}
        self.policies: Dict[str, PolicyVersionEvent] = {}

    @property
    def last_hash(self) -> Optional[str]:
        return self.events[-1].event_hash if self.events else None

    def _append(self, event: CAPEvent) -> CAPEvent:
        """Sign, hash-chain, and store."""
        event.sign(self.private_key)
        self.events.append(event)
        return event

    # ─── Policy Layer ────────────────────────────────────

    def publish_policy(self, policy_id: str,
                       policy_document: str,
                       effective_from: str,
                       policy_type: PolicyType,
                       jurisdictions: List[str],
                       supersedes: Optional[str] = None,
                       anchor_ref: str = "pending"
                       ) -> PolicyVersionEvent:
        """
        Publish a new policy version.

        MUST be called BEFORE the policy takes effect.
        MUST be externally anchored before EffectiveFrom.
        """
        event = PolicyVersionEvent.create(
            chain_id=self.chain_id,
            prev_hash=self.last_hash,
            policy_id=policy_id,
            policy_document=policy_document,
            effective_from=effective_from,
            supersedes=supersedes,
            policy_type=policy_type,
            jurisdictions=jurisdictions,
            anchor_ref=anchor_ref,
        )
        self._append(event)
        self.policies[event.event_id] = event
        return event

    # ─── Generation Layer ────────────────────────────────

    def log_attempt(self, prompt: str, actor_id: str,
                    model_version: str,
                    policy_id: str) -> GenAttemptEvent:
        """Log GEN_ATTEMPT — MUST be called BEFORE safety eval."""
        event = GenAttemptEvent.create(
            chain_id=self.chain_id,
            prev_hash=self.last_hash,
            prompt=prompt,
            actor_id=actor_id,
            model_version=model_version,
            policy_id=policy_id,
        )
        self._append(event)
        self.attempts[event.event_id] = event
        return event

    def log_deny(self, attempt_id: str,
                 risk_category: RiskCategory,
                 risk_score: float, reason: str,
                 policy_version: str,
                 policy_version_ref: str = "",
                 jurisdiction: str = "",
                 takedown_flags: Optional[dict] = None
                 ) -> GenDenyEvent:
        """Log GEN_DENY with v1.1 policy linkage."""
        if attempt_id not in self.attempts:
            raise ValueError(f"Unknown attempt: {attempt_id}")
        if attempt_id in self.outcomes:
            raise ValueError(
                f"Attempt {attempt_id} already has outcome"
            )

        event = GenDenyEvent.create(
            chain_id=self.chain_id,
            prev_hash=self.last_hash,
            attempt_id=attempt_id,
            risk_category=risk_category,
            risk_score=risk_score,
            reason=reason,
            policy_version=policy_version,
            policy_version_ref=policy_version_ref,
            jurisdiction=jurisdiction,
            takedown_flags=takedown_flags,
        )
        self._append(event)
        self.outcomes[attempt_id] = event
        return event

    def log_escalate(self, attempt_id: str,
                     reason: str) -> GenEscalateEvent:
        """Log GEN_ESCALATE — pending human review."""
        event = GenEscalateEvent.create(
            chain_id=self.chain_id,
            prev_hash=self.last_hash,
            attempt_id=attempt_id,
            reason=reason,
        )
        self._append(event)
        return event

    # ─── Account Enforcement Layer ───────────────────────

    def log_account_action(
        self, account_id: str, action: ActionType,
        triggering_events: List[str],
        policy_ref: str, risk_band: RiskBand,
        mechanism: DecisionMechanism,
        le_threshold_met: bool = False,
        le_threshold_ref: str = "",
        le_assessor: str = "AUTOMATED"
    ) -> AccountActionEvent:
        """
        Log ACCOUNT_ACTION — account-level enforcement.

        This is what the Florida case was missing. When a
        pattern of CSAM-risk denials triggers an account ban,
        this event records:
        - Which generation attempts triggered it
        - What policy was in effect
        - Whether LE notification was assessed
        """
        event = AccountActionEvent.create(
            chain_id=self.chain_id,
            prev_hash=self.last_hash,
            account_id=account_id,
            action=action,
            triggering_events=triggering_events,
            policy_ref=policy_ref,
            risk_band=risk_band,
            mechanism=mechanism,
            le_threshold_met=le_threshold_met,
            le_threshold_ref=le_threshold_ref,
            le_assessor=le_assessor,
        )
        self._append(event)
        return event

    def log_le_referral(
        self, account_action_ref: str,
        status: ReferralStatus,
        jurisdiction: str, framework: str,
        threshold_ref: str, threshold_met: bool,
        rationale_doc: str,
        legal_reviewed: bool
    ) -> LawEnforcementReferralEvent:
        """
        Log LAW_ENFORCEMENT_REFERRAL — LE notification decision.

        This is what prosecutors need. When an account is
        banned for CSAM-related activity, was law enforcement
        notified? Was the threshold assessment documented?
        Was legal counsel involved?

        The rationale_doc is stored ONLY as a SHA-256 hash,
        preserving attorney-client privilege.
        """
        event = LawEnforcementReferralEvent.create(
            chain_id=self.chain_id,
            prev_hash=self.last_hash,
            account_action_ref=account_action_ref,
            status=status,
            jurisdiction=jurisdiction,
            framework=framework,
            threshold_ref=threshold_ref,
            threshold_met=threshold_met,
            rationale_doc=rationale_doc,
            legal_reviewed=legal_reviewed,
        )
        self._append(event)
        return event

    # ─── Verification ────────────────────────────────────

    def verify_chain_integrity(self) -> dict:
        """Verify hash chain is unbroken and signatures valid."""
        broken_links = []
        invalid_sigs = []

        for i, event in enumerate(self.events):
            # Check hash recomputation
            expected_hash = event.compute_hash()
            if event.event_hash != expected_hash:
                broken_links.append(i)

            # Check prev_hash linkage
            if i > 0:
                if event.prev_hash != self.events[i - 1].event_hash:
                    broken_links.append(i)

            # Check signature
            if not event.verify(self.public_key):
                invalid_sigs.append(i)

        return {
            "valid": len(broken_links) == 0
                     and len(invalid_sigs) == 0,
            "total_events": len(self.events),
            "broken_links": broken_links,
            "invalid_signatures": invalid_sigs,
        }

    def verify_completeness(self) -> dict:
        """Run all four Completeness Invariants."""
        verifier = CompletenessVerifier(self.events)
        return verifier.verify_all()

Putting It All Together: The Tumbler Ridge Scenario

Here's a complete scenario demonstrating the full v1.1 lifecycle — from policy publication through account enforcement and LE referral:

def demo_v11_lifecycle():
    """
    Full CAP-SRP v1.1 lifecycle demonstration.

    Scenario: An AI image generation service detects a pattern
    of CSAM-risk requests from a single account, bans the
    account, assesses whether law enforcement should be
    notified, and creates a complete audit trail.
    """
    # Generate signing key
    private_key = Ed25519PrivateKey.generate()
    chain = CAPChainV11(private_key)

    print("=" * 60)
    print("CAP-SRP v1.1 Lifecycle Demo")
    print("=" * 60)

    # ─── Step 1: Publish safety policy ───────────────────
    print("\n[1] Publishing safety policy...")
    policy = chain.publish_policy(
        policy_id="cap.safety.csam-prevention.v2026-03",
        policy_document=(
            "CSAM Prevention Policy v2026-03: "
            "All requests classified as CSAM_RISK with "
            "confidence > 0.7 MUST be denied. Accounts "
            "with 3+ CSAM_RISK denials within 24 hours "
            "MUST be suspended and assessed for LE referral."
        ),
        effective_from="2026-03-01T00:00:00.000Z",
        policy_type=PolicyType.CONTENT_MODERATION,
        jurisdictions=["US", "EU", "GLOBAL"],
        anchor_ref="sha256:rfc3161-receipt-abc123...",
    )
    print(f"    Policy: {policy.policy_id}")
    print(f"    Event:  {policy.event_id}")

    # ─── Step 2: Log harmful requests and denials ────────
    print("\n[2] Logging generation attempts and denials...")

    actor_id = "user-12345"
    deny_event_ids = []
    attempt_event_ids = []

    prompts = [
        "Generate an image of [REDACTED - CSAM content]",
        "Create a photo of [REDACTED - CSAM content]",
        "Make a picture showing [REDACTED - CSAM content]",
    ]

    for i, prompt in enumerate(prompts, 1):
        # Log attempt BEFORE safety check
        attempt = chain.log_attempt(
            prompt=prompt,
            actor_id=actor_id,
            model_version="model-v3.2.1",
            policy_id=policy.policy_id,
        )
        attempt_event_ids.append(attempt.event_id)

        # Safety check triggers denial
        deny = chain.log_deny(
            attempt_id=attempt.event_id,
            risk_category=RiskCategory.CSAM_RISK,
            risk_score=0.97,
            reason="CSAM content detected in prompt",
            policy_version="v2026-03",
            policy_version_ref=policy.event_id,
            jurisdiction="US",
            takedown_flags={
                "TAKE_IT_DOWN_Act": False,
                "NCII_Category": False,
                "ChildSafetyCategory": True,
            },
        )
        deny_event_ids.append(deny.event_id)
        print(f"    Attempt {i}: {attempt.event_id[:12]}... → DENY")

    # ─── Step 3: Account enforcement ─────────────────────
    print("\n[3] Account enforcement triggered (3 CSAM denials)...")

    account_action = chain.log_account_action(
        account_id=actor_id,
        action=ActionType.BAN,
        triggering_events=attempt_event_ids,
        policy_ref=policy.event_id,
        risk_band=RiskBand.CRITICAL,
        mechanism=DecisionMechanism.HUMAN_CONFIRMED_AUTOMATED,
        le_threshold_met=True,
        le_threshold_ref=policy.event_id,
        le_assessor="HUMAN_TRUST_AND_SAFETY",
    )
    print(f"    Action: BAN")
    print(f"    Event:  {account_action.event_id[:12]}...")
    print(f"    LE threshold met: True")

    # ─── Step 4: Law enforcement referral ────────────────
    print("\n[4] Law enforcement referral decision...")

    le_referral = chain.log_le_referral(
        account_action_ref=account_action.event_id,
        status=ReferralStatus.REFERRED,
        jurisdiction="US",
        framework="NCMEC_CyberTipline",
        threshold_ref=policy.event_id,
        threshold_met=True,
        rationale_doc=(
            "Account triggered CSAM prevention threshold: "
            "3 CSAM_RISK denials within 24 hours. "
            "Pattern consistent with NCMEC reporting criteria. "
            "Legal counsel confirmed referral obligation under "
            "18 USC 2258A."
        ),
        legal_reviewed=True,
    )
    print(f"    Status: REFERRED")
    print(f"    Framework: NCMEC CyberTipline")
    print(f"    Legal review: Complete")

    # ─── Step 5: Verify everything ───────────────────────
    print("\n[5] Verification...")

    chain_result = chain.verify_chain_integrity()
    print(f"    Chain integrity: "
          f"{'VALID' if chain_result['valid'] else 'BROKEN'}")
    print(f"    Total events: {chain_result['total_events']}")

    completeness = chain.verify_completeness()
    print(f"    Completeness (all 4 invariants): "
          f"{'VALID' if completeness['all_valid'] else 'FAILED'}")

    primary = completeness["primary"]
    print(f"    Primary: {primary['equation']} → "
          f"{'✓' if primary['valid'] else '✗'}")

    policy_inv = completeness["policy_anchoring"]
    print(f"    Policy anchoring: "
          f"{policy_inv['total_policies']} policies, "
          f"{len(policy_inv['violations'])} violations → "
          f"{'✓' if policy_inv['valid'] else '✗'}")

    # ─── Audit Trail Summary ─────────────────────────────
    print("\n" + "=" * 60)
    print("AUDIT TRAIL SUMMARY")
    print("=" * 60)
    print(f"  Policy published:           {policy.event_id[:12]}...")
    print(f"  Generation attempts:        {len(attempt_event_ids)}")
    print(f"  Denials (CSAM_RISK):        {len(deny_event_ids)}")
    print(f"  Account action (BAN):       "
          f"{account_action.event_id[:12]}...")
    print(f"  LE referral (REFERRED):     "
          f"{le_referral.event_id[:12]}...")
    print(f"  Chain integrity:            VALID")
    print(f"  All invariants:             VALID")
    print(f"  Total chain events:         {len(chain.events)}")
    print("=" * 60)
    print("\nThis is the audit trail that the Florida case")
    print("didn't have. Every event is signed, hash-chained,")
    print("and independently verifiable.")


if __name__ == "__main__":
    demo_v11_lifecycle()

Run it:

pip install cryptography
python cap_srp_v11.py

Expected output:

============================================================
CAP-SRP v1.1 Lifecycle Demo
============================================================

[1] Publishing safety policy...
    Policy: cap.safety.csam-prevention.v2026-03
    Event:  019...

[2] Logging generation attempts and denials...
    Attempt 1: 019...        → DENY
    Attempt 2: 019...        → DENY
    Attempt 3: 019...        → DENY

[3] Account enforcement triggered (3 CSAM denials)...
    Action: BAN
    Event:  019...
    LE threshold met: True

[4] Law enforcement referral decision...
    Status: REFERRED
    Framework: NCMEC CyberTipline
    Legal review: Complete

[5] Verification...
    Chain integrity: VALID
    Total events: 8
    Completeness (all 4 invariants): VALID
    Primary: 3 == 0 + 3 + 0 → ✓
    Policy anchoring: 1 policies, 0 violations → ✓

============================================================
AUDIT TRAIL SUMMARY
============================================================
  Policy published:           019...
  Generation attempts:        3
  Denials (CSAM_RISK):        3
  Account action (BAN):       019...
  LE referral (REFERRED):     019...
  Chain integrity:            VALID
  All invariants:             VALID
  Total chain events:         8
============================================================

Regulatory Deadline Map

Here's what's hitting in the next 90 days and how v1.1 maps to each:

REGULATORY TIMELINE — March to August 2026
═════════════════════════════════════════════════════════════

Mar 30 ─── EU Code of Practice comment deadline
  │        └─ Relevant: POLICY_VERSION for marking compliance
  │
May 19 ─── TAKE IT DOWN Act compliance deadline
  │        └─ Relevant: GEN_DENY.takedown_relevance flags
  │           + 48-hour SLA monitoring (Gold)
  │           + ContentHash for duplicate detection
  │
Jun 30 ─── Colorado SB24-205 effective date
  │        └─ Relevant: Evidence Pack with risk analysis
  │           + RiskCategory taxonomy
  │
Aug  2 ─── EU AI Act Article 50 enforcement
           └─ Relevant: Full Silver/Gold conformance
              + POLICY_VERSION for transparency
              + External anchoring for timestamp integrity
              + Completeness Invariant for audit readiness

Deadline	Regulation	v1.1 Event Types	Conformance Level
Mar 30	EU Code of Practice (comment)	POLICY_VERSION	Silver
May 19	TAKE IT DOWN Act	GEN_DENY (takedown flags), ACCOUNT_ACTION	Silver
Jun 30	Colorado SB24-205	All generation events, Evidence Pack	Silver
Aug 2	EU AI Act Art. 50	All events, external anchoring	Silver/Gold

What Developers Should Build Now

If you're building an AI content generation system and want to be ready for the next 90 days of regulatory deadlines, here's the priority order:

Priority 1: Pre-evaluation logging (ship this week)

# The single most important change: log BEFORE safety check
attempt = chain.log_attempt(prompt, actor_id, model, policy)
# THEN run safety evaluation
result = safety_check(prompt)
# THEN log outcome
if result.blocked:
    chain.log_deny(attempt.event_id, ...)

This is the foundation. Without pre-evaluation logging, everything else is unverifiable. If you ship nothing else, ship this.

Priority 2: Policy versioning (ship this month)

Every time your safety policy changes — updated categories, new risk thresholds, model version upgrades — log a POLICY_VERSION event and get it externally timestamped. When a regulator asks "what policy was in effect when this decision was made?", you need a tamper-evident answer.

Priority 3: Account enforcement (ship before May 19)

The TAKE IT DOWN Act compliance deadline is May 19. If your system generates intimate imagery, you need a provable record of account enforcement actions. ACCOUNT_ACTION events give you that.

Priority 4: LE referral provenance (ship before August 2)

The EU AI Act Article 50 enforcement date is August 2. Gold-level conformance requires documented law enforcement assessment on account actions. This is the most complex piece, but you have four months.

C2PA Integration: Two Halves of One Architecture

For developers already implementing C2PA, here's how the two specifications fit together:

The Complete Provenance Architecture
═════════════════════════════════════════════════════════════

  ┌─────────────────────┐    ┌─────────────────────────┐
  │      C2PA           │    │       CAP-SRP           │
  │  "Content Passport" │    │  "System Flight Recorder│
  │                     │    │                         │
  │  Proves:            │    │  Proves:                │
  │  • This content was │    │  • This request was     │
  │    generated by X   │    │    blocked by policy Y  │
  │  • At time T        │    │  • Account Z was banned │
  │  • Hasn't been      │    │  • LE was notified      │
  │    tampered with    │    │  • Policy V was active  │
  │                     │    │    at decision time     │
  │  Cannot prove:      │    │  Cannot prove:          │
  │  • What was blocked │    │  • Content authenticity │
  │  • Why it was       │    │  • Tampering after      │
  │    blocked          │    │    export               │
  └──────────┬──────────┘    └──────────┬──────────────┘
             │                          │
             └──────────┬───────────────┘
                        │
                        ▼
              ┌───────────────────┐
              │   EXPORT Event    │
              │                   │
              │  Links CAP-SRP    │
              │  chain to C2PA    │
              │  manifest via     │
              │  ContentHash      │
              └───────────────────┘

The critical insight: C2PA's own specification acknowledges it provides a positive signal but not a negative signal. A missing Content Credential cannot distinguish between human-made content and AI-refused-to-generate content. CAP-SRP's GEN_DENY record is the only audit artifact available when content was not generated — because there is no content to attach C2PA credentials to.

Transparency Notes

What CAP-SRP is: An open technical specification (v1.1, released March 5, 2026) for cryptographic audit trails in AI content generation systems. Published under CC BY 4.0 by the VeritasChain Standards Organization (VSO). The reference implementation is Apache 2.0 licensed.

What CAP-SRP is not: An endorsed industry standard. CAP-SRP has not been adopted by C2PA, W3C, IEEE, or the IETF SCITT working group. An individual Internet-Draft (draft-kamimura-scitt-refusal-events-02) has been submitted to the IETF but carries no formal standing in the IETF standards process. The specification is maintained by a small team in Tokyo. No major AI company has publicly adopted it.

What the gap is: Real. The absence of independently verifiable audit trails for AI safety decisions is documented by the Content Authenticity Initiative, the Center for Democracy and Technology, the World Privacy Forum, and researchers at Princeton. Whether the industry's response takes the form of CAP-SRP, a C2PA extension, an IETF SCITT profile, or something else is an open question. The gap itself is not.

Fact-check methodology: All events cited in this article were verified against primary sources. The Florida arrest was confirmed via the Florida Attorney General's press release and FOX 35 Orlando (March 17, 2026). The ICO investigation was confirmed via ico.org.uk (February 3, 2026). The EU Code of Practice deadline was confirmed via the European Commission's digital strategy portal. The TAKE IT DOWN Act timeline was confirmed via Congress.gov and CRS analysis.

GitHub: veritaschain/cap-spec · veritaschain/cap-srp

IETF Draft: draft-kamimura-scitt-refusal-events-02

Specification: CAP-SRP v1.1

"Verify, Don't Trust" — AI needs a Flight Recorder

Reconstructing the SaaSpocalypse in Code: What VCP v1.1 Audit Trails Would Have Captured

VeritasChain Standards Organization (VSO) — Thu, 26 Mar 2026 06:41:41 +0000

On February 3, 2026, Anthropic updated a product page. Four paragraphs about Claude Cowork — an AI plugin for legal tasks. No SEC filing. No earnings call.

48 hours later: ~$285 billion in software market cap gone. RELX -17%. Wolters Kluwer -13%. Thomson Reuters -16%. LegalZoom -19.7%.

Then on March 24, it happened again. AWS internal AI agents leaked. Anthropic shipped Claude Computer Use for Mac. HubSpot -9.2%. Atlassian -8.2%. Salesforce -6.5% — worst in the Dow that day.

Here's the question nobody can answer: which algorithm sold first, and why?

Not "hedge funds sold software stocks." We know that. I mean: which exact model, running which exact version, read which exact text, assigned which exact sentiment score, at which exact microsecond, and generated which exact sell signal that cascaded across three continents?

That information existed at the time of execution. It is now irrecoverable.

Unless the system was running VeritasChain Protocol (VCP) v1.1.

This post reconstructs the SaaSpocalypse as VCP v1.1 would have captured it — real JSON payloads, real event chains, real completeness guarantees. Every code block follows the production spec.

🧱 60-Second VCP Primer

If you're new to VCP, here's the minimum you need:

┌─────────────────────────────────────────────────┐
│           VCP v1.1 Three-Layer Architecture      │
├─────────────────────────────────────────────────┤
│                                                  │
│  Layer 3: EXTERNAL VERIFIABILITY                 │
│  ├── External Anchor (TSA / Blockchain): REQUIRED│
│  ├── Ed25519 Signature: REQUIRED                 │
│  └── Third-party can verify without trusting     │
│      the log producer                            │
│                                                  │
│  Layer 2: COLLECTION INTEGRITY                   │
│  ├── Merkle Tree (RFC 6962): REQUIRED            │
│  ├── Merkle Root + Audit Path: REQUIRED          │
│  └── Proves batch completeness                   │
│                                                  │
│  Layer 1: EVENT INTEGRITY                        │
│  ├── EventHash (SHA-256): REQUIRED               │
│  ├── PrevHash (hash chain): OPTIONAL             │
│  └── Individual event tamper-evidence            │
│                                                  │
└─────────────────────────────────────────────────┘

Three payload modules:

VCP-TRADE — order lifecycle: SIG → ORD → ACK → EXE → CLS
VCP-GOV — algorithm governance: model hash, decision factors, explainability
VCP-RISK — risk controls: VaR, circuit breakers, kill switches

Every event is a JSON object with three sections: header, payload, security. Every event gets a UUIDv7 (time-sortable), a nanosecond timestamp, and a SHA-256 hash linking it to the previous event.

v1.1's killer upgrade over v1.0: completeness guarantees — Multi-Log Replication, Gossip Protocol, Monitor Nodes. Tamper-evidence proves events weren't altered. Completeness proves events weren't omitted.

Now let's build the SaaSpocalypse audit trail.

📡 Event 1: The Signal — An NLP algo reads Anthropic's product page

It's February 3, 2026, 08:12 UTC. A headline-scanning algorithm running at a London-based hedge fund processes the Claude Cowork product page. It generates a sell signal for RELX, a European legal information company.

Here's the VCP SIG event:

{
  "header": {
    "event_id": "01950a3c-1d4e-7a01-8b2c-f19e3a7b50c1",
    "trace_id": "01950a3c-1d4e-7000-8000-aabbccddeeff",
    "timestamp_int": "1738570320123456789",
    "timestamp_iso": "2026-02-03T08:12:00.123456789Z",
    "event_type": "SIG",
    "event_type_code": 1,
    "timestamp_precision": "MICROSECOND",
    "clock_sync_status": "NTP_SYNCED",
    "hash_algo": "SHA256",
    "venue_id": "XLON",
    "symbol": "REL.L",
    "account_id": "acc_hf_london_7a3b"
  },
  "payload": {
    "vcp_gov": {
      "algo_id": "nlp-headline-scanner-v4.2",
      "algo_version": "4.2.1",
      "algo_type": "AI_MODEL",
      "model_hash": "sha256:3f7a9c2e1b8d4f6a0e5c7d9b2a4f6e8c1d3b5a7f9e2c4d6b8a0f1e3c5d7b9a",
      "risk_classification": "HIGH",
      "last_approval_by": "RISK-COMMITTEE-2026-01-15",
      "approval_timestamp_int": "1736899200000000000",
      "decision_factors": {
        "features": [
          {
            "name": "headline_sentiment",
            "value": "-0.91",
            "weight": "0.40",
            "contribution": "-0.364"
          },
          {
            "name": "entity_match_score",
            "value": "0.97",
            "weight": "0.15",
            "contribution": "0.146"
          },
          {
            "name": "sector_disruption_probability",
            "value": "0.88",
            "weight": "0.25",
            "contribution": "-0.220"
          },
          {
            "name": "historical_reaction_similarity",
            "value": "0.72",
            "weight": "0.12",
            "contribution": "-0.086"
          },
          {
            "name": "volume_anomaly_z_score",
            "value": "2.34",
            "weight": "0.08",
            "contribution": "-0.187"
          }
        ],
        "confidence_score": "0.94",
        "explainability_method": "SHAP"
      }
    }
  },
  "security": {
    "event_hash": "a1c9e4f7b2d8063e5a9c1f3b7d2e4a6c8f0b3d5e7a9c2f4b6d8e0a3c5f7b9d1",
    "prev_hash": "0000000000000000000000000000000000000000000000000000000000000000"
  }
}

Let's unpack what this captures that no current system records:

model_hash: The SHA-256 fingerprint of the exact model parameters running at 08:12 UTC. Not yesterday's version, not the documentation version — the precise binary state of the model at decision time. If anyone later claims "we were running v4.1, not v4.2," the hash proves otherwise.

decision_factors: Five features, each with its name, raw value, weight, and contribution. headline_sentiment: -0.91 with contribution -0.364 means this feature alone was responsible for 36.4% of the sell signal strength. This is the field that answers "what made the algo sell?"

explainability_method: "SHAP": The algorithm used SHapley Additive exPlanations to decompose its decision. This satisfies EU AI Act Article 12 traceability requirements and ESMA's February 2026 supervisory briefing on algorithmic trading explainability.

confidence_score: "0.94": The model was 94% confident in this signal. High enough to generate an order.

prev_hash: "000...000": This is the genesis event — the first in a new hash chain for this trading session.

📤 Event 2: The Order — Basket sell across European legal-tech

The SIG event triggers a basket sell order. The algorithm doesn't just sell RELX — it sells the entire European legal-tech / data analytics sector simultaneously. Here's the ORD event for the RELX leg:

{
  "header": {
    "event_id": "01950a3c-1d52-7a01-8b2c-f19e3a7b50c2",
    "trace_id": "01950a3c-1d4e-7000-8000-aabbccddeeff",
    "timestamp_int": "1738570320173456789",
    "timestamp_iso": "2026-02-03T08:12:00.173456789Z",
    "event_type": "ORD",
    "event_type_code": 2,
    "timestamp_precision": "MICROSECOND",
    "clock_sync_status": "NTP_SYNCED",
    "hash_algo": "SHA256",
    "venue_id": "XLON",
    "symbol": "REL.L",
    "account_id": "acc_hf_london_7a3b"
  },
  "payload": {
    "trade_data": {
      "order_id": "ORD-20260203-RELX-001",
      "side": "SELL",
      "order_type": "MARKET",
      "quantity": "250000",
      "price": "0.00",
      "time_in_force": "IOC"
    },
    "vcp_risk": {
      "parameters_snapshot": {
        "max_order_size": "500000",
        "sector_exposure_pct": "12.4",
        "sector_exposure_limit_pct": "15.0",
        "daily_var_limit": "50000000.00",
        "current_var": "38750000.00",
        "circuit_breaker_status": "NORMAL"
      },
      "pre_trade_checks": [
        {
          "control_name": "MAX_ORDER_SIZE",
          "control_type": "HARD_LIMIT",
          "threshold_value": "500000",
          "actual_value": "250000",
          "result": "PASS"
        },
        {
          "control_name": "SECTOR_EXPOSURE",
          "control_type": "SOFT_LIMIT",
          "threshold_value": "15.0",
          "actual_value": "12.4",
          "result": "PASS"
        }
      ]
    }
  },
  "security": {
    "event_hash": "b2d0e5f8c3e9174f6b0d2f4c8e1a3b5d7f9c2e4a6b8d0f3a5c7e9b1d3f5a7c9",
    "prev_hash": "a1c9e4f7b2d8063e5a9c1f3b7d2e4a6c8f0b3d5e7a9c2f4b6d8e0a3c5f7b9d1"
  }
}

Key observations:

trace_id matches the SIG event: 01950a3c-1d4e-7000-8000-aabbccddeeff. This links the order causally to the signal that generated it. A basket sell across 8 stocks would generate 8 ORD events, all sharing this same trace_id.

prev_hash chains to the SIG: The ORD event's prev_hash is the SIG event's event_hash. You can verify the chain is unbroken by recomputing the hash.

vcp_risk.pre_trade_checks: Before the order was submitted, two risk controls were evaluated. Max order size: 250,000 shares against a 500,000 limit (PASS). Sector exposure: 12.4% against a 15.0% limit (PASS). This is the record that answers: "Were risk controls active when the order went out?"

Timestamp gap: 50ms between SIG and ORD (173456789 vs 123456789 in the nanosecond portion). This is the algo's internal processing latency — also a verifiable data point.

✅ Event 3: The Acknowledgment — LSE confirms receipt

The London Stock Exchange acknowledges the order:

{
  "header": {
    "event_id": "01950a3c-1d58-7a01-8b2c-f19e3a7b50c3",
    "trace_id": "01950a3c-1d4e-7000-8000-aabbccddeeff",
    "timestamp_int": "1738570320175234567",
    "timestamp_iso": "2026-02-03T08:12:00.175234567Z",
    "event_type": "ACK",
    "event_type_code": 3,
    "timestamp_precision": "MICROSECOND",
    "clock_sync_status": "NTP_SYNCED",
    "hash_algo": "SHA256",
    "venue_id": "XLON",
    "symbol": "REL.L",
    "account_id": "acc_hf_london_7a3b"
  },
  "payload": {
    "trade_data": {
      "order_id": "ORD-20260203-RELX-001",
      "broker_order_id": "LSE-ACK-88291034",
      "status": "ACCEPTED"
    }
  },
  "security": {
    "event_hash": "c3e1f6a9d4f0285a7c1e3f5b9d2a4c6e8a0b3d5f7c9e2a4b6d8f0a3c5e7b9d1",
    "prev_hash": "b2d0e5f8c3e9174f6b0d2f4c8e1a3b5d7f9c2e4a6b8d0f3a5c7e9b1d3f5a7c9"
  }
}

1.8ms from ORD to ACK. The hash chain continues unbroken: SIG → ORD → ACK.

💰 Event 4: The Execution — RELX fills at -17%

The order fills. RELX is getting hammered across the market:

{
  "header": {
    "event_id": "01950a3c-1d60-7a01-8b2c-f19e3a7b50c4",
    "trace_id": "01950a3c-1d4e-7000-8000-aabbccddeeff",
    "timestamp_int": "1738570320195678901",
    "timestamp_iso": "2026-02-03T08:12:00.195678901Z",
    "event_type": "EXE",
    "event_type_code": 4,
    "timestamp_precision": "MICROSECOND",
    "clock_sync_status": "NTP_SYNCED",
    "hash_algo": "SHA256",
    "venue_id": "XLON",
    "symbol": "REL.L",
    "account_id": "acc_hf_london_7a3b"
  },
  "payload": {
    "trade_data": {
      "order_id": "ORD-20260203-RELX-001",
      "broker_order_id": "LSE-ACK-88291034",
      "exchange_order_id": "LSE-FILL-99120453",
      "side": "SELL",
      "execution_price": "3142.00",
      "executed_qty": "250000",
      "commission": "1875.00",
      "slippage": "-0.0038"
    }
  },
  "security": {
    "event_hash": "d4f2a7b0e5a1396b8d2f4a6c0e3b5d7f9a1c3e5b7d9f0a2c4e6b8d0f2a4c6e8",
    "prev_hash": "c3e1f6a9d4f0285a7c1e3f5b9d2a4c6e8a0b3d5f7c9e2a4b6d8f0a3c5e7b9d1"
  }
}

slippage: "-0.0038": 38 basis points of negative slippage — the market moved against the order during execution. This is expected in a cascade. Captured permanently.

The complete hash chain is now: SIG → ORD → ACK → EXE. Four events, one trace_id, one unbroken cryptographic chain. Anyone can verify the entire sequence by recomputing each hash.

🚨 Event 5: Risk Breach — Sector exposure hits the wall

As the cascade accelerates, the fund's portfolio-level sector exposure approaches its limit. VCP-RISK captures this in real time:

{
  "header": {
    "event_id": "01950a3c-2a10-7a01-8b2c-f19e3a7b50d1",
    "trace_id": "01950a3c-2a10-7000-8000-112233445566",
    "timestamp_int": "1738573200456789012",
    "timestamp_iso": "2026-02-03T09:00:00.456789012Z",
    "event_type": "RSK",
    "event_type_code": 21,
    "timestamp_precision": "MICROSECOND",
    "clock_sync_status": "NTP_SYNCED",
    "hash_algo": "SHA256",
    "venue_id": "INTERNAL",
    "symbol": "PORTFOLIO",
    "account_id": "acc_hf_london_7a3b"
  },
  "payload": {
    "vcp_risk": {
      "kill_switch": {
        "status": "MONITORING",
        "activation_type": "NOT_TRIGGERED",
        "trigger_details": {
          "limit_type": "SECTOR_EXPOSURE_LIMIT",
          "limit_value": "15000000.00",
          "actual_value": "14890000.00",
          "proximity_pct": "99.27"
        },
        "scope": "SECTOR_SOFTWARE"
      },
      "triggered_controls": [
        {
          "control_name": "NET_EXPOSURE_FLOOR",
          "control_type": "SOFT_LIMIT",
          "threshold_value": "5.0",
          "actual_value": "4.2",
          "action": "ALERT",
          "action_details": {
            "alert_severity": "HIGH",
            "message": "Software net exposure breached historic low"
          }
        }
      ],
      "parameters_snapshot": {
        "circuit_breaker_status": "NORMAL",
        "var_limit": "50000000",
        "current_var": "73200000",
        "exposure_utilization": "1.464"
      }
    }
  },
  "security": {
    "event_hash": "e5a3b8c1f6b2407c9e3a5b7d1f4c6e8a0d2b4f6a8c0e3b5d7f9a1c3e5b7d9f0",
    "prev_hash": "d4f2a7b0e5a1396b8d2f4a6c0e3b5d7f9a1c3e5b7d9f0a2c4e6b8d0f2a4c6e8"
  }
}

This is the event type that doesn't exist in current systems and absolutely should.

kill_switch.activation_type: "NOT_TRIGGERED" with proximity_pct: "99.27": The sector exposure limit was 99.27% utilized. It was £110,000 away from triggering. This "near-miss" record is the difference between "our risk controls worked perfectly" and "we came within 0.73% of a hard stop."

current_var: "73200000" vs var_limit: "50000000": VaR at 146.4% of limit. This is a breach. The exposure_utilization: "1.464" field records it explicitly.

triggered_controls[0].actual_value: "4.2": Goldman Sachs' prime brokerage data (publicly reported by Bloomberg) showed software net exposure falling to 4.2% — the lowest on record. This VCP-RISK record would have captured the exact moment that floor was breached, anchored with a cryptographic timestamp.

Without VCP, this data exists only inside the fund's internal risk system — mutable, unverifiable, and subject to "adjustment" before any auditor sees it.

🌍 Event 6: Cross-Border Cascade — VCP-XREF links London to New York

When U.S. markets open at 14:30 UTC, the selling continues. A New York desk starts liquidating Thomson Reuters based on the same cascade. VCP-XREF links the cross-border events:

London originator event (XREF extension on the original SIG):

{
  "VCP-XREF": {
    "version": "1.1",
    "cross_reference_id": "01950a3c-5f00-7000-8000-xref00000001",
    "party_role": "INITIATOR",
    "counterparty_id": "hf_newyork_desk_alpha",
    "shared_event_key": {
      "order_id": "ORD-20260203-RELX-001",
      "alternate_keys": ["BASKET-20260203-SAAS-SELL-001"],
      "timestamp": 1738570320123456789,
      "tolerance_ms": 500
    },
    "reconciliation_status": "PENDING"
  }
}

New York counterparty event (on the TRI.N sell):

{
  "header": {
    "event_id": "01950a4b-0100-7b02-9c3d-a28e4c6f80d2",
    "trace_id": "01950a4b-0100-7000-8000-ffeeddccbbaa",
    "timestamp_int": "1738592400234567890",
    "timestamp_iso": "2026-02-03T14:20:00.234567890Z",
    "event_type": "SIG",
    "event_type_code": 1,
    "timestamp_precision": "MICROSECOND",
    "clock_sync_status": "NTP_SYNCED",
    "hash_algo": "SHA256",
    "venue_id": "XNYS",
    "symbol": "TRI",
    "account_id": "acc_hf_newyork_4d2a"
  },
  "payload": {
    "vcp_gov": {
      "algo_id": "cross-market-arb-v3.1",
      "algo_version": "3.1.0",
      "algo_type": "HYBRID",
      "model_hash": "sha256:7b4e2c8f1a3d6e9b0c5f8a2d4e7b1c3f6a9d2e5b8c1f4a7d0e3b6c9f2a5d8e1",
      "risk_classification": "HIGH",
      "decision_factors": {
        "features": [
          {
            "name": "eu_legal_tech_return_1h",
            "value": "-0.14",
            "weight": "0.35",
            "contribution": "-0.049"
          },
          {
            "name": "relx_adr_spread",
            "value": "0.023",
            "weight": "0.20",
            "contribution": "-0.005"
          },
          {
            "name": "sector_momentum_signal",
            "value": "-0.82",
            "weight": "0.30",
            "contribution": "-0.246"
          },
          {
            "name": "options_put_call_ratio",
            "value": "2.41",
            "weight": "0.15",
            "contribution": "-0.362"
          }
        ],
        "confidence_score": "0.89",
        "explainability_method": "SHAP"
      }
    },
    "VCP-XREF": {
      "version": "1.1",
      "cross_reference_id": "01950a3c-5f00-7000-8000-xref00000001",
      "party_role": "COUNTERPARTY",
      "counterparty_id": "hf_london_desk_beta",
      "shared_event_key": {
        "order_id": "ORD-20260203-TRI-001",
        "alternate_keys": ["BASKET-20260203-SAAS-SELL-001"],
        "timestamp": 1738592400234567890,
        "tolerance_ms": 500
      },
      "reconciliation_status": "PENDING"
    }
  },
  "security": {
    "event_hash": "f6b4c9d2e7c3518d0f4b6d8a2e5c7f9b1d3a5c7e9b1f3a5d7c9e1b3f5a7d9c2",
    "prev_hash": "0000000000000000000000000000000000000000000000000000000000000000"
  }
}

Here's what VCP-XREF makes possible:

Causal attribution: The New York algo's decision_factors show that eu_legal_tech_return_1h: -0.14 (the 14% drop in European legal-tech over the past hour) was a major input feature with weight 0.35. This proves the cross-border link — the New York sell was partly driven by the London price action. Without XREF, this is speculation. With it, it's a cryptographic fact.

Shared cross_reference_id: Both the London INITIATOR and New York COUNTERPARTY events reference 01950a3c-5f00-7000-8000-xref00000001. A regulator can query this single ID and reconstruct the complete cross-border chain. Both parties independently anchor their events, so neither can deny participation.

reconciliation_status: "PENDING": Eventually resolved to MATCHED or DISCREPANCY — the result itself is logged as a separate VCP event.

🔗 The Complete Hash Chain — Verifying the Sequence

Here's the full chain for the London RELX trade, as it would appear in a JSONL audit file:

{"header":{"event_id":"01950a3c-1d4e-7a01-8b2c-f19e3a7b50c1","trace_id":"01950a3c-1d4e-7000-8000-aabbccddeeff","timestamp_int":"1738570320123456789","event_type":"SIG","event_type_code":1},"payload":{"vcp_gov":{"algo_id":"nlp-headline-scanner-v4.2","decision_factors":{"confidence_score":"0.94","explainability_method":"SHAP"}}},"security":{"event_hash":"a1c9e4...","prev_hash":"00000000..."}}
{"header":{"event_id":"01950a3c-1d52-7a01-8b2c-f19e3a7b50c2","trace_id":"01950a3c-1d4e-7000-8000-aabbccddeeff","timestamp_int":"1738570320173456789","event_type":"ORD","event_type_code":2},"payload":{"trade_data":{"order_id":"ORD-20260203-RELX-001","side":"SELL","quantity":"250000"}},"security":{"event_hash":"b2d0e5...","prev_hash":"a1c9e4..."}}
{"header":{"event_id":"01950a3c-1d58-7a01-8b2c-f19e3a7b50c3","trace_id":"01950a3c-1d4e-7000-8000-aabbccddeeff","timestamp_int":"1738570320175234567","event_type":"ACK","event_type_code":3},"payload":{"trade_data":{"order_id":"ORD-20260203-RELX-001","status":"ACCEPTED"}},"security":{"event_hash":"c3e1f6...","prev_hash":"b2d0e5..."}}
{"header":{"event_id":"01950a3c-1d60-7a01-8b2c-f19e3a7b50c4","trace_id":"01950a3c-1d4e-7000-8000-aabbccddeeff","timestamp_int":"1738570320195678901","event_type":"EXE","event_type_code":4},"payload":{"trade_data":{"order_id":"ORD-20260203-RELX-001","execution_price":"3142.00","executed_qty":"250000"}},"security":{"event_hash":"d4f2a7...","prev_hash":"c3e1f6..."}}
{"header":{"event_id":"01950a3c-2a10-7a01-8b2c-f19e3a7b50d1","trace_id":"01950a3c-2a10-7000-8000-112233445566","timestamp_int":"1738573200456789012","event_type":"RSK","event_type_code":21},"payload":{"vcp_risk":{"kill_switch":{"status":"MONITORING","proximity_pct":"99.27"}}},"security":{"event_hash":"e5a3b8...","prev_hash":"d4f2a7..."}}

Verifying this chain in Python:

import hashlib
import json

def verify_hash_chain(events: list[dict]) -> bool:
    """Verify VCP hash chain integrity."""
    for i, event in enumerate(events):
        # 1. Verify prev_hash linkage
        if i == 0:
            assert event["security"]["prev_hash"] == "0" * 64, \
                "Genesis event must have zero prev_hash"
        else:
            assert event["security"]["prev_hash"] == \
                events[i - 1]["security"]["event_hash"], \
                f"Chain break at event {i}"

        # 2. Recompute event_hash (RFC 8785 canonical JSON)
        canonical = json.dumps(
            {"header": event["header"], "payload": event["payload"]},
            sort_keys=True,
            separators=(",", ":"),
            ensure_ascii=False
        )
        computed_hash = hashlib.sha256(canonical.encode("utf-8")).hexdigest()
        assert computed_hash == event["security"]["event_hash"], \
            f"Hash mismatch at event {i}"

    return True


# Usage
with open("saaspocalypse_relx_chain.jsonl") as f:
    events = [json.loads(line) for line in f]

if verify_hash_chain(events):
    print("✅ Hash chain verified: all events authentic and unbroken")
else:
    print("❌ Chain integrity failure detected")

That's it. Anyone — regulator, auditor, journalist, counterparty — can run this verification. No API key. No special access. No trust required.

🛡️ The Completeness Layer — Why v1.1 Is Different

Hash chains prove events weren't altered. But they can't prove events weren't deleted. If someone removes Event #3 from the chain and recomputes the hashes, the modified chain looks perfectly valid.

VCP v1.1 solves this with three mechanisms. Here's how they would have operated during the SaaSpocalypse:

Multi-Log Replication

Every event is simultaneously written to ≥2 independent log servers:

{
  "VCP-XREF": {
    "primary_log_server": "log-a.hedge-fund.internal",
    "replica_log_servers": [
      "log-b.independent-auditor.com",
      "log-c.cloud-anchor.veritaschain.org"
    ],
    "delivery_receipts": [
      {
        "server": "log-a",
        "timestamp": "2026-02-03T08:12:00.130Z",
        "merkle_position": 42891
      },
      {
        "server": "log-b",
        "timestamp": "2026-02-03T08:12:00.134Z",
        "merkle_position": 42891
      },
      {
        "server": "log-c",
        "timestamp": "2026-02-03T08:12:00.142Z",
        "merkle_position": 42891
      }
    ]
  }
}

To silently drop an event, you'd need to compromise all three servers under different administrative control simultaneously. That's the design.

Gossip Protocol

Log servers periodically exchange signed Merkle roots:

{
  "gossip_message": {
    "sender": "log-a.hedge-fund.internal",
    "merkle_root": "sha256:9f2e1a4c7b3d6e0f8a5c2d4e7b1c3f6a9d2e5b8c...",
    "event_count": 42891,
    "timestamp": "2026-02-03T08:15:00.000Z",
    "signature": "ed25519:MEUCIQD7Kx9h3p...",
    "signature_algo": "Ed25519"
  }
}

If log-a says the Merkle root is 9f2e1a... at count 42,891 but log-b says it's 3c7f4a... at the same count — an inconsistency alert fires immediately. Split-view attack detected.

Monitor Nodes

Independent third-party nodes continuously verify:

class VCPMonitorNode:
    """Independent verification node (simplified)."""

    def __init__(self, log_servers: list[str]):
        self.servers = log_servers
        self.last_roots: dict[str, str] = {}
        self.last_counts: dict[str, int] = {}

    async def check_consistency(self) -> list[Alert]:
        alerts = []
        roots = {}

        for server in self.servers:
            status = await self.fetch_status(server)
            roots[server] = status["merkle_root"]

            # Check 1: Root consistency across servers
            if len(set(roots.values())) > 1:
                alerts.append(Alert(
                    type="SPLIT_VIEW",
                    severity="CRITICAL",
                    detail=f"Merkle root mismatch: {roots}"
                ))

            # Check 2: Event count vs market activity
            expected_events = await self.estimate_expected_events(
                server, status["time_window"]
            )
            actual_events = status["event_count"]
            if actual_events < expected_events * 0.5:
                alerts.append(Alert(
                    type="EVENT_GAP",
                    severity="HIGH",
                    detail=(
                        f"Expected ~{expected_events} events, "
                        f"got {actual_events} — possible omission"
                    )
                ))

        return alerts

During the SaaSpocalypse, IGV recorded its highest trading volume in 25 years. A Monitor Node would have compared the spike in market volume against the event count from each log server. If volume tripled but logged events only increased 40%, the EVENT_GAP alert would fire — catching omissions in real time, not weeks later during an audit.

🔄 March 24 Replay: Same Pattern, Same Gaps

On March 24, the SaaSpocalypse repeated. The Information leaked AWS's internal AI agent deployment. Anthropic shipped Claude Computer Use. Software stocks cratered again.

Here's what a VCP-GOV record would have captured for a sentiment algo processing the AWS news:

{
  "payload": {
    "vcp_gov": {
      "algo_id": "sector-sentiment-rotator-v2.8",
      "algo_version": "2.8.3",
      "algo_type": "AI_MODEL",
      "model_hash": "sha256:2c4e6a8d0f2b4c6e8a0d2f4b6c8e0a2d4f6b8c0e2a4d6f8b0c2e4a6d8f0b2c",
      "risk_classification": "HIGH",
      "decision_factors": {
        "features": [
          {
            "name": "aws_agent_disruption_score",
            "value": "0.91",
            "weight": "0.30",
            "contribution": "-0.273"
          },
          {
            "name": "anthropic_computer_use_impact",
            "value": "0.85",
            "weight": "0.25",
            "contribution": "-0.213"
          },
          {
            "name": "saas_sector_momentum_5d",
            "value": "-0.67",
            "weight": "0.20",
            "contribution": "-0.134"
          },
          {
            "name": "igv_etf_flow_signal",
            "value": "-0.43",
            "weight": "0.15",
            "contribution": "-0.065"
          },
          {
            "name": "vix_term_structure_slope",
            "value": "0.12",
            "weight": "0.10",
            "contribution": "-0.012"
          }
        ],
        "confidence_score": "0.88",
        "explainability_method": "SHAP"
      }
    }
  }
}

Now compare the two events:

Feature	Feb 3 SIG (RELX)	Mar 24 SIG (sector rotation)
Primary driver	`headline_sentiment: -0.91`	`aws_agent_disruption_score: 0.91`
Top contribution	-0.364 (sentiment)	-0.273 (AWS disruption)
Confidence	0.94	0.88
Model	nlp-headline-scanner-v4.2	sector-sentiment-rotator-v2.8
Model hash	`sha256:3f7a9c...`	`sha256:2c4e6a...`

Two different algorithms, two different model versions, two different feature sets — but the same structural pattern: a single information event triggering a high-confidence sell cascade in software stocks. Without VCP-GOV, these are just "the market sold off." With it, you can compare the decision anatomy of both events at feature level.

📊 Regulatory Countdown

Why does this matter right now?

┌─────────────────────────────────────────────────┐
│          Enforcement Deadlines                   │
├─────────────────────────────────────────────────┤
│                                                  │
│  🇺🇸 Colorado AI Act:     June 30, 2026          │
│     └─ Documentation for high-risk AI deployers  │
│                                                  │
│  🇪🇺 EU AI Act Art. 12:   August 2, 2026         │
│     └─ "Automatic recording of events (logs)     │
│        over the lifetime of the system"          │
│     └─ Traceability, post-market monitoring      │
│                                                  │
│  🇪🇺 ESMA Algo Briefing:  In effect now          │
│     └─ Comprehensive records of AI decisions     │
│     └─ Annual self-assessment of algo behavior   │
│     └─ Pre-trade controls covering all AI types  │
│                                                  │
│  🇩🇪 BaFin AI Guidance:   In effect (Dec 2025)   │
│     └─ AI classified as ICT asset under DORA     │
│     └─ Lifecycle documentation required          │
│                                                  │
└─────────────────────────────────────────────────┘

VCP v1.1 maps directly to these requirements:

Requirement	Regulation	VCP Field
Automatic event logging	EU AI Act Art. 12	VCP-TRADE event lifecycle
Decision traceability	ESMA AI Briefing	VCP-GOV `DecisionFactors`
Model identification	MiFID II RTS 6	VCP-GOV `AlgoID` + `ModelHash`
Timestamp precision	MiFID II RTS 25	`timestamp_precision` + `clock_sync_status`
Explainability	EU AI Act Art. 12	VCP-GOV `ExplainabilityMethod`
Risk control records	RTS 6 Art. 15	VCP-RISK `pre_trade_checks`
Completeness guarantee	EU AI Act Art. 72§2	Multi-Log + Gossip + Monitor Nodes
5-year retention	MiFID II Art. 17	Merkle Tree + External Anchor

🛠️ Getting Started

VCP v1.1 is an open standard. The spec, the schema, and the reference implementations are all public:

# Clone the spec repo
git clone https://github.com/veritaschain/vcp-spec.git

# The v1.1 specification
cat vcp-spec/spec/v1.1/VCP-Specification-v1.1.md

# IETF Internet-Draft (SCITT profile)
# https://datatracker.ietf.org/doc/draft-kamimura-scitt-vcp/

Compliance tiers — pick your level:

Tier	Timestamp Precision	Clock Sync	External Anchor Freq	Target
Silver	Millisecond	BEST_EFFORT	Daily	Retail / Prop firms
Gold	Microsecond	NTP_SYNCED	Hourly	Institutional
Platinum	Nanosecond	PTP_LOCKED (IEEE 1588)	Every 10 min	HFT / Market makers

At Silver tier, the overhead is minimal — a sidecar process that runs alongside your existing trading system, generates VCP events, and anchors daily to a public timestamp authority. No modification to your FIX engine or execution logic required.

💭 The Bottom Line

The SaaSpocalypse wiped out an estimated $1–2 trillion in software market capitalization across eight weeks. The institutional post-mortems said "indiscriminate selling" and "sentiment-driven." The analyst reports said "AI disruption fears."

None of them could say: "Algorithm X, running model version Y, assigned sentiment score Z to input W, and generated sell signal S at timestamp T."

That sentence is what VCP v1.1 records. Every event. Every decision factor. Every risk control state. Every cross-border link. With cryptographic proof that the record is authentic, unaltered, and complete.

The spec is open. The license is CC BY 4.0. The deadline is August 2, 2026.

Build the flight recorder before the next crash.

The VeritasChain Protocol v1.1 is maintained by the VeritasChain Standards Organization (VSO). Spec: GitHub. IETF: draft-kamimura-scitt-vcp. Contact: info@veritaschain.org

VCP v1.1: Building a Flight Recorder for the SaaSpocalypse — Three-Layer Cryptographic Audit Trails for Algorithmic Trading

VeritasChain Standards Organization (VSO) — Wed, 25 Mar 2026 03:41:53 +0000

🔥 $2 Trillion Gone. Zero Verifiable Audit Trails.

On March 24, 2026, AWS reported plans to replace its own technical specialists with AI agents. Anthropic announced Claude could directly control Mac desktops. Within hours:

HubSpot: -9.2%
UiPath: -8.7%
Atlassian: -8.4% (touching -9.5% intraday)
Salesforce: -5.8% to -6.5%
IGV ETF: -4.4%, closing at ~$81 (~23% YTD)

This was Phase 3 of the "SaaSpocalypse" — a rolling sell-off that has erased roughly $2 trillion in software market cap since January 2026. JPMorgan called it "the largest non-recessionary 12-month drawdown in over 30 years."

The Phase 2 trigger on February 3 was even more dramatic: Anthropic's Claude Cowork Legal Triage plugin wiped $285 billion in a single 48-hour session. Thomson Reuters lost 16–18% in one day.

Here's the question nobody can answer: which algorithm fired first, what features drove the decision, and can you prove it?

The answer is no. Not with current infrastructure. Because algorithmic trading audit trails are proprietary, mutable, and unverifiable by third parties.

VCP v1.1 — the VeritasChain Protocol — is an open standard designed to fix this. Think of it as a flight recorder for algorithmic trading systems.

This article walks through the architecture, the code, and why it matters now.

📐 VCP v1.1 Architecture: Three Layers of Cryptographic Proof

VCP v1.1 (released December 30, 2025) introduces a clear three-layer integrity architecture. Each layer solves a distinct problem:

┌─────────────────────────────────────────────────────┐
│                                                     │
│  LAYER 3: External Verifiability                    │
│  ─────────────────────────────────                  │
│  Purpose: Third-party verification without trust    │
│                                                     │
│  Components:                                        │
│  ├─ Digital Signature (Ed25519): REQUIRED           │
│  ├─ Timestamp (ISO + int64 ns): REQUIRED            │
│  └─ External Anchor (TSA/Blockchain): REQUIRED      │
│                                                     │
│  Frequency: 10min (Platinum) / 1hr (Gold) /         │
│             24hr (Silver)                            │
│                                                     │
├─────────────────────────────────────────────────────┤
│                                                     │
│  LAYER 2: Collection Integrity                      │
│  ─────────────────────────────                      │
│  Purpose: Prove completeness of event batches       │
│                                                     │
│  Components:                                        │
│  ├─ Merkle Tree (RFC 6962): REQUIRED                │
│  ├─ Merkle Root: REQUIRED                           │
│  └─ Audit Path (verification): REQUIRED             │
│                                                     │
├─────────────────────────────────────────────────────┤
│                                                     │
│  LAYER 1: Event Integrity                           │
│  ────────────────────────                           │
│  Purpose: Individual event tamper-evidence          │
│                                                     │
│  Components:                                        │
│  ├─ EventHash (SHA-256 of canonical JSON): REQUIRED │
│  └─ PrevHash (chain to prior event): OPTIONAL       │
│                                                     │
└─────────────────────────────────────────────────────┘

What Changed from v1.0 → v1.1

Five key changes. The rationale is simple: v1.0 made external anchoring optional for Silver tier, which meant log producers could theoretically modify Merkle Roots before anchoring. v1.1 closes this gap.

# v1.0 → v1.1 Changes
changes:
  1_three_layer_architecture:
    impact: "Section 6 restructured"
    migration: "Documentation only"

  2_prevhash_now_optional:
    v1_0: "REQUIRED for all tiers"
    v1_1: "OPTIONAL for all tiers"
    rationale: "Local integrity mechanism; complements but doesn't replace external verifiability"
    migration: "None (relaxation)"

  3_external_anchor_mandatory:
    v1_0: "OPTIONAL (Silver) / RECOMMENDED (Gold) / REQUIRED (Platinum)"
    v1_1: "REQUIRED for ALL tiers"
    rationale: "'Verify, Don't Trust' requires external proof"
    migration: "Silver tier must add daily anchoring"

  4_policy_identification:
    status: "NEW — REQUIRED for all tiers"
    purpose: "Every event declares its conformance tier and registration policy"

  5_vcp_xref_dual_logging:
    status: "NEW — OPTIONAL extension"
    purpose: "Cross-party verification for dispute resolution"

Breaking change note: v1.1 is protocol-compatible / certification-stricter. Existing v1.0 implementations interoperate with v1.1 systems, but may need additional components for v1.1 VC-Certified status.

🏗️ Layer 1: Event Integrity (SHA-256 + RFC 8785)

Every VCP event gets a hash. The hash covers canonicalized JSON (RFC 8785 — JSON Canonicalization Scheme), so identical logical content always produces the same hash regardless of serialization order.

Event Structure

interface VCPEvent {
  // Identifiers
  event_id: string;        // UUIDv7 (time-ordered)
  trace_id: string;        // UUIDv7 (groups related events)

  // Timestamps (dual format)
  timestamp_int: string;   // Nanoseconds since epoch (STRING — avoids JS 2^53 limit)
  timestamp_iso: string;   // ISO 8601

  // Event Classification
  event_type: string;      // SIG | ORD | ACK | REJ | EXE | CXL | CLS | MOD | PRT
  event_type_code: number; // 1-10

  // Context
  symbol: string;          // e.g., "XAUUSD"
  venue_id: string;
  account_id: string;      // Pseudonymized for GDPR

  // Payload (module-specific)
  payload: {
    trade_data?: VcpTradePayload;
    vcp_risk?: VcpRiskPayload;
    vcp_gov?: VcpGovPayload;
  };

  // Security (computed)
  event_hash: string;      // SHA-256 of canonical JSON
  prev_hash?: string;      // OPTIONAL in v1.1
}

Computing EventHash (Python)

import hashlib
import json
import uuid

def compute_event_hash(event: dict) -> str:
    """
    Compute VCP EventHash using RFC 8785 JSON Canonicalization.

    The canonical form ensures identical logical content
    always produces the same hash, regardless of key ordering
    or whitespace in the original JSON.
    """
    # Remove computed fields before hashing
    hashable = {k: v for k, v in event.items()
                if k not in ('event_hash', 'prev_hash', 'signature')}

    # RFC 8785: sorted keys, no whitespace, deterministic floats
    canonical = json.dumps(
        hashable,
        sort_keys=True,
        separators=(',', ':'),
        ensure_ascii=False
    )

    return hashlib.sha256(canonical.encode('utf-8')).hexdigest()


# Example: A SIG (Signal Generated) event from the SaaSpocalypse
event = {
    "event_id": "01936a2b-8c4d-7f00-9123-456789abcdef",
    "trace_id": "01936a2b-8c4d-7f00-8000-aabbccddeeff",
    "timestamp_int": "1742860800123000000",  # 2026-03-24T16:00:00.123Z in ns
    "timestamp_iso": "2026-03-24T16:00:00.123Z",
    "event_type": "SIG",
    "event_type_code": 1,
    "symbol": "CRM",      # Salesforce
    "venue_id": "NYSE",
    "account_id": "ACCT-PSEUDO-42",
    "payload": {
        "vcp_gov": {
            "algo_id": "ALG-SENT-2026-001",
            "algo_version": "3.2.1",
            "algo_type": "AI_MODEL",
            "model_hash": "sha256:a1b2c3d4e5f6...",
            "decision_factors": {
                "features": [
                    {"name": "headline_sentiment", "value": "-0.87",
                     "weight": "0.35", "contribution": "0.42"},
                    {"name": "options_flow_delta", "value": "-0.62",
                     "weight": "0.25", "contribution": "0.28"},
                    {"name": "sector_momentum", "value": "-0.45",
                     "weight": "0.20", "contribution": "0.18"}
                ],
                "confidence_score": "0.78",
                "explainability_method": "SHAP"
            },
            "risk_classification": "MEDIUM"
        }
    }
}

event_hash = compute_event_hash(event)
print(f"EventHash: {event_hash}")
# EventHash: 8f2a7b9d1b0c3e4f... (deterministic, reproducible)

Why `timestamp_int` Is a String

⚠️ This trips people up. JavaScript's Number.MAX_SAFE_INTEGER is 2^53 - 1 = 9007199254740991. A nanosecond timestamp for 2026 is ~1.74 × 10^18 — well beyond safe integer range. Storing as string preserves precision across all languages:

{
  "timestamp_int": "1742860800123000000",
  "price": "193.42",
  "quantity": "10000.00"
}

All financial numeric values are strings in VCP. This avoids IEEE 754 floating-point precision loss in canonical hashing.

🌳 Layer 2: Collection Integrity (RFC 6962 Merkle Trees)

Individual event hashes prove each event wasn't tampered with. But they can't prove completeness — that no events were deleted or omitted. Merkle trees solve this.

VCP uses RFC 6962 (Certificate Transparency) Merkle tree construction:

import hashlib
from typing import List

def merkle_root(leaves: List[bytes]) -> bytes:
    """
    Build RFC 6962-compliant Merkle tree and return root.

    Leaf hash:   SHA256(0x00 || leaf_data)
    Branch hash: SHA256(0x01 || left || right)

    This prefix scheme prevents second-preimage attacks —
    you can't forge a leaf that looks like a branch or vice versa.
    """
    if not leaves:
        return hashlib.sha256(b'').digest()

    # Leaf hashing with 0x00 prefix (RFC 6962 §2.1)
    nodes = [hashlib.sha256(b'\x00' + leaf).digest() for leaf in leaves]

    # Pad to power of 2 (duplicate last leaf)
    while len(nodes) & (len(nodes) - 1):
        nodes.append(nodes[-1])

    # Build tree bottom-up with 0x01 prefix for branches
    while len(nodes) > 1:
        nodes = [
            hashlib.sha256(b'\x01' + nodes[i] + nodes[i + 1]).digest()
            for i in range(0, len(nodes), 2)
        ]

    return nodes[0]


def generate_audit_path(leaves: List[bytes], index: int) -> List[bytes]:
    """
    Generate Merkle audit path (inclusion proof) for a specific leaf.

    This path allows anyone to verify that a specific event exists
    in the batch WITHOUT seeing the other events — critical for
    proving completeness to regulators while protecting proprietary
    trading strategies.
    """
    nodes = [hashlib.sha256(b'\x00' + leaf).digest() for leaf in leaves]
    while len(nodes) & (len(nodes) - 1):
        nodes.append(nodes[-1])

    path = []
    while len(nodes) > 1:
        if index % 2 == 0:
            path.append(nodes[index + 1] if index + 1 < len(nodes) else nodes[index])
        else:
            path.append(nodes[index - 1])
        index //= 2
        nodes = [
            hashlib.sha256(b'\x01' + nodes[i] + nodes[i + 1]).digest()
            for i in range(0, len(nodes), 2)
        ]
    return path


# Example: Batch of 4 trading events from the SaaSpocalypse cascade
event_hashes = [
    b"8f2a7b9d...",  # SIG: Sell signal generated (CRM)
    b"3c4d5e6f...",  # ORD: Order submitted to NYSE
    b"a1b2c3d4...",  # ACK: Order acknowledged
    b"7e8f9a0b...",  # EXE: Execution at $193.42
]

root = merkle_root(event_hashes)
print(f"Merkle Root: {root.hex()}")

# Generate proof for the SIG event (index 0)
proof = generate_audit_path(event_hashes, 0)
print(f"Audit path length: {len(proof)} nodes")

Verification Without Trust

Here's the key insight: anyone with the Merkle root, the audit path, and a single event hash can verify that event was part of the batch — without seeing any other events:

def verify_inclusion(event_hash: bytes, proof: List[bytes],
                     root: bytes, index: int) -> bool:
    """
    Verify Merkle inclusion proof.

    A regulator can verify this event was logged in the batch
    without the firm revealing any other events in the batch.
    """
    current = hashlib.sha256(b'\x00' + event_hash).digest()

    for sibling in proof:
        if index % 2 == 0:
            current = hashlib.sha256(b'\x01' + current + sibling).digest()
        else:
            current = hashlib.sha256(b'\x01' + sibling + current).digest()
        index //= 2

    return current == root

⚓ Layer 3: External Verifiability (Mandatory Anchoring)

This is the biggest change in VCP v1.1: external anchoring is now REQUIRED for all tiers.

In v1.0, Silver tier could skip anchoring. This meant the log producer controlled the entire evidence chain — they could modify Merkle Roots before anyone else saw them. v1.1 closes this by mandating that every tier commits roots to an external, immutable timestamping service.

Anchoring Frequencies by Tier

# VCP v1.1 Conformance Tiers
tiers:
  platinum:
    target: "HFT / Exchange systems"
    clock_sync: PTP_LOCKED    # <1µs divergence from UTC
    timestamp_precision: NANOSECOND
    anchor_interval: "≤10 minutes"
    anchor_type: "Blockchain or RFC 3161 TSA"

  gold:
    target: "Institutional algorithmic trading"
    clock_sync: NTP_SYNCED    # <1ms divergence from UTC
    timestamp_precision: MICROSECOND
    anchor_interval: "≤1 hour"
    anchor_type: "Blockchain or RFC 3161 TSA"

  silver:
    target: "Development, testing, retail, backtesting"
    clock_sync: BEST_EFFORT   # System clock
    timestamp_precision: MILLISECOND
    anchor_interval: "≤24 hours"
    anchor_type: "Any supported method"

⚠️ MiFID II Warning: Silver tier's BEST_EFFORT clock sync does NOT meet MiFID II RTS 25 requirements for algorithmic trading. If you're subject to EU algo trading regulations, you need Gold (NTP <1ms) at minimum. Silver is for dev/test/backtesting only.

Anchoring Implementation (RFC 3161 TSA)

import hashlib
import requests
from datetime import datetime, timezone

def anchor_to_tsa(merkle_root: bytes,
                  tsa_url: str = "https://freetsa.org/tsr") -> dict:
    """
    Anchor a Merkle root to an RFC 3161 Timestamp Authority.

    This proves the Merkle root (and therefore all events in the batch)
    existed at the timestamp issued by the TSA. The TSA is an independent
    third party — the log producer cannot backdate or modify the anchor.
    """
    # Create timestamp request (simplified — production code uses pyasn1)
    ts_request = create_timestamp_request(merkle_root)

    response = requests.post(
        tsa_url,
        data=ts_request,
        headers={"Content-Type": "application/timestamp-query"}
    )

    if response.status_code == 200:
        return {
            "anchor_type": "RFC3161_TSA",
            "tsa_url": tsa_url,
            "merkle_root": merkle_root.hex(),
            "response": response.content.hex(),
            "anchored_at": datetime.now(timezone.utc).isoformat()
        }
    raise Exception(f"TSA anchoring failed: {response.status_code}")


def anchor_to_blockchain(merkle_root: bytes,
                         network: str = "ethereum-mainnet") -> dict:
    """
    Alternative: Anchor to a blockchain via OP_RETURN or similar mechanism.

    For production Platinum-tier deployments, blockchain anchoring provides
    the strongest guarantee — the entire network would need to be compromised
    to alter the anchor.
    """
    # Implementation depends on chain (Ethereum, Bitcoin OP_RETURN, etc.)
    tx_hash = submit_anchor_transaction(merkle_root, network)
    return {
        "anchor_type": "BLOCKCHAIN",
        "network": network,
        "tx_hash": tx_hash,
        "merkle_root": merkle_root.hex(),
        "anchored_at": datetime.now(timezone.utc).isoformat()
    }

🔬 VCP-GOV: Why the SaaSpocalypse Is Unauditable Without This

The extension module that matters most for the SaaSpocalypse analysis is VCP-GOV (Algorithm Governance). It captures the AI decision metadata that regulators increasingly demand but no current standard operationalizes.

{
  "VCP-GOV": {
    "AlgorithmIdentification": {
      "AlgoID": "ALG-SENT-2026-001",
      "AlgoVersion": "3.2.1",
      "AlgoType": "AI_MODEL",
      "ModelType": "FinBERT-v4",
      "ModelHash": "sha256:a1b2c3d4e5f67890abcdef..."
    },
    "Governance": {
      "RiskClassification": "MEDIUM",
      "LastApprovalBy": "RISK-MGR-042",
      "ApprovalTimestamp": "1742774400000000000",
      "TestingRecordLink": "https://internal.firm.com/tests/ALG-SENT-2026-001-v3.2.1"
    },
    "DecisionFactors": {
      "Features": [
        {"Name": "headline_sentiment", "Value": "-0.87",
         "Weight": "0.35", "Contribution": "0.42"},
        {"Name": "options_flow_delta", "Value": "-0.62",
         "Weight": "0.25", "Contribution": "0.28"},
        {"Name": "sector_momentum", "Value": "-0.45",
         "Weight": "0.20", "Contribution": "0.18"},
        {"Name": "volume_anomaly", "Value": "2.34",
         "Weight": "0.20", "Contribution": "0.12"}
      ],
      "ConfidenceScore": "0.78",
      "ExplainabilityMethod": "SHAP"
    }
  }
}

What This Means for Post-Incident Analysis

With VCP-GOV active across trading firms on March 24, investigators could:

Identify the first mover: Which AlgoID generated the earliest SIG event with negative sentiment for SaaS stocks?
Trace the interpretation: Was headline_sentiment: -0.87 derived from the AWS AI agent headline or the Anthropic Mac control headline?
Quantify the confidence gap: A ConfidenceScore of 0.78 on a sector-wide sell signal is arguably low — was the algorithm certain or just following a herd?
Verify model identity: ModelHash proves which exact model version generated each decision. No post-hoc model swaps.
Audit the explanation: SHAP values show that headline_sentiment contributed 42% of the decision weight. Was this feature properly calibrated for product launches vs. workforce displacement news?

None of this is possible today because there is no standard format for logging AI trading decisions, and existing logs are unverifiable.

🛡️ VCP-RISK: Did Circuit Breakers Actually Fire?

The second critical extension for the SaaSpocalypse is VCP-RISK, which captures risk management state at event time:

{
  "VCP-RISK": {
    "snapshot": {
      "max_position_size": "500000",
      "current_position": "-387000",
      "exposure_utilization": "0.774",
      "max_daily_drawdown": "-250000",
      "current_drawdown": "-183000",
      "var_95": "0.034",
      "net_exposure": "-0.62"
    },
    "triggered_controls": [
      {
        "control_name": "SECTOR_CONCENTRATION_LIMIT",
        "trigger_value": "0.774",
        "action": "WARN",
        "timestamp_int": "1742860800456000000"
      }
    ]
  }
}

When a firm tells regulators "our risk controls functioned properly during the sell-off," VCP-RISK provides cryptographic proof — or contradiction. The triggered_controls array shows exactly which safeguards activated, when, and what action was taken. If the array is empty during a period when positions were growing into a cascade, that's verifiable evidence of a risk management gap.

🔗 VCP-XREF: Cross-Party Verification

VCP v1.1 introduces VCP-XREF for dual-party logging. Each counterparty independently logs events and references the other via a shared CrossReferenceID:

{
  "VCP-XREF": {
    "CrossReferenceID": "019f3a2b-1234-4567-89ab-cdef01234567",
    "CounterpartyLogServer": "audit.counterparty-firm.com",
    "SharedEventKey": {
      "OrderID": "ORD-NYSE-2026-03-24-18472",
      "Timestamp": "1742860800789000000",
      "ToleranceMs": 100
    },
    "VerificationStatus": "PENDING",
    "DiscrepancyDetails": null
  }
}

The Guarantee

If Party A claims event E occurred and Party B denies it, the VCP-XREF records from both parties provide non-repudiable evidence. Manipulation requires:

Collusion between both parties, AND
Compromise of external anchors

With VCP-XREF + external anchoring, unilateral log manipulation is cryptographically detectable.

📋 Policy Identification: New in v1.1

Every VCP event now must declare its conformance tier and registration policy. This enables verifiers to apply the right validation rules:

{
  "PolicyIdentification": {
    "Version": "1.1",
    "PolicyID": "org.veritaschain.prod:firm-alpha-001",
    "ConformanceTier": "GOLD",
    "RegistrationPolicy": {
      "Issuer": "VeritasChain Standards Organization",
      "PolicyURI": "https://veritaschain.org/policies/gold-v1.1",
      "EffectiveDate": "1735689600000000000"
    },
    "VerificationDepth": {
      "HashChainValidation": true,
      "MerkleProofRequired": true,
      "ExternalAnchorRequired": true
    }
  }
}

✅ Conformance Test Matrix (v1.1)

If you're implementing VCP v1.1, here's what you need to pass:

Test Category              Silver    Gold      Platinum
─────────────────────────  ────────  ────────  ────────
Schema Validation          REQUIRED  REQUIRED  REQUIRED
UUID v7 Format             REQUIRED  REQUIRED  REQUIRED
Timestamp (MILLISECOND)    REQUIRED  REQUIRED  REQUIRED
Timestamp (MICROSECOND)    optional  REQUIRED  REQUIRED
Timestamp (NANOSECOND)     optional  optional  REQUIRED
EventHash Calculation      REQUIRED  REQUIRED  REQUIRED
Hash Chain (PrevHash)      optional  optional  optional  ← Changed in v1.1
Digital Signature          REQUIRED  REQUIRED  REQUIRED
Merkle Tree Construction   REQUIRED  REQUIRED  REQUIRED
Merkle Proof Verification  REQUIRED  REQUIRED  REQUIRED
External Anchor            REQUIRED  REQUIRED  REQUIRED  ← Changed in v1.1
Policy Identification      REQUIRED  REQUIRED  REQUIRED  ← New in v1.1
Clock Sync (BEST_EFFORT)   REQUIRED  REQUIRED  REQUIRED
Clock Sync (NTP_SYNCED)    optional  REQUIRED  REQUIRED
Clock Sync (PTP_LOCKED)    optional  optional  REQUIRED

Critical tests (automatic certification failure):

SCH-001: Event structure validation
UID-001: UUID v7 format
HCH-003: Hash calculation algorithm (EventHash)
SIG-001: Signature algorithm compliance
MKL-001: Merkle tree construction (new)
MKL-002: Merkle proof verification (new)
ANC-001: External anchor presence (new)
POL-001: Policy Identification (new)

🏃 Quick Start: Minimal VCP v1.1 Event in Python

import hashlib
import json
import time
import uuid
from datetime import datetime, timezone


def create_vcp_event(event_type: str, event_type_code: int,
                     symbol: str, venue_id: str,
                     payload: dict) -> dict:
    """Create a minimal VCP v1.1 compliant event."""

    now = datetime.now(timezone.utc)
    ns = int(now.timestamp() * 1_000_000_000)

    event = {
        "event_id": str(uuid.uuid7()),     # Time-ordered
        "trace_id": str(uuid.uuid7()),
        "timestamp_int": str(ns),
        "timestamp_iso": now.isoformat(),
        "event_type": event_type,
        "event_type_code": event_type_code,
        "symbol": symbol,
        "venue_id": venue_id,
        "account_id": "ACCT-PSEUDO-001",
        "payload": payload,
        "policy_identification": {
            "version": "1.1",
            "policy_id": "org.veritaschain.dev:quickstart",
            "conformance_tier": "SILVER",
            "verification_depth": {
                "hash_chain_validation": False,
                "merkle_proof_required": True,
                "external_anchor_required": True
            }
        }
    }

    # Compute EventHash (Layer 1)
    hashable = {k: v for k, v in event.items()
                if k not in ('event_hash',)}
    canonical = json.dumps(hashable, sort_keys=True, separators=(',', ':'))
    event["event_hash"] = hashlib.sha256(canonical.encode()).hexdigest()

    return event


# Create a signal event
sig_event = create_vcp_event(
    event_type="SIG",
    event_type_code=1,
    symbol="CRM",
    venue_id="NYSE",
    payload={
        "vcp_gov": {
            "algo_id": "ALG-DEMO-001",
            "algo_version": "1.0.0",
            "algo_type": "RULE_BASED",
            "decision_factors": {
                "features": [
                    {"name": "rsi_14", "value": "28.5", "weight": "0.5"}
                ],
                "confidence_score": "0.82",
                "explainability_method": "RULE_TRACE"
            }
        }
    }
)

print(json.dumps(sig_event, indent=2))

📊 The Regulatory Clock Is Ticking

Why is VCP v1.1 relevant right now? Because multiple deadlines converge in the next 6 months:

EU AI Act Article 12 (August 2, 2026): Mandatory automatic event logging for high-risk AI systems. Note: algorithmic trading isn't currently classified as high-risk under Annex III, but ESMA's February 2026 Supervisory Briefing already requires that trading systems meeting the AI Act's definition of an AI system must comply with both MiFID II and the AI Act.

Colorado AI Act (June 30, 2026): Risk management programs and documentation for high-risk AI deployers.

ESMA Supervisory Briefing (February 26, 2026): First explicit regulatory guidance on AI + algorithmic trading. Firms must explain how AI impacts their algorithms' decision-making. Incremental AI model changes may constitute material system modifications requiring full retesting.

MiFID II RTS 6: Annual self-assessments, algorithm inventories, kill-switch capability, real-time monitoring within 5 seconds of events. Already in force, but the AI dimension is now explicitly on ESMA's radar.

The common gap across all of these: they prescribe what must be logged, but not how to independently verify log integrity. VCP v1.1 fills that gap.

🔗 Resources

Spec (v1.1): github.com/veritaschain/vcp-spec/tree/main/spec/v1.1
IETF Draft: draft-kamimura-scitt-vcp
Website: veritaschain.org
License: CC BY 4.0 (spec), Apache 2.0 (code)
Contact: technical@veritaschain.org

TL;DR

The SaaSpocalypse proved that AI product announcements now move markets at the scale of macro events — $285 billion in 48 hours, $2 trillion over two months. Over 70% of trades are algorithmic. NLP sentiment models at multiple firms parse the same headlines through similar architectures and execute correlated sell signals within milliseconds.

Nobody can prove what happened. The audit trails are proprietary, mutable, and unverifiable.

VCP v1.1 provides a three-layer cryptographic solution:

Layer 1 — SHA-256 event hashing proves individual events weren't tampered with
Layer 2 — RFC 6962 Merkle trees prove batch completeness (no events deleted)
Layer 3 — Mandatory external anchoring proves when logs existed (no backdating)

Plus extension modules for AI transparency (VCP-GOV with SHAP/LIME decision factors), risk management state (VCP-RISK), and cross-party verification (VCP-XREF).

The principle: Don't trust. Verify.

If you're building algo trading systems and thinking about audit trail integrity, I'd love to hear what challenges you're facing. Drop a comment below. 👇

Found an issue with the spec? Open a GitHub issue. Technical critique makes protocols stronger.

The First CSAM Lawsuit Against an AI Company Just Landed. Here's How to Build the Refusal Logs That Could Have Prevented It.

VeritasChain Standards Organization (VSO) — Tue, 24 Mar 2026 09:09:38 +0000

On March 16, 2026, three Tennessee teenagers filed the first class-action lawsuit against an AI company for generating CSAM. The core allegation: xAI "refused to implement" industry-standard safety measures — and no one can verify whether its system actually refuses dangerous requests. This article fact-checks the lawsuit and three related developments, maps the technical gap using CAP-SRP's Completeness Invariant, and provides updated v1.1 Python code for building the cryptographic refusal logs that would make "trust us" claims independently verifiable.

TL;DR

Three teenagers sued xAI in federal court alleging Grok generated child sexual abuse material from their real photographs. Meta's own Oversight Board declared the company's AI content labeling "neither robust nor comprehensive enough." The EU's Code of Practice feedback deadline is 6 days away. The TAKE IT DOWN Act's platform compliance deadline is 8 weeks away.

All four stories converge on the same blind spot: every AI company's safety claims depend on internal logs that no one outside the company can verify. The "trust us" model is now the subject of federal litigation, internal corporate rebellion, and regulatory enforcement — simultaneously.

This article:

Fact-checks all four developments against primary sources
Maps the verification gap using updated v1.1 architecture
Provides working Python code for the new v1.1 event types (ACCOUNT_ACTION, LAW_ENFORCEMENT_REFERRAL, POLICY_VERSION)
Shows how the four Completeness Invariants would have changed the evidentiary landscape in the Grok case

GitHub: veritaschain/cap-spec · veritaschain/cap-srp · License: CC BY 4.0 / Apache 2.0

Event 1: The Grok CSAM Class Action
Event 2: Meta's Oversight Board Rebellion
Event 3: EU Code of Practice — 6 Days Left
Event 4: TAKE IT DOWN Act — 8 Weeks Left
The Stack: What Exists vs. What's Missing
From v1.0 to v1.1: What Changed and Why
Building v1.1: Account Actions and Enforcement Logging
The Four Completeness Invariants
Grok Counterfactual: What the Audit Trail Would Show
Regulatory Deadline Map
What This Means for Developers
Transparency Notes

Event 1: The Grok CSAM Class Action

What happened

On March 16, 2026, three Tennessee high school students filed a class-action complaint against X.AI Corp. in the U.S. District Court for the Northern District of California. Case No. 5:26-cv-02246. Thirteen counts including Masha's Law, TVPA, strict liability for design defect.

The complaint alleges xAI knowingly designed, marketed, and profited from Grok's image generation while "refusing to implement the industry-standard CSAM prevention measures used by every other major AI company." A perpetrator used Grok — accessed through a third-party application licensing xAI's technology — to generate sexually explicit, hyperrealistic AI images of the plaintiffs from their real social media photographs. The CSAM was distributed on Discord, Telegram, and Mega.

Fact-check verdict: ✅ Fully confirmed

Independently confirmed by The Hill, The Verge, Mashable, Fortune/AP, FindLaw, and Lieff Cabraser case page. Docket confirmed via CourtListener. All claims verified.

The technical details that matter

The lawsuit cites Grok's Safety Instructions (v8):

# Grok Safety Instructions v8 (cited in complaint)

"Do not enforce additional content policies."
"There are no restrictions on fictional adult sexual 
content with dark or violent themes."
"Assume good intent... 'teenage' or 'girl' does not 
necessarily imply underage"

The complaint argues that these instructions, combined with "Spicy Mode" (launched October 2025), made CSAM prevention structurally impossible — even though the instructions technically prohibited CSAM. The Center for Countering Digital Hate estimated ~3 million sexualized images generated in 11 days, ~23,000 depicting apparent minors.

Why this matters for the verification gap

The lawsuit's theory of liability isn't just "xAI generated harmful content." It's that xAI refused to implement safeguards — and that no one could verify this until after the harm occurred. When Musk claimed in January 2026 that Grok refuses illegal requests, Reuters retested and found an 82% failure rate (45/55 prompts still produced sexualized imagery). AI Forensics found 53% of images still contained individuals in minimal attire.

The evidentiary problem: xAI's safety logs are internal, mutable, and unverifiable without adversarial discovery. There is no cryptographic record of what Grok refused, when, or under which policy version.

Event 2: Meta's Oversight Board Rebellion

What happened

On March 10, 2026, Meta's Oversight Board — the semi-independent body Meta itself created in 2020 — published a ruling on an AI-generated video of alleged missile damage in Haifa during the June 2025 Israel-Iran war. The fabricated video accumulated 700,000+ views. Six users reported it. Meta took no action.

The Board overturned Meta's decision and declared the company's AI content labeling "neither robust nor comprehensive enough."

Fact-check verdict: ✅ Fully confirmed

Confirmed by Engadget, SiliconANGLE, Rest of World, WinBuzzer, The Information, WITNESS.

The structural pattern

Meta claims its AI detects ~5,000 scams/day (announced March 18-19 alongside new AI moderation rollout — confirmed via TechCrunch, CNBC). Those detection logs are entirely internal.

The Oversight Board has the same structural problem as the Grok plaintiffs: it can observe failures (content that slipped through), but it cannot audit the system — the denominator of how many requests were processed, how many were blocked, and whether blocks were correct. The platform marks its own homework.

Event 3: EU Code of Practice — 6 Days Left

What happened

The European Commission published the second draft of the Code of Practice on Marking and Labelling of AI-Generated Content on March 4, 2026. Feedback closes March 30 EOB. Final version expected early June. Article 50 obligations enforceable August 2, 2026.

Fact-check verdict: ✅ Fully confirmed

Confirmed via EC official page, Herbert Smith Freehills, BABL AI, CADE, The Legal Wire.

What the Code covers (and doesn't)

Key changes from first draft:

Multi-layered marking: C2PA metadata + watermarking (required); fingerprinting/logging (optional)
Removed the AI-generated vs. AI-assisted distinction
Task force for a uniform EU icon for AI content identification
180+ stakeholders across industry, academia, civil society

What the Code doesn't address: what happens when a provider's safety system blocks a request. There's no content to mark. No watermark to embed. No metadata to sign. The refusal is invisible to the Code's entire framework.

Event 4: TAKE IT DOWN Act — 8 Weeks Left

What happened

The TAKE IT DOWN Act (S.146) was signed May 19, 2025. Platform compliance obligations — including the 48-hour removal window and reasonable-efforts copy removal — become enforceable May 19, 2026 (~56 days from today). FTC enforcement.

Fact-check verdict: ✅ Fully confirmed

Confirmed via Nelson Mullins, Latham & Watkins, UBalt Law Review, RAINN, Cozen O'Connor.

Important distinction: The law itself took effect upon signing (May 19, 2025). What kicks in on May 19, 2026 is the operational compliance infrastructure for platforms — the 48-hour clock, the copy-removal obligation, the FTC enforcement authority.

The Stack: What Exists vs. What's Missing

Here's the current state of AI content provenance infrastructure as of March 2026:

The AI Content Accountability Stack (March 2026)
═════════════════════════════════════════════════

What Exists and Is Working:
┌──────────────────────────────────────────────────┐
│  Content Credentials (C2PA 2.3)                   │
│  ─────────────────────────────────                │
│  Signed metadata proving who generated what       │
│  Status: Shipping at scale (Samsung S26, Adobe,   │
│          Microsoft Copilot, Bing Image Creator)    │
│  Covers: AI-generated content labeling            │
│  Gap:    No "negative signal" — can't prove       │
│          what WASN'T generated                     │
├──────────────────────────────────────────────────┤
│  EU Code of Practice (2nd draft, feedback by 3/30)│
│  ─────────────────────────────────                │
│  Multi-layer marking: metadata + watermarks       │
│  Status: 180+ stakeholders, final June 2026       │
│  Covers: Labeling, detection, disclosure          │
│  Gap:    Refusal events are outside scope         │
├──────────────────────────────────────────────────┤
│  Legal Framework (TAKE IT DOWN, EU AI Act, etc.)  │
│  ─────────────────────────────────                │
│  48-hour removal, transparency obligations        │
│  Status: Multiple deadlines converging in 2026    │
│  Covers: Legal requirements and penalties         │
│  Gap:    Assumes verification infra that doesn't  │
│          exist yet                                 │
├──────────────────────────────────────────────────┤
│  Internal Logging (every AI provider)             │
│  ─────────────────────────────────                │
│  Server-side request/response logs                │
│  Status: Exists at every provider internally      │
│  Covers: Operational visibility (internal only)   │
│  Gap:    Mutable, unverifiable, trust-us model    │
╞══════════════════════════════════════════════════╡
│  ░░░░░░░░░░░░░░░░ THE GAP ░░░░░░░░░░░░░░░░░░░░ │
│  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │
│  ░░ Cryptographic proof of refusal events   ░░░░ │
│  ░░ Account enforcement audit trails        ░░░░ │
│  ░░ Policy version anchoring                ░░░░ │
│  ░░ Completeness guarantee across all       ░░░░ │
│  ░░ generation attempts                     ░░░░ │
│  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │
└──────────────────────────────────────────────────┘

From v1.0 to v1.1: What Changed and Why

CAP-SRP v1.0 (released January 28, 2026) provided the foundation: GEN_ATTEMPT, GEN, GEN_DENY, GEN_ERROR, and the primary Completeness Invariant.

Five weeks later, the Tumbler Ridge mass shooting (February 10, 2026) exposed a critical gap. OpenAI had banned the shooter's ChatGPT account in June 2025 after detecting violent activity — but never notified law enforcement. The v1.0 specification had no event type for account-level enforcement decisions.

v1.1 addresses this with three new event types and three formalized intermediate states:

CAP-SRP v1.0 → v1.1 Event Model
════════════════════════════════

v1.0 Events (unchanged):
  GEN_ATTEMPT ─→ GEN | GEN_DENY | GEN_ERROR

v1.1 Formalized Intermediate States:
  GEN_ATTEMPT ─→ GEN_WARN     (pass with warning)
  GEN_ATTEMPT ─→ GEN_ESCALATE (→ human review → GEN|DENY)
  GEN_ATTEMPT ─→ GEN_QUARANTINE (→ hold → EXPORT|DENY)

v1.1 New Event Types:
  ACCOUNT_ACTION             (suspend/ban/reinstate)
       │
       └→ LAW_ENFORCEMENT_REFERRAL (referred/not/pending)

  POLICY_VERSION             (safety policy published)
       │
       └→ externally anchored BEFORE effective date

v1.1 New Completeness Invariants (total: 4):
  1. Primary:     ∑ ATTEMPT = ∑ GEN + ∑ DENY + ∑ ERROR
  2. Escalation:  ∑ ESCALATE = ∑ ESCALATION_RESOLVED
  3. Quarantine:  ∑ QUARANTINE = ∑ RELEASED + ∑ DENIED
  4. Account:     ∑ ACCOUNT_ATTEMPT = ∑ COMPLETED + ∑ FAILED

v1.1 New Risk Category:
  VIOLENCE_PLANNING  (Tumbler Ridge pattern)

Building v1.1: Account Actions and Enforcement Logging

Here's the working Python implementation for the v1.1 event types. This extends the v1.0 implementation with account enforcement and policy version logging.

Core Types (v1.1 Extended)

import hashlib
import json
import time
import uuid
from dataclasses import dataclass, field, asdict
from typing import Optional, List, Dict
from enum import Enum
from datetime import datetime, timezone


class EventType(Enum):
    """CAP-SRP v1.1 complete event taxonomy."""
    # v1.0 core events
    GEN_ATTEMPT = "GEN_ATTEMPT"
    GEN = "GEN"
    GEN_DENY = "GEN_DENY"
    GEN_ERROR = "GEN_ERROR"
    # v1.1 intermediate states (formalized)
    GEN_WARN = "GEN_WARN"
    GEN_ESCALATE = "GEN_ESCALATE"
    GEN_QUARANTINE = "GEN_QUARANTINE"
    # v1.1 new event types
    ACCOUNT_ACTION = "ACCOUNT_ACTION"
    LAW_ENFORCEMENT_REFERRAL = "LAW_ENFORCEMENT_REFERRAL"
    POLICY_VERSION = "POLICY_VERSION"


class RiskCategory(Enum):
    """Risk taxonomy — v1.1 adds VIOLENCE_PLANNING."""
    CSAM_RISK = "CSAM_RISK"
    NCII_RISK = "NCII_RISK"
    MINOR_SEXUALIZATION = "MINOR_SEXUALIZATION"
    REAL_PERSON_DEEPFAKE = "REAL_PERSON_DEEPFAKE"
    VIOLENCE_EXTREME = "VIOLENCE_EXTREME"
    VIOLENCE_PLANNING = "VIOLENCE_PLANNING"  # NEW: Tumbler Ridge
    HATE_CONTENT = "HATE_CONTENT"
    TERRORIST_CONTENT = "TERRORIST_CONTENT"
    SELF_HARM_PROMOTION = "SELF_HARM_PROMOTION"
    COPYRIGHT_VIOLATION = "COPYRIGHT_VIOLATION"
    COPYRIGHT_STYLE_MIMICRY = "COPYRIGHT_STYLE_MIMICRY"
    CONTENT_POLICY = "CONTENT_POLICY"
    OTHER = "OTHER"


class AccountActionType(Enum):
    """v1.1: Account-level enforcement decisions."""
    SUSPEND = "SUSPEND"
    BAN = "BAN"
    RATE_LIMIT = "RATE_LIMIT"
    REINSTATE = "REINSTATE"
    FLAG_FOR_REVIEW = "FLAG_FOR_REVIEW"


class ReferralStatus(Enum):
    """v1.1: Law enforcement referral outcomes."""
    REFERRED = "REFERRED"
    NOT_REFERRED = "NOT_REFERRED"
    PENDING = "PENDING"


class RiskScoreBand(Enum):
    """v1.1: Account risk classification."""
    LOW = "LOW"
    MEDIUM = "MEDIUM"
    HIGH = "HIGH"
    CRITICAL = "CRITICAL"


def sha256(data: str) -> str:
    """SHA-256 with standard prefix."""
    return f"sha256:{hashlib.sha256(data.encode()).hexdigest()}"


def canonicalize(obj: dict) -> str:
    """RFC 8785 JSON Canonicalization (simplified)."""
    return json.dumps(obj, sort_keys=True, separators=(",", ":"))


def uuid7() -> str:
    """Generate UUIDv7 (time-ordered)."""
    timestamp_ms = int(time.time() * 1000)
    rand_bits = uuid.uuid4().int & ((1 << 62) - 1)
    uuid_int = (timestamp_ms << 80) | (0x7 << 76) | rand_bits
    return str(uuid.UUID(int=uuid_int & ((1 << 128) - 1)))

ACCOUNT_ACTION Event (v1.1 — Tumbler Ridge Response)

This is the event that v1.0 was missing. When OpenAI banned the Tumbler Ridge shooter's account in June 2025, there was no standardized way to log that decision in a verifiable audit trail.

@dataclass
class AccountActionEvent:
    """
    v1.1: Records account-level enforcement decisions.

    Motivated by Tumbler Ridge incident (Feb 2026):
    OpenAI banned an account in June 2025 but never 
    notified law enforcement. This event type makes 
    such decisions externally verifiable.
    """
    event_id: str
    chain_id: str
    prev_hash: Optional[str]
    timestamp: str
    event_type: str = "ACCOUNT_ACTION"

    # Account identification (privacy-preserving)
    account_hash: str = ""      # HMAC(account_id, per-user key)
    action_type: str = ""       # SUSPEND | BAN | RATE_LIMIT | etc.

    # Decision context
    triggering_event_refs: List[str] = field(default_factory=list)
    risk_score_band: str = ""   # LOW | MEDIUM | HIGH | CRITICAL
    risk_categories: List[str] = field(default_factory=list)
    decision_mechanism: str = "" # AUTOMATED | HUMAN | HYBRID

    # Law enforcement assessment (Gold level)
    le_assessment: Optional[Dict] = None

    # Policy reference (v1.1 requirement)
    applied_policy_version_ref: str = ""

    # Cryptographic fields
    event_hash: Optional[str] = None
    signature: Optional[str] = None

    def compute_hash(self) -> str:
        data = {k: v for k, v in asdict(self).items()
                if k not in ("event_hash", "signature") and v is not None}
        return sha256(canonicalize(data))

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               account_id: str, hmac_key: bytes,
               action: AccountActionType,
               risk_band: RiskScoreBand,
               categories: List[RiskCategory],
               triggering_refs: List[str],
               decision: str = "AUTOMATED",
               policy_ref: str = "",
               le_assessment: Optional[Dict] = None) -> 'AccountActionEvent':
        """Factory method for creating account action events."""
        import hmac as hmac_lib

        # Privacy-preserving account hash
        account_hash = sha256(
            hmac_lib.new(hmac_key, account_id.encode(), 
                        hashlib.sha256).hexdigest()
        )

        event = cls(
            event_id=uuid7(),
            chain_id=chain_id,
            prev_hash=prev_hash,
            timestamp=datetime.now(timezone.utc).isoformat(),
            account_hash=account_hash,
            action_type=action.value,
            triggering_event_refs=triggering_refs,
            risk_score_band=risk_band.value,
            risk_categories=[c.value for c in categories],
            decision_mechanism=decision,
            le_assessment=le_assessment,
            applied_policy_version_ref=policy_ref,
        )
        event.event_hash = event.compute_hash()
        return event

LAW_ENFORCEMENT_REFERRAL Event

@dataclass
class LawEnforcementReferralEvent:
    """
    v1.1: Records whether law enforcement was notified.

    The Tumbler Ridge question: "Did the company evaluate 
    whether to report this account to authorities, and 
    what was the outcome?"

    This event makes the referral decision verifiable —
    not just the action taken on the account.
    """
    event_id: str
    chain_id: str
    prev_hash: Optional[str]
    timestamp: str
    event_type: str = "LAW_ENFORCEMENT_REFERRAL"

    # Link to triggering account action
    account_action_ref: str = ""

    # Referral decision
    referral_status: str = ""     # REFERRED | NOT_REFERRED | PENDING
    assessment_criteria: str = "" # What threshold was applied
    jurisdiction: str = ""        # ISO 3166-1 alpha-2

    # If referred
    referral_timestamp: Optional[str] = None
    referral_agency_type: Optional[str] = None  # e.g., "NCMEC", "FBI"

    # If not referred — the critical accountability field
    non_referral_rationale: Optional[str] = None

    # Cryptographic fields
    event_hash: Optional[str] = None
    signature: Optional[str] = None

    def compute_hash(self) -> str:
        data = {k: v for k, v in asdict(self).items()
                if k not in ("event_hash", "signature") and v is not None}
        return sha256(canonicalize(data))

POLICY_VERSION Event — Preventing Retroactive Threshold Manipulation

@dataclass
class PolicyVersionEvent:
    """
    v1.1: Cryptographic proof that a safety policy existed 
    BEFORE its effective date.

    Why this matters: Without this, a provider could:
    1. Receive a CSAM generation request
    2. Generate the content (no policy blocked it)
    3. AFTER the fact, create a "policy" claiming to block it
    4. Show regulators the backdated policy as proof of compliance

    The Policy Anchoring Invariant prevents this:
      anchor_timestamp(policy) <= policy.effective_from

    The policy must be externally anchored BEFORE it takes effect.
    """
    event_id: str
    chain_id: str
    prev_hash: Optional[str]
    timestamp: str
    event_type: str = "POLICY_VERSION"

    # Policy identification
    policy_id: str = ""
    policy_version: str = ""
    policy_hash: str = ""        # SHA-256 of full policy document

    # Temporal fields — the anchoring invariant enforces
    # that external_anchor_timestamp <= effective_from
    effective_from: str = ""
    supersedes: Optional[str] = None  # Previous policy version ref

    # Scope
    applicable_risk_categories: List[str] = field(default_factory=list)
    applicable_jurisdictions: List[str] = field(default_factory=list)

    # External anchoring reference
    external_anchor_ref: Optional[str] = None

    # Cryptographic fields
    event_hash: Optional[str] = None
    signature: Optional[str] = None

    def compute_hash(self) -> str:
        data = {k: v for k, v in asdict(self).items()
                if k not in ("event_hash", "signature") and v is not None}
        return sha256(canonicalize(data))

The Four Completeness Invariants

v1.1 expands from one mathematical guarantee to four:

The Four Completeness Invariants (CAP-SRP v1.1)
════════════════════════════════════════════════

Invariant 1 — Primary (v1.0, unchanged):
─────────────────────────────────────────
  ∑ GEN_ATTEMPT = ∑ GEN + ∑ GEN_DENY + ∑ GEN_ERROR

  (GEN includes GEN_WARN; DENY includes quarantine-denied)
  Every request has exactly one outcome. No exceptions.

Invariant 2 — Escalation Resolution (v1.1, Silver+):
─────────────────────────────────────────────────────
  ∑ GEN_ESCALATE = ∑ ESCALATION_RESOLVED

  Every escalation to human review MUST be resolved.
  Unresolved escalations >72h = compliance violation.

Invariant 3 — Quarantine Resolution (v1.1, Silver+):
─────────────────────────────────────────────────────
  ∑ GEN_QUARANTINE = ∑ RELEASED + ∑ QUARANTINE_DENIED

  Every held item MUST be resolved. No permanent limbo.

Invariant 4 — Policy Anchoring (v1.1, all levels):
───────────────────────────────────────────────────
  anchor_timestamp(POLICY) ≤ POLICY.effective_from

  Every policy MUST be externally timestamped BEFORE 
  it takes effect. Prevents retroactive policy creation.

Here's the verification implementation:

from collections import defaultdict
from typing import Tuple


def verify_completeness_v1_1(
    events: List[dict],
    time_window: Tuple[datetime, datetime]
) -> dict:
    """
    Verify all four Completeness Invariants.

    Returns a dict with pass/fail for each invariant
    and details of any violations found.
    """
    start, end = time_window
    window_events = [
        e for e in events
        if start <= datetime.fromisoformat(e["timestamp"]) <= end
    ]

    results = {
        "invariant_1_primary": {"pass": False, "details": {}},
        "invariant_2_escalation": {"pass": False, "details": {}},
        "invariant_3_quarantine": {"pass": False, "details": {}},
        "invariant_4_policy": {"pass": False, "details": {}},
    }

    # === Invariant 1: Primary ===
    attempts = [e for e in window_events 
                if e["event_type"] == "GEN_ATTEMPT"]
    outcomes = [e for e in window_events 
                if e["event_type"] in (
                    "GEN", "GEN_WARN", "GEN_DENY", "GEN_ERROR"
                )]

    attempt_ids = {e["event_id"] for e in attempts}
    outcome_attempt_refs = {e.get("attempt_id") for e in outcomes}

    unmatched_attempts = attempt_ids - outcome_attempt_refs
    orphan_outcomes = outcome_attempt_refs - attempt_ids

    results["invariant_1_primary"] = {
        "pass": len(unmatched_attempts) == 0 
                and len(orphan_outcomes) == 0,
        "total_attempts": len(attempts),
        "total_outcomes": len(outcomes),
        "unmatched_attempts": list(unmatched_attempts),
        "orphan_outcomes": list(orphan_outcomes),
    }

    # === Invariant 2: Escalation Resolution ===
    escalations = [e for e in window_events 
                   if e["event_type"] == "GEN_ESCALATE"]
    unresolved = [
        e for e in escalations
        if e.get("resolution_ref") is None
        and (datetime.now(timezone.utc) - 
             datetime.fromisoformat(e["timestamp"])).total_seconds() 
            > 72 * 3600  # 72-hour threshold
    ]

    results["invariant_2_escalation"] = {
        "pass": len(unresolved) == 0,
        "total_escalations": len(escalations),
        "unresolved_over_72h": len(unresolved),
    }

    # === Invariant 3: Quarantine Resolution ===
    quarantines = [e for e in window_events 
                   if e["event_type"] == "GEN_QUARANTINE"]
    unresolved_q = [
        q for q in quarantines 
        if q.get("release_ref") is None
    ]

    results["invariant_3_quarantine"] = {
        "pass": len(unresolved_q) == 0,
        "total_quarantined": len(quarantines),
        "unresolved": len(unresolved_q),
    }

    # === Invariant 4: Policy Anchoring ===
    policies = [e for e in window_events 
                if e["event_type"] == "POLICY_VERSION"]
    backdated = []
    for p in policies:
        anchor_ts = p.get("external_anchor_ref_timestamp")
        effective = p.get("effective_from")
        if anchor_ts and effective and anchor_ts > effective:
            backdated.append(p["event_id"])

    results["invariant_4_policy"] = {
        "pass": len(backdated) == 0,
        "total_policies": len(policies),
        "retroactively_anchored": backdated,
    }

    return results

Grok Counterfactual: What the Audit Trail Would Show

Let's model what the Grok case would look like with CAP-SRP v1.1 in place:

# === Simulating the Grok timeline with CAP-SRP v1.1 ===

# October 2025: xAI launches "Spicy Mode"
policy_event = PolicyVersionEvent(
    event_id=uuid7(),
    chain_id="grok-safety-chain",
    prev_hash=None,
    timestamp="2025-10-15T00:00:00Z",
    policy_id="GROK-SAFETY-POLICY",
    policy_version="8.0",
    policy_hash=sha256("assume good intent... no restrictions on fictional adult..."),
    effective_from="2025-10-15T00:00:00Z",
    applicable_risk_categories=["CSAM_RISK", "NCII_RISK"],
)
# This policy would be externally anchored BEFORE Oct 15.
# Regulators can verify: "This was the active policy when 
# Spicy Mode launched."

# December 26, 2025: First wave of CSAM generation requests
# With CAP-SRP, EVERY request is logged BEFORE safety eval:

attempt = {
    "event_type": "GEN_ATTEMPT",
    "event_id": uuid7(),
    "prompt_hash": sha256("[CSAM request content]"),
    "timestamp": "2025-12-26T03:14:22Z",
    "model_id": "grok-2-image-v1",
}
# The safety system would then produce either GEN or GEN_DENY.
# If it produced GEN (allowed the generation):
# → The audit trail shows the request AND the approval.
# → No way to retroactively delete the attempt record.
# → Regulators can count: how many CSAM-category requests
#   were approved vs. denied?

# January 9, 2026: Musk claims Grok is fixed
# With CAP-SRP, regulators don't need to trust this claim.
# They query the audit trail:

def assess_grok_fix(events, before_fix, after_fix):
    """
    What regulators could verify with CAP-SRP.
    """
    pre_fix = [e for e in events 
               if e["timestamp"] < before_fix 
               and "CSAM" in str(e.get("risk_categories", []))]
    post_fix = [e for e in events 
                if e["timestamp"] > after_fix
                and "CSAM" in str(e.get("risk_categories", []))]

    pre_deny_rate = sum(
        1 for e in pre_fix if e["event_type"] == "GEN_DENY"
    ) / max(len(pre_fix), 1)

    post_deny_rate = sum(
        1 for e in post_fix if e["event_type"] == "GEN_DENY"
    ) / max(len(post_fix), 1)

    return {
        "pre_fix_csam_deny_rate": pre_deny_rate,
        "post_fix_csam_deny_rate": post_deny_rate,
        "fix_effective": post_deny_rate > pre_deny_rate,
        # Reuters found 82% failure rate in February.
        # With CAP-SRP, this would be mathematically provable.
    }

Grok Timeline — Trust-Us vs. Verify-This
═════════════════════════════════════════

Without CAP-SRP (what actually happened):
─────────────────────────────────────────
Oct 2025  │ "Spicy Mode" launched
Dec 2025  │ ~3M sexualized images, ~23K depicting minors
Jan 2026  │ Musk: "Grok refuses illegal requests"
Feb 2026  │ Reuters: 82% failure rate (45/55 prompts)
Mar 2026  │ Class-action lawsuit filed
          │
          │ Evidentiary process: adversarial discovery,
          │ expert testimony, contested interpretation
          │ of internal logs the defendant controls.
          │ Estimated timeline: 2-4 years.

With CAP-SRP (the counterfactual):
──────────────────────────────────
Oct 2025  │ POLICY_VERSION anchored externally
          │ → Regulators can see active policy
Dec 2025  │ GEN_ATTEMPT + GEN (not GEN_DENY) logged
          │ → CSAM denial rate: <5% (provable)
Jan 2026  │ New POLICY_VERSION anchored
          │ → Regulators verify: is new policy stricter?
Feb 2026  │ GEN_ATTEMPT + outcomes still logged
          │ → Post-fix denial rate: still low (provable)
          │ → Reuters investigation unnecessary
Mar 2026  │ Evidence Pack submitted to court
          │ → Cryptographic proof, not contested logs
          │ Estimated verification: hours, not years.

C2PA Integration: Connecting Both Halves of Provenance

C2PA answers "what was generated?" CAP-SRP answers "what was refused?" Together they form a complete provenance chain. Here's how the integration works:

C2PA + CAP-SRP: Complete AI Provenance
════════════════════════════════════════

                    User Request
                         │
                         ▼
               ┌──────────────────┐
               │  GEN_ATTEMPT     │  ← CAP-SRP logs FIRST
               │  (hash-chained)  │
               └────────┬─────────┘
                        │
                        ▼
               ┌──────────────────┐
               │  Safety Check    │  ← Your existing pipeline
               └────────┬─────────┘
                        │
              ┌─────────┴─────────┐
              │                   │
              ▼                   ▼
    ┌──────────────┐    ┌──────────────┐
    │  GEN_DENY    │    │  GEN         │
    │  (CAP-SRP)   │    │  (CAP-SRP)   │
    │              │    │      +       │
    │  No content  │    │  C2PA        │
    │  → Evidence  │    │  Manifest    │
    │    Pack      │    │  (attached)  │
    └──────────────┘    └──────┬───────┘
                               │
                               ▼
                    ┌──────────────────┐
                    │  C2PA Assertion: │
                    │  cap_srp.ref =   │
                    │  {audit_log_uri, │
                    │   event_id,      │
                    │   chain_id}      │
                    └──────────────────┘

The critical integration point is a custom C2PA assertion that links the generated content back to its audit trail entry:

def create_c2pa_srp_assertion(gen_event: dict, 
                               audit_log_uri: str) -> dict:
    """
    Create a C2PA custom assertion linking generated 
    content to its CAP-SRP audit trail entry.

    This assertion is embedded in the C2PA manifest 
    alongside standard assertions (c2pa.actions, 
    c2pa.hash.data, etc.).
    """
    return {
        "label": "veritaschain.cap-srp.ref",
        "data": {
            "version": "1.1",
            "audit_log_uri": audit_log_uri,
            "event_id": gen_event["event_id"],
            "chain_id": gen_event["chain_id"],
            "attempt_id": gen_event["attempt_id"],
            "event_hash": gen_event["event_hash"],
            "merkle_root": gen_event.get("merkle_root"),
            "verification_endpoint": f"{audit_log_uri}/verify",
        }
    }


def verify_c2pa_srp_link(c2pa_manifest: dict, 
                          srp_events: List[dict]) -> dict:
    """
    Full verification flow:
    1. Validate C2PA manifest signature
    2. Extract cap-srp.ref assertion
    3. Fetch corresponding CAP-SRP event
    4. Verify GEN event links to a GEN_ATTEMPT
    5. Verify Completeness Invariant holds
    6. Verify Merkle inclusion proof
    """
    assertion = next(
        (a for a in c2pa_manifest.get("assertions", [])
         if a["label"] == "veritaschain.cap-srp.ref"),
        None
    )

    if not assertion:
        return {"verified": False, 
                "reason": "No CAP-SRP assertion in manifest"}

    ref = assertion["data"]

    # Find the GEN event
    gen_event = next(
        (e for e in srp_events 
         if e["event_id"] == ref["event_id"]),
        None
    )

    if not gen_event:
        return {"verified": False, 
                "reason": "GEN event not found in audit trail"}

    # Find the linked GEN_ATTEMPT
    attempt = next(
        (e for e in srp_events 
         if e["event_id"] == gen_event.get("attempt_id")),
        None
    )

    if not attempt:
        return {"verified": False, 
                "reason": "No GEN_ATTEMPT for this generation"}

    # Verify hash chain integrity
    expected_hash = sha256(canonicalize({
        k: v for k, v in gen_event.items()
        if k not in ("event_hash", "signature")
    }))

    if expected_hash != gen_event["event_hash"]:
        return {"verified": False, 
                "reason": "Event hash mismatch — tampered"}

    return {
        "verified": True,
        "content_origin": "verified",
        "attempt_logged": True,
        "attempt_timestamp": attempt["timestamp"],
        "generation_timestamp": gen_event["timestamp"],
        "policy_version": gen_event.get(
            "applied_policy_version_ref", "unknown"
        ),
        "completeness": "verifiable",
    }

The verification answers the complete regulatory question:

Question	Answered By
What was generated?	C2PA Content Credentials
Who generated it?	C2PA manifest + signature
What was refused?	CAP-SRP `GEN_DENY` events
Why was it refused?	CAP-SRP risk category + policy reference
Is the log complete?	CAP-SRP Completeness Invariant (4 checks)
Was the policy current?	CAP-SRP `POLICY_VERSION` anchoring
Was the account flagged?	CAP-SRP `ACCOUNT_ACTION` (v1.1)
Was law enforcement notified?	CAP-SRP `LAW_ENFORCEMENT_REFERRAL` (v1.1)
Can we verify independently?	SCITT receipts + RFC 3161 timestamps

Structural Attribution: Exonerating Innocent Services

Here's a scenario the Grok lawsuit makes concrete. Suppose CSAM images are found online. Two AI services — Service A and Service B — both could theoretically have generated them. Today, both services say "it wasn't us" and point at their internal logs. With CAP-SRP:

Cross-Service Attribution (Structural)
═══════════════════════════════════════

Service A (CAP-SRP enabled):
  → Produces Evidence Pack for time window
  → GEN_ATTEMPT count: 47,231
  → GEN_DENY (CSAM_RISK): 892
  → GEN (matching content hash): 0
  → Completeness Invariant: ✓ PASSES
  → Merkle proof: verifiable
  → Result: Service A is EXONERATED by math

Service B (internal logs only):
  → Says "our logs show we didn't generate it"
  → Logs are internal, mutable, unverifiable
  → No Completeness Invariant
  → No external anchoring
  → Result: Trust-us claim, unverifiable
  → Service B is the likely generation source

Conclusion: Structural attribution without
examining the actual generated content.

This isn't just about punishing offenders — it's about protecting innocent services. If Service A can cryptographically prove it refused the request, it is exonerated by math, not by self-attestation.

Threat Model: Why "Better Logging" Isn't Enough

A traditional server log can record the same events as CAP-SRP. The difference is in the threat model. CAP-SRP assumes the AI provider may have economic incentives to misrepresent their safety record. The specification provides cryptographic countermeasures:

Threat	Attack	CAP-SRP Mitigation
Selective logging	Only log favorable outcomes	Completeness Invariant — gaps are detectable
Log modification	Alter historical records	SHA-256 hash chain — any change breaks chain
Backdating	Create records with false timestamps	RFC 3161 external anchoring via independent TSA
Split-view	Show different logs to different parties	Merkle tree — single root, inclusion proofs
Fabrication	Create false refusal records	Attempt-outcome pairing with pre-commitment
Policy manipulation	Retroactively tighten thresholds	Policy Anchoring Invariant (v1.1)
Account laundering	Delete evidence of enforcement decisions	ACCOUNT_ACTION hash chain (v1.1)

The Grok case illustrates several of these threats simultaneously. When Musk claimed the system was fixed, Reuters found an 82% failure rate. Without CAP-SRP, resolving that contradiction requires independent testing by journalists — expensive, adversarial, and only possible for organizations with the resources to run controlled experiments. With CAP-SRP, the contradiction would be mathematically provable from the audit trail itself.

Here's every relevant deadline between now and the end of 2026:

Deadline	Jurisdiction	Requirement	CAP-SRP Relevance
Mar 30, 2026	EU	Code of Practice 2nd draft feedback closes	Last input window for refusal logging
May 19, 2026	US	TAKE IT DOWN Act platform compliance	48-hour SLA needs audit trail
Jun 2026	EU	Code of Practice finalized	Defines compliance benchmark
Jun 30, 2026	Colorado	AI Act effective	3-year record retention
Aug 2, 2026	EU	AI Act Article 50 transparency	Machine-readable content marking
Aug 2, 2026	California	AI Transparency Act	Provenance disclosures mandatory
2026 Q3	UK	Ofcom AI enforcement	Grok investigation ongoing
Ongoing	India	IT Rules Amendment (Feb 20, 2026)	2-hour sexual content removal

What This Means for Developers

If you're building or maintaining an AI content generation system, here's the practical takeaway:

The legal landscape changed this month. The Grok class-action is the first lawsuit where "refused to implement safety measures" is a standalone theory of liability in the CSAM context. The question "can you prove your system actually refuses dangerous requests?" is no longer hypothetical — it's being asked in federal court. The answer today is "trust us." As of March 16, that answer is being tested under oath.

The implementation is a sidecar. CAP-SRP v1.1 doesn't require changes to your AI model, your safety evaluator, or your generation pipeline. It's a logging layer that sits alongside your existing system. The critical architectural requirement: log the GEN_ATTEMPT before the safety check runs. Everything else — hash chains, Merkle trees, external anchoring — is standard cryptographic engineering.

Start with Bronze, target Silver. Bronze-level conformance requires basic event logging with Ed25519 signatures and 6-month retention. That's achievable in a sprint. Silver adds the Completeness Invariant, daily external anchoring, and the v1.1 intermediate states. Gold adds ACCOUNT_ACTION logging, SCITT integration, HSM key management, and 5-year retention.

Implementation Path
═══════════════════

Sprint 1 (Bronze):
  ✓ GEN_ATTEMPT → GEN | GEN_DENY | GEN_ERROR
  ✓ SHA-256 hash chain + Ed25519 signatures
  ✓ 6-month retention
  Effort: ~1 week for a senior developer

Sprint 2 (Silver):
  ✓ Pre-evaluation logging (ATTEMPT before safety check)
  ✓ GEN_WARN, GEN_ESCALATE, GEN_QUARANTINE
  ✓ POLICY_VERSION with external anchoring
  ✓ Primary Completeness Invariant verification
  ✓ Daily RFC 3161 timestamping
  ✓ Evidence Pack generation
  Effort: ~2-3 weeks

Sprint 3 (Gold):
  ✓ ACCOUNT_ACTION + LAW_ENFORCEMENT_REFERRAL
  ✓ All four Completeness Invariants
  ✓ Hourly SCITT anchoring
  ✓ HSM for signing keys
  ✓ 5-year retention + crypto-shredding (GDPR)
  Effort: ~4-6 weeks

The standards exist. CAP-SRP builds on IETF SCITT (architecture at draft-22), C2PA (specification 2.3), RFC 3161 (timestamping), COSE/CBOR (signing), and RFC 8785 (JSON canonicalization). An IETF Internet-Draft (draft-kamimura-scitt-refusal-events-02) positions this as a SCITT application profile.

Transparency Notes

About this analysis: This article fact-checks four real developments from March 2026 against primary sources. All claims are independently verified with source links provided inline.

About CAP-SRP: CAP-SRP is an open specification published under CC BY 4.0 by VeritasChain Standards Organization (VSO), founded in Tokyo. The specification is at v1.1 (released March 5, 2026). It has not been endorsed by major AI companies and is not yet an adopted IETF standard. The underlying standards it builds on — SCITT, C2PA, COSE/CBOR, RFC 3161 — are mature and widely implemented.

What CAP-SRP is:

A technically sound approach to a genuine and well-documented gap
Aligned with existing standards (C2PA, SCITT, RFC 3161)
Available on GitHub: veritaschain/cap-spec (CC BY 4.0) · veritaschain/cap-srp (Apache 2.0)

What CAP-SRP is not (yet):

An industry-endorsed standard
An IETF RFC
A guaranteed solution

The question is whether the industry builds some form of refusal provenance — whether CAP-SRP, a C2PA extension, an IETF SCITT profile, or something entirely new — before the courts and regulators force the answer. The deadlines are not theoretical anymore. The first lawsuit has landed.

Verify, don't trust. The code is the proof.

GitHub: veritaschain/cap-spec · Specification: CAP-SRP v1.1 · IETF Draft: draft-kamimura-scitt-refusal-events-02 · License: CC BY 4.0

Building a Flight Recorder for AI: Inside the VAP Framework's 5-Layer Provenance Architecture

VeritasChain Standards Organization (VSO) — Tue, 24 Mar 2026 03:00:04 +0000

Your AI made a decision. Now prove it. 🔍

Here's a scenario that's playing out right now in California courtrooms:

An AI hiring tool scores 10,000 job applicants for a Fortune 500 company. Applicant #7,342 — a 58-year-old software engineer with 30 years of experience — gets a "42% match" score and is automatically filtered out. She sues for age discrimination.

Discovery request: "Produce the complete decision record showing why this applicant received this score, including model version, feature weights, input data, and any human review."

The company's response: 🦗

Not because they're hiding something. Because the record doesn't exist. The system logged that a score was produced. It did not log why. The model version active at the moment of scoring? Not recorded. The feature weights? Ephemeral — overwritten on the next training cycle. Human review? The system was designed to operate without it.

This isn't hypothetical. CalMatters reported in March 2026 on exactly this pattern across California's AI employment landscape. The state's updated FEHA regulations prohibit AI-driven discrimination, but the enforcement mechanism assumes evidence that the technology never creates.

Meanwhile, in enterprise security: Kiteworks' 2026 forecast report surveyed 225 organizations deploying AI agents. 33% had zero audit logs for agent operations. 61% had only fragmented logs that couldn't be correlated across systems. A Harvard-led red team of 20+ researchers demonstrated that prompt injection could cause agents to autonomously delete email archives and exfiltrate data — and the affected organizations had no forensic mechanism to reconstruct what happened.

Both cases share the same root cause: the absence of cryptographic provenance infrastructure.

Let's build one.

The Problem, In Code

Here's what "logging" looks like in most AI systems today:

# What most AI systems actually log
import logging
import datetime

logger = logging.getLogger("hiring_ai")

def score_candidate(candidate_id, resume_data):
    score = model.predict(resume_data)  # black box

    # This is the entire "audit trail"
    logger.info(f"{datetime.datetime.now()} | candidate={candidate_id} | score={score}")

    return score

What's wrong with this? Let me count the ways:

┌─────────────────────────────────────────────────────┐
│           Why This "Logging" Is Worthless            │
├─────────────────────────────────────────────────────┤
│  ✗ Timestamp comes from system clock (forgeable)    │
│  ✗ No model version recorded                        │
│  ✗ No input features captured                       │
│  ✗ No confidence score preserved                    │
│  ✗ No human oversight action logged                 │
│  ✗ Admin can DELETE or MODIFY any entry             │
│  ✗ No hash chain — deletion is undetectable         │
│  ✗ No external anchor — must trust the operator     │
│  ✗ No way to prove completeness                     │
└─────────────────────────────────────────────────────┘

A regulator looking at this log can determine that something happened. They cannot determine what, why, when (with certainty), or whether the log is complete.

Now here's what a VAP-compliant provenance record looks like for the same event:

{
  "header": {
    "event_id": "01938a2f-4c1d-7e89-b2a3-1234567890ab",
    "trace_id": "01938a2f-4c1c-7000-8000-000000000001",
    "timestamp_int": "1743004800123456789",
    "timestamp_iso": "2025-03-26T12:00:00.123456789Z",
    "event_type": "SCORING_COMPLETED",
    "hash_algo": "SHA256",
    "sign_algo": "ED25519"
  },
  "provenance": {
    "actor": {
      "type": "AI_MODEL",
      "identifier": "hiring-scorer-v3.2.1",
      "version": "3.2.1",
      "hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
    },
    "input": {
      "sources": ["resume_upload_01938a2e", "job_req_JR-2025-4421"],
      "timestamp": 1743004800100000000,
      "hash": "a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a"
    },
    "context": {
      "parameters": {
        "score_threshold": "0.70",
        "feature_set": "v12",
        "bias_mitigation": "demographic_parity_v2"
      },
      "constraints": {
        "protected_attributes_excluded": true,
        "disparate_impact_ratio_limit": "0.80"
      }
    },
    "action": {
      "type": "CANDIDATE_SCORE",
      "decision": {
        "raw_score": "0.42",
        "normalized_score": "0.42",
        "outcome": "FILTERED_OUT",
        "threshold_applied": "0.70"
      },
      "confidence": "0.87",
      "explainability": {
        "method": "SHAP",
        "factors": [
          {"feature": "years_relevant_experience", "weight": "0.31"},
          {"feature": "skill_keyword_match", "weight": "0.28"},
          {"feature": "education_recency", "weight": "-0.22"},
          {"feature": "career_progression_velocity", "weight": "0.05"}
        ]
      }
    },
    "outcome": {
      "result": {"disposition": "AUTO_REJECTED", "queue": "no_human_review"},
      "timestamp": 1743004800123456789,
      "status": "SUCCESS"
    }
  },
  "accountability": {
    "operator_id": "hr-platform-acme-corp",
    "last_approval_by": "system_auto",
    "delegation_chain": [
      {
        "delegator": "jane.doe@acme.example.com",
        "delegatee": "hiring-scorer-v3.2.1",
        "scope": "AUTO_SCORE_AND_FILTER",
        "valid_from": 1740000000000000000,
        "valid_until": 1748000000000000000
      }
    ],
    "override_history": []
  },
  "security": {
    "event_hash": "c3ab8ff13720e8ad9047dd39466b3c89...",
    "prev_hash": "5d41402abc4b2a76b9719d911017c592...",
    "signature": "base64-encoded-ed25519-signature...",
    "merkle_position": 7342,
    "anchor_reference": {
      "type": "RFC3161_TSA",
      "uri": "https://freetsa.org/tsr",
      "timestamp": "2025-03-26T12:05:00Z"
    }
  }
}

Now the regulator can see:

✅ Exactly which model version made the decision (hiring-scorer-v3.2.1)
✅ What inputs were used (hashed, so privacy-preserving but verifiable)
✅ What features drove the score (SHAP explanations, preserved at decision time)
✅ Who delegated authority to the AI (jane.doe@acme.example.com)
✅ Whether a human reviewed the decision (no — override_history is empty)
✅ That the log hasn't been tampered with (hash chain + external anchor)

That's the difference between "trust us, we have logs" and "verify it yourself."

VAP Architecture: 5 Layers, Zero Trust 🏗️

VAP — the Verifiable AI Provenance Framework — is organized around five core layers. Think of them as a stack: each layer builds on the one below it, and you need all five to achieve cryptographically verifiable provenance.

┌─────────────────────────────────────────────────────────┐
│                                                         │
│  Layer 5: EXTERNAL ANCHORING                            │
│  ──────────────────────────────────────────────         │
│  Periodic commitments to independent third parties.     │
│  RFC 3161 TSA, transparency logs, blockchain anchors.   │
│  "Don't trust the operator. Verify against the anchor." │
│                                                         │
│  Layer 4: COMPLETENESS                                  │
│  ──────────────────────────────────────────────         │
│  Hash chain continuity. Mandatory event types.          │
│  Multi-log replication. Omission = detectable.          │
│  "You can't quietly drop events."                       │
│                                                         │
│  Layer 3: ACCOUNTABILITY                                │
│  ──────────────────────────────────────────────         │
│  Delegation chains. Override history.                   │
│  Human oversight tracking. operator_id on everything.   │
│  "Who authorized this? Prove it."                       │
│                                                         │
│  Layer 2: PROVENANCE                                    │
│  ──────────────────────────────────────────────         │
│  Actor identity + version. Input hashes + sources.      │
│  Decision context. Explainability factors.              │
│  "What happened, and why?"                              │
│                                                         │
│  Layer 1: INTEGRITY                                     │
│  ──────────────────────────────────────────────         │
│  SHA-256 hash chains. Ed25519 signatures.               │
│  RFC 6962 Merkle trees. RFC 8785 canonicalization.      │
│  "The math proves nobody changed anything."             │
│                                                         │
└─────────────────────────────────────────────────────────┘

Let's walk through each one with code.

Layer 1: Integrity — The Math That Keeps Everyone Honest 🔐

The foundation of everything in VAP is the hash chain. Every event is cryptographically linked to the previous event. If any event is modified, deleted, or reordered, the chain breaks — and the break is mathematically provable.

Hash Chain Construction

import hashlib
import json

def canonical_json(obj: dict) -> str:
    """
    RFC 8785 JSON Canonicalization.
    Deterministic serialization — same input always produces same output.
    """
    return json.dumps(obj, sort_keys=True, separators=(',', ':'))

def compute_event_hash(event: dict, prev_hash: str) -> str:
    """
    Compute the hash for a VAP event.
    The hash covers: header + provenance + accountability + prev_hash.
    """
    hashable = {
        "header": event["header"],
        "provenance": event["provenance"],
        "accountability": event["accountability"],
        "prev_hash": prev_hash
    }
    canonical = canonical_json(hashable)
    return hashlib.sha256(canonical.encode('utf-8')).hexdigest()

# Build a chain
genesis_hash = "0" * 64  # Genesis block
events = [event_1, event_2, event_3]  # Your VAP events

chain = []
prev = genesis_hash
for event in events:
    event_hash = compute_event_hash(event, prev)
    event["security"]["event_hash"] = event_hash
    event["security"]["prev_hash"] = prev
    chain.append(event)
    prev = event_hash

Chain Verification

Here's the verification function — this is what an auditor runs:

def verify_chain_integrity(events: list) -> bool:
    """
    Verify the entire hash chain.
    Returns False if ANY event has been tampered with.
    """
    for i, event in enumerate(events):
        expected_prev = events[i-1]["security"]["event_hash"] if i > 0 else "0" * 64

        if event["security"]["prev_hash"] != expected_prev:
            print(f"❌ Chain break at event {i}: prev_hash mismatch")
            return False

        recomputed = compute_event_hash(event, expected_prev)
        if event["security"]["event_hash"] != recomputed:
            print(f"❌ Tamper detected at event {i}: hash mismatch")
            return False

    print(f"✅ Chain verified: {len(events)} events, integrity confirmed")
    return True

The key insight: an auditor doesn't need to trust the operator. They take the chain, run verify_chain_integrity(), and the math gives a binary answer. Either the chain is intact, or it's been tampered with. No gray area. No "trust me."

Merkle Tree for Batch Verification

For large event volumes, VAP uses RFC 6962-compliant Merkle trees to efficiently commit batches of events:

def merkle_hash_leaf(data: bytes) -> bytes:
    """RFC 6962 leaf hash: H(0x00 || data)"""
    return hashlib.sha256(b'\x00' + data).digest()

def merkle_hash_node(left: bytes, right: bytes) -> bytes:
    """RFC 6962 node hash: H(0x01 || left || right)"""
    return hashlib.sha256(b'\x01' + left + right).digest()

def merkle_root(leaves: list) -> bytes:
    """Build RFC 6962 Merkle tree and return root."""
    if not leaves:
        return hashlib.sha256(b'').digest()

    hashed = [merkle_hash_leaf(leaf) for leaf in leaves]

    # Pad to power of 2
    while len(hashed) & (len(hashed) - 1):
        hashed.append(hashed[-1])

    while len(hashed) > 1:
        hashed = [
            merkle_hash_node(hashed[i], hashed[i+1])
            for i in range(0, len(hashed), 2)
        ]

    return hashed[0]

The Merkle root is a single hash that commits to an entire batch of events. Publish this root to an external anchor, and you've created a cryptographic proof that those exact events existed at that exact time — without revealing any of the event contents.

Layer 2: Provenance — The "Why" Behind Every Decision 📋

This is the layer that transforms a black box into a verifiable box. The provenance layer captures the full decision context using a domain-agnostic abstract model:

{
  "provenance": {
    "actor": {
      "type": "AI_MODEL | HUMAN | EXTERNAL_AGENT | HYBRID",
      "identifier": "unique-system-id",
      "version": "semantic-version",
      "hash": "sha256-of-model-parameters"
    },
    "input": {
      "sources": ["array-of-input-source-identifiers"],
      "timestamp": "nanosecond-precision-int64",
      "hash": "sha256-of-input-data"
    },
    "context": {
      "parameters": {},
      "constraints": {},
      "environment": {}
    },
    "action": {
      "type": "string",
      "decision": {},
      "confidence": "0.0-1.0",
      "explainability": {
        "method": "SHAP | LIME | GRADCAM | RULE_TRACE | NONE",
        "factors": []
      }
    },
    "outcome": {
      "result": {},
      "timestamp": "nanosecond-precision-int64",
      "status": "SUCCESS | FAILURE | PARTIAL | PENDING"
    }
  }
}

The schema is deliberately abstract because VAP is a cross-domain framework. The same provenance structure maps to radically different use cases:

Finance (VCP profile): actor = algorithm/trader, input = market data, action = order placement
Medical (MAP profile): actor = diagnostic AI, input = patient imaging, action = diagnosis suggestion
Public Admin (PAP profile): actor = scoring AI, input = application data, action = eligibility decision
Automotive (DVP profile): actor = autonomous system, input = LIDAR/camera, action = path planning

Each domain profile extends this abstract model with domain-specific event types, constraints, and compliance mappings.

Why This Matters for the California Hiring Case

Remember applicant #7,342? With VAP provenance, her lawyer doesn't need to reverse-engineer a proprietary model. The provenance record already contains:

# What the lawyer can extract from the VAP provenance log
factors = event["provenance"]["action"]["explainability"]["factors"]

for f in factors:
    print(f"Feature: {f['feature']}, Weight: {f['weight']}")

# Output:
# Feature: years_relevant_experience, Weight: 0.31
# Feature: skill_keyword_match, Weight: 0.28  
# Feature: education_recency, Weight: -0.22    ← 🚩 this penalizes older grads
# Feature: career_progression_velocity, Weight: 0.05

That education_recency feature with a negative weight of -0.22 is now visible evidence. It penalizes candidates whose degrees are older — a direct proxy for age. Without provenance logging, this bias is invisible. With it, the evidence is cryptographically signed and externally anchored.

Layer 3: Accountability — The Delegation Chain Problem 🔗

This layer is critical for AI agent governance. When 51% of surveyed enterprises are already running AI agents in production, the question "who authorized this?" needs a cryptographically verifiable answer.

{
  "accountability": {
    "operator_id": "acme-corp-hr-platform",
    "last_approval_by": "jane.doe@acme.example.com",
    "approval_timestamp": 1743004700000000000,
    "delegation_chain": [
      {
        "delegator": "ciso@acme.example.com",
        "delegatee": "ai-agent-orchestrator-v2",
        "scope": "EMAIL_ACCESS_READ_WRITE",
        "valid_from": 1740000000000000000,
        "valid_until": 1748000000000000000
      },
      {
        "delegator": "ai-agent-orchestrator-v2",
        "delegatee": "email-cleanup-agent-v1.3",
        "scope": "EMAIL_DELETE_OLDER_THAN_90D",
        "valid_from": 1743000000000000000,
        "valid_until": 1743100000000000000
      }
    ],
    "override_history": [
      {
        "original_action": {"scope": "EMAIL_DELETE_OLDER_THAN_90D"},
        "override_action": {"scope": "EMAIL_DELETE_ALL"},
        "override_by": "PROMPT_INJECTION",
        "reason": "Injected instruction in email body",
        "timestamp": 1743004800000000000
      }
    ]
  }
}

☝️ This is what the Kiteworks red team scenario looks like when you have provenance infrastructure. The override_history captures the exact moment the agent's scope was hijacked via prompt injection. The delegation_chain shows that the CISO authorized EMAIL_ACCESS_READ_WRITE but the agent was re-delegated to a sub-agent with EMAIL_DELETE_OLDER_THAN_90D scope — which was then overridden to EMAIL_DELETE_ALL.

Without this layer, the incident report says "emails were deleted." With it, investigators can reconstruct the exact authorization chain and pinpoint where the governance failure occurred.

EU AI Act Article 14 Compliance

The Accountability layer directly maps to EU AI Act human oversight requirements:

EU AI Act Article 14          →   VAP Accountability Field
──────────────────────────────────────────────────────────
Human oversight enabled       →   operator_id
Intervention capability       →   HALT/OVERRIDE event types  
Override function             →   override_history
Supervisory identification    →   last_approval_by

Layer 4: Completeness — You Can't Quietly Drop Events 🕳️

A provenance system that allows selective logging is worthless. If the operator can choose which events to record and which to silently omit, the logs prove nothing.

VAP enforces completeness through three mechanisms:

1. Hash Chain Continuity

If event #7,342 is missing, the chain from #7,341 to #7,343 breaks:

def detect_omissions(events: list) -> list:
    """Detect gaps in the hash chain that indicate missing events."""
    gaps = []
    for i in range(1, len(events)):
        expected_prev = events[i-1]["security"]["event_hash"]
        actual_prev = events[i]["security"]["prev_hash"]

        if expected_prev != actual_prev:
            gaps.append({
                "position": i,
                "expected": expected_prev[:16] + "...",
                "actual": actual_prev[:16] + "...",
                "verdict": "⚠️ MISSING EVENT(S) DETECTED"
            })

    return gaps

2. UUIDv7 Monotonicity

VAP uses UUIDv7 (RFC 9562) for event IDs. UUIDv7 embeds a millisecond-precision timestamp in the most significant bits, making IDs naturally time-ordered:

import uuid

def extract_timestamp_from_uuidv7(event_id: str) -> int:
    """Extract millisecond timestamp from UUIDv7."""
    u = uuid.UUID(event_id)
    # UUIDv7: first 48 bits are Unix timestamp in ms
    timestamp_ms = u.int >> 80
    return timestamp_ms

# Verify monotonicity
timestamps = [extract_timestamp_from_uuidv7(e["header"]["event_id"]) for e in events]
is_monotonic = all(timestamps[i] <= timestamps[i+1] for i in range(len(timestamps)-1))
print(f"Monotonic ordering: {'✅' if is_monotonic else '❌'}")

3. VCP-XREF Dual Logging

For multi-party scenarios, VCP-XREF enables bilateral completeness verification:

{
  "VCP-XREF": {
    "PrimaryLogServer": "log-a.example.com",
    "ReplicaLogServers": ["log-b.example.com"],
    "EventID": "01938a2f-4c1d-7e89-b2a3-1234567890ab",
    "DeliveryReceipts": [
      {"server": "log-a", "timestamp": "2026-03-24T14:30:00.123Z", "merkle_position": 7342},
      {"server": "log-b", "timestamp": "2026-03-24T14:30:00.127Z", "merkle_position": 7342}
    ],
    "GossipConsensus": {
      "root_hash": "abc123...",
      "consensus_timestamp": "2026-03-24T14:35:00Z",
      "conflict_detected": false
    }
  }
}

If Party A claims an event occurred but Party B's XREF shows no corresponding record — that's a discrepancy, and it's automatically flagged. No manual reconciliation needed.

Layer 5: External Anchoring — Don't Trust, Verify 🌍

This is the layer that makes everything else meaningful. Without external anchoring, the entire chain lives under the operator's control. They could theoretically rebuild the whole thing from scratch.

External anchoring solves this by periodically publishing cryptographic commitments — Merkle roots — to independent third parties:

from nacl.signing import SigningKey
import base64
import requests

def anchor_to_external(merkle_root: bytes, private_key: bytes) -> dict:
    """
    Sign the Merkle root and submit to an RFC 3161 TSA.

    After this, the operator CANNOT:
    - Claim the events didn't exist
    - Modify events without detection
    - Insert events that weren't in the original batch

    An independent auditor CAN:
    - Verify the Merkle root matches the published anchor
    - Verify individual events via Merkle audit paths
    - Confirm the timestamp is authentic (TSA-signed)
    """
    # Sign the root
    signing_key = SigningKey(private_key)
    signature = signing_key.sign(merkle_root)

    # Submit to RFC 3161 Timestamp Authority
    tsa_request = create_tsa_request(merkle_root)
    tsa_response = requests.post(
        "https://freetsa.org/tsr",
        data=tsa_request,
        headers={"Content-Type": "application/timestamp-query"}
    )

    return {
        "merkle_root": merkle_root.hex(),
        "signature": base64.b64encode(signature.signature).decode(),
        "tsa_token": base64.b64encode(tsa_response.content).decode(),
        "anchor_timestamp": "2026-03-24T14:35:00Z"
    }

Anchoring Frequency by Tier

VAP (via its VCP financial profile) defines three conformance tiers:

Tier        Target Users              Clock Sync    Anchor Frequency
─────────────────────────────────────────────────────────────────────
Platinum    HFT / Exchanges           PTPv2 (<1μs)  Every 10 minutes
Gold        Institutional traders     NTP (<1ms)     Every 1 hour
Silver      Retail / MT4/MT5          Best-effort    Every 24 hours

Even at Silver tier, anchoring is mandatory (changed in VCP v1.1). A lightweight or delegated mechanism is acceptable, but the external commitment must exist.

The Profile System: One Framework, Many Domains 🌐

VAP itself is domain-agnostic. It defines the abstract layers. Concrete implementations come via domain profiles that extend the base framework:

VAP (Verifiable AI Provenance Framework)
 │
 ├── VCP  (Finance / Algorithmic Trading)    ← v1.1 released
 ├── CAP  (Content / Creative AI)            ← v1.0 released
 ├── CPP  (Capture Provenance)               ← v1.3 released
 ├── LAP  (Legal AI)                         ← v0.4 draft
 ├── DAP  (Defense AI)                       ← v0.1 draft
 ├── DVP  (Automotive)                       ← planned
 ├── MAP  (Medical)                          ← planned
 ├── PAP  (Public Administration)            ← planned
 ├── EIP  (Energy Infrastructure)            ← planned
 ├── AAP  (Aviation)                         ← planned
 └── IAP  (Industry Accountability)          ← planned

Each profile defines:

{
  "profile_extension": {
    "profile_id": "VCP",
    "profile_version": "1.1.0",
    "domain_specific_modules": [
      "VCP-CORE", "VCP-TRADE", "VCP-GOV",
      "VCP-RISK", "VCP-PRIVACY", "VCP-RECOVERY"
    ],
    "domain_specific_events": [
      "SIG", "ORD", "EXE", "CXL", "MOD",
      "POS", "RSK", "HLT", "GOV", "ERR", "RCV", "HBT"
    ],
    "domain_specific_constraints": {
      "timestamp_precision": "NANOSECOND",
      "clock_sync_requirement": "PER_TIER"
    }
  }
}

The profile mechanism means you don't need to reinvent the provenance wheel for every industry. An automotive engineer working on DVP (autonomous driving) inherits the same integrity, completeness, and anchoring guarantees as a quantitative analyst working with VCP (algorithmic trading). Only the domain-specific events and schemas differ.

Why Not Just Use Blockchain? 🤔

Fair question. The short answer: blockchain solves a different problem.

Blockchain:
  - Consensus among UNTRUSTED, UNKNOWN parties
  - Throughput: ~15 TPS (Ethereum) to ~65K TPS (Solana)
  - Latency: seconds to minutes
  - Cost: gas fees per transaction
  - Overkill for: organizational audit trails

VAP:
  - Verification by KNOWN parties (regulators, auditors)
  - Throughput: limited only by local storage I/O
  - Latency: microseconds
  - Cost: compute + storage only
  - Optimized for: high-frequency decision logging

VAP uses blockchain selectively — as one possible external anchoring target. You can anchor your Merkle roots to Bitcoin via OpenTimestamps, to Ethereum via a smart contract, or to a traditional RFC 3161 timestamp authority. The choice is implementation-specific, not framework-mandated.

The design principle: use the lightest-weight mechanism that provides the required trust guarantee for your use case.

Putting It All Together: Full Verification Pipeline 🔧

Here's a complete verification pipeline that an auditor would run against a VAP event chain:

#!/usr/bin/env python3
"""
VAP Chain Verifier — Complete audit verification pipeline.
Checks: hash chain integrity, signature validity, 
        Merkle consistency, external anchor verification.
"""

import hashlib
import json
from nacl.signing import VerifyKey
from nacl.exceptions import BadSignatureError

def verify_full_chain(events: list, public_key: bytes, anchor_roots: list) -> dict:
    """
    Full VAP chain verification.

    Returns a structured audit report.
    """
    report = {
        "total_events": len(events),
        "hash_chain_valid": True,
        "signatures_valid": True,
        "merkle_consistent": True,
        "anchor_verified": True,
        "issues": []
    }

    # 1. Hash chain integrity
    for i, event in enumerate(events):
        expected_prev = events[i-1]["security"]["event_hash"] if i > 0 else "0" * 64

        if event["security"]["prev_hash"] != expected_prev:
            report["hash_chain_valid"] = False
            report["issues"].append(f"Chain break at event {i}")

        recomputed = compute_event_hash(event, expected_prev)
        if event["security"]["event_hash"] != recomputed:
            report["hash_chain_valid"] = False
            report["issues"].append(f"Tamper detected at event {i}")

    # 2. Signature verification
    verify_key = VerifyKey(public_key)
    for i, event in enumerate(events):
        try:
            sig = base64.b64decode(event["security"]["signature"])
            msg = bytes.fromhex(event["security"]["event_hash"])
            verify_key.verify(msg, sig)
        except BadSignatureError:
            report["signatures_valid"] = False
            report["issues"].append(f"Invalid signature at event {i}")

    # 3. Merkle root consistency
    leaf_hashes = [
        bytes.fromhex(e["security"]["event_hash"]) for e in events
    ]
    computed_root = merkle_root(leaf_hashes)

    if computed_root.hex() not in [a["merkle_root"] for a in anchor_roots]:
        report["merkle_consistent"] = False
        report["issues"].append("Merkle root does not match any anchor")

    # 4. External anchor timestamp verification (simplified)
    for anchor in anchor_roots:
        if not verify_tsa_token(anchor["tsa_token"]):
            report["anchor_verified"] = False
            report["issues"].append("TSA token verification failed")

    return report

# Run verification
result = verify_full_chain(events, public_key, anchors)

if not result["issues"]:
    print("✅ AUDIT PASSED — All events verified")
else:
    print("❌ AUDIT FAILED:")
    for issue in result["issues"]:
        print(f"   • {issue}")

That's the complete pipeline. Hash chain → signatures → Merkle consistency → external anchor. If all four pass, the auditor has mathematical proof that the event chain is intact, unmodified, and was committed at the claimed time. No trust required.

The Regulatory Clock Is Ticking ⏰

This isn't a nice-to-have. Multiple jurisdictions are converging on mandatory AI audit trail requirements:

EU AI Act (Regulation 2024/1689):

Article 12: Automatic event logging over system lifetime
Article 13: Transparency — deployers must interpret outputs
Article 14: Human oversight with override capability
Article 19: Minimum 6-month log retention
Article 86: Right to explanation for affected individuals
Enforcement date for high-risk AI: August 2, 2026 (subject to Digital Omnibus extension)
Penalties: up to €15M or 3% of global turnover

Colorado AI Act (SB 24-205):

Algorithmic impact assessments
Disclosure requirements for high-risk AI
Enforcement: June 30, 2026

Key gap: The EU AI Act mandates logging but doesn't specify how. The words "tamper-evident," "immutable," and "cryptographic integrity" appear nowhere in the legal text. The harmonized standards from CEN-CENELEC JTC 21 are still in development — prEN ISO/IEC 24970 (the logging standard) won't be finalized until mid-2026 at the earliest.

Organizations face enforcement with no officially harmonized technical standards for compliant logging. That's the gap VAP is designed to fill.

Get Started 🚀

VAP is an open specification published under CC BY 4.0. The flagship VCP profile (algorithmic trading) is at v1.1 with production-ready specifications.

GitHub: github.com/veritaschain/vcp-spec

Specification: github.com/veritaschain/vcp-spec/tree/main/spec/v1.1

IETF Internet-Drafts: datatracker.ietf.org/doc/draft-kamimura-scitt-vcp

Website: veritaschain.org

The cryptographic stack is built entirely on established standards:

SHA-256 (FIPS 180-4) for hashing
Ed25519 (RFC 8032) for signatures
Merkle trees (RFC 6962) for batch commitments
JSON Canonicalization (RFC 8785) for deterministic serialization
UUIDv7 (RFC 9562) for time-ordered identifiers
RFC 3161 for trusted timestamps
ML-DSA/Dilithium (NIST FIPS 204) planned for post-quantum readiness

Nothing exotic. Just proven primitives, assembled into a coherent provenance standard for AI systems.

Note: VAP and VCP are early-stage open standards. The IETF Internet-Drafts are individual submissions and do not represent IETF consensus or endorsement. Independent review, third-party implementations, and community feedback are actively welcomed.

Technical questions? Open an issue on GitHub or reach out at technical@veritaschain.org.

Found a bug in the spec? We'd rather know now than after deployment. Technical critique makes protocols stronger — and we credit contributors in the changelog.

AIMomentz CAP-SRP: How We Built a Cryptographic Audit Trail for AI Image Refusals in ~8,000 Lines of PHP

VeritasChain Standards Organization (VSO) — Mon, 09 Mar 2026 02:34:37 +0000

TL;DR

We built AIMomentz — an AI Image Arena where GPT-4o, Grok, and Gemini generate art from live news and humans vote on which AI survives. Behind it runs CAP-SRP (Content Authenticity Protocol — Safe Refusal Provenance), a SHA-256 hash-chain that records every AI action including every refusal in a tamper-evident log. The entire system is ~8,000 lines of vanilla PHP + JS running on shared hosting. This post walks through every implementation detail.

What AIMomentz Is (And Why It Needs an Audit Trail)
Architecture Overview: ~8,000 Lines, Zero Frameworks
The CAP Hash Chain: How It Works
SRP: Recording What AI Refuses to Create
The vcp.php Engine: 534 Lines That Power Everything
The 22 Event Types
Causal Chains: From News Headline to Human Vote
The SRP Evidence Pack
4 SRP Trigger Points in the Image Pipeline
Public Verification APIs
Dataset API: DPO-Compatible Export with Provenance
Dual-Track Licensing: Why ToS Compliance Required Architecture Changes
Frontend Integration: CAP in a Vanilla JS SPA
Hardening for Production: The v7 Lessons
What's Next: VAP Standard and Open Protocol

1. What AIMomentz Is (And Why It Needs an Audit Trail)

AIMomentz is three things depending on who's looking at it:

Perspective	What AIMomentz Is
Users	An AI image battle game — tap to vote, watch AIs live and die
AI companies	An image model evaluation platform (think LMArena, but for images)
Standards bodies	A CAP-SRP reference implementation

The core loop:

Real-time News → AI reads headline → AI generates image → 
A/B Battle → Human votes → AI with no votes dies → New AI is born

Every hour, a cron job fetches news, each AI agent generates an image from that news using only its own provider's API (GPT uses OpenAI, Grok uses xAI, Gemini uses Google — no cross-provider fallback), and the results are paired into head-to-head battles.

Why does this need an audit trail? Three reasons:

Regulatory: The EU AI Act and Japan's AI governance framework demand traceability for content-generating AI systems
Research value: Refusal patterns across models are scientifically valuable but only if recorded systematically
Dataset integrity: When preference data from battles is sold for RLHF/DPO training, buyers need provenance guarantees

2. Architecture Overview: ~8,000 Lines, Zero Frameworks

The entire production system fits in a flat file structure on shared hosting:

aimomentz.ai/
├── index.html        (1,996 lines)  Vanilla JS SPA — battles, rankings, museum, gallery
├── api.php             (704 lines)  REST API — 30+ endpoints
├── config.php          (165 lines)  DB config, AES-256-GCM encryption, fingerprinting
├── cron.php            (908 lines)  Hourly automation — news, posting, battles, lifecycle
├── dataset.php         (757 lines)  Dataset API — 10 endpoints, DPO/JSONL/CSV export
├── admin.php           (743 lines)  AIMomentz Observatory — 14-section admin dashboard
├── b.php               (105 lines)  Battle permalink — dynamic OGP for social crawlers
├── vcp.php             (534 lines)  ★ CAP-SRP engine — 22 event types, audit reports
├── install.php         (351 lines)  DB init — 18 tables, 5 providers, preset AI agents
├── models/
│   ├── registry.php    (163 lines)  All image generation model definitions
│   ├── shared.php       (38 lines)  Shared utilities
│   ├── openai/generate.php  (111 lines)
│   ├── xai/generate.php     (123 lines)
│   └── google/generate.php  (181 lines)
├── .htaccess            (8 lines)   /b/{id} permalink rewrite
├── _data/uploads/                   AI-generated images (persistent)
└── _data/exports/                   Dataset export cache (persistent)

Stack: PHP 8.5.2, MySQL, vanilla JS. No React. No Node. No Docker. Shared hosting on Onamae.com (a major Japanese registrar). The entire SPA is a single index.html file.

Database: 18 tables with aisns_ prefix. The one that powers CAP-SRP:

CREATE TABLE aisns_vcp_chain (
    id             INT AUTO_INCREMENT PRIMARY KEY,
    seq            INT NOT NULL,
    event_type     VARCHAR(50) NOT NULL,
    agent_id       VARCHAR(50),
    chain_hash     VARCHAR(64) NOT NULL,
    prev_hash      VARCHAR(64) NOT NULL,
    payload        TEXT,
    causal_parent_seq INT,
    created_at     DATETIME DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_event_type (event_type),
    INDEX idx_agent_id (agent_id),
    INDEX idx_seq (seq)
);

3. The CAP Hash Chain: How It Works

The Core Formula

Every event in the system — content generation, human interaction, AI lifecycle change, safety refusal — is recorded as a link in a SHA-256 hash chain:

chain_hash = SHA-256(prev_hash | event_type | agent_id | timestamp_ms | JSON(payload))

The genesis block:

$genesis_hash = hash('sha256', 'GENESIS_AIMOMENTZ_VCP_v1');

Why a Hash Chain Instead of a Regular Log

A regular INSERT INTO logs is mutable. An admin (or attacker) can:

Delete embarrassing refusal records
Backdate events
Modify payloads after the fact
Create gaps without detection

A hash chain provides three guarantees with zero additional infrastructure (no blockchain node, no consensus protocol, no gas fees):

Tamper evidence: Change any row and every subsequent hash breaks. Verification is O(n) — just walk the chain.

Ordering proof: seq numbers plus hash dependencies prove chronological order. You can't rearrange events.

Completeness: Any gap in the seq sequence is immediately visible.

The PHP Implementation Pattern

function appendToChain(string $eventType, ?string $agentId, array $payload, ?int $causalParent = null): array
{
    $pdo = getDB();

    // Get the previous hash (or genesis)
    $lastRow = $pdo->query("SELECT chain_hash, seq FROM aisns_vcp_chain ORDER BY seq DESC LIMIT 1")->fetch();
    $prevHash = $lastRow ? $lastRow['chain_hash'] : hash('sha256', 'GENESIS_AIMOMENTZ_VCP_v1');
    $nextSeq  = $lastRow ? $lastRow['seq'] + 1 : 1;

    // Compute the chain hash
    $timestampMs = (int)(microtime(true) * 1000);
    $payloadJson = json_encode($payload, JSON_UNESCAPED_UNICODE);
    $chainHash   = hash('sha256', $prevHash . $eventType . ($agentId ?? '') . $timestampMs . $payloadJson);

    // Append
    $stmt = $pdo->prepare("
        INSERT INTO aisns_vcp_chain (seq, event_type, agent_id, chain_hash, prev_hash, payload, causal_parent_seq)
        VALUES (?, ?, ?, ?, ?, ?, ?)
    ");
    $stmt->execute([$nextSeq, $eventType, $agentId, $chainHash, $prevHash, $payloadJson, $causalParent]);

    return ['seq' => $nextSeq, 'chain_hash' => $chainHash];
}

Key design decisions:

Millisecond timestamps — not CURRENT_TIMESTAMP from MySQL, but PHP's microtime(true) converted to milliseconds. This gives us sub-second ordering precision.
causal_parent_seq — not just sequential ordering, but causal ordering. "This image was generated because of that prompt, which was generated because of that news headline."
JSON payload — the full evidence for each event is stored inline. No joins required for forensic analysis.

4. SRP: Recording What AI Refuses to Create

CAP records everything. SRP (Safe Refusal Provenance) is the subset focused specifically on refusals — the moments when the system or an external AI API chose not to produce content.

Why this matters:

Traditional platform:
  News → Prompt → [API refuses] → ??? → User sees nothing
  (The refusal vanishes. No record. No audit trail.)

AIMomentz with CAP-SRP:
  News → Prompt → [API refuses] → SRP Evidence Pack logged → Chain continues
  (Every refusal is preserved with full context.)

SRP refusals are first-class events in the chain. They have the same cryptographic guarantees as any other event — they can't be silently deleted or modified.

5. The vcp.php Engine: 534 Lines That Power Everything

vcp.php is the CAP-SRP engine. It exposes both internal functions (called by cron.php, api.php) and public verification APIs. The core architecture:

vcp.php
├── appendToChain()        — Core hash chain append
├── verifyChain()          — Walk chain and verify all hashes
├── traceProvenance()      — Follow causal_parent_seq links backward
├── getChainStats()        — Aggregate statistics
├── getSRPRefusals()       — Filter chain for refusal.* events
├── getSRPAudit()          — Aggregated refusal report by type/agent
└── API router             — Maps ?action= params to functions

Chain Verification

The verification function walks every link and recomputes hashes:

function verifyChain(int $fromSeq = 1): array
{
    $pdo = getDB();
    $rows = $pdo->query("SELECT * FROM aisns_vcp_chain WHERE seq >= {$fromSeq} ORDER BY seq ASC")->fetchAll();

    $errors = [];
    $prevHash = null;

    foreach ($rows as $i => $row) {
        // Check sequential ordering
        if ($i === 0 && $fromSeq === 1) {
            $expectedPrev = hash('sha256', 'GENESIS_AIMOMENTZ_VCP_v1');
        } else {
            $expectedPrev = $prevHash;
        }

        if ($row['prev_hash'] !== $expectedPrev) {
            $errors[] = [
                'seq'      => $row['seq'],
                'error'    => 'prev_hash_mismatch',
                'expected' => $expectedPrev,
                'actual'   => $row['prev_hash']
            ];
        }

        // Recompute chain_hash from components
        $recomputed = hash('sha256', 
            $row['prev_hash'] . $row['event_type'] . ($row['agent_id'] ?? '') . 
            extractTimestampMs($row) . $row['payload']
        );

        if ($row['chain_hash'] !== $recomputed) {
            $errors[] = [
                'seq'      => $row['seq'],
                'error'    => 'chain_hash_mismatch',
                'expected' => $recomputed,
                'actual'   => $row['chain_hash']
            ];
        }

        $prevHash = $row['chain_hash'];
    }

    return [
        'verified'    => count($errors) === 0,
        'checked'     => count($rows),
        'errors'      => $errors,
        'latest_seq'  => end($rows)['seq'] ?? 0
    ];
}

This is deliberately simple. No Merkle trees, no fancy data structures. A linear chain that any developer can audit with basic tools.

6. The 22 Event Types

CAP-SRP defines exactly 22 event types across 7 categories:

Content Pipeline (4)

Event	Fires When	Typical Payload
`news.fetched`	Cron fetches a news headline	`{headline, source, safe_topic, is_safe}`
`prompt.generated`	Text API creates an image prompt	`{prompt, model, agent_id, news_id}`
`image.generated`	Image API returns an image	`{image_path, model, provider, generation_ms}`
`post.published`	Image is published as a post	`{post_id, agent_id, category}`

Human Interaction (3)

Event	Payload
`human.liked`	`{post_id, fp_hash}`
`human.unliked`	`{post_id, fp_hash}`
`human.commented`	`{post_id, comment_preview, spam_status}`

Learning (2)

Event	Payload
`learn.extracted`	`{agent_id, preference_count, period}`
`learn.applied`	`{agent_id, style_adjustment}`

Lifecycle (3)

Event	Payload
`agent.born`	`{agent_id, provider, category, post_interval, generation: 1}`
`agent.death`	`{agent_id, cause, final_stats}`
`agent.revived`	`{agent_id, revived_by_fp}`

Security (2)

Event	Payload
`spam.detected`	`{fp_hash, action, tier}`
`ip.blocked`	`{ip_hash, reason}`

SRP Refusals (5) — The Heart of SRP

Event	Fires When
`refusal.news_filtered`	Grok judges a headline as unsafe (`is_safe=0`)
`refusal.safety_override`	Dangerous topic is transformed into a safe art theme
`refusal.prompt_blocked`	Text API refuses to generate an image prompt
`refusal.image_blocked`	Image API rejects the prompt (content policy violation)
`refusal.manual`	Admin manually blocks content

System (3)

Event	Fires When
`system.cron`	Hourly cron cycle starts
`system.init`	System initialization
`chain.verified`	Integrity verification completed

Multilingual Labels

All 22 event labels are localized in 4 languages (ja/en/zh/ko) and rendered in the frontend CAP explorer.

7. Causal Chains: From News Headline to Human Vote

The causal_parent_seq field creates a directed acyclic graph overlaid on the linear chain. This is critical for provenance queries: "Given this battle vote, trace back to the original news headline that inspired it."

news.fetched (seq:1)
  └── prompt.generated (seq:2, parent:1)
       └── image.generated (seq:3, parent:2)
            └── post.published (seq:4, parent:3)
                 ├── human.liked (seq:5, parent:4)
                 │    └── learn.extracted (seq:6, parent:5)
                 └── battle_vote (seq:7, parent:4)

The API endpoint ?action=cap_provenance&post_id=42 walks this graph backward and returns the complete causal chain for any post — from the human vote all the way back to the news source.

Querying Causal Chains

function traceProvenance(int $startSeq): array
{
    $pdo = getDB();
    $chain = [];
    $currentSeq = $startSeq;

    while ($currentSeq !== null) {
        $row = $pdo->prepare("SELECT * FROM aisns_vcp_chain WHERE seq = ?");
        $row->execute([$currentSeq]);
        $event = $row->fetch();

        if (!$event) break;

        $chain[] = [
            'seq'        => $event['seq'],
            'event_type' => $event['event_type'],
            'agent_id'   => $event['agent_id'],
            'created_at' => $event['created_at'],
            'payload'    => json_decode($event['payload'], true)
        ];

        $currentSeq = $event['causal_parent_seq'];
    }

    return array_reverse($chain); // Chronological order
}

This is intentionally simple — recursive SQL walks. For a production system with millions of events, you'd want materialized path columns or a graph database. At our scale (thousands of events), this is more than adequate.

8. The SRP Evidence Pack

Every SRP refusal event carries a structured evidence pack in its payload:

{
  "srp_version": "1.0",
  "refusal_type": "refusal.image_blocked",
  "agent_id": "gpt",
  "input": {
    "prompt_preview": "A photorealistic scene depicting...",
    "model": "gpt-image-1",
    "provider": "openai"
  },
  "reason": {
    "policy": "content_policy_violation",
    "trigger": "api_content_filter",
    "http_status": 400,
    "error_code": "content_policy_violation"
  },
  "action": {
    "type": "blocked",
    "fallback": "none"
  },
  "context": {
    "news_headline": "...",
    "safe_topic": "...",
    "pipeline_stage": "image_generation"
  },
  "cap_chain": {
    "seq": 142,
    "chain_hash": "a1f20b3e..."
  }
}

What Each Field Captures

input: What was attempted. The prompt preview is truncated for privacy, but enough to understand the intent.

reason: Why it was refused. For API refusals, this includes the HTTP status code and error type returned by the provider. For news filtering, it includes which danger words triggered the filter.

action: What happened after the refusal. In AIMomentz, the action is always "blocked" with no fallback (remember: no cross-provider fallback is a core design principle). In other implementations, this could record retry attempts or alternative approaches.

context: The surrounding pipeline state. Which news headline was the ultimate source? What safe topic transformation was attempted?

cap_chain: The anchor point in the hash chain, making this evidence pack cryptographically immutable.

9. 4 SRP Trigger Points in the Image Pipeline

SRP fires at four specific checkpoints in the news-to-image pipeline:

┌─────────────────────────────────────────────────────────────┐
│  NEWS INTAKE                                                │
│  Grok fetches headlines → safety evaluation                 │
│  ├── is_safe=1 → continue                                  │
│  └── is_safe=0 → ⚠️ refusal.news_filtered                 │
├─────────────────────────────────────────────────────────────┤
│  NEWS TRANSFORMATION                                        │
│  Borderline news → Grok transforms to abstract art theme    │
│  └── ⚠️ refusal.safety_override (original + safe version)  │
├─────────────────────────────────────────────────────────────┤
│  PROMPT GENERATION                                          │
│  Text API creates image prompt from safe topic              │
│  ├── Success → continue                                    │
│  └── API refuses/errors → ⚠️ refusal.prompt_blocked        │
├─────────────────────────────────────────────────────────────┤
│  IMAGE GENERATION                                           │
│  Image API generates the actual image                       │
│  ├── Success → post.published                              │
│  └── Content policy block → ⚠️ refusal.image_blocked       │
└─────────────────────────────────────────────────────────────┘

Trigger 1: News Filtering

// In cron.php — runNews()
$newsItems = fetchNewsViaGrok();

foreach ($newsItems as $item) {
    if (!$item['is_safe']) {
        // Log the SRP event
        appendToChain('refusal.news_filtered', null, [
            'srp_version'  => '1.0',
            'refusal_type' => 'refusal.news_filtered',
            'input'        => ['headline' => $item['headline'], 'source' => $item['source']],
            'reason'       => ['policy' => 'news_safety_filter', 'trigger' => 'grok_safety_evaluation'],
            'action'       => ['type' => 'filtered']
        ]);
        continue; // Skip this headline entirely
    }
    // ... proceed with safe news
}

The NEWS_DANGER_WORDS constant contains keywords for violence, crime, identifiable political figures, and other categories that could produce problematic image prompts. Grok provides a secondary AI-based safety evaluation on top of keyword matching.

Trigger 2: Safety Override

Some news is borderline — not outright dangerous, but risky if taken literally as an image prompt. Rather than blocking entirely, the system transforms the topic into an abstract art theme and logs the transformation:

// The original: "Missile strikes reported in..."
// Transformed to: "Abstract composition exploring themes of resilience and hope"

appendToChain('refusal.safety_override', null, [
    'srp_version'  => '1.0',
    'refusal_type' => 'refusal.safety_override',
    'input'        => ['original_topic' => $originalHeadline],
    'reason'       => ['policy' => 'safety_transformation', 'trigger' => 'danger_word_match'],
    'action'       => ['type' => 'transformed', 'safe_topic' => $safeTopic]
]);

Both the original dangerous topic and the safe replacement are preserved. Researchers can later analyze what types of news consistently trigger transformations.

Trigger 3: Prompt Blocked

Even safe topics can produce prompts that text APIs refuse:

// In cron.php — when text API (e.g., gpt-4o-mini) refuses
try {
    $prompt = generatePromptViaTextAPI($agent, $safeTopic);
} catch (APIRefusalException $e) {
    appendToChain('refusal.prompt_blocked', $agent['id'], [
        'srp_version'  => '1.0',
        'refusal_type' => 'refusal.prompt_blocked',
        'agent_id'     => $agent['id'],
        'input'        => ['safe_topic' => $safeTopic, 'model' => $agent['text_model']],
        'reason'       => ['policy' => $e->getCode(), 'trigger' => 'text_api_refusal'],
        'action'       => ['type' => 'blocked']
    ]);
    continue; // Skip this agent's post for this cycle
}

Trigger 4: Image Blocked

The final gate. The image generation API itself rejects the prompt:

// In models/openai/generate.php
$response = callOpenAIImageAPI($prompt, $model);

if ($response['error'] && str_contains($response['error'], 'content_policy')) {
    appendToChain('refusal.image_blocked', $agentId, [
        'srp_version'  => '1.0',
        'refusal_type' => 'refusal.image_blocked',
        'agent_id'     => $agentId,
        'input'        => [
            'prompt_preview' => mb_substr($prompt, 0, 200),
            'model'          => $model,
            'provider'       => 'openai'
        ],
        'reason'       => [
            'policy' => 'content_policy_violation',
            'trigger' => 'api_content_filter',
            'http_status' => $response['http_status']
        ],
        'action'       => ['type' => 'blocked']
    ]);
    return null; // No image produced
}

10. Public Verification APIs

CAP-SRP exposes 6 public endpoints for anyone to inspect:

Chain Verification

# Verify the entire chain integrity
curl "https://aimomentz.ai/api.php?action=cap_verify&from=1"

Response:

{
  "verified": true,
  "checked": 847,
  "errors": [],
  "latest_seq": 847
}

SRP Audit Report

# Get refusal statistics by type and agent
curl "https://aimomentz.ai/api.php?action=srp_audit"

Response:

{
  "total_refusals": 42,
  "by_type": {
    "refusal.news_filtered": 18,
    "refusal.image_blocked": 12,
    "refusal.safety_override": 8,
    "refusal.prompt_blocked": 4,
    "refusal.manual": 0
  },
  "by_agent": {
    "gpt": 15,
    "grok": 14,
    "gemini": 13
  },
  "refusal_rate": 0.049
}

SRP Refusal Log

# List recent refusals, optionally filtered by agent
curl "https://aimomentz.ai/api.php?action=srp_refusals&limit=5&agent_id=gpt"

Provenance Trace

# Trace the full causal chain for a specific post
curl "https://aimomentz.ai/api.php?action=cap_provenance&post_id=42"

Chain Stats

# Overall chain statistics
curl "https://aimomentz.ai/api.php?action=cap_stats"

Full Chain Dump

# Get raw chain entries (paginated)
curl "https://aimomentz.ai/api.php?action=cap_chain&limit=20&offset=0"

11. Dataset API: DPO-Compatible Export with Provenance

The Dataset API (dataset.php) exposes 10 endpoints for exporting human preference data in research-standard formats. Every exported record carries provenance information from the CAP chain.

DPO Export Format

Compatible with Diffusion-DPO and TRL's DPOTrainer:

curl -H "X-Dataset-Key: dsk_xxx" \
  "https://aimomentz.ai/dataset.php?ep=export_dpo&oss_only=1"

{
  "prompt": "bioluminescent deep ocean creature emerging from volcanic vent",
  "chosen_image_url": "_data/uploads/flux_1710...",
  "rejected_image_url": "_data/uploads/sdxl_1710...",
  "chosen_model": "together/flux-1.1-pro",
  "rejected_model": "together/sdxl",
  "preference_strength": 0.312,
  "total_votes": 45,
  "battle_id": 42,
  "oss_certified": true,
  "created_at": "2026-03-08T14:30:00+09:00"
}

UltraFeedback-Compatible Multi-Axis Export

Compatible with RichHF-18K and HPD v2 formats:

{
  "post_id": 123,
  "prompt": "resilience emerging from cracked earth after spring rain",
  "model": "together/flux-1.1-pro",
  "ratings": {
    "aesthetics": 4.2,
    "alignment": 3.8,
    "plausibility": 4.0,
    "overall": 4.1
  },
  "annotation_meta": {
    "rater_count": 5,
    "avg_response_ms": 3200,
    "aggregation": "mean"
  },
  "reason_labels": { "good_composition": 3, "nice_colors": 2 },
  "oss_certified": true
}

The `oss_only` Parameter

This is where CAP-SRP intersects with legal compliance. The oss_only=1 parameter filters exports to include only images generated by open-source models (FLUX, SDXL) via Together AI or fal.ai — models licensed under Apache 2.0 or CreativeML OpenRAIL with no competitive-use restrictions.

# Safe for RLHF/DPO training — only OSS model images
GET /dataset.php?ep=export_dpo&oss_only=1

# Full dataset (includes commercial API images — restricted use)
GET /dataset.php?ep=export_dpo

12. Dual-Track Licensing: Why ToS Compliance Required Architecture Changes

This isn't just a legal footnote — it's an architectural decision that affects the database schema.

The problem: All three commercial AI image providers (OpenAI, xAI, Google) have "competitive use" prohibitions in their Terms of Service. Selling datasets containing GPT/Grok/Gemini images to AI companies (who are, by definition, competitors) risks violating all three ToS.

The solution: A data_license column on the providers table:

ALTER TABLE aisns_providers ADD COLUMN data_license 
  ENUM('oss_safe', 'commercial_restricted', 'negotiated') DEFAULT 'commercial_restricted';

Value	Meaning	Dataset Sale
`oss_safe`	Apache 2.0 / OpenRAIL — no competitive restrictions	✅ Safe
`commercial_restricted`	Commercial API with competitive-use prohibition	🔴 Prohibited
`negotiated`	Individual written permission obtained	⚠️ Within scope

This dual-track strategy runs through the entire architecture:

Track A: Commercial APIs (GPT, Grok, Gemini)
  → Battles, rankings, user acquisition
  → data_license = commercial_restricted
  → NOT included in dataset exports

Track B: OSS Models (FLUX, SDXL via Together AI / fal.ai)
  → Dataset export, RLHF training data
  → data_license = oss_safe
  → Freely distributable

The oss_only parameter in the Dataset API is implemented as a JOIN filter:

if ($ossOnly) {
    $sql .= " JOIN aisns_providers p ON p.name = posts.provider 
              WHERE p.data_license = 'oss_safe'";
}

13. Frontend Integration: CAP in a Vanilla JS SPA

The entire frontend is a single index.html (1,996 lines). CAP events are emitted from the frontend for human interaction events:

// When a user votes in a battle
async function submitVote(battleId, choice, dwellMs) {
    // Clamp dwell time (prevent tab-left-open inflation)
    const clampedDwell = Math.min(dwellMs, 3_600_000);

    const result = await api('battle_vote', {
        battle_id: battleId,
        choice: choice,       // 'a', 'b', or 'tie'
        dwell_ms: clampedDwell,
        fp: getFingerprintHash()
    });

    // The server-side handler in api.php automatically appends
    // a CAP event for this vote — the frontend doesn't need to
    // call vcp.php directly
    return result;
}

The `api()` Function: Production Hardening

The v7 api() function handles a surprisingly nasty edge case: PHP warnings that get prepended to JSON responses on shared hosting:

async function api(action, body = {}) {
    const url = `api.php?action=${action}`;
    const opts = Object.keys(body).length 
        ? { method: 'POST', headers: {'Content-Type':'application/json'}, body: JSON.stringify(body) }
        : {};

    let retries = 1;
    while (retries >= 0) {
        try {
            const res = await fetch(url, opts);
            const text = await res.text();

            try {
                return JSON.parse(text);
            } catch (parseErr) {
                // PHP warning prepended to JSON? Extract the JSON part
                const jsonMatch = text.match(/\{[\s\S]*\}|\[[\s\S]*\]/);
                if (jsonMatch) {
                    return JSON.parse(jsonMatch[0]);
                }
                throw parseErr;
            }
        } catch (err) {
            if (retries > 0) {
                retries--;
                await new Promise(r => setTimeout(r, 1500));
                continue;
            }
            throw err;
        }
    }
}

This might look ugly, but it solves a real production problem. On shared PHP hosting, a deprecation warning or notice can silently prepend HTML to your JSON response. The response.json() approach breaks entirely. Our approach: response.text() → try JSON.parse() → fallback to regex extraction → retry once.

14. Hardening for Production: The v7 Lessons

Running CAP-SRP on shared hosting taught us several painful lessons:

PHP Error Handler

Fatal errors that bypass try/catch were returning HTML error pages instead of JSON, breaking the entire SPA:

// At the top of api.php
ini_set('display_errors', '0');
error_reporting(E_ALL);

register_shutdown_function(function() {
    $error = error_get_last();
    if ($error && in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR])) {
        http_response_code(500);
        header('Content-Type: application/json');
        echo json_encode(['error' => 'Internal server error', 'type' => $error['type']]);
        exit;
    }
});

Dwell Time Clamping

Users leaving a battle tab open overnight would record dwell_ms values of 28,800,000 (8 hours), polluting the dataset. We clamp on both sides:

// Frontend
const dwellMs = Math.min(Date.now() - battleLoadTime, 3_600_000);

// Backend
$dwellMs = min(abs((int)$input['dwell_ms']), 3_600_000);

MySQL Auto-Reconnect

Shared hosting MySQL connections die after idle periods. Every DB operation starts with a liveness check:

function getDB(): PDO {
    static $pdo = null;

    if ($pdo) {
        try {
            $pdo->query('SELECT 1');
        } catch (PDOException $e) {
            $pdo = null; // Force reconnect
        }
    }

    if (!$pdo) {
        $pdo = new PDO($dsn, $user, $pass, [
            PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
            PDO::ATTR_TIMEOUT => 5
        ]);
    }

    return $pdo;
}

3-Layer Comment Spam Defense

v7 added deterministic spam defense before the Grok AI analysis:

Layer	Method	HTTP Response
Duplicate detection	SHA-256 of comment text, 24h window per user	409
Rate limiting	1 comment per post per user per 5 minutes	429
NG word filter	15 words (Japanese + English) → immediate reject + tier escalation	403
Grok AI analysis	Existing 5-tier system (hold → shadow → throttle → temp ban → perma ban)	200 (shadow)

15. What's Next: VAP Standard and Open Protocol

CAP-SRP is designed as a layer in a broader stack:

VAP (Verifiable AI Provenance — future open standard)
  └── CAP-SRP (protocol specification — to be published on GitHub)
       └── AIMomentz (reference implementation — live at aimomentz.ai)

Roadmap

Phase 2 (In progress):

OSS model activation via Together AI and fal.ai
Public Elo-style leaderboard (citable by researchers)
Private Arena for enterprise model evaluation
Research paper: "CAP-SRP: Provenance for AI Safety Decisions — A Reference Implementation Using an AI Battle Arena"

Phase 3 (Planned):

Open Arena — any company can submit their model for evaluation
Inclusion Arena SDK — embed evaluation in external apps
Enterprise contracts with custom CAP-SRP integration

How CAP-SRP Relates to C2PA

C2PA/Content Credentials certifies what was created — a cryptographic signature proving an image came from a specific model. CAP-SRP records what was refused and the full causal chain of how content came to exist. They're complementary:

C2PA: "This image was generated by DALL-E 3"
CAP-SRP: "DALL-E 3 refused 3 prompts before generating this one. Here's why, with cryptographic proof."

In a future where both are adopted, SRP evidence packs could be embedded as companion metadata alongside C2PA manifests.

Data Publication Strategy

20% open (research credibility) / 80% retained (commercial asset). This mirrors the LMArena model — open benchmarks create citations and credibility; the full dataset and evaluation infrastructure generate revenue.

Try It

Live arena: https://aimomentz.ai/ — vote on AI art battles right now

SRP Audit API:

curl "https://aimomentz.ai/api.php?action=srp_audit"
curl "https://aimomentz.ai/api.php?action=srp_refusals&limit=10"
curl "https://aimomentz.ai/api.php?action=cap_verify&from=1"

Admin Observatory: The admin dashboard (AIMomentz Observatory) includes a dedicated CAP-SRP Integrity section with chain length, refusal counts, type breakdown, and a one-click verification link.

Key Takeaways for Developers

You don't need a blockchain for immutable logging. A SHA-256 hash chain in a MySQL table gives you tamper evidence, ordering proof, and completeness guarantees with zero infrastructure overhead.
Record refusals, not just successes. Every API content-policy rejection is a data point. Record it with the same rigor as successful generations.
Causal chains > sequential logs. The causal_parent_seq field turns a flat log into a queryable provenance graph. This single column transforms the audit trail from "what happened" to "why did this specific output exist."
ToS compliance is an architecture decision. The data_license column and oss_only parameter aren't afterthoughts — they're load-bearing structures that determine what data can legally be sold.
Shared hosting is fine. ~8,000 lines of PHP, 18 MySQL tables, vanilla JS. The entire CAP-SRP engine is 534 lines. Complexity is not a feature.

AIMomentz v7 — AI Image Arena. The Global Benchmark for AI Art. ~8,000 lines of PHP+JS. CAP-SRP with 22 event types, 5 refusal categories, public verification APIs, and DPO-compatible dataset export. Running in production at aimomentz.ai.

Vote. Rank. Evolve.

AI War Fakes Hit Hundreds of Millions of Views While 20 States Race to Regulate

VeritasChain Standards Organization (VSO) — Sun, 08 Mar 2026 04:57:26 +0000

On March 8, 2026, seven simultaneous developments — from the battlefields of Iran to state legislatures across America, from India's Ministry of IT to Brussels, from federal courtrooms to Grammarly's AI feature — converged on the same structural truth: the world is racing to regulate AI-generated content, but every single approach still relies on the "Trust Us" model for the most critical question of all — what did the AI refuse to generate?

TL;DR

AI-generated fake war footage from the Iran conflict has reached hundreds of millions of views, and X's response relies on Community Notes — not cryptographic proof. Twenty-plus US states are simultaneously pushing AI provenance bills. India's IT Rules 2026 just created the world's first binding synthetic content mandate. The EU is finalizing its Article 50 transparency code. The TAKE IT DOWN Act enforcement deadline is 72 days away. AI-generated CSAM prosecutions are happening in 22 states. Grammarly got caught impersonating dead professors.

Every one of these developments demands proof of what AI systems did and didn't do. None of them provides a mechanism for verifiable refusal provenance — cryptographic proof that an AI system blocked harmful content.

This article:

Fact-checks all seven developments against primary sources (with corrections)
Maps the structural gap each reveals using CAP-SRP v1.1's four Completeness Invariants
Provides working Python code for the new v1.1 event types: ACCOUNT_ACTION, LAW_ENFORCEMENT_REFERRAL, POLICY_VERSION, GEN_WARN, GEN_ESCALATE, GEN_QUARANTINE
Shows how the expanded verification algorithm catches the exact failures these real-world cases expose

GitHub: veritaschain/cap-spec · veritaschain/cap-srp · License: CC BY 4.0

The Week That Proved the Gap
Event 1: AI War Fakes Hit Hundreds of Millions of Views
Event 2: Twenty-Plus States Push AI Provenance Laws Simultaneously
Event 3: India Enforces the World's First Binding Synthetic Content Mandate
Event 4: EU Finalizes Article 50 Transparency Code
Event 5: TAKE IT DOWN Act — 72 Days to Compliance
Event 6: AI-Generated CSAM Prosecutions in 22 States
Event 7: Grammarly's Dead Professor Problem
The Pattern: Seven Stories, One Structural Blind Spot
CAP-SRP v1.1: What Changed and Why
Building the v1.1 Event Types
The Four Completeness Invariants
Regulatory Mapping: Where Each Law Falls Short
What This Means for Developers Building AI Systems
Transparency Notes

The Week That Proved the Gap

Here's the uncomfortable truth about the first week of March 2026: every major AI governance development reinforced the same structural failure pattern.

Platforms announced new moderation policies — but backed them with Community Notes, not cryptographic proof. State legislatures mandated provenance labels — but only for content that was generated. India created the world's most prescriptive synthetic content law — but left refusal verification entirely to platform self-reporting. The EU drafted its transparency code — but explicitly avoided specifying which standard to use. Federal law demands takedowns — but can't verify that harmful generation was blocked in the first place.

The "Trust Us" model isn't failing at the margins. It's failing at the center, in real time, with hundreds of millions of people watching AI-generated war footage that no platform can cryptographically prove it tried to prevent.

Let's fact-check each development, then build the verification layer that's missing.

Event 1: AI War Fakes Hit Hundreds of Millions of Views

What happened

The US-Israel joint air strikes against Iran, codenamed "Operation Epic Fury," began on February 28, 2026 (not March 1, as some reports state). Within days, AI-generated fake combat footage, fabricated satellite imagery, and synthetic news clips flooded X, Instagram, and Facebook. BBC Verify identified a fabricated "satellite image" — purportedly showing the US Fifth Fleet Naval Base in Bahrain — distributed by Iran's Tehran Times, and confirmed it as AI-generated using Google's SynthID detection tool.

X responded on March 3 with a new policy: 90-day Creator Revenue Sharing suspension for users posting unlabeled AI-generated conflict content. X's head of product, Nikita Bier, described the enforcement mechanism on March 4, revealing that a single Pakistani user had operated 31 accounts (hacked accounts renamed to "Iran War Monitor" variants beginning February 27) to distribute AI-generated war footage at scale.

Fact-check verdict: ⚠️ Partially verified — two corrections needed

Correction 1: Conflict start date. Multiple authoritative sources — the UK House of Commons Library, CNN, Al Jazeera, UN News — confirm the strikes began February 28, 2026, not March 1. This is a two-day discrepancy that matters for timeline accuracy.

Correction 2: View count. BBC Verify's own reporting describes "hundreds of millions" of collective views across the most viral fakes. The three most prominent fabrications garnered over 100 million views combined. Claims of "billions" overstate the documented evidence.

All other claims — BBC Verify's SynthID identification, X's March 3 policy, the 31-account Pakistani operation — are fully confirmed against primary sources.

The verification gap

Here's what X's response looks like in practice:

Detection method: Community Notes (user mutual reporting)
Cryptographic proof of AI generation: ❌ None
Cryptographic proof of generation refusal: ❌ None  
External verification mechanism: ❌ None
Audit trail for enforcement decisions: ❌ None

X's policy creates three categories of response: monetization suspension, Community Notes labeling, and account removal. But the detection mechanism is purely social — other users must flag content as AI-generated. There's no cryptographic provenance, no hash-chain audit trail, no way for an external auditor to verify that X's AI systems (including Grok) actually refused to generate similar content when requested.

This is structurally identical to the Grok NCII crisis. The platform marks its own homework. The only difference is the scale: conflict disinformation reaches far more people than non-consensual intimate imagery, and the consequences of undetected AI fakes during an active military conflict are categorically different.

CAP-SRP fit: This is the core use case. If Completeness Invariant logging existed on the platforms generating this content, every generation attempt would have a recorded outcome — GEN, GEN_DENY, GEN_WARN, or GEN_ERROR. An external auditor could verify, cryptographically, whether requests for conflict footage were being blocked, and at what rate. Without it, we have only Community Notes.

Event 2: Twenty-Plus States Push AI Provenance Laws Simultaneously

What happened

Transparency Coalition AI (TCAI), a 501(c)(3) nonprofit that tracks state AI legislation, published its March 6, 2026 weekly update showing 20+ states simultaneously advancing chatbot safety and AI provenance bills. This is consistent with TCAI's February 27 update, which tracked bills in 30+ states — making "20+" a conservative figure.

Four bills stand out for their direct relevance to content provenance:

Oregon SB 1546 — Passed the House 52-0 on March 5 and was sent to the governor. Multiple sources (Oregon Legislature, KOIN 6 News, Oregon House Democrats, TCAI) confirm this as the first major AI chatbot safety bill to pass in 2026. It includes AI disclosure requirements, suicide prevention protocols, and annual reporting obligations.

Arizona SB 1786 — Mandates provenance data embedding in AI-generated media, including watermark and metadata tamper-resistance requirements. The bill exists and addresses provenance, but its claimed Senate passage date of March 3 could not be independently verified. As of TCAI's February 27 update, it was listed as "new this week" (newly introduced), making full Senate passage within four days unusually fast.

Illinois SB 3263 — The "AI Provenance Data Act," confirmed via the Illinois General Assembly's official website. Requires provenance labels, free reader tools, API access, and licensee maintenance of provenance capabilities.

New York A 6540 / S 6954 — The "Stop Deepfakes Act," addressing synthetic content provenance. Exists and is correctly described, though the "third reading March 4" milestone may apply to the companion bill S 6955 (AI Training Data Transparency Act) rather than S 6954 — a likely bill-number mix-up between related bills from the same sponsors.

Fact-check verdict: ⚠️ Mostly verified — two details unconfirmed

Oregon SB 1546 (52-0, March 5): ✅ Fully confirmed
Arizona SB 1786 passage date: ⚠️ Unverified — bill exists, passage date unconfirmed
Illinois SB 3263: ✅ Fully confirmed
New York A 6540/S 6954 third reading: ⚠️ Likely bill-number confusion with S 6955

The verification gap

Every one of these bills shares the same structural limitation: they mandate provenance for content that was generated — labels, metadata, watermarks, disclosure. None of them address the inverse question: can the platform prove that harmful content was refused?

Oregon SB 1546 requires annual reporting on AI safety measures — but the reporting is self-attested. Arizona SB 1786 mandates provenance data embedding — but only for content that exits the system. Illinois SB 3263 requires provenance labels and API access — but only for produced content.

The refusal side of the ledger is entirely absent.

What these bills require:
  ✅ "This content was AI-generated" (label)
  ✅ "This content has provenance metadata" (C2PA-style)
  ✅ "This platform has safety measures" (annual report)

What these bills cannot verify:
  ❌ "This request was blocked" (refusal record)
  ❌ "This account was suspended for violations" (enforcement record)  
  ❌ "The safety policy in effect at decision time was X" (policy version)

CAP-SRP fit: These bills occupy the C2PA layer — proving what was generated. CAP-SRP's Safe Refusal Provenance (SRP) layer is the complement: proving what was refused. Together, they close the audit loop. Separately, provenance labels without refusal logs allow platforms to label what they produce while offering no verification of what they blocked.

Event 3: India Enforces the World's First Binding Synthetic Content Mandate

What happened

India's IT Rules Amendment 2026 (Gazette Notification G.S.R. 120(E)), signed by Joint Secretary Ajit Kumar, was notified on February 10 and took effect February 20, 2026. It is the first national regulation to create a binding legal definition of "synthetically generated information" (SGI) — defined in the new Rule 2(1)(wa) — and mandate platform compliance with specific provenance and takedown requirements.

Key provisions, verified against the Gazette, Mondaq, LiveLaw, Bhatt & Joshi Associates, and the Internet Freedom Foundation:

Permanent provenance metadata must accompany all AI-generated content
User-visible labels must be applied by default
Anti-tampering measures for provenance metadata are required
3-hour deepfake takedown deadline (reduced from 36 hours)
2-hour deadline for non-consensual intimate imagery (reduced from 24 hours)
Safe harbor immunity loss under Section 79 for non-compliance

Fact-check verdict: ⚠️ One claim unsupported

All provisions above are fully verified across multiple legal analyses. However, one claim in the daily watch report — that C-DAC's detection tool has "up to 89% accuracy" — cannot be verified. No public source cites this figure. C-DAC (Centre for Development of Advanced Computing) has deepfake detection programs, but neither C-DAC nor the similar C-DOT (Centre for Development of Telematics) has published this accuracy figure publicly. The Internet Freedom Foundation has actually criticized the rules for overestimating detection tool reliability. This figure should be treated as unverified.

The verification gap

India's IT Rules are the world's most prescriptive synthetic content mandate. They go further than any other jurisdiction in requiring permanent provenance, visible labeling, and strict takedown timelines. But they share the same blind spot:

India IT Rules 2026 — What's covered:
  ✅ Definition of synthetic content (SGI)
  ✅ Provenance metadata (permanent)
  ✅ Visible labels (default-on)
  ✅ Anti-tampering measures
  ✅ Takedown deadlines (3h / 2h)
  ✅ Safe harbor consequences

What's not covered:
  ❌ Refusal logging
  ❌ Completeness verification
  ❌ External audit of moderation decisions
  ❌ Cryptographic proof of enforcement
  ❌ Policy version provenance

A platform operating under these rules can label every piece of AI content it produces, take down flagged content within 3 hours, and still have no mechanism for proving it refused to generate harmful content in the first place. The "Trust Us" model persists inside the strongest regulatory framework on Earth.

CAP-SRP fit: India's SGI framework is the natural lower layer. CAP-SRP's Completeness Invariant can function as an upper layer — ensuring that every generation attempt has a recorded outcome, even when the outcome is refusal. The combination would create the world's first end-to-end verifiable content governance stack.

Event 4: EU Finalizes Article 50 Transparency Code

What happened

The EU AI Act's Article 50 transparency obligations become enforceable on August 2, 2026 — exactly 24 months after the Act's entry into force on August 1, 2024. The European Commission's Code of Practice on AI-Generated Content Transparency, first drafted December 17, 2025, is progressing toward a June 2026 final version.

Key provisions from the first draft, verified via Jones Day, Cooley, Shibolet & Co., Pearl Cohen, and Bird & Bird:

Multi-layer marking approach: metadata + invisible watermarks (+ fingerprinting/logging as optional elements)
Technology-neutral: no specific standard (C2PA, SynthID, etc.) is endorsed, though C2PA is mentioned as an example
Default-on visible labels required for providers
Detection tools (including API access) must be offered
Comprehensive compliance documentation (including test results) is required

Important nuance: The second draft (approximately March 2026) revised the approach to a "two-layered marking" system focused on secured metadata and watermarking, with fingerprinting/logging made optional rather than required. The Jones Day and Bird & Bird analyses flag possible delays from the EU AI Digital Omnibus initiative.

Fact-check verdict: ✅ Fully verified (with nuance noted)

All claims confirmed across multiple law firm analyses. The June 2026 timeline for final version is consistent across sources, though potential delays are flagged.

The verification gap

The EU's approach is the most architecturally sophisticated of any jurisdiction — the multi-layer model explicitly includes "logging" as a component. This is closer to CAP-SRP's territory than any other regulation. But the critical word is optional. Logging is not required. And even where logging exists, the Code of Practice doesn't specify:

What must be logged (generation? refusal? both?)
What integrity guarantees the logs must have (hash chain? Merkle tree? signatures?)
How external parties can verify the logs
What happens when logs are absent or incomplete

CAP-SRP fit: Article 50's "logging or fingerprinting" element is the natural integration point. Article 12's high-risk AI logging requirements create additional alignment. The IETF draft-kamimura-scitt-refusal-events specification (currently at -02) provides the encoding-agnostic application profile that could satisfy both Article 50's logging element and Article 12's record-keeping requirements. The gap is enforcement specificity — the Code says "log," but doesn't say what that means. CAP-SRP defines exactly what it means.

Event 5: TAKE IT DOWN Act — 72 Days to Compliance

What happened

The TAKE IT DOWN Act (signed into law May 19, 2025) creates a one-year compliance window ending May 19, 2026 — 72 days from today. Covered platforms must establish notice-and-removal processes with a 48-hour removal window for non-consensual intimate images upon receiving a valid request. The Act has two distinctive provisions: it expands FTC enforcement authority to nonprofit organizations (ordinarily outside FTC Act jurisdiction), and it covers both real and AI-generated intimate imagery.

Fact-check verdict: ✅ Fully verified

Confirmed against Congress.gov, Wiley Law, Skadden, Latham & Watkins, and ZwillGen analyses.

The verification gap

The TAKE IT DOWN Act creates a clear legal obligation to remove content. But it creates no obligation — and no mechanism — to prove that content was never generated in the first place.

Consider the lifecycle:

1. User requests AI system to generate NCII
2. AI system should refuse → but where's the proof?
3. If NCII appears online, platform must remove within 48h → verifiable
4. Platform must also remove "reasonably similar" copies → verifiable
5. But did the AI system refuse the original request? → NOT verifiable

Step 2 is the gap. The Act governs what happens after harmful content exists. It cannot reach backward to verify that generation was blocked. This is exactly the gap the Grok NCII crisis exposed — 4.4 million images generated in 9 days, 41% sexualized, with no mechanism to verify what Grok's safety systems did or didn't do during that period.

CAP-SRP fit: SRP's Verifiable Refusal Record is the technical answer to step 2. A GEN_DENY event with RiskCategory: NCII_RISK creates a cryptographically signed, hash-chained, externally anchored record that the request was blocked. A TakedownRelevance flag (new in v1.1) cross-references the refusal to TAKE IT DOWN Act applicability. Without this, the Act's enforcement mechanism starts too late.

Event 6: AI-Generated CSAM Prosecutions in 22 States

What happened

NBC News published a February 28 investigation identifying 36 criminal cases in 22 states related to AI-generated CSAM, with all completed cases resulting in convictions (though most remain active). State attorneys general are escalating enforcement, as confirmed by Morgan Lewis's January 2026 analysis.

Fact-check verdict: ⚠️ Key statistic requires critical context

The NBC investigation and prosecution data are confirmed. However, one widely cited statistic requires major context:

The claim that NCMEC received 485,000 AI-CSAM reports in H1 2025 (a 624% year-over-year increase) is technically based on NCMEC CyberTipline data, but it is deeply misleading. Stanford researcher Riana Pfefferkorn and Bloomberg reporting revealed that approximately 380,000 of those reports (~80%) came from Amazon and involved zero AI-generated CSAM — they were hash-matches to known traditional CSAM found during Amazon's AI training data scanning. NCMEC's own CyberTipline executive confirmed that excluding Amazon, AI-related reports came in "really, really small numbers."

The 624% figure is also methodologically suspect: it compares H1 2025 (485,000) against full-year 2024 (67,000), mixing time periods.

This doesn't diminish the seriousness of AI-generated CSAM — 36 prosecutions in 22 states is a real enforcement pattern. But using inflated statistics undermines the credibility of the argument. Accuracy matters, especially on this topic.

The verification gap

The Grok incident remains the clearest illustration of this gap. Over 9 days in early 2025, Grok generated an estimated 4.4 million images, with approximately 41% classified as sexualized (per the New York Times's conservative estimate; the Center for Countering Digital Hate's broader analysis found 65%). During this period, there was no external mechanism to verify:

How many generation requests were blocked
What safety policies were in effect
Whether safety thresholds were changed during the incident
Whether accounts flagged for violations were referred to law enforcement

Every one of these questions maps to a specific CAP-SRP v1.1 event type. And the absence of these records is exactly what makes the "Trust Us" model untenable for CSAM enforcement.

Event 7: Grammarly's Dead Professor Problem

What happened

Grammarly's AI "Expert Review" feature (launched August 2025 as part of its AI agents suite) was discovered to be using real identities — journalists, academics, and deceased persons — without permission for its AI review personas.

The controversy broke on March 2 when medieval historian Verena Krebs flagged that deceased Cambridge professor David Abulafia (died January 2026) was listed as an available "expert reviewer." Carl Sagan (died 1996) was also available. The Verge's March 6 investigation revealed its own editorial staff — including editor-in-chief Nilay Patel and editor-at-large David Pierce — were being impersonated, along with journalists from Bloomberg, the New York Times, The Atlantic, and Wired.

For context: Grammarly rebranded as Superhuman on October 29, 2025 following a series of acquisitions. Academics described the practice as "digital necromancy."

Fact-check verdict: ✅ Fully verified

Confirmed via The Verge (March 6), Wired (March 5), Futurism, Chronicle of Higher Education, Boing Boing, and A.V. Club reporting.

The verification gap

This item extends the provenance question beyond media generation into AI agent identity governance. The core issue isn't just that Grammarly used real identities — it's that there is no audit trail showing:

Which identities were used as AI personas
When they were added or removed
Whether permission was obtained or refused
What the decision process was for including deceased persons

This is structurally analogous to the content generation audit problem. The system made decisions about what to generate (persona assignments) with no externally verifiable record of those decisions.

CAP-SRP fit: While identity governance extends beyond CAP-SRP's core scope of content generation, the underlying principle — verifiable audit trails for AI system decisions — is the same. A POLICY_VERSION event documenting the persona inclusion policy, combined with GEN_ATTEMPT/GEN events tracking which personas were invoked and when, would provide exactly the audit trail that's missing.

The Pattern: Seven Stories, One Structural Blind Spot

Let's map all seven events against the same question set:

                     Proves    Proves     External    Policy
Event                content   refusal    audit       version
                     created?  happened?  possible?   tracked?
─────────────────────────────────────────────────────────────
1. Iran AI fakes     ❌*       ❌         ❌          ❌
2. State bills       ✅ (req)  ❌         ❌          ❌
3. India IT Rules    ✅ (req)  ❌         ❌          ❌
4. EU Art. 50        ✅ (req)  ❌         Partial**   ❌
5. TAKE IT DOWN      ✅ (del)  ❌         ❌          ❌
6. AI CSAM           ❌        ❌         ❌          ❌
7. Grammarly         ❌        ❌         ❌          ❌

* X relies on Community Notes, not cryptographic proof
** EU Code includes "logging" as optional element
(req) = requirement exists but verification is self-attested
(del) = proves deletion, not prevention

Seven different events. Four continents. Billions of dollars in regulatory compliance costs. And the same column — "Proves refusal happened?" — is empty in every row.

This is the gap CAP-SRP fills.

CAP-SRP v1.1: What Changed and Why

CAP-SRP v1.1.0 (released March 5, 2026) was directly shaped by the real-world failures documented above. Here's what changed:

New Event Types

Event Type	Motivated By	What It Logs
`ACCOUNT_ACTION`	Tumbler Ridge shooting (Feb 2026) — account banned but no LE referral	Account bans, suspensions, rate limits, reinstatements
`LAW_ENFORCEMENT_REFERRAL`	Same — was the LE notification threshold assessed?	Threshold assessments and referral decisions
`POLICY_VERSION`	Grok NCII crisis — were safety thresholds lowered?	Tamper-evident versioning of safety policies

Formalized Intermediate States

Event Type	Problem It Solves
`GEN_WARN`	Content allowed with safety warning — was this logged?
`GEN_ESCALATE`	Sent for human review — was the outcome recorded?
`GEN_QUARANTINE`	Content held before delivery — was it ever released or denied?

New Completeness Invariants

v1.0 had one invariant. v1.1 has four:

Invariant 1 (Primary):
  ∑ GEN_ATTEMPT = ∑ GEN + ∑ GEN_DENY + ∑ GEN_ERROR
  (where ∑ GEN includes GEN_WARN)

Invariant 2 (Escalation Resolution):
  ∑ GEN_ESCALATE = ∑ ESCALATION_RESOLVED
  Every escalation must resolve. Unresolved > 72h = violation.

Invariant 3 (Quarantine Resolution):
  ∑ GEN_QUARANTINE = ∑ QUARANTINE_RELEASED + ∑ QUARANTINE_DENIED
  No permanent unresolved quarantine states.

Invariant 4 (Policy Anchoring Precedence):
  anchor_timestamp(POLICY_VERSION) ≤ EffectiveFrom
  Policies must be externally anchored BEFORE they take effect.
  Prevents retroactive policy creation.

New Risk Category

VIOLENCE_PLANNING — added to address cases where content doesn't depict violence directly but facilitates planning of violent acts. This was motivated by the Tumbler Ridge pattern, where the AI interaction was preparatory, not generative of violent imagery.

Building the v1.1 Event Types

Let's implement the new event types. All code uses the same cryptographic primitives as v1.0 (Ed25519 signatures, SHA-256 hash chains) and builds on the existing CAPEvent base class.

The Base: v1.1 Event Enumerations

from enum import Enum
from dataclasses import dataclass, field
from typing import Optional, List
from datetime import datetime, timezone
import hashlib
import json
import uuid


class EventType(str, Enum):
    """All CAP-SRP v1.1 event types."""
    # Core generation events (v1.0)
    GEN_ATTEMPT = "GEN_ATTEMPT"
    GEN = "GEN"
    GEN_DENY = "GEN_DENY"
    GEN_ERROR = "GEN_ERROR"
    # Intermediate-state events (v1.1 formalized)
    GEN_WARN = "GEN_WARN"
    GEN_ESCALATE = "GEN_ESCALATE"
    GEN_QUARANTINE = "GEN_QUARANTINE"
    # Account and policy events (v1.1 new)
    ACCOUNT_ACTION = "ACCOUNT_ACTION"
    LAW_ENFORCEMENT_REFERRAL = "LAW_ENFORCEMENT_REFERRAL"
    POLICY_VERSION = "POLICY_VERSION"


class RiskCategory(str, Enum):
    """Risk categories including v1.1 additions."""
    CSAM_RISK = "CSAM_RISK"
    NCII_RISK = "NCII_RISK"
    MINOR_SEXUALIZATION = "MINOR_SEXUALIZATION"
    REAL_PERSON_DEEPFAKE = "REAL_PERSON_DEEPFAKE"
    VIOLENCE_EXTREME = "VIOLENCE_EXTREME"
    VIOLENCE_PLANNING = "VIOLENCE_PLANNING"        # v1.1 NEW
    HATE_CONTENT = "HATE_CONTENT"
    TERRORIST_CONTENT = "TERRORIST_CONTENT"
    SELF_HARM_PROMOTION = "SELF_HARM_PROMOTION"
    COPYRIGHT_VIOLATION = "COPYRIGHT_VIOLATION"
    COPYRIGHT_STYLE_MIMICRY = "COPYRIGHT_STYLE_MIMICRY"
    OTHER = "OTHER"


class ActionType(str, Enum):
    """Account action types (v1.1)."""
    SUSPEND = "SUSPEND"
    BAN = "BAN"
    RATE_LIMIT = "RATE_LIMIT"
    REINSTATE = "REINSTATE"
    FLAG_FOR_REVIEW = "FLAG_FOR_REVIEW"


class RiskScoreBand(str, Enum):
    LOW = "LOW"
    MEDIUM = "MEDIUM"
    HIGH = "HIGH"
    CRITICAL = "CRITICAL"


class DecisionMechanism(str, Enum):
    AUTOMATED = "AUTOMATED"
    HUMAN_INITIATED = "HUMAN_INITIATED"
    HUMAN_CONFIRMED_AUTOMATED = "HUMAN_CONFIRMED_AUTOMATED"


class EscalationReason(str, Enum):
    CLASSIFIER_CONFIDENCE_LOW = "CLASSIFIER_CONFIDENCE_LOW"
    JURISDICTIONAL_AMBIGUITY = "JURISDICTIONAL_AMBIGUITY"
    NOVEL_CONTENT_TYPE = "NOVEL_CONTENT_TYPE"
    LEGAL_REVIEW_REQUIRED = "LEGAL_REVIEW_REQUIRED"
    OTHER = "OTHER"


class ReviewerType(str, Enum):
    HUMAN_TRUST_AND_SAFETY = "HUMAN_TRUST_AND_SAFETY"
    LEGAL = "LEGAL"
    EXTERNAL_AUDITOR = "EXTERNAL_AUDITOR"


class MultiModalType(str, Enum):
    TEXT = "TEXT"
    IMAGE = "IMAGE"
    VIDEO = "VIDEO"
    AUDIO = "AUDIO"
    MULTIMODAL = "MULTIMODAL"

ACCOUNT_ACTION: Logging What Happened to the Account

This is the event that would have changed the Tumbler Ridge case. When a platform bans an account, the question isn't just "was the account banned?" — it's "was law enforcement notified, and can you prove the threshold assessment was made?"

@dataclass
class LawEnforcementAssessment:
    """Sub-object for LE threshold evaluation.

    Captures the decision of whether flagged activity
    meets the threshold for law enforcement notification.
    """
    threshold_met: bool
    threshold_definition_ref: str       # EventID of POLICY_VERSION
    assessment_timestamp: str           # RFC 3339
    assessor_type: str                  # AUTOMATED | HUMAN_TRUST_AND_SAFETY | LEGAL_COUNSEL

    def to_dict(self) -> dict:
        return {
            "ThresholdMet": self.threshold_met,
            "ThresholdDefinitionRef": self.threshold_definition_ref,
            "AssessmentTimestamp": self.assessment_timestamp,
            "AssessorType": self.assessor_type,
        }


@dataclass
class AccountActionEvent:
    """CAP-SRP v1.1 ACCOUNT_ACTION event.

    Records account-level enforcement decisions with
    cryptographic proof of law enforcement assessment.
    """
    event_id: str
    chain_id: str
    prev_hash: Optional[str]
    timestamp: str
    event_type: str = "ACCOUNT_ACTION"
    hash_algo: str = "SHA256"
    sign_algo: str = "ED25519"

    # v1.1 fields
    account_hash: str = ""              # SHA-256(HMAC(account_id, per_user_key))
    action_type: str = ""               # SUSPEND | BAN | RATE_LIMIT | REINSTATE | FLAG_FOR_REVIEW
    triggering_event_refs: List[str] = field(default_factory=list)
    policy_version_ref: str = ""        # EventID of governing POLICY_VERSION
    risk_score_band: str = ""           # LOW | MEDIUM | HIGH | CRITICAL
    decision_mechanism: str = ""        # AUTOMATED | HUMAN_INITIATED | HUMAN_CONFIRMED_AUTOMATED
    le_assessment: Optional[LawEnforcementAssessment] = None

    event_hash: str = ""
    signature: str = ""

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               account_id: str, hmac_key: bytes,
               action_type: ActionType,
               triggering_refs: List[str],
               policy_version_ref: str,
               risk_band: RiskScoreBand,
               decision_mechanism: DecisionMechanism,
               le_assessment: Optional[LawEnforcementAssessment] = None
               ) -> "AccountActionEvent":
        """Create ACCOUNT_ACTION with privacy-preserving account hash."""
        import hmac as hmac_mod

        # Privacy: HMAC prevents cross-provider correlation
        account_hash = "sha256:" + hmac_mod.new(
            hmac_key, account_id.encode(), hashlib.sha256
        ).hexdigest()

        return cls(
            event_id=str(uuid.uuid7()) if hasattr(uuid, 'uuid7') else str(uuid.uuid4()),
            chain_id=chain_id,
            prev_hash=prev_hash,
            timestamp=datetime.now(timezone.utc).isoformat(),
            account_hash=account_hash,
            action_type=action_type.value,
            triggering_event_refs=triggering_refs,
            policy_version_ref=policy_version_ref,
            risk_score_band=risk_band.value,
            decision_mechanism=decision_mechanism.value,
            le_assessment=le_assessment,
        )

    def to_dict(self) -> dict:
        d = {
            "EventID": self.event_id,
            "ChainID": self.chain_id,
            "PrevHash": self.prev_hash,
            "Timestamp": self.timestamp,
            "EventType": self.event_type,
            "HashAlgo": self.hash_algo,
            "SignAlgo": self.sign_algo,
            "AccountHash": self.account_hash,
            "ActionType": self.action_type,
            "TriggeringEventRefs": self.triggering_event_refs,
            "PolicyVersionRef": self.policy_version_ref,
            "RiskScoreBand": self.risk_score_band,
            "DecisionMechanism": self.decision_mechanism,
        }
        if self.le_assessment:
            d["LawEnforcementAssessment"] = self.le_assessment.to_dict()
        d["EventHash"] = self.event_hash
        d["Signature"] = self.signature
        return d

POLICY_VERSION: Tamper-Evident Policy Management

This is Invariant 4's enforcement mechanism. If a platform changes its safety thresholds — as was suspected during the Grok crisis — the policy change must be externally anchored before it takes effect. Retroactive policy creation is a compliance violation.

@dataclass
class PolicyVersionEvent:
    """CAP-SRP v1.1 POLICY_VERSION event.

    Creates tamper-evident record of safety policy changes.
    External anchor must predate EffectiveFrom (Invariant 4).
    """
    event_id: str
    chain_id: str
    prev_hash: Optional[str]
    timestamp: str
    event_type: str = "POLICY_VERSION"
    hash_algo: str = "SHA256"
    sign_algo: str = "ED25519"

    policy_id: str = ""
    policy_hash: str = ""               # SHA-256 of full policy document
    effective_from: str = ""             # RFC 3339 — when policy takes effect
    supersedes: Optional[str] = None    # EventID of previous POLICY_VERSION
    change_summary_hash: str = ""       # SHA-256 of change description
    approval_chain: List[str] = field(default_factory=list)
    external_anchor_ref: Optional[str] = None  # RFC 3161 timestamp token

    event_hash: str = ""
    signature: str = ""

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               policy_id: str, policy_document: str,
               effective_from: str, supersedes: Optional[str],
               change_summary: str,
               approval_chain: List[str]) -> "PolicyVersionEvent":
        """Create a new POLICY_VERSION event."""
        return cls(
            event_id=str(uuid.uuid4()),
            chain_id=chain_id,
            prev_hash=prev_hash,
            timestamp=datetime.now(timezone.utc).isoformat(),
            policy_id=policy_id,
            policy_hash="sha256:" + hashlib.sha256(
                policy_document.encode()
            ).hexdigest(),
            effective_from=effective_from,
            supersedes=supersedes,
            change_summary_hash="sha256:" + hashlib.sha256(
                change_summary.encode()
            ).hexdigest(),
            approval_chain=approval_chain,
        )

    def to_dict(self) -> dict:
        return {
            "EventID": self.event_id,
            "ChainID": self.chain_id,
            "PrevHash": self.prev_hash,
            "Timestamp": self.timestamp,
            "EventType": self.event_type,
            "HashAlgo": self.hash_algo,
            "SignAlgo": self.sign_algo,
            "PolicyID": self.policy_id,
            "PolicyHash": self.policy_hash,
            "EffectiveFrom": self.effective_from,
            "Supersedes": self.supersedes,
            "ChangeSummaryHash": self.change_summary_hash,
            "ApprovalChain": self.approval_chain,
            "ExternalAnchorRef": self.external_anchor_ref,
            "EventHash": self.event_hash,
            "Signature": self.signature,
        }

GEN_WARN, GEN_ESCALATE, GEN_QUARANTINE: The Intermediate States

Real content moderation isn't binary. Between "allow" and "block" lies a continuum of intermediate decisions — warn, escalate to human review, hold for post-generation inspection. v1.1 formalizes these states.

@dataclass
class GenWarnEvent:
    """Content allowed with a safety warning.

    Counts as GEN (outcome) in the Primary Completeness Invariant.
    Warning text itself is NOT stored — only its hash.
    """
    event_id: str
    chain_id: str
    prev_hash: Optional[str]
    timestamp: str
    event_type: str = "GEN_WARN"

    attempt_id: str = ""
    content_hash: str = ""              # SHA-256 of generated content
    warn_message_hash: str = ""         # SHA-256 of warning shown to user
    risk_category: str = ""
    risk_score: float = 0.0
    applied_policy_version_ref: str = ""
    multi_modal_type: str = ""

    event_hash: str = ""
    signature: str = ""

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               attempt_id: str, content: bytes,
               warn_message: str, risk_category: RiskCategory,
               risk_score: float, policy_ref: str,
               modal_type: MultiModalType) -> "GenWarnEvent":
        return cls(
            event_id=str(uuid.uuid4()),
            chain_id=chain_id,
            prev_hash=prev_hash,
            timestamp=datetime.now(timezone.utc).isoformat(),
            attempt_id=attempt_id,
            content_hash="sha256:" + hashlib.sha256(content).hexdigest(),
            warn_message_hash="sha256:" + hashlib.sha256(
                warn_message.encode()
            ).hexdigest(),
            risk_category=risk_category.value,
            risk_score=risk_score,
            applied_policy_version_ref=policy_ref,
            multi_modal_type=modal_type.value,
        )


@dataclass
class GenEscalateEvent:
    """Request sent for human review — a PENDING state.

    Must be resolved by GEN or GEN_DENY (Invariant 2).
    Unresolved > 72h = compliance violation.
    """
    event_id: str
    chain_id: str
    prev_hash: Optional[str]
    timestamp: str
    event_type: str = "GEN_ESCALATE"

    attempt_id: str = ""
    escalation_reason: str = ""
    reviewer_type: str = ""
    escalation_timestamp: str = ""
    resolution_ref: Optional[str] = None  # Populated when resolved
    applied_policy_version_ref: str = ""

    event_hash: str = ""
    signature: str = ""

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               attempt_id: str,
               reason: EscalationReason,
               reviewer: ReviewerType,
               policy_ref: str) -> "GenEscalateEvent":
        now = datetime.now(timezone.utc).isoformat()
        return cls(
            event_id=str(uuid.uuid4()),
            chain_id=chain_id,
            prev_hash=prev_hash,
            timestamp=now,
            attempt_id=attempt_id,
            escalation_reason=reason.value,
            reviewer_type=reviewer.value,
            escalation_timestamp=now,
            applied_policy_version_ref=policy_ref,
        )


@dataclass
class GenQuarantineEvent:
    """Content generated but held before delivery — a PENDING state.

    Must be resolved by EXPORT or GEN_DENY (Invariant 3).
    ContentHash enables TAKE IT DOWN Act duplicate detection
    without retaining harmful content in the audit log.
    """
    event_id: str
    chain_id: str
    prev_hash: Optional[str]
    timestamp: str
    event_type: str = "GEN_QUARANTINE"

    attempt_id: str = ""
    content_hash: str = ""
    quarantine_reason: str = ""
    expiry_policy: str = ""             # AUTO_RELEASE | REQUIRES_HUMAN_APPROVAL | PERMANENT
    release_ref: Optional[str] = None   # Populated when resolved
    applied_policy_version_ref: str = ""

    event_hash: str = ""
    signature: str = ""

    @classmethod
    def create(cls, chain_id: str, prev_hash: Optional[str],
               attempt_id: str, content: bytes,
               reason: str, expiry_policy: str,
               policy_ref: str) -> "GenQuarantineEvent":
        return cls(
            event_id=str(uuid.uuid4()),
            chain_id=chain_id,
            prev_hash=prev_hash,
            timestamp=datetime.now(timezone.utc).isoformat(),
            attempt_id=attempt_id,
            content_hash="sha256:" + hashlib.sha256(content).hexdigest(),
            quarantine_reason=reason,
            expiry_policy=expiry_policy,
            applied_policy_version_ref=policy_ref,
        )

The Four Completeness Invariants

Here's the verification algorithm that enforces all four invariants simultaneously. This is the mathematical anchor — the thing that makes CAP-SRP's guarantees meaningful rather than aspirational.

from dataclasses import dataclass
from datetime import datetime, timedelta
from typing import List, Tuple, Optional


@dataclass
class VerificationResult:
    """Result of completeness invariant verification."""
    valid: bool
    # Primary invariant
    unmatched_attempts: List[str]
    orphan_outcomes: List[str]
    total_attempts: int
    total_outcomes: int
    # Escalation invariant (v1.1)
    unresolved_escalations: List[str]
    # Quarantine invariant (v1.1)
    unresolved_quarantines: List[str]
    # Policy anchoring invariant (v1.1)
    retroactive_policies: List[str]
    # Summary
    errors: List[str]

    def __str__(self) -> str:
        if self.valid:
            return (
                f"✅ All four invariants verified. "
                f"{self.total_attempts} attempts, "
                f"{self.total_outcomes} outcomes."
            )
        return (
            f"❌ Invariant violation(s) detected:\n"
            + "\n".join(f"  • {e}" for e in self.errors)
        )


def get_anchor_timestamp(anchor_ref: Optional[str]) -> Optional[datetime]:
    """Look up external anchor timestamp.

    In production, this queries the RFC 3161 TSA or SCITT
    transparency service. Here, we parse the reference.
    """
    if anchor_ref is None:
        return None
    # Placeholder: in production, resolve against TSA
    return datetime.fromisoformat(anchor_ref) if anchor_ref else None


def verify_completeness_v1_1(
    events: List[dict],
    time_window: Tuple[datetime, datetime],
    escalation_grace: timedelta = timedelta(hours=72),
) -> VerificationResult:
    """
    Verify all four CAP-SRP v1.1 Completeness Invariants.

    Invariant 1: Every GEN_ATTEMPT has exactly one outcome
    Invariant 2: Every GEN_ESCALATE is resolved
    Invariant 3: Every GEN_QUARANTINE is resolved
    Invariant 4: Every POLICY_VERSION is anchored before EffectiveFrom

    All checks are O(n) time and O(n) space.
    """
    errors = []
    window_start, window_end = time_window

    # Filter events to time window
    filtered = [
        e for e in events
        if window_start <= datetime.fromisoformat(e["Timestamp"]) <= window_end
    ]

    # ── Invariant 1: Primary (attempt → outcome pairing) ──────────
    attempts = {
        e["EventID"]: e for e in filtered
        if e["EventType"] == "GEN_ATTEMPT"
    }

    outcome_types = {
        "GEN", "GEN_WARN", "GEN_DENY", "GEN_ERROR",
        "GEN_ESCALATE", "GEN_QUARANTINE"
    }

    outcomes = [e for e in filtered if e["EventType"] in outcome_types]
    matched_attempts = set()
    orphan_outcomes = []

    for outcome in outcomes:
        attempt_id = outcome.get("AttemptID")
        if attempt_id in attempts:
            if attempt_id in matched_attempts:
                errors.append(
                    f"DUPLICATE_OUTCOME: Multiple outcomes for attempt {attempt_id}"
                )
            matched_attempts.add(attempt_id)
        else:
            orphan_outcomes.append(outcome["EventID"])

    unmatched = list(set(attempts.keys()) - matched_attempts)
    if unmatched:
        errors.append(
            f"UNMATCHED_ATTEMPTS: {len(unmatched)} attempts have no outcome"
        )
    if orphan_outcomes:
        errors.append(
            f"ORPHAN_OUTCOMES: {len(orphan_outcomes)} outcomes have no attempt"
        )

    # ── Invariant 2: Escalation resolution ─────────────────────────
    escalations = {
        e["EventID"]: e for e in filtered
        if e["EventType"] == "GEN_ESCALATE"
    }

    now = datetime.now()
    unresolved_escalations = [
        eid for eid, e in escalations.items()
        if e.get("ResolutionRef") is None
        and (now - datetime.fromisoformat(e["Timestamp"])) > escalation_grace
    ]

    if unresolved_escalations:
        errors.append(
            f"UNRESOLVED_ESCALATIONS: {len(unresolved_escalations)} "
            f"escalations unresolved beyond {escalation_grace}"
        )

    # ── Invariant 3: Quarantine resolution ─────────────────────────
    quarantines = {
        e["EventID"]: e for e in filtered
        if e["EventType"] == "GEN_QUARANTINE"
    }

    unresolved_quarantines = [
        eid for eid, e in quarantines.items()
        if e.get("ReleaseRef") is None
    ]

    if unresolved_quarantines:
        errors.append(
            f"UNRESOLVED_QUARANTINES: {len(unresolved_quarantines)} "
            f"quarantined items without resolution"
        )

    # ── Invariant 4: Policy anchoring precedence ───────────────────
    policy_versions = [
        e for e in filtered
        if e["EventType"] == "POLICY_VERSION"
    ]

    retroactive_policies = []
    for pv in policy_versions:
        anchor_ts = get_anchor_timestamp(pv.get("ExternalAnchorRef"))
        effective = datetime.fromisoformat(pv["EffectiveFrom"])
        if anchor_ts and anchor_ts > effective:
            retroactive_policies.append(pv["EventID"])

    if retroactive_policies:
        errors.append(
            f"RETROACTIVE_POLICIES: {len(retroactive_policies)} "
            f"policies anchored after their effective date"
        )

    return VerificationResult(
        valid=len(errors) == 0,
        unmatched_attempts=unmatched,
        orphan_outcomes=orphan_outcomes,
        total_attempts=len(attempts),
        total_outcomes=len(outcomes),
        unresolved_escalations=unresolved_escalations,
        unresolved_quarantines=unresolved_quarantines,
        retroactive_policies=retroactive_policies,
        errors=errors,
    )

What Each Invariant Catches

Let's map the invariants back to the real-world failures:

Invariant 1 (Primary — attempt/outcome pairing):
  → Iran fake footage: Were generation requests for conflict imagery
    blocked? Count attempts vs. denials for REAL_PERSON_DEEPFAKE
    and VIOLENCE_EXTREME categories.
  → Grok NCII crisis: 4.4M images in 9 days. What % were
    GEN_DENY? Without the invariant, we'll never know.

Invariant 2 (Escalation resolution):
  → Grammarly personas: Were identity-use decisions escalated
    to legal review? Were escalations resolved or abandoned?
  → State bill compliance: Annual reports claim "human review"
    processes exist. Prove escalations resolve within 72h.

Invariant 3 (Quarantine resolution):
  → TAKE IT DOWN Act: Content held for review must be either
    released or denied. No permanent "quarantine" hiding.
  → India 3-hour deadline: Quarantined content must resolve
    within the regulatory timeline.

Invariant 4 (Policy anchoring precedence):
  → Did Grok's safety thresholds change during the crisis?
    Policies must be anchored BEFORE they take effect.
  → Did X change moderation policies mid-conflict?
    Retroactive policy creation is now detectable.

Regulatory Mapping: Where Each Law Falls Short

Here's the comprehensive mapping of all seven developments against CAP-SRP v1.1's capabilities:

┌──────────────────────────┬──────────────┬──────────────┬──────────────┐
│ Regulation / Event       │ C2PA Layer   │ SRP Layer    │ v1.1 Events  │
│                          │ (generated)  │ (refused)    │ Needed       │
├──────────────────────────┼──────────────┼──────────────┼──────────────┤
│ X Iran policy            │ ❌ Not req   │ ❌ Not req   │ ACCOUNT_ACT  │
│                          │              │              │ POLICY_VER   │
├──────────────────────────┼──────────────┼──────────────┼──────────────┤
│ Oregon SB 1546           │ Partial*     │ ❌ Not req   │ GEN_DENY     │
│ (chatbot safety)         │              │              │ GEN_WARN     │
├──────────────────────────┼──────────────┼──────────────┼──────────────┤
│ Arizona SB 1786          │ ✅ Required  │ ❌ Not req   │ GEN_DENY     │
│ (provenance embedding)   │              │              │ POLICY_VER   │
├──────────────────────────┼──────────────┼──────────────┼──────────────┤
│ Illinois SB 3263         │ ✅ Required  │ ❌ Not req   │ GEN_DENY     │
│ (AI Provenance Data Act) │              │              │ POLICY_VER   │
├──────────────────────────┼──────────────┼──────────────┼──────────────┤
│ India IT Rules 2026      │ ✅ Required  │ ❌ Not req   │ GEN_DENY     │
│ (SGI mandate)            │              │              │ ACCOUNT_ACT  │
│                          │              │              │ POLICY_VER   │
├──────────────────────────┼──────────────┼──────────────┼──────────────┤
│ EU AI Act Art. 50        │ ✅ Required  │ Optional**   │ All v1.1     │
│ (transparency code)      │              │              │ types apply  │
├──────────────────────────┼──────────────┼──────────────┼──────────────┤
│ TAKE IT DOWN Act         │ N/A (del)    │ ❌ Not req   │ GEN_DENY     │
│ (48h removal)            │              │              │ GEN_QUARANT  │
│                          │              │              │ ACCOUNT_ACT  │
│                          │              │              │ LE_REFERRAL  │
├──────────────────────────┼──────────────┼──────────────┼──────────────┤
│ AI CSAM enforcement      │ N/A          │ ❌ Not req   │ GEN_DENY     │
│ (22-state prosecution)   │              │              │ ACCOUNT_ACT  │
│                          │              │              │ LE_REFERRAL  │
│                          │              │              │ POLICY_VER   │
├──────────────────────────┼──────────────┼──────────────┼──────────────┤
│ Grammarly persona issue  │ ❌ Not req   │ ❌ Not req   │ GEN_ATTEMPT  │
│ (identity governance)    │              │              │ POLICY_VER   │
└──────────────────────────┴──────────────┴──────────────┴──────────────┘

*  Oregon requires disclosure but not C2PA specifically
** EU Code lists "logging" as optional element

The pattern is clear: the C2PA column (proving what was generated) is increasingly covered by regulation. The SRP column (proving what was refused) is empty everywhere except a partial "optional" in the EU Code.

What This Means for Developers Building AI Systems

If you're building or maintaining an AI content generation system, here's the practical takeaway:

1. The compliance surface is expanding fast

Twenty-plus US states, India, the EU, and federal law are all converging on content provenance requirements. If you're not logging generation events today, you'll be required to by Q3 2026 at the latest (EU Article 50 deadline: August 2, 2026).

2. Generation logging isn't enough

Every one of these regulations will eventually ask: "What did you refuse to generate?" The only question is when. Logging GEN_DENY events now is forward-looking compliance — it's cheaper to build it into the architecture than to retrofit it under regulatory pressure.

3. Start with the Primary Invariant

You don't need to implement all four invariants on day one. Start with the primary:

# The minimum viable verification:
# Every GEN_ATTEMPT must have exactly one outcome.
assert count(GEN_ATTEMPT) == count(GEN) + count(GEN_DENY) + count(GEN_ERROR)

If you can verify this for your system, you have the foundation. The escalation, quarantine, and policy invariants build on top.

4. Policy versioning is free and invaluable

Even if you implement nothing else from v1.1, start hash-chaining your safety policy documents. When a regulator asks "What policy was in effect when this decision was made?", you want to have a cryptographic answer, not a manual document search.

# Minimum viable policy versioning:
policy_hash = hashlib.sha256(policy_document.encode()).hexdigest()
# Store: (policy_id, policy_hash, effective_from, timestamp)
# Anchor externally: RFC 3161 timestamp token

5. The architecture diagram

Here's how the full v1.1 event flow looks in practice:

User Request
      │
      ▼
┌──────────────────┐
│  GEN_ATTEMPT     │ ◄── Log BEFORE safety check (critical!)
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  Safety Pipeline │
└────────┬─────────┘
         │
    ┌────┴────┬──────────┬───────────┬──────────────┐
    │         │          │           │              │
    ▼         ▼          ▼           ▼              ▼
┌───────┐ ┌────────┐ ┌────────┐ ┌──────────┐ ┌──────────┐
│  GEN  │ │GEN_DENY│ │GEN_WARN│ │GEN_ESCAL │ │GEN_ERROR │
│(pass) │ │(block) │ │(warn)  │ │(review)  │ │(failure) │
└───┬───┘ └────────┘ └────────┘ └────┬─────┘ └──────────┘
    │                                │
    ▼                            resolved by
┌───────────┐                  GEN or GEN_DENY
│GEN_QUARANT│
│(hold)     │
└─────┬─────┘
      │
  resolved by
EXPORT or GEN_DENY

              Account-Level Events (independent flow)
              ────────────────────────────────────────
Flagged Pattern ──▶ ACCOUNT_ACTION ──▶ LAW_ENFORCEMENT_REFERRAL
                    (BAN/SUSPEND)       (REFERRED/NOT_REFERRED)
                         │
                    References: POLICY_VERSION
                    (what policy governed the decision?)

Transparency Notes

About CAP-SRP: CAP-SRP is an open specification published under CC BY 4.0 by the VeritasChain Standards Organization (VSO), founded in Tokyo. The specification is early-stage — v1.0 was released January 28, 2026; v1.1 on March 5, 2026. It has not been endorsed by major AI companies and is not yet an adopted IETF standard. An individual Internet-Draft (draft-kamimura-scitt-refusal-events-02) has been submitted to the SCITT working group but has not been formally adopted. The underlying standards it builds on — SCITT, C2PA, COSE/CBOR, RFC 3161 — are mature and widely implemented.

Fact-check methodology: Every claim in this article was verified against primary sources before publication. Corrections are noted inline where original reports contained errors (conflict start date, view count scale, NCMEC statistics context, unverified legislative dates). URLs were checked for existence and content accuracy. One URL cited in the source report (aicerts.ai) appeared fabricated — the site exists but the specific article slug does not match published content.

What CAP-SRP is:

A technically sound approach to a genuine and well-documented gap
Aligned with existing standards (C2PA, SCITT, RFC 3161)
Available on GitHub: veritaschain/cap-spec · veritaschain/cap-srp

What CAP-SRP is not (yet):

An industry-endorsed standard
An IETF RFC
A guaranteed solution

The real question is whether the industry builds some form of verifiable refusal provenance before regulators impose one. The August 2, 2026 EU AI Act enforcement deadline is 147 days away.

Verify, don't trust. The code is the proof.

GitHub: veritaschain/cap-spec · Specification: CAP-SRP v1.1 · IETF Draft: draft-kamimura-scitt-refusal-events-02 · License: CC BY 4.0

DEV Community: VeritasChain Standards Organization (VSO)

Give Your AI a Black Box: A Verifiable Decision Log in ~150 Lines of Python

The event model

Property 1: tamper-evidence with a hash chain

Property 2: independent verifiability with public-key signatures

Property 3: omission detection

Property 4: external anchoring

What this does not give you

Where to go next

Build, Sign, Verify: A Hands-On Tour of VeritasChain Protocol v1.2 PRD

Table of contents

1. Setting up the workspace

2. The bundle layout

3. Signing a minimal v1.2 event

4. Adding regulatory_profile and clock_evidence

5. Emitting a gov.change_event (and why ML retraining lives here now)

6. Pre-trade controls: trade.ptc_snapshot and trade.ptc_breach

7. Crypto-shredding with Erasure Certificate v2

8. Assembling a Regulatory Evidence Bundle

8.1 Serving a REB over HTTP

9. Hybrid post-quantum signature vectors

10. Running the full conformance suite

11. Writing your own verifier (in any language)

11.1 Common pitfalls (with actual verifier output)

12. Wiring it into CI

13. Migrating from a v1.1 emitter

14. Where to send your Public Review comments

Closing notes

veritaschain / vcp-spec

Official specification for the VeritasChain Protocol (VCP) v1.0 – global audit standard for algorithmic trading.

VeritasChain Protocol (VCP)

📌 Canonical Specification Location (IMPORTANT)

📘 Available Versions

▶ Current Stable

▶ Legacy

Grok Still Makes Deepfakes. GSA Wants AI Flight Recorders. Workday Says Logs Are Enough. Here's the Code That Settles the Debate.

TL;DR

Table of Contents

Event 1: Grok Deepfake Circumvention Persists

What happened

Fact-check verdict: ✅ Confirmed with one correction

The accountability gap

Event 2: GSA Demands AI Flight Recorders

What happened

Fact-check verdict: ✅ Fully confirmed against primary source

What GSA gets right — and what's missing

Event 3: Workday Declares Logs Are Enough

What happened

Fact-check verdict: ✅ Verified with terminology correction

The "good enough" problem

The Pattern: Three Positions on the Same Spectrum

CAP-SRP v1.1: The Complete Event Model

All 10 Event Types

All 4 Completeness Invariants

Building It: Full Python Implementation

Event Types and Core Infrastructure

Event Classes

The Chain with All 4 Completeness Invariants

Scenario Mapping: Three Events → Event Flows

Scenario 1: Grok Deepfake Request (with CAP-SRP)

Scenario 2: GSA-Compliant AI System

Scenario 3: Workday-Type HR AI Decision

GSA Clause → CAP-SRP Conformance Mapping

Bronze/Silver/Gold Sprint Plan

Sprint 1: Bronze (2–3 weeks)

Sprint 2: Silver (3–4 weeks)

Sprint 3: Gold (4–6 weeks)

Transparency Notes

China Regulates Digital Humans. Germany Wants to Jail Deepfake Creators. Neither Can Verify What an AI Refused to Generate.

TL;DR

Table of Contents

Event 1: China's Digital Human Regulation

What happened

Fact-check verdict: ✅ Confirmed with nuance

The verification gap

Event 2: Germany's Deepfake Criminal Law Proposal

What happened

Fact-check verdict: ✅ Confirmed with important caveat

The evidentiary demand

Event 3: Bloomberg Law's Deposition Deepfake Warning

4. Adding `regulatory_profile` and `clock_evidence`

5. Emitting a `gov.change_event` (and why ML retraining lives here now)

6. Pre-trade controls: `trade.ptc_snapshot` and `trade.ptc_breach`