Keep the Dead Ends: How to Record What Your Firm Ruled Out, and Why

What Is a Dead End Worth Keeping?

An option the firm took seriously, tested or argued through, and then ruled out, written down with the reason it was ruled out.

It is not every idea anyone mentioned. It is the option that cost real thought: a second structure for a deal, a line of argument the team drafted and abandoned, a supplier evaluated and turned down, a scope that was proposed and then narrowed.

What makes it worth keeping is the reason. A note that says an option was not taken tells the next team almost nothing. A note that says why, and what would change the answer, tells them where to start.

In August I argued that a firm's decisions, with their rationale, belong in the knowledge its AI works from. The options a decision ruled out are the part of that rationale easiest to leave out, because nothing about the finished deliverable asks for them.

What Did One Design Campaign Show?

That a record of failed attempts can change what a system tries next, in one case reported by the vendor itself.

The example in this section is a vendor's account of its own product: 1 campaign, with no published control. I use it for the move it describes, not as proof.

On 7 September 2026, a Microsoft team described a design campaign in which its AI system, working with outside research partners, designed a candidate material for grid energy storage.

The post describes a system that worked in 3 rounds and kept a structured record of what it learned, the failures included. The post says why such a record matters: "structured records allow successes and dead ends to accumulate across themes and campaign rounds."

By Microsoft's account, none of the explorations in the second round produced a candidate fit to take forward, and in the third round 4 of the 6 explorations succeeded.

The post is specific about what stayed the same between the 2 rounds: "The seed candidate, tools, compute, and problem boundary conditions were unchanged between the two rounds; what changed was how Discovery Engine interpreted the accumulated evidence and adapted its workflow for analyzing candidate options."

It then draws an inference, which is Microsoft's and not a measurement: "Had only successful explorations been retained, the third round would likely have repeated the second round’s failures."

The sentence I would keep from the whole post is shorter: "negative evidence creates value when it changes the next decision".

That clause carries the test I would apply to any record of dead ends. Writing a note can sharpen the decision in hand. Its value to the next team arrives only when someone reads it before choosing.

This is laboratory chemistry, and nothing in it concerns a law, accountancy or consulting practice. The post makes the wider claim itself: "Most organizations are optimized to preserve outcomes, yet few are optimized to preserve the evolution of belief that produced them." Teams, it goes on, then "relearn lessons that have already been paid for."

Carrying that into an expert firm is my argument, not Microsoft's. The post closes on Microsoft's own products, as a vendor's post will; the record I mean needs only a document the firm already keeps.

Why Can AI Make This Half Grow Faster?

Because exploring an option can now take minutes, so a team can look at more options than it will ever take forward, and each one it drops leaves a reason worth keeping.

The same post names the shift it sees in scientific work: "Generating ideas is no longer the primary bottleneck."

It adds: "The scale of explorations and hypotheses increases rapidly over the course of a design campaign."

My reading for a firm is simple arithmetic. When a second structure for a deal, a third line of argument or a fourth way to scope the work takes minutes to draft, a team can explore more of them than it could when each one was drafted by hand.

Whatever goes to the client, other options may have been considered and dropped on the way. So the more a team explores, the more dropped options it can have, and the more reasons worth keeping.

None of this argues for exploring less. It argues for keeping what the exploring found.

A design fact to plan for

The post also describes AI agents staying effective on long tasks by compressing their earlier working context, "a critical but lossy technique for maintaining agent performance on long duration tasks".

Nothing is wrong with that; it is part of how long tasks stay manageable. It means the reason an option was dropped is not something to leave inside the tool's working context: someone has to decide it belongs in a durable record the firm keeps.

The same holds without any AI at all. A reason kept only in a meeting, a chat thread or one person's recollection is in a lossy store too. The tools have changed how fast options appear, not where their reasons should end up.

What Should a Firm Write Down?

On any decision that took real thought, 3 lines: what else was considered, why each option was dropped, and what would reopen it.

• What else was considered: the options that were live, named plainly.
• Why each was dropped: the test, the evidence or the judgement that ruled it out.
• What would reopen it: the condition under which the firm should look again.

Each line has a weak version and a strong one. To show the difference, take one illustration, not a case from any firm: a team deciding how to produce a quarterly update for a client. The team settles on a short briefing drafted with an AI tool from the quarter's file notes and reviewed by the partner.

