The meeting is scheduled for an hour and runs ten minutes over. The product owner wants the new platform “highly available — let’s say 99.99%,” “real-time where it matters,” and “scalable, obviously.” The architect writes all three on the whiteboard. Everyone nods; the meeting ends; the requirements document says exactly what the whiteboard said. Six months later the platform carries a cross-region consensus store nobody can operate, a queue on paths that needed function calls, and a latency target no one can state from memory — and every one of those purchases traces back to that whiteboard, where three wishes were recorded as answers.
Chapter 1 claimed the architecture follows from the answers. That claim puts enormous weight on the answers, and this chapter is where the weight lands. A derivation is only as honest as its inputs: garbage answers derive garbage vectors with perfect mechanical integrity. So the input side needs two things a requirements meeting never produces on its own — the right questions, and a gate that keeps wishes from passing as answers.
It also needs something subtler, which this chapter does in the open: a justification for the questions themselves. A question list handed down without argument is taste moved upstream — the loudest voice replaced by the author’s voice, which is no improvement. Every question below has to demonstrate its seat: its answer must be able to force an axis on its own. The list was not born this clean; it is the survivor of an audit against this method’s own derivation record, and its count is an output of that audit rather than a choice.
What a question must do to earn a seat
The derivation gives questions a job description. An answer participates by pressing an axis toward a value or pruning values an axis can no longer hold. So the membership criterion writes itself: a question earns its place only if its answer can press or prune at least one axis independently of every other question’s answer. A question whose answers never move anything is decoration. A question whose pressure always arrives bundled with another question’s is a duplicate wearing different words.
Nine questions hold seats under that criterion, each audited against every derivation this book runs. The count deserves one sentence of standing law rather than a history: it is an output, and if a tenth demand ever demonstrates independent pressure — pressing or pruning an axis no current answer reaches — the sheet grows. The criterion outranks the number.
The questions organize by what their answers do in the derivation, because that is the property that matters when you hold the sheet. Five driver modes cover them.
Prune mode: the correctness answers
Prune-mode answers are binary. They do not trade against money or cleverness; a value that cannot honor them is struck, and no amount of hardware buys it back.
The consistency contract — per data class and per path: which reads must be strict, which may lag behind writes and by how much, who must see their own writes. This is the question people answer with a shrug and pay for with an incident. The contract is per data class because one system legitimately carries several: the booking that must be strict and the availability display that tolerates thirty seconds of lag are different contracts in one product.
The loss budget — per data class: how much of this data may be lost, ever, and how long must it be kept. A recovery-point objective of zero on confirmed sales is a prune-mode fact: values that cannot durably commit before acknowledging are simply gone from the board.
External constraints — the regulator’s and the contract’s reach: what must be auditable, what must be replayable, what must be erasable, where data must reside, which mandates strike values outright. One decomposition inside this question does more damage prevention than any other in the sheet, and it gets its own section below.
Multi-X — countries, currencies, tenants, regions, versions. Two different outputs hide here: partition gifts (tenants that never interact are a natural shard key — Part II shows one carrying a hundred-billion-dollar platform) and legal pins (data that must stay in-country by statute). One question, because both arrive in the same breath of business fact; two readings, because one gives capacity away and the other takes options off the table.
Select, isolate, split, bound
The time budget (select mode) — per operation, and shaped, never a scalar: percentiles and tails for request paths, soft maxima where a human waits, completion windows where a batch must land inside a business deadline. Latency selects among surviving values rather than striking them, and it presses only near a physics floor: a 2-second budget over a 2-millisecond path forces nothing, a 50-millisecond contract over a cross-region hop forces everything. The shape catalog doubles as a scope detector: an answer with a hard maximum as a correctness criterion — a deadline whose breach is a system failure, at hard-real-time strictness — is the tripwire that says this book’s methods stop applying. Enterprise backends live in percentiles; anti-lock brakes do not, and the sheet must say so at elicitation time rather than let the derivation discover it.
The failure budget (isolate mode) — per operation: the error budget and the criticality that sets it. A 99.5% target is forty-four hours a year, and a restart strategy fits inside it; a 99.99% target is fifty-three minutes, and whole classes of design stop fitting. Availability starts biting past roughly three nines on a named path, and what it bites is blast radius: the axis moves it forces are isolations.
Load (split mode) — magnitude at steady state and peak, shape per path, concentration, and window. This is the merged question, and the merge taught a discipline: load answers are only meaningful per path, because “the system is read-heavy” is routinely true at one tier and false at another: Part II contains a system that is read-dominated at the HTTP tier and write-majority at the store, simultaneously, and any sheet that recorded one number for it would be wrong twice. Load presses only on divergence: uniform load, however large, presses sizing rather than structure. The shape vocabulary that decides what a load answer can force — volume (sustained magnitude), burst (a peak with a tolerable settling delay), contention (many actors, one record), deadline (finish inside a window) — belongs to the ledger, where each shape meets the mechanism that contains it.
Release structure (bound mode) — cadence divergence between parts of the system, and deploy safety; one of this question’s usual bundles is a fake driver so common it needs its own paragraph below.
The cost and capacity envelope (bound mode) — money, and the question that sounds too small to matter and decides more architectures than latency does: who operates this? Four engineers and no operations team is an answer that moves axes. Bound-mode answers rarely press a single move; they set the envelope every other resolution optimizes inside.
The entry gate: answers are purchased, not collected
The whiteboard meeting failed before any question was asked, because it treated answers as things people say. The derivation treats answers as things people buy. Five disciplines make up the gate.
Priced. Chapter 1 planted the flag on unpriced SLOs; the gate is where pricing happens. A fourth nine costs a number someone can compute — in redundancy, in on-call, in correlated-failure engineering — and the pricing drill is one question long: what does the business do differently in the fifty-third minute of annual downtime? If the honest answer is “nothing,” the real target just revealed itself, one nine lower and an order of magnitude cheaper. Most nines dissolve under this question. The ones that survive are real, and the derivation treats them with full respect.
Scoped. Scope lives inside the question — per operation, per data class, per path — never around the system. One system-level number is how bare adjectives sneak back wearing digits. The banned vocabulary is worth naming: “scalability,” “high availability,” “performance” (words that hide both the scope and the shape of a demand). The sheet forces the honest versions: which path, under what load, within what budget.
Decomposed. Answers arrive as bundles, and bundles press falsely. The canonical fake driver: “the teams need independence.” Decomposed, it splits into ownership boundaries (which module boundaries contain at zero deployment cost) and release-cadence independence, which is a genuine topology driver that most teams, asked directly, do not actually want: they want to stop stepping on each other, and one deploy train with owned modules delivers that. The bundled version buys a service fleet; the decomposed version buys a directory structure. The same discipline dismantles “we need audit,” which is where the most expensive accident in the storage axis lives, and it splits three ways, because a third demand hides behind the same meeting language. Audit asks who changed what, when: answerable by an audit log written alongside current state. Replay asks what did the system believe on March 3rd under March 3rd’s rules: answerable only by event-sourced history. And erasure — the right to be forgotten, a statutory demand wherever personal data lives — runs against both: it requires that specific facts become irrecoverable, which strikes exactly the append-forever machinery replay buys. Three demands that sound alike in a requirements meeting force three different storage answers, and one pair of them can genuinely contradict: replay-required and erasure-required on the same data class is a statutory collision the derivation must surface, not paper over. The regulated industries’ folklore that “compliance requires event sourcing” is this three-way decomposition skipped, at seven figures.
Triaged. Two things masquerade as answers and belong outside the sheet. Business-process deadlines bind the requester’s clock: a statutory 14-day filing window is a real obligation that no latency mechanism can address and no architecture axis feels: it re-enters later as a calendar constraint on transformations. Only system-clock targets press. And observed failures — last quarter’s outage, the incident that started the whole initiative — are evidence about failure domains, never demands: they earn a place in the derivation only if the business converts them into a number it will pay for, which is the gate doing its job on trauma the way it does on wishes.
Surfaced early. When two stakeholders answer the same question differently at the same scope — the CFO wants every report strictly current, the COO won’t fund the store that could deliver it — the sheet has caught a business contradiction wearing an engineering costume. Catching it here, where renegotiation costs a meeting, is the cheap version of a discovery that otherwise arrives in production. What the derivation does when a contradiction survives all the way through is Chapter 8’s subject, and it is the method at its most useful.
The second row source
One kind of input deliberately lives outside the nine questions, because no stakeholder answers it — the domain itself does, through the analysis work this book’s companion methodology owns. Two families of fact arrive this way.
Domain-shape facts, for every operation that changes the world: does a defined inverse exist (a reservation releases, an authorization voids — but an email does not unsend)? does the value decay (a seat hold that expires is a fact with a half-life)? can the operation be reshaped so a whole class of failure cannot occur (made idempotent, commutative, append-only)? These drive exactly one axis — recovery.
Change-driver facts, for the system’s rules and data classes: how often, and under whose control, does the logic governing this data class change? A benefits platform whose rules move with political weather, a pricing engine whose rules move with the market, a tax calculation whose rules move annually by statute — these are facts about the domain’s volatility structure, and they come from the same change-driver analysis that PFD builds its entire design method on. The analysis method is PFD’s; the sheet does not require the book — the question as stated, asked of every rule set and data class and answered by whoever owns the roadmap, produces the row this book needs. They rarely press an axis alone; their power is in combination — volatility meeting a continuity answer is what forces isolation between a paying path and its changing rules, as Part III’s largest case shows at national scale. This is the precise seam where PFD’s central concept feeds this book’s sheet: the design method finds the change drivers; the architecture method prices what they press on.
Both families are analysis output, not elicitation answers, and pretending they are a tenth and eleventh question would misstate where they come from. The sheet has nine questions and a second row source with two kinds of row.
What a filled sheet looks like
The venue’s sheet in Chapter 1 is the miniature. A real one runs a few pages: every answer a number with a scope and a citation to whoever committed to it, UNKNOWNs recorded as UNKNOWNs — an honest UNKNOWN derives a null position and a note, which beats a confident guess deriving machinery — and the domain-shape facts listed per effectful operation. It reads less like a requirements document and more like a term sheet, which is what it is: the business’s commitments, in the only form a derivation can consume.
The sheet also defines what it means to disagree with this book productively. Every dispute about an architecture derived from a sheet is a dispute about a row — a price someone didn’t accept, a scope drawn wrong, a decomposition missed. Arguments about rows terminate. That was the promise of Chapter 1, delivered by structure.
Answers press; something has to receive the pressure. Each axis holds a small set of values, each value provides specific capabilities through a specific mechanism at a specific ongoing cost — and “cheapest value that contains the demand” stays a slogan until those costs are on the table. The next chapter builds the table.
Instruments introduced: the nine-question sheet · driver modes (prune / select / isolate / split / bound) · the membership criterion · the entry gate (priced, scoped, decomposed, triaged, surfaced) · the audit / replay / erasure decomposition · the second row source (domain-shape facts, change-driver facts).