Kuantillion Cloud: the execution plan

Kuantillion Cloud is a fictional company. Any resemblance to real companies reflects problems the industry shares.

What this program is. Kuantillion Cloud retires drives by the million and holds idle flash in running machines, while new flash costs three to four times last year's price. The program decides where each older drive goes: a workload, a repair spare, a build, or exit. This page is its runbook: owners, dates, seven decision gates, rules, measures and playbooks.

This page is the execution plan for Case 3. The strategy page says why each move is right. This page says who does it, in what order, and how you'll know it worked.

How to read the labels. A quote with a Section is the seed paper's own text. Rules this plan adds are marked argued. Quantities nobody has published are unmeasured. Every number is illustrative unless the case tags it otherwise. Every owner and date is a proposal, to be adjusted to the teams you find. The seed paper is "a practitioner synthesis, not a model, and untested" (Abstract), and so is this plan.

The small grid under the contents places this page on the map. Its columns are the five cadences, annual to post-launch; its rows are the five altitudes, envelope to unit. Every cell is lit, because the plan runs at all of them.

Terms used on this page #

• Sink: one of four places a usable drive can go: workloads, repair spares, upgrades and builds, or exit (sink).
• Harvest: drives taken out of retiring hosts for reuse or exit (harvest).
• Cohort: drives sharing a model, firmware and power-on-hour band, which tend to fail together (cohort).
• Grade: this plan's three-level rule for where a tested drive may go (the rules section).
• Tier cap and grading tax: how many grades the systems can carry, and the cost of each extra one (tier cap; grading tax).
• Cover point: the spares level a signed shortage-to-idle ratio sets (cover point).
• Showback: a price shown to a team before anyone is billed (showback).
• Decision gates and technical gates: the program's seven steps, G0–G6, and the case's eleven tests on each drive.
• P1–P8: the case's eight decision problems, such as P1 the drive record and P6 allocation (full case, section 11).
• Off-host states: where a drive sits once it leaves a running machine: harvested, erased, in test or held.
• Supply register: the supply plan of record and commitment register, mechanism 11.
• Commit point: the last date to commit without paying to change shape (commit point).
• Named gap and bridge: a shortfall with an owner, and the costly stopgap that covers it (named gap; bridge).
• Seam: a standing line of conflict between groups (seam).
• Path A and Path B: the case's two futures. Path A stays tight through 2028; Path B eases from late 2027.

1. What this plan delivers, and the decision it serves #

The Kuantillion Cloud flash program: what it must decide, by when, and on what ideas.

The situation. Kuantillion Cloud runs a hyperscale fleet. It retires millions of components a year, over 3 million of them drives in 2024. It also holds older flash idle inside running machines. New enterprise flash now costs three to four times last year's price, and next year's supply is largely pledged. The full case sets this out.

The decision this plan serves. Should Kuantillion Cloud run a program for its older flash, and at what size? If yes, how should it split each usable drive among four sinks? Those sinks are workloads, repair spares, upgrades and builds, and exit through resale or recycling.

What the plan delivers, in order.

1. Within one week, an answer to whether a program already exists, or was tried and dropped.
2. Within 30 days, a dollar test of whether the program pays, and its scope: spares continuity, mixed, or supply strategy. Beside it, the value anchor read from the flash contracts.
3. Within 90 days, the rules signed in advance, spares and the reverse pipeline staffed to a signed plan, and spares allocation running in a standing forum. Wider allocation follows once the drive record is live (G3b, the second half of gate G3).
4. From week 2, in parallel, a track on the stranded flash already installed. It needs no sanitization, custody or qualification, and it may be the larger prize.
5. From G4, capacity delivered: TB to each sink per quarter, by scope, declared in advance and scored promised against actual.
6. Over the following year, a pilot of reused flash in tiers that absorb device loss, and experiments that test the case's eight stated assumptions.

The clock against the shortage argued. Suppose day 1 is 2 November 2026 (illustrative). Then G1 falls on 1 December, G4 on 30 January 2027, and G5 no earlier than 30 April 2027.

• Under the case's Path B, the shortage eases from late 2027. Reused flash would then reach workloads with about two quarters of shortage left.
• Harvest value falls as that window closes. At a 50% yearly price fall, it loses about 16% per quarter of delay; at 10%, under 3% (illustrative). So the gates that don't depend on each other run in parallel: spares, the pipeline, the record build and the stranded track.
• Under Path A, tight through 2028, the same calendar leaves nearly seven quarters.

What it rests on. Five ideas from the seed paper carry it.

• A retirement is a dated supply step that slips (Section 6.7). Here it also delivers drives.
• Each pricing question gets its own price (three prices; Section 4).
• An approval is not an allocation (approval and allocation; Section 6.1).
• Every number has an owner, and every gap is named (principles).
• Turn-up is a staffed rate (Section 6.2). Applied here, so is the reverse pipeline.

