Within a short span of public attention, one formulation about how an AI should maintain a wiki shows up as YouTube walkthroughs, Obsidian vault recipes, Claude Code starter prompts, personal “second brains,” research companions, and team memory experiments. The stacks differ. The frontmatter conventions differ. Whether the human stays in the ingest loop differs. What does not differ is the seed: a compressed idea about AI and knowledge that is small enough to paste into a coding agent and rich enough to generate a recognisable family of systems.

That cascade is the phenomenon this book is about. Not the celebrity of the messenger. Not a claim that someone invented wikis or agent memory. The fact that one compressed formulation is now enough for large numbers of people to generate their own software.

An AI-era design pattern is a sentence that generates a family of systems.

Popularisation root, not inventor myth

Agent-maintained memory, knowledge graphs, personal wikis, and compounding notes all predate any single 2026 gist. If you treat the cascade as proof of invention, you will learn the wrong lesson and mis-measure influence.

Andrej Karpathy’s public “LLM Wiki” note is load-bearing for this book because of what it compressed, not because private intent can be audited from the outside.¹ Claims here trace to that public text and to the observable cascade of tutorials and builds that cite the formulation. The discipline for measuring propagation ancestry — without mythologising reputation — is developed in the Cascade Ledger; we do not invent reply counts or repository tallies here.

What the public record shows is a popularisation root for a formulation: turn your messy world into a wiki your AI maintains — layers, operations, and roles stated abstractly enough that an agent can fill the rest.

What the cascade looks like without inventing numbers

You do not need a fabricated tally of repositories to see the shape. Independent builds re-state the same roles (human curates, AI maintains), the same three-layer instinct (raw / wiki / schema), and the same operations (ingest, query, health-check). Guides attribute the pattern explicitly; videos demo personal second brains; teams try corporate memory variants. That is a family forming around a seed — not a single product being downloaded.

Public kernel (compressed formulation)
        |
        +-- tutorial / guide expansions
        +-- personal second-brain builds
        +-- research / team memory experiments
        +-- domain-fitted variants (radar, CRM intelligence, ...)
        |
   Shared: invariant + roles + ops
   Local:  folders, entities, stack, UI

If the only thing shared were a celebrity name, you would see random software with a hashtag. What you actually see is related system kinds. That is the signal this book generalises into a framework.

The reader question

Why did one note spawn a family of systems — and how do you mint ideas with that property?

After this book you should be able to write a Generative Design Pattern card: problem shape, North Star sentence, known variants, carried failure shapes. You should also know which of your ideas are one compression pass away from being transmissible, and which are still slogans or local implementation documents in disguise.

What this book owns

We mint Generative Design Patterns: one artefact (the promptable design kernel / pattern card) and one engine (compress architectural truth until a human can carry it and an AI can expand it into a locally fitted system). The mass-custom future is the ecosystem-scale consequence of that engine, not a second mechanism.

What we deliberately do not own:

• The full design-evolution loop and candidate breeding — that is Replay-Driven Design Evolution.
• AI-as-user usability of agent-facing systems — that is Reflexive Agent Design.
• Signal-case product architecture in depth — that is The Signal-Case Queue; we mint it as a second pattern card only.
• Cascade graph mechanics — Cascade Ledger.
• Whether to fork an existing implementation — later sibling territory (open-source shortcut trap); named in prose, no invented URL.
• Private kernel compounding as personal moat — nuke-and-regenerate / worldview compression canon; we differentiate, we do not re-centre.

Thesis in one breath

The AI-era successor to the design pattern is a promptable kernel — a compressed North Star short enough for a human to carry and precise enough for an AI to regenerate — because when implementation is abundant, the scarce, transmissible asset is the sentence that reliably generates a family of locally fitted systems.

Part I names the pattern class and inverts the reuse hierarchy. Part II dissects the Karpathy kernel, develops the democratisation mechanic with public sources, and fills the first pattern card. Part III adds a second card, a counterexample, the mass-custom consequence, and a mint protocol you can run this week.

