Attestation of Scrutiny: Adversarial Provenance for AI-Era Artifacts

Matrix CR Studio, Costa Rica. 2026-08-28. Defensive publication.

This document is a defensive publication. It places the described artifact class, receipt format, canonicalization rules, and methods into the public domain as prior art, with a cryptographically hardened publication date. Our intent is that no party, including us, can patent what is disclosed here, whether as the whole composition or as any of its elements or sub-combinations. The reference implementation remains proprietary.

Abstract

Provenance standards answer the question "where did this artifact come from." None of them answer the question a verifier actually asks in the age of generative models: "why should I believe this." We define a complementary artifact class, the attestation of scrutiny, also called adversarial provenance: a machine-verifiable, offline-checkable, signed record of what an artifact survived under adversarial examination, bound to the artifact by hash. We disclose the receipt format with a complete worked example, the exact canonicalization and verification algorithms, and the three method elements that generate such records: per-gate seal chains carrying each gate's measured discrimination statistic and disposition, blind cross-family cold-read judging, and verdict-flip re-certification as an acceptance criterion. Each element is disclosed both alone and in every combination with the others and with the receipt construction.

The gap

The provenance field is crowded and none of it covers scrutiny. C2PA and Content Credentials attest media origin. in-toto and SLSA attest how a software artifact was built. Sigstore and Rekor give signing transparency. OpenTimestamps proves existence at a time. W3C PROV models lineage. TEE remote attestation proves which code ran on which hardware. Every one of these attests origin, custody, or instantiation. None of them attest examination: the challenges an artifact was subjected to, the verdicts, the measured discriminating power of each check, and the dispositions, bound to the artifact as a first-class signed record. Evaluation logs exist everywhere, but they are not bound, signed, or anchored as provenance, and they evaporate.

As verification research matures (weak-verifier ensembles, process reward models, test-time compute scaling), the score a verifier produces is consumed at selection time and discarded. The attestation of scrutiny is the missing persistence layer: it turns the act of verification into durable, portable evidence.

Definition

An attestation of scrutiny is a record with the following properties:

1. Bound. It contains a cryptographic fingerprint of the examined artifact (or of the claim about it), so the record cannot be reattached to a different artifact.
2. Transcriptive. It records the examination itself: which checks ran, in what order, each check's verdict, each check's measured discrimination statistic (how well that check separates good from bad on reference data), and the disposition, including recorded exceptions and overrides.
3. Integrity without a secret. The records form an append-only hash chain that any party can re-verify offline, forever, using hash functions alone: forward linkage, backward linkage, and closure over the chain's seed. Detecting tampering requires no key of any kind.
4. Authentic at rest. A digital signature (Ed25519 in the reference profile) over the terminal chain hash proves who issued the record. Issuing requires the private key; checking requires only the public key embedded in the receipt. An attacker who alters records and recomputes the chain produces a chain that is internally consistent but whose terminal hash no longer matches the sealed value, so the seal fails.
5. Revocation-aware. Trust in the signing key is held separate from the cryptographic validity of the signature, PKI-style, so a compromised key's receipts can stop being trusted while remaining cryptographically intact. Any revocation transport works: a local keyring, a CRL or OCSP-style responder, or a transparency log; all are disclosed variants.

The receipt format, with a worked example

The minimal profile below attests one AI inference event. The same chain construction generalizes to any examined artifact by substituting the claim object. The example below is a complete, internally verifiable receipt: every hash and the signature can be recomputed by a reader from the algorithms in this document. The signing keypair was generated solely for this publication and is not an operational key, as its metadata states; all values are otherwise synthetic.

