Reversible by when?

The question has a missing word

Is this action reversible? is not a question about software. Answered as one, it gives the wrong answer roughly half the time. The question that decides is this:

Reversible before who acts on it?

Two clocks start the moment an action runs, and only their order matters.

The reversal window is how long it takes before the action can actually be put back. That is the time until somebody notices it was wrong, plus the time to undo it. Notice which part is larger. Undoing takes seconds or minutes. Noticing takes hours or days, and it is a property of your habits, not of the system.

The consumption latency is how long until the first person or system outside the action does something that depends on it. They read the field and book against it, or print it, or send it, or cut to it, or simply believe it.

reversible in practice   when   reversal window  <  consumption latency

If the window is longer, the action is irreversible, whatever the undo button says. By the time you undo it, the thing you needed to prevent has already happened. Quality engineering has had the general form of this for decades, and it is worth borrowing: a fault's detection rating is not about whether it could be found, but about whether it is found before it reaches the next stage.

The two clocks, measured

Ashour measured both for all nine action types. Detection came from the replay: how long, historically, between a wrong value being written and somebody querying it. Consumption came from reading what actually reads each field. That turned out to be the hard part, and it gets a section of its own below.

Now rank the list twice.

By the software's own measure of reversibility, which is how long the undo takes, moving a plan date is the most reversible action on the desk. Three seconds, one field, no counterparty, no money. It is the row a merchandiser would hand over first and feel good about.

By the test that decides, it is the worst row on the list, with a margin of minus 100.40 hours. Nobody looks at a date that moved by itself, so it sits wrong for four days. The portal mirrors it outward in 36 minutes.

And the row people were most nervous about, booking container space with a forwarder, involves a third party and money. Its margin is plus 93.70 hours. It gets noticed within an afternoon, because someone is watching the booking, and nothing downstream of it happens until the cut-off four days away.

The two rankings are close to inverted, and the software's ranking is the one people use.

Two complaints, nine days apart, one cause

In the week of 8 July the desk took two complaints.

Bexholt's merchandiser rang on the Tuesday. The ship date on her portal had moved twice in five days and nobody had sent her a word about either move. On the Thursday of the following week the cutting room stopped work, because Tuesday's loading sequence carried a style whose fabric was not in the building.

They were investigated separately, by two people, for nine days, as a communications problem and a planning problem. They are the same event.

The agent had moved a plan date, correctly by its own rules, on an internal field. That field is mirrored to the buyer portal by an integration that runs every hour. It is also read by the nightly job that builds the next day's loading sequence. Neither of those integrations was on the action inventory. Neither is something the agent does. Both were built years before anybody had heard of an agent, and both were doing exactly what they were built to do.

Every decision in that chain was correct. The outcome was a buyer who thought she was being ignored, and a line that stopped.

An internal field with a subscriber is an outbound action wearing an internal name. Classify an action by its furthest consequence, not by the table it writes to.

This is why the action inventory in lesson 1 is necessary but not sufficient. The inventory lists what the agent does. The consequence map lists what happens next, and the second list is longer, older and owned by nobody.

The subscriber census

The repair is dull and takes an afternoon. For every field the agent is permitted to write, find everything that reads it.

Serdana's agent could write 9 fields. The census took 14.5 hours across two people and found 14 subscribers.

• 3 of the fourteen had no owner anybody could name. All three had been built by people who no longer worked there.
• 2 of the fourteen sent something outside the company: the portal mirror, and a weekly space request to Nordreth Freight built from the plan dates.
• 2 of the nine fields were reclassified on the spot from internal to outbound, which moved them across the boundary before a single number was computed.

I am about to let an automated system write to a field in our order records. I need to know how quickly anything else acts on that field, because that interval decides whether a mistake can be caught in time.

Below I will paste what I know: the field, the screens it appears on, the reports it feeds, the exports and integrations I am aware of, and who looks at it in a normal week.

Build me a census table with one row per reader. For each one give: who or what reads it, how often they read it, whether that reader is inside or outside my company, and what they are entitled to do on the strength of it. Sort the table by how soon the first reader acts, soonest first.

Then list the questions I should go and ask to find readers I have not listed. In particular, anything that runs on a schedule, anything that mirrors data to a customer or a supplier, and anything built by somebody who has left. Tell me plainly that this census cannot be completed from my description alone.

Here is what I know:

You can buy detection. You cannot buy back the consumption.

Half the reversal window is detection, and detection is cheap to improve. Serdana added a daily digest: every field the agent wrote yesterday, listed to the person who owns that field, read in about six minutes. Two readers, twenty-one working days, at the desk's own loaded rate, comes to USD 48.30 a month.

On the plan-date row, detection fell from 101.00 hours to 9.40. A tenfold improvement for fifty dollars a month.

It does not move the row. The window is still 9.40 hours against a consumption latency of 0.60, a margin of minus 8.80. The portal mirror runs every hour, and there is no version of noticing that beats it.

That is the honest shape of this test, and it is worth saying plainly: detection is yours to improve and consumption is not. Consumption is set by what other people and other systems are entitled to do with your record. Shortening it means changing them, not you. Where you cannot, the action belongs to a human, and it belongs there permanently, not until the technology improves.

One row did move. Releasing an order from credit hold went from a window of 31.08 hours to 6.58, against a consumption latency of 8.00. That makes it reversible in practice for the first time. It still fails, for an entirely different reason, and lesson 4 shows why.

What you own at the end of this lesson

Two clocks per action instead of one yes-or-no. A census of who reads every field your agent may write. The rule that an action is classified by its furthest consequence. And the knowledge that detection is the half you can buy and consumption is the half you cannot.

Next: the four terms, the nine rows, and the row that passes on its measured error rate and fails on the honest one.