How to read the named people

Andrej Karpathy appears because a public formulation compressed architectural truth into something agents could expand. We analyse the text and the cascade, not private intent. Wes Roth appears in Part II as a public builder who documented a second-brain / LLM-wiki implementation; what he did is cited; what he “understood” is fenced as inference or generalised to non-programmer creators. Vendor names are used only when the public record supports the claim — if a shipping claim cannot be verified, it is dropped rather than asserted.

In 1994, Gamma, Helm, Johnson and Vlissides published the catalogue that made “design pattern” everyday engineering vocabulary: named solutions to recurring object-oriented problems, communicated so humans could share structure without reinventing every class hierarchy from scratch.² That work still matters. It is not what is scarce now.

When a competent coding agent can expand a clear intent into a working system, the scarce unit of reuse stops being “the sample structure you copy” or even “the reference repository you fork.” It becomes the promptable invariant you show the agent so it builds the version that fits this world.

Definition

A Generative Design Pattern says: when a problem has this recurring shape, give AI this compact North Star and let it generate an implementation fitted to the local world. You are not reusing a fixed class diagram. You are reusing a compressed intent structure that expands into a family of systems.

Short enough for a human to carry; precise enough for an AI to regenerate.

That is the bar. Too long and the pattern stops travelling — it becomes a local implementation document that only its authors will read. Too vague and it fails the family test: agents produce demos that share a buzzword and nothing else. The generative zone sits between those failures: abstract on purpose, operational enough that independent expansions still recognise each other as kin.

Promptable architecture

The cleanest one-line diagnosis of the Karpathy note is not “he built a product.” It is: he made the architecture promptable. The public gist is an idea file designed to be copy-pasted into an agent; it states that its job is to communicate the pattern and let the LLM figure out the rest.¹

That is a different intellectual object from a complete application and from a classical pattern catalogue. It is closer to a seed crystal than to a finished building.

OO said “organise objects this way”

Classical patterns spoke to humans who would write the code. Observer, Factory, Strategy, Composite — each said, approximately: when a problem has this recurring shape, organise the objects this way.² The AI-era equivalent says: when a problem has this recurring shape, give AI this compact North Star and let it generate an implementation fitted to the local world. So instead of reusing a fixed class diagram, you reuse a promptable invariant.

That shift is easy to understate. A class diagram still assumes a human will interpret structure into a codebase. A generative pattern assumes the expansion step is largely automated, so the scarce craft moves upstream into compression quality: problem shape, North Star, known variants, and failure shapes you can name before the first generate.

The carry / regenerate bar in practice

• Carry test: can a colleague recite the North Star without opening a doc, and still mean the same system kind?
• Regenerate test: can an agent, given only the card plus a local domain sketch, produce something a third party recognises as a family member?
• Omit test: if you delete stack names and local chrome, does the invariant survive? (Chapter 10 formalises this into a mint protocol.)

Fail carry and you have a private notebook. Fail regenerate and you have a slogan. Fail omit and you have a project plan dressed as a pattern.

What this is not (differentiation)

LeverageAI already has private-kernel canon: worldview recursive compression and nuke-and-regenerate are about your recipe compounding for you — the durable personal or team generation asset. The North Star Prompt is about orienting a model in a session with tight intent and loose method, without turning the prompt into a denial-of-service attack on the model’s intelligence.

Generative Design Patterns are the public, transmissible unit. They are what an ecosystem shares when it shifts from shipping reference implementations to shipping promptable seeds. Private kernels still matter. Session-level North Stars still matter. This book is about minting the sentence others will carry.

External voices already treat code as ephemeral and design intent as the durable asset.³ We take that climate as supportive weather, then push further: durability at sentence scale, with an explicit family of variants and an explicit grammar of failure.

Belief worth stating

