Chapter 4 — Storage Administration and the Weight of Data

“Data is the new oil.” — Clive Humby, 2006

“a time to keep, and a time to cast away.” — Ecclesiastes 3:6 (ESV)

Why This Matters

Storage is the discipline everyone thinks is solved until the day it isn’t. You provision a volume, you mount it, it works, and for years storage administration looks like nothing more than watching a df percentage creep upward and ordering more disk before it hits 100. Then artificial intelligence arrives in your estate, and the ground moves under you. A single 70-billion-parameter model in half precision is 140 gigabytes of weights that must sit on fast storage and load into VRAM in seconds. A vector database backing one modest RAG system is ten million embeddings that quietly consume sixty-plus gigabytes before you have indexed a single one of them. A fine-tuning dataset is a legal artifact you may be required to retain for a decade and to describe, in detail, to a regulator. Storage just became the most expensive, most regulated, and least forgiving surface you administer.

This is the chapter where the book’s thesis gets heavy — literally, in bytes. AI is your most powerful tool and your most demanding workload, and storage is where the workload’s demand is most concrete. You can hand-wave a CPU. You cannot hand-wave 810 gigabytes of FP16 weights for a 405B model; either the disk is there or the model does not load. So this week you will learn to do the one thing a senior storage administrator must do that a junior one cannot: size the estate before you buy it, in writing, with numbers you can defend.

Both AI threads run straight through storage, and you must hold both. AI as the tool you wield: the new generation of storage platforms ships an AI classifier that crawls your data, guesses its sensitivity, and proposes a tier — “this looks like PII, move it to encrypted warm storage; this hasn’t been read in a year, archive it.” That is genuinely useful and genuinely dangerous, because the classifier is a confident, fast, sometimes-wrong partner making recommendations about what to keep and what to delete. AI as the workload you run and govern: model weights, KV cache, embeddings, vector indexes, and training datasets are a new asset class with their own sizing math, their own failure modes, and their own governance regime. You will learn the napkin math for all of it — params times bytes-per-weight, num-vectors times dimensions times bytes, plus index overhead — because an administrator who cannot estimate the footprint cannot plan the budget, and an administrator who cannot plan the budget gets surprised, and surprise in storage means either an outage or a five-figure invoice.

And underneath the engineering sits the week’s question, which storage forces on you more bluntly than any other domain: what is worth keeping, and what must be let go? The Preacher in Ecclesiastes says there is “a time to keep, and a time to cast away” (Ecclesiastes 3:6, ESV). Every retention policy you write is an answer to that verse. Keep too little and you cannot reproduce a model, defend an audit, or recover from a ransomware event. Keep too much and you pay to store data you may not legally be allowed to hold, you widen your breach blast-radius, and you bury the signal under the noise. The discipline of storage is, at bottom, the discipline of deciding — deliberately, accountably — what abides and what is cast away. We will treat that as a real question, not a sermon, because the regulator, the budget, and the backup window will all treat it as a real question whether you do or not.

Coach’s Note — The fastest way to spot an administrator who has never run AI infrastructure is to ask them to size a 70B deployment on a whiteboard. The one who has done it writes 70 × 2 = 140 GB at FP16, ~35–40 at INT4, add 25% for KV cache and framework, so a 48 GB card is my floor in fifteen seconds. The one who hasn’t says “it depends, I’d have to look it up.” This week you become the first kind. The math is not hard. Not knowing it is just expensive.

4.1 — Storage Fundamentals: Block, File, Object

Before AI, the baseline. You know what a disk is; you may not have had to choose between the three ways a system presents storage, and AI workloads make the choice matter again. There are three abstractions, and they are not interchangeable.

Block storage hands an application a raw, addressable volume — a sequence of fixed-size blocks — with no notion of files. The application (usually a filesystem or a database) imposes its own structure on top. Block is the lowest-level, lowest-latency option: a SAN LUN, an AWS EBS volume, a local NVMe namespace. You reach for block when you need raw IOPS and a single writer — a database, a model-serving node’s local scratch.

File storage presents a hierarchy of directories and files over a network protocol — NFS or SMB — so many clients can mount the same tree. This is your NAS. It is convenient and shareable, and it is where teams want to dump model weights and datasets because everyone can reach them. Convenience has a cost: network filesystem latency and metadata overhead that can throttle the random reads a model loader does at startup.