{
  "counterfoil_receipt_version": "1",
  "kind": "ai-inference-attestation",
  "issued_ns": "2026-08-28T14:57:49.102976Z",
  "claim": {
    "model_id": "example-classifier-v1",
    "output_label": "EXAMPLE_LABEL",
    "confidence": 0.99,
    "input_fingerprint": "sha3-256:36a476d9b88a95975dfadcc0be61a0d1c22af30a5e03a30589f537a42d64895f",
    "inference_ts": null,
    "meta": {
      "purpose": "defensive-publication-worked-example",
      "key": "throwaway keypair generated solely for this document"
    }
  },
  "chain": [
    {
      "seq": 0,
      "stage": "SEED",
      "ts_ms": 1787929069094,
      "payload_hash": "4978a40ae9419b7ddc5ea3bea92ebbb329977521fc79689c378796c868f628d2",
      "prev_hash": "",
      "record_hash": "00483fdb648e6b98413e89422c12368c1c47fc3fffc4806efbf25602e155b8d4"
    },
    {
      "seq": 1,
      "stage": "LOG",
      "ts_ms": 1787929069094,
      "payload_hash": "1f5d07d551536e74bf1f5ad376cc9427c2e729234c32d05d796286c805795c82",
      "prev_hash": "00483fdb648e6b98413e89422c12368c1c47fc3fffc4806efbf25602e155b8d4",
      "record_hash": "8fc0362a30e656cfffe736508055f0e0391ced4bccfc16ac5417f7142f11b0f0"
    }
  ],
  "seed_anchor": "4978a40ae9419b7ddc5ea3bea92ebbb329977521fc79689c378796c868f628d2",
  "seal": {
    "alg": "ed25519",
    "public_key": "fcc7684ad5141102bd9bd3eb522d7970b94fe6526b6892eb9da6379190a4fbab",
    "key_fingerprint": "4eddf6eb263969ff",
    "sealed_field": "chain[-1].record_hash",
    "sealed_value": "8fc0362a30e656cfffe736508055f0e0391ced4bccfc16ac5417f7142f11b0f0",
    "signature": "691dd90911b997e1536e819e400b955c278edc765d528466f0e85fec73885ed74a9598be3d8407602aad2e1c9dd55f2a863523d57a01ad6ce014266639cb3301"
  }
}

Semantics: the claim carries only a fingerprint of the input, never the input itself, so the receipt can travel where the data cannot (clinical and confidential settings). The chain's ts_ms values are the authoritative, hash-covered timestamps; issued_ns is a human-readable rendering outside the hashed material. A receipt may carry an optional per-record session HMAC field for online co-verification within an issuing session; it is null in the offline profile and ignored by offline verification.

Canonicalization (normative)

All hashes are SHA3-256 over the following canonical forms.

1. Payload hash. payload_hash = SHA3-256(canon(payload)) where canon is JSON serialization with lexicographically sorted keys, separators "," and ":" with no whitespace, non-JSON-native values rendered via their string form, encoded as UTF-8. This is equivalent in effect to JCS-style canonical JSON.
2. Record hash. record_hash = SHA3-256(UTF-8("<seq>|<stage>|<ts_ms>|<payload_hash>|<prev_hash>")), the five fields joined with the pipe character. The first record's prev_hash is the empty string (serialized as "").
3. Seed record. chain[0].payload_hash = payload_hash(claim), and seed_anchor repeats that value, closing the chain over its seed.
4. Closure record. The terminal record's payload is the object {"closes": <seed payload_hash>, "kind": <kind>}, hashed under rule 1.
5. Input fingerprint. "sha3-256:" + SHA3-256(canon(input)), with canon as in rule 1 (raw UTF-8 bytes for plain strings, canonical JSON for structured inputs).
6. Seal. Ed25519 signature over the UTF-8 bytes of the terminal record_hash hex string; public_key is the raw 32-byte Ed25519 public key in hex; key_fingerprint is the first 16 hex characters of SHA3-256 over those raw public key bytes.

Verification algorithm (offline, no server)

