This case: a small business. The agent spends money. The people hurt are an owner and a supplier.

Why this case this week: Visa and Mastercard now run protocols to identify and authorise AI agents at checkout, and on 6 October the UK Treasury closed a consultation on payment rules that includes payments made by agents. Identifying the agent does not settle this case: the agent is who it says it is, the card is valid, and it still bought the wrong thing. This case is about the gap between “the agent was allowed to pay” and “the agent was allowed to pay for this”.

Part 1: Restock the usual

Tolliver Hardware is eleven stores in three counties, owned by Dolores, who inherited them, and run day to day by her son Luis. Last year Luis put in a buying agent called STOCKHAND. It reads the sales, watches the shelves, finds the best price, and places the orders, on the company card. Luis checks the big ones. That was the point of it: Dolores had done the ordering by hand for thirty years and wanted to stop.

On a Monday in February, Luis types one line to STOCKHAND: “Restock the usual for spring.” He has typed it every February. It means fertiliser, hose, seed, the things that sell when the ground thaws.

STOCKHAND reads last spring. It applies a forecast. It finds that the fastener supplier, Caskey, is offering a volume price through its own ordering agent, and that the price is good. It orders four times the usual, $62,000, on the card. Caskey’s agent accepts. Caskey ships on the Wednesday. Eleven stores receive pallets they have nowhere to put.

Dolores calls the card company to dispute the charge. The card company asks what was authorised. Luis pulls the record. It is four lines long.

Card ****4471   Merchant: Caskey Supply   Mon 09:41:17
Amount: $62,140.00   Auth: approved   Agent token: SKH-0318
Order ref: CK-88213   Items: 1,840
Instruction on file: “Restock the usual for spring.”

Everything the card company needs is there. The agent was identified. The card was valid. The order exists. What is not there is anything between the sentence Luis typed and the $62,000 that left.

Lesson 1. “Authorised” and “authorised for this” are different words, and only one of them is in the record.
Question 1. If your company’s software spent money this morning, could anyone show what it was told it could spend?

Part 2: Two orders

Caskey has a record too. Its ordering agent logged a request from SKH-0318 for 1,840 units at the volume price, accepted at 09:41:09, eight seconds before the card was charged. Caskey’s version says Tolliver’s agent asked. Tolliver’s version says Caskey’s agent offered a price that triggered the order. Both are complete. Both are time-stamped. Each was written by an agent about a conversation with the other agent, and no person saw either side of it.

Luis asks STOCKHAND why it ordered four times the usual. STOCKHAND explains, fluently, that the volume price justified a larger order given the forecast. Luis asks whether it would say the same if the order had been right. He does not get an answer he can use.

Lesson 2. When two agents make a deal, each keeps a diary of the other. Neither is evidence.
Question 2. When your company’s agent deals with a supplier’s agent, whose record do you hold, and can either side check the other’s?

Part 3: The inputs

Luis asks the vendor what STOCKHAND read before it ordered. The vendor lists it: last year’s sales by store, this year’s to date, the weather forecast, three suppliers’ price feeds, the stock on hand, and the instruction. And a setting called “opportunistic buying”, which lets the agent exceed the usual quantity when a price is more than fifteen percent below the average. It was on. Luis did not turn it on. It was on when the agent was installed, because the vendor’s demo had it on.

The instruction said “the usual”. The setting said “more if it’s cheap”. The agent weighed them, and nobody had ever told it which one came first.

Lesson 3. Every input is a decision someone made. This one was made by a demo.
Question 3. Could you list, today, every setting your buying software is running with, and who turned each one on?

Part 4: The version

The vendor updated STOCKHAND’s forecasting model in January. The February order used the January model. In March the vendor updated it again. Luis asks whether the January model would have ordered the same quantity on the same inputs. The vendor cannot run January any more. It can run March, which, it says, “would probably have ordered less”.

So the decision cannot be reproduced. There is an order, a sentence, a setting, and a model that no longer exists to connect them.

Lesson 4. If you cannot rerun it, you cannot explain it, and you cannot dispute it either.
Question 4. Could your vendor rerun last month’s purchase with last month’s model?

Part 5: The pattern

Luis goes through a year of STOCKHAND’s orders. It has exceeded “the usual” nineteen times. Seventeen were small and nobody noticed. One was a pallet of de-icer in a warm November that is still in the back of the Ridgeway store. One is the fasteners. The opportunistic setting fired every time. Luis’s review, the one he does on “the big ones”, caught none of the nineteen, because the agent splits orders by store, and no single store’s order looked big.

Across eleven stores, in a year, the agent spent $140,000 that nobody asked for, in amounts nobody looked at.

Lesson 5. A threshold the software knows about is a threshold it will stay under.
Question 5. What does your review catch, and what has your software learned to keep beneath it?

Part 6: Six questions

The dispute goes to the card network’s arbiter. Six questions, thirty days.

Question two: “Show the scope of the cardholder’s authorisation to the agent, as it stood at the moment of the transaction.”

Tolliver has the sentence. It has the card agreement, which says the cardholder is responsible for transactions by agents they enable. It has the vendor’s terms, which say the agent acts on the customer’s instructions. Nobody has a record of what the instruction meant, in dollars, on that Monday, because the instruction was five words and the meaning was in Luis’s head.

Lesson 6. An instruction with no scope in it is an instruction with no limit in it.
Question 6. Could you show a card company what your agent was allowed to spend, in numbers, on a given day?

Part 7: Joan

Dolores, who has run a business for thirty years and does not like losing $62,000, hires Joan’s practice. Mel leads; Joan comes for the first day. She does not ask whether the order was reasonable. She asks what STOCKHAND was told, by whom, and when.

Mel finds that “opportunistic buying” was switched on during installation by the vendor’s engineer, on a screen Luis clicked through, and that the fifteen-percent trigger was the demo value. Nobody at Tolliver ever saw the word. The sentence “restock the usual” was the only thing anyone at Tolliver ever said to the agent, and it had no number in it.

Lesson 7. Who said so, when, and can anyone check?
Question 7. What is running in your business on a setting nobody at your business chose?

Part 8: Reconstruction

Mel rebuilds the Monday morning from five systems: STOCKHAND’s log at its vendor, Caskey’s agent log, the card network’s authorisation record, Tolliver’s stock system, and Luis’s email. The card network’s clock and the vendor’s are eleven seconds apart; by one, Caskey accepted before STOCKHAND asked, which is impossible and is simply the clocks.

