The passport that became weaker without changing a pixel

An onboarding analyst receives two image files. They have the same dimensions, the same photograph, the same machine-readable zone and the same visible security artwork. A pixel comparison finds no difference. In the first case, the image was captured inside an approved mobile flow, tied to a live session, checked against chip data and retained with a device and transformation record. In the second, it arrived as a screenshot forwarded through an email chain.

If identity were a property of the image alone, the files should have equal evidential force. They do not. The first carries a testable route from applicant to capture, validation and verification. The second may still contain true information, but the workflow cannot establish who presented it, how it was produced, what may have happened before receipt or whether its use is permitted. The difference lies in the evidence relationship, not the visual object.

This puzzle generalises. A registry extract can establish a filed director while saying nothing about economic purpose. A transaction can show payment to a new beneficiary without proving that the relationship is suspicious. A screening system can find a similar name without establishing that the candidate and customer are the same person. Each observation has a limited job.

The core answer is to make the supported proposition, rather than the document or generated summary, the durable unit of KYC automation. A case opens because one or more propositions are unknown, stale or contested. The system gathers evidence under purpose and role constraints, preserves disagreement, applies approved evidence contracts and routes the resulting state to the person or control that owns the decision. This changes both the data model and the authority model.

Identity is a claim, not a field

A customer record encourages a dangerous grammatical shortcut: it appears to say what the customer is. In practice, the record is a bundle of claims made by different parties for different purposes. “Asha Rao, born 14 May” may be a customer declaration. A passport may support a legal name and date of birth. A chip validation may support that the credential was issued and has not obviously been altered. A live comparison may support that the presenter resembles the credential holder. None alone establishes every relevant identity question.

The NIST identity-proofing model is useful here as technical decomposition, although it is not a bank KYC rule. It separates identity resolution, evidence validation and identity verification. Resolution distinguishes a claimed person within the served population. Validation tests the evidence and its attributes. Verification tests the binding between the applicant and the evidence. Legal-entity KYC adds further questions about corporate existence, ownership, control and relationship purpose.

Those questions should remain separate because their failure modes differ. A genuine passport can be presented by an impostor. A genuine person can present a manipulated image. A correctly identified director may not be a beneficial owner. A correctly identified beneficial owner may share a name with a politically exposed person but differ on decisive attributes. Correctness in one layer cannot be silently promoted into correctness in the next.

The five evidence bonds

To make that distinction executable, treat every proposed use of evidence as a five-part test. Let e be an evidence item, p a proposition, c the active case, t its decision time and π the approved policy. Evidence is eligible only when every bond is true:

The subject bond asks whether the evidence concerns the candidate under review, not merely a similar name. The semantic bond asks whether it supports the exact proposition, rather than mentioning related words. The temporal bond asks whether it applies to the decision period. The authority bond asks whether policy accepts that source class for that proposition. The purpose bond asks whether this role may retrieve and use it for this case.

These bonds are a practitioner synthesis, not a statement that one regulator has prescribed this schema. Their value is diagnostic. When a proposed conclusion fails, the case can say why: wrong subject, weak semantic support, expired fact, unaccepted source or impermissible purpose. A single confidence score cannot preserve those distinctions.

Worked example: two candidates, the same score

Consider a minimal screening review. The customer is “Mina El-Amin”, born in 1984, a Jordanian national. Two watchlist candidates receive a name-similarity score of 0.92. Candidate A has a compatible birth year, matching nationality and an alias used on the customer record. Candidate B has a different date of birth, a different nationality and a distinct government identifier.

Now vary only the distinguishing attributes while holding the score fixed. If the workflow treats 0.92 as identity, both candidates appear equally likely. If it treats the score as a retrieval instrument, Candidate A remains unresolved and Candidate B is rejected on explicit conflict. A ranking score is evidence about where to look, not evidence that the people are identical.

