Regulated intake that resumes with the full case intact

Client onboarding at a regulated institution is a case that can remain open for weeks. Documents arrive in batches, some expire along the way, and the completeness checklist often lives in the operator's memory. When the operator goes on vacation or the process restarts after a new release, someone may have to reconstruct the case from scratch.

The controlled version uses 12 generated case sets and contains no client data.

Automating such a process requires durable state across days and restarts. It also requires a firm action boundary, because a support system in a KYC process must not approve the client or perform a restricted action.

Interruption as a first-class state

In our document intake system, waiting is a normal process state. The workflow compares the case file with the required set for the entity type, checks data consistency and validity dates, and saves the full state in a database when a document or human decision is missing.

At each step boundary, a checkpoint records the workflow state. After an interruption, work resumes with the same files, history, and next step. The public check covers an API restart. Multi-day uptime and compatibility across application versions still need testing in the deployment environment.

The restart check records the case state, restarts the API, and compares the resumed state with the earlier record. The tested case retained its files, history, and next step. The same check belongs in deployment infrastructure and release testing.

A boundary made of absence

The second requirement is enforced through the tool registry: the system cannot approve a client because no approval tool exists.

The tool registry has exactly seven entries: document read, classification, the required set, file state, consistency check, a draft request for the missing item, and internal escalation. Approval, sanctions screening, and risk scoring are absent from the registry. The product screen documents that boundary in the action-scope tab.

That boundary survives model error or attack because the restricted action has no callable tool. Both prohibited-output checks held, and completeness assessment made no false-complete decision across 1,000 generated intake states. A separate small-model document read using gpt-5-mini took 1.81 seconds and cost about PLN 0.00089.

What a durable case state must contain

A checkpoint is useful only if work can resume without reconstruction. It should retain the received documents, versions and expiry dates, identified gaps, unresolved contradictions, completed checks, human decisions, and the next permitted step. A status labeled “waiting” is insufficient if the operator still has to reread the correspondence.

Every transition also needs idempotency. Receiving the same file twice or replaying a message after failure must not create a duplicate case state or send another request. Documents need stable identifiers, and external actions need keys that let the workflow recognize a completed operation.

Versioning needs an explicit policy. If document requirements change while a case is waiting, the owner must decide whether the case follows the policy at opening or the current policy. The chosen ruleset should be recorded with the case.

Designing the pilot

Begin with one entity type and a limited document set. Describe the allowed states, transition conditions, human actions, and events that trigger a complete recheck. Classification and gap detection come after that process model.

Restart tests should interrupt the workflow at every meaningful boundary: after receipt, after classification, before a request, after an operator decision, and across a software release. Compare the next step, history, already completed external actions, and the number of files.

Include a handover exercise. If a second operator can understand the case, evidence, gaps, and required decision from the stored record alone, the checkpoint is doing operational work.

Measuring value and risk

The number of cases marked complete is unsafe as a headline measure unless false completeness is reported separately. Prioritise cases incorrectly declared complete, missed contradictions, duplicate requests, and files that could not resume without manual reconstruction.

For value, measure active operator time, contacts per case, delay caused by unclear requests, and handovers between staff. A model read cost excludes the database, integrations, archival controls, and exception handling. Treat it as one line in the operating calculation.

Durable-process checklist

1. Does the state retain documents, versions, gaps, decisions, and the next step?
2. What happens when the same file or event arrives twice?
3. How are requirement changes applied to cases already in progress?
4. Can each external action be replayed safely or recognized as complete?
5. Which sensitive actions are deliberately absent from the tool registry?
6. Are restarts tested at every important state and across software versions?
7. Can another operator take over using only the recorded state?
8. What is the recovery path when a checkpoint is incomplete or corrupted?

What this means for the process

The operator opens the case room and sees files with gaps named explicitly and the next step for every case. A ready draft points to the specific missing item, sparing the operator from reconstructing the request from memory. On resumption, the operator sees the case with its recorded decision history.

The audit record makes the operating boundary explicit: a human always closes the intake, and every system capability appears in a closed registry. This gives a regulated team a workflow it can explain and verify.

Details and measurements are on the case page. If your onboarding drags for weeks on checklists in people's heads, a free process scan is a good place to start.