Object storage abandons the hierarchy entirely. Data is stored as objects in a flat namespace, each with a key and metadata, reached over an HTTP API — S3 and its hundred compatible cousins. Object storage scales effectively without bound, is cheap per gigabyte, and is the natural home for datasets, model checkpoints, and backups. Its tradeoff is that it is not a filesystem: you GET and PUT whole objects, you do not seek into the middle of one cheaply, and consistency and latency semantics differ from a local disk.

The 2026 pattern worth knowing: model weights increasingly live as OCI artifacts in a registry, or are mounted from object storage into a serving pod via a CSI driver, precisely so you get object storage’s economics and a registry’s provenance instead of copying 140 GB files around by hand. Hold that — we return to it in §4.5 and in Chapter 11.

4.2 — RAID, SAN, NAS, and the Two Numbers That Define a Disk

RAID — Redundant Array of Independent Disks — combines drives for redundancy, performance, or both. You must know four levels cold, because the choice trades capacity against survivability against speed.

• RAID 0 stripes across drives for speed, with zero redundancy — one drive dies, all data dies. Acceptable only for reproducible scratch.
• RAID 1 mirrors — two copies, survives one drive loss, costs you half your raw capacity.
• RAID 5 stripes with one parity block — survives one drive failure, with a painful rebuild window during which a second failure is fatal.
• RAID 6 stripes with two parity blocks — survives two simultaneous failures, the sane default for large slow archive arrays where rebuilds take many hours.
• RAID 10 (1+0) mirrors then stripes — the performance-and-redundancy choice for databases and hot AI data, at the cost of half your capacity.

RAID is not a backup (Chapter 11 will hammer this). RAID survives hardware failure; it does nothing against rm -rf, ransomware, or a corrupt write faithfully mirrored to both copies.

SAN versus NAS is block versus file at the datacenter scale: a SAN delivers block storage over a dedicated fabric (Fibre Channel or iSCSI) and your servers see raw volumes; a NAS delivers file storage over the LAN and your servers mount shares. SAN for raw performance and databases; NAS for shared trees.

Now the two numbers that decide whether a disk is fit for an AI workload, and that beginners conflate constantly:

• IOPS — I/O operations per second — measures how many discrete reads/writes you can do. It governs random, small-block work: a database, a vector index doing scattered lookups, a model loader pulling many shards.
• Throughput — megabytes or gigabytes per second — measures how much data you can move sequentially. It governs streaming a 140 GB weight file off disk and into VRAM.

A spinning disk gives you maybe 150 IOPS and decent sequential throughput. A modern NVMe SSD gives you hundreds of thousands of IOPS and several GB/s of throughput. The gap is why you do not serve a model’s weights off an HDD: cold-start latency — the seconds between “deploy” and “ready to answer” — is dominated by how fast you can read the weights, and on a slow disk a 70B model can take minutes to load.

Coach’s Note — When someone says “the storage is slow,” your first question is always slow at what — IOPS or throughput? They are different bottlenecks with different fixes. A vector database starved for IOPS and a model loader starved for throughput look identical in a Slack message and need opposite hardware. Name the number.

4.3 — Tiering, Capacity Planning, and Watching the Curve

You cannot afford to put everything on NVMe, and you do not need to. Tiering matches data to media by how hot it is: NVMe SSD for hot data that is served live (model weights, the active vector index), SATA SSD for warm data, HDD RAID for cold data accessed rarely, and an archive class (S3 Glacier-style, retrieval measured in hours) for data you must keep but almost never read. The policy in code/data_classification.yaml encodes exactly this, with an illustrative target cost per GB-month per tier — roughly $0.20 hot, $0.08 warm, $0.02 cold, $0.004 archive as of 2026 (verify against your own vendor; these move). The order-of-magnitude spread between hot and archive is the whole reason tiering exists: get the cold 80% of your bytes onto cheap media and your storage bill collapses.

Capacity planning is forecasting. You measure current usage and growth rate, project the curve forward, and provision before you hit the wall — with a buffer, because most filesystems and many vector indexes degrade well before 100% full (past ~85% is a useful alarm line). The audit script code/storage_audit.sh gives you the raw inputs: df for capacity and headroom, lsblk to see which devices are rotational versus SSD, du to find the largest consumers, and an atime-based scan for cold-tier candidates. Run it read-only, off-peak, and you have the numbers to forecast instead of guess.

