diff --git a/writings/the-policy-set-is-the-blueprint.md b/writings/the-policy-set-is-the-blueprint.md
new file mode 100644
index 0000000..c5f7246
--- /dev/null
+++ b/writings/the-policy-set-is-the-blueprint.md
@@ -0,0 +1,106 @@
+---
+uri: "klappy://writings/the-policy-set-is-the-blueprint"
+title: "The Policy Set Is the Blueprint — Your Code Was Only Ever Its Derivation"
+audience: public
+exposure: draft
+tier: 2
+voice: first_person
+stability: draft
+tags: ["policy-as-blueprint", "regeneration", "prompt-over-code", "dolcheo", "validation-gate", "ai-development", "bulldoze"]
+
+public: false
+type: "essay"
+slug: "the-policy-set-is-the-blueprint"
+hook: "You took the advice — protect the blueprint, not the code. Then you tried to regenerate the app and got a different one. The blueprint you kept was too vague to build from."
+description: "Bulldoze the App said protect the blueprint. This is what the blueprint turned out to be: a set of named, versioned policies, each one paid for by a real building pain, with the code derived from them and citing them back. Swap the policies and the variations fall out for free."
+date: "2026-07-17"
+epoch: "E0010"
+og_description: "The blueprint was never a diagram. It was a policy set — and the code was only ever its derivation."
+companion: "klappy://canon/principles/bulldoze-but-keep-the-blueprint, klappy://writings/artifacts-are-projections"
+---
+
+# The Policy Set Is the Blueprint — Your Code Was Only Ever Its Derivation
+
+> *Bulldoze the App, Keep the Blueprint* said the code was never the asset and the blueprint was. It left "blueprint" as a gesture. The blueprint is a policy set: named, versioned rules, each one earned from a specific building pain. The code is a derivation of them: self-building, because you regenerate it from the policies; self-documenting, because it cites the policy it came from. The loop that keeps it honest: reality rubs against the current build, a running ledger catches the observations, tensions, learnings, constraints, and decisions, and those hand off into policy that gets written, amended, or retired. Every build is audited against the whole policy set before a line is written; a PRD forms; then the code. Swap the policies and the variations fall out for free, because the variation lives in the blueprint, not in bespoke code. Infinite versions of the same app, at the same quality, sharing one set of DNA.
+
+## Summary — The Blueprint You Kept Was Supposed to Be a Rulebook
+
+If you took the advice to protect the blueprint instead of the code, you may have discovered the same gap I did: nobody said what the blueprint actually was. So you kept a folder of notes, a README, some diagrams, and when you regenerated the app, you got a different app. Close, but not the same. Why?
+
+Here is the sharper version. The blueprint is a set of policies. A policy is one rule, stated plainly enough to build from and narrow enough to check against, and every real one was bought with a specific pain you do not want to pay again. The code is downstream of the policies — you derive it from them, and you make it cite them, so any line can be traced back to the rule that put it there. Reality keeps rubbing against the build and generating friction; you catch that friction in a ledger; the ledger hands off into the policy set; the next build is audited against the whole set before it starts. Do this a few times and something strange becomes ordinary: you can throw the app away and get the same app back, or change three policies and get a different app that is just as trustworthy, without hand-writing the difference.
+
+## You Took the Advice and Still Couldn't Rebuild It Twice
+
+The parent argument was that code stopped being the scarce thing. When generation gets cheap, variation explodes, maintenance becomes a tax, and understanding old output can cost more than regenerating it. So you protect what makes regeneration safe. Fine. I believed it. I still believe it.
+
+But "protect the blueprint" is only useful if you can say what a blueprint is, and for a long time I couldn't. So why couldn't I rebuild the same thing twice? I had intent in my head, constraints in a chat transcript, decisions in a commit message I'd never find again. When I regenerated, the model filled every gap I'd left with something plausible, and plausible is not the same as decided. The second build drifted from the first not because the model was wrong, but because I had never written down the thing it drifted from.
+
+What does a blueprint have to be, then, if the test is "regenerate and get the same house"? It has to hold every decision that the drawing implies but the drawing doesn't state. In software that is not a diagram. It's a rulebook.
+
+## A Policy Is a Pain You Only Pay Once
+
+Where does a policy actually come from? Watch, and you stop treating it as bureaucracy. Every good one is a scar.
+
+You ship a build. It does something you didn't want — drops a record, trusts an input it shouldn't, solves the wrong problem confidently. You feel the friction. If you're disciplined, you don't just fix the bug; you name the rule that would have prevented it and you write the rule down. Now the pain is load-bearing. It stops being a memory you'll lose and becomes a constraint the next build inherits whether or not anyone remembers the incident.
+
+That is the difference between a note and a policy. A note says "remember the time the import wiped the record." A policy says "the store is the source of truth; a projection is regenerated, never reconciled back into the store" — and it says it in a form the next build is checked against. The note decays with you. The policy outlives the session, the model, and your memory of why you were angry.
+
+Each policy is hard-won on purpose. If it didn't cost something, it probably isn't protecting anything.
+
+## The Code Derives From the Policy, and Says So
+
+What turns a pile of rules into a blueprint you can build from? Two properties, and both are things the code does, not things you do.
+
+The first is that the code is self-building: you regenerate it from the policies rather than carrying it forward by hand. The policy set is the input; the build is the output. When the build is disposable and the policies are durable, "start over" stops being a defeat and becomes a button. You are not throwing away work. You are re-running the blueprint.
+
+The second is that the code is self-documenting in a specific, unusual sense — it cites its policy. Not a comment explaining what the function does. A reference to the rule that caused the function to exist. When a line of code points back to the policy it derives from, three things get easier at once: you can audit whether the build actually honors the rule, you can find every place a rule reaches when you change it, and you can tell the difference between a line that encodes a decision and a line the model invented to fill a gap. A build whose parts can't name their reasons is a build you have to trust on faith. A build that cites its policies is one you can check.
+
+## The Loop: Reality Rubs, the Ledger Catches, the Policy Rules
+
+None of this holds still, which is the point. The world keeps moving, and a frozen rulebook rots as surely as frozen code. So how does a policy set learn?
+
+The mechanism is a loop with four beats. Reality rubs against the current build: a bug, a surprise, a constraint you didn't know you had, a decision you finally made out loud. A running ledger catches the friction as it happens, sorted into the kinds of thing it is: observations of what actually occurred, tensions you haven't resolved, learnings you'd give an apprentice, constraints that must hold, decisions and why one path beat another. (Internally I call it the DOLCHEO ledger; the name matters less than the habit.) At a breakpoint, the ledger hands off into the policy set: a new policy is written, an old one amended, a stale one retired. Then the next build is audited against the whole combined set before a line is generated. That audit is where the plan, the PRD, forms, and only then the code.
+
+The ledger is the short-term memory; the policy set is the long-term memory; the audit is the immune system that keeps the two honest. Skip the ledger and friction evaporates between sessions. Skip the handoff and you relearn the same lesson forever. Skip the audit and the policies become decoration nobody builds against.
+
+## One Turn of the Wheel
+
+What does one full turn actually look like? Here is the loop turning once, on a real system I work in. I'll keep it truthful about what's documented and where the edges are.
+
+The store came first — a single-writer store with a board projected on top of it. The pain was concrete and destructive: an import ran as a full replace and wiped a record that had been created the day before. Not a crash. A quiet deletion that looked like success. The record's title had to be rebuilt from its id and from memory, which is exactly the situation you never want to be in, because memory is the thing that fails.
+
+That friction went into the debrief, and the debrief produced a ruling instead of just a patch. The rule that came out: provenance is the one pinned invariant (who, which tool, which model, which role, when), and everything above it is allowed to flex. The store is the source; the board is a projection; the projection is regenerated, never reconciled back into the store. A second policy came from the same wound: every store needs an export path and a restore test, because the risk that actually bites is the one with no way back.
+
+Then the discipline that ties the beats together: no PRD, no execution. Planning's required output is a plan, and a build cannot launch without one. So the next build didn't start from a vibe. It started from a PRD that had been audited against the policy set — including the two rules the wipe had just written.
+
+The build ran. And the wheel closed where it was supposed to: at the gate. A fresh-context validator, a reviewer that had not spent the session creating the work, audited the change before it could merge. It caught dropped content, restored three pieces the build had silently lost, and separately confirmed that a concurrent write hadn't been clobbered. The data loss that started the turn was the exact failure mode the gate was now built to catch. That is one turn of the wheel: a pain, a rule, a plan, a build, and a gate that refused to let the same wound reopen.
+
+I'm compressing here. Those beats are real but they span days, not one clean afternoon, and I'd rather you know that than believe a tidier story than the record supports. The shape is what's true: friction became policy, policy shaped the build, and the gate enforced the policy against the build.
+
+## Swap the Policies, the Variations Fall Out for Free
+
+So what do you actually buy with all this rule-writing? Here is the payoff that makes the discipline worth its cost. If the variation between two versions of an app lives in bespoke code, every version is a new maintenance burden and a new place to drift. If the variation lives in the policy set, a different version is a different set of rules pointed at the same machinery.
+
+Want the same app for a stricter domain? Change the constraints that define "strict" and regenerate. Want it for a team that can't be offline versus one that mostly is? Swap the policies that encode that assumption. The build changes because its blueprint changed, not because someone hand-edited a fork that now has to be maintained forever. Same DNA, different expression. The quality holds across variations because the thing that guarantees quality, the audited policy set, is shared, and only the deltas differ.
+
+That's the bet: infinite variations of the same app, at the same quality, because the variation was never in the code. It was always in the blueprint.
+
+## Where This Holds, and Where It Doesn't
+
+So where does this stop being true? A working rule, not a law of nature, and I'll hold it until an artifact-first workflow beats it for this kind of work.
+
+It holds where the build is genuinely derivable from stated rules: tools, pipelines, apps whose behavior you can specify and check. It holds best where being wrong has real consequences, because that's where the cost of writing the policy down is obviously less than the cost of the pain repeating.
+
+It does not hold where the artifact is the asset. A codebase whose value is years of accumulated runtime behavior no document captures, a system under regulatory continuity requirements, anything where the running thing itself is the irreplaceable part — protect those directly. And the discipline has a real price. Writing policies is work, keeping the ledger is work, and a policy set can rot into ritual just like anything else: rules nobody builds against, an audit that rubber-stamps, a gate that waves everything through. The failure mode of a checklist is checklist theater, and a policy set is a large checklist. If the rules aren't earned and enforced, you've built a beautiful blueprint for a house nobody's checking.
+
+I'd retract the strong version of this the day someone regenerates a complex, trustworthy system from bespoke code faster and more reliably than from a policy set. I haven't seen it. I've seen the opposite, more than once.
+
+## Start With One Rule You Paid For
+
+Where do you start? Not with a policy set. With one policy.
+
+Take the last build that hurt: the one that dropped something, trusted something, or solved the wrong problem with total confidence. Don't just fix it. Name the rule that would have stopped it, write the rule down where the next build will be checked against it, and make the next build cite it. One scar, converted into a constraint that outlives your memory of the scar.
+
+Do that a few times and you'll notice the app has stopped being the thing you protect. The rules are. And the day you delete the app on purpose and rebuild it from the rules, the same app only cleaner, you'll understand what the bulldozer was pointing at the whole time. Not the drawing. The rulebook underneath it.
+
+*See also: [Bulldoze the App, Keep the Blueprint](klappy://canon/principles/bulldoze-but-keep-the-blueprint) — where the claim that code was never the asset began. [Artifacts Are Projections](klappy://writings/artifacts-are-projections) — the view from the artifact looking back at its source.*