Case history: what you should be able to reconstruct a year later

A company discovers it has no case history at exactly the moment somebody asks for it. An inspection, an audit, a dispute with a counterparty, a complaint from a year ago, a board question after a project went wrong.

And by then it is too late, because history cannot be written retrospectively. Files can be recovered, e-mails can be found, people can be asked, but you cannot demonstrate who took a decision and when if nobody was recording it as it happened.

The ten-minute test

Before reading on, do this for real, because the result is more interesting than the rest of this piece. Take any case from a year ago: an order, a contract, a complaint, a project. And answer five questions.

1. Who created it, and when?

2. Who last changed the amount or the deadline?

3. Who approved it, and exactly when?

4. Which version of the attachment were they looking at when they approved?

5. Who had access to it over that year?

Most companies answer the first, some the third, and almost none the fourth and fifth. If you cannot answer at least four out of five, you do not have a case history. You have files and the memory of the people who worked on it.

A file is not a case

The most common misconception is that the company has an archive, therefore it has a history. These are two different things and worth separating once and for all.

A file archive answers the question of what was produced. A case history answers the question of what happened. A folder holding a contract, an amendment and a scanned protocol tells you those three documents exist. It does not tell you that the amendment came about because the client raised an objection, that a department head approved it rather than the board, and that this happened three days after the deadline everybody had agreed on.

That difference is irrelevant most of the time. It becomes relevant precisely when a case turns contentious, which is the only moment any of it is needed.

Four layers that have to be recorded

A full case history consists of four layers. Most companies have one, sometimes two.

1. The data. Which field changed, from what value to what, who did it and when. Not “record updated”, but specifically an amount going from one figure to another.

2. Files and their versions. Not merely that an attachment exists, but which version of it applied on a given day. This is the layer that settles disputes about what was actually agreed.

3. Decisions in the process. Who approved, who rejected, with what comment, at which stage and how long it took. This is not the same as a change to a status field.

4. Access. Who viewed the case and when. With personal data and commercial information this often matters more than who changed it.

The third and fourth layers cannot be added later. Either the system records them from the outset, or that information simply does not exist.

Permissions are part of the evidence

“Everybody had access” is also an answer to an auditor's question. It is simply a bad one.

If any employee can open a case and change something in it, then knowing who changed it loses half its evidential value. Change history works as evidence only once the circle of people able to make that change was limited, and you can show how it was limited at the time.

So permissions and history are one subject, not two. A system that logs everything while allowing everyone to do anything produces an event log rather than evidence.

Retention: what gets deleted, when, and on what basis

The other side of the same coin. Keeping everything indefinitely is not caution, it is the absence of a decision, and with personal data it can be a problem in itself.

Sensible retention needs three decisions: how long a given kind of case is kept, what exactly is removed afterwards, and what remains as evidence that the case existed. Usually the content and attachments go while the record stub stays, because it weighs almost nothing and rescues you in a dispute.

The crucial part is that retention should be a process rather than an annual tidy-up done when somebody remembers. A process means the deadline counts itself, and somebody signs off before anything is deleted.

What no tool will fix

This needs saying honestly, otherwise the whole piece reads as a promise nothing can back.

If a decision was taken in a corridor conversation, no system will record it. If a manager said go ahead and the formal approval appeared a week later, the history will show that second date and it will be an incomplete truth.

The system's job is not to watch the corridor. It is to make the corridor unnecessary: to make approving a case take less effort than mentioning it to somebody over coffee. If the formal path is slower than the informal one, people will use the informal one and they will be right.

Where to start

Not by rolling out an event log across the whole company. By picking one kind of case where the question “who decided this” comes up most often, and bringing it to the point where it passes the test at the top of this piece.

Usually that means contracts or complaints. Both carry disputes, deadlines and real consequences, so the benefit shows up immediately rather than at the first inspection.