AI changes the shape of the curve. Traditional data grows roughly linearly with users. An AI estate grows in step functions: nothing, nothing, nothing, then someone fine-tunes a model and you gain 140 GB of irreplaceable weights overnight; then RAG goes live and you gain a vector index that grows with every document ingested; then a second model lands. Capacity planning for AI is less “extrapolate the line” and more “inventory the planned step functions and sum them” — which is exactly what this week’s project makes you do.

4.4 — Sizing Model Weights: Params × Bytes-per-Weight

Here is the single most useful piece of arithmetic in this book. A model’s weight footprint is, to first order:

bytes = parameters × bytes-per-weight

Bytes-per-weight is set by the numeric precision you store the weights in:

Run the rule across the common sizes and memorize the shape of the table:

Two facts fall out immediately and you should be able to state both without looking. First, a 48 GB GPU is the practical floor for serving a 70B model at INT4 with modest context — 35–40 GB of weights plus headroom does not fit on a 24 GB card. Second, a 405B model at FP8 (~405 GB) fits inside a single 8×H100 node (640 GB aggregate VRAM) but nothing smaller. Quantization — the deliberate trade of precision for memory — is the lever that moves the entire bill, and the knee of the curve sits around INT4/Q4_K_M, where you have roughly quartered your footprint while keeping most of the quality. The sizing calculator in code/estate_sizer.py computes this whole table; run it and confirm the numbers match what you can do in your head.

That last clause is the point of teaching the math by hand: you must be able to do it in your head, because in Phase 2 an agent will write your deployment manifest and you need to know in one glance whether it asked for a card that can physically hold the model.

4.5 — The KV Cache: The Memory the Sizing Tables Forget

The weight tables above are weights only, and weights-only is the number that gets people in trouble. A serving model also needs the KV cache — the stored keys and values for every token already in the context window, the thing that lets the model attend to what came before without recomputing it. The KV cache lives in VRAM, it is not on the weight tables, and at long context it can exceed the weights themselves. The formula:

KV bytes = 2 × num_layers × num_kv_heads × head_dim × bytes_per_element × context_length × batch_size

The terms that blow up are context_length and batch_size: serve many users (batch) at long context and the KV cache grows linearly in both. At 32K–128K context the cache routinely exceeds the weight footprint. Grouped-Query Attention (GQA) shrinks it by sharing key/value heads, which is why modern models use it. The practical consequence for you, the storage and capacity administrator, is the rule of thumb: real deployed VRAM runs roughly 15–40% above weights-only. code/estate_sizer.py bakes a 25% headroom factor into its deployed_vram_gb() for exactly this reason.

This is also where the storage/compute boundary blurs. The KV cache is VRAM, not disk — but in 2026’s disaggregated-inference designs the cache is shuttled between machines over the network, and “where does the KV cache live” becomes a storage and networking question we pick up in Chapter 5. For now, the discipline is simple: never quote a VRAM budget as weights-only. Add the headroom. The administrator who forgets the KV cache sizes a node that OOMs the first time a user pastes a long document.

4.6 — Vector Databases and Embedding Storage: The Other Half of the Estate

Weights are the workload people expect. Embeddings are the workload that quietly doubles the estate. Every RAG system, every semantic search, every “chat with your documents” feature converts text into embeddings — fixed-length vectors of floating-point numbers — and stores them in a vector database for nearest-neighbor search. The sizing is, again, napkin math:

bytes = num_vectors × dimensions × bytes_per_component

Bytes-per-component depends on how you store each number: 4 for float32, 2 for halfvec, 1 for int8, and 0.125 for binary quantization. A worked example you should internalize: one million 1536-dimensional float32 vectors is about 6.1 GB raw, before any index. Scale that to ten million and you are at sixty-plus gigabytes for the vectors alone. Then add the index. The near-universal index is HNSW (Hierarchical Navigable Small World), a graph whose overhead is roughly 8 × M bytes per vector, where M is the graph’s connectivity (typically 16–64; recall plateaus past ~32–64). A common OpenSearch-style estimate is ~1.1 × (4 × dims + 8 × M) bytes per vector all-in.