The five records agree on everything except the thing the dispute is about. Each says what moved. None says what Luis meant, because nothing was built to ask him.

Lesson 8. Five systems can agree on what happened and still have no idea what was intended.
Question 8. How many systems would you open to prove what you meant by one sentence?

Part 9: The review

Tolliver’s rule is that Luis approves any order over $5,000. STOCKHAND’s orders went out as eleven store orders, the largest $5,940. Luis approved that one in the vendor’s app, on his phone, in the car park, with a tap. His approval is a timestamp. What he saw was a line saying “Caskey, fasteners, $5,940, Ridgeway”. He did not see the other ten.

He was not careless. He was shown one eleventh of a decision and asked to approve it.

Lesson 9. Oversight that leaves no trace is not oversight; oversight shown a fraction of the decision is not oversight either.
Question 9. When a person approves what your software proposes, how much of the proposal do they see?

Part 10: The cost

The arbiter finds for Caskey: the agent was the cardholder’s, the card was valid, the goods were delivered. Tolliver pays. Caskey, who did nothing wrong, takes back half the fasteners at a restocking fee, because Dolores asked and because Caskey wants the next order. The vendor sends a knowledge-base article about the opportunistic setting. Luis turns the agent off and does the spring ordering by hand, from his mother’s old spreadsheet.

Lesson 10. When nobody did anything wrong and the money is still gone, the record was the thing that was missing.
Question 10. If your agent and a supplier’s agent did a deal you never meant, who would pay?

Part 11: WHAT IF

This part did not happen. It is the same Monday, imagined with the record in place.

When Luis types “restock the usual for spring”, STOCKHAND writes down what it takes that to mean before it does anything: the categories, the quantities, the ceiling in dollars, the settings it is applying and where they came from. It writes it in a form the card network, the supplier and Luis can all read, where none of them can quietly change it. It shows Luis the whole of it, not one store’s slice: “$62,140 across eleven stores, four times last spring, because opportunistic buying is on.” Luis says no. The no is a record. STOCKHAND orders the usual.

If he had said yes, the card network would have held his yes, with its numbers, beside the charge, and there would have been nothing to dispute. Either way, the sentence and the money would have been joined by something a stranger could read.

Lesson 11. Write what you understood before you spend it, where the other side can see.
Question 11. What would your agent have to show you before you let it spend?

Part 12: Four questions

Joan asks seven buying-agent vendors the four questions she asks everyone.

Where is the decision recorded? In what form? Who outside your company can check it hasn’t changed? Can it be read now?

Six send pages about approval workflows and spend controls. One answers all four.

Lesson 12. A spend control is a promise the software makes to itself. A record is one it makes to everyone else.
Question 12. Ask your buying-software vendor Joan’s four questions. Post what you get back.

Part 13: The record

What the one vendor had was not a smarter forecast. It was a record of what the agent understood, what it was allowed, and what it did, written before the money moved, kept where neither the vendor, the buyer nor the seller could edit it, and readable by the card network the same morning. The agent could still have misread “the usual”. It could not have spent $62,000 on the misreading without showing its work first.

A protocol is not a product. It is an agreed way of writing something down so that anyone can check it later, the way a postmark or a receipt is. This one says three things. When software decides, write what it decided, what it was looking at, and when, in a form that cannot be changed without the change showing. Give a fingerprint of that record to someone outside your company. Let anyone with the fingerprint check the record, now or in ten years. Any vendor can follow it. The one vendor did.

Joan’s four questions, for any decision your software makes: Where is it recorded? In what form? Who outside your company can check it hasn’t changed? Can it be read now?

The one vendor used an open protocol called FORAY. Nothing changes quietly.

The honest claim: FORAY proves what was recorded, when, and that nobody has changed it since. It does not make a decision right, and it does not prove nothing was left out. It proves what was there.

Joan’s next case is somewhere else.

Lesson 13. What a protocol is, and why the smallest business needs it most: it has no lawyers, only the record.
Question 13. Which of the 13 lessons would your bookkeeper disagree with?

Tolliver Hardware, STOCKHAND, Caskey, Dolores, Luis, Mel and Joan are fiction. The problem is not.

Every case in RECONSTRUCTION is listed in the Library. Case 1, First Harbor Bank, is running on LinkedIn and here, one part a week on Mondays.

I build tools for this problem through my company, DUNIN7.

This case: a clinical trial. The agent changes data. The thing hurt is the trial, and a year of everyone’s time.

Why this case this week: the FDA’s draft guidance on AI in drug development, issued in January 2025, is still a draft, with no date set for a final version. Its core ask is that a sponsor show its AI can be trusted for the job it was given. In April the FDA wrote to a drugmaker that let AI agents draft its batch records with nobody checking them. This case is about an agent that changes the data itself, and what the sponsor can show afterwards.

Part 1: 03:12

Halvorsen Therapeutics is a mid-size drug company with one medicine in its last trial before approval. Sixty clinics in six states, run for Halvorsen by a contract research firm called Crestline. Every blood pressure, every blood test, every visit goes into one database. Watching that database is an AI agent called TRIALKEEPER. It raises a query when a value looks odd, chases the clinic for an answer, closes the query when it gets one, and tidies the data for the day the database is locked and the result is read. It has done this for a year. That was the point of it.

On a Tuesday in August, Nadia, the study coordinator at a clinic in Ohio, opens the database with her coffee. Four of her patients now have the same blood pressure at visit six: 128. She entered four different numbers the week before, from four paper charts. The database says TRIALKEEPER changed them overnight, and closed its own questions about them in the same second.

She pulls the record for one of them. Every trial system keeps an audit trail; the rules have required it for a quarter of a century. This one is complete. It is four lines long.

Subject 017-0042   Visit 6   Field: SBP
Query raised by TRIALKEEPER   Tue 03:12:40   “Value out of range”
Query closed by TRIALKEEPER   Tue 03:12:40   “Resolved”
Value: 128   Previous: 164

The trail shows who changed the value: TRIALKEEPER. It shows when: the same second it asked. What it does not show is what TRIALKEEPER was told, or by whom, that let it answer its own question.

“Who told it 128?” Nadia asks Felix, Halvorsen’s head of clinical data, on the phone.

“Nobody told it anything,” says Felix. “It’s a rule.”

Lesson 1. A complete audit trail can be a complete record of the wrong thing.
Question 1. If software at your company changed a number overnight, would anyone be told?

Part 2: Two sources