We think the durable unit of reuse in agentic software is no longer the reference implementation by default. It is the promptable kernel — the sentence (and its short card) that survives contact with many local worlds. Spec-driven development culture is right that design should lead code;⁴ generative patterns push that further into compression at a scale humans can actually carry between rooms, companies, and coding sessions.

Every team has met the “reference implementation” that cannot be inherited. It works. It is documented. It encodes someone else’s North Star so thoroughly that adapting it costs more than generating a fitted system from a clearer seed. That experience is not a complaint about open source. It is a signal that the value order of reusable assets has flipped.

The hierarchy (definitive placement)

When coding agents can expand intent, reuse value looks like this:

Most valuable (carry & share)
  1. North Star / design kernel
  2. Domain distinctions (what must not be conflated)
  3. Thin reference architecture
  4. Schemas & eval cases
  5. Bounded libraries
  6. Complete application code
Least valuable (regenerate locally)

The North Star is scarce because it is hard to compress well and easy to fake with slogans. Domain distinctions are scarce because they encode hard-won “these are not the same thing” judgments. Thin architecture and schemas travel if they stay unopinionated about local missions. Bounded libraries still pay when interfaces are stable. Complete application code is the most locally opinionated artefact and the easiest to regenerate — which makes it the worst thing to treat as the primary unit of reuse.

People no longer download the reference implementation; they show the idea to their agent and say: build the version of this that fits my work.

Why the flip is rational

As the cost of generating and regenerating code falls, the asset that was expensive to recreate stops being the asset you protect first.⁵ Industry commentary that treats code as ephemeral and design intent as durable is describing the same inversion from another angle.³

A complete app is a bundle of local opinions: folder names, auth choices, entity schemas for that company, UI chrome for that audience. Those opinions are exactly what a generative kernel omits on purpose. Inherit the app and you inherit the opinions. Carry the kernel and you regenerate opinions that fit.

Economics, not aesthetics

Economies of Specificity — meeting the needs of one at near-scale cost when agents implement — is the economic frame that makes mass-custom application layers rational. Chapter 9 develops the ecosystem consequence. Here the point is narrower: if specificity is affordable, the hierarchy tells you where to invest attention. Invest in kernels, distinctions, schemas, and eval cases. Treat the application as a disposable expansion.

Standardise below the application (preview)

The healthy response to inverted reuse is not chaos. It is standardisation under the application layer: protocols, components, eval cases, interchange formats. Let applications go bespoke. Share the substrate that makes regeneration cheap and comparable. Part III returns to that Cambrian picture; the hierarchy above is the investment map that makes it coherent.

Where teams still mis-invest

• Polishing the app as the asset: months of local chrome, zero written North Star that could regenerate it.
• Documenting everything equally: hundred-page architecture dumps that no agent and no colleague will carry.
• Sharing only the repo: the fossilised investigation is useful as a mine of distinctions — extract domain distinctions upward; do not treat the code as the seed.
• Skipping eval cases: without schemas and evals in the middle of the hierarchy, regeneration cannot be checked for regression of intent.

A useful mental move: when you find a mature repository, ask what North Star and domain distinctions it encodes — not only how to run it. The repo becomes less like a free product and more like a fossilised design investigation. Its greatest value may not be the code. It may be the years of distinctions encoded in the code’s shape. Lift those into the hierarchy. Leave the bulk application as optional evidence.

Flagship proof starts with the public text, not with fan summary. Andrej Karpathy’s “LLM Wiki” gist presents itself as an idea file: copy it into a coding agent and collaborate on the specifics. It contrasts everyday RAG — re-discovering fragments on every question with no accumulation — with a persistent, interlinked markdown wiki the model builds and maintains between the human and the raw sources.¹

What is specified