The lesson the math forces is that raw vectors dominate, so quantize them. Storing vectors as int8 instead of float32 cuts the footprint ~4× at a small recall cost; binary quantization (BBQ, RaBitQ) can cut it ~32× while holding ~95% recall on the right data. And Matryoshka Representation Learning lets you truncate a 1536-dim embedding to 256 dims for typically ~2–3% quality loss and ~4× storage savings — you store fewer dimensions of the same vector. The administrator who knows this turns a 60 GB index into a 15 GB one with a config change.

Which store? There are three architectures, and the choice is a real engineering decision:

The default recommendation for a team that already runs Postgres is pgvector until the index hurts — roughly 5–10M vectors, past which HNSW build time and memory push you to Qdrant or Milvus. The starter in code/pgvector_setup.sql builds exactly this: CREATE EXTENSION vector, a halfvec(1536) column to halve storage, an HNSW index, and the real-world hnsw.iterative_scan = 'relaxed_order' fix for the “overfiltering” bug where a restrictive WHERE clause starves a plain HNSW scan.

Coach’s Note — Pinecone’s tier minimums are confirmable (Starter $0, Builder $20, Standard $50, Enterprise $500 per month, as of 2026), but per-unit read/write rates change constantly — defer to the vendor’s live pricing page in any real plan, and write that habit into your runbook. Quoting a stale managed-vector-DB price in a budget memo is how you end up explaining a 3× overrun to a finance committee.

4.7 — The Embedding Model and the Datasets Behind It

Before you can store a vector, something has to produce it, and that choice has a storage consequence the napkin math makes obvious. The embedding model sets the dimensions — the dims term in N × dims × bytes — and dimensions are a direct multiplier on your entire vector estate. A model that emits 3072-dim vectors costs exactly twice the storage of one emitting 1536, for the same number of chunks. So embedding selection is not only a retrieval-quality question; it is a sizing question.

As of 2026 the field splits into closed APIs and open weights. Closed: gemini-embedding-001 ($0.15/M tokens), OpenAI text-embedding-3-small ($0.02/M) and -large ($0.13/M), Cohere Embed v4 ($0.12/M), the Voyage 4 family — you send tokens, you pay per token, the vectors come back, and the text leaves your building. Open-weight, self-hosted: Qwen3-Embedding, BGE-M3, Jina v5, nomic — you run the model, you pay in GPU, and the data never leaves. For a ministry holding pastoral and donor records, that data-residency line is often the deciding factor, not the MTEB leaderboard (whose scores trade places monthly and should be read as dated snapshots — Qwen3-Embedding-8B ~70.6, gemini-embedding-001 ~68.3 at launch, as of 2026). And Matryoshka Representation Learning is now standard across the good models, which is why the §4.6 truncation trick works: the model was trained so its first 256 dimensions carry most of the signal.

The datasets are the third asset class, and the one people forget to budget. There is the RAG corpus itself — the source documents you embed, which you must keep because the vector index is reproducible only if the source survives (§4.6, Chapter 11). There is, if you fine-tune, the curated training dataset — small, hand-labeled, expensive to build, and irreplaceable. And there is the raw collected data behind both. Datasets are usually object-storage residents (cheap per gigabyte, §4.1), but two of them — the fine-tuning set and any PII corpus — carry governance weight far heavier than their byte count: they are exactly the data the regulator asks about. Which is the bridge to governance.

4.8 — Data Governance: Retention, Classification, Lineage

Now the part that is not about bytes at all, and that AI made unavoidable. Data governance is the set of decisions about who may hold what data, where, for how long, and with what record of where it came from. For an AI estate, four governance artifacts are now load-bearing:

• Classification. Every dataset gets a sensitivity label — public, internal, restricted (PII / special-category) — and the label drives both the storage tier and the controls. code/data_classification.yaml shows the shape: a restricted training set carries encryption_at_rest: required, a bounded retention_days, and legal_basis_documented: true.
• Retention. How long you keep each class, and — just as important — when you delete it. “A time to cast away” is a retention policy. Logs may need WORM (write-once-read-many) retention; scratch embeddings should expire in 30 days.
• Lineage / provenance. For any model or dataset: which base model and which data produced it. This is not bureaucracy. Under the EU AI Act Article 10, high-risk systems must document dataset quality, examine for bias, identify gaps, and record provenance; and providers of general-purpose AI must publish a “sufficiently detailed summary” of training-data content using the AI Office’s template, while respecting text-and-data-mining opt-outs under the EU Copyright Directive. (The Act’s high-risk timeline is in flux as of mid-2026 — the Digital Omnibus would defer Annex III obligations to December 2, 2027, but that deferral is not yet formally adopted; treat the date as provisional and re-confirm.)
• The AI bill of materials. An AIBOM — CycloneDX ML-BOM or SPDX 3.0 — is an ingredients label for an AI system: which weights, which datasets, which configs. Model cards and data cards (datasheets) are the human-readable companions. We build these properly in Chapter 14; here you only need to know that storage is where these artifacts live, and that a model without a recorded lineage is, increasingly, a model you are not allowed to ship.

