The status that is computed instead of entered

An international group, a whistleblowing channel. In each case, a Status field, as a drop-down list. On paper, nothing could be simpler.

A drop-down list is a statement

A status in a drop-down list is someone stating where the case stands. The day they choose it, it's true.

Then the case moves forward. The investigation ends. The report is submitted. And the status stays where it was left.

Nobody lied. Someone simply forgot to update it. It's human, and that's exactly the problem: a field that depends on someone's memory ends up wrong.

Multiply that by the number of cases. You get a dashboard that shows statuses without being able to say which ones are still true.

Turning the logic around

I turned the logic around. The status is no longer entered. It's computed.

It's deduced from the facts of the case:

• the investigation closing date;
• the report closing date;
• the conclusion on the facts.

At every save, the application rereads these facts and writes the status automatically. Always with the same rule. A single rule, and a documented one.

For the user, nothing gets more complicated. They fill in the facts of the case: a date, a conclusion. The status updates itself on save.

The result: a case is "Closed" when the objective conditions are met. Not because someone clicked "Closed".

The status is no longer a field to fill in. It's a consequence. It follows the case, instead of depending on someone's memory.

What changes in an audit

In an audit, the question isn't only "what is the status of this case?". It's also "why this status?".

With an entered status, the only possible answer is: "because someone chose it". That isn't proof. It's a memory.

With a computed status, the answer can be proven. Here are the facts of the case. Here is the rule. Here is the result. The status is provable, case by case.

It's the same idea as in accounting. Nobody asks you to believe a balance. They ask you to support it with documents. A computed status is supported by the facts of the case.

The rule behind it

The rule I draw from it fits in one sentence: anything that can be deduced from the data should never be entered.

A closing date already exists in the case. Entering it a second time, in the form of a status, creates a second truth. And two truths end up diverging.

This rule applies far beyond a whistleblowing channel. A progress status, a missed deadline, a complete or incomplete file: as soon as the answer is in the data, it's up to the tool to compute it.

It also has an effect on the teams' work. There's one less field to fill in, and one less possible oversight. The energy goes into the facts of the case, not into summarizing them.

What this means for you

Open one of your tracking tools. Spot the fields your teams update by hand. For each one, ask the question: is the answer already somewhere else in the file?

• If the status depends on dates that already exist, it can be computed.
• If an "overdue" indicator depends on a known deadline, it can be computed.
• If a "complete" file depends on documents being present or missing, it can be computed.

Every computed field is a field nobody can forget. And, on audit day, it's a field you prove instead of defending.

This computed status is part of a larger tool, told in the case study A whistleblowing channel that watches its own deadlines. The same tool also counts its overdue cases: regulatory deadlines watched by the tool. And it works out each person's role with no list to maintain: no list of administrators. This kind of tool is described on the page An application instead of the Excel file.

Anything that can be deduced from the data should never be entered.