• A problem contrast: RAG re-derives; the wiki compounds. Cross-references and contradictions are maintained over time, not rediscovered each query.
• Three layers: immutable raw sources; an LLM-owned wiki of summaries, entities, concepts; a schema document (CLAUDE.md / AGENTS.md) that makes the agent a disciplined maintainer rather than a generic chatbot.
• A role split: the human curates sources, explores, and asks; the LLM does the grunt work of filing, cross-referencing, and bookkeeping.
• Three operations: ingest, query, lint.
• Context examples without a product mandate: personal, research, business, competitive analysis — illustrations of fit, not a single SKU.
• Optional tooling metaphors: Obsidian as IDE, LLM as programmer, wiki as codebase — useful, not law.

The note states the method of its own transmission: it is intentionally abstract; it describes the idea, not a specific implementation; its only job is to communicate the pattern so the LLM can figure out the rest.¹

What is omitted

• Exact directory trees as non-negotiable law (only sketches).
• A fixed vendor stack.
• Domain schemas for your company, hobby, or research programme.
• Auth, multi-tenant policy, compliance packaging.
• UI chrome and product surface area.
• A complete application anyone could “just deploy.”

Those omissions are not negligence. They are the generative gaps. Every filled-in detail would be a local opinion that travels badly. The schema file is the hinge: you and the agent co-evolve conventions for your domain. The pattern says what kind of system should exist; the local world supplies the missing specification.

Why omissions generate families

Karpathy kernel (carried)
        |
        v
   Agent expands --> your folders, entities, CLAUDE.md, tools
        |
        v
   Contact with reality --> "I don't use it that way"
        |
        v
   Cheap modification --> fitted system (one member of the family)

The same invariant yields different systems:

• Personal second brain
• Corporate or team memory
• Coding-agent project wiki
• News / signal radar
• Customer intelligence desk
• Research corpus or book companion

That list is the family test in reverse: if independent builders keep landing in these shapes from the same seed, you are looking at a generative pattern, not a one-off app idea.

Cascade without fake numbers

Public tutorials, vault guides, and agent rulebooks citing the formulation are qualitative evidence of spread. Precise cascade depth, breadth, and high-authority descendants belong to measurement practice — the Cascade Ledger — not to vibes or invented tallies. For this book, Karpathy is the current-cascade popularisation root of the formulation under discussion. That is enough to dissect the kernel. It is not a claim about private priority in the history of knowledge management.

In usable form: the underlying value is a one-type sentence you can reasonably repeat to an AI — turn your big messy world into a wiki — and hold as North Star while the agent fills gaps. That is the seed. The family is what grows when many local worlds water it.

The kernel a non-specialist can hand over

Restate the compression without the gist’s full length:

Take a large, messy, evolving body of material and have AI continuously compile it into an interlinked wiki it can navigate and maintain.

That is small enough to hand directly to a coding model, yet rich enough to generate an entire family of implementations. A builder does not need the final schema, the ingestion architecture, the exact page taxonomy, the graph-maintenance algorithm, or a full retrieval design up front. They need enough direction that the AI’s priors can fill in a credible first organism. Then friction from real use — “this relationship is being lost,” “organise it around my content,” “that page is not useful” — reshapes the implementation while the compact kernel holds.

That is tight intent, loose method applied to whole architectures: the North Star directs the model without consuming its attention with a premature pseudo-specification.

Specified vs omitted (quick map)

If you fill the right-hand column into the public seed, you stop minting a pattern and start shipping a local product. If you empty the left-hand column, you are left with “build a second brain” — Chapter 8’s counterexample.

The democratisation claim needs a public case, not a myth. Wes Roth published a video walkthrough of building a “second brain” with Claude Code — an AI-maintained personal knowledge base in the LLM-wiki family, with ingestion and Obsidian as the browsing surface.⁶ Companion writing spells out the same pattern family in operational form: Raw / Inbox / Wiki folders, a CLAUDE.md rulebook, ingest that ripples across entity and concept pages, query that reads the index first and answers with citations, explicitly attributing the pattern to Karpathy’s formulation.⁷

What the public record supports

What we can say he did, with citations:

• Documented a personal AI-maintained wiki / second brain built with a coding agent.
• Used plain-text markdown and a human-browsable vault (Obsidian in the published materials).
• Operated with maintainer rules and ingest/query workflows in the same family as the Karpathy kernel.
• Published the result so others could copy the shape.