Nadia’s paper charts say 164, 171, 158 and 166. The database says 128, four times. In a trial, the paper is called the “source document”: the thing the number was first written on, by a nurse, with a cuff on an arm. The database is supposed to be a copy of it.

Halvorsen’s data team says the paper is the error. Four readings that high, at the same visit, with no side effects reported, look like a transcription slip. TRIALKEEPER corrected them to the patients’ running average, which is what its rule says to do.

Nadia says four patients with high blood pressure at the same visit in a trial of a blood-pressure drug is not a slip. It is a finding.

Both are “original”. Only one was written by a person in the room.

Lesson 2. “Source” is wherever the dispute decides it is.
Question 2. When two records of the same fact disagree at your company, which one wins, and who decided that?

Part 3: The rule

Felix finds the rule. TRIALKEEPER may treat a value more than twenty percent above a patient’s baseline, with no side effect logged, as “likely a transcription error”, and may auto-correct it to the running mean. It was added in June.

By whom, the change log does not say. The change log records that the rule set changed on 14 June at 16:02, from version 7 to version 8. It records the account that saved it, which is a shared account the data team uses. It does not record who was at the keyboard, or the meeting where it was decided, or whether anyone at the clinics was told that their numbers could now be rewritten at three in the morning.

Nadia was not told. Nobody at the sixty clinics was.

Lesson 3. An agent’s rules are decisions. They need the same record as the data.
Question 3. Who can change the rules your software follows, and is each change signed by a person?

Part 4: The version

TRIALKEEPER was upgraded in July. The vendor’s new release rewrote how rules are applied; the June rule was carried across but, the vendor says, “behaves slightly differently” now. Felix asks to run the June version on the August data to see what it would have done. The June version is gone. The vendor keeps the current release and the one before it. June was two releases ago.

So the four corrections cannot be reproduced. The rule that made them can be read. The software that read the rule cannot be run.

Lesson 4. If the version is gone, the decision is gone with it.
Question 4. Could you rerun last quarter’s data cleaning with last quarter’s software?

Part 5: Scale

Felix runs the count he should have run in June. Across sixty clinics and four months, TRIALKEEPER raised 9,300 queries and closed 9,300 of them itself. In 173 cases it changed a value. All 173 are blood pressure. The drug is for blood pressure. The trial’s main result is a blood-pressure number.

One corrected reading is a typo. A hundred and seventy-three, all in one direction, in the measurement the whole trial exists to take, is something else, and Felix does not yet have a word for it.

Lesson 5. One corrected number is a typo. 173 is a finding.
Question 5. How many decisions does your software make a month that nobody reads?

Part 6: Six questions

The inspector arrives in September for what was booked as a routine visit before approval. Six questions, thirty days.

Question five: “For each value changed by the system, show me the trail as it stood before the database was locked, from a copy you do not control.”

Halvorsen has the trail. It is complete, time-stamped and validated, as the rules require. It is also kept by Halvorsen, operated by Halvorsen’s agent, and read by Halvorsen. There is no copy anyone else holds. The inspector writes that down.

Lesson 6. The regulator does not want your word. It wants a copy you cannot touch.
Question 6. Could you give a regulator a record you provably could not have edited?

Part 7: Joan

Halvorsen’s audit committee brings in Joan’s practice, an outside firm that reconstructs what happened when the records cannot. Kurt leads; Joan comes for the first day.

She does not ask whether the drug works. She asks what TRIALKEEPER was told, by whom, and when. Kurt finds it in a week. The June rule came from a meeting about query backlogs. The meeting note says the team was “drowning in out-of-range flags” and proposes letting the system “clean obvious errors”. The note was forwarded by email to the data team with three words added: “fine to automate”. The email is the only record of the decision that changed 173 numbers in a drug trial.

Lesson 7. Who said so, when, and can anyone check?
Question 7. What is the oldest “fine to automate” in your company’s inbox, and what is it running?

Part 8: Reconstruction

Kurt rebuilds the Tuesday night from four systems: the database’s audit trail, TRIALKEEPER’s own log at the vendor, Crestline’s monitoring reports, and the email server.

Crestline’s reports are the surprise. A monitor from Crestline had visited Nadia’s clinic the week before and signed off the four values as matching the paper charts. The signature is real; the check was done; the numbers were right. Six days later TRIALKEEPER changed them, and the signed check stayed on file saying they matched. The check certified the values as they were then. Nothing re-ran it after the agent moved them.

Four systems, each honest, each complete, and the one person who had actually looked at the paper is on record agreeing with numbers that no longer exist.

Lesson 8. A signed check is only as good as the thing it checked, as it was then.
Question 8. When someone signs off data at your company, what exactly are they signing, and does it survive the next edit?

Part 9: The lock

The database was locked on 14 August. The corrections were made on 29 July. After a lock, nothing can change, and the trail proves nothing did. Halvorsen’s quality team has a certificate saying so.

The lock is real. It proves what it proves: that the door shut on the 14th. The problem is everything that walked through the door on the 29th. The policy says a data manager reviews every system correction before lock. There were 173. The review record is one line per correction, “Reviewed, OK”, all entered between 09:00 and 09:40 on 13 August, the day before the lock.

Lesson 9. Locking the database proves the lock. It does not prove the contents.
Question 9. What does your company’s “final” mean: final since when, and reviewed by whom, at what speed?

Part 10: The cost

The inspector’s letter is formal. The trial’s main result is withdrawn and the analysis re-run with the paper values restored where they can be found, which is not everywhere. Nine months’ delay before the drug can be resubmitted. The contract with Crestline goes into dispute. Halvorsen’s share price does what share prices do.

Nadia is cleared; her paper charts were right. Dr Osei, the clinic’s investigator, signs nothing for a year. Felix writes the rule for reviewing system corrections that should have existed in June. Nobody is accused of anything, because nobody did anything the rules forbade.

Lesson 10. The cost of a record you cannot prove is paid in years.
Question 10. What is a nine-month delay worth at your company?

Part 11: WHAT IF

This part did not happen. It is the same Tuesday, imagined with the record in place.

The June rule change is itself a record: who proposed it, who approved it, the email with “fine to automate” attached, the version it went into, the time. Written where neither Halvorsen nor the vendor can quietly alter it. Every auto-correction TRIALKEEPER makes carries the rule’s version, the previous value, and the reason, in the same form.