The administrator’s job here is to make governance a property of the storage layout, not a spreadsheet someone updates quarterly. Encryption at rest, retention windows, WORM locks, and lineage tags should be enforced by the tier and bucket policy — config, not goodwill.

4.9 — AI as the Tool: Assisted Classification, Tiering, and Lifecycle

Now the other thread. The same AI you are storing weights for is also being sold to you as a storage tool. Modern data platforms ship an AI classifier that crawls your unstructured data and proposes labels — “this directory looks like it contains PII,” “these files haven’t been read in 200 days, archive them,” “this dataset resembles your restricted class, encrypt it.” AI-assisted tiering watches access patterns and recommends moving cold data down and hot data up. AI-assisted lifecycle management flags retention violations and stale data. Used well, this turns the atime scan at the bottom of code/storage_audit.sh — a list of files nobody has read in 180 days — from a raw signal into a ranked, explained recommendation. That is real leverage; a human cannot eyeball ten million files.

And here is the spine of the whole book, stated for storage: the classifier proposes, but the human disposes. A confident, fast, sometimes-wrong partner recommending what to delete and what to expose is exactly the place over-trust does the most damage. The classifier that mislabels a restricted clinical dataset as “internal” has just told you it is safe to move PII onto an unencrypted, broadly-readable tier. The lifecycle bot that flags a “stale” directory for deletion may be looking at the one cold backup of an irreplaceable fine-tuned model. AI gets you the ranked list in seconds — the typing, the crawl, the first-pass triage. You own the verdict on every label that changes a control or destroys data, because the accountability for a wrongly-deleted dataset or a wrongly-exposed record lands on a human, and a model cannot be held accountable.

The working rule: let AI classify and rank freely; require a human ratification gate before any AI-proposed label change crosses a control boundary (encryption, access, deletion). Log every AI recommendation and every human decision — that log is itself a governance artifact. This is the same “AI proposes, humans gate, the system logs” pattern you will see in every chapter of this book; storage is just where it guards data instead of infrastructure.

4.x — Interactive Lab: AI Estate Sizer

Below this chapter on the website is an interactive panel called the AI Estate Sizer. It is the napkin math of §4.4–§4.6 turned into knobs, and you should not move past this chapter until you have played with it until the numbers feel obvious.

Do this. Pick a model size — 7B, 8B, 13B, 70B, 405B — and a quantization, and watch the panel compute the weights-on-disk and the deployed VRAM (weights plus the KV-cache and framework headroom of §4.5). Then add a vector-database block: set the number of vectors, the dimensions, and the bytes-per-component, and watch it add raw-vector storage plus HNSW graph overhead to give you a total estate size. Drive a 70B from FP16 down to INT4 and watch 140 GB collapse toward 35–40. Drive a ten-million-vector index from float32 to int8 and watch it shrink ~4×. Truncate the dimensions from 1536 to 256 and watch Matryoshka do its work.

What it teaches is the instinct this whole chapter is built to give you: storage for AI is dominated by two numbers — bytes-per-weight and bytes-per-vector — and quantization is the lever on both. When you can predict the panel’s output before you release the slider, you can size an estate on a whiteboard in front of a budget committee. That is the skill. The panel is the gym; the whiteboard is the game.

4.10 — The Steward and the Cast-Away: What Is Worth Keeping

The Preacher’s catalog of seasons includes a line that storage administration makes uncomfortably literal: “a time to keep, and a time to cast away” (Ecclesiastes 3:6, ESV). Every storage decision you make is a vote on that verse. And the AI estate sharpens it, because the data now divides into categories with radically different answers.