That is enough for the architectural argument. The agent wrote custom software fitted to a person’s use. The person did not need to hand-author a complete classical specification first.

Inference fence

What he understood mid-build, how completely he grasped the original note, or what formal computer-science background he brings are not facts we can read off a video title. My outside-in reading is that many creators in this cascade start without a full academic model of wikis, graphs, or agent memory — and they still converge on useful systems. Prefer the general form over biography:

A non-programmer creator needs (1) a reasonable North Star, (2) boundaries and access to the real environment, (3) judgment about what is annoying in daily use. The agent supplies implementation knowledge. Reality supplies the missing specification.

“I don’t use it that way” is design evidence, not a bug report.

The mechanic

Reasonable North Star + competent generated implementation + contact with reality + cheap modification = converging fit. That is the democratisation loop. Credentials are not the bottleneck. Judgment and environment access are.

“Vibe coding” entered mainstream discourse as a name for feel-directed agent coding.⁸ The evolved form that matters here is not vibes as strategy. It is a held North Star, an agent that can implement, and the discipline to treat friction as design input. Excessive procedural specification can consume the model’s capacity and prevent it from filling the gaps it is now capable of filling — the same tight-intent, loose-method instinct as North Star prompting, applied to whole systems.

You do not need a complete specification. You need a sufficiently clear North Star, rapid contact with reality, and the discipline to move each lesson out of the patched code and back into the design.

What the builder did not need to know first

Generalising from public builds in this family — not from mind-reading any one creator — a non-programmer creator typically does not start with:

• the final schema,
• a full ingestion architecture diagram,
• exact page taxonomy,
• graph-maintenance algorithms,
• or a classical retrieval design.

They start with a carried kernel and access to a real workspace. Then they steer: automatic ingest for sources they care about; relationships that were being lost; organisation around their content; pages that are not useful; retrieval that should be easier. The AI reshapes the implementation while the compact North Star holds. That is democratisation as architecture, not as marketing: the scarce human inputs are judgment and environment access, not a computer-science degree.

Generating code around your own North Star

There is a harder economic corollary: generating code around your own North Star can be cheaper than adapting a mature system built around somebody else’s. That is why the inverted hierarchy (Chapter 3) and the open-source fork decision (a later sibling) matter. Here the democratisation point is simpler: once the seed is clear and the agent is competent, the barrier to a fitted first system is no longer “can you hire an engineering team?” It is “can you hold a North Star and recognise when reality disagrees?”

A Generative Design Pattern is reusable when another practitioner can hand it to an agent without you in the room. The card format forces the compression: if you cannot fill a slot, you do not yet have a pattern — you have a feature request or a slogan.

Four slots

1. Problem shape — the recurring pain across contexts, not your favourite technology.
2. North Star — one or two sentences: what kind of system should exist, who does the grunt work, what compounds.
3. Generated variants — at least three family members that share the invariant and differ in local world.
4. Failure shapes — how implementations go wrong while still “following” the words.

Agent Wiki Pattern (full card)

Problem shape, restated

The recurring shape is not “I want notes.” It is: a large, messy, relational corpus; new information arrives over time; repeated questions require accumulated understanding rather than isolated retrieval. Chat-native RAG answers the last question by re-deriving fragments. Humans abandon hand-maintained wikis because the bookkeeping grows faster than the value. The pattern targets that intersection: compounding structure without human librarian burnout.¹

Why variants prove the pattern

Personal second brain, corporate memory, coding-agent project wiki, news radar, customer intelligence, research corpus — the implementations change radically. Folders differ. Entities differ. Whether the human stays in every ingest differs. The pattern remains stable: AI-maintained interlinked wiki over immutable raw material under a schema. If your “variant” loses that invariant, it is not a variant; it is a different product wearing the same marketing words.

Why failure shapes are first-class

