“Only Hyperscalers Need CXL”

"That is a hyperscaler technology" is the last belief in this module and the one with the most truth in it. Large operators did adopt first, they do buy the early parts, and a small installation genuinely cannot get some of them yet. Every observable fact points the same way.

The question this chapter turns on:

Is the problem a ratio or a scale — and what is the break-even node count?

A ratio is the same number in a rack of four and a hall of forty thousand. The mismatch the mechanism addresses is computed from two quantities that are both per machine, and the fleet size appears in neither of them.

1. Who Buys First Is Not Who Benefits

The belief conflates two independent facts, and separating them is most of the work.

Both are real and neither implies the other. Large operators adopt first because they can absorb a failed evaluation and negotiate parts nobody else can get yet — neither of which is "they are the only ones with the problem".

The order of adoption and the distribution of need are different distributions, and the belief reads the first as the second.

2. How To Use This Chapter

Each of the nine dimensions below is a working test of the claim, and every one answers the same seven questions:

The cost row is different in this chapter. The other misconceptions cause something wrong to be built. This one causes nothing to be built — and a decision not taken leaves no evidence, which is why the belief survives without ever being tested.

3. The One-Sentence Model

The mismatch is a ratio computed from two per-machine quantities, stranding needs exactly one machine to exist, the benefit is per node and the fleet multiplies it, and the break-even is one division — so the fleet size decides how much, and never whether.

4. What This Chapter Owns

This chapter closes Module 31 and the CXL curriculum. It is deliberately last, because it is the only misconception in the module that is about the reader rather than about the technology: the other five are held by people describing a mechanism, and this one is held by people deciding whether to look at it.

5. Teaching-Model Boundary And Source Discipline

Every model in this chapter is a teaching model, and each computes a property of a CLAIM rather than of a market.

No model names any company, operator, product or vendor, and no figure is a price. Every number is an illustrative parameter in arbitrary units, and the model headers say so. This is the strictest naming discipline in the module, because a chapter about who needs something is the one where an invented market claim would be most tempting and least defensible.

Nothing in this chapter states a normative detail of any specification. No capacity, density, bandwidth, latency, opcode, layout, field width, encoding, register definition, timing guarantee or specification revision appears anywhere.

And one thing is conceded up front. Section 13 accepts that the supply constraint is real — early parts do go where the volume is. The chapter's argument is that a statement about a queue is not a statement about a need, not that the queue does not exist.

6. Test 1 — Compute The Ratio On One Machine

The claim under test. That the problem is a scale.

What "only" would require. That the mismatch only occurred above some fleet size.

