diff --git a/canon/principles/doing-less-enables-more.md b/canon/principles/doing-less-enables-more.md
new file mode 100644
index 0000000..c255565
--- /dev/null
+++ b/canon/principles/doing-less-enables-more.md
@@ -0,0 +1,113 @@
+---
+uri: klappy://canon/principles/doing-less-enables-more
+title: "Doing Less Enables More — The Inversion Principle for Substrate Design"
+audience: canon
+exposure: nav
+tier: 2
+voice: neutral
+stability: semi_stable
+tags: ["canon", "principle", "inversion", "substrate", "doing-less", "vodka-architecture", "design", "TCP-IP", "unix-pipes", "HTTP", "dial-tone"]
+epoch: E0008.4
+date: 2026-05-02
+derives_from: "canon/principles/vodka-architecture.md, canon/principles/kiss-simplicity-is-the-ceiling.md, canon/principles/dry-canon-says-it-once.md, canon/values/axioms.md"
+complements: "canon/principles/prompt-over-code.md, canon/principles/maintainability-one-person-indefinitely.md"
+governs: "Substrate-design decisions across all programs in this canon: oddkit, AMS, future MCP servers, future protocol-grade work. The empirical principle behind why vodka architecture wins where opinionated stacks lose. Recommended frame for evaluating any substrate proposal."
+status: active
+---
+
+# Doing Less Enables More — The Inversion Principle for Substrate Design
+
+> A substrate wins by refusing to own layers above it. Every opinion the substrate adopts is a layer the substrate must defend forever, and a layer that the layers above cannot replace. The principle is empirical, not aesthetic: TCP/IP, Unix pipes, HTTP, oddkit, and AMS all instantiate it. Each was "too thin to be useful" by contemporary standards. Each enabled an ecosystem that opinionated alternatives could not host.
+
+---
+
+## Summary — The Empirical Claim
+
+Substrate-design wins by doing less. This is not "less is more" as aesthetic preference, not "minimum viable product" as lifecycle stage, not "keep it simple" as engineering virtue. It is a structural claim about what makes a layer host other layers: every opinion the substrate refuses to take is a layer above it that can be designed independently, replaced without coordination, and composed with peers the substrate never anticipated.
+
+The principle is the empirical observation behind `canon/principles/vodka-architecture.md`. Vodka architecture is the discipline that produces substrates. This principle is the claim about why the discipline pays.
+
+The lineage of working substrates is the proof. TCP/IP refuses opinions about the application; HTTP, SMTP, gopher, and a dozen things nobody had thought of yet were built on top. Unix pipes refuse opinions about what bytes mean; every Unix tool composes with every other. HTTP refuses opinions about payload type; REST APIs, GraphQL, gRPC-Web, server-sent events, and WebSockets all sit above it. oddkit refuses opinions about the domain; software architecture canon and oral theology corpus serve through the same ten actions. AMS refuses opinions about the agent; messages from any agent on any stack flow through it as opaque tokens.
+
+In each case, the substrate was contemporaneously criticized as too thin to be useful. In each case, the thinness was the property that made the ecosystem above possible.
+
+---
+
+## The Lineage in Detail
+
+**TCP/IP.** The OSI seven-layer model was the consensus answer in the 1980s for how networks should be structured. TCP/IP's four layers were widely judged insufficient — no presentation layer, no session layer, no clean separation of concerns the OSI design committees had identified as necessary. The thinness was the bet. The OSI stack got built into specs and rarely shipped to scale. TCP/IP got built into Berkeley sockets and became the substrate of the global internet. Every layer above (HTTP, SMTP, FTP, SSH, the things invented later) sits on TCP/IP because TCP/IP refuses to know what is above it.
+
+**Unix pipes.** Doug McIlroy's pipe primitive gave every Unix tool a single uniform interface: read bytes from stdin, write bytes to stdout. The bytes are uninterpreted. The pipe carries them. Every contemporary alternative — VMS's RMS records, MS-DOS's typed files, the various structured-IPC schemes — knew more about what the bytes meant and composed less. The bytes-are-bytes refusal is what made `ls | grep | sort | uniq | head` possible without anyone designing for that combination. The pipe is fifty years old and still the default.
+
+**HTTP.** HTTP's original design carried an opinion about hypertext documents and very little else. The MIME-type extension came later, and once it did, HTTP carried anything you could MIME-type — JSON APIs, image streams, video, audio, server-sent events, WebSocket upgrades, gRPC-Web, things invented decades after HTTP was specified. SOAP's contemporary insistence on owning the envelope, the contract, and the binding produced richer wire-level guarantees and a much smaller ecosystem. HTTP's "I carry whatever you tell me to carry" is the same bet TCP/IP made one altitude up.
+
+**oddkit.** The MCP server has ten composable actions. Not twenty. Not fifty. The same ten serve a 400+-document software architecture canon and a 26-document oral theology corpus without modification. Every action beyond the minimum is complexity the server carries forever; every governance opinion the server takes is a layer the canon cannot override. The thinness is what makes oddkit usable across knowledge bases the maintainer never anticipated.
+
+**AMS.** The Agent Messaging Service wire frames opaque tokens between subscribers and refuses to own identity, capability schema, authorization beyond the two-door minimum, payload format, transport, queue, registry, pricing dimension, or URL structure. Every entrant in the 2025–2026 agent-comms cluster (`ams://canon/principles/envelope-altitude-consensus`) bundles those layers into one envelope and calls itself a substrate. AMS's refusal to bundle is the substrate property; the cluster's bundling is what makes each entrant a vertical product instead.
+
+The pattern repeats because the structural force is the same.
+
+---
+
+## Why the Inversion Works
+
+Three forces compound to make doing less enable more:
+
+**Layered orthogonality.** A substrate that does N things commits the layer above to N decisions it cannot revisit. A substrate that does one thing leaves N–1 decisions to whoever needs them. Layer counts upward stack additively when the layers are orthogonal; they collapse multiplicatively when the layers are coupled. Substrate refusal preserves orthogonality at the layer above.
+
+**Composability under uncertainty.** The future cannot be designed for completely. A substrate that picks the right opinions in 2026 may be wrong in 2028. A substrate that picks no opinions stays right because the opinions live above it and can be replaced as understanding improves. TCP/IP did not know HTTPS would exist; it did not need to. The opinion lived one layer up and was added without re-grounding the substrate.
+
+**Maintenance asymmetry.** Every opinion a substrate adopts must be defended forever — backwards-compatibility constrains every future revision, every implementation must support the opinion, every consumer must reason about it. Every opinion the substrate refuses costs the substrate nothing and frees the layers above to evolve independently. The asymmetry compounds: substrates that refuse opinions get cheaper to maintain over time as the ecosystem above them grows; substrates that adopt opinions get more expensive to maintain forever as more parties depend on each opinion.
+
+Together these three forces explain why TCP/IP, Unix pipes, HTTP, oddkit, and AMS were each derided as too thin and turned out to be exactly thin enough.
+
+---
+
+## Smell Test — How to Detect a Violation
+
+A substrate-design proposal is violating this principle when:
+
+- **"While we're here, the substrate could just…"** — a feature added because it would be convenient at the substrate level rather than at the application level. The convenience is real. The convenience is also why this principle exists.
+- **"Most consumers will want…"** — a proposal that universalizes an application convention into a substrate requirement. If most consumers want it, they can build it once above the substrate and share it as a library; the substrate does not need to bake it in.
+- **"It's a small addition…"** — a proposal that argues from the size of the change rather than the location of it. Small additions to the substrate are not small if they commit the substrate to an opinion forever.
+- **"Without this we cannot…"** — a proposal that frames a missing substrate feature as blocking a use case the application could solve. The substrate is structurally permissive; if the application cannot do it, that is usually the application's job to figure out.
+- **"It would be more developer-friendly if the substrate handled…"** — developer-friendliness for a specific use case is the wrong optimization at the substrate layer. The substrate optimizes for hosting use cases its designers have not thought of yet, not for being convenient for the use case in front of you today.
+
+These smells are the same shape as the vodka-architecture smells (`canon/principles/vodka-architecture.md`). The two articles are two views of the same constraint: vodka architecture is the discipline; this principle is the empirical claim about why the discipline pays.
+
+---
+
+## Failure Modes — What Happens When You Violate
+
+**Substrate inflation.** Each opinion adopted at the substrate makes the substrate larger. Larger substrates have smaller ecosystems because each opinion forecloses some compositional possibility. Substrates that try to do everything end up doing one thing well — the thing the designers anticipated — and being unable to host the things they did not.
+
+**Replacement cost.** A substrate that knows about its layers above cannot easily be replaced when those layers evolve. Substrates that refuse opinions are replaceable substrate-by-substrate (TCP/IP can in principle be replaced by QUIC because the layers above HTTP do not depend on TCP's specific properties). Substrates that bundle opinions can only be replaced by reimplementing the bundle.
+
+**Forking under disagreement.** When a substrate carries opinions that some consumers disagree with, the consumers fork the substrate. This is the fate of opinionated protocols (the perpetual rebooting of "we should have one standard" in messaging, identity, and configuration). Substrates that refuse opinions never fork over them because there is nothing to disagree about at the substrate layer; disagreements happen at the application layer where they are cheap to resolve.
+
+**Marketing as proof.** Opinionated stacks defend themselves by demonstrating their richness ("look at all this protocol does"). Substrates defend themselves by demonstrating their absences ("look at all this protocol does not assume"). The defenses pull the products in opposite directions: opinionated stacks add features to win; substrates remove opinions to win. A substrate that is being asked to add features is being asked to lose.
+
+---
+
+## Relationship to Vodka Architecture
+
+`canon/principles/vodka-architecture.md` is the design pattern. This principle is the empirical claim. The relationship:
+
+- Vodka architecture says: *infrastructure should be thin, stateless, and domain-agnostic.*
+- Doing less enables more says: *the reason that pattern wins is structural, not stylistic — refused opinions become composable layers above; adopted opinions become irrevocable constraints below.*
+
+A reader who absorbs only vodka architecture might conclude that the discipline is an aesthetic preference. The empirical lineage in this principle answers the "why" — vodka discipline produces substrates that beat opinionated alternatives because the structural forces favor refusal. The two articles are complements: discipline and rationale.
+
+---
+
+## See Also
+
+- `canon/principles/vodka-architecture.md` — the design pattern this principle explains
+- `canon/principles/kiss-simplicity-is-the-ceiling.md` — the surface-area constraint that follows from this principle
+- `canon/principles/dry-canon-says-it-once.md` — the duplication-avoidance pattern that follows from this principle
+- `canon/principles/prompt-over-code.md` — the same pattern applied to governance specifically
+- `canon/values/axioms.md` — the foundational values this principle operates under
+- `ams://canon/principles/per-query-dynamic-orchestration` — one specific instance of this principle for agent orchestration latency budget
+- `ams://canon/principles/envelope-altitude-consensus` — another specific instance, naming what the 2025–2026 agent-comms cluster did differently
+- `ams://canon/principles/vodka-architecture-applied` — vodka discipline expressed for the AMS substrate
+- `ams://canon/constraints/permanent-non-goals` — an applied list of opinions one specific substrate refuses to own