1. Recompute record_hash for every record under canonicalization rule 2. Any mismatch fails.
2. Check linkage: chain[i].prev_hash == chain[i-1].record_hash for all i, chain[0].prev_hash == "", and seed_anchor == chain[0].payload_hash. Recompute the closure record's payload hash under rule 4.
3. Check claim binding: payload_hash(claim) == chain[0].payload_hash. A swapped claim fails here even when the chain is internally consistent.
4. Verify the Ed25519 signature over sealed_value with the embedded public key, and confirm sealed_value equals the terminal record_hash actually present.
5. Trust check, separate from cryptography: look up key_fingerprint against a keyring, revocation list, or transparency log. A revoked or unknown key yields "cryptographically valid, not trusted." Steps 1 through 4 require no network and no secret; step 4 uses only the public key carried in the receipt.

The scrutiny transcript: three method elements

Per-gate seal chain. A verification pipeline declared as a fixed, ordered protocol of gates, where a gate is a persisted, versioned protocol unit, not an ephemeral function call. Each gate appends one seal record to the artifact's chain under the same canonicalization rules, with a payload of the form:

{
  "gate_id": "example-gate/2",
  "verdict": "PASS",
  "discrimination": { "metric": "TPR_at_FPR", "fpr": 0.05, "value": 0.91, "reference_set": "held-out labeled corpus, versioned" },
  "disposition": "accepted; verdict stands",
  "exceptions": []
}

The discrimination field records how well the gate separates good from bad artifacts on reference data. Any standard discrimination statistic is a disclosed variant: true-positive rate at fixed false-positive rate, area under the ROC curve, an effect size, or an equivalent measured separation, computed against a versioned reference set. Running the pipeline produces the evidence chain as a byproduct. The chain records not just that checks passed but how discriminating each check was and what was ruled and why, including exceptions and overrides, which makes the transcript auditable rather than merely reassuring.

Blind cross-family cold-read judging. Model-based checks are performed by judge models from two or more foreign lineages (different labs, different training pipelines), under any assignment policy. Each judge receives the artifact with no provenance metadata, no prior verdicts, and no knowledge of what it is gating, in a fresh context. Multiple independent families defeat single-family blind spots, and blindness prevents the judge from anchoring on the generator's framing.

Verdict-flip re-certification. The acceptance criterion for an iterated artifact is not a fresh pass but a flip: a probe that previously failed the artifact must, on a new blind cold read by the same foreign family, now pass it. Variants disclosed: requiring the flip from the specific failing probe, from any quorum of previously failing probes, or from all of them. The acceptance signal is adversarial, independent of the generator, and anchored to the artifact's own failure history.

Composition. This document discloses each element independently, every pairwise combination, and the full composition in which blind cross-family judging and verdict-flip re-certification execute as gates whose seal records enter the per-gate chain, sealed and bound to the artifact as described above. It also discloses the trivial decouplings, such as verdict-flip certification recorded outside a chain or a seal chain fed by non-blind judges.

What this is not

This is not a claim on verification research, LLM-as-judge, hash chains, digital signatures, transparency logs, or timestamping, all of which are established fields and prior art. The disclosed instrument is the composition: scrutiny records as first-class, bound, signed, offline-verifiable, revocation-aware provenance artifacts, generated by the method elements above.

Reduction to practice and priority

The reference implementation is built and tested: the receipt profile above passes an adversarial suite including cascade-tamper-fails-seal and revoked-key-untrusted-though-cryptographically-intact cases, and the generating pipeline has run cross-domain. Dated development records exist in a private repository under cryptographic hash, and the claims register covering this material carries an OpenTimestamps proof anchored to the Bitcoin chain. The released version of this document is hash-anchored via OpenTimestamps at publication, and the proof is published alongside it.

Key lifecycle internals, gate discrimination thresholds, judge panel composition, and the reference source code are deliberately not disclosed and remain proprietary.

Contact: Matrix CR Studio, https://matrixcr.ai

This disclosure is made to be citable and to be unpatentable. Cite it, build on the ideas, and expect the reference implementation to stay ahead.