Keeping a Record of Who Approved What, and Why It Matters in Year Three

A client asks why a figure in a report from two years ago says what it says. The person who approved it has left. The tool that produced it has been upgraded twice. Somebody starts searching their email.

An approval record is only worth keeping if it can answer that question without anyone's memory. That means storing what was approved, not just that approval happened: the exact content at the moment of the decision, who decided, when, and what they could see. Most systems record the fact and lose the substance, which is the half that matters in year three.

What an approval record is for

On day one it is a control. Someone with authority looked at this before it went out.

By year three it is evidence, which is why it is worth checking against what an audit trail should contain if a regulator asks. Somebody is questioning a decision and the only useful reply is a reconstruction of what was known at the time. Nobody is going to remember. The record either carries the answer or it does not.

Those two purposes want different things. The control only needs a name and a timestamp. The evidence needs the content. Build for the second and you get the first for free.

The five fields that survive

Everything else is optional. These are not.

• The content as approved. Stored, not linked. A link points at a document that has been edited eleven times since.
• Who approved. A person, not a role and not a shared account. "Finance" is not an approver.
• When. With a timezone, because a date alone becomes ambiguous the moment your firm has two offices.
• What they were shown. The approver saw a screen. What was on it? If the screen showed a summary and hid the detail, the record should say so, because the fair question later is what the person could reasonably have caught.
• What produced it. Which agent or process, running under which configuration. Not the model's internal workings, just enough to know that the thing running in March was not the thing running in September, which is also what you need in order to undo what an agent did.

If you record only one of these badly, make it not be the first. A record that says "Priya approved it" with a broken link is close to worthless.

Storing the content, not the pointer

This is the mistake worth naming loudly. Teams store an approval as a row with a reference to the document. The document lives in a normal editable store. Two years later the document has moved on, and the approval row now attests to something that no longer exists.

Keep a copy of the content at the moment of approval, immutable, alongside the record. It is boring and it costs storage and it is the difference between an answer and a shrug.

If the content is large, store a hash at minimum, plus enough of a rendering that a person can read what was decided. A hash alone proves nothing changed but tells a client nothing they can understand.

Format, so it is readable later

Assume the system that wrote the record will not be the system reading it.

• Plain, self describing formats. Text and JSON outlive proprietary exports.
• Human readable field names. Someone unfamiliar will read this.
• Identifiers that mean something outside the tool. A record referring to internal row 48213 is useless once that database is retired.
• One record per approval, complete on its own, rather than a row that only makes sense when joined to four other tables.

The test is simple. Could someone hand a single approval record to an outside party, with no access to your systems, and would it make sense?

How long to keep it

Longer than you think, and the reason is that the clock usually starts when the problem surfaces, not when the work was done.

Retention periods for business records vary by country, sector and regulator, and there are competing pressures where personal data is involved, since keeping everything forever conflicts with data minimisation duties in several regimes. That tension is real and it is a question for your legal advisers, not a default to pick from a blog. What you can do without advice is make sure the retention decision is deliberate rather than an accident of which system happened to keep logs.

The year three test

Before you settle a design, run it against one scenario. Pick a decision your team made this month that involved an agent. Now imagine being asked about it in two years by someone who is unhappy, with everyone who touched it gone.

Walk through what you would produce. If the honest answer involves reading old messages or asking someone to remember, the record is not finished. Approvals also feed the weekly report on agent activity, which is where the gaps show up early.

Where this sits in practice

SicherOne keeps project management, HR and agent activity on one set of records, and a human approves agent output before it ships, so the approval and the thing approved are already in the same place rather than in a tool and a mailbox. What the system cannot decide for you is how long to hold it and what your regulator expects. Decide that once, write it down, and let the record do the remembering.