Choosing Under Constraint

Overview

You have the menu, the properties that drive the choice, and the tactics available inside it. This topic makes the decision — and does it in the form that will survive being challenged, because an architectural choice that cannot be defended in a room is not yet a decision.

The method is a trade-off table. The thing most people get wrong about it is the order of operations.

Constraints veto; requirements score

A trade-off table has two kinds of column, and treating them the same way is how indefensible decisions get made.

A constraint is pass or fail. An option that violates it is not a low-scoring option; it is not an option. Scoring it at 1 out of 5 and letting a strong total carry it is the most common way a compliance boundary gets quietly traded away by arithmetic.

A requirement scores. Options can be better or worse against it, and the scores are comparable.

So the sequence is: eliminate on constraints first, then score what survives.

graph LR
  O["Candidate<br/>options"] --> V{"Violates any<br/>constraint?"}
  V -->|yes| X["Eliminated<br/><i>not scored at all</i>"]
  V -->|no| S["Scored against<br/>weighted ASRs"]
  S --> D["Decision<br/>plus rejected options<br/>and their reasons"]

  classDef start fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef gate fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  classDef out fill:#D8D3CB,stroke:#B8B2A8,stroke-width:2px,color:#3F3F3F
  classDef score fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef dec fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  class O start
  class V gate
  class X out
  class S score
  class D dec

Elimination happens before scoring. The drained box is where options go when they fail a constraint — and they leave the table rather than competing on points.

Fix the criteria before you look at the options

The second discipline, and it is about intellectual honesty rather than method.

Write the columns — the constraints and the weighted ASRs — and commit to them before scoring anything. Weights come from the Utility Tree, which already carries business value and architectural risk, so you are not inventing them here.

The reason is simple: if you score first, the criteria get adjusted until the option you already preferred wins. Everyone does this unconsciously, including people with no agenda, and the only protection is sequence. Module 8 treats this as a credibility mechanism rather than a methodological nicety, because a table whose criteria visibly predate its scores is the difference between a justification and a rationalisation.

Rejected options are the credible part

A table with one option is a decision presented as inevitable. Nobody believes it, and rightly.

Include the options you genuinely considered, including the one that was tempting for bad reasons. For each rejection, state what killed it: a violated constraint, a specific ASR it scored badly against, or a capacity cost the organisation cannot absorb.

Three properties make rejections useful rather than decorative. They must be real — a straw man damages credibility more than having no alternatives at all. They must name which criterion did the killing, not a vague “too complex”. And they are reusable: when the same option is proposed again in nine months by someone new, the reasoning is already written down, which is exactly the compounding effect Module 9’s ADR practice exists to capture.

The column everyone forgets: what it costs to staff

An option you cannot staff is not an option, and this column is missing from most trade-off tables in the wild.

Add it: for each surviving option, what does it demand in engineering capacity, what existing work does that displace, and does whoever owns the engineers agree the trade is acceptable? A design that requires a platform investment nobody will fund is not a better design than one that does not — it is a worse one, because it will not exist.

The honest consequence is that the technically strongest option sometimes loses to the one that can actually be built this year. That is not a compromise of architectural standards; it is the standard. The next topic in Section 2 is about making that sequencing explicit rather than letting it be the hidden reason a design quietly fails.

The table that makes the decision

Four options, with residency as a veto column rather than a score.

Option	Residency constraint	Accuracy ASR	Cost ceiling ASR	Blast-radius ASR	Capacity cost
A — build it inside the Rails monolith	Pass	Weak: couples the retrieval path to monolith release cadence	Neutral	Poor: agent actions share a process with the system of record	Low build, high risk to Ivan Petrov’s domain
B — one new service in the Go estate	Pass	Good	Good	Weak: retrieval and action share a deployable and a failure domain	Moderate
C — two services: retrieval path and action path	Pass	Good	Good	Good: action surface isolated, separately rate-limited and audited	Moderate, plus one extra deployment pipeline
D — third-party support-AI SaaS	FAIL	—	—	—	—

Option D is eliminated, not scored. Several enterprise contracts forbid customer data leaving its region entirely, and a hosted product that processes tickets outside it violates a constraint — so it never reaches the comparison, regardless of how well it would have performed on cost or speed. Writing it as a failed constraint rather than a low score is what stops someone totalling the columns and reviving it.

Option A is tempting for a bad reason: it is the fastest path to Priya Shah’s two-quarter commitment. It loses on blast radius, because an agent that issues credits should not share a process with the system of record, and it would also put the initiative’s release cadence inside the monolith that the strangler migration is trying to empty.

Decision: option C. The retrieval path and the action path have genuinely different NFR budgets — the accuracy and cost numbers sit on one, the blast-radius and audit numbers on the other — and the change-case analysis showed their expected changes do not cross. Option B is the serious runner-up and would be the right answer if the agent could not take actions; that is the sentence worth keeping, because it names the condition under which the decision should be revisited.

Feeds the workbook

This is the style selection with its trade-off table, and three rubric items land here: the choice must cite specific ASRs, the table must include a rejected option with real reasoning, and the result must respect the existing monolith rather than assuming it away.

Check your understanding

1. Build your table with constraints as veto columns. Did any option survive scoring that should have been eliminated earlier?
2. Add the capacity column. Does your preferred option change? If not, are you sure the column is honest?
3. Write the one-sentence condition that would make you revisit your decision. If you cannot, what does that suggest about the decision?

---

→ That closes Section 1: you have a decision. A decision is not yet something a team can follow. — Reference architecture