Variants show generativity. Failure shapes show that the North Star is falsifiable. Without them, every broken build can claim allegiance to the same sentence. With them, you can say: that implementation used the words and violated the invariant — it is not a family member, it is a failure mode.

Develop the failures briefly:

• Chat-log dump: sources land as pages with no ripple across entities and concepts — no compound structure.
• Human re-becomes librarian: the schema never disciplines the agent; maintenance load returns to the person.
• No schema thrash: each session invents conventions; the wiki does not cohere.
• Editing raw: source of truth collapses; provenance dies.
• Slogan capture: “second brain” without maintainer invariant (Chapter 8).
• Vendor over-spec: seed becomes “only works with stack X” and stops travelling.

What this card is not

Why agents need wiki-shaped memory rather than chat-native RAG is a substrate argument developed in prior work. This chapter does not re-derive that product doctrine. It packages the transmissible seed so the family can keep branching without each builder needing the full substrate lecture.

How to use the card

1. Paste the four slots into a coding agent with a short description of the local domain.
2. Co-evolve the schema file (CLAUDE.md / AGENTS.md) as conventions firm up.
3. After reality contact, update failure shapes and North Star wording — not only the code.
4. When patch debt accumulates, prefer regenerating from the sharpened kernel over nursing a one-off app forever (private nuke discipline is adjacent; here the public lesson is: lessons flow upward).

Short enough for a human to carry; precise enough for an AI to regenerate.

If Generative Design Patterns only described the Karpathy note, the framework would be a brand name for a single cascade. The second card proves portability: a different recurring pain, a different North Star, the same four-slot discipline.

The full product design of the signal-case queue — case lifecycle, merge/split, review rhythm, failure modes in depth — lives in its own book. Here we mint only the generative pattern card.

Signal-Case Queue Pattern (full card)

Why the problem shape is different from Agent Wiki

Agent Wiki is about compounding knowledge. Signal-Case Queue is about unresolved attention under a budget. You can have a beautiful wiki and still drown in an undifferentiated feed. You can also queue noise forever with no place for settled understanding to land. The pattern forces a split: the wiki holds what is known enough to navigate; the queue holds what still needs a decision, a review, or more evidence.

A case is not a tweet. It is an object with anchors (canonical and discovery sources), concept links, state, heat, uncertainty, and a next review. Queueing raw posts without that object is a failure shape, not a variant. Merging distinct claims into one mega-case to reduce count is another: you lose the ability to resolve or reopen cleanly.

Why this is still the same doctrine

Both cards compress a recurring system shape into a carryable North Star. Both list variants that prove family membership. Both name failure shapes so the words cannot be hollowed out. Neither ships a complete application as the unit of reuse. An agent given the Signal-Case Queue card and a domain description can generate a fitted attention system the same way an agent given the Agent Wiki card can generate a fitted memory system.

Same generative doctrine
  |
  +-- Agent Wiki card     --> memory / compounding family
  |
  +-- Signal-Case card    --> attention / unresolved-work family
  |
  +-- (your third card)   --> your domain's recurring shape

Related but not identical

Cascade measurement — influence as a receipt of propagation — is the instrumentation cousin of heat and lineage on cases, not the pattern itself. Do not collapse the queue pattern into the ledger, or the ledger into the queue. One is how you structure unresolved attention. The other is how you audit how claims travel.

Portability proof

Two cards are the minimum demonstration that the format is a tool, not a trophy for one celebrity note. After these two, the next exercise is yours: pick a recurring pain in your work and force it into the four slots. Chapter 10 turns that into a protocol. Chapter 8 shows what happens when the sentence fails the family test.

If the only test of a pattern were virality, every motivational slogan would qualify. The family test is stricter: give only the sentence to two competent agents (or two independent teams). Do the resulting systems share a recognisable invariant and differ mainly in local fit? If yes, you have a generative-pattern candidate. If they share only a buzzword, you have a slogan.

Counterexample: “Build a second brain”