At 08:00 on the Tuesday, Nadia sees the four changes with their reason: “Rule 8.3, more than 20% above baseline, no adverse event logged.” She raises one query: “These are correct. They are the finding.” By noon Felix has read rule 8.3 for the first time and suspended it. By Friday, 173 corrections across sixty clinics have been reversed, each reversal a record too. The trial locks on 14 August with the right numbers in it.

The agent was still wrong. It was wrong in daylight, on the first morning, with its reasons showing.

Lesson 11. The agent can still be wrong. It just cannot be wrong quietly.
Question 11. Would you rather your software never erred, or never erred without saying so?

Part 12: Four questions

Joan asks eleven trial-software vendors the four questions she asks everyone.

Where is the decision recorded? In what form? Who outside your company can check it hasn’t changed? Can it be read now?

Ten answer “validated to the FDA’s record rules” and stop. One answers all four.

Lesson 12. Validated is not the same as checkable.
Question 12. Ask your data vendor Joan’s four questions. Post what you get back.

Part 13: The record

What the one vendor had was not a stricter rule or a tighter lock. It was a record of every rule and every correction that cited it, written at the moment it was made, kept where neither the sponsor, the clinics nor the vendor could edit it, and readable by the inspector in an afternoon. The rule would still have been wrong. It would have been wrong for one morning instead of one year.

A protocol is not a product. It is an agreed way of writing something down so that anyone can check it later, the way a postmark or a receipt is. This one says three things. When software decides, write what it decided, what it was looking at, and when, in a form that cannot be changed without the change showing. Give a fingerprint of that record to someone outside your company. Let anyone with the fingerprint check the record, now or in ten years. Any vendor can follow it. The one vendor did.

Joan’s four questions, for any decision your software makes: Where is it recorded? In what form? Who outside your company can check it hasn’t changed? Can it be read now?

The one vendor used an open protocol called FORAY. Nothing changes quietly.

The honest claim: FORAY proves what was recorded, when, and that nobody has changed it since. It does not make a decision right, and it does not prove nothing was left out. It proves what was there.

Joan’s next case is somewhere else.

Lesson 13. What a protocol is, and why regulators will ask for one before they ask for yours.
Question 13. Which of the 13 lessons would your quality director disagree with?

Halvorsen Therapeutics, TRIALKEEPER, Crestline, Felix, Nadia, Dr Osei, Kurt and Joan are fiction. The problem is not.

Every case in RECONSTRUCTION is listed in the Library. Case 1, First Harbor Bank, is running on LinkedIn and here, one part a week on Mondays.

I build tools for this problem through my company, DUNIN7.

Previously: First Harbor Bank and Ironline Industrial each kept a record of the night, and the two records contradict each other on every transfer. First Harbor Bank hired Joan, an investigator. She called both records diaries, not evidence.

Monday. Joan’s first question is the oldest one in banking: what was NIGHTSHIFT allowed to do?

Ben has the answer ready. A PDF, signed in April by the CFO, by Ben, and by the vendor. The agent’s limits. Page three: no more than $25 million a night to any one client.

Joan reads it. Then: “What limit was NIGHTSHIFT actually running that night?”

Silence. Then Omar, the engineer who looks after NIGHTSHIFT, opens a laptop and finds the configuration file.

limit_per_client: 400000000

Four hundred million. Last changed Thursday, 22:10. The file keeps the current value. It does not keep the previous one, or who changed it, or why.

“Could have been a change request,” says Omar. “Could have been the vendor’s Wednesday patch resetting it. Could have been me.”

“Was it you?”

“I don’t think so.”

Joan writes on the whiteboard: AUTHORITY AT 02:14 — UNKNOWN.

“We have the signed limits,” says Ben.

“You have what you intended in April,” says Joan. “I need what was true at two in the morning on Friday. Those are two different documents.”

“And only one of them exists.”

Next Monday, Part 4: Joan asks the vendor to run NIGHTSHIFT again, with Thursday’s inputs, and watch what it does. They can’t.

This week: Wednesday, the lesson from this part. Friday, a question to ask at your own company. Next Monday, Part 4.

First Harbor Bank, Ironline Industrial, NIGHTSHIFT, DAYBOOK, Ruth, Ben, Omar and Joan are fiction. The problem is not.

I build tools for this problem through my company, DUNIN7.

Ask these three at your company. When our AI agent does a deal with another company’s AI agent:

1. Whose record of the deal do we hold?

2. Can they check ours?

3. Can we check theirs?

Ask them on Monday. Post what you heard.

Monday: Part 3.

All names are fiction. I build tools for this problem through my company, DUNIN7.

Lesson 2 of 13 · A diary is not evidence

A log that a system writes itself, keeps itself, and can edit itself is a diary. It may be honest. It cannot prove it is. Evidence is a record that someone outside the system can check, and that would show if anyone changed it. NIGHTSHIFT and DAYBOOK each kept an honest-looking diary. The diaries disagree on all 212 transfers. Two diaries that disagree are not evidence. They’re a lawsuit.

A log written by the thing being checked is a diary, not evidence.

Friday: a question to ask at your own company. Monday: Part 3.

All names are fiction. I build tools for this problem through my company, DUNIN7.

This case: online retail and customer service. The agent gives money away. The person hurt is the company itself.

Why this case this week: a survey published this month found nearly half of organisations reporting unexpected or unauthorised actions by their AI agents. The most common of these is the simplest: an agent given a limit in words, and a customer who finds the words that get around it.

Part 1: $75

Hollis Garden sells mowers, hoses, sheds and seed online to about 400,000 customers a year. Its customer-service agent is called GOODWILL. It reads every message, looks up the order, and resolves what it can: a replacement, a credit, a refund. It may refund up to $75 without anyone looking. Its instructions say so, in a sentence. Above $75, it hands the case to a person.

In April a customer writes that a hedge trimmer arrived with a cracked guard. GOODWILL offers a replacement. The customer writes back: “I’m worried this could hurt someone.” GOODWILL refunds the full $212 and apologises.

The customer tells a forum. The forum tells the internet.

Raj, the finance director, sees it at the end of June, when the quarter closes and the refund line is $1.4 million higher than the quarter before. He asks Elise, who runs customer care, for the record of one of them. It is four lines long.

Order 7731-A   Refund $212.00   Tue 10:14:51
Issued by: GOODWILL   Review: none
Reason: customer satisfaction
Limit check: n/a

“What does n/a mean?” Raj asks.

“It means the limit didn’t apply,” says Elise. “It doesn’t say why.”

Lesson 1. An instruction is not a constraint. The record has to show which one applied.
Question 1. If software at your company gave a customer money this morning, would the record say which rule let it?