// RTL 1 - the problem is a ratio, and a ratio does not have a size.
//
// The thing the mechanism addresses is a MISMATCH between how much compute a
// machine has and how much memory it has. That mismatch is a RATIO, and a ratio
// is the same number in a rack of four and a hall of forty thousand. "Only
// hyperscalers" is the claim that the problem is a SCALE, and the arithmetic
// says it is not: the ratio is computed from two numbers that are both per
// machine, and the fleet size appears in neither of them.
//
//   BAD  : "it is a big-fleet problem"
//   GOOD : compute the ratio on ONE machine; the fleet multiplies the
//          consequence and does not create it
//
// TEACHING MODEL. Illustrative unit counts. It is not a model of CXL or of any
// platform, contains no capacity, density, bandwidth or figure from any
// specification, and names no company, operator, product or vendor.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero; the ratio is a pure function
//     re-initialise  : not applicable
//     telemetry      : ratio_x10 is per node, which is the granularity the
//                      claim is missing
module ratio_not_scale #(parameter int SCALE_IS_THE_PROBLEM = 0) (
  input  logic clk, rst_n,
  input  logic        assess,
  input  logic [7:0]  compute_units, memory_units, target_ratio_x10, node_count,
  output logic [15:0] ratio_x10,
  output logic [7:0]  n_assessments, n_misdiagnosed,
  output logic        mismatched, reported_mismatched,
  output logic        ratio_err
);
  logic [31:0] r_q;

  // Memory per unit of compute, scaled by ten so one decimal survives integer
  // division. A machine with no compute is reported at the maximum rather than
  // dividing: infinite memory per unit of compute is not a mismatch anybody
  // needs to fix.
  assign r_q = (compute_units == 8'd0) ? 32'd65535
             : (({24'd0, memory_units} * 32'd10) / {24'd0, compute_units});
  // WIDTH INVARIANT. memory_units x 10 reaches 2,550 and the zero-compute
  // branch assigns exactly 65,535, so r_q never exceeds a 16-bit destination
  // and a clamp here would be unreachable. Widening either input needs the
  // clamp added back with a driven case that reaches it.
  assign ratio_x10 = r_q[15:0];

  // The truth: a machine is mismatched when it has less memory per unit of
  // compute than the workload needs. NODE COUNT APPEARS NOWHERE.
  assign mismatched = (ratio_x10 < {8'd0, target_ratio_x10});

  // The whole review point: a reader for whom the fleet size is the diagnosis.
  // Fewer than sixteen nodes, and there is no problem to have.
  assign reported_mismatched = (SCALE_IS_THE_PROBLEM != 0)
                             ? (mismatched && (node_count >= 8'd16))
                             : mismatched;

  // SAFETY-OF-CLAIM VIOLATION: a mismatched machine was reported sound because
  // of how many neighbours it has.
  assign ratio_err = assess && !reported_mismatched && mismatched;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_misdiagnosed <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (ratio_err) n_misdiagnosed <= n_misdiagnosed + 8'd1;
    end
  end
endmodule

The measurement. Forty units of memory over sixteen of compute, on a four-node site:

40 memory over 16 compute on a 4-node site : ratio=2.5 target=4.0 mismatched=1 scale_is_the_problem_says=0

Two point five memory units per unit of compute, against a target of four. The machine is mismatched, and the scale-is-the-problem build dismisses it because it has three neighbours instead of fifteen.

The same machine in a large fleet

The run then drives the identical machine with a node count of 200:

The ratio does not move. It is computed from two per-machine quantities, and the fleet size is in neither of them. The weak build now agrees — and nothing about the machine changed, which is the whole argument in one contrast: the weak build was right the second time on the same inputs it was wrong about the first time.

The run drives the weak build's own boundary too — exactly sixteen nodes, which clears its assumed floor, and fifteen, which does not. A one-node difference changes its diagnosis of an unchanged machine.

Why the belief is reasonable. The consequence really does scale: a mismatch on forty thousand machines is a large number and a mismatch on four is a small one. Scale multiplies the consequence, and it is easy to read a large consequence as the existence of the problem.

What it costs to hold. A mismatched machine described as sound, and a workload that never gets diagnosed because the installation is "too small to have that problem".

What to say instead. "Compute the ratio on one machine. The fleet multiplies the consequence; it does not create it."

Figure 1 — the two site boxes are the only thing that differs, and the ratio box does not read them. That is what "the fleet size is in neither quantity" means, drawn.

7. Test 2 — Measure One Node

The claim under test. That stranding needs a fleet.

What "only" would require. That a single machine could not strand anything.

Stranding is capacity attached to a machine and not used by it. It needs exactly one machine to exist.

// RTL 2 - one machine can strand capacity all by itself.
//
// Stranding is capacity attached to a machine and not used by it. It needs
// exactly one machine to exist. A fleet makes the total larger and does not
// make the phenomenon appear, which means the smallest interesting
// installation is one server with a workload that does not fit its memory
// profile - and every argument about hyperscale is an argument about the
// TOTAL rather than about the mechanism.
//
//   BAD  : "we are too small to strand anything"
//   GOOD : measure one node. If it strands, the fleet strands that times N
//
// TEACHING MODEL. Illustrative byte counts in arbitrary units.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : stranded_here is a PER NODE number, measurable on one
//                      machine with no fleet to compare against
module stranding_at_any_size #(parameter int NEEDS_A_FLEET = 0) (
  input  logic clk, rst_n,
  input  logic        assess,
  input  logic [7:0]  node_attached, node_used, node_count,
  output logic [15:0] stranded_here, fleet_stranded,
  output logic [7:0]  n_assessments, n_dismissed,
  output logic        anything_stranded, reported_stranded,
  output logic        strand_err
);
  logic [7:0]  used_c;
  logic [31:0] f_q;

  assign used_c = (node_used > node_attached) ? node_attached : node_used;
  assign stranded_here = {8'd0, (node_attached - used_c)};

  // The fleet total is the per-node number multiplied by the node count -
  // 255 x 255 = 65,025, which fits a 16-bit destination exactly.
  assign f_q = {16'd0, stranded_here} * {24'd0, node_count};
  // WIDTH INVARIANT. Both operands are 8 bits, so the product reaches
  // 255 x 255 = 65,025 against a 16-bit destination that holds 65,535. The
  // clamp would be unreachable.
  assign fleet_stranded = f_q[15:0];

  // The truth: stranding exists on one node or it does not.
  assign anything_stranded = (stranded_here != 16'd0);

  // The whole review point: a reader who needs a fleet before the phenomenon
  // counts as real.
  assign reported_stranded = (NEEDS_A_FLEET != 0)
                           ? (anything_stranded && (node_count >= 8'd16))
                           : anything_stranded;

  assign strand_err = assess && !reported_stranded && anything_stranded;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_dismissed <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (strand_err) n_dismissed <= n_dismissed + 8'd1;
    end
  end
endmodule

The measurement. A hundred units attached, forty used, on a four-node site:

100 attached, 40 used, 4 nodes : stranded_here=60 fleet=240 needs_a_fleet_says=0

Sixty stranded on one node, 240 across four. The needs-a-fleet build dismisses it, and the run drives a single node — where the per-node figure is unchanged and the fleet total is the same 60.

The smallest interesting installation is one server with a workload that does not fit its memory profile. Every argument about hyperscale is an argument about the total rather than about the mechanism.

The run also drives the boundary at exactly sixteen nodes and at fifteen — the same constant three of this chapter's models use, and driving it in one model does not drive it in another. Section 19 records a survivor that proved exactly that.

Why the belief is reasonable. The total stranded across a large fleet is a headline number, and headline numbers are what get written about.

What it costs to hold. Stranded capacity never measured, because a small site is assumed not to have any — and the measurement is a subtraction on two numbers the site already has.

What to say instead. "Measure one node. If it strands, the fleet strands that times N."

8. Test 3 — The Benefit Is Per Node

The claim under test. That the savings only make sense at scale.

What "only" would require. That scale created the benefit rather than multiplying it.

// RTL 3 - the benefit is computed per node.
//
// Whatever a mechanism saves, it saves on a machine. The fleet total is that
// number multiplied by the count, and multiplication by a large number does not
// bring a benefit into existence - it makes an existing one larger. So the
// question "does this help us" is answered on one machine, and the question
// "how much" is answered by the count.
//
//   BAD  : "the savings only make sense at scale"
//   GOOD : compute the per-node saving. If it is positive, scale is a
//          multiplier; if it is zero, no fleet size rescues it
//
// TEACHING MODEL. Illustrative saving figures in arbitrary units.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : per_node_saving is the figure that decides, and it is
//                      measurable without owning a second machine
module per_node_benefit #(parameter int SCALE_CREATES_THE_BENEFIT = 0) (
  input  logic clk, rst_n,
  input  logic        assess,
  input  logic [7:0]  per_node_saving, node_count,
  output logic [15:0] total_saving,
  output logic [7:0]  n_assessments, n_dismissed,
  output logic        benefit_exists, reported_exists,
  output logic        node_err
);
  logic [31:0] t_q;

  // 255 x 255 = 65,025 fits a 16-bit destination exactly.
  assign t_q = {24'd0, per_node_saving} * {24'd0, node_count};
  // WIDTH INVARIANT. 255 x 255 = 65,025, inside a 16-bit destination.
  assign total_saving = t_q[15:0];

  // The truth: a benefit exists when the per-node saving is positive. The node
  // count is a multiplier and multiplying zero gives zero.
  assign benefit_exists = (per_node_saving != 8'd0);

  // The whole review point: a reader for whom the total is the benefit.
  assign reported_exists = (SCALE_CREATES_THE_BENEFIT != 0)
                         ? (total_saving >= 16'd100) : benefit_exists;

  assign node_err = assess && !reported_exists && benefit_exists;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_dismissed <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (node_err) n_dismissed <= n_dismissed + 8'd1;
    end
  end
endmodule

The measurement. A per-node saving of five on four nodes:

saving 5 per node, 4 nodes : total=20 exists=1 scale_creates_it_says=0

Twenty in total, and a positive per-node saving is a benefit. The scale-creates-it build needs a bigger total and dismisses it.

Zero nodes is the sharpest case

The run drives a positive per-node saving on zero nodes. The fleet total is zero and the per-node benefit is not — which is the chapter's argument as a degenerate input. Reading the benefit off the total erases a real saving at a small enough installation, and a mutation found that gap by removing the distinction from the model rather than from the prose.

And no fleet size rescues a zero per-node saving. The run drives that too: zero times 255 nodes is still zero. Multiplication cannot create a benefit; it can only enlarge one.

Why the belief is reasonable. Business cases are written in totals, because totals are what a budget is denominated in. The per-node figure is an intermediate quantity that nobody publishes.

What it costs to hold. A real per-node saving never computed, because the total it would produce is below somebody's threshold for interest.

What to say instead. "Compute the per-node saving. If it is positive, scale is a multiplier; if it is zero, no fleet size rescues it."

9. Test 4 — Separate Who Buys From Who Benefits

The claim under test. That the early buyers define the market.

What "only" would require. That buying and benefiting were decided by the same thing.

// RTL 4 - who buys first is not who benefits.
//
// Large buyers adopt new platform technology first, and the reasons are
// procurement volume and risk appetite - they can absorb a failed evaluation
// and they can negotiate parts nobody else can get yet. Neither reason is
// "they are the only ones with the problem". Confusing the order of adoption
// with the distribution of need is the whole of this misconception, and the
// two are independent inputs.
//
//   BAD  : "they bought it first, so it is for them"
//   GOOD : separate WHO BUYS FIRST from WHO BENEFITS, and notice they are
//          decided by different things
//
// TEACHING MODEL. Abstract booleans; no company, operator, product, vendor or
// market figure appears.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : buys_first and benefits are published SEPARATELY, which
//                      is the entire fix
module who_buys_first #(parameter int BUYERS_ARE_THE_MARKET = 0) (
  input  logic clk, rst_n,
  input  logic assess,
  input  logic procurement_volume, risk_appetite, has_the_problem,
  output logic [7:0] n_assessments, n_excluded,
  output logic       buys_first, benefits, reported_benefits,
  output logic       adopt_err
);
  // Adoption order is decided by the ability to buy and the willingness to try.
  assign buys_first = procurement_volume && risk_appetite;

  // The truth: benefit is decided by having the problem, and by nothing else.
  assign benefits = has_the_problem;

  // The whole review point: a reader for whom the early buyers define the need.
  assign reported_benefits = (BUYERS_ARE_THE_MARKET != 0) ? buys_first : benefits;

  // SAFETY-OF-CLAIM VIOLATION: somebody with the problem was excluded from the
  // set of people it helps, on the grounds of how they buy.
  assign adopt_err = assess && !reported_benefits && benefits;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_excluded <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (adopt_err) n_excluded <= n_excluded + 8'd1;
    end
  end
endmodule

The measurement. A buyer with no procurement volume, no risk appetite, and the problem:

no volume, no risk appetite, HAS the problem : buys_first=0 benefits=1 buyers_are_the_market_says=0

Not an early adopter, and it has the problem the thing solves. The buyers-are-the-market build excludes it.

The run drives all four combinations, including the mirror case — a large buyer without the problem, where the weak build over-includes rather than excludes. Over-inclusion is a different error and this chapter's counter tracks the exclusion, because exclusion is the one that stops somebody looking.

Four buyers driven, and the weak build excludes three of them.

Why the belief is reasonable. Adoption order is observable and need is not. Everybody can see who bought; nobody publishes who has the problem.

What it costs to hold. An organisation that never evaluates a mechanism that would help it, because the published adopters look nothing like it.

What to say instead. "Adoption order is decided by volume and risk appetite. Benefit is decided by having the problem. Different inputs."

10. Test 5 — Divide, Then Compare

The claim under test. That it is not worth it at our size.

What "only" would require. That the break-even exceeded what smaller installations have.

Adopting the mechanism has a fixed cost and a per-node saving. The number of nodes at which it pays for itself is one division, and the answer is frequently a small number.

// RTL 5 - the break-even node count, which is a division.
//
// Adopting the mechanism has a fixed cost - the component, the control plane,
// the integration - and a per-node saving. The number of nodes at which it pays
// for itself is one division, and the answer is frequently a small number.
// "Only hyperscalers" is a claim that the break-even is enormous, and it is a
// claim anybody can check with two figures they already have.
//
//   BAD  : argue about whether it is worth it at our size
//   GOOD : divide the fixed cost by the per-node saving and compare against
//          the nodes you actually have
//
// TEACHING MODEL. Illustrative cost and saving figures in arbitrary units.
// None is a price, and none is attributed to any product or vendor.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : break_even_nodes is published, so "not at our size" is
//                      a number somebody can disagree with
module break_even_count #(parameter int ASSUME_ENORMOUS = 0) (
  input  logic clk, rst_n,
  input  logic        assess,
  input  logic [7:0]  fixed_cost, per_node_saving, node_count,
  output logic [15:0] break_even_nodes, total_saving,
  output logic [7:0]  n_assessments, n_wrong_calls,
  output logic        worth_it_here, reported_worth_it,
  output logic        even_err
);
  logic [31:0] b_q, t_q;

  // Ceiling division: 7 units of cost against 2 of saving needs 4 nodes, not 3.
  // A zero saving never breaks even, and is reported as the maximum rather
  // than dividing.
  assign b_q = (per_node_saving == 8'd0) ? 32'd65535
             : (({24'd0, fixed_cost} + {24'd0, per_node_saving} - 32'd1)
                / {24'd0, per_node_saving});
  // WIDTH INVARIANT. The ceiling division reaches (255 + 255 - 1) / 1 = 509
  // at worst, and the zero-saving branch assigns exactly 65,535.
  assign break_even_nodes = b_q[15:0];

  assign t_q = {24'd0, per_node_saving} * {24'd0, node_count};
  // WIDTH INVARIANT. 255 x 255 = 65,025, inside a 16-bit destination.
  assign total_saving = t_q[15:0];

  // The truth: it is worth it here when this installation has at least the
  // break-even count.
  assign worth_it_here = ({8'd0, node_count} >= break_even_nodes);

  // The whole review point: a reader who assumes the break-even is out of reach
  // without computing it. Sixteen nodes is the assumed floor.
  assign reported_worth_it = (ASSUME_ENORMOUS != 0) ? (node_count >= 8'd16)
                                                    : worth_it_here;

  // SAFETY-OF-CLAIM VIOLATION: an installation that clears its own break-even
  // was told it is too small.
  assign even_err = assess && !reported_worth_it && worth_it_here;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_wrong_calls <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (even_err) n_wrong_calls <= n_wrong_calls + 8'd1;
    end
  end
endmodule

The measurement. A fixed cost of seven against a per-node saving of two, on a six-node site:

fixed 7, saving 2 per node, 6 nodes : break_even=4 worth_it=1 assume_enormous_says=0

Ceiling division: seven over two is four nodes, not three. Six nodes clears it, and the assume-enormous build says six nodes is too small. An installation past its own break-even, told it is too small.

The run drives both boundaries — exactly at the break-even, which is worth it, and one node short, which is not and where the weak build is right by accident. It also drives an exact division, where no ceiling is needed, and a zero saving, which never breaks even at any fleet size.

"Only hyperscalers" is a claim that the break-even is enormous, and it is a claim anybody can check with two figures they already have.

Why the belief is reasonable. The fixed cost is the part a small installation pays in full, and it is genuinely the part that hurts. The belief is a correct instinct about which term dominates, stated as a conclusion instead of as a division.

What it costs to hold. An argument about size that could have been a division, running for as long as nobody does the division.

What to say instead. "Divide the fixed cost by the per-node saving and compare against the nodes you have. It takes a minute."

11. Test 6 — Does The Working Set Fit?

The claim under test. That installation size decides.

What "only" would require. That the discriminator were the organisation rather than the workload.

What decides whether a machine needs more memory than it has is the WORKING SET of the thing running on it. A four-node installation running an in-memory analytic has the problem; a four-thousand-node installation running stateless request handling does not — and the two examples are the wrong way round from what the misconception predicts.

// RTL 6 - the discriminator is the workload, not the headcount.
//
// What decides whether a machine needs more memory than it has is the
// WORKING SET of the thing running on it. A four-node installation running an
// in-memory analytic has the problem; a four-thousand-node installation running
// stateless request handling does not. The organisation's size does not appear
// in that sentence, and the two examples are the wrong way round from what the
// misconception predicts.
//
//   BAD  : classify by organisation size
//   GOOD : classify by whether the working set fits the memory the node has
//
// TEACHING MODEL. Illustrative working-set and memory figures in arbitrary
// units; no product, configuration or benchmark appears.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : spills is per node and needs no fleet to measure
module workload_not_headcount #(parameter int SIZE_DECIDES = 0) (
  input  logic clk, rst_n,
  input  logic        assess,
  input  logic [7:0]  working_set, node_memory, node_count,
  output logic [15:0] spill_amount,
  output logic [7:0]  n_assessments, n_misclassified,
  output logic        spills, reported_needs_it,
  output logic        work_err
);
  // The truth: a node needs more memory when its working set does not fit.
  assign spill_amount = (working_set > node_memory)
                      ? {8'd0, (working_set - node_memory)} : 16'd0;
  assign spills = (spill_amount != 16'd0);

  // The whole review point: a reader who classifies by installation size.
  assign reported_needs_it = (SIZE_DECIDES != 0) ? (node_count >= 8'd16) : spills;

  // SAFETY-OF-CLAIM VIOLATION: a node whose workload does not fit was
  // classified as not needing anything, because of how many nodes it has.
  assign work_err = assess && !reported_needs_it && spills;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_misclassified <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (work_err) n_misclassified <= n_misclassified + 8'd1;
    end
  end
endmodule

The measurement. A working set of ninety against sixty-four of memory:

working set 90, node memory 64, 4 nodes : spill=26 spills=1 size_decides_says=0

Twenty-six units spill, and the size-decides build dismisses the node for having three neighbours.

The run drives the mirror — a working set of 32 in 64 of memory on a 200-node site, which does not need more and which the weak build says does. Both errors are present and they point in opposite directions, which is what a classification by the wrong variable produces.

The run drives both sides of the fit boundary too: a working set exactly equal to the memory spills nothing, and one unit over spills exactly one.

Why the belief is reasonable. Workload profiles are not published and organisation sizes are. Classifying by the visible variable is a reasonable heuristic that happens to be uncorrelated with the answer.

What it costs to hold. A spilling workload never profiled, because the installation it runs on is the wrong size to have that problem.

What to say instead. "Does the working set fit the memory the node has? The organisation's size is not in that sentence."

12. Test 7 — The Verdict Has A Date On It

The claim under test. That the economics do not work for us.

What "only" would require. That the fixed cost were permanent.

The break-even is a ratio of a FIXED cost to a VARIABLE saving. The fixed part is integration, qualification and the component itself, and it is the part a small installation pays in full. It is also the part that falls as a technology becomes ordinary — so the break-even node count is not a constant, it is a number that moves.

// RTL 7 - the fixed cost is the thing that scales badly, and it falls.
//
// The break-even count of section 5 is a ratio of a FIXED cost to a VARIABLE
// saving. The fixed part is integration, qualification and the component
// itself, and it is the part that a small installation pays in full. It is also
// the part that falls as a technology becomes ordinary - so the break-even node
// count is not a constant, it is a number that moves, and "not at our size" is
// a statement with a date on it.
//
//   BAD  : "the economics do not work for us"
//   GOOD : say which year, and say what the fixed cost would have to fall to
//
// TEACHING MODEL. Illustrative cost figures in arbitrary units. None is a
// price and none is attributed to any product, vendor or year.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : payback_nodes at two fixed costs, which is what turns a
//                      verdict into a forecast
module cost_floor #(parameter int FIXED_COST_IS_FOREVER = 0) (
  input  logic clk, rst_n,
  input  logic        assess,
  input  logic [7:0]  mechanism_cost, future_cost, variable_saving, node_count,
  output logic [15:0] payback_nodes, future_payback,
  output logic [7:0]  n_assessments, n_static_calls,
  output logic        reachable_later, reported_reachable,
  output logic        floor_err
);
  logic [31:0] p_q, f_q;

  // Ceiling division again, and a zero saving never pays back.
  assign p_q = (variable_saving == 8'd0) ? 32'd65535
             : (({24'd0, mechanism_cost} + {24'd0, variable_saving} - 32'd1)
                / {24'd0, variable_saving});
  // WIDTH INVARIANT. The ceiling division reaches 509 at worst, and the
  // zero-saving branch assigns exactly 65,535.
  assign payback_nodes = p_q[15:0];

  assign f_q = (variable_saving == 8'd0) ? 32'd65535
             : (({24'd0, future_cost} + {24'd0, variable_saving} - 32'd1)
                / {24'd0, variable_saving});
  assign future_payback = f_q[15:0];

  // The truth: this installation reaches the break-even at the FUTURE cost even
  // if it does not reach it today.
  assign reachable_later = ({8'd0, node_count} >= future_payback);

  // The whole review point: a reader who treats today's fixed cost as permanent
  // and therefore never revisits the verdict.
  assign reported_reachable = (FIXED_COST_IS_FOREVER != 0)
                            ? ({8'd0, node_count} >= payback_nodes)
                            : reachable_later;

  assign floor_err = assess && !reported_reachable && reachable_later;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_static_calls <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (floor_err) n_static_calls <= n_static_calls + 8'd1;
    end
  end
endmodule

The measurement. A cost of twenty today and nine later, against a per-node saving of three, on a six-node site:

cost 20 now / 9 later, saving 3, 6 nodes : payback_now=7 payback_later=3 fixed_forever_says=0

Seven nodes today and three at the future cost. A six-node site misses today and clears later — and the fixed-cost-is-forever build reports it permanently out of reach, so the verdict is never revisited.

"Not at our size" is a statement with a date on it, and the belief's damage is that the date is never written down.

Why the belief is reasonable. The verdict is correct today, and being correct today is what a verdict is usually asked to be.

What it costs to hold. A correct verdict that outlives its correctness by years, because nothing in it carries an expiry.

What to say instead. "Say which year, and say what the fixed cost would have to fall to."

13. Test 8 — Can We Get It, Or Would It Help?

The claim under test. That being unable to get it means not needing it.

What "only" would require. That supply and need were the same question.

Part of the misconception is simply true about SUPPLY. Early parts go where the volume is, and a small buyer genuinely cannot get them yet. That is a statement about a queue, and it changes.

// RTL 8 - availability is a supply fact, not a need fact.
//
// Some of the misconception is simply true about SUPPLY: early parts go where
// the volume is, and a small buyer genuinely cannot get them yet. That is a
// statement about a queue, and it changes. Reading it as a statement about need
// makes a temporary supply condition into a permanent architectural belief, and
// the belief outlives the condition by years.
//
//   BAD  : "we cannot get it, so it is not for us"
//   GOOD : separate can-we-get-it from would-it-help, and put a review date on
//          the first one
//
// TEACHING MODEL. Abstract availability flags; no product, vendor, supply chain
// or market claim appears.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : available_here and needed_here are published
//                      SEPARATELY, so a supply verdict cannot be read as a
//                      need verdict
module availability_argument #(parameter int UNAVAILABLE_MEANS_UNNEEDED = 0) (
  input  logic clk, rst_n,
  input  logic assess,
  input  logic available_here, needed_here,
  output logic [7:0] n_assessments, n_conflated,
  output logic       supply_limited, reported_needed,
  output logic       avail_err
);
  // The state the two readings disagree about, published on its own: the thing
  // would help and cannot be had yet.
  assign supply_limited = needed_here && !available_here;

  // The whole review point: a reader for whom a supply answer settles a need
  // question.
  assign reported_needed = (UNAVAILABLE_MEANS_UNNEEDED != 0) ? available_here
                                                             : needed_here;

  // SAFETY-OF-CLAIM VIOLATION: a real need was recorded as absent because of a
  // temporary supply condition.
  assign avail_err = assess && !reported_needed && needed_here;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_conflated <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (avail_err) n_conflated <= n_conflated + 8'd1;
    end
  end
endmodule

The measurement. Needed here and not available yet:

needed here, not available yet : supply_limited=1 unavailable_means_unneeded_says=0

The supply-limited state has its own name, and publishing it is the fix: a real need recorded as absent because of a temporary condition is a need that nobody revisits when the condition lifts.

The run drives all four combinations. The two readings agree on three of them and disagree on exactly one — which is why this is the part of the belief that survives longest.

Reading a supply fact as a need fact makes a temporary condition into a permanent architectural belief, and the belief outlives the condition by years.

Why the belief is reasonable. It is true, as a supply statement, at the moment it is made. This is the one test in the chapter where the misconception's premise is not merely true but directly relevant — and it is still the wrong question.

What it costs to hold. A need deleted from the register rather than deferred in it.

What to say instead. "Separate can-we-get-it from would-it-help, and put a review date on the first one."

14. Test 9 — Write Down What Would Have To Be True

The claim under test. All of them, at once.

What "only" would require. Four conditions, and all four.

// RTL 9 - what would have to be true for "only hyperscalers" to hold?
//
// Same discipline, sixth chapter running. Four conditions: the mismatch ratio
// only occurs above some fleet size, a single node cannot strand anything, the
// break-even node count exceeds what smaller installations have, and the
// benefit is created by scale rather than multiplied by it.
//
// TEACHING MODEL. Four illustrative booleans.
//
//   INITIALIZATION CONTRACT (combinational + counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : met_pct beside the conjunction
module only_hyperscaler_conditions #(parameter int MOSTLY_TRUE = 0) (
  input  logic clk, rst_n,
  input  logic       assess,
  input  logic       ratio_needs_scale, one_node_cannot_strand,
  input  logic       break_even_out_of_reach, scale_creates_benefit,
  output logic [7:0] conditions_met, n_assessments, n_overclaims,
  output logic [15:0] met_pct,
  output logic       would_hold, claimed_holds,
  output logic       only_err
);
  logic [31:0] m_q;
  assign conditions_met = {7'd0, ratio_needs_scale} + {7'd0, one_node_cannot_strand}
                        + {7'd0, break_even_out_of_reach} + {7'd0, scale_creates_benefit};
  // No clamp: four one-bit values over four cannot exceed a hundred.
  assign m_q = ({24'd0, conditions_met} * 32'd100) / 32'd4;
  assign met_pct = m_q[15:0];
  assign would_hold = (conditions_met == 8'd4);
  assign claimed_holds = (MOSTLY_TRUE != 0) ? (conditions_met >= 8'd3) : would_hold;
  assign only_err = assess && claimed_holds && !would_hold;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_overclaims <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (only_err) n_overclaims <= n_overclaims + 8'd1;
    end
  end
endmodule

The measurement. Three of four met:

3 of 4 conditions : met=75% would_hold=0 mostly_true_says=1

Seventy-five percent, and a conjunction has no partial credit. The fourth condition is arithmetically impossible — a zero per-node saving multiplied by any fleet size is zero — which means the claim fails by construction.

What to say instead. "Here are the four things that would have to be true. The fourth one cannot be true of any multiplication."

15. The Misconception Assembled

Nine tests, one summary.

// RTL 10 - the misconception examined. Nine tests, one summary.
// "The largest operators adopted it first" is bit 0: a true statement about a
// procurement queue, and one sixth of an argument about who needs something.
module scale_review_signoff #(parameter int EARLY_BUYERS_ARE_PROOF = 0) (
  input  logic clk, rst_n,
  input  logic        review,
  input  logic        large_buyers_first, ratio_computed, stranding_measured,
  input  logic        break_even_computed, workload_profiled, conditions_checked,
  output logic [5:0]  fail_mask,
  output logic [15:0] conditions_met, sound_pct,
  output logic        sound,
  output logic [7:0]  n_reviews, n_sound, n_claimed,
  output logic        mis_err
);
  logic [31:0] s_q;
  logic        truly_sound, claimed;
  assign fail_mask[0] = ~large_buyers_first;
  assign fail_mask[1] = ~ratio_computed;
  assign fail_mask[2] = ~stranding_measured;
  assign fail_mask[3] = ~break_even_computed;
  assign fail_mask[4] = ~workload_profiled;
  assign fail_mask[5] = ~conditions_checked;
  assign conditions_met = {15'd0, large_buyers_first} + {15'd0, ratio_computed}
                        + {15'd0, stranding_measured} + {15'd0, break_even_computed}
                        + {15'd0, workload_profiled} + {15'd0, conditions_checked};
  assign s_q = ({16'd0, conditions_met} * 32'd100) / 32'd6;
  // No clamp: six one-bit values over six cannot exceed a hundred.
  assign sound_pct = s_q[15:0];
  assign truly_sound = (fail_mask == 6'd0);
  assign claimed = (EARLY_BUYERS_ARE_PROOF != 0) ? large_buyers_first : truly_sound;
  assign sound = claimed;
  assign mis_err = review && !truly_sound && claimed;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_reviews <= 8'd0; n_sound <= 8'd0; n_claimed <= 8'd0;
    end else if (review) begin
      n_reviews <= n_reviews + 8'd1;
      if (truly_sound) n_sound <= n_sound + 8'd1;
      if (claimed)     n_claimed <= n_claimed + 8'd1;
    end
  end
endmodule

The measurement. Two views of the same argument:

the break-even was never computed : mask=001000 met=5 sound=83%
the largest operators adopted it first : mask=111110 met=1 sound=16%

The first line is a serious assessment with one thing missing — bit 3, the break-even was never computed. Five of six, and the missing step is one division.

The second line is the misconception. Bit 0 is clear — the largest operators did adopt first — and nothing else was done. Sixteen percent of an argument, from a true statement about a procurement queue.

Figure 3 — bit 0 is a fact about a procurement queue, and the other five are facts about a machine. All five of the others are measurable on one node, which is what makes this the cheapest sign-off in the module to complete.

16. Quantitative Reasoning

Every figure here is a teaching parameter or a value derived from one and asserted by the testbench. None is a price, none is a capacity, and none is attributed to any company, operator, product or vendor.

The ratio, derived. Forty memory units over sixteen compute units is 40 × 10 / 16 = 25, which is 2.5 with one decimal preserved by the scaling, against a target of 4.0. Both inputs are per machine and the node count is in neither. The general form: ratio = memory per unit of compute, and a ratio is dimensionless in fleet size.

The same machine at two scales. Four nodes and two hundred nodes, identical machine, ratio 2.5 in both. The weak build's verdict changes and the machine does not, which is the argument as a controlled experiment: one variable moved and it was the wrong one.

The weak build's boundary. Its assumed floor is sixteen nodes, driven at exactly 16 (clears) and 15 (does not). A one-node difference changes the diagnosis of an unchanged machine — and the same constant appears in three of this chapter's models, which section 19 records as a survivor the stimulus missed in one of them.

Stranding, derived. A hundred attached with forty used strands 100 − 40 = 60 on one node. Four nodes strand 60 × 4 = 240; one node strands 60. The per-node figure is identical and the total is not, which is the whole distinction between a mechanism and a headline.

The width corner. 255 units stranded on 255 nodes is 65,025 — the largest product two 8-bit operands can make — and the destination is 16 bits, which holds 65,535. The case is driven and asserted, and section 18 records why the clamp that used to guard it was deleted.

The benefit, derived. Five per node on four nodes is 20; on forty nodes, 200. The per-node figure is unchanged and the total is not. On zero nodes the total is 0 and the per-node benefit is still five — a positive saving with a zero total, and the degenerate input a mutation used to find the gap. And zero per node on 255 nodes is 0: multiplication cannot create a benefit.

Adoption against benefit. Two independent inputs per buyer, four combinations. The weak build excludes three of four — everyone who is not a large-volume, risk-tolerant buyer — and over-includes on the fourth. Two errors in opposite directions, from one substitution of variables.

The break-even, derived. Ceiling division: (7 + 2 − 1) / 2 = 4 nodes, not three. Six nodes clears it; four exactly clears it; three does not. An exact division needs no ceiling: (8 + 2 − 1) / 2 = 4 as well. A zero saving never breaks even at any fleet size. The general form is ceil(fixed / per-node), and it is one division on two numbers anybody has.

The working set, derived. Ninety against sixty-four spills 90 − 64 = 26. Exactly 64 spills 0; 65 spills 1. The organisation's size is in none of those three numbers.

The moving verdict, derived. ceil(20/3) = 7 nodes today; ceil(9/3) = 3 at the future cost. A six-node site misses today by one and clears the future break-even by three, and the difference between those two statements is a date.

Conditions, derived. Four conditions with three met is 3 × 100 / 4 = 75 percent, and the fourth is arithmetically impossible: a zero per-node saving multiplied by any fleet size is zero, so scale creates the benefit cannot be true of a multiplication.

The sign-off arithmetic. Six conditions; five met is 5 × 100 / 6 = 83 percent under integer division, and one met is 100 / 6 = 16 percent.

17. Verification Method

Order of work

names.txt → ten models, each compiled alone → model-expressiveness review → boolean-tautology review → width review → structural gates → testbench → legal baseline → PASS → mutation campaign → re-baseline after every change → MDX assembled from the verified sources

The width review found seven defects on this chapter before a single cycle was simulated, which is recorded in section 18 and is the batch's clearest demonstration that the pre-simulation reviews are cheaper than the campaign.

Independent oracles

chkv prints got against expected, which is what lets an oracle be wrong out loud. In this chapter it caught none — the first chapter in the batch with no wrong oracle at all, including the two ceiling divisions and the 65,025 width corner.

X and Z rejected explicitly

chk(c, …) tests c !== 1'b1, so an X-valued condition fails rather than passing. chkv(got, exp, …) reduces the result and reports an explicit X/Z failure before comparing. The scripted output-connectivity gate returns zero on all ten models.

Pulses are latched, never sampled

Every evidence output — ratio_err, strand_err, node_err, adopt_err, even_err, work_err, floor_err, avail_err, only_err, mis_err — is caught by a continuous always @(posedge clk) monitor into a sticky bit, asserted outside any conditional, in a window containing a clock edge.

Stimulus never lands on the active edge, and reset is released after it

step_clk is @(posedge clk); #1;, and reset release lands one delta after the edge.

Every model here is combinational, and that is stated rather than assumed

All ten models are combinational scoring plus two registered counters each. No model carries sequential state beyond its counters, and each header says so explicitly in its initialisation contract: power-on zero, no initialising event, re-initialisation not applicable.

That is a fact worth publishing rather than leaving implicit, because it is the reason this chapter had no wrong oracle: every wrong oracle in batches 030 to 032 was a timing relationship, and a model with no timing relationships produces none.

Both builds are always instantiated

Every model has both its counting build and its shortcut build wired to the same stimulus, and the testbench asserts the internal figures on both. In every one of the ten the shortcut build computes the honest figure internally — the ratio, the stranding, the total, the break-even, the spill — and reports a different verdict from it.

That is stronger than in any other chapter in the batch, and it is deliberate: the chapter's claim is that the weak build is looking at the right numbers and applying the wrong test.

Safety, liveness and performance kept apart

Safety-of-claim is this chapter's safety class. A mismatched machine is never reported sound. Real stranding is never dismissed. A real per-node saving is never erased by an empty fleet. A buyer with the problem is never excluded from the set the thing helps. None requires an assumption.

Liveness — nothing in this chapter is a liveness claim.

Performance — nothing here is a performance claim. Every figure is a ratio, a count or a break-even, and none is a rate.

18. Baseline Defects Found Before Mutation

RTL defects — seven unreachable clamps, found by the WIDTH review

The §14 width review was run over all ten models before the testbench existed, and it found seven clamps whose true branch has no reachable input.

Every destination below is 16 bits wide, which holds 65,535.

All seven were deleted and the invariant written into the source, with the precondition that widening an operand invalidates it and needs the clamp back with a driven case that reaches it.

This is the finding worth keeping from the whole batch. In 31.3 and 31.5 the same shape was found by the mutation campaign, one clamp at a time, after the models were written and the testbenches built. Here it was found by computing the maximum of each expression before a single cycle was simulated — which is cheaper, catches all of them at once, and is exactly what §14 asks for: do not depend on compiler warnings; reason about operand width, expression width and destination width explicitly.

domcheck reported zero on all ten models while all seven were present, for the reason it has reported zero on every dead clamp in this batch: the unreachability comes from operand width, which is outside its model.

Testbench defects — none. Wrong oracles — none.

The first chapter in the batch with no wrong oracle at all. Every expected value — including both ceiling divisions, the 65,025 width corners and the sixteen-node boundaries — was correct on the first run, and section 17 records why: these models have no timing relationships, and every wrong oracle in three batches was a timing relationship.

Coverage gaps found by the structural gates

Second chapter in a row where every structural gate returned zero on the first run, and for the same reason as 31.5: the pre-simulation reviews had already removed what the gates would have found.

Compiler-warning findings

Under -Wall the ten models produce no truncation, select-width, signedness, cast, multiplication-width, shift-width or loop-width warnings — and that silence covered seven unreachable clamps, which is the point. A warning-free compile says nothing about whether an expression can reach the value its guard is checking for.

Six width results were reasoned rather than trusted.

• memory_units × 10 reaches 2,550; stranded_here × node_count and per_node_saving × node_count reach 65,025, the largest product two 8-bit operands can make, inside a 16-bit destination by 510.
• The two ceiling divisions (cost + saving − 1) / saving reach 509 at worst, and both are guarded against a zero denominator by an explicit branch rather than by a clamp — the branch is reachable and the campaign kills the mutation that flips it.
• node_attached − used_c cannot underflow, because the subtrahend is clamped to the minuend; working_set − node_memory cannot, because the subtraction is guarded by working_set > node_memory. Both protections are load-bearing and both corresponding mutations are killed.
• conditions_met × 100 / 4 and / 6 cannot exceed 100: a sum of one-bit values over its own denominator.

Simulator constraints

Icarus Verilog 13.0 rejects ref task arguments, carried forward.

19. Mutation Testing

74 mutations attempted, 74 non-equivalent, 74 killed. Zero unexplained survivors, zero equivalents withdrawn.

Two survivors on the first run, and both are the boundary family. Eight further mutations were added afterwards — three each to the per-node-benefit and break-even models and two to the conditions model, which were the thinnest three in the chapter — and closing them needed three new boundary cases: the smallest saving that exists at all, a fleet total sitting exactly on the weak build's threshold, and a site one node below its assumed floor. All eight died. The two boundary constants the first campaign had reached by accident are now reached on purpose.

A boundary driven in one model is not driven in another

The weak build in three of this chapter's models uses the same assumed floor of sixteen nodes. The boundary was driven exactly in the ratio model — where the campaign killed the corresponding mutation — and not in the stranding model, where the identical constant appears.

A boundary driven in one model is not driven in another, however similar they look. That is the 29.2 symmetric-clamp lesson in a new shape: two models that share a constant still need the case twice.

The other was the chapter's own argument as a degenerate input

The mutation replaced "the per-node saving is positive" with "the fleet total is positive". The separating input is a positive per-node saving on zero nodes, and it was never driven.

Reading the benefit off the total therefore erases a real per-node saving at a small enough installation — which is precisely the error the chapter is written to refute, and the campaign found it by removing the distinction from the model rather than from the prose.

Driving it is one line, and the case became the sharpest assertion in section 8.

The classification rule

Never add an assertion for a survivor before classifying it.

20. Synthesis And Implementation Reality

These models are not meant to be synthesised. What follows is the honest reading of what the instrumentation this chapter asks for would cost, because every one of its nine tests is answered by a register somebody could publish and mostly does not.

The ratio is two counters and a divider. Memory units and compute units are numbers a platform already knows at configuration time, which makes the ratio a design-time constant published in a register rather than a runtime measurement. Cost: two registers.

Stranded bytes per node is one subtraction. Attached and used are both already known — one at configuration and one from the memory subsystem — so the stranded figure is a subtraction on two numbers a node already reports. It is the cheapest number in this chapter and the one most often absent.

The break-even is a division nobody has to implement. Fixed cost and per-node saving are planning inputs, not hardware quantities. The only thing hardware has to publish is the node count, and everything else is arithmetic on a page.

The spill amount is a counter on a path that already exists. A memory subsystem that can tell you it is full can tell you by how much, and the spill figure is the difference between a workload profile and a guess.

The per-direction and per-region telemetry from the rest of this module applies here unchanged, which is the point of putting this chapter last: every number the other five chapters asked for is a number this one uses to answer a business question.

A divider is the only structure of any size, and the same conclusion applies as everywhere else in the module: publish the numerator and the denominator and let the reader divide. "Forty memory units over sixteen compute units" is exact; "2.5" has already chosen the scaling.

No area, frequency or power figures appear in this chapter, because none was measured.

21. Silicon Observability

The second row is the one that ends the argument. Stranded bytes per node is a subtraction on two numbers every node already has, and it is measurable on a single machine with no fleet to compare against — which is exactly the claim the misconception denies.

Publish counts, not percentages — the same conclusion 30.5 reached about denominators, and the last time this module makes it. "100 attached, 40 used" is exact and lets a reader compute any ratio they want; "60 percent utilised" has already chosen one.

One pattern is worth reading for. A small installation with no stranding telemetry at all is indistinguishable from a small installation with no stranding — and the belief this chapter refutes is what stops anybody adding the counter that would tell them apart.

22. DebugLabs

These labs debug decisions not taken. The symptom is always an absence — a measurement nobody made, an evaluation nobody ran, a verdict nobody revisited — which is what makes this chapter's failures the hardest in the module to notice.

Lab 1 — A mismatched machine was described as sound

Symptom. A workload underperforms on a small installation. The platform assessment records no issue.

Evidence. The assessment gated its findings on fleet size. The machine's memory-to-compute ratio is well below the workload's target.

Hypothesis. A per-machine quantity was assessed with a fleet-level filter.

Investigation. Compute the ratio on one machine. It is 2.5 against a target of 4.0, and the node count appears in neither input.

Root cause. Scale multiplies the consequence and does not create the problem, and the assessment read a small consequence as the absence of a problem.

Fix. Assess the ratio per machine, and use the fleet size only to size the consequence.

Prevention. Compute the ratio on one machine. If the fleet size is not in either input, it does not belong in the verdict.

Observability. Memory units and compute units as two published numbers. The ratio becomes a query.

Lab 2 — Stranded capacity was never measured

Symptom. A four-node installation buys capacity to relieve a shortfall. A later survey finds substantial idle memory on two of the four nodes.

Evidence. No node publishes a stranded figure. The site was assumed too small to strand anything.

Hypothesis. A per-node phenomenon was assumed to need a fleet.

Investigation. Compute attached minus used, per node. Sixty units on one of them.

Root cause. Stranding needs exactly one machine to exist, and nobody measured because of a belief about the total.

Fix. Publish attached and used per node, and compute the difference.

Prevention. Measure one node. The subtraction is on two numbers the node already reports.

Observability. Stranded bytes per node. The cheapest number in this chapter and the one most often absent.

Lab 3 — A real saving was never computed

Symptom. A mechanism is dismissed in a business case. Two years later the same case is made successfully with the same per-node figures and a larger fleet.

Evidence. The original case computed only the total. The total was below a threshold for interest.

Hypothesis. The benefit was read off the total rather than the per-node figure.

Investigation. Compute the per-node saving. It was positive both times and identical.

Root cause. Scale multiplied a benefit that already existed, and the original case could not see it because it was denominated in totals.

Fix. Publish the per-node figure in every business case, beside the total.

Prevention. If the per-node saving is positive, scale is a multiplier; if it is zero, no fleet size rescues it.

Observability. None — this is a process artefact. Its output is a per-node line in the case.

Lab 4 — An organisation never evaluated something that would have helped it

Symptom. An organisation with a clear instance of the problem has never evaluated the mechanism. Nobody can say why.

Evidence. The published adopters look nothing like the organisation.

Hypothesis. Adoption order was read as the distribution of need.

Investigation. Separate the two questions. The organisation does not buy first — no volume, no appetite for a failed evaluation — and it does have the problem.

Root cause. Adoption order is decided by procurement volume and risk appetite; benefit is decided by having the problem. Different inputs, and only the first is observable.

Fix. Evaluate against the problem, not against the adopter list.

Prevention. Ask who benefits, separately from who bought. The second question has a public answer and the first one does not.

Observability. None — process. The artefact is a problem statement rather than a peer list.

Lab 5 — An argument about size ran for a year and was a division

Symptom. Two groups disagree about whether a mechanism is worth adopting. The argument does not converge.

Evidence. Neither side has computed the break-even node count.

Hypothesis. A claim about magnitude is being argued instead of computed.

Investigation. Divide the fixed cost by the per-node saving. Ceiling division gives four nodes; the site has six.

Root cause. "Only hyperscalers" is a claim that the break-even is enormous, and it was never checked against two figures both sides already had.

Fix. The division, in the first meeting.

Prevention. Divide, then compare. It converts an argument into arithmetic and takes a minute.

Observability. The node count is the only hardware input. Everything else is arithmetic on a page.

Lab 6 — A spilling workload was never profiled

Symptom. A workload performs poorly on a four-node site and well on a large one running different software.

Evidence. The classification in use is by installation size. No working-set profile exists for either.

Hypothesis. The classification variable is uncorrelated with the answer.

Investigation. Profile both. The small site's working set exceeds its node memory by 26 units; the large site's fits with room to spare.

Root cause. The discriminator is the working set, not the headcount — and the two examples are the wrong way round from what the classification predicts.

Fix. Classify by profile, and keep a working-set high-water mark per node.

Prevention. Does the working set fit the memory the node has? The organisation's size is not in that sentence.

Observability. Spill amount and working-set high-water mark, per node.

Lab 7 — A correct verdict outlived its correctness

Symptom. A mechanism dismissed three years ago on cost grounds is still dismissed, and the fixed cost has fallen substantially.

Evidence. The verdict was recorded without a date and without the cost it assumed.

Hypothesis. A moving number was treated as a constant.

Investigation. Recompute the break-even at today's fixed cost. It has fallen from seven nodes to three, and the site has six.

Root cause. The break-even is a ratio of a fixed cost to a variable saving, and the fixed part falls as a technology becomes ordinary. The verdict was correct when it was made.

Fix. Re-record the verdict with the cost it assumed and a review date.

Prevention. Say which year, and say what the fixed cost would have to fall to. A verdict with no expiry never gets one.

Observability. None — process. The artefact is a decision log with an assumed-cost column.

Lab 8 — A need was deleted rather than deferred

Symptom. A capability that would help is absent from the requirements register entirely. Nobody recalls discussing it.

Evidence. It was unavailable at the time the register was written, and the entry was removed rather than marked pending.

Hypothesis. A supply answer settled a need question.

Investigation. Separate the two fields. The need was real then and is real now; the supply constraint has lifted.

Root cause. Reading a statement about a queue as a statement about a need, which makes a temporary condition into a permanent belief.

Fix. Two fields: would-it-help, and can-we-get-it — with a review date on the second.

Prevention. Separate can-we-get-it from would-it-help. The first one changes and the second one does not.

Observability. A capability-present bit beside a capability-used bit, which is 31.2 section 11's telemetry answering a procurement question.

23. Coverage Reasoning

Coverage of a decision has a failure mode the other chapters' coverage does not: a decision not taken leaves no record, so the uncovered cells are invisible rather than merely empty.

Four coverage models are worth keeping:

Scale-invariance coverage. The same machine assessed at several node counts, including one. The cell that matters is a single node, and an assessment process that never looks at one machine fills it never.

Boundary coverage per constant, per model. This chapter's weak builds share a sixteen-node floor across three models, and driving the boundary in one of them does not drive it in the others. Section 19 records the survivor that proved it.

Degenerate-input coverage. A bin for zero on every count: zero nodes, zero saving, zero stranding, zero working set. This chapter's second survivor lived in the zero-node cell, and it is the cell where a total and a per-node figure disagree most sharply.

Adoption-versus-need coverage. Buys-first crossed with benefits, four cells. Two of the four are where the two questions disagree, and a process that reads a peer list fills neither.

The bin the shortcut build cannot hit is the most valuable bin in any model. In section 6 it is "mismatched on a four-node site". In section 8 it is "a positive saving with a zero total". In section 9 it is "benefits and does not buy first". Each is unreachable in the shortcut build and trivial in the counting one.

24. How This Appears In Real Engineering

Adoption order is published and need is not. Everybody can see who bought; nobody publishes who has the problem, so the visible variable becomes the classifier.

Business cases are denominated in totals, because budgets are, and the per-node figure is an intermediate quantity that never reaches the page.

Small installations do not instrument what they are told they do not have. The stranded counter is absent because the belief says there is nothing to count, and its absence is then evidence for the belief.

Workload profiles are expensive to produce and organisation sizes are free, so the free variable is the one that gets used.

Verdicts are recorded without their assumptions. "Not at our size" survives because nothing in it says which size, which year, or which cost.

Supply constraints are real and are recorded as need constraints, because a requirements register has one column and the distinction needs two.

And the failure leaves no trace. The other five misconceptions in this module produce something wrong that somebody eventually debugs. This one produces nothing — no evaluation, no measurement, no decision — and there is no incident report for a question nobody asked.

25. Where The Misconception Comes From

More of this belief is true than of any other in the module. Large operators did adopt first. They do buy the early parts. A small buyer genuinely cannot get some of them yet. Every check a reasonable person would run comes back confirming it.

The consequence really does scale. A mismatch across forty thousand machines is a large number and across four is a small one, and reading a large consequence as the existence of a problem is one inference away from correct.

The fixed cost genuinely dominates at small scale. The belief is a correct instinct about which term dominates, stated as a conclusion instead of as a division — which is why the people who hold it are usually the ones who have thought about cost most carefully.

The supply constraint is real and it expires silently. Nobody sends a notification when a part becomes generally available, so a verdict formed during the constraint has no trigger to be revisited.

And the belief is self-sealing. It prevents the measurement that would test it: a small site with no stranding telemetry is indistinguishable from a small site with no stranding, and the belief is what stops the counter being added.

26. Common Misconceptions

"That is a hyperscaler technology." The problem is a ratio, and a ratio is the same number in a rack of four and a hall of forty thousand.

"It is a big-fleet problem." Compute the ratio on one machine. The fleet size is in neither input.

"We are too small to strand anything." Stranding needs exactly one machine to exist. Measure one node.

"The savings only make sense at scale." Compute the per-node saving. Scale multiplies a benefit; it cannot create one.

"They bought it first, so it is for them." Adoption order is decided by volume and risk appetite. Benefit is decided by having the problem.

"It is not worth it at our size." Divide the fixed cost by the per-node saving. The answer is frequently a small number.

"We are not the kind of organisation that needs this." The discriminator is the working set, not the headcount. Does it fit?

"The economics do not work for us." Say which year. The fixed cost falls and the break-even moves with it.

"We cannot get it, so it is not for us." That is a statement about a queue. Put a review date on it.

"Most of the conditions hold." A conjunction has no partial credit, and the fourth condition is arithmetically impossible.

"The largest operators adopted it first." That is bit 0, and it is worth one sixth of an argument about who needs something.

27. Interview And Design-Review Questions

Ratio and scale

1. Is the problem a ratio or a scale? A ratio — memory per unit of compute — and both quantities are per machine, so the fleet size appears in neither.

2. What does the fleet size change? The consequence, not the problem. It multiplies an existing mismatch and cannot create one.

3. Forty memory units over sixteen compute units. What is the ratio? 2.5 memory units per unit of compute, and against a target of 4.0 the machine is mismatched.

4. The identical machine moves from a four-node site to a two-hundred-node site. What changes? Nothing about the machine, and nothing about the ratio. A verdict that changes is a verdict reading the wrong variable.

5. Why is that a controlled experiment rather than an argument? Because exactly one variable moved and it was not one of the two the ratio is computed from.

6. Why is the belief one inference away from correct? Because the consequence genuinely scales. Reading a large consequence as the existence of a problem is a single step, and it is the wrong one.

Stranding and benefit

7. What is the minimum installation that can strand capacity? One machine. Stranding is capacity attached to a machine and not used by it.

8. A hundred attached, forty used, four nodes. Give the two figures. Sixty stranded per node and 240 across the fleet. The first is the mechanism and the second is the headline.

9. Why is the per-node figure the one that decides? Because it is what a mechanism acts on. A fleet total tells you how much is at stake and nothing about whether anything can be done.

10. Five units of saving per node on four nodes. Is that a benefit? Yes — twenty in total and five per node, and a positive per-node saving is a benefit whatever the total is.

11. The same five per node on zero nodes. Now what? The total is zero and the per-node benefit is still five. Reading the benefit off the total erases a real saving at a small enough installation.

12. Zero saving per node on 255 nodes? Zero. Multiplication cannot create a benefit; it can only enlarge one.

13. Why are business cases written in totals? Because budgets are denominated in totals, and the per-node figure is an intermediate quantity that never reaches the page.

Adoption, break-even and workload

14. Name the two things that decide who buys first. Procurement volume and risk appetite — the ability to buy, and the willingness to absorb a failed evaluation.

15. Name the one thing that decides who benefits. Having the problem — and nothing else, which is why a device count, a headcount and a purchase history are all uninformative about it.

16. Why does the belief conflate them? Because adoption order is observable and need is not. Everybody can see who bought.

17. A buyer with no volume, no appetite and the problem. What is true of it? It is not an early adopter and it benefits. The two facts are independent.

18. Give the break-even formula. Ceiling of the fixed cost divided by the per-node saving.

19. Fixed cost 7, saving 2 per node. What is the break-even? Four nodes, not three — the ceiling matters, because three nodes save six against a cost of seven.

20. A site has six nodes. Is it worth it? Yes, and it was worth checking rather than arguing about. The division takes a minute.

21. When does the break-even not exist? When the per-node saving is zero. No fleet size reaches it, and the model reports the maximum rather than dividing.

22. What actually decides whether a machine needs more memory? The working set of the thing running on it, against the memory the node has.

23. Give the two examples that are the wrong way round. A four-node site running an in-memory analytic has the problem; a four-thousand-node site running stateless request handling does not.

24. Why is size used as the classifier anyway? Because workload profiles are expensive to produce and organisation sizes are free, so the free variable gets used.

Time and supply

25. Why does the break-even move? Because the fixed part — integration, qualification, the component — falls as a technology becomes ordinary, and the saving does not.

26. Cost 20 today and 9 later, saving 3 per node. Give both paybacks. Seven nodes today and three later. A six-node site misses today by one and clears later by three.

27. What is missing from the sentence "not at our size"? A year, a cost, and a review date. A verdict with no expiry never gets one.

28. Which part of the misconception is simply true? The supply constraint. Early parts go where the volume is, and a small buyer genuinely cannot get them yet.

29. Why is that still the wrong question? Because it is a statement about a queue. Reading it as a statement about need turns a temporary condition into a permanent belief.

30. What two fields fix it? Would-it-help, and can-we-get-it — with a review date on the second one only.

31. Why does the supply constraint expire silently? Because nobody sends a notification when a part becomes generally available, so a verdict formed during the constraint has no trigger to be revisited.

Why this one is different

32. What makes this misconception harder to notice than the others in this module? It produces nothing. No evaluation, no measurement, no decision — and there is no incident report for a question nobody asked.

33. In what sense is the belief self-sealing? It prevents the measurement that would test it. A small site with no stranding telemetry is indistinguishable from a small site with no stranding.

34. Which single counter breaks the seal? Stranded bytes per node — a subtraction on two numbers every node already reports, measurable on one machine with no fleet to compare against.

35. Why is this chapter last in the module? Because the other five are held by people describing a mechanism and this one is held by people deciding whether to look at it.

Method

36. Give the four conditions "only hyperscalers" requires. The ratio only occurs above some fleet size, one node cannot strand, the break-even exceeds what smaller sites have, and scale creates the benefit.

37. Which of the four is arithmetically impossible? The fourth. A zero per-node saving multiplied by any fleet size is zero, so scale cannot create a benefit.

38. What did the width review find on this chapter? Seven clamps whose true branch has no reachable input, all found before a single cycle was simulated.

39. Why is that cheaper than finding them with a campaign? Because it catches all of them at once, before the testbench exists — and in two other chapters of this batch the same shape was found one clamp at a time, after everything was built.

40. Why did domcheck report zero while all seven were present? Because the unreachability comes from operand width, which is outside its model.

41. This chapter had no wrong oracle. What does that prove? That its models are combinational. Every wrong oracle across three batches was a timing relationship, and a model with no timing relationships produces none.

42. Three models here share a sixteen-node constant. What did the campaign find? That driving the boundary in one of them does not drive it in the others. Two models that share a constant still need the case twice.

43. What was the second survivor, and why does it matter? A positive per-node saving on zero nodes — the chapter's own argument as a degenerate input, found by removing the distinction from the model rather than from the prose.

44. State the rule that kills both survivors. Drive every boundary in every model that uses it, and drive zero for every count.

45. What would you say to a colleague who states this belief? Ask for two numbers — the node's memory and its compute — and then for a third, the fixed cost over the per-node saving. All three are things they already have.

46. State the single question this chapter turns on. Is the problem a ratio or a scale — and what is the break-even node count?

28. Exercises

1 — Analysis · Foundation. Builds: separating a per-machine quantity from a fleet-level one. Take the sentence "that is a hyperscaler technology". Bounded scope: write the four conditions it requires, mark each true or false, and identify the one that is arithmetically impossible. Hint: one of them is a claim about what multiplication can do.

2 — Quantitative · Foundation. Builds: measuring one node. Take a machine you have access to. Bounded scope: find its attached memory and its used memory, compute the stranded figure, and state what a fleet of forty identical machines would strand — then say which of the two numbers a mechanism acts on. Hint: the subtraction is on two numbers the machine already reports.

3 — Quantitative · Intermediate. Builds: turning an argument into a division. A mechanism has a fixed adoption cost of 45 units and saves 4 units per node per year. Bounded scope: compute the break-even node count with ceiling division, state whether a 10-node site clears it, and say what the answer becomes if the fixed cost halves. Hint: the third part of the question is the one that shows the verdict has a date.

4 — Analysis · Intermediate. Builds: classifying by the variable that decides. Take three workloads you know. Bounded scope: for each, give the working set, the node memory available, the spill, and the installation size — then say whether installation size predicted the spill in any of the three. Hint: the interesting result is a table where the two columns are uncorrelated.

5 — Design review · Advanced. Builds: separating adoption order from need. You are shown an adopter list as evidence that a mechanism is not relevant to your organisation. Bounded scope: state what the list measures, name the two inputs that decide adoption order, name the one that decides benefit, and write the problem statement you would evaluate against instead. Hint: only one of the two questions has a public answer.

6 — Design · Advanced. Builds: instrumenting so a belief can be tested. Specify the minimum telemetry a single node needs so that "we are too small to have that problem" becomes falsifiable. Bounded scope: name each field, say which are design-time constants and which are runtime counters, and identify the single field you would add first. Hint: the cheapest one is a subtraction.

7 — Design review · Advanced. Builds: recording a verdict that can expire. Take a "not at our size" decision from your own organisation. Bounded scope: reconstruct the fixed cost and per-node saving it assumed, compute the break-even it implied, state what would have to change for the verdict to flip, and write the review trigger you would attach. Hint: a verdict with no assumed-cost column cannot be re-evaluated at all.

8 — Verification · Expert. Builds: driving a shared constant in every model that uses it. Take a verification environment with a threshold constant appearing in more than one model or checker. Bounded scope: for each occurrence, identify whether the boundary is driven exactly; construct the missing cases; and state why driving it in one place did not cover the others. Hint: this chapter's survivor was exactly that, and the same constant appeared three times.

29. Summary

The problem is a ratio, and a ratio is the same number in a rack of four and a hall of forty thousand. Both quantities are per machine and the fleet size is in neither.

Scale multiplies the consequence. It does not create the problem. The identical machine has the identical ratio at any node count, and a verdict that changes is reading the wrong variable.

Stranding needs exactly one machine to exist. Measure one node; the fleet strands that times N.

The benefit is per node and the fleet multiplies it. A positive per-node saving is a benefit at any total, and no fleet size rescues a zero.

Who buys first is decided by procurement volume and risk appetite. Who benefits is decided by having the problem. Only the first has a public answer, which is why it becomes the classifier.

The break-even is one division, and the answer is frequently a small number. An argument about size that could have been a division is an argument that will not converge.

The discriminator is the working set, not the headcount — and the canonical examples are the wrong way round from what the belief predicts.

The verdict has a date on it. The fixed cost falls, the break-even moves with it, and a decision recorded without its assumed cost cannot be re-evaluated.

The supply constraint is real and it is a statement about a queue. Separate can-we-get-it from would-it-help, and put a review date on the first one only.

This is the only misconception in the module that produces nothing — no wrong design, no incident, no evidence — which is why it is self-sealing and why one counter breaks the seal.

A conjunction has no partial credit, and the fourth condition here is arithmetically impossible rather than merely false.

Six conditions, and "the largest operators adopted it first" is one of them. A true statement about a procurement queue, checked correctly, is 16 percent of an argument about who needs something.