As motivation, fine. As a kernel, it fails. It names a desire — externalised memory, less forgetting — without an expandable invariant. Who maintains what? What compounds? What is immutable? What are the operations? Agents given only the slogan produce random note apps, GTD clones, chat wrappers, and bookmark managers. They do not form a family. They form a marketing category.

The Karpathy compression succeeds where the slogan fails because it adds the maintainer split, the compounding wiki between human and raw sources, and schema-bound operations — still short enough to carry.¹ Same cultural neighbourhood as “second brain”; different generative power.

Counterexample: “Make it agentic” / tool-name-as-pattern

“Make it agentic,” “just use multi-agent,” and often “just use RAG” have the same disease when they name a fashion or a mechanism without a problem shape, a role split, or a failure grammar. You get a spray of architectures that cannot be compared or transmitted as one pattern. The words travel; the systems do not recognise each other as kin.

Tool names can appear inside a good pattern card as implementation hints. They cannot replace the North Star. “Use Obsidian” is not a generative design pattern. “AI maintains an interlinked wiki over immutable sources under a schema” can be one — with or without Obsidian.

The same trap appears when teams treat a vendor feature name as the pattern. A chunking library is not an Agent Wiki. An evaluation product is not Replay-Driven Design Evolution. Reuse the component if it sits below the application layer (Chapter 9); do not confuse a block for a seed, and do not assert that a vendor “shipped the pattern” unless the public record shows a product that matches the invariant. If you cannot verify, drop the claim.

The family test (operational)

1. Write only the candidate sentence (or four-slot card without stack law).
2. Expand twice: two agents, two domains, or two teams with no further coordination.
3. Ask: do the systems share an invariant a third party can name in one sentence?
4. Ask: do the differences look like local fit (entities, schema, tools) rather than unrelated products?
5. If no on either question — compress again or admit it is a slogan / app idea.

Almost-patterns and their failure modes

• Too complete: a fifty-page architecture document feels rigorous and will not travel. It is already an implementation opinion bundle (see the inverted hierarchy in Chapter 3).
• Too tool-specific: the seed dies when the stack changes; variants cannot form across tools.
• No failure shapes: every broken build claims allegiance; the North Star cannot be falsified.
• Desire without mechanism: “be more organised,” “use AI better” — no system kind.

Cascade heat is not a substitute for this test. A formulation can spread widely and still be a slogan; a quieter kernel can generate a coherent family. Measure propagation with a ledger when you care about influence; judge pattern quality with the family test when you care about reuse.

Worked contrast in one scene

Hand two agents only “build me a second brain.” One returns a todo app with AI chat. Another returns a vector store over PDFs. A third returns a calendar summariser. There is no shared invariant a third party can name without inventing one after the fact.

Hand two agents the Agent Wiki card from Chapter 6 plus a domain sketch (personal research vs sales team memory). Both produce raw-source immutability, an AI-owned wiki layer, a schema file, and ingest/query behaviour. Folders and entity names differ. A third party can still say: these are the same kind of system. That is generativity.

Mass-custom software is not a second framework. It is the ecosystem-scale consequence of generative patterns plus agent coding. When a kernel can be carried and expanded cheaply, missions that never justified a product manager or a SaaS SKU still get software — fitted to one person, one team, one desk.

From mechanism to ecosystem

One influential kernel
        |
        +-- interpretation A --> local system A1, A2, ...
        |
        +-- interpretation B --> local system B1, B2, ...
        |
        +-- interpretation C --> local system C1, C2, ...

Shared substrate below the app layer:
  protocols · components · eval cases · interchange formats

The application layer goes Cambrian: many species, short-lived individuals, rapid local fit. That is not chaos if the layer underneath is where standards live. Protocols, bounded libraries, eval cases, and interchange formats make regenerations comparable and portable. Complete applications stay disposable expansions of seeds (Chapter 3 hierarchy).

Economics of specificity