What it doesn't do. It doesn't settle questions the practice can't yet answer. The Second lives note holds the two that stay open: supply that is a byproduct of other decisions, coupled to demand, and quality that fails after delivery, as a cohort.

2. Roles and decision rights #

Who runs the Kuantillion Cloud flash program, who decides each of the case's eight problems, and who signs.

The planner sits in the middle, "usually owning no capacity and no budget" (Section 10). So every change below is a proposal to the forum and finance. Its standing comes, in the paper's experience, "from the number and the team's own signature" (Section 9.1). See people for how that works without a budget.

The groups. This table extends the case's team map. After the sponsor, the next nine rows are the case's; the rest are groups the case names elsewhere, or that this plan defines argued.

Drive supply in the tables below means fleet provisioning and spares planning together, the groups that answer for drives. Supply chain is a separate group: it owns vendor contracts.

Decision rights, RACI-style. R does the work, A decides, S signs, C is consulted. Change marks a move from today's owner in the case.

Three rights come straight from the seed paper's list (Section 9.2):

• The shortage-to-idle ratios belong to "finance and product jointly; supply provides the cost of idle and the liability terms".
• Change bands belong to "supply and planning, signed by the declaring team, with finance agreeing who pays for a change outside them".
• "Reliability buffers: reliability engineering".

Assigning them to these groups is this plan's reading argued. The ratio and the bands are separate rights, signed separately.

Why storage systems own the stranded line. The case's team map gives stranding to fleet provisioning. Mechanism 4's owner is the "Service owner (not necessarily the cause)" (Section 9.2), and the storage systems serve the stranded flash. So they own the line, and fleet provisioning is consulted argued.

The landing rule, one statement used everywhere argued. Planning proposes it, finance signs it, and the forum ratifies it.

Technical-gate owners. Each of the case's eleven technical gates has one owner argued:

• fleet shaping and hardware engineering: physical fit, and protocol and backplane;
• flash platform engineering: qualification, firmware and provenance, observability, and condition;
• data-center operations: change windows;
• fleet provisioning: systems of record;
• planning, with the solver team: systems complexity;
• drive security engineering: sanitization;
• finance, with legal and tax: jurisdiction, for any drive that crosses a legal entity or a border.

Seams. Hosts and harvest sit on seam 3, between planning and supply. Keeping hosts, and the split between capital and operating budgets, sit on seam 2, between planning and finance. Grades and wear sit on seam 1, between product and platform (Section 10.1). Mapping them this way is this plan's reading.

3. The first 30, 60 and 90 days #

The program's first quarter, day by day: one owner and one output per action.

Day 1 is the day the sponsor names the program lead. Each action has one owner and one output. Owners and days are proposals argued.

Days 1–5: stand up the program #

Why hold first argued. Destruction and resale can't be undone, and allocation starts only at day 90. So preserve the option before you price it. When the cages fill, the oldest held lots go to exit first.

Days 1–5: does a program already exist? #

The public record is silent, and the case reads that silence three ways. A program may run quietly, one may have been tried and dropped, or none exists. Test all three before you design anything.

Talk to the owners one to one, before any form goes out. Section 9.3 gives that advice for demand intake; this plan borrows it. Sort what you hear into "a fact", "an assumption" or "an ask" (Section 10.4).

Go or stop.

• If a program runs, audit it against the thirteen mechanisms and add only what's missing.
• If a decline still holds at today's prices, stop the full program and re-center on redeploying whole hosts. Run only G2's redeploy-whole test and the keep sheet.
• If neither, go to G1.

Days 6–30: size it and read the contracts #

Days 31–60: counter-arguments and the record #

Days 61–90: spares and the pipeline first #

Why staffing is a commit point. The case bounds a year's SSD harvest at about 25–375 technician-years of labor, an upper bound. Crews of that size can't be hired in the 15 days after G3a, so the rate is committed at G1.

Why spares go first. Spares are the harvest's most predictable claim and its value floor. The paper's order of change is "prove fulfillment first" (Section 10.4); this plan applies it to reused drives.

4. The gates #

The program's seven decision gates, G0–G6, each with the evidence that opens it and the call it makes.

This plan uses "gate" in two senses. The program's seven decision gates, G0 to G6, are the steps of this plan. The case's eleven technical gates are the tests every drive must pass before reuse, such as fit, qualification, sanitization and jurisdiction (full case, section 6). This section is about the decision gates.

Each decision gate opens only on the evidence in its row. The paper's rule for declarations is that "promotion needs the evidence in its row" (Section 5.4). This plan applies it to the program's own gates argued. Each artifact names its mechanism, linked to the operating mechanisms.

G0: existence test #

