(CASE 01 · SELF-INITIATED · 5 DAYS)

Records what was checked.
Not just what was decided.

Docket is an AI-assisted compliance review console for anti-money-laundering analysts, framed for a GB-licensed remote casino and designed end to end in five days as a self-initiated build. Audit trails prove who decided and rarely what was checked, Docket makes the checking itself the record. No client, no users, no invented metrics.

ROLE
Designer, end to end
CLIENT
Self-initiated, no client
TIMELINE
Five days, August 2026
STATUS
Design complete, 9 of 14 DoD items closed

22 SCREENS × 2 MODES · 3,560 CONTRAST CHECKS · 0 FAILURES

The Docket queue staged in a browser: every case, its flags, and where the work stands
FIG. 01 · THE DOCKET — EVERY CASE, ITS FLAGS, AND WHERE THE WORK STANDS
ENTRY 01 The stake
RECORDED

The claim became the atomic unit.

An audit trail proves who decided. It almost never proves what was checked, which is the question an analyst actually faces months later, in front of a reviewer. A pass across Hummingbird, Unit21, Sumsub and WorkFusion found no product that treats individual claims as first-class objects with their own verification state. So that became the move: the claim, one verifiable statement with a source, a verdict and an asserter, is Docket’s atom, and everything else is built out of it.

The Docket review view staged in a tilted browser: claims on the left, evidence on the right

FIG. 02 · THE REVIEW VIEW

Claims on the left, the evidence on the right. The analyst works through statements, not documents, and the screen keeps both in view.

ENTRY 02 The mechanic
VERIFIED

Verification takes two seconds, not a search.

Click a claim and the cited line highlights inside the source document, with the OCR boundary drawn around exactly what the model read. That is the whole mechanic. The model reports its boundaries instead of performing confidence, and it never recommends: it reads, it cites, and the verdict stays with the analyst. An assistant in a regulated review earns trust by showing its work, not by being sure.

The record view staged in a browser: every claim as answered, with dwell times, sources and who asserted what
FIG. 03 · WHAT THE MECHANIC LEAVES BEHIND — EVERY VERDICT WITH ITS SOURCE AND DWELL TIME
ENTRY 03 When the model is wrong
PRESERVED

Five failure states, none of them erased.

Override, a citation that will not resolve, two sources that conflict, a rule that changed mid-case, and the model going down entirely. Each one is a designed state, and each one preserves the record instead of cleaning it up: when an analyst overrides the model, the model’s reading stays in the file next to the human verdict. Being wrong is allowed. Hiding it is not.

Failure state staged in a browser: analyst override, model reading preserved
Failure state staged in a browser: a citation that will not resolve
Failure state staged in a browser: two sources that conflict
Failure state staged in a browser: a rule that changed mid-case

FIG. 04 · OVERRIDE · UNRESOLVABLE CITATION · CONFLICTING SOURCES · RULE CHANGED

Docket's dark mode staged in a browser: the queue in the ink theme

FIG. 05 · INK

The console’s dark mode is a first-class theme, not an afterthought: the same console, 44 frames audited in both modes, 3,560 contrast checks, zero failures.

ENTRY 04 The record
SEALED

The reasoning ships with the decision.

The output of a review is a time-ordered, version-stamped record of what was checked, in which order, against which version of which rule, and why a contradiction did not block approval. It is sealed with the analyst’s and the reporting officer’s signatures. The most delicate law in the product is handled the same way: tipping-off protection keys off the state of the case, whether a disclosure exists, rather than a list of banned phrases, and the reporting officer’s screen carries the two statutory clocks in plain sight.

The request-evidence dialog staged in a browser: what it asks, what it does to the clocks, and the tipping-off note

FIG. 06 · THE EVIDENCE REQUEST

Asking a player for a document, with the consequences on the surface: what it asks for, what it does to each clock, and the tipping-off rule keyed off the state of the case. The law sits in the interface, where it is hardest to forget.

ENTRY 05 The review
CORRECTED

Three critics tried to break it. They found things.

Before the design was called done, three independent critic passes went through it. They found a misquoted regulation, a licence condition that does not exist, and a tipping-off block that was legally wrong, and all three were corrected in the file. The system underneath held: one component set spanning two axes, paper and ink, pointer and touch, with no per-mode variants.

3,560

CONTRAST CHECKS, RUN ACROSS 44 FRAMES

550

INTERACTIVE TARGETS AUDITED

0

ACCESSIBILITY FAILURES

The master style frame: tokens, type and both modes on one sheet
FIG. 07 · THE MASTER STYLE FRAME — TOKENS, TYPE AND BOTH MODES ON ONE SHEET

Not done, and saying so.

Nine of fourteen definition-of-done items were closed when this was written. The open ones stay on the record, because a record that only lists finished things is marketing.

The escalations queue staged in a browser
The Docket queue on mobile, staged
The Docket queue on a phone, staged wide
The review view staged in a browser

Docket

SELF-INITIATED · THE RECORD IS THE PRODUCT

CLAIMS AS THE ATOMFIVE FAILURE STATES, PRESERVED3,560 CHECKS · 0 FAILURES
FlowLift cover

NEXT CASE

FlowLift. Sixty screens in seven days, with every decision argued.