flowchart TD
  A["The passport that became<br/>weaker without changing a<br/>pixel"] --> B["Identity is a claim, not a field"]
  B --> C["Build a governed case state<br/>before asking a model to<br/>reason"]
  C --> D["Compose controls without<br/>blending their authority"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#D95545,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Build a governed case state before asking a model to reason

A long case transcript is a poor state representation. It mixes customer claims, observations, copied source text, model interpretations, prior decisions and superseded facts. A model can summarise the transcript fluently while preserving the wrong temporal version or erasing a disagreement. The safer input is a compiled case state whose elements already have types.

At minimum, the case state needs a subject, case purpose, applicable policy version, decision time, active propositions, evidence items, transformations, conflicts, required decisions and execution status. Each evidence item records its source identifier, source class, valid time, retrieval time, permitted purpose and stance toward one proposition. The W3C PROV-O recommendation supplies a general vocabulary for entities, activities and agents. KYC still needs its own authority, purpose, time and proposition semantics on top.

World state, evidence history and remembered narrative must not share one field. The world may contain a director change effective in June. The institution may learn it in August. A reviewer may approve the revised record in September. Those are three different events. Overwriting “director” with the newest value makes it impossible to reconstruct what was knowable at the earlier decision.

Evidence contracts prevent semantic promotion

For each proposition, an evidence contract states what the proposition means, which source classes may support or contradict it, required corroboration, freshness or valid-time conditions, conflict rules, deciding role and permitted downstream effect. “Current operating address” must not be confused with registered office, mailing address or a director’s residence merely because all contain the word address.

The contract also limits absence. A failed registry search does not prove that an owner does not exist. It may mean the jurisdiction has no accessible coverage, the query used the wrong identifier, the source was unavailable or the record has not yet been updated. The safe state is “not established from the sources searched”, accompanied by query receipts.

Transformations need their own receipts. Optical character recognition, translation, table extraction, transliteration, entity matching and summarisation can each change meaning. A receipt should identify input, output, software or model version, time, uncertainty where meaningful and any reviewer correction. The original remains inspectable. This is especially important for negation and time: “no longer a director”, “proposed owner” and “held 30 per cent until March” should not become the same positive relation.

Policy is compiled, not improvised

KYC requirements vary by legal entity, customer, product, jurisdiction and effective time. The FATF Recommendations establish international standards that jurisdictions implement. United States materials such as the FinCEN CDD FAQs and FFIEC CDD manual express their own legal and supervisory context. The FCA’s review of CDD controls addresses United Kingdom firms. These sources are related, not interchangeable.

The deployed workflow therefore receives an approved obligation manifest. It does not ask a language model to read a corpus of law and decide what governs. The manifest binds scope, policy version, proposition, accepted evidence classes, deciding role, expiry and exception route. Legal and compliance owners approve interpretation. Engineering tests executability. Operations tests whether evidence and exception capacity actually exist.

Compose controls without blending their authority

A KYC workflow combines unlike mechanisms. Document analysis inspects security and capture signals. Identity resolution compares candidates. Screening retrieves names and attributes from external lists. Graph calculations traverse ownership assertions. Language models extract and compare messy text. Policy services decide whether an obligation applies. Transactional services update systems of record. People make judgements that policy reserves for accountable roles.

The system fails when connectivity is mistaken for authority. A model that can call a screening API has not acquired the right to clear a candidate. A graph that calculates 37.5 per cent indirect ownership has not decided that a threshold and legal interpretation apply. An MCP server, workflow engine or service account may transport a request, but none supplies customer purpose, reviewer authority or postcondition evidence by itself.

Keep the model proposal stochastic and the authority kernel deterministic. Every consequential change is a typed action contract naming requester, subject, purpose, proposed diff, policy version, approving role and evidence references. The system of record accepts only authorised contracts. It returns an effect receipt. An independent readback confirms the intended state, exactly once, or declares an unknown outcome.

Authentication does not silently refresh identity

A returning customer may authenticate successfully with a passkey, device credential or one-time code. That proves something about control of an authenticator under the authentication system. It does not by itself prove that the original identity evidence remains current, that a legal entity still has the same controllers, or that a customer profile still describes the relationship. The same distinction works in reverse: a new KYC document does not automatically authorise access to an existing digital account.

The workflow should therefore bind authentication events to their limited propositions. A strong login can support “the enrolled account holder controlled the required authenticator at this time”. It should not be promoted into “the beneficial owners are unchanged”. This matters operationally because convenient account access can create a false sense that every identity question has been refreshed. Digital identity is useful when its assurance, governance and independence are understood, as the FATF digital-ID guidance emphasises. Its precise evidential role still belongs in the institution’s approved contract.

Beneficial ownership is a time-bounded graph

For a legal entity, identity resolution precedes ownership calculation. Nodes represent candidate people and entities with stable identifiers where available. Edges represent sourced assertions such as direct ownership, voting rights, control roles or trustee relationships. Each edge carries valid time, source, transformation and review status. Conflicting sources create parallel edges rather than forcing one value into the record.

A graph engine may traverse an approved chain and calculate indirect percentages, but the output is conditional on entity resolution, edge completeness and the rule supplied. A wrongly merged “Harbour Holdings” makes an exact calculation wrong. A new director is a control-role observation, not automatic evidence of ownership. The FATF beneficial-ownership guidance supports adequate, accurate and up-to-date information and a multi-pronged approach at the jurisdictional level. It does not give a universal customer-level graph formula. Missing intermediate entities, circular structures or disputed control therefore remain review states, not gaps for a model to fill.

Exceptions are governed states, not control-free exits

Identity processes will encounter customers who cannot satisfy the normal path: a credential cannot be read, a name does not transliterate cleanly, a registry is inaccessible, a biometric comparison is unsuitable, or the person cannot use the standard remote channel. Treating every exception as failure can exclude legitimate customers. Treating “manual review” as an unstructured override creates an invisible weaker standard.

An exception contract should name the failed normal requirement, permitted alternative evidence, additional corroboration, deciding role, time limit and downstream restriction if uncertainty remains. The reviewer should see which bond failed and why the alternative repairs it. A trusted referee, assisted route or in-person check is a different evidence path, not a waiver of identity. NIST’s identity-proofing guidance similarly gives exception mechanisms explicit roles and requirements rather than treating them as informal discretion.

Exceptions also need population-level review. Measure which customer groups enter them, how often alternatives succeed, whether outcomes differ and whether a vendor or interface is creating avoidable barriers. Fair access and control strength are not opposite objectives when the workflow can distinguish the proposition that must be established from one preferred method of establishing it.

Document authenticity remains a specialised control

Document images are attractive to general models because they contain language and layout. Yet authenticity depends on capture conditions, issuer features, presentation attacks, injection paths and out-of-distribution manipulation. Public datasets such as MIDV-2020 and SIDTD help test recognition and presentation-attack detection on synthetic identity documents. They do not reproduce every issuer, device, attack or operating population.

The FantasyID benchmark supplies a particularly useful negative result. In its reported practical-style threshold setting, a validation false-positive rate of 10 per cent corresponded to test false-negative rates close to 50 per cent for several evaluated forgery detectors. That is one dataset and operating setup, not a universal detector score. Its architectural lesson is stronger than its number: an apparently strong document model still needs bounded claims, operating thresholds, shift tests and an exception path.

Worked example: Meridian Components changes between reviews

Meridian Components Ltd. is a fictional wholesale importer with two recorded beneficial owners, one operating address and a stable supplier pattern. Its next scheduled review is months away. Three events arrive: a registry feed names a new director, a returned payment carries a different trading address, and a payment goes to a beneficiary in a country not present in the approved activity profile. A screening service also returns a possible match for the director.

The unsafe design sends each event to a separate queue. The director change becomes a screening update, the address becomes operations data and the payment becomes a monitoring alert. The KYC record remains “current” because the review date has not arrived. An equally unsafe event-driven design concludes that ownership, risk and suspicion have changed.

The evidence-bound workflow opens questions instead: has control changed, is the operating address current, does the beneficiary fit the stated relationship, and is the screening candidate the same person? The trigger record stores observation, source, event time, producing rule and affected proposition. The context compiler retrieves only sources authorised for those questions.

The registry confirms a new director but does not establish beneficial ownership. An approved service-location record supports the new operating address. An invoice and shipping record support a supplier relationship, while the relevant monitoring process retains responsibility for any suspicion assessment. The screening candidate shares a name but conflicts on date of birth and nationality. A customer response then contradicts the registry description of control.

The system produces a provenance table, proposition ledger, unresolved-conflict list, proposed customer-record diff and targeted outreach draft. It does not guess which control statement is true. The KYC reviewer examines the conflict, edits and approves the outreach, and decides whether evidence is sufficient under policy. Any change to risk rating, enhanced measures, restriction or relationship status remains with the named authority.

Customer outreach is controlled evidence acquisition

Once the proposition ledger exposes a gap, outreach should ask for the smallest evidence that can resolve it. A broad “refresh your KYC” request often collects identity, address, income and ownership documents regardless of which fact is uncertain. That increases privacy exposure and customer work while making it harder to explain why each item was necessary.

For Meridian, the unresolved proposition is current control. The request should identify the relevant entity, the control information already held, the observed discrepancy and the acceptable response route. It should not imply suspicion, ask every director for fresh proof of address, or request a full onboarding pack because one source changed. A language model may turn a structured gap into clear prose, but an approved policy service checks necessity, evidence type, jurisdiction, recipient and channel before dispatch. A named reviewer approves the final message.

The response re-enters the same evidence boundary. Attachments are untrusted content, and instructions inside them cannot change the task or permissions. Files pass malware, format and provenance controls before extraction. Customer statements remain customer-provided claims until the evidence contract applies the required validation or corroboration. Unrelated sensitive material is quarantined rather than copied into a general model context. Measure unnecessary requests, repeat contacts, abandonment and complaints beside drafting speed.

KYC facts do not automatically become suspicion

A changed address, new beneficiary or unresolved owner may be relevant both to customer due diligence and to transaction monitoring. That shared fact does not merge the decisions. The KYC workflow determines whether the customer profile remains supportable. A separate authorised financial-crime process determines whether activity warrants investigation or reporting under its own evidence and confidentiality rules.

The case can pass a bounded referral containing permitted facts and stable references. It should not expose restricted filing information back into ordinary KYC context, nor should a fluent case summary label the customer suspicious. This separation protects due process and prevents a model’s narrative from becoming an undeclared escalation mechanism. It also makes evaluation possible: profile correctness, screening disposition and suspicious-activity judgement can fail independently and need separate ground truth.

Design the review interface against automation bias

A fluent narrative placed above the evidence invites the reviewer to confirm its frame. A systematic review of automation bias in decision-support settings found that workload, task complexity and time pressure can increase over-reliance, while interface and accountability choices influence it. KYC requires direct testing, but the general warning is relevant.

Show contested propositions before the recommendation. Present supporting and contradictory evidence side by side. Make the reviewer open decisive source excerpts. Separate “I agree with this proposition” from “I authorise this action”. Record edits, rejected model suggestions and the basis for exceptions. The objective is not to slow every case. It is to spend attention where evidence or consequence makes judgement necessary.

Decision instrument: place each mechanism by evidence and consequence

The following matrix is an architecture decision record in compact form. It asks what the mechanism can establish, how its error becomes visible and who owns the consequence. Choose the least stochastic mechanism that can do the work without hiding the evidence boundary.

Prove the boundary with negative controls, failure injection and reperformance

A convincing architecture must show when its preferred mechanism is unnecessary. Consider a low-risk individual who presents a digitally signed credential through an approved identity service. The issuer is recognised, the credential is current, the subject binding passes, required attributes validate against an authoritative source, sanctions screening returns no candidate above the institution’s retrieval threshold, and no proposition is contested.

In that case a general language model adds no causal value. A deterministic flow can construct the proposition ledger, apply the obligation manifest and route the case according to policy. This is the negative control. If the proposed “AI KYC” design insists on generating a narrative anyway, it has confused universality with usefulness. The evidence-bound architecture should make the model disappear when the evidence is already structured and sufficient.

The explicit failure boundary

The workflow ceases to help when the necessary evidence relationship cannot be established. It cannot discover a beneficial owner whom every available source conceals. It cannot repair an issuer database that contains a wrong birth date. It cannot infer document authenticity from visual plausibility after the capture path has been lost. It cannot decide which jurisdictional interpretation applies without an approved policy owner. It cannot make a novel forgery detector reliable outside its tested distribution by adding a second model explanation.

Nor does a complete evidence packet guarantee one uniquely correct disposition. Two qualified reviewers may weigh credible but incomplete evidence differently, especially where policy allows judgement. The system’s duty is to expose the evidence, policy and consequence well enough to diagnose disagreement. The unresolved remainder belongs in an exception state with an owner, expiry and permissible next action.

Evaluate the control chain, not only the final answer

Accuracy on a labelled document set is one component metric. A release decision needs a chain of tests. Can the trigger identify material change without treating novelty as suspicion? Does retrieval preserve source coverage and access failures? Do extraction tests include negation, tables, transliteration and temporal qualification? Does entity resolution retain candidates when decisive fields conflict? Does the obligation service select the correct policy version? Does the reviewer interface expose contradiction before recommendation?

Then inject operational failures: stale registry data, corrected issuer records, an expired screening list, a source timeout, a malicious instruction inside an attachment, a duplicated customer response, a reviewer session that loses authority before approval and a write that times out after the downstream system commits. Each fault should have an expected state transition and recovery route.

Reperformance supplies the decisive assurance test. Give an independent authorised reviewer the retained packet, not the original analyst’s memory. Ask whether the reviewer can identify the active propositions, inspect decisive sources, reproduce the applicable policy, understand conflicts and verify the executed effect. Measure missing evidence, unsupported conclusions, disagreement causes and readback failures. Fast closure without reperformable evidence is throughput, not control effectiveness.

Executable artefact: a five-bond case evaluator

The following Python programme operates only on synthetic data. It assumes that source classification, policy approval and evidence collection have already occurred. It does not authenticate a document, screen a real person, calculate risk or decide whether a customer should be accepted. Its narrow purpose is to reveal logic that prose can hide: evidence is rejected when any bond fails, conflict is preserved, and only a fully supported case becomes ready for human disposition.

#!/usr/bin/env python3
"""Minimal evidence-bond evaluator for a synthetic KYC case.

The evaluator demonstrates one narrow claim: an item of evidence becomes
eligible for a proposition only when five independent bonds hold.
It is not a legal rule engine, sanctions screen, document authenticator,
or customer-risk model.
"""

from __future__ import annotations

from dataclasses import dataclass
from datetime import date
from enum import Enum
from typing import FrozenSet, Iterable


class Stance(str, Enum):
    SUPPORTS = "supports"
    CONTRADICTS = "contradicts"
    MENTIONS = "mentions"


class PropositionState(str, Enum):
    SUPPORTED = "SUPPORTED"
    CONFLICT = "CONFLICT"
    UNKNOWN = "UNKNOWN"


@dataclass(frozen=True)
class Evidence:
    evidence_id: str
    subject_id: str
    proposition_id: str
    stance: Stance
    valid_from: date
    valid_to: date | None
    source_class: str
    permitted_purposes: FrozenSet[str]
    semantic_support: bool


@dataclass(frozen=True)
class PropositionPolicy:
    proposition_id: str
    accepted_sources: FrozenSet[str]
    required: bool = True


@dataclass(frozen=True)
class Case:
    case_id: str
    subject_id: str
    purpose: str
    decision_date: date
    policies: tuple[PropositionPolicy, ...]


@dataclass(frozen=True)
class BondResult:
    subject: bool
    semantic: bool
    temporal: bool
    authority: bool
    purpose: bool

    @property
    def eligible(self) -> bool:
        return all((self.subject, self.semantic, self.temporal,
                    self.authority, self.purpose))

    def failed(self) -> tuple[str, ...]:
        names = ("subject", "semantic", "temporal", "authority", "purpose")
        values = (self.subject, self.semantic, self.temporal,
                  self.authority, self.purpose)
        return tuple(name for name, value in zip(names, values) if not value)


def evaluate_bonds(
    evidence: Evidence,
    case: Case,
    policy: PropositionPolicy,
) -> BondResult:
    """Evaluate the five evidence bonds for one item and proposition."""
    temporal = (
        evidence.valid_from <= case.decision_date
        and (evidence.valid_to is None or case.decision_date <= evidence.valid_to)
    )
    return BondResult(
        subject=evidence.subject_id == case.subject_id,
        semantic=(
            evidence.proposition_id == policy.proposition_id
            and evidence.semantic_support
            and evidence.stance in {Stance.SUPPORTS, Stance.CONTRADICTS}
        ),
        temporal=temporal,
        authority=evidence.source_class in policy.accepted_sources,
        purpose=case.purpose in evidence.permitted_purposes,
    )


def evaluate_case(case: Case, evidence_items: Iterable[Evidence]) -> dict:
    """Return proposition states, rejected evidence and a routing outcome."""
    items = tuple(evidence_items)
    proposition_states: dict[str, PropositionState] = {}
    rejected: dict[str, tuple[str, ...]] = {}

    for policy in case.policies:
        eligible: list[Evidence] = []
        for item in items:
            if item.proposition_id != policy.proposition_id:
                continue
            bonds = evaluate_bonds(item, case, policy)
            if bonds.eligible:
                eligible.append(item)
            else:
                rejected[item.evidence_id] = bonds.failed()

        stances = {item.stance for item in eligible}
        if Stance.SUPPORTS in stances and Stance.CONTRADICTS in stances:
            proposition_states[policy.proposition_id] = PropositionState.CONFLICT
        elif Stance.SUPPORTS in stances:
            proposition_states[policy.proposition_id] = PropositionState.SUPPORTED
        else:
            proposition_states[policy.proposition_id] = PropositionState.UNKNOWN

    required_states = [
        proposition_states[p.proposition_id] for p in case.policies if p.required
    ]
    if PropositionState.CONFLICT in required_states:
        route = "EXCEPTION_REQUIRED"
    elif PropositionState.UNKNOWN in required_states:
        route = "EVIDENCE_INSUFFICIENT"
    else:
        route = "READY_FOR_HUMAN_DISPOSITION"

    return {
        "case_id": case.case_id,
        "route": route,
        "propositions": {key: value.value for key, value in proposition_states.items()},
        "rejected_evidence": rejected,
    }


def print_result(result: dict) -> None:
    print(f"{result['case_id']}: {result['route']}")
    for proposition, state in result["propositions"].items():
        print(f"  {proposition}: {state}")
    for evidence_id, failures in result["rejected_evidence"].items():
        print(f"  rejected {evidence_id}: {', '.join(failures)}")


def demo() -> None:
    review_date = date(2026, 8, 30)
    common_purpose = frozenset({"KYC_REVIEW"})

    clear_case = Case(
        case_id="CASE-KYC-001",
        subject_id="MERIDIAN-LTD",
        purpose="KYC_REVIEW",
        decision_date=review_date,
        policies=(
            PropositionPolicy("legal_name", frozenset({"company_registry"})),
            PropositionPolicy(
                "operating_address",
                frozenset({"company_registry", "verified_customer_response"}),
            ),
        ),
    )
    clear_evidence = (
        Evidence(
            "REG-1", "MERIDIAN-LTD", "legal_name", Stance.SUPPORTS,
            date(2020, 1, 1), None, "company_registry", common_purpose, True,
        ),
        Evidence(
            "RESP-1", "MERIDIAN-LTD", "operating_address", Stance.SUPPORTS,
            date(2026, 7, 1), None, "verified_customer_response", common_purpose, True,
        ),
    )

    conflict_case = Case(
        case_id="CASE-KYC-002",
        subject_id="MERIDIAN-LTD",
        purpose="KYC_REVIEW",
        decision_date=review_date,
        policies=(
            PropositionPolicy(
                "current_control",
                frozenset({"company_registry", "verified_customer_response"}),
            ),
        ),
    )
    conflict_evidence = (
        Evidence(
            "REG-2", "MERIDIAN-LTD", "current_control", Stance.SUPPORTS,
            date(2026, 6, 1), None, "company_registry", common_purpose, True,
        ),
        Evidence(
            "RESP-2", "MERIDIAN-LTD", "current_control", Stance.CONTRADICTS,
            date(2026, 6, 1), None, "verified_customer_response", common_purpose, True,
        ),
    )

    weak_case = Case(
        case_id="CASE-KYC-003",
        subject_id="PERSON-42",
        purpose="KYC_REVIEW",
        decision_date=review_date,
        policies=(
            PropositionPolicy(
                "identity_document",
                frozenset({"trusted_capture_service", "issuer_validation"}),
            ),
        ),
    )
    weak_evidence = (
        Evidence(
            "IMG-1", "PERSON-42", "identity_document", Stance.SUPPORTS,
            date(2026, 8, 1), None, "forwarded_screenshot",
            frozenset({"CUSTOMER_SUPPORT"}), True,
        ),
    )

    for case, evidence in (
        (clear_case, clear_evidence),
        (conflict_case, conflict_evidence),
        (weak_case, weak_evidence),
    ):
        print_result(evaluate_case(case, evidence))


if __name__ == "__main__":
    demo()

CASE-KYC-001: READY_FOR_HUMAN_DISPOSITION
  legal_name: SUPPORTED
  operating_address: SUPPORTED
CASE-KYC-002: EXCEPTION_REQUIRED
  current_control: CONFLICT
CASE-KYC-003: EVIDENCE_INSUFFICIENT
  identity_document: UNKNOWN
  rejected IMG-1: authority, purpose

A release gate for an evidence-bound KYC workflow

Release should be denied unless the team can answer eight questions with operating evidence. Are propositions and evidence contracts versioned? Can every evidence item be traced to source and transformation? Are valid time and knowledge time separate? Does access bind actor, subject and purpose? Can a model proposal change no consequential record directly? Are conflicts and unknowns visible in the reviewer interface? Do ambiguous writes use idempotency, effect receipts and readback? Can an independent reviewer reperform representative decisions?

Monitor the same chain after release. Useful measures include candidate recall before reranking, false clearance and false escalation by subgroup, document-control performance by device and attack family, source-availability and staleness, proposition conflict rate, avoidable outreach, reviewer disagreement, override reason, unknown-outcome frequency, duplicated-effect prevention and time to resolve exceptions. Customer burden and contestability belong beside operational cost.

The most important drift signal may not be model drift. A registry changes its semantics. A policy version expires. A screening source adds new fields. A customer population shifts toward documents absent from validation. A reviewer team begins approving faster under queue pressure. The case ledger must connect each observed change to the decisions and controls it could invalidate.

stateDiagram-v2
  [*] --> Claim
  state "The five evidence bonds" as Claim
  state "Worked example: two<br/>candidates, the same score" as Test
  state "Evidence contracts prevent<br/>semantic promotion" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Compact glossary

Identity proposition

A bounded claim about a person or entity, such as legal name, current control or screening identity, evaluated for one case and time.

Evidence contract

The approved definition of what can support or contradict a proposition, including source class, time, corroboration, conflict and deciding role.

Case state

The typed, replayable set of propositions, evidence, policy, conflicts, decisions and effects. It is distinct from a transcript or generated summary.

Disposition

An accountable decision about an unresolved or consequential case, made by the role named in policy rather than inherited by a model or connector.

Effect receipt

A record returned by the executing system that identifies what action was accepted or committed, with enough information for independent readback.

Unknown outcome

A state in which a command may have succeeded although the caller did not receive a definitive response. The safe next step is reconciliation, not blind retry.

Preserve the evidence relationship, and the automation boundary becomes clear

KYC is often described as collecting documents, screening names and assigning risk. That description makes the document, score or profile appear to be the product. The real product is a defensible decision about bounded propositions under a particular policy, time and authority.

The architecture should therefore optimise for reconstructible evidence relationships, not maximal automated closure. It should know which subject an item concerns, what proposition it supports, when it applies, why its source is accepted and whether its use is permitted. It should preserve contradiction and absence. It should let specialised controls do specialised work, use models where language or ambiguity makes them useful, and keep consequential disposition with the named authority.

This changes the programme plan. Do not begin with a universal KYC agent. Begin with one proposition family, its evidence contract, source coverage, exception route and effect boundary. Establish a deterministic baseline. Add model assistance only where it produces a measurable improvement in evidence completeness, comparison or reviewer effort without reducing candidate recall, reperformance or contestability. Inject failures before scaling.

The durable outcome is not a better summary. It is a KYC case state another authorised person can inspect, challenge, reperform and recover. When evidence is sufficient, the workflow moves. When it is conflicted, it asks a precise question. When the world cannot yet support a conclusion, it says so. That is not a limitation to hide. It is the control.