• When. Days 1–5, as an initial reading. If interviews run long, extend to day 10.
• Purpose. Don't build what exists, or what was rightly declined.
• Entry evidence. A named program lead.
• Work. The days 1–5 interviews, using the interview guide and the mechanism audit checklist in the templates.
• Exit criteria. One of three readings recorded: exists, declined, or absent.
• Artifacts. A decision note.
• Owner. Planning.
• Go or stop. Go if absent, or if a decline fails today's prices. If a decline still holds, stop and re-center on redeploying whole hosts: G2's redeploy-whole test and the keep sheet only. If a program exists, audit it against the thirteen mechanisms. Then either enter G1 with that program as the base, or stop with a decision note.

G1: size and anchor #

• When. Day 30.
• Purpose. Know whether the program pays, at what scope, and on which value anchor, before building anything. "Below materiality, the mechanisms cost more than they return" (Section 13). The paper writes that of elastic-cloud customers; reading it as a dollar test here is this plan's argued.
• Entry evidence. G0 reads absent, or a decline that no longer holds.
• Work.
  • The dollar test.
  • The materiality ratio, as a scope descriptor.
  • The stranded stock, sized on its own.
  • The contracts read into the supply register.
  • The capacity anchor's inputs.
  • The pipeline rate on the commit-point map, with surge crews on option.
• Exit criteria.
  • The dollar test passed, and the scope chosen.
  • The anchor declared.
  • The forum chartered for two rules: it agrees the shortage rule, and it ratifies the landing rule that planning proposes and finance signs.
• Artifacts.
  • Contract lines on the supply plan of record (mechanism 11).
  • The purchase plan, frozen as the baseline for savings.
  • The controller's accounting memo. It covers the inventory basis, near net book value. It says whether spares are capitalized or expensed, and when drives are held for sale or impaired.
  • The memo also covers resale gain or loss, builds that look cheaper than they are, and a management ledger at fair value: the drive record with a value column.
  • The stranded line, owned (mechanism 4).
  • A decision note.
• Owner. Planning, with finance.
• The dollar test argued. Go when expected annual net value over exit, under the declared anchor, times usable TB, exceeds the program's fixed cost. That cost is the record, the forum and the pipeline's standing staff.
  • For example, a central harvest of about 1.8 EB a year at 80% yield is about 1.44 million usable TB (illustrative).
  • At +$10 per TB over exit, that is about $14M a year. At +$370 it is about $530M.
  • Against a fixed cost of $20–60M a year (illustrative), the low-price cell fails and the high-price cell passes easily.
• The ratio describes scope; it doesn't decide go. It is the SSD harvest, before yield, divided by a year's new flash (materiality). The case puts it at about 0.5–30%, central 3–9% (illustrative).
• Its numerator is a hard-drive count. The company's report calls the 3 million retired drives hard drives. If they all are, the ratio is near zero. A vintage check gives about 4–9 EB of flash retiring a year. So the day-10 pull splits harvest by drive type and vintage.
• Scope table argued. One price basis per scenario: the ratio and the dollar test use the same one.

• Tie-break. If the ratio's range spans two rows, run the smaller scope, and re-test at the first quarterly supply review argued.

• Stranded stock, beside it. Neither the dollar test nor the ratio gates the stranded stock, which runs as its own track from week 2. The case puts installed flash at 60–100 EB.

• Recovering the gap between one peer's 54% and 19% stranding, after a haircut for reach, frees about 11–35 EB, once (illustrative). That is two to six times the top harvest row.

• The reclaim pilot reads out by day 90, and that is the track's own go or stop.

• Go or stop. Go at the chosen scope. "Stop at the step where the next one costs more than it saves" (Section 12). The paper writes that for mid-sized companies; this plan applies it to the program's own steps.

G2: counter-arguments #

• When. Day 60.
• Purpose. Test the two hypotheses that could move the center: the grading tax, and redeploying whole hosts.
• Entry evidence. G1 says go.
• Work.
  • Count the qualification backlog and solver categories.
  • Read decommission records by branch.
  • Check whether the solvers reach physical devices.
• Exit criteria.
  • A tier cap: how many grades the systems can carry.
  • A test for redeploying whole.
• Artifacts.
  • The tier cap, as a decision note.
  • The keep, redeploy or harvest sheet's test.
• Owner. Planning, with the solver team and lifecycle transitions.
• Go or stop. If the systems can carry no more than one grade, run spares and exit only. If redeploying whole usually wins, re-center there.

G3: the drive record, designed (G3a) and live (G3b) #

• When. G3a at day 60. G3b when the record is live for the off-host states, on the date fleet provisioning estimates at G1.
• Purpose. One record every decision can cite. It is a systems build, not a meeting.
• Entry evidence. G1 says go. The build starts then; it doesn't wait for G2.
• Work.
  • Name an owner for each field, off-host fields first.
  • Define each handoff.
  • Build the off-host states into the systems of record.
  • Reconcile the record with the erasure log.
• Exit criteria.
  • G3a: every field owned, and each off-host state defined, with who accepts it.
  • G3b: the record live for every off-host state, across crews, benches, cages and partners, and reconciled with the erasure log.
