Eleven months later, somebody asks you to show why

One approval. One week. And somebody who reads it eleven months later. An outside contractor needs the real customer database to finish a job. The practice data cannot check the work. Monday, somebody writes down why.

Somebody else agrees, and sets it to run out on Friday. The request system records all of that, properly. Then somebody from outside walks in and asks you to show it.

Four people. An analyst who needs access the rules do not allow. An approver who can grant an exception. A reviewer who checks it afterwards. And somebody from outside, who was there for none of it. Exceptions get granted because no rule fits every job.

Granting one is not the problem. Accounting for it later is.

The request system still holds who asked, who agreed, what they agreed to and when it ran out, eleven months later. That part works. So ask the harder question. Not who approved it, but what they approved it on, and what happened afterwards. The reason the approver said yes is a line in a chat channel that has since been archived. The job ticket is closed, and its last comment says approved, see email.

And the spreadsheet the quarterly review reads has a date range somebody widened at some point, from Friday to month end. Nothing went red, and the copy cannot tell you whether that person had a good reason. So the outsider arrives with four questions. Who did you record. When. On what.

And has it changed since.

Run the same week again, with one change. The team keeps the request system it already uses, which still routes, grants and reviews. One thing is added. When the approver grants the exception, the company's own software also writes it into a shared notebook, as a decision. Picture an approval that walks around with its papers stapled to it. The software writes what was decided, the reason, and the three things read on the way to it.

The analyst's write up, the job ticket, last quarter's review note. Linking those three can fail quietly, so the software reads the entry back and checks they are there. Nothing files itself.

Think of a ledger where, before you write today's page, you press yesterday's page into wax and stick that wax at the top of today's. Change yesterday afterwards, and the wax no longer matches. And it is not one page. Tomorrow's wax came from today's, so the mismatch runs to the end of the book. Be exact about what is under the wax. What the page said, when it was opened, which number it is, and which papers it points at.

Not the papers themselves. Those are separate records, and they are not pages of this book.

Thursday. The reviewer reads the ticket properly. The work only touches two tables, and the exception was written for the whole database. So the approver narrows it to those two. Notice the direction. The control got tighter.

That is good work, not a cover up. Nobody rubs anything out. The narrower approval is its own entry, with its own reason and papers, and it replaces Monday's. Monday's is still there, marked as replaced, with the reason and the date. Here is the quiet part, for a manager. Ask how a late tightening looks in your own reviews, when its only trace is a changed cell in a spreadsheet.

Here it has somewhere to go, with the reason beside it. Nothing checks that the reason is a useful one, so a person still has to write a good one.

Eleven months later. The same four questions. Who did you record. Ask the notebook why this access exists, and it names no approver. It witnessed nobody, and any name in it is one a person typed into the words. The name of record is in the request system.

When. The printout carries the date, where the decision stands, and the approval it replaced. On what. Underneath, the reason, then each piece of evidence, with a short preview and a date. The stapled papers, read back. That printout says nothing about the wax, so the fourth question is a separate one.

Has it changed since. The check is run again, oldest page first, worked out from what is written down right now rather than read off a box that says fine. Three answers. The stored pages agree with their seals, which is all it says. Or it stopped, at an exact page, with the reason. Or there was nothing to check, which is a real answer and different from fine.

Two limits. Pages written before any of this existed carry no wax, and are counted and reported as outside. And somebody with direct access to the database underneath could rewrite the whole book and redo every seal to agree, and that would pass. What the seals force is that a change to one surviving page be rewritten consistently, all the way forward. None of that came from anyone's memory, and it does not depend on who is still around.

Look at what did not happen. Nothing was watching. Nobody got notified. The notebook approved nothing and routed nothing. It does not tell you whether the decision was a good one. That is what SmartMemory is.

A shared notebook your own software writes its decisions into. Eleven months later, this week's record was still there to read, with its reasons, its references, and the previews that came back when they were read. If you want to see how the wax works, and what those answers really look like, that is Part 2. You do not have to be believed. You have to be checkable.