Recording the option you rejected

The path you closed still matters. If it is not written down, the next reader will reopen it — or assume you never considered it.

3 min read

You spent half an hour talking yourself out of vendor C. The briefing you send names A and B and asks for a pick. Two days later the reply is "what about C?" You have the argument again, this time in email, with someone who thinks they are being helpful.

They are. You left a hole that looks like a gap in the work. A closed door that is not on the floor plan is a wall people walk into.

Silence reads as "never considered"

The person who was not in the session cannot see the abandoned direction. In a chat, the thread just stops. In a meeting, the no was a shrug. Neither produces a sentence a later reader can trust.

So they do one of two things, both expensive:

  • They reopen it. You re-explain. The decision slips a week.
  • They assume you missed it. They lose confidence in the rest of the brief, because if you missed C you might have missed the constraint that actually matters.

Asking for a decision only works when the list is closed. A list that omits the obvious alternative is not closed. It is a trap.

One line is enough, if the reason is honest

You do not need the full debate. You need a sentence the reader can disagree with.

"C is out — they cannot hit September, and the deadline is not movable." That is a fact, if the date is real.

"C is out — I am guessing their implementation team is two people, and I will not bet the launch on that." That is an assumption, and it should look like one. State it so they can correct it. If they know the team is twelve, C comes back for a reason, not as a vibe.

A rejected option with a false reason is worse than no mention. You have now recorded a premise someone will treat as decided.

Put it where the next model will see it

Your assistant will forget the abandonment the moment the session ends, or it will remember it as a preference and write it into the next draft as if it were a law. The briefing is the place the closure survives.

A briefing has a slot for options considered. A rejected path belongs there, not in a paragraph of colour. The reader who skims still sees that C was on the table and left it. The assistant who pulls the package later does not invent "we never looked at C."

If you hand off to yourself, this line is the whole point. The other model should not reopen a door you already shut. Give it the door and the reason.

When to leave it out

If the rejected idea would never occur to this reader, naming it teaches them a bad option they then have to unsee. Do not list every fantasy the model offered. List the one they will raise, or the one a reasonable person would think you forgot.

The test is the next reply. If you can predict the "what about C," write the line now. It is the cheapest page in the package and the one people skip because they already know. They already know. The reader does not.

Frequently asked questions

Why include an option I already said no to?
Because the next reader was not in the session where you closed it. Silence reads as omission. They will raise it again, or they will think you missed it.
How much do I have to write about the rejected path?
One line — what it was, and why it is closed. If the reason is a guess, label the guess.
Does a briefing require rejected options?
The format has a place for options considered. Use it when reopening the path would waste a turn. Skip it when the rejected idea would never occur to the reader.