• Artifacts. The drive record (the templates below give its fields). The fulfillment ledger, run backwards (mechanism 5).
• Owner. Planning keeps it; each field's performer owns its entry; fleet provisioning owns the systems build.
• Go or stop. Don't move a drive between sinks on a record with an open reconciliation gap. Until G3b, the spares pilot runs on a manual ledger, by lot.

G4: hosts and allocation, spares and pipeline first #

• When. Day 90 for spares and the pipeline. Allocation beyond spares waits for G3b.
• Purpose. Clear the coupled decisions together: when hosts go, how harvest is split, how many spares, how fast the pipeline.
• Entry evidence. G3a exit, with G3b dated. Until G3b, a manual lot-level ledger serves the spares pilot.
• Work.
  • Decommissions on the register.
  • The spares ratio signed.
  • The pipeline staffed to the signed rate, at its commit point.
  • The forum ranking harvest.
  • The risk budget set.
• Exit criteria.
  • Every harvest claim answered with a dated commit or a named gap.
  • Each tested drive pegged to one claim.
• Artifacts.
  • Ledger lines (mechanism 5).
  • Supply answers (mechanism 11).
  • The commit-point map for last-time buys and decommissions (mechanism 13).
  • The forum's decision log (mechanism 10).
• Owner. The forum, run by planning; fleet provisioning for supply answers.
• Go or stop. Hold G5 until spares fill holds at the signed cover point for one quarter.

G5: workloads and builds #

• When. No earlier than day 180: one quarter of spares fill after G4.
• Purpose. Offer reused flash as its own class, and declare build programs.
• Entry evidence. G4 exit, and the tier cap from G2.
• Work.
  • A pilot cohort in caches and replicated tiers.
  • Build programs declared, with stages and bands.
• Exit criteria.
  • A reused-flash class offered, with its guarantee and evidence bar.
  • A substitution table.
• Artifacts.
  • Declaration entries for builds (mechanism 12).
  • The class on the rate card (mechanism 3).
• Owner. Storage systems; fleet shaping and hardware engineering.
• Go or stop. Stop widening the class if the pilot's failure rate breaks its evidence bar.

G6: the wear link #

• When. After the pilot's first second-life outcomes; no date is set.
• Purpose. Price first-life wear against second-life value.
• Entry evidence. G5's pilot gives a second-life value to price against.
• Work.
  • Register the wear price, owned and versioned.
  • Report endurance used by cohort quarterly.
• Exit criteria. The wear price on the rate card with an effective date.
• Artifacts. The coefficient register and versioned rate card (mechanism 3).
• Owner. Flash platform engineering, with finance.
• Go or stop. Change first-life placement only where endurance used at harvest is shown to change second-life value.

Why the wear link goes last. The case's own best guess is that placement shapes the harvest little today, except in write-heavy and low-endurance cohorts.

5. Standing cadence #

The meetings that keep the flash program running once the first 90 days are over.

The cycles nest, slowest outside: "Each cycle commits only what its lead time forces" (Section 9.1). See annual, quarterly, monthly, weekly and post-launch.

"In my experience, the step most often missing is the supply review" (Section 9.1). Here it is the main meeting, because supply is a byproduct of other decisions argued. A vendor's end-of-life notice triggers an off-cycle review.

The forum sets rules; a system pegs argued. Millions of drives can't be allocated by hand. The forum owns the ranking rule, the cut line and overrides. The solver, or fleet provisioning's tools, peg each tested drive to a claim. The forum reviews only the exceptions.

Annual signatures, kept separate.

• Finance and tier owners sign the spares ratio.
• Drive supply and planning set the harvest change bands, and each declaring sink signs them.
• Planning proposes the landing rule, finance signs it and the forum ratifies it (mechanism 8).

The charter overlay. "Once a year, lay the charters over the chain that delivers the product, end to end, and name an owner for every gap" (Section 10.2).

6. Rules agreed in advance #

The rules the program's forum and finance sign before any drive is allocated or any saving counted.

"A rule agreed in advance is a contract; one proposed after the savings appear is a request" (Section 9.3). Each rule below is written so the forum can sign it. Each is this plan's argued, built on the seed text it cites.

Booking rule argued. Applies to every planned retirement's harvest, cohort by cohort.

• In the first cycle, with no stage record yet, book firm only drives already tested.
• After that, book harvest firm only to the stage record's lower quantile until the drives are drained.
• Then book to the stage record's middle.
• Above the firm slice, hold options on new purchase. Above that, name a bridge with an owner.
• Label harvest uncommitted until supply answers with a dated commit or a named gap.
• Basis: "Until then, label it uncommitted, a firmness class of its own" (Section 6.1); the firm, flexible and named split (Section 8.2).
• The stage record carries pull-ins as well as slips. A power-forced retirement delivers drives early.
• Working estimate, by cohort mix argued. Suppose 50–70% of scheduled retirements land on their date. Yield is near all-or-nothing within a cohort, so draw it per cohort, not as one average.
• For example, 60% of drives in observable cohorts yield about 90%, and 40% in blind ones about 40% (illustrative; the real yields are unmeasured).
• The central share is then about 35–49% of scheduled drives. The firm slice, from observable cohorts at the low on-time share, is about 27%.
• For a batch of 40,000 drives, that is about 14,000–19,600 central, and about 10,800 firm.

