Cryptographic provenance.

1. Executive Summary

AirIndex’s audit chain — documented in the AIX-ID methodology paper §6 — uses append-only and succession-only Postgres tables with database-level immutability triggers. That’s strong operational discipline, but the externally verifiable proof reduces to “AirIndex promises the triggers were never disabled.”

Cryptographic provenance changes the proof model. Every audit record, once anchored, is verifiable as having existed at its claimed timestamp without trusting AirIndex’s database, infrastructure, or assertions. A reader, journalist, regulator, insurance counterparty, or legal opponent can independently verify the record’s integrity using only the published Merkle path, the DigiCert TSA cert chain, and the Bitcoin blockchain.

The provenance system rests on three independent statements, any one of which is sufficient evidence:

1. Merkle inclusion — the record’s canonical-identity hash is a leaf in the daily batch’s Merkle tree, with a verifiable path to the published root.
2. TSA timestamp — the Merkle root was signed by DigiCert at a specific moment, verifiable with off-the-shelf openssl ts -verify.
3. Bitcoin commitment — the root was anchored to a specific Bitcoin block via the OpenTimestamps protocol, verifiable with ots verify against the public Bitcoin chain.

The first ProvenanceAnchor — the “genesis anchor” — committed AirIndex’s entire audit history (21,245 records across six audit tables, every score / override / classification / changelog / identifier mint / wire post on the platform) at 2026-05-12 15:17 UTC. Any retroactive edit to any of those records is now mathematically detectable.

2. The Problem

Three threats motivate cryptographic provenance:

Retroactive tampering. Operator account compromise, malicious insider, or business pressure could motivate after-the-fact edits to audit records. Without cryptographic anchoring, an editor with database access can rewrite history; the operational triggers can themselves be disabled by an attacker with sufficient privilege.

Bulk substitution. Restore-from-tampered-backup, migration to a different database with altered records, or disaster-recovery scenarios that introduce inconsistencies. Anchor proofs survive any database operation; the anchor exists on Bitcoin’s chain independent of AirIndex’s infrastructure.

Timeline manipulation. “AirIndex claims this score was published on May 10” — could the timestamp have been backdated? The TSA signature combined with the Bitcoin anchor prove the Merkle root existed by no later than the earliest of the two proof moments, eliminating backdating entirely.

The proof system does not address “wrong data but correctly recorded” — it proves what was recorded, not whether the record was correct at recording time. That’s a different problem, handled by the confidence-tier methodology and the public correction history.

3. Architecture

The system has four layers, each adding independent assurance:

Layer 0 — the immutable-audit tables (unchanged). ScoreSnapshot, ScoringOverride, ChangelogEntry, ClassificationResult, AixIdentifier, WirePost. Append-only or succession-only at the schema level; protected by database triggers as documented in the AIX-ID paper §6.

Layer 1 — daily Merkle batch. Each day, AirIndex’s anchor cron pulls every audit record created since the previous anchor, serializes each record’s identity columns canonically (sorted keys, no whitespace, ISO 8601 dates), SHA-256 hashes each leaf, and assembles a Merkle tree following the RFC 6962 / Certificate Transparency convention.

Layer 2 — RFC 3161 TSA signature. The Merkle root is submitted to the DigiCert public Timestamp Authority over RFC 3161’s standard TimeStampRequest / TimeStampResponse protocol. DigiCert returns a CA-grade signed timestamp binding the root to a specific moment. Verifiable with openssl ts -verify against DigiCert’s public TSA certificate (already in every browser’s trust store).

Layer 3 — Bitcoin anchor via OpenTimestamps. The same Merkle root is submitted to the OpenTimestamps public calendars (alice.btc, bob.btc, finney.calendar, etc.) which aggregate pending hashes and periodically commit their aggregate root to Bitcoin. After Bitcoin confirms (typically within hours), the proof can be “upgraded” to include the BTC block-level commitment. This eliminates trust in AirIndex AND in the TSA.

A reader verifying a record gets three statements: this record was included in the Merkle tree rooted at R, R was signed by DigiCert at T, and R was anchored to Bitcoin at block H. Any one is sufficient evidence; together they form an institutional-grade proof chain.

4. Canonical Record Serialization

Hashing requires a deterministic byte representation. The following convention applies per audit table:

1. Take the identity columns. Each table has a specific allowlist of columns that contribute to the leaf hash. Identity columns are the ones that must not change post-insert (per the immutable-audit-table rules in §6 of the AIX-ID paper). Mutable allowlist columns — appliedAt, publishedAt, supersededAt on ScoringOverride; retiredAt, xrefs, displayName on AixIdentifier; status, sentAt on WirePost — are deliberately excluded so the hash remains stable under design-intended state transitions.
2. Canonicalize. Serialize as JSON with sorted keys (recursive), no whitespace, ISO 8601 strings for dates, base64 for byte buffers, arrays preserve order, explicit nulls.
3. Prefix with table name and SHA-256. Hash the literal string <TableName>:<canonical-json> with SHA-256, hex-encode. The table prefix makes the hash self-describing; two records from different tables with structurally identical identity columns cannot collide.

The full identity-column allowlist per table is published in the open-source implementation at src/lib/provenance/canonical-hash.ts (visible to anyone with read access to the AirIndex audit-trail API).

