Case work
A workbench, not a workflow. AI, APIs, decision logic and people work the same case file, in whatever order the evidence actually arrives - and every part of how the decision was reached is traceable, explainable and auditable.
Evidence does not arrive in order
Some decisions cannot be answered in 200 milliseconds. The decision takes days or weeks. Evidence dribbles in from a dozen places at unpredictable times. A person looks at some of it. An AI reads a document. A bureau answers. Somebody uploads a corrected file on day nine that invalidates a conclusion reached on day two.
Classic case management asks you to draw that as a flowchart in advance. Every "what if this arrives late" becomes another branch and another loop-back arrow, until the diagram has two hundred boxes, nobody dares change it, and the real logic lives in the exception handling.
No flowchart. No pointer. Nothing to rewind.
A task declares only what it reads and what it produces. Nothing declares what runs next.
There is no current-position pointer on a case, and there are no transitions between tasks. Instead there is a case file - everything known about the case so far - and a set of tasks that each watch it. A task runs when its inputs are on the case file and its own output is missing or out of date. Never because something before it called it.
The order is derived from the data. Nobody authors it. Every advantage of this design comes from that one decision.
A business onboarding case, day by day
| When | What happens |
|---|---|
| Day 1 | A company applies. The case file has the application and the registration number. A registry lookup runs - nothing told it to, its input simply arrived - and produces the company record and three beneficial owners. |
| Day 1, moments later | Three sanctions screenings run in parallel, one per owner, because the owner records now exist. An AI task reads the submitted articles of association and extracts the ownership percentages. |
| Day 1, still | A decision logic task evaluates the risk rules against everything gathered so far and concludes: refer to a human. A review task appears in the right queue, routed by role rather than by name. |
| Day 9 | The customer uploads a corrected shareholder register. One beneficial owner was wrong. |
And here is the entire difference
In a workflow engine the case is sitting at box seven of the diagram. The corrected document does not rewind anything. Either somebody manually notices that the screening from day one was run against a person who was never a real owner, or nobody notices, and the case is approved on evidence that has been invalid for a week.
Here, the corrected document lands on the case file and everything that read the old owner data is out of date automatically. The AI re-extracts. The screening re-runs for the new owner. The risk rules re-evaluate. The human review re-opens with the changed evidence flagged. Nobody authored "if a corrected register arrives, go back and redo the screening". Nobody could have. It happens because the answer depended on the input, and the input changed.
Six task types, one case file
These are not separate systems bolted together. They are task types on the same case file, which is why they compose.
Human review
Read what arrived, judge what it means, or supply what is missing on a form built from exactly what the case still needs. Work routes by role, so a case never waits on one named individual.
AI
A language model reads, extracts, classifies, summarises or drafts - running a governed, versioned AI configuration rather than an ad-hoc prompt.
Document OCR
Documents become structured records on the case file.
Decision logic
A real rule set, decision table, scorecard or full decision flow: the same versioned, tested artifacts used in real-time decisioning.
External data
Bureaus, registries, sanctions lists, KYC providers, any REST API.
Memo
Derived values and calculations.
Three things that follow from having no fixed order
- They collaborate in both directions. A person’s answer can trigger an AI task, an AI extraction can trigger a rules evaluation, and a bureau response arriving on day four can re-open a human review completed on day two. In a workflow engine, backwards is an exception path somebody had to draw. Here it is the normal mechanism.
- The AI and the rules are governed artifacts. When a task calls a language model or evaluates a scorecard, it runs a real platform entity - versioned, testable, revisable, releasable, shared with your real-time decisioning. The prompt is not typed into a text box on the task. Your case work and your instant decisions cannot say different things about the same policy.
- Nothing blocks. A slow external call and a human being are the same shape to the engine: both write a pending fact onto the case file, and the case carries on doing everything else it can. When the answer arrives, from a person or from an API, whatever depended on it wakes up. No thread waits, and no case is stuck because one lookup is slow.
Because the order is derived, the system knows why everything happened
Auditability here is not a logging feature bolted on. It falls out of the architecture.
- Every fact knows where it came from - which task produced it, when, and in which run. There is no anonymous state on a case.
- Every task run can be justified. Not just that it ran, but why: which piece of evidence changed, and therefore made its previous answer out of date.
- The full activity trail, in the order things actually happened, including the re-runs. A conclusion that was reached, invalidated by new evidence and reached again is visible as exactly that, rather than being silently overwritten.
- Every automated task carries its own trace. A decision logic task brings the rule-by-rule, predictor-by-predictor explanation from the decision engine. Open the case, open the task, see which rule fired on which value.
- The exact version of the design that ran. Case designs compile into immutable releases. A case that ran in March ran against March’s release, and that release is still there, still readable.
Built like software, by people who do not write software
Case processes elsewhere are configured live, by hand, with no version history and no way to test a change except to let it run on real customers.
- Built with AI assistance. Describe the process, or point the assistant at the written procedure, and review what it proposes one change at a time against a visible diff before anything saves.
- Impact analysis before you change anything. Pick any input - a record attribute, an external data key - and the platform tells you which tasks would re-run and whether open cases would re-open. It computes that from the same dependency extraction the runtime uses, so the answer cannot drift from reality. A flowchart cannot answer this question at all, because there the dependencies are implicit in the drawing.
- Test with real scenarios in a sandbox. Run a whole case through the design, watch every task fire and every piece of evidence accumulate, before publishing.
- Versioned and released. Full revision history on the design and on every task, regression tests captured from real runs, and immutable releases with lineage and release-to-release comparison.
Built for
Onboarding and KYB · commercial and complex underwriting · claims handling · AML alert review · fraud investigation · disputes and complaints · credit restructuring.
Questions we get asked
New evidence arrives that invalidates a conclusion the case already reached. What happens?
Everything that depended on the old evidence becomes out of date automatically, and re-runs. This is the question worth asking every vendor you evaluate. Elsewhere the answer involves a human noticing.
How is this different from a BPM suite?
A BPM suite asks you to draw the process in advance. We ask what each task needs and what it produces, and derive the rest. Their exception paths are our normal operation.
Is a queue with a status field not enough?
That is what a case module in a CRM gives you. It works until evidence from day one turns out to be wrong on day nine, at which point nothing tells you what is now unsafe to rely on.
Do the rules here differ from our real-time decisions?
No, and that is the point. A decision logic task runs the same versioned rule set or scorecard your instant decisions use, so the two cannot say different things about the same policy.
Can we test a change to a case design before it goes live?
Yes. Run whole cases through the design in a sandbox, capture regression tests from real runs, and use impact analysis to see which tasks would re-run and which open cases would re-open before you publish.
Where does case data live?
The whole case file sits on your side, in a Postgres database you own. Execution can run in your own environment, and documents stay in storage you control with credentials in a vault you hold. Execution data reaches the endpoint in order to be decided on, and is not retained there.
Decisions that answer in milliseconds
When a decision can be made in one request, it should be. The same rule sets and scorecards run there too.