Economies of Specificity describe why this is rational: agent-enabled individuals and small teams can meet the needs of one at near-scale cost, because coordination overhead collapses and iteration accelerates. Generative Design Patterns answer a different question: what seed should those teams carry so the custom systems still form families instead of pure one-offs with no learning between them?

Specificity without kernels is a thousand disconnected demos. Kernels without specificity is a forced standard application. The interesting future is both: shared seeds, local expansions.

What mass-custom is not

• Not “no standards.” Standards move down a layer.
• Not “everyone forks the same mega-repo.” Forking alien North Stars is a different trap (open-source shortcut territory — named only here).
• Not private worldview compounding as the centre. Your personal kernel still compounds for you; this chapter is about ecosystem structure around public seeds.

Role of cascades

Cascades show which formulations are fit to travel. They do not prove pattern quality by themselves (Chapter 8). When you need to know whether a seed is actually propagating — and through whom — use cascade measurement discipline rather than reputation folklore.

Boundaries for this book

How a design evolves after generation — replay, candidates, build boundary — is Replay-Driven Design Evolution. How AI users stress agent-facing systems is Reflexive Agent Design. This chapter only places mass-custom as the consequence of promptable seeds: invest in what travels; regenerate what is local.

The seed travels. The codebase does not have to.

What to build as shared infrastructure

If applications go Cambrian, the shared layer should prefer:

• Protocols and interchange: how cases, walks, or wiki pages move between tools.
• Bounded libraries: chunking, lint passes, index helpers — not full products with alien North Stars.
• Eval cases and golden paths: so regenerations can be scored against intent, not only against “it runs.”
• Pattern cards themselves: the public seeds of Chapter 6 and 7, refined as failure shapes accumulate.

What not to force into the shared layer: complete mission-shaped applications. Those are the expansions. When vendors ship partial building blocks, reuse the block if it sits below the app; do not confuse a library with a generative pattern, and do not assert product claims you have not verified (for example, do not claim a vendor “shipped the Agent Wiki” unless the public record shows that — if uncertain, drop the claim).

The book is useless if it only teaches you to admire someone else’s cascade. The point is to mint. Take an idea you keep explaining on calls and force it into a Generative Design Pattern card someone else can carry.

Six-step mint protocol

After generation

Contact reality early. “I don’t use it that way” is design evidence. Then do the hard part: move the lesson out of the patched code and back into the North Star, the schema, or the failure shapes. That is how the seed sharpens. Nursing patches forever is how you get a disposable app with no transmissible IP.

You do not need a complete specification. You need a sufficiently clear North Star, rapid contact with reality, and the discipline to move each lesson out of the patched code and back into the design.

Anti-patterns checklist

• Inventor prestige over compression quality.
• Shipping long specs as if length equalled transmissibility.
• Unverified vendor claims (if you cannot confirm a product shipped, drop the claim).
• Absorbing design-evolution loops, fork decisions, or private-kernel compounding into this card — those are other books.
• Confusing cascade heat with family coherence.

Worked micro-example of the omit test

Suppose your draft North Star reads: “Build an Obsidian vault with Claude Code, Pinecone, and our company SSO that stores meeting notes as a second brain.” Run the omit test. Strip SSO, Pinecone, Obsidian, and meeting notes. What remains? If nothing operational remains, you had a project plan, not a pattern. Rebuild until something like this survives: “Compile ongoing organisational exhaust into an AI-maintained interlinked wiki over immutable sources, under a schema the team co-evolves.” Then re-add local fit only in the expansion, not in the carried seed.

Close

When implementation is abundant, the scarce, transmissible asset is a promptable kernel: short enough for a human to carry, precise enough for an AI to regenerate a family of locally fitted systems. That is the AI-era successor to the catalogue pattern. The Agent Wiki and Signal-Case Queue cards are worked instances. The counterexamples show what fails. Mass-custom software is what happens when many people carry good seeds.

The only reuse question that still scales:

Is this a sentence someone else can carry — and an AI can expand into a family?