Ranking: priority classes, priced within class argued. The shortage rule below sets the classes. Within a class, the forum ranks each claim at the cost of that sink's next-best source on that date:

The spares row's cost is qualitative, so spares rank by class, not by price. Score the rule after two cycles.

Three-grade starter rule argued. Revisit after the pilot.

Grade on event history, firmware and burn-in, not on wear. Those are the signals that predict failure in published fleets.

• Why event history. After one uncorrectable error, the chance of another next month was about 30%, against 2% in a random month (Schroeder et al. 2016).
• Firmware version can move the annual replacement rate tenfold (Maneas et al. 2020).
• Wear stays a recorded field. It is a threshold only for write-heavy or QLC cohorts, because most drives use little of their rated endurance.
• Age matters per firmware cohort, measured in power-on hours. At grading, reject or stagger drives near a known fault age.
• N and the counts are unmeasured; set them from the first cohorts' telemetry. Three grades fit inside a tier cap of three or more. At a cap of two, merge grades 1 and 2 into one reusable grade, limited to loss-absorbing tiers and like-for-like spares, and keep grade 3 for exit argued. At a cap of one, G2's rule governs: run spares and exit only.

Internal showback rate, shown back first argued. Call it a showback rate, not a transfer price, to keep it apart from tax transfer pricing.