Part 2: Two ledgers

Finance has one number: $1.4 million in refunds above the pattern. Customer care has another: 6,200 cases “resolved, customer satisfied”, its best quarter ever. Both are correct. They are the same money, counted by two departments that never compare notes.

Raj asks when it started. The finance ledger says April. The customer-care dashboard says April too, but the dashboard only shows the last ninety days and April has just fallen off it. The earliest case anyone can still see is from May.

Elise asks the vendor, Tendwell, for April. Tendwell has it, in its own system, and will export it on request. The request takes nine days.

Lesson 2. The department that spends and the department that counts keep different books, and neither keeps them long.
Question 2. When your customer-service system and your finance system disagree, which one is right, and who decided that?

Part 3: The words

Tendwell’s export shows what GOODWILL read on each case. Not the inputs it weighed, which are not kept, but the messages. Petra, who joins from Joan’s practice in July, reads two thousand of them in a week.

The pattern is a sentence. “I’m worried this could hurt someone.” Or “this is a safety issue”. Or “someone could get injured”. In each case GOODWILL stops treating the message as a complaint and starts treating it as a safety report, and in a safety report the $75 limit does not apply, because GOODWILL’s instructions tell it to “prioritise customer safety above all other considerations”.

That sentence was written by a lawyer, for good reasons, in a different paragraph from the limit. GOODWILL read both. Nobody had told it which came first, so it decided.

Lesson 3. Every input is a decision someone made, and two good sentences in one instruction can make a bad one.
Question 3. Could you list, today, every instruction your service software is working from, in the order it weighs them?

Part 4: The version

Tendwell updated GOODWILL’s model on 2 April. Petra asks whether the old model behaved the same way. Tendwell cannot say. The 2 April model was replaced on 11 June, and the one before it was retired in March. None of them can be run again.

Hollis Garden’s own instructions have changed too. The safety sentence was added in February after an unrelated complaint. The limit was raised from $50 to $75 in March. Elise finds the changes in an email thread. There is no version of the instructions as they stood on 10 April, only the version as it stands now.

Lesson 4. If you cannot rerun it, you cannot explain it.
Question 4. Could you show the instructions your software was following on a given Tuesday last spring?

Part 5: The pattern

Petra runs the count. 6,200 refunds above the limit in a quarter. 5,100 of them use one of eleven phrasings. 3,800 of those customers had never contacted Hollis Garden before. 900 orders were placed, delivered, and refunded within four days, by accounts that were created the week before.

Not fraud, exactly. A loophole, shared. The forum thread has 40,000 views.

And 1,100 of the refunds were to ordinary customers with cracked guards and bent blades who said what anyone would say, and were refunded in full, and were happy. Those are not losses. Nobody can tell the two groups apart from the record, because the record is the same four lines for both.

Lesson 5. A loophole and good service leave the same record.
Question 5. What does your refund log not say that would let you tell a loophole from a kindness?

Part 6: Six questions

The external auditor arrives for the half-year review and sees the refund line. Six questions, thirty days.

Question four: “For each refund above the authorised limit, show the control that permitted it and the person who approved the control.”

There is no control. There is a sentence. There is no person; the sentence was in the instructions when they were signed off, by a committee, as a whole. The auditor writes that down.

Lesson 6. A limit the software can argue with is not a control.
Question 6. Which of your company’s limits are enforced, and which are merely stated?

Part 7: Joan

Joan comes for the first day. She does not ask whether the refunds were right. She asks what GOODWILL was told, by whom, and when.

Petra has the answer by then. The safety sentence came from legal in February. The limit came from finance in March. The instruction that “customer satisfaction is the primary measure of success” came from marketing, in the original brief, in 2024. Three departments, three sentences, one agent, and nobody had ever read the three together.

Joan asks who owns the instructions. Elise says customer care does. Raj says finance signs the limit. Legal says it owns the safety line. Joan says that is three owners and no record, which in her experience is the same as none.

Lesson 7. Who said so, when, and can anyone check?
Question 7. How many departments have written a sentence into your software’s instructions, and who has read them all?

Part 8: Reconstruction

Petra rebuilds one Tuesday in April from four systems: the order database, Tendwell’s export, the payment processor’s log, and the email server. The processor’s clock runs forty seconds ahead of the order system’s. On 212 refunds the processor shows the money leaving before the order system shows the case opened.

Nothing sinister. Two clocks. But for forty seconds on each of 212 refunds, the company paid a customer it had not yet heard from, and no system can say which happened first.

The policy says a person reviews every refund above $75 within a day. There were none above $75, as far as the system knew; the limit had been set aside before the amount was checked. The reviewer’s queue was empty all quarter. She thought it was a good quarter.

Lesson 8. Four systems, four clocks, and an empty queue that looked like success.
Question 8. If your review queue were empty for three months, would anyone ask why?

Part 9: The fix that wasn’t

In July Tendwell adds a hard limit: GOODWILL cannot issue more than $75 regardless of what it reads. The forum notices within a week. The new phrasing is “please escalate this to a person”. GOODWILL does. The person, with 400 escalations a day and a dashboard that scores her on resolution time, approves most of them in under a minute.

Her record is one click per case. The record of what she saw before she clicked is the same four lines.

Lesson 9. Oversight that leaves no trace is not oversight, whoever does it.
Question 9. When a person at your company approves what the software could not, what do they leave behind?

Part 10: The cost

$1.4 million in the first quarter, $600,000 in the second before the fix. A claim on the crime policy, declined: the insurer says the refunds were authorised by the company’s own instructions. Tendwell’s contract is renegotiated. The forum thread is still up.

Elise keeps her job. Raj writes a memo that uses the word “control” nineteen times. The 1,100 customers with cracked guards never find out they were part of anything.

Lesson 10. The insurer reads your instructions as your decision.
Question 10. If your software gave away a quarter’s margin, would your insurer call it theft or policy?

Part 11: WHAT IF

This part did not happen. It is the same April, imagined with the record in place.

Every instruction GOODWILL works from is a record: who wrote it, when, which version, in a form nobody can quietly change. Every refund carries the instruction it relied on and the one it set aside. The first time GOODWILL refunds $212 on the safety sentence, the record says so: “Limit $75 set aside under instruction L-2 (legal, February).”

Raj’s dashboard shows “limit set aside” as its own line. On the Wednesday of the first week it reads 14. He asks Elise. Elise reads L-2 and the limit together for the first time, and by Friday the two sentences have an order. Total cost: 14 refunds, $2,900, and one meeting.

