Rejected Options and Uncertainty

Overview

A table showing why your choice won is weak evidence. Everyone’s choice wins in their own table.

Credibility comes from two things most justifications omit: the options you rejected, with real reasoning, and the places where you do not know. Both feel like weaknesses to include and both are what make the document persuasive.

Why rejections carry the weight

A justification with one option is a decision presented as inevitable, and no experienced reader believes it. The implicit claim — that only one approach was available — is almost never true, and asserting it tells the reader you either did not look or are not telling them what you found.

Rejections do three things a chosen option cannot:

They demonstrate the space was searched. A reader can see what you considered and judge whether the set was serious.

They let someone disagree productively. If the rejected option they favour is listed with a reason, the conversation is about that reason rather than about whether you thought of it. That is a far better argument to have, and it is winnable on evidence.

They are reusable. When the same option is proposed again in nine months by someone new — and it will be — the reasoning already exists. Module 3 made this the compounding argument for recording decisions; this is the same mechanism inside a single document.

Three properties of a usable rejection

graph TD
  A["<b>Real</b><br/>an option someone<br/>would actually propose"] --> D["A rejection that<br/>survives challenge"]
  B["<b>Attributed</b><br/>names the criterion<br/>that killed it"] --> D
  C["<b>Conditional</b><br/>states what would<br/>bring it back"] --> D

  classDef prop fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef out fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  class A,B,C prop
  class D out

Three properties. The third is the one almost always missing, and it is what turns a rejection into a decision somebody can revisit honestly.

Real. An option someone would actually propose. A straw man — included to be dismissed — damages credibility more than having no alternatives at all, because a reader who spots one stops trusting the rest of the document. The test: would a competent engineer have advocated this?

Attributed. Name the criterion that killed it, not a vague judgement. “Too complex” is not a reason; “requires GPU operations capability the organisation does not have and cannot acquire this year” is.

Conditional. State what would bring it back. This becomes the right answer if the volume reaches X, or if the provider cannot contractually guarantee Y. A rejection with a reversal condition is a decision; one without is a dismissal, and dismissals get re-litigated by whoever did not hear them.

Stating uncertainty

The other half, and it runs against instinct: naming what you do not know makes the rest of the document more believable.

The mechanism is the asymmetry from the first topic in this module. A document with no stated uncertainty implies everything in it is equally solid, so a reader who finds one soft claim has to downgrade all of it. A document that marks its own soft spots is telling the reader which parts to trust — and the marked spots are evidence that the unmarked ones were examined.

Three forms that work:

• Not measured. “Correctness is unmeasured; no golden set exists. A two-week shadow run would resolve it.” Names the gap and the remedy.
• Estimated, with the assumption exposed. State the figure, then name the one assumption carrying most of its weight — the handling rate, say — so a reader knows which number to attack first.
• Genuinely unknown. “Nobody knows whether the documentation can answer these questions. A two-day audit of fifty tickets would settle it.”

Module 1’s rule holds: where a claim is a strong thesis rather than settled fact, say so. The cost is that an uncertain-looking document is occasionally read as indecisive by someone who wanted reassurance — which is a real cost, and smaller than being found to have overclaimed.

Making the reasoning outlive you

One last property, and it is the test that matters most in two years.

Write the justification so that someone who was not there can reconstruct the decision — the criteria, the options, the evidence, the rejections, the conditions that would reopen it. That document is what stops the same argument recurring every time the team changes, and it is the highest-leverage thing an architect produces.

Module 9 builds this into a practice. Here it is enough to notice that the audience for a justification includes people you will never meet.

Two rejections and three admissions

From the Module 4 stack decision, written as a reviewer would need to read it.

Rejection 1 — self-hosted open-weight inference, in-region. Real: genuinely tempting. It satisfies the residency constraint perfectly, removes the vendor relationship, and a competent engineer would advocate it. Attributed: rejected on capability, not cost. The arithmetic actually came out acceptable — roughly $0.46 per deflected interaction on a stated assumption of $2.00 per accelerator-hour, against a $1.54 ceiling. What defeats it is that there is no GPU operations capability among 140 engineers fully consumed by the strangler migration, and acquiring it would displace the migration itself. Conditional: revisit if a platform capability exists for other reasons, or if hosted in-region processing cannot be contractually guaranteed — in which case this becomes the only compliant option rather than the second choice.

Rejection 2 — third-party support-AI product. Real: the fastest path to Priya Shah’s two-quarter commitment, and the option a product-minded stakeholder would raise first. Attributed: eliminated on a constraint, not scored. Several enterprise contracts forbid customer data leaving its region entirely, and a hosted product processing tickets outside it violates that outright. Conditional: revisit only if such a product offers contractually guaranteed in-region processing with retention terms Lena Fischer accepts.

The three admissions, stated in the pack rather than buried:

1. Correctness is unmeasured. No golden set exists yet. The 90% floor is a requirement, not an observation, and a two-week shadow run against 300 curated questions is what would turn it into one.
2. The cost model is an estimate with one load-bearing assumption — a 70% handling rate. At 50% the per-interaction ceiling tightens substantially, and that sensitivity is shown rather than mentioned.
3. The 38% deflectable figure is untested. It is a claim about the documentation rather than about the tickets, and nobody has attempted to answer fifty of them from the docs alone. Two days of Grace Adeyemi’s team would settle it.

That third admission is uncomfortable because every number downstream depends on it. Including it is what makes the rest of the pack trustworthy — and it converts a hidden risk into a two-day task somebody can fund.

Feeds the workbook

Two rubric items land here directly: at least two rejected options with real reasoning rather than straw men, and uncertainty stated somewhere rather than smoothed over. Add the reversal condition to each rejection — it is the property that makes them hold.

Check your understanding

1. Write your two strongest rejections with all three properties. Which one lacked a reversal condition until you added it?
2. Where is your justification softest? Write the sentence that admits it and names what would resolve it.
3. Someone proposes a rejected option again in nine months. What in your document answers them without you present?

---

→ The pack is defensible on paper. Now it has to survive a room. — The architecture pitch