The architecture adapts to the customer it meets. The customer never adapts to the architecture.

What this brief is for

The AML Paradox set out the cost of the current verification model. The Witness Model brief set out the architectural shift the existing legal framework already supports. This piece picks up where both end: what does the witness model actually look like in operation, when a real customer arrives at the platform?

The mechanism matters because it is the part most often misunderstood. Read at a distance, confidence-accumulation verification sounds like a checklist - three proof levels, run each one, issue a certificate. That description is not accurate. What actually happens is more interesting, and is the reason the architecture can be both lighter-touch for clearly-verified customers and substantially deeper for ambiguous ones - without ever collecting more documents than the customer themselves chose to put on a public record.

This brief describes the architecture at the level a regulator, an underwriter, or an interested professional reader needs to understand it. The deeper technical description sits in the WhyAML technical documentation set; the patent applications cover the implementation.

Two concurrent streams at the threshold

When a customer begins a verification, the platform runs two streams of evidence-gathering in parallel. They are independent of each other in source, in method, and in what they evidence - and they run simultaneously, not sequentially. The customer experiences a single guided process; what is actually happening underneath is two parallel investigations, each one drawing its conclusions independently.

By the time the customer has completed the foreground stream, the background stream has its initial reading. Two streams, two independent pictures, ready to converge.

Convergence - what the two streams together produce

The platform reaches the end of Proof Level 1 with two independent pictures of the same person. In the cleanest case, both streams agree strongly: the customer's declared identity matches their public record completely, their institutional relationship looks active, ordinary, and consistent with the declared profile, and the two streams reinforce each other. The threshold for institutional connection has effectively been crossed before any additional proof has been requested.

In the less clean cases, the streams disagree, or converge weakly, or one stream is rich while the other is thin. A customer with a strong civic record but a very recent or thinly-populated institutional relationship; a customer with a deep institutional history but inconsistent address triangulation; a customer whose answers to the dynamic knowledge-based questions are correct but slow, or correct but unusual. The system can read each of these patterns. None of them is a failure; each is a signal about which path through the remaining proof levels makes sense.

The convergence picture at Level 1 is what determines what the remaining proof levels actually do. The same architecture, meeting two different customers, will move differently through Levels 2 and 3.

Dynamic task composition at Levels 2 and 3

Proof Levels 2 and 3 are not single fixed tests. Each level holds multiple tasks of different evidential weight: at Level 2, a DKIM-validated institutional communication, a live two-factor authentication on the institutional account, or both, in different combinations; at Level 3, a Transaction Anchor (evidence of a regulated-threshold transaction with the institution within the lookback window), a Natural Transfer (an upcoming routine transaction observed in real time), or where immediate proof is required, a small transfer from the selected institution within a defined window.

What the platform actually requires from any given customer is composed dynamically from these available tasks, based on the convergence picture the two streams produced at Level 1. A customer whose streams converge strongly may complete on the lighter task at each level; a customer whose convergence is ambiguous is routed through additional or harder tasks until either the institutional-connection threshold is reached or the path concludes with a NO determination.

The dynamic composition is what makes the architecture both proportionate to risk (low-risk customers complete quickly) and rigorous when the situation demands (ambiguous customers face deeper proof). Crucially, the proportionality is not negotiated by the customer or the firm. It is determined by what the architecture has already learned from the convergence at Level 1 - and is recorded.

The path itself is the audit trail

Every verification produces a Broker Compliance Certificate. The Certificate records, among other things, the timestamped flow of the verification - which tasks were applied, which were completed, and at what point the institutional-connection threshold was reached. The proof path each customer took is, in this sense, the customer's own audit trail.

This is what makes the Regulation 33 enhanced due-diligence argument concrete rather than asserted. A regulator examining the firm's compliance can read, on the face of the Certificate, that a customer who presented elevated signals was routed through additional proof - and that a customer with strong convergence was not put through scrutiny disproportionate to their risk profile. The proportionality required by the risk-based approach is not the firm's claim; it is visible in the record.

This is also what makes the architecture defensible when the next AI-driven evolution arrives. Synthetic documents defeat the document-centric model in part because every customer is put through the same brittle checkpoint. The witness model, with dynamic task composition, has no single checkpoint to defeat - each customer's verification is composed from independent streams and tasks that strengthen each other, and the composition itself is calibrated to what the convergence picture shows.