• The rate per usable TB is the higher of net realizable resale for the cohort and grade, and pipeline cost per usable TB, plus a risk loading.
• Why resale is the floor. Where an outside market exists, the efficient internal price includes that market price as an opportunity cost (Baldenius 2008, on Hirshleifer's rule). That holds for a seller that takes the price; this program also moves it. A lower rate invites every sink to over-claim.
• Net resale is what the resale and recycling contracts actually pay, after their fees.
• Carry is charged per TB-month while the drive is held, not once.
• Risk loading per usable TB = the chance of a correlated event × its cost, bridges included ÷ usable TB at risk. For example, 5% a year × $1M ÷ 10,000 TB is $5 (illustrative).
• For example, a 2 TB drive costing $40 to process at 80% yield is $25 per usable TB. If net resale is $100 and risk loading $5, the rate is about $105. Carry is cage space plus a capital charge on the held value. At $100 and a 10% cost of capital, the charge alone is about $0.83 per TB-month (illustrative).
• The gap between resale and pipeline cost is a credit to recovery in the management ledger. It is never booked as a saving.
• Show it back for a full cycle before anyone is billed: "Move to attributed cost only after a full cycle of showback" (Section 10.4).
• The forum ranks on next-best-source value, not on this rate.

Release trigger argued. Write it before you hold. The paper's option rule is "write down the trigger for converting options into orders" (Section 6.2).

• Hold a cohort's drives only while the expected discounted value of a claim, minus holding cost, exceeds net resale now.
• Read resale prices monthly, not quarterly. Waiting for two quarterly prints costs about six months in a falling market.
• Add a stop-loss: release when resale falls a set share from the hold date, such as 20% (illustrative).
• Or release when a drive's shelf time passes two re-test cycles with no claim.
• Release in steps, under a cap on resale per model per quarter.

Sanitization by sink argued. The case says internal reuse faces a lower bar than exit. Drive security engineering sets each bar.

• Internal sinks: crypto-erase, with custody unbroken from host to new host.
• Exit: purge, then verify and validate each lot before it leaves custody.
• Both: the standing read-back rule under scenario S3, per tool × firmware × model.
• Destruction: current standards have moved past shredding for flash; the revised federal guideline's FAQ calls it ineffective for medium- and high-security flash. Use a listed destruct method, such as melting or incineration, and rely on keys held off the drive.
• Price the pipeline separately for each path, since exit costs more per drive.

Landing rule argued (landing rule).

• Capital savings land only on evidence. That means a purchase-order line cancelled, reduced or pushed out in the supply register (mechanism 11). Or it means a cut against the purchase plan frozen at G1.
• Once a saving lands, split it: shares booked as savings, returned to the recoverer and held centrally. That is the split Section 9.3 offers as an example.
• Under the capacity anchor, avoided stockout cost is credited to the product's profit and loss. It is not capital saved.
• The pipeline counts as a recoverer. Its credit for the gap between resale and pipeline cost stays in the management ledger.
• Planning proposes it, finance signs it and the forum ratifies it (mechanism 8), before any recovery is counted.

Spares cover rule argued. Cover comes from the signed shortage-to-idle ratio, one per repair-urgency segment (cover point).

• A ratio of k to 1 sets cover at the k ÷ (k + 1) quantile of demand over the resupply time.
• Host-down platforms, with no fail-in-place, get a high ratio. Tiers that can fail in place get a low one, because failing in place is their bridge.
• For example, 200,000 drives failing at 1.5% a year, with 30 days to resupply, average about 247 failures in that time (illustrative).
• Cover is then about 246 drives at 1 to 1, 260 at 4 to 1, and 273 at 19 to 1.
• At 260, the fill rate is about 80%, and about 1.75 drives are on backorder on average.
• Failures come in batches. A firmware fault at a fixed age fails a cohort together. At a variance twice the mean, the 80% and 95% pools become 265 and 284. At four times, 273 and 300.
• So size a firmware-cliff scenario from the case's known fault ages (full case, section 6.1). Size the pool and the cohort cap together.
• Two legs, sized apart. The pool above is the test-and-ship leg, given untested stock in the cage. Harvest reaches the cage in lumps, on decommission dates. So size the untested cage against the decommission calendar.
• A pre-tested float. Keep a burned-in float of tested drives, sized to the resupply quantile, so a repair doesn't wait for a full test.
• Retest staleness. Retest any held drive whose last full test is older than a set limit, such as 90 days (illustrative). Erase, quick-screen and hold stays the default.

Shortage rule argued. "Agree it in the forum beforehand; supply carries it out. Written during the shortage, it's a negotiation. And don't split a shortage pro rata" (Section 9.3). Who goes short, last to first:

1. Spares for host-down platforms with no other source go short last, because a missed repair has no bridge.
2. Spares for platforms that new drives can still serve.
3. Claims backed by a signed build program.
4. Workload claims, ranked by next-best-source value.
5. Exit goes short first.

Who pays when harvest fails to arrive argued. The default:

• If drive supply gave a dated commit and missed it, drive supply pays the bridge.
• If the claim was booked against uncommitted harvest, the claiming sink pays.
• Finance signs the exceptions in advance, as the paper has finance agree "who pays for a change outside" the bands (Section 9.2).

7. Measures #

How the flash program is scored, each measure with a denominator and a test that can fail.

Finance keeps score: "Finance, not planning, should keep the score, or the indicators become self-assessment" (Section 9.3). Read the measures as a set, because "any indicator in Section 9.2 can be gamed once rewarded" (Section 13).

Targets are this plan's proposals argued. None of these tests has been run.

Two of the tests follow the paper's own.

• For mechanism 11: "the gap between promised and actual delivery dates narrows" (Section 9.2).
• For mechanism 13: "fewer orders are placed after their commit point, and their bridge premiums shrink" (Section 9.2).

Why not count bridges. Section 10.2's "about one launch in five should need a bridge" is for one-shot buys. A spares pool is replenished, so fill rate and backorders are the right tests.

8. Experiments #

One experiment for each assumption the case states, each able to change the program.

One experiment per stated assumption in the case. Each has an owner, a date in program days (the same clock as section 3), a method, a falsifier and the decision it unlocks. All are proposals argued. "The rollout is the measurement" (Section 5.4).

What experiment 4 measures. The bar is exit, not zero. Resale pays about $80–160 per TB gross. So the margin over exit is about +$90 to +$490 per TB at the case's $640 high price, and about −$135 to +$85 at its $190 low (illustrative). The central cells are about +$370 and +$10. At low prices, reuse barely beats selling.

What experiment 7 measures. At the case's peer (Xu et al. 2019), triage resolved 34.4% of SSD tickets before any swap. Only 31.2% of tickets ended in a swap. So the peer's healthy share of pulled drives is unknown, and so is Kuantillion Cloud's unmeasured. Analogies only: 43% of one vendor's returned hard drives showed no fault (Schroeder and Gibson 2007). About half of swapped SSDs at one operator never returned to service (Alter et al. 2019). Up to 1.5 times true failures is a bound for a site with no triage at all.

The capacity anchor, as a formula. Nothing public gives it an input unmeasured. So experiment 1 fills a formula:

Capacity value per usable TB = Σₜ [P(stockout) × margin × attribution share × survival × P(binding zone)] ÷ (1 + r)ᵗ + terminal value. argued

Here t counts months until new supply lands, and the margin is that of a short TB-month.

• Contribution margin, not revenue. The value lands in the product's profit and loss, not in planning's.
• The attribution share. A stockout is usually of a whole host or VM shape. The drive's share is high only where SSD is the binding dimension.
• The terminal value. After new supply, the drive is worth the purchase it avoids if contracts can move, or its net resale if they can't.

For example, take a $40 margin per short TB-month, 12 months, a stockout in 75% of them, 10% cost of capital and a $100 terminal value (illustrative). At a 10% attribution share the anchor is about $121 per usable TB. At 30% it is about $188, and at 100% about $423.

So the capacity anchor passes the case's $190 floor only above about a 30% share. At these inputs it never reaches the $640 ceiling. Experiment 1's real output is the attribution share, zone by zone unmeasured.

The pilot cohort. It carries the case's most load-bearing question: where second-life hazard crosses the new-drive curve unmeasured.

• Place it in caches and replicated tiers, which absorb device loss by design.
• Spread it across failure domains.
• Track it by power-on hours.

With no reference class, the paper's rule applies: "The planner can only bound it, phase it and buy options" (Section 13).

9. Signposts to actions #

Public market signs, read quarterly, and what the program does when each one moves.

The case names public signposts between two futures. Path A stays tight through 2028; Path B eases from late 2027. Read them at the quarterly supply review. Each action is this plan's argued.

10. Risk register and incident playbook #

What can go wrong with reused flash, and the first hours of the two worst incidents.

Risk register. Each risk has a counter, an early sign and an owner argued. The risks are the case's failure modes.

The cohort cap argued. Name each cohort as a shared driver: "Name the driver; don't infer independence from a low measured correlation" (Section 6.6). A cohort is one model, one firmware and one power-on-hour band.

• The rule. No redundancy group holds more members of one cohort than its failure tolerance minus one.
• For example, an erasure-coded group that survives three lost drives holds at most two of any cohort (illustrative).
• A cap on a cohort's share of a rack or other failure domain is secondary.
• Why groups, not shares. Failures cluster. In one study, a drive in a failed drive's RAID group was over 180 times likelier to be replaced within a week (Maneas et al. 2020).
• In another, 37% of node failures came in bursts, and rack-aware placement typically tripled a stripe's mean time to failure (Ford et al. 2010).

The risk budget, set at G4 argued:

1. A cohort cap per redundancy group, set by reliability engineering. Its test is the chance of losing more cohort drives than the group tolerates within one repair window.
2. An evidence bar per tier, rising only with scored outcomes. Caches start lower, durable tiers higher.
3. An incident cost bound, signed by finance before volume grows. Finance states whether it is accrued as a reserve or expensed when drawn.

Incident playbook: a redeployed cohort fails together (scenario S2) argued.

Durability comes first: protect the data, then fix the schedule. Faults keyed to power-on hours fire together across a co-harvested cohort. In one fleet, 46% of consecutive replacements came within a day of the previous one (Maneas et al. 2020).

The challenge channel follows the paper: "A consumer who can challenge a coefficient, and sometimes wins, trusts the rest of the bill" (Section 10.4).

Incident playbook: a data-bearing drive surfaces outside custody (scenario S3) argued.

A record can say erased while the drive still holds data. In one lab study, only four of seven testable drives erased reliably. One reported success while all its data remained (Wei et al. 2011). So reconciling logs can find a lost drive, but not a failed erasure.

Standing rule argued. No tool × firmware × model combination is trusted until a sampled forensic read-back has passed. Verification inspects each erase's outcome. Validation reviews that evidence and formally accepts the remaining risk (NIST SP 800-88 Rev. 2).

Proving erasure is a security discipline. The practice's part is the record.

11. Templates #

Field lists for the records, sheets and notes the program produces.

Short field lists for the artifacts this plan produces. Each follows a seed mechanism; the drive-specific fields are this plan's argued.

Drive record (mechanism 5, run backwards)

• Drive ID; model; capacity; interface; form factor
• Firmware version; safe version obtainable (yes or no)
• Health: uncorrectable errors and critical warnings, with dates; grown bad blocks and their trend; available spare; capacitor test; wear; latency history
• Burn-in result and date; last full test date, for the retest-staleness limit
• Power-on hours
• State: in service → harvested → erased → in test → available → spare or placed; or out of custody (the erase-first order of the storage policy)
• Location; host platform; cohort
• Grade; costing basis; regraded SKU
• Reuse eligibility: free, constrained or forbidden
• Erasure: method; tool and its firmware; verification result; validation sample ID; reconciled at each state change
• Field owner, per field

Declaration entry (mechanism 12; declarations)

• Owner; driver; stage
• Size and date ranges
• Change bands per stage, with who signed
• Transient and persistent shapes
• Shared drivers, including cohort
• Record: declared against actual, by stage

Commit-point map line (mechanism 13; commit points)

• Layer: last-time buy, decommission, qualification slot, pipeline rate
• Usual and cautious lead time
• Need date; commit point
• Usual stage by then
• Instrument: order, option, bridge
• Cost to change shape after commit

Supply answer (mechanism 11; supply's answer)

• Claim ID; pegged drive lot
• Either a dated commit: quantity, date, confidence, any substituted grade or shape
• Or a named gap: how much, by when, why, and a proposed bridge with its owner

Keep, redeploy or harvest sheet (one per retiring cohort, filled per period; P2) argued

• Cohort; platform; host count; planned retirement date; horizon, such as four quarters
• Harvest value = yield × each sink's next-best-source value − pipeline cost.

• The rule. Keep while next period's value exceeds next period's total carry, decay included. In accounting terms it is a relevant-cost, equipment-replacement decision.
• Harvest is deferred, not lost. For example, harvest now is worth $300 per drive. Keep a year at $60 carry, then harvest: about $185 if prices fall 10%, about $76 if they fall 50% (illustrative).
• So keeping must earn over $115–224 of capacity value that year.
• Power-forced retirements. Where the site needs the slot's power, keep isn't available. The sheet then chooses between redeploying whole elsewhere and harvesting.
• Depreciation is a memo line. Net book value is near zero past useful life, and depreciation is sunk and non-cash. Useful-life changes come from the controller's annual review.
• Signing. Finance confirms the accounting effect; the forum decides the economics, for every keep past plan.

Forum charter (mechanism 10; forum) argued

• Members: the sponsor, as chair; planning, which runs it; finance; drive supply; one seat per sink; a tax seat for claims that cross legal entities
• Remit: the ranking rule and the cut line across the four sinks; exceptions from the pegging system; the decision log with overrides and brokered trades
• Rules it holds: the shortage rule; the ranking rule; the landing rule, which it ratifies
• Cadence: monthly, plus the quarterly supply review
• Overrides: logged with what moved down

Risk-budget record argued

• Cohort: model, firmware, power-on-hour band
• Cohort cap per redundancy group, the group's failure tolerance, and who set it (reliability engineering)
• Chance of a cohort loss beyond tolerance within one repair window
• Evidence bar per tier, the outcomes it rests on, and the date it last rose
• Incident cost bound, and who signed it (finance)
• Draws on the bound to date
• Next review date

Mechanism audit checklist (for G0, when a program exists) argued. Fill the last column in the days 1–5 interviews. The strategy page names six to check first.

Interview guide (days 1–5) argued. Two or three questions per group; record each answer as a fact, an assumption or an ask.

• Reverse logistics and data-center operations: What happens to a pulled SSD, step by step? Where does it wait, and for how long? Who signs each handoff?
• Drive security engineering: Which erase method runs for which sink? How is an erase validated? What does the cage hold today?
• Lifecycle transitions and finance: Was reuse ever evaluated and declined? On what numbers? Who decides when a host retires?
• Flash platform engineering: Which health fields exist per model? Which firmware versions have known faults?
• Spares planning and supply chain: Which legacy models have last-time buys open? What do the resale contracts pay, and what volumes do they require?
• Supply chain, on the memory-reclaim program: Which gates did it cross, and which stopped it?

Decision note (decision note)

• The decision
• What was known
• When, and by whom
• What would have changed it
• The trigger to revisit it

Where this comes from #

• Seed paper:
  • Sections 4, 5.2–5.4, 6 and 6.1–6.7.
  • Sections 8.2, 9.1–9.3, 10 and 10.1–10.4.
  • Sections 12, 13 and 14, and Appendix A.
• The case: the full case, its team map, scenarios, signposts and stated assumptions.
• The reasoning: the strategy page.
• Studies cited on this page. Other operators' and researchers' fleets, cited as analogies; none is Kuantillion Cloud's:
  • Schroeder and Gibson, Disk failures in the real world, USENIX FAST (2007): https://www.usenix.org/legacy/event/fast07/tech/schroeder/schroeder_html/
  • Xu, Zheng, Qin, Xu and Wu, Lessons and Actions: What We Learned from 10K SSD-Related Storage System Failures, USENIX ATC (2019): https://www.usenix.org/conference/atc19/presentation/xu
  • Schroeder, Lagisetty and Merchant, Flash Reliability in Production: The Expected and the Unexpected, USENIX FAST (2016): https://www.usenix.org/conference/fast16/technical-sessions/presentation/schroeder
  • Ford, Labelle, Popovici, Stokely, Truong, Barroso, Grimes and Quinlan, Availability in Globally Distributed Storage Systems, USENIX OSDI (2010): https://www.usenix.org/conference/osdi10/availability-globally-distributed-storage-systems
  • Maneas, Mahdaviani, Emami and Schroeder, A Study of SSD Reliability in Large Scale Enterprise Storage Deployments, USENIX FAST (2020): https://www.usenix.org/conference/fast20/presentation/maneas
  • Wei, Grupp, Spada and Swanson, Reliably Erasing Data From Flash-Based Solid State Drives, USENIX FAST (2011): https://static.usenix.org/event/fast11/tech/full_papers/Wei.pdf
  • NIST, Guidelines for Media Sanitization, SP 800-88 Rev. 2 (2025): https://doi.org/10.6028/NIST.SP.800-88r2
  • Baldenius, Internal Pricing, Foundations and Trends in Accounting (2008): https://doi.org/10.1561/1400000013
  • Alter, Xue, Dimnaku and Smirni, SSD Failures in the Field: Symptoms, Causes, and Prediction Models, SC (2019): https://par.nsf.gov/servlets/purl/10172650

Every number on this page is illustrative unless the case tags it otherwise.