5. Verification Flow

A reader wants to verify that aix:bill:6W2SA6W2 (the Arizona SB1819 record that anchored Phoenix’s May 10 tier movement) was real on May 10:

Step 1 — fetch the record’s proof:

The response contains the anchor metadata, the leaf hash, the leaf index in the deterministic ordering, the Merkle proof path (sibling-step sequence from leaf to root), and the anchor’s TSA signature + OTS proof.

Step 2 — recompute the leaf hash independently. Fetch the source record from the AirIndex API (or via the published record). Extract the identity columns. Canonicalize per §4. SHA-256 hash with the table prefix. Result must equal leaf.hash in the response.

Step 3 — walk the Merkle path. Starting from the leaf hash, for each step: hash (sibling, current) if side=="left", or (current, sibling) if side=="right". After all steps, the result must equal anchor.merkleRoot.

Step 4 — verify the anchor’s proofs. Either or both of:

• Fast path (TSA). Base64-decode anchor.tsa.signature_base64 into the raw RFC 3161 TimeStampResponse bytes, then:openssl ts -verify -in tsr.der -CAfile <DigiCert TSA root cert>Confirms the Merkle root was signed by DigiCert at anchor.tsa.timestamp. Immediate proof; no Bitcoin wait.
• Trustless path (OpenTimestamps / Bitcoin). Base64-decode anchor.ots.proof_base64, then:ots verify proof.otsOnce anchor.ots.btcAnchorHeight is non-null, this confirms the Merkle root was committed to a specific Bitcoin block at a specific height. AirIndex’s servers play no role in this verification.

Step 5 — conclude. If steps 2, 3, and 4 succeed, the record existed in AirIndex’s audit chain by no later than the earliest of the two proof timestamps. AirIndex cannot retroactively edit or insert this record without breaking the proof.

6. Verification API

Three public, cacheable endpoints:

GET /api/provenance/anchors — lists all ProvenanceAnchor rows with summary metadata. Useful for discovering when anchors were taken and which had Bitcoin confirmation.

GET /api/provenance/anchor/[id] — returns one anchor’s full data, including the TSA signature (base64), the OTS proof (base64), the recordManifest (which records are leaves in this batch), and per-proof verification hints.

GET /api/provenance/record?table=<TableName>&id=<recordId> — returns the Merkle proof path for a specific audit record. The server recomputes the tree on demand and returns the path; cacheable because the data is immutable. Supported tables: AixIdentifier, ScoreSnapshot, ScoringOverride, ChangelogEntry, ClassificationResult, WirePost.

All three endpoints return JSON, are public, and require no authentication. They have no rate limit beyond the platform’s general protection; institutional integrations are welcome to call them at any cadence the use case warrants.

7. What This Does NOT Prove

Cryptographic provenance is a strong property but not a universal one. Several things remain outside the proof model:

• Real-time tampering between record write and anchor batch. Anchors are daily. A record created on day N is included in the day-N anchor (or the next successful one). Edits in the intervening window are caught by the immutable-audit triggers, but not by the cryptographic proof until the anchor lands.
• Correctness of the recorded fact. The proof binds AirIndex’s assertion to a moment in time. Whether the assertion was correct at recording time is a separate question, addressed by the confidence-tier methodology and the public correction history (visible at every record’s page).
• Compromise of the verification publishing infrastructure. If airindex.io serves false proofs, a verifier would detect it because the proofs would fail to verify against external trust roots (DigiCert TSA cert, Bitcoin chain). The verification API can be compromised; the verification itself cannot.

8. Adoption Commitment

AirIndex commits to maintaining cryptographic provenance over the audit chain in perpetuity. Anchor cadence is daily. The TSA provider may change (currently DigiCert; could move to Sectigo, GlobalSign, or another CA-grade provider for cost or relationship reasons), but the proof model and verification API surface stay stable. The Bitcoin anchoring will continue regardless of TSA provider.

Third parties — insurance carriers, public-private partnership advisors, federal contracting officers, legal counsel preparing for discovery, journalists verifying claims — are encouraged to cite the verification API as the canonical reference for AirIndex audit-chain integrity. The endpoints are stable, the response shapes are versioned in this document, and the underlying records are immutable.

Same permissive license as the AIX-ID system. The verification API is free to call, cite, and integrate against commercially.

9. Open Questions and Future Work

• Bitcoin transaction id extraction. The current OTS upgrade flow records the Bitcoin block height containing the commitment. Pulling the exact transaction id requires an additional Bitcoin RPC call beyond what the OpenTimestamps library exposes; that’s deferred. Block height plus the commitment hash in the proof is sufficient evidence for the immutability claim.
• In-browser verifier UI. A planned addition at /methodology/provenance/verify: a client-side JavaScript tool that takes a record identifier, calls the verification API, recomputes the leaf hash + Merkle path in the browser, fetches the relevant Bitcoin block header from a public explorer, and displays a verification result without requiring command-line tools.
• BLS aggregate signatures. A v2 enhancement would let AirIndex publish one aggregate signature per anchor across multiple TSA providers, providing T-of-N TSA assurance. v1 ships with single-provider TSA; v2 evolves based on adoption signal.