Ask three people in the same team whether a case is complete and you will often get three answers. Not because anybody is careless — because "complete" was never written down anywhere a system could read it. It lives in the experience of whoever has done this a hundred times.
That works, and it keeps working right up until that person is on holiday, or the volume doubles, or a regulator asks how you know.
Completeness is a property, not an opinion
The shift is small to describe and large in effect: the process declares what a complete case looks like, and every case is created already carrying that declaration.
Not a checklist in a wiki. Not a template someone copies. The list belongs to the process, and when a case is created the required items are materialised into it — so the case itself can answer "what am I missing" without anybody consulting anything.
Once that is true, completeness stops being a judgement and becomes an evaluation. The system can answer it, at any moment, identically for every case and every person.
Four states, not two
The most common mistake when teams first model this is a boolean: the document is there, or it is not. That is not enough to be useful, because it collapses distinctions that matter operationally.
A required document is realistically in one of these:
- Missing — nothing has been provided.
- Partial — something arrived, but the requirement asks for more (three pages of a five-page contract; one of two signatories).
- Delivered but unverified — a file exists and nobody has confirmed it is the right thing.
- Validated — somebody with the authority to say so has accepted it.
- Rejected — it was looked at and refused, and the case is waiting for a correction.
- Expired — it was valid and no longer is.
The fifth and sixth are where boolean models fail hardest. "Rejected" and "missing" look identical to a checkbox and mean very different things to the person who has to act. And expiry is the one nobody builds until an auditor asks whether that insurance certificate was current on the date of the decision — a question a store of files cannot answer at all.
Who decides, and what they are allowed to decide
Separating these two roles is what makes the model hold:
The process owner decides what is required. Which documents, how many files each, whether it is mandatory, whether it expires and after how long. This is a design-time decision, made once, for every case of that kind.
The reviewer decides whether what arrived satisfies it. This is a per-case judgement and it should stay one — no system can tell you whether a photograph of a passport is legible.
The failure mode is letting either one do the other's job. When reviewers can quietly waive a requirement, the declared list stops describing reality. When the process owner's list is so rigid that reviewers cannot record a legitimate exception, people work around the system, which is worse than either.
The resolution is that exceptions are recorded rather than hidden: a requirement can be waived, by somebody with the authority to waive it, with a reason, and the case carries that fact forever.
Why a snapshot, not a live reference
One detail that looks like an implementation choice and is really a governance one: when a case is created, the requirements should be copied into it, not referenced.
If the case points at the live process definition, then changing the process changes the past. A case approved in March under three requirements silently becomes a case that needed five, and the record of its approval now looks like an error. Nobody edited that case; its history changed underneath it.
Copying costs a little storage and buys the property that matters: what a case needed is what it needed at the time, and a decision made against it stays legible for as long as the record exists.
The one thing to build first
If you take one idea from this: make the system able to say which requirement is unmet, not just that something is.
"This case is incomplete" is a message people learn to ignore. "Proof of address is missing, and the insurance certificate expired on 14 May" is a message people act on — and it is the difference between a control that speeds work up and one that everybody routes around.