Line 1: what else was considered

Weak: other options were reviewed.

Strong: also considered a full written report, a call with no written record, and drafting each update by hand.

The test is whether a second person could name the options without asking anyone. Naming them plainly matters more than describing them fully.

Line 2: why each was dropped

Weak: did not fit.

Strong: the full report was dropped because the client's team said, when asked at the last review, that they read the first page only; the call was dropped because the client needs something to forward internally; drafting by hand was dropped because the file notes already hold the facts, and the partner's time is better spent on the review.

The reason should say what kind of reason it was: a test that was run, evidence that was read, or a judgement that was made. In the illustration, the first is evidence, the second a stated need and the third a judgement.

The kinds call for different things later. A test can be run again, and evidence can be read again. A judgement can be tested later against what happened, but the next person cannot see why it was made unless the reasoning was written down, so in my view it is the kind that most needs that reasoning in a sentence.

Line 3: what would reopen it

Weak: revisit later.

Strong: reopen the full report if the client asks for one for its board; reopen the call if the client no longer needs to forward the update inside its own organisation; reopen drafting by hand if reviewing the drafts starts to take longer than writing them did.

This line does the most work over time. A reason can go out of date, and a reopening condition tells the next person when to check. A good one names something a person could notice, not a feeling that things may have changed.

Where Should the Record Live?

With the decision it belongs to, in the document the firm already keeps for that work, not in a separate archive.

My concern with a separate archive of failures is that it sits outside the path to the next decision. Put the lines where the next person is most likely to look before deciding: depending on the work, the file note, the matter record, the project's decision log or the written procedure.

The written procedure is a natural home for one kind of dead end: the step the team tried and replaced. A line beside the step, saying what it replaced and why, can stop someone restoring the old step the next time the procedure is reviewed.

If a firm's AI tools read from its documents, a dead end kept with its decision is there to be found when the same question comes back. That is a reason to write it in plain text, where both the people and the tools can find it.

What Does a Record of Dead Ends Look Like in Practice?

Mine is a decision log, written by my AI operating system as it works, that the system's standing instructions point back to. One episode from it shows the lines at work, and one line missing.

On 19 September 2026 it recorded the diagnosis of a slow storage array on my own workstation. The question was mine: I did not accept the speed the record had been treating as normal, and the measurements bore that out.

What the entry holds is the point. It has a table of 5 suspects, each with the test that cleared it, and it names the 1 that remained. The drives, the cards and fragmentation are in it, with 2 more.

The same entry keeps a mistake in its own method, in a bullet whose bold lead ends "worth keeping."

A later entry the same day records the cause that a second, independent diagnosis strongly indicated, and 3 reasons the first pass had not found it, set down "so it is not repeated". It also corrects the test behind 1 of the 5 eliminations.

My reading: an elimination written down with its test can be checked later, and this one was.

The log also records a fix that was not made, with the reason and with what must happen first: "Test on spare storage first." That is a reopening condition in 5 words.

The diagnosis is not closed: the entry asks for its numbers to be measured again on a quiet machine, and, as I write, no fix has been applied. The record is there so that the next look at that array can start from the table rather than from the beginning.

Set against the 3 lines, the record is partial, and usefully so. For the question of cause, the 5 suspects the record cleared, each with its test, are the first 2 lines. The condition on the fix is a third line for a different decision: whether to change the array at all.

What the entry does not say is what would reopen any of the eliminated suspects. That is the line I would add.

When Is a Dead End Only Half Dead?

When the option that failed is wrong in one way and still useful in another. The Microsoft post carries this quieter lesson.

A prediction tool in the campaign turned out to be wrong on its numbers: the post says it "was not numerically accurate, but it remained directionally useful for ranking candidates".

By Microsoft's account, the system did not throw the tool away. "Rather than discarding the model, Discovery Engine recalibrated its trust in the predictor, treating predicted values as relative signals instead of precise estimates."

That is 1 tool in 1 campaign, reported by Microsoft, and I take it as a question to ask, not a law.

Before a firm retires a scoring or forecasting tool for being wrong, it is worth asking whether it is wrong on the values or wrong on the order. To take an illustration, a model that estimates how long pieces of work will take can be wrong on the hours and still put the jobs in the right order from shortest to longest.

A record that says dropped loses that distinction. A record that says dropped for exact figures, still used for ranking keeps it.