Some data is irreplaceable — a fine-tuned set of weights that cost compute and a curated dataset to produce, a hand-built prompt library, the curated training data itself. Cast that away and it does not come back; you re-derive nothing. It must be kept, backed up (Chapter 11), and treated as a first-class asset. Other data is reproducible — a vector index that can be rebuilt from its source embeddings, scratch embeddings, derived caches. Keeping it is a convenience, not a duty; you may cast it away to save money and rebuild on demand. And some data is liability — PII you no longer have a legal basis to hold, training data whose provenance you cannot defend. Here “cast away” is not thrift but obligation: keeping it is the sin, and the retention policy that deletes it on schedule is the faithful act.

This is stewardship in the precise LCMS sense. You did not create this data; it is entrusted to you, and “it is required of stewards that they be found faithful” (1 Corinthians 4:2, ESV). Faithfulness is not hoarding — the steward who keeps everything is not careful, he is afraid, and his fear costs the organization money, widens its breach exposure, and breaks its compliance. Nor is faithfulness reckless deletion. Faithfulness is discernment: knowing which is the irreplaceable thing to guard, which is the reproducible thing to let go cheaply, and which is the liability to be rid of in obedience. The hardest cases are the ones where keeping and casting-away both feel like loss, and there the steward must decide and own the decision — which is exactly why you cannot delegate the verdict to a classifier. The AI can sort the ten million files by access date. It cannot tell you which silence in that list is a forgotten treasure and which is dead weight. That discernment is your vocation, and it does not transfer to the tool.

An unbelieving reader can drop the theology and keep the engineering intact: classify your data by reproducibility and liability, keep the irreplaceable, release the reproducible, and delete the liability on a schedule you can defend. The Preacher just got there three thousand years early, and named the thing the budget and the regulator both confirm — that wisdom is knowing the time for each.

4.11 — Common Pitfalls

Pitfall: Sizing a deployment on weights-only and forgetting the KV cache. Example: You provision a 24 GB card for an INT4 70B “because the weights are ~38 GB” — except 38 > 24 already, and even an 8B model at long context OOMs when the cache balloons past the weights. Fix: Always quote deployed VRAM as weights × ~1.15–1.4. Compute the KV cache for your real context length and batch size (§4.5). Never put weights-only in a budget.

Pitfall: Treating RAID as a backup. Example: A node on RAID 10 gets hit by ransomware; the encryption is faithfully mirrored across both copies, and “redundant” storage holds two perfect copies of the damage. Fix: RAID survives hardware failure only. Back up separately — 3-2-1, immutable/WORM, air-gapped (Chapter 11). RAID is not a time machine.

Pitfall: Letting the AI classifier’s label cross a control boundary unreviewed. Example: The classifier labels a restricted clinical dataset “internal,” lifecycle automation moves it to an unencrypted, broadly-readable warm tier, and you have an exposure incident born of a confident wrong guess. Fix: Let AI classify and rank freely; gate every label change that touches encryption, access, or deletion behind human ratification. Log both the recommendation and the decision (§4.9).

Pitfall: Forgetting that raw vectors, not the index, dominate the vector estate. Example: You budget for “the HNSW index” and are blindsided when ten million 1536-dim float32 vectors eat 60+ GB before the graph is even built. Fix: Size raw vectors first (N × dims × bytes), then add ~10% for HNSW. Quantize to int8/halfvec/binary and consider Matryoshka truncation before buying disk (§4.6).

Pitfall: Provisioning storage to ~100% before adding more. Example: A filesystem at 96% slows to a crawl and an HNSW build fails for lack of working space, mid-ingest, in production. Fix: Alarm at ~85%, provision with a buffer, and plan AI growth as step functions (a new model, a new index), not a smooth line (§4.3).

Pitfall: Storing a model or dataset with no recorded lineage. Example: Audit time arrives and you cannot say which base model and which data produced a deployed fine-tune — so you cannot answer an EU AI Act Article 10 provenance question or reproduce the model. Fix: Make lineage a property of the storage layout: tag every weight and dataset with its provenance, keep a model card/AIBOM beside it (§4.8, Chapter 14). A model without lineage is increasingly a model you may not ship.

Pitfall: Quoting a managed vector-DB or storage price as if it were stable. Example: A budget memo cites last quarter’s per-unit Pinecone rate; the rate changed; the bill comes in 3× and you own the overrun. Fix: Quote tier minimums you can confirm, mark per-unit rates as “as of , verify live,” and link the vendor pricing page in the runbook (§4.6 Coach’s Note).

