The Evidence Contract Behind a Defensible AI Acceptance Decision

Evidence-carrying artifacts and acceptance-contract engineering replaces a single green checkmark with a specific, checkable claim: which exact artifact, tested against which exact requirement, under which assumptions, by which method. A passed test, a signed transformation and a model's own judgment are different kinds of evidence, and none proves what a blended pass or fail score implies. Leaders who fund one all-purpose verification step are buying a badge, not a defensible decision.

What it is

An evidence-carrying artifact is any object under review, source code, a binary, a model checkpoint, a configuration, a dataset, or a proposed action, paired with typed evidence bound to its exact identity, not its name or version label. A source hash is not a binary hash, so the build recipe and every dependency affecting the claim travels with the artifact.

Requirements are not all the same kind of thing: some are mechanically decidable, some formally provable only under stated assumptions, some behaviorally testable, some statistically estimated, some frankly subjective. A program that never checks whether the requirement itself was adequate is checking the wrong thing carefully.

Four principles hold the discipline together: name the exact artifact, never a mutable label such as latest. Classify every requirement by kind. Bind evidence to the artifact's digest, the requirement's version, its dependency slice, and the verifier that produced it. Never collapse a proof, a test result, a benchmark score, a signature and a model's opinion into one verified flag, since each rests on a different trusted base.

Why it matters now

Production systems increasingly generate the artifacts they will later be judged on, alongside the proofs used to accept them, and a checker that waves through something defective looks identical, from outside, to one that caught a real problem. A preliminary August 2026 study of a trusted large-language-model compiler framework ran its bounded checker with an unwind bound of 20, restricted matrix sizes and several checks turned off, and let its language model fallback override the verifier's own rejection. Across 30 PolyBench benchmark programs, the hybrid still did not reach perfect correctness.

A September 2026 study of a multi-day autonomous development harness found separate role prompts inside it do not demonstrate independent verification. Boards that assume an agent checking its own work equals independent review are underwriting a risk the evidence does not support.

The architecture

The clearest way to build this is what I call the evidence contract: every acceptance decision binds four things about evidence before it counts, and every mandatory requirement has to hold at once, not on average.

The first binding is identity: the exact artifact digest, not a filename or release label. The second is the requirement: a specific, versioned claim, classified by kind, assumptions written down. The third is the dependency slice: everything the claim depends on, so a build flag, schema or evaluator changing can invalidate it even when the artifact's bytes have not moved. The fourth is the verifier: the method, tool version and environment that produced the result, and who had authority to run it. Only once all four hold does evidence count, and the decision requires every mandatory clause, typically security, authorization and correctness, to pass together. A weighted average must never let an excellent score offset a failed mandatory gate: a candidate scoring near perfectly on speed and style and zero on a required authorization check has failed.

Two failure modes recur: a hidden environment variable can let unrelated claims go stale together, and agreement between two reviewers is not independence, since two instances of the same model can share the same systematic mistake. A signed transformation record supports a lineage claim under a trusted issuer, never a claim that the transformation was correct.

How to lead it

Ownership belongs with a team structurally separate from whoever builds the artifact under review, since a verifier the producer can quietly override fails the contract's core requirement.

Fund a content-addressed manifest naming every artifact by digest, a requirement graph classified by kind, typed evidence bound to it, and a deterministic evaluator applying mandatory gates conjunctively rather than averaged. Measure how many requirements were verified, rejected with a reason, or returned unknown, alongside the re-verification rate after a dependency change, not one aggregate pass rate. Stop accepting a signature as proof of correctness, and stop letting the same model grade its own output as the only evidence behind an irreversible action.

Two decisions belong to the executive alone: where the line sits between a mandatory gate and a softer weighted judgment, and what the organization accepts when full reproducibility is not possible.

What it is worth

Money and risk show up in three places: engineering time chasing a high aggregate score instead of a sound mandatory gate, downstream cost when a hidden gate failure reaches production, and unnecessary re-verification spend when invalidation runs too conservatively. Measure the mandatory-gate false-accept rate on known-good and known-defective artifacts, and the re-verification cost per dependency change.

What the 2026 evidence supports is narrower than the usual pitch: bounded verification settings limit what a pass certifies, and a signed lineage record does not establish semantic truth. It does not yet support a validated, running version of the full evidence-contract architecture proposed here, which its own source material calls an original synthesis, not independently implemented or tested. Two of the five primary studies are graded preliminary or first-party only. No dollar figure or return percentage appears anywhere in the underlying evidence.