So I would add a short fourth note to the 3 lines whenever it applies: what the dropped option is still good for. When there is nothing to say, leave it out. When there is something, it is the note meant to stop a useful tool being thrown away with its mistake.

Who Writes the 3 Lines, and When?

The person who ran the work, at the moment the decision is closed, while the reasons are still fresh.

In my judgement, lines written weeks later become a reconstruction. Written at the close, they are part of closing the decision, the way a file note is part of closing a meeting.

A newer post on the same Microsoft blog puts the expert's side of this well. Writing on 23 September 2026 about an analysis of wastewater sequencing data done with Microsoft's platform, Simon Frost, a Principal Scientist at Microsoft, lists among the expert's tasks "knowing what assumptions and trade-offs were made at critical analytical junctures".

He also writes that capturing how the work was done matters in large collaborative teams, for reproducibility and for training. It is, again, a Microsoft author describing Microsoft's product, and I quote it for the principle.

In a firm, the junctures are the decisions, and the person who knows what was traded off is the person who ran the work. An AI tool can draft the 3 lines from the meeting notes and the drafts; the person who ran the work decides what they say.

One practical rule can help it stick: a decision is not closed until its 3 lines exist. That is a habit, not a system.

What Should a Leadership Team Ask?

Where did we last relearn a lesson we had already paid for?

I would expect the answers to be specific: a pilot that was stopped and then proposed again by a team that never saw why, a tool evaluated twice, an approach abandoned in one office and attempted in another.

For a stopped pilot, the third line is the restart condition I argued for in the decision a pilot was never asked to make: what has to be true before the work starts again.

Then make the 3 lines part of how a decision is closed, not a separate archive. Ask the person who ran the work to write them while the reasons are fresh, and keep them with the decision they belong to.

Nobody needs to be told to explore less. The more options your people can try with AI, the more this record is worth.

The Verdict

A firm's files hold what it delivered. What it tried and ruled out, with the reasons, is knowledge it has already paid for and can choose to keep.

AI can make that half grow faster, because exploring takes less time and a team can explore more than it takes forward.

3 lines on each real decision keep it: what else was considered, why it was dropped, and what would reopen it. Keep them with the decision, and write them when it closes.

A firm that keeps its dead ends can stop relearning its own lessons, and spend that time on the questions it has not answered yet.

This is the work I do, and I keep the same kind of record in my own practice.

If your team has a decision it keeps having to make again, see how the engagements work and send me a note about it.

The thinking continues in The AI Operating System, my fortnightly LinkedIn newsletter, where an earlier version of this argument first appeared.

Frequently Asked Questions

What is a dead end in a firm's decision record?

An option the firm took seriously and ruled out, written down with the reason. It is not every idea mentioned in a meeting; it is the option that cost real thought.

Is this the same as a lessons-learned review?

Not quite. A lessons-learned review looks back at a finished piece of work; the 3 lines are written as each decision closes. They can feed such a review, but they are shorter, they sit with the decision, and they are there when the same question comes back.

Why does AI make this record more valuable?

Because exploring an option can now take minutes, so a team can consider more options than it takes forward. Each one it drops leaves a reason the firm has paid for and can keep.

Should the AI system keep the record by itself?

It can draft the record; a person decides what it says. Long-running AI agents can compress their earlier working context, so the reason an option was dropped belongs in a durable record the firm keeps, written or approved by the person who ran the work.

What if a reason goes out of date?

That is what the third line is for. A reopening condition tells the next person when to check whether the reason still holds, instead of treating an old answer as permanent.

Sources

Each page was read at the publisher's own site on 3 November 2026. All 3 are Microsoft describing its own work and products.

• Microsoft Discovery Blog (Microsoft Tech Community), Reinventing Organic Redox Flow Batteries with Microsoft Discovery, 7 September 2026.
• Simon Frost, Microsoft Discovery Blog, Decoding Environmental Viromes: Amplifying Human Expertise with Microsoft Discovery, 23 September 2026.
• Microsoft Azure Blog, Beyond the benchmark: How an adaptive approach drives scientific discovery, 8 September 2026, which refers to the same battery work.

Dr Bruno Oliveira — PhD · Associate Professor, University of Bath. Founder of GustoMind.ai. Builds and installs AI operating systems for expert-led firms, running the same system daily in his own work.