4.12 — Reps

The reps for this week live in the exercises. They make the napkin math muscle memory and the governance instinct real. A preview of where you are going:

• Run code/storage_audit.sh against a real tree and read the weight of your own data — capacity, rotational vs SSD, cold-tier candidates.
• Hand-compute the weight footprint for 7B/13B/70B/405B at FP16/INT8/INT4, then check against code/estate_sizer.py. Predict before you measure.
• Stand up pgvector in Docker from code/pgvector_setup.sql, load vectors, measure the on-disk size, and reproduce-then-fix the overfiltering bug.
• Re-size a vector index across float32 → int8 → binary and across 1536 → 256 dims, and quantify the savings.
• Write a real retention/classification decision for one dataset and defend the keep-or-cast-away call in two sentences.

This week’s AI policy (Phase 1): for every rep, do the sizing and the classification by hand first, then — where a rep invites it — ask an AI for the same answer and grade it. You own the verdict. You cannot direct an agent to right-size a GPU node or set a retention policy in Phase 2 if you have never sized an estate or written a retention rule yourself. Build the instinct now.

A short Check Your Reps quiz is embedded on this page, below the lab — five questions straight from this chapter. Take it before you start the reps.

4.13 — This Week’s Project

The project is P4 — “Size the AI Estate”, specified in Project 4. You will inventory a planned AI deployment for a ministry — a local LLM plus a RAG vector store plus datasets — and produce a defensible sizing-and-storage plan: the weight and VRAM footprint of the model at a chosen quantization, the vector-DB footprint at a chosen precision and dimension, the tier each asset belongs on, a retention and classification policy, and a total estate size with a cost estimate.

At a high level: Normal tier sizes the model and the vector store correctly and lays out tiers — the napkin math, defended. Medium tier adds the KV-cache headroom, a quantization trade study (what you save and what it costs in quality), and a real pgvector build with a measured on-disk size against your prediction. Hard tier demands the steward’s judgment an agent cannot supply: a written keep-or-cast-away policy for each asset class — irreplaceable, reproducible, liability — with the retention windows, the lineage requirements, and a defense of the line you drew. The build is mechanical; the recommendation is the grade.

4.14 — Coach’s Final Word

Storage is where this book stops being abstract. A CPU you can hand-wave; a process you can restart. Bytes you cannot argue with — either the 140 gigabytes fit on the card or the model does not load, either you kept the irreplaceable dataset or it is gone. This week you learned to size the AI estate before you buy it, in numbers you can defend on a whiteboard: params times bytes-per-weight, vectors times dimensions times bytes, plus the KV cache and the index overhead the naive tables forget. That arithmetic is the difference between an administrator who plans and one who gets surprised, and surprise in storage is always either an outage or an invoice.

Both AI threads ran through every section, and you held both. You sized AI as a workload — its weights, its cache, its embeddings, its governance — and you weighed AI as a tool, the classifier that crawls your data and proposes what to keep and cast away. And you kept the line the whole book defends: the classifier ranks the ten million files in seconds; you own the verdict on every label that encrypts, exposes, or deletes, because accountability does not transfer to a model. AI accelerated the triage. You owned the decision.

And the decision is the heart of it. “A time to keep, and a time to cast away” is not poetry you bolt onto a retention policy — it is the retention policy, the same question the Preacher asked and the regulator and the budget now ask again. The faithful steward is not the one who hoards every byte in fear, nor the one who deletes in carelessness, but the one who discerns — guarding the irreplaceable, releasing the reproducible, and being rid of the liability on a schedule he can defend. You did not make this data. It is entrusted to you. Be found faithful with it.

Do the reps until the math is automatic. Then size the ministry’s estate for real.

See you next week.

Up next: Read the exercises and put the napkin math into your fingers, then build Project 4 — Project 4: Size the AI Estate. Set up your environment with Appendix A; for the local and cloud AI pieces (Ollama, pgvector, embeddings) see Appendix B; the agentic-AI rules that govern Phase 2 are in Appendix C. Previously: Chapter 3 guarded who may reach the data; next, Chapter 5 — Network Services and the Watch on the Wire, where the KV cache you just met goes over the wire and the GPU cluster’s interconnect decides whether your inference scales at all.