> AI screeners are collapsing the cost of KYC — which is good for a credential rail. But a screener produces evidence, not verdicts. The MintID issuer plane now enforces that division by construction: enumerated checks with provenance, or a named rejection — and no field anywhere that could carry a provider-asserted grade. Blog · issuance # AI writes the evidence. It doesn’t get to decide. AI screeners are collapsing the cost of KYC — which is good for a credential rail. But a screener produces evidence, not verdicts. The MintID issuer plane now enforces that division by construction: enumerated checks with provenance, or a named rejection — and no field anywhere that could carry a provider-asserted grade. by Marc Miró i Rierola·published 2026-07-26·updated 2026-07-26·7 min read A new class of tool is eating the expensive middle of compliance. Anthropic’s finance agents include a KYC screener that extracts fields from documents, screens watchlists and packages escalations as structured JSON. Sardine’s rejoinder to that launch was that the reasoning itself is commoditising, while durable value sits in evidence quality and operational infrastructure. Both are right, and — read carefully — both are describing the _input_ side of an identity credential, not the credential. That distinction is the whole design of the MintID issuer plane, and it now has a module enforcing it. ## Cheaper screening is good news for a credential rail It is worth saying plainly, because the reflex in identity circles is defensive: the collapse in screening cost is **good** for MintID. The economics of [amortised accountability](/en/blog/amortised-accountability) start with someone doing a real KYC check once. Every cheaper screener widens the set of organisations that can viably operate as an approved issuing authority, and every new authority means more credentials in circulation — each of which is then proven thousands of times in zero knowledge, at no further screening cost. The screener market can commoditise all it wants. Every cheaper screener makes a MintID credential cheaper to issue, and none of them can issue one. ## Evidence and verdicts are different objects The failure mode to design against is subtle and extremely tempting. A screener returns a rich structured payload, somewhere in it is a field called `assurance` or `tier` or `grade`, and an issuing system under deadline pressure copies it forward. At that moment the issuing authority has stopped deciding and started forwarding — but the credential it signs still says _this authority assessed this person at this grade_. The accountability chain has a hole in it that nobody can see from the outside. So the profile draws the line at the type level. The normalized evidence it produces **has no field that could carry a grade**. Not an optional one, not a nullable one — none. And a payload that asserts a grade or tier label is rejected outright, _wherever it appears, at any depth_, including outcome strings shaped like a grade. You cannot forward what you cannot represent. Which grade an authority assigns, and against which evidence vocabulary, remains an [open architecture decision](/en/sdk/adr-0001-kyc-trust-model). This profile deliberately does not settle it. It settles only who is allowed to answer. ## What a screener payload becomes Accepted evidence normalizes into **enumerated checks with enumerated outcomes**: document authenticity, field-extraction consistency, identity-data validation, sanctions, PEP and adverse-media screening — each resolving to pass, fail, inconclusive or escalated, and each carrying the attestation of _how it was retrieved_: an authenticated API call, or a signed webhook that was re-fetched over the authenticated channel before being believed. Nothing is trusted for returning JSON. The screener’s own escalation disposition survives as **one more enumerated check**. Not a header, not a flag, not a fast path. A screener recommending approval carries exactly the weight of a check outcome — a fact the issuer weighs, never an instruction the issuer follows. ## Or it is rejected, by name The alternative to acceptance is not a warning log. It is a rejection with a reason from a closed vocabulary: Rejected when Why case or subject mismatch The payload describes a case or a subject other than the one this authority opened. Evidence that arrived for someone else is not evidence. provenance missing No attestation of how the payload was retrieved. Nothing is trusted for the mere fact of returning JSON. bare verdict A payload reduced to “verified: true”. A boolean is not evidence — it is a conclusion with the reasoning removed. grade asserted A provider-asserted assurance grade or tier label, anywhere in the payload, at any depth. The issuer decides the grade. timestamps missing or evidence stale Undated evidence, or evidence older than the issuing authority accepts at the moment of evaluation. unknown check kind or outcome A check or an outcome outside the closed vocabulary. Unrecognised is not a synonym for harmless. A closed vocabulary is the same discipline the [verifier reason codes](/en/sdk/reason-codes) apply on the other side of the protocol, for the same reason: a named rejection is auditable, and a catch-all is where exceptions quietly become policy. ## Pure, deterministic, and invisible to the chain The module is a deterministic function of its inputs. Evaluation time is injected by the caller; there is no clock, no network and no randomness inside it — authenticated retrieval is the driver’s duty, attested through the provenance fields the normalizer demands. Twenty-five tests hold that shape in place. And the material itself goes exactly one place: **issuer-private, on arrival**. No raw KYC data, no PII and no screener payload ever touches the chain — that is the [architecture](/en/technology), not a retention policy. The practical consequence for an issuing authority is that a provider outage, an API change or a vendor switch is invisible to the protocol. The evidence contract is what you integrate against, and it outlives whichever screener is cheapest this quarter. ## The division that has to hold AI writes the evidence. It doesn’t get to decide. That sentence is easy to put in a policy document and hard to keep true under commercial pressure — which is precisely why it belongs in a type signature and a rejection vocabulary instead. The [issuing authority](/en/issuers) decides the grade, after independent assessment, and stakes its bond on that decision. The screener, however good, is a witness. Does an AI screener decide whether a MintID credential is issued? No. A screener produces evidence: extracted fields, per-check outcomes, watchlist results, an escalation disposition. The issuing authority decides — including the assurance grade. The evidence profile makes that division structural rather than procedural: an asserted grade is rejected on sight, and the normalized evidence type has no field that could carry one. What does the profile accept? Enumerated checks with enumerated outcomes — document authenticity, field-extraction consistency, identity-data validation, sanctions, PEP and adverse-media screening, plus the escalation disposition as one more check — each carrying an attestation of how it was retrieved: an authenticated API call, or a signed webhook re-fetched over the authenticated channel. What happens to the screener’s escalation decision? It survives as one more enumerated check, never as an acceptance shortcut. A screener saying “this one is fine, ship it” carries exactly the weight of a check outcome — a fact the issuer weighs, not an instruction the issuer follows. What happens if the screening provider changes or goes down? Nothing visible to the protocol. Provider material becomes issuer-private on arrival and never touches the chain; the module that normalizes it is pure and deterministic, with evaluation time injected by the caller — no clock, no network, no randomness. Swap screeners, keep the evidence contract. ## Cheaper screening. Same accountability. If you are considering operating as an approved issuing authority, the evidence contract is the part worth reading first — it is what makes your screening choice yours. [The issuer role on MintID](/en/issuers)[Talk to us](/en/contact) --- Source: https://mintid.net/en/blog/ai-writes-the-evidence · AI writes the evidence. It doesn’t get to decide. — MintID blog