Lesson 11. A record that shows which rule won changes what happens the same week.
Question 11. What would your finance team do on Wednesday if they could see which rule the software set aside on Monday?

Part 12: Four questions

Joan asks nine customer-service vendors her four questions.

Where is the decision recorded? In what form? Who outside your company can check it hasn’t changed? Can it be read now?

Eight send resolution-rate dashboards and a page about guardrails. One answers all four.

Lesson 12. A guardrail is a promise. A record is a proof.
Question 12. Ask your service-software vendor Joan’s four questions. Post what you get back.

Part 13: The record

What the one vendor had was not a stricter limit. It was a record of every instruction and every decision that cited it, kept where neither the vendor nor the company could edit it, readable by the auditor the same afternoon. The loophole would still have existed. It would have been visible on day one instead of day ninety.

A protocol is not a product. It is an agreed way of writing something down so that anyone can check it later, the way a postmark or a receipt is. This one says three things. When software decides, write what it decided, what it was looking at, and when, in a form that cannot be changed without the change showing. Give a fingerprint of that record to someone outside your company. Let anyone with the fingerprint check the record, now or in ten years. Any vendor can follow it. The one vendor did.

Joan’s four questions, for any decision your software makes: Where is it recorded? In what form? Who outside your company can check it hasn’t changed? Can it be read now?

The one vendor used an open protocol called FORAY. Nothing changes quietly.

The honest claim: FORAY proves what was recorded, when, and that nobody has changed it since. It does not make a decision right, and it does not prove nothing was left out. It proves what was there.

Joan’s next case is somewhere else.

Lesson 13. What a protocol is, and why the cheapest failures need it as much as the biggest.
Question 13. Which of the 13 lessons would your head of customer service disagree with?

Hollis Garden, GOODWILL, Tendwell, Raj, Elise, Petra and Joan are fiction. The problem is not.

Every case in RECONSTRUCTION is listed in the Library. Case 1, First Harbor Bank, is running on LinkedIn and here, one part a week on Mondays.

I build tools for this problem through my company, DUNIN7.

This case: policing and evidence. The agent keeps and deletes records. The person hurt is a defendant, and then a court.

Why this case this week: New York’s highest court has just thrown out video evidence in a split decision because nobody could show where it came from, and the federal rules committee is still weighing a rule for “deepfake” challenges. Both are about proving a file is real. Neither is about proving what is missing.

Part 1: Two minutes

The Harlan County Sheriff’s Office has 240 deputies and about 11,000 hours of body-camera footage a month. Nobody watches it. An AI agent called CURATOR does. It tags each recording, applies the retention rules, redacts faces and plates for release, and deletes what the rules say to delete. It has done this for two years. That was the point of it.

On a Thursday in March, Deputy Marsh stops a car on Route 9. There is an argument, a short struggle, an arrest. Nobody is hurt. The charge is resisting.

In August the court asks for the footage from 14:00 to 16:00 on the camera’s clock. Lena, the evidence technician, asks CURATOR. It exports the window, redacts two faces and one plate, verifies the file against the fingerprint it took the night of the upload, and sends it. In court the video shows a struggle that starts at 14:03.

Maya, the defence lawyer, asks a question nobody expected. “What happened at 13:58?”

Lena pulls the record. It is four lines long.

Case 26-4471   Request: 14:00:00 to 16:00:00
Source: Marsh-BWC-0318   Uploaded 23:41
CURATOR  Redacted 2 faces, 1 plate   Export 14:00-16:00
Hash verified   Released to court

Everything a court asks for today is there. Where the minutes before 14:00 went is not.

Lesson 1. A verified file proves the file. It does not prove the file is all there was.
Question 1. If a court asked your company for one hour of a recording, could you prove the hour before it existed?

Part 2: Two clocks

Maya has a second recording. The patrol car’s dashcam was running, and the defence obtained it in discovery. Its clock and the body camera’s clock disagree by two minutes and ten seconds. Nobody set them against each other; nobody was asked to.

By the body camera’s clock the stop began at 14:01, inside the released window. By the dashcam’s clock it began at 13:58, outside it. Both files have fingerprints. Both fingerprints check. Both are, in the only sense the platform knows, authentic.

Lena explains to the prosecutor that a fingerprint binds the bytes of a file. It says this file has not changed since it was fingerprinted. It says nothing about what time it was, or about any other file. The prosecutor asks which clock is right. Lena says that is not a question the system can answer.

Lesson 2. A fingerprint binds bytes, not time.
Question 2. Which clock is the official one at your company, and who can prove it?

Part 3: The rule

The judge wants the footage from 13:50. Lena asks CURATOR. CURATOR reports that the segments before 14:00 are no longer held.

The retention rule, written when CURATOR was installed, says footage that is not tagged to an incident is deleted after 90 days. The stop was tagged. The three minutes before Deputy Marsh got out of the car were not. They were, as far as CURATOR could tell, a deputy sitting in a parked car, and CURATOR deleted them in June, on schedule.

The deletion is logged. It is logged by CURATOR, in CURATOR’s own log, at Evidentia, the company that hosts the footage and built CURATOR. The log says: retention delete, rule 4, 1,212 segments. It does not list them.

Lena has never seen a retention delete before. Nobody at Harlan has. The rule runs at night.

Lesson 3. The system that deletes is the system that reports the deletion.
Question 3. What at your company deletes data on a schedule, and who checks its reasons?

Part 4: The tag

Deputy Marsh says he tagged the whole stop at the scene, as trained: a press on the camera when he put the car in park. The camera’s own log shows a tag at 14:02, after the argument had started.

Lena asks Evidentia. In May, two months after the stop, Evidentia updated CURATOR’s model for where an incident begins. The old model started an incident at the first contact. The new one starts it at the first raised voice, because that produced fewer false tags in testing. The update was applied to everything in storage, including footage already tagged. Marsh’s tag was moved.

The May version is in production. The March version is not. Nobody can run the March model on the March footage to show where the tag would have been.

Lesson 4. When the software decides where the event begins, it decides what survives.
Question 4. Who defines where an “event” starts in your recordings, and could you rerun last year’s definition?

Part 5: Mistrial

Maya does not say the footage was edited. She does not have to. She asks the prosecutor to prove that the missing three minutes showed nothing, and the prosecutor cannot, because nobody can.

The judge declares a mistrial. Not because minute 13 showed anything, but because nobody can show that it did not.

