diff --git a/docs/design/class-v6-rotating-family.md b/docs/design/class-v6-rotating-family.md
index 84307c30a..aa0984e07 100644
--- a/docs/design/class-v6-rotating-family.md
+++ b/docs/design/class-v6-rotating-family.md
@@ -581,6 +581,8 @@ Placement and the clock tree add 32 percent to the class v4 draw (7.78 pJ per la
 
 Scored on lane 3's seven conditions at these energies (a first reading on lane 3's rows, approximate; its own scoring with the sunk-development case replaces it by 21:00): the board's verdicts stand (its per-joule ratio falls a tenth, its dollars do not move; it passes all seven at a one to three year life); the hybrid's stand (it fails (b) and (c), the dollar conditions, which placement does not touch; on (e) it sits on the 3x line a node ahead and under it node-for-node); the die's stand on (a), (b), (c) and (f) (its dollars are the die's) and on (e) it now holds node-for-node (2.4x) and fails a node ahead (3.3x). **So the success statement holds for the pure DRAM board, fails for the SRAM die once sunk, and fails for the hybrid on the dollar conditions; the placed energies change no verdict and tighten every per-joule figure by a tenth.** The served energy sentence (10.0h) reads from this table.
 
+Two more D4 pins from the complete 2.0 plan (on master at b943c047; the coordinator, 18:1x UK), both for the 21:00 landing on lane 3's model: the scenario axes gain MARKET STRUCTURE (private supply, public hardware sales, multiple suppliers, concentration) as a named axis with a row per structure for each of the three chips; and every threshold figure produced today (the USD 340 M and USD 23 M a year revenue thresholds, the USD 20 to 75 M development range, the p* rows, the break-even electricity rows) moves into a sensitivity workbook, `docs/analysis/class-v6/coexistence-workbook.md`, with the assumption that produces each row in its columns, never served as a boundary; the site lane holds them off every page. The success condition to serve, verbatim from the plan: "A specialised supplier may earn a normal return; ordinary GPUs remain sufficiently close in total cost, widely obtainable and useful outside mining that new operators can still compete."
+
 The proving-payment pin is in the code (the node-side hand, 17:03 UK): branch proving-payment of the fork at eaddbf83 on release-2.0.0-node's c04674fe, the suites green on build-2 (igneum-exec 66 passed, kaspa-consensus-core 174 passed): behind `Params::proving_payment_activation_daa` (u64::MAX on every object; the height is main's word) a transaction's proving charge (pgas used x f_p) is 90 percent credited to `PROVING_POOL_ADDRESS` and the block's `proving_pool_credit` (so 5.3's per-shard payout carries it) and 10 percent burned, the rounding wei to the burn; below the height the whole charge burns as 5.1 stood; the receipt's new field `proving_payment` shows the provers' part beside `burned_proving`. One fact before any height is named: the shard guest (`proving/igneum-prove/core/src/executor.rs` lines 290 and 318) still burns the whole charge, so the floor stays at never until the guest carries the same split behind the same switch and the object pins the new shard program id; set before that, no shard proof verifies past the floor. The economics row reads: "designed, in the code behind the constant; the guest's mirror owed before any height".
 
 #### 10.0d The rotation schedule the close adopts (the rotation lane, `docs/design/class-rotation-four-layers.md` on class-v6-rotation at bd43f808, build-3, gate green, 14:4x UK; one line per layer; both of this document's constraints held: the 180-day family epoch not shorter, W = 4 not drawn)