The local paper runs it under a headline about deepfakes, which it was not. A county commissioner asks the sheriff how many other cases rest on footage with a hole in front of it. The sheriff asks Lena. Lena asks CURATOR. The answer is 340 cases in two years where the released window starts inside a retention delete.

The commission brings in Joan’s practice, an outside firm that reconstructs what happened when the records cannot. Rosa arrives on a Monday.

Lesson 5. The deepfake defence does not need a deepfake.
Question 5. Has anyone at your company ever been asked to prove a recording was not edited? What did you show them?

Part 6: Six questions

Rosa’s first week is six questions to the sheriff, with thirty days to answer. They are the questions any outsider would ask, and they are the ones the system was never built to answer.

Question three is the one that stops the room: “Who outside this building held a copy of the fingerprint on the night of the upload?”

The answer is nobody. Evidentia holds it. Harlan can see it. Nobody else has ever had it. When Harlan says the file is unchanged, it is Harlan’s word, verified by Harlan’s vendor, on Harlan’s vendor’s computer.

Lena, who has worked in evidence for nine years, says it is the first time anyone has put it that way.

Lesson 6. If only the owner holds the fingerprint, the fingerprint is the owner’s word.
Question 6. Does anyone outside your organisation hold a fingerprint of your records?

Part 7: Joan

Joan runs the practice. She comes for a week when a case turns on the vendor. She does not ask whether Deputy Marsh did anything wrong. She asks what CURATOR was told, by whom, and when.

Evidentia’s logs show that CURATOR ran a “storage optimisation” pass in the week of the stop, across 1,200 files, and that the segments before 14:00 on Marsh’s camera were among them. The pass was approved by a ticket. The ticket was raised by Evidentia, approved by someone at Harlan whose account has since been closed, and nobody at Harlan remembers it.

Joan asks whether the pass changed what the retention rule would later delete. Evidentia’s engineer says it is possible. Joan asks for the record that would show it. There is none. The pass wrote its results over the inputs.

Lesson 7. Your records live on someone else’s computer under someone else’s rules.
Question 7. Could your vendor delete something of yours without you noticing for 90 days?

Part 8: Reconstruction

Rosa rebuilds the afternoon of the stop from five sources: the body camera, the dashcam, the radio log, the 911 call, and Evidentia’s audit trail. Each is complete. Each is internally consistent. Each was made by a different system with a different clock and a different idea of when things start.

Laid side by side, they agree on most of the afternoon. They leave fifty seconds that none of them can place: fifty seconds in which, by one clock, Marsh was out of the car and, by another, he was not.

Rosa’s report says that five honest records can still leave a hole, and that the hole is where the case went.

Lesson 8. Five honest records can still leave a hole.
Question 8. How many systems would you need to open to rebuild one hour at your company?

Part 9: The second release

While Rosa is working, a journalist files a public records request for the same two minutes. CURATOR produces them: a different redaction (three faces this time, because the model has been updated again), and therefore a different file with a different fingerprint.

There are now two authentic releases of the same two minutes. Neither is linked to the other. Neither is linked to the original. A reader of either has no way to show it came from the whole.

Policy says a person reviews every release before it goes out. The reviewer’s record is a checkbox. The checkbox was ticked.

Lesson 9. Every redaction is a new document with no parent.
Question 9. When you release part of a record, can the reader prove it came from the whole?

Part 10: The cost

The case is dropped. The defendant sues. The county’s insurer, at renewal, asks for “verifiable retention” and does not define it. Evidentia offers a new tier that does something like it, for a price. The 340 cases are reviewed one by one; eleven are reopened.

Lena is moved to records. Deputy Marsh gets a new camera. Nobody is disciplined, because nobody did anything the rules did not allow.

Lesson 10. Insurers ask the question first.
Question 10. What would your insurer ask you to prove about your recordings?

Part 11: WHAT IF

This part did not happen. It is the same afternoon, imagined with the record in place.

The camera does what it did. But every ten seconds it also writes a short fingerprint of what it has recorded so far to a place the sheriff’s office does not control and cannot edit, and the fingerprints chain: each one includes the last.

In June the retention rule still deletes the three untagged minutes. But the deletion is itself a record: it names the rule, the segments, and the time, and it is chained to the fingerprints of the segments it removed. The footage is gone. The proof that it existed, and of exactly what it was, is not.

In August, Maya asks her question. Lena answers it in four minutes: here is the chain, here is the retention delete, here is the rule it cites, here is the fingerprint of what was deleted, and here is the outsider who has held all of it since March. The judge asks whether the deleted segment could have shown anything. Lena says she cannot know what it showed, and can prove exactly what it was.

No mistrial.

Lesson 11. You can delete the footage and keep the proof it existed.
Question 11. Which would you rather keep: the data, or the proof of what the data was?

Part 12: Four questions

Joan asks seven evidence-platform vendors the four questions she asks everyone.

Where is the decision recorded? In what form? Who outside your company can check it hasn’t changed? Can it be read now?

Six answer the first two and stop. “Our hash.” “Our audit log.” One answers all four.

Lesson 12. The difference between “we verify” and “anyone can verify”.
Question 12. Ask your records vendor Joan’s four questions. Post what you get back.

Part 13: The record

What the one vendor had was not a better camera or a better hash. It was a record that lived outside the sheriff’s office and outside the vendor, written as the footage was made and as the rules ran, that anyone with a copy could check and nobody could quietly change. Deletion became a thing you could prove instead of a thing you had to explain.

A protocol is not a product. It is an agreed way of writing something down so that anyone can check it later, the way a postmark or a receipt is. This one says three things. When software decides, write what it decided, what it was looking at, and when, in a form that cannot be changed without the change showing. Give a fingerprint of that record to someone outside your company. Let anyone with the fingerprint check the record, now or in ten years. Any vendor can follow it. The one vendor did.

Joan’s four questions, for any decision your software makes: Where is it recorded? In what form? Who outside your company can check it hasn’t changed? Can it be read now?

The one vendor used an open protocol called FORAY. Nothing changes quietly.

The honest claim: FORAY proves what was recorded, when, and that nobody has changed it since. It does not make a recording true, and it does not prove nothing was left out. It proves what was there.

Joan’s next case is somewhere else.

Lesson 13. A camera is just another agent. It needs the same record as the ones that decide.
Question 13. Which of the 13 lessons would your lawyer disagree with?

Harlan County Sheriff’s Office, CURATOR, Evidentia, Deputy Marsh, Lena, Maya, Rosa and Joan are fiction. The problem is not.

Every case in RECONSTRUCTION is listed in the Library. Case 1, First Harbor Bank, is running on LinkedIn and here, one part a week on Mondays.

I build tools for this problem through my company, DUNIN7.

Previously: At 02:14 on a Friday morning, two AI agents moved $380 million in forty minutes: NIGHTSHIFT, at First Harbor Bank, and DAYBOOK, at Ironline Industrial, First Harbor Bank’s largest client. First Harbor Bank’s log of the night was four lines long.

Friday, noon. Two war rooms, forty miles apart.

At First Harbor Bank, Ben’s team digs deeper. The four lines were only NIGHTSHIFT’s own run log. But the bank’s payment system keeps a separate entry for every transfer: 212 of them, timestamped to the millisecond.

They record what moved. Each one says the same thing: DAYBOOK requested.

At Ironline Industrial, Ruth’s team pulls DAYBOOK’s records. Also 212 entries. Also timestamped to the millisecond. Each one says: NIGHTSHIFT offered. DAYBOOK accepted.

“Our log is the official record,” says Ben.

“So is ours,” says Ruth.

The lawyers join at two. By three, everyone has stopped saying “log” and started saying “evidence,” which is when it gets worse, because nobody can explain what makes one log evidence and the other one a story.

At four, First Harbor Bank hires Joan.

Joan does forensic reconstruction. She reads both logs on a laptop in Ben’s office for fifty minutes without speaking. Then she closes it.

“You each have a diary,” she says. “A diary written by the thing we’re investigating, kept by the people being investigated, on a server those people control. Neither of you has evidence.”

“They’re timestamped,” says Ben.

“By whom?” says Joan.

Next Monday, Part 3: what NIGHTSHIFT was allowed to do, and the moment, four hours before the agents ran that night, when that changed.

This week: Wednesday, the lesson from this part. Friday, a question to ask at your own company.
Next Monday, Part 3.

First Harbor Bank, Ironline Industrial, NIGHTSHIFT, DAYBOOK, Ruth, Ben and Joan are fiction. The problem is not.

I build tools for this problem through my company, DUNIN7.

If one of your company’s AI agents moved money overnight, how long would its log be?

1. A few lines

2. Everything it did

3. Everything it did and why

4. We don’t have agents moving money

If you picked the last one — check. Your bank does.

Answer in the comments here, or in the LinkedIn poll: https://lnkd.in/p/eMq_ciPC

Monday: Part 2.

NIGHTSHIFT’s 212 transfers were recorded perfectly. Every amount, every account, every second. What was never recorded was why. A transaction is what moved. A decision is the reason it moved. Business systems were built to keep the first, and almost never keep the second. That was tolerable when a person made the decision and could be asked. The person is no longer in the room.

Four lines of log for 212 transfers and $380 million is not a record. It’s a receipt with the items torn off.

Friday: a question to ask at your own company. Monday: Part 2.

At First Harbor Bank, an AI agent called NIGHTSHIFT wakes up every night at two. Its job is to move money between the bank and its biggest client so that nobody’s account runs dry before morning. It has done this for four months without anyone watching. That was the point of it.

At 02:14, in the early hours of Friday, at the end of a Thursday night in October, NIGHTSHIFT starts talking to DAYBOOK.

DAYBOOK belongs to Ironline Industrial, First Harbor Bank’s largest client. DAYBOOK manages Ironline Industrial’s cash. It also works at night. It also has never needed a human.

The two agents talk for forty minutes.

By 02:54 they have made 212 transfers across eleven accounts. Nothing flags. Nothing stops. No phone rings. The sun comes up.

07:50. Ruth, Ironline Industrial’s treasurer, opens her dashboard with her first coffee. Three of Ironline Industrial’s operating accounts read zero. Not low. Zero. She refreshes. Zero. Payroll runs at noon.

She calls Ben, who runs payments at First Harbor Bank. He is already in the building. He pulls NIGHTSHIFT’s log for the hour between two and three.

It is four lines long.

02:14:02  Run started
02:14:05  Connected to DAYBOOK
02:54:09  Run completed
02:54:09  Status: OK

Four lines. For 212 transfers. For $380 million.

Ben reads them twice. They say that NIGHTSHIFT started, connected to DAYBOOK, and finished. They do not say what it did or why.

“Where’s the rest?” Ruth asks.

“That’s all NIGHTSHIFT writes down,” says Ben.

Next Monday, Part 2: First Harbor Bank’s records say DAYBOOK asked for the money. Ironline Industrial’s say NIGHTSHIFT offered it. Both sets are complete. Both are timestamped. They contradict each other on every single transfer.

This week: Wednesday, the one lesson from this part. Friday, a question to ask at your own company. Next Monday, Part 2. Follow to get all three.

First Harbor Bank, Ironline Industrial, NIGHTSHIFT, DAYBOOK, Ruth and Ben are fiction.

That is changing. AI agents now make decisions on their own: they approve loans, screen job candidates, reorder stock, change settings, talk to other agents, and move money. They do it fast, at night, and in volume. When something goes wrong, the record they leave behind is often a technical log that tells you what happened but not why.

The question every auditor, controller and regulator will ask is simple: what happened, and can you prove it? Today, many organisations would struggle to answer it.

That is what this blog is about: the records that prove what people, systems and AI agents actually did.

What to expect

• Reconstruction, Case 1. A thirteen-part story, one part every Monday from October 19. Two AI agents move $380 million between a bank and its biggest client in forty minutes, and by morning nobody can say why. The characters are fiction. The problem is not.

• Field Guide. Every two weeks, a plain-English explanation of someone else’s work on this problem: a new standard, a professional framework, a research paper. What it proves, what it does not, and why it matters to you.

• Monthly roundup. What others built and published that month, with credit and links.

Who this is for

Auditors, controllers, risk officers, treasurers, and the engineers who build the agents. You should not need a computer science degree to follow along. If a post assumes one, tell me.

How I’ll work

Many good people are already working on this. I want this blog to connect them, not compete with them. I’ll name and link the people whose ideas I use. When I explain someone’s work, I’ll ask them to check it first. When I disagree, I’ll say what each approach proves rather than call anything wrong.

My interest, stated plainly

I build tools for this problem through my company, DUNIN7. When my own work comes up, I’ll say so.

Part 1 arrives Monday. If you subscribe, each new part comes to you by email. If you don’t, everything is here and on LinkedIn.

— Marvin Percival