Guilds of the Crown — Game Design

This is the why the code answers to. Every system in source/ should be traceable to a pillar in this document. When a system can’t be — when you can’t say which pillar it serves — that is a smell, not a feature. Build top-down from here, not bottom-up from whatever a system happens to make possible.

This is a design document: the picture, not the implementation plan. It contains no code and no task tickets. Where the current code and this vision disagree, that is called out explicitly as a ⚠ Tension — those are the most valuable lines in the file, because they are the tangles you felt but couldn’t name.

Shared vocabulary for cross-cutting terms — relationship, standing, and the rest — lives in design/glossary.md. When a word keeps causing confusion, pin it there before it spreads.

1. Vision & fantasy

You are a merchant dynasty clawing for control of a single medieval town. You build a business — workshops, mines, farms, trade — grow it across generations, and use that economic muscle to seize political power, until rival dynasties are driven out and your family sits on the town council.

The control feel is indirect command, in the lineage of Majesty and Dwarf Fortress: you do not puppet individual characters frame by frame. You express intent, and characters carry it out. The world keeps running whether you act or not.

It is a sandbox with teeth. There is no scripted campaign and no victory screen to chase. But it is not a toy either — rival dynasties are real opponents fighting for the same town on the same terms, and you can be beaten. The pleasure is the open-ended climb; the stakes are that the climb can end.

2. The control model — the architectural spine

This is the load-bearing wall of the entire game. Read it twice.

Everything in the world happens through tasks. A task is a unit of intent posted onto a building or character — gather this, craft that, go sell, hire a worker. Characters claim tasks and execute them step by step. The task system is not a system among many; it is the single seam between intent and action. Nothing acts except by posting a task, and nothing is acted upon except by a task being executed.

What makes this powerful is that intent has many sources but one output. A building is driven by a controller — the swappable “brain” that decides which tasks get posted onto it. There are several kinds of brain, and they all emit the exact same tasks:

                 ┌─ Player (manual)            ┐
                 │   you click the shop and     │
                 │   post orders yourself       │
                 │                              │
   CONTROLLER ───┤─ Auto policy                 ├──►  TASKS  ──►  Characters
   (a building's │   a rule runs the shop:      │    (the one          execute,
    swappable    │   produce what sells, hire   │     substrate)       step by
    brain)       │   to fill slots              │                      step
                 │                              │
                 ├─ Delegate (family member)    │
                 │   "Boris runs these shops";   │
                 │   his skill/traits decide     │
                 │                              │
                 └─ Dynasty planner (AI)        ┘
                     coordinates ALL the
                     dynasty's buildings at once

Three consequences fall out of this, and they are the reason the whole design hangs together:

1. Player and AI are the same thing wearing different hats. They both post tasks into the same pipeline. Switching a shop between “I run this by hand” and “run itself” is, in principle, a single tick box — you are just swapping which brain is allowed to post tasks onto that building. There is no separate “AI code path” and “player code path”; there is one path, fed by different brains.

2. The world is symmetric. Rival dynasties are not special-cased opponents with bespoke AI. They are dynasties exactly like yours, their buildings driven by controllers exactly like yours. Anything you can do to them, they can do to you, because it is literally the same machinery. This symmetry is a design commitment, not an accident — it keeps the game honest and keeps the code from forking into “player stuff” and “enemy stuff.” Rival AI is therefore not a subsystem at all — a rival is a dynasty whose topmost controller (the Elder) runs on Auto, exactly the toggle you can flip on your own house to hand it to the AI, CK3-style. Full model: design/rival-ai.md.

3. Control is a property of the building, not the system. Each building carries “who is currently driving me.” That field is what the tick box flips, what delegation reassigns, and what the AI reads to know which buildings are its responsibility.

Positions: every brain needs a living vessel

The four-brain sketch above is the first approximation. The refinement: a brain is not free-floating — it must be seated in a living family member. This is what makes player and AI genuinely symmetric. Without it, AI behaviour would be flavoured by character traits and the player’s wouldn’t, and the symmetry would be a lie. So control splits into two layers:

Layer 1 — the position (the vessel). A seat that must be filled by a living family member before anything can happen, at two scales:

• Dynasty offices — a slate of seats: the Elder (head), plus specialists such as a Treasurer, a Trademaster, and so on. Each office’s holder confers a dynasty-wide modifier in its domain — the Elder a production bonus across all shops and better election odds, the Treasurer finance, the Trademaster trade prices. More offices means more capable members you need.

• Building managers — before you can post a single order to a building, you must seat a family member as its manager. The manager’s traits modify that building’s performance.

Layer 2 — the control mode (how the vessel is driven). Once a manager is seated, you choose how their intent is set: manual (you post the orders yourself, through the manager) or delegated (the manager runs the building autonomously — the “auto policy” / planner brain). The manager’s traits colour performance in both modes — delegating doesn’t add the traits, manual doesn’t strip them. The human is always in the loop; you are only choosing who decides. That is the true source of player↔AI symmetry: both are a family member in a seat, differing only in whether a person or a rule sets the intent.

Two rules give the family real weight, for player and AI alike:

• Overload diminishes the good and amplifies the bad. Spread one member across many shops and their strengths dilute while their flaws compound. You cannot run an empire off one brilliant cousin — both sides are pushed to breed, raise, and spread capable members. This is what turns family from flavour into a scarce, managed resource (and loops into §4 and the hard-loss condition).

• A vacant seat bites, scoped to its tier. A building with no manager accepts no orders; an empty office lapses its bonus. The Elder seat auto-passes to the oldest living family member, so it is never transiently empty — the only way to lack an Elder is to have no members, which is the hard loss (§6). Death is never a mere stat adjustment: it vacates seats and, at the top, turns the dynasty’s page (a new Elder’s traits differ). Full model: design/dynasty.md §4.

Authoritative position model: design/positions.md unifies the vessel layer — one definition (seat = controller domain + modifier + posting rights) and three classes: the fixed cabinet (Elder, Treasurer, Trademaster, Marshal — Matron parked), dynamic building managers, and council seats won via politics. It is the reconciliation of the position framings scattered across dynasty.md, controllers.md, and politics.md.

⚠ Tension: positions, offices, and traits do not exist yet

The whole position layer — dynasty offices with domain modifiers, per-building manager assignment, traits that modify production/prices/elections, the overload curve, paralysis-on-vacancy — is unbuilt. DynastyFamilySystem tracks family members, but seats, trait-driven modifiers, and the assignment UI are greenfield. This layer is also the linchpin of the player↔AI symmetry, so it is not optional polish — without it, §2’s central claim doesn’t hold.

⚠ Tension: today there is exactly one brain, and it is bolted on

WorkshopSystem currently is a controller — the “auto policy” one — but it is hardwired and unswappable. It walks every workshop and greedily posts its Hire/Craft/Sell/Gather tasks, with no notion that a building might be driven by the player, a delegate, or a coordinating planner instead. There is no “controller” concept in the code yet; there is one brain, welded to every shop.

This is the gap between the code and the vision, and it reframes much of the recent confusion (see §7). The fix is not “more systems” — it is introducing the controller concept so the existing brain becomes one option among several rather than the only law.

Full model: design/controllers.md goes deep on this layer — a controller is a dynasty position bound to a domain; positions coordinate by passing declinable orders and asking each other for judgments; an unfilled seat switches off a part of the dynasty’s brain; and the four-brain sketch above collapses into “a manager is always seated; Auto is a toggle on top of it.” Production is its first worked example.

3. The core loop

At the heart of the economy, one loop repeats at every scale:

gather → produce → sell → reinvest → expand influence

Raw materials are gathered or extracted; workshops turn them into goods; goods are sold for coin; coin buys more buildings, more workers, more political leverage; leverage clears the board of rivals so you can do it all at greater scale. The gather → produce half — the building archetypes, the specialized chain shops trade along, leveling, and the rules that stop it deadlocking — is its own model: design/production.md.

This loop runs at three nested time horizons, and good play means thinking at all three at once:

The art of the design is that the same task substrate serves all three: the player’s generational ambition and the worker’s next thirty seconds are expressed in the same currency — tasks.

The market the loop sells into is a real, dynamic one: prices move with supply and demand around a guaranteed floor, demand is driven by a few town demographic numbers, and the distant Crown reaches in with events (wars, famines) that swing what’s profitable. Full model — pricing, demand, the money supply, taxes, and the Kingdom Events layer: design/economy.md. The Crown layer is itself a designed pillar (see below).

The Crown & Kingdom Events — a designed pillar

The outside world. There is one town and one market — no second city, no caravans. The rest of the kingdom exists abstractly as the Crown, an environmental force (not a negotiating party) that reaches into the local market through Kingdom Events. Designed in design/crown.md, completing the hooks design/economy.md §6 registered. The Crown is three things at once: flavour (announced events — “The Crown marches to war”), chaos (timed swings in what’s profitable, so the market never solves), and a sanctioned “cheat” (when the market seizes, the City injects supply to restart it). The shape:

• An event is a timed bundle of pool-modifiers — a data row carrying one or more effects, each one of exactly four kinds (demand+ / supply− / supply+ / tariff) pushing on the same demand/supply pools the market already has (design/economy.md §3). It adds no new market machinery; an event just turns an existing knob, for a while, with a name on it.

• Two triggers, one atom. Ambient events fire on a weighted timer (the war/famine churn); the relief valve (crisis import — a supply+ injection on a critical good pinned at the scarcity cap) fires reactively, off the random table, as the City controller’s call — the economy’s tailspin escape hatch.

• One read-only panel — active events, their effects in plain terms, days remaining. You read the Crown and react; you do not act on it.

• Parked (the “earn complexity on a proven base” discipline): real Crown diplomacy — petitions, royal favour, charters as a played system — is a future layer, cousin to the parked inter-dynasty diplomacy.

4. The generational layer

The dynasty is mortal, but your viewpoint is not. You always watch from the dynasty’s perspective — unlike Crusader Kings, control never jumps into a specific heir’s body when someone dies. You are the steady will of the bloodline. But the bloodline itself is flesh: characters age, and characters die.

This makes family members a triple-purpose resource, which is what gives the generational layer real mechanical weight instead of mere flavour:

• Skilled labour — a talented family member is your best craftsman.

• Delegates — a trusted member becomes a controller, running a cluster of shops with their own skill and temperament (§2). Grooming a capable heir and handing them shops to run is the same act.

• Political vessels — a council seat must be occupied by a living member (§5). Your bloodline is the resource that physically holds your political power.

Because members serve all three roles, succession is not cosmetic — you must keep producing and raising heirs not in order to keep playing, but in order to keep holding power and running your holdings. A dynasty that stops making children stops being able to govern its empire, then stops existing.

The position system (§2) is the concrete mechanism that makes this true. Every dynasty office and every building manager is a seat that consumes a living member, and the overload rule punishes you for stretching too few members across too many seats. So family size is a hard constraint on how large an empire you can actually run, and a death that empties a key seat is a real crisis (§2, “hard paralysis”). This is the bridge between the generational layer and everything else: members are not background population, they are the literal fuel the control model burns.

⚠ Tension: verify how much of aging/death/succession exists

This pillar assumes characters age, die of old age, reproduce, and that the dynasty tracks its living members. DynastyFamilySystem and CharacterSystems are the likely homes for this, but the depth of the aging/death/heir loop should be verified against the code before building on it — it may be partial or absent.

5. Power & victory pressure

The town is governed by a council, and a seat on it confers real mechanical power over the whole town — not prestige points. A seat-holder can pull levers that affect every dynasty: setting taxes, granting or denying building licences, imposing trade tariffs. The council is therefore not a scoreboard; it is a weapon, and the central prize of the political game.

Seats are won by election, and this is where the position layer (§2) reaches into politics: a candidate’s charisma and traits swing the vote. So the same family member who buffs your production also carries your political campaign — another reason the right person in the right seat matters, and another way a succession crisis can cost you the town.

The council is a closed oligarchy of five offices — Mayor, Chamberlain, Magistrate, Procurator, Sheriff — in a rank pyramid where office-holders elect office-holders and power cascades from the Mayor down. Each seat is held by a living family member and pulls its own levers (tax, courts, guards, banishment). Full model — offices, powers, elections, the crime engine, the money loop: design/politics.md.

You drive rival dynasties out on three reinforcing fronts:

• Economic — outproduce and undercut them, buy out their buildings, starve them of materials, bankrupt them.

• Political — use council power to tax them, deny them licences, and tariff their trade into the ground.

• Force — guards and enforcers (a §2 position) defend your businesses and attack rival characters and buildings; criminal workshops steal from and sabotage rivals. This is the Crime & conflict pillar (see below).

The fronts feed each other: economic dominance buys the influence that wins council seats, council seats kneecap rivals’ economies, and force protects your holdings while bleeding theirs — a flywheel. And because the world is symmetric (§2), every rival is spinning the same flywheel against you. The “pressure” in this sandbox is that you are never the only player reaching for the same finite town.

Guilds — the namesake pillar (designed)

The game’s namesake. Guilds are craft-regulating bodies and a fourth dimension of power intertwined with the council. Full design: design/guilds.md — a guild has two halves: a plentiful license (bought, a position, gates a craft) and a single scarce guildmaster seat (held ex officio by the Elder, won monthly by economic dominance of the craft — highest summed shop profit — not bought), which pulls craft-wide levers (fees, top-tier license caps, the guild-recall, council-vote favour/disfavour, craft buffs). Four broad guilds (Craftsmen / Patrons / Scholars / Rogues) group the crafts so the roster doesn’t chase the craft list. The agreed shape it builds on:

• A license is a position. A guild license is bought by a dynasty and assigned to a living family member — structurally identical to an office / manager seat (§2): it injects modifiers and expires when the holder dies, forcing a costly rebuy + re-level. Reuses the member-vessel pattern and the attribute/building modifier pipeline wholesale — which is why it stays simple.

• Licenses gate production. Without a license for a craft, a dynasty cannot build / upgrade that craft’s workshops or receive its bonuses. A money/material sink and a gate on the existing upgrade system. Contributing gold/materials raises a license’s level → more bonuses.

• Bonuses are permanent-while-licensed craft buffs plus purchasable timed “document” buffs — all just modifiers.

• Two-tier scarcity. Basic licenses are plentiful (no dynasty is hard-locked out of a craft); guild control — high ranks, offices, the guildmastership — is scarce and contested. Capturing a guild lets you pull its craft-wide levers (rivals’ fees, deny their high-level licenses/bonuses, set regulations) — the same “capture-it-and-pull-levers” shape as the council, one domain down.

• Intertwined with politics. Guild power and council power trade influence: a guild you control swings council elections (the path to the Crown runs through the guilds); the council legislates over guilds (charter, tax, override). Two contested arenas that feed each other.

• Symmetric (§2): rivals buy, level, and fight over licenses and guild control too.

Setting reading this gives us: the Crown charters the guilds; the guilds regulate the crafts and bankroll the politics; the council governs the town — and a dynasty muscles up through the guilds to reach the council. Keep it simple and fun — a sink, a gate, a bonus layer, and one more contested ladder; not a bureaucracy sim. Tracked in todo/TODO_FUTURE_WORK.md.

Crime & conflict — a designed pillar

Violence and crime are a first-class part of the game, heavily in the spirit of Guild 2. Designed in design/crime.md: one pipeline — act → detection → resolution → punishment — carrying both the direct force track and the legal (courts) track, because they share the act and evidence substrate. The shape:

• A crime is a task (§2) with a victim, an illegal payoff, and a detection risk — posted through the position layer like any task; categories (economic / force / political) are just posting rules.

• Detection → evidence. A witnessed act writes an isProof memory (design/memory.md); its court weight is decayed magnitude × whether the witnesses are alive / present / of standing — computed at trial, not stored.

• Force resolves as an abstract stat contest (a quick dice roll, narrative flavor on top); building HP damage is a force outcome. Law resolves at the courts (Procurator → Magistrate → Sheriff): the Magistrate chooses the verdict, but ruling against the evidence backfires as corruption proof.

• Punishment is a data-driven crime→sentence map (severity dial picks the range): fine · jail · forfeiture-to-victim · strip-office · execution (violent crime).

• Martial positions — guard / enforcer members, seated like any office (§2).

This is why members can be killed (§6 hard loss), not only die of old age.

Relationships & standing — a designed pillar

The social substrate the fronts above lean on. Designed in design/relationships.md as two derived numbers, and nothing else:

• Relationship (an edge, A→B) — how one character/house feels about another. This is the memory ledger’s existing derived opinion/attitude (design/memory.md §5); pure-derived, never stored.

• Standing (a node) — how important a party is, derived from wealth + titles/offices + guild rank + age.

The discipline: the whole layer is those two numbers plus facts feeding modifiers into them — no bespoke buff systems. The Magistrate’s Venerability is just a standing modifier; marriage kinship is just a relationship modifier. It feeds bribery (an act riding the relationship number; backfire = corruption proof), vote weighting, and trial weight. Deliberately minimal — Guild 2’s social systems were flaky, so favours, formal treaties, and a diplomatic council seat are parked as a future diplomacy layer, to build only on a proven base.

There is no victory screen. “Winning” reads as a felt state: your family on the council, your goods dominating the market, the rival banners gone from the town.

⚠ Tension: the political layer barely exists yet

A council with taxes, licences, and tariffs — and the rule that a seat must be held by a living family member — is a substantial political system. CitySystem is the likely seat of it, but it almost certainly does not model a council, seats, or town-wide economic levers today. This is the least-built pillar and should be treated as largely greenfield. It is also where succession (§4) and economy (§3) fuse, so it cannot be designed in isolation from them.

6. Loss

Loss splits cleanly along the dynasty’s two natures — its flesh and its fortune:

• Hard loss — bloodline extinction. When the last family member dies, killed or of old age, the dynasty is gone — no member left even to be Elder (§2, design/dynasty.md §4). There is nothing left to hold seats, run shops, or bear heirs. This is the only coded game-over. The dynasty is its people; no people, no dynasty.

• Soft loss — economic dead-end. You hit a state from which recovery is effectively impossible: zero gold and no productive assets, or debt so deep the arithmetic of climbing out never closes. Nothing stops you — the game simply becomes unwinnable, and you choose to walk away. This is Dwarf Fortress “losing is fun”: not a scripted failure, an emergent one the player recognises and accepts.

The asymmetry is deliberate: the hard wall is biological (a definite event the engine detects), the soft wall is economic and self-determined (a slope the player judges hopeless). Short of true extinction, the game stays a sandbox — you can be reduced to a single struggling cousin with one shop and grind your way back. The hard floor only exists at the very bottom.

7. System map & the reframe

Every existing system tagged to the pillar it serves. Systems that don’t map to a pillar are flagged — they are either pure infrastructure (fine) or orphans worth questioning.

The task substrate (§2 — the seam)

The pipeline every brain feeds and every character drains:

• NoticeboardSystem, TaskClaimSystem, TaskCleanupSystem, TaskFailureRecoverySystem, StepTagRebuildSystem — posting, claiming, lifecycle, recovery.

• Step executors: MoveToStepSystem, PickupStepSystem, CraftStepSystem, SellStepSystem, GatherStepSystem, DeliverStepSystem — the atomic actions a task decomposes into.

This layer is the most vision-aligned part of the codebase. It is exactly the “one substrate” the control model demands.

• High-level design: design/agency.md — the agency layer: the personal controller seated in every character (always autonomous, trait-driven, with a light expandable needs model), the noticeboard topology (which boards a character reads vs. which a position posts to, plus type/role/ capability filtering), and the unification that makes orders, addressed tasks, and labour one task system on one set of boards (an order = a task that monitors another task). The counterpart to controllers.md (intent). Unusually well-built already — TaskClaimSystem Phase B is the dummy personal controller; the needs board is stubbed.

Controllers — the brains (§2)

• WorkshopSystem — currently the only brain, the hardwired “auto policy” controller. See the §2 tension.

• ProductionUtils — the shared task-posting primitives (CountLabour, PostHireTasks, PostSellTaskForProducedItems, PostCraftTask). This is correctly factored: it is the toolkit any brain calls. It was built ahead of its callers, which felt like working in a vacuum but is actually the substrate every future controller sits on.

• High-level design: design/controllers.md — the full controller layer (positions as domain-owning agents, the order/labour task tiers, queries-as-judgments, discovery + graceful degradation, the shop-manager-as-profit- strategist and the Trademaster planner). Largely greenfield today: there is one hardwired brain (WorkshopSystem) and only the labour task tier exists.

Rival AI & memory — the top controller and its world-reaction (§2, §5)

• No code yet — there is no player/rival distinction in the codebase (no PlayerComponent, no AI flag), no Elder controller, no memory/opinion store. Both are greenfield, sitting on top of the controller + position layers.

• High-level design: design/rival-ai.md — rival AI is the Elder controller (the always-filled top of the controller stack); player vs. rival is a single Auto toggle on that seat. The Elder sets an Agenda (a standing bias — priority dials + grudge attitudes — not a task) from the seated character’s traits and the house’s memories, and issues the big orders that bias motivates. No difficulty mode — the AI does its best; friction, if ever, is modifiers.

• High-level design: design/memory.md — the shared memory substrate that lets rivals react: a fading ledger in two banks (character + dynasty), with opinion and the Agenda as derived readers and isProof entries reserved for the future crime courts. A cross-cutting service, not a rival-AI-only feature.

Production buildings — driven by controllers (§3)

• WorkshopSystem (crafting), GatheringSpotSystem (raw gathering).

• Extraction (mines/farms) — has its output data (ExtractionProductionComponent, read from extract_items) but no controller posts its tasks, so it is inert. See the reframe below.

• High-level design: design/production.md — the building model (a chassis + task repertoire: production is the core family, services another); three archetypes (Workshop / Gathering spot / House, extraction = an inputless workshop); a specialized split chain with three stacked soft-lock guards (L1 raws-only floor · production inputs are “critical” so the City keeps them on the market · cross-products kept cheap); two-axis leveling (building level = worker slots + recipe tiers; guild licence = permission + bonuses); a money+time build/upgrade lifecycle; no inventory caps; destructible buildings. Largely greenfield today (one blind brain, inert extraction, no chain/guards/repertoire). Its scratch-data appendix is ../design/production_notes.md (non-authoritative).

Labour & people (§3, §4)

• EmploymentSystem — hiring; already building-type-agnostic (resolves the hiring building generically), which is what lets any controller staff any building.

• CharacterSystems, DynastyFamilySystem — characters and the family. The home of the generational layer (§4). High-level design: the member atom in design/characters.md; the dynasty/positions/succession layer in design/dynasty.md; the authoritative vessel/roster model (the three position classes) in design/positions.md.

Economy (§3)

• MarketplaceSystems, ItemSystems / ItemUtils — the market goods are sold into and bought from; the economic front of §5. High-level design: design/economy.md (dynamic prices, demand pools, taxes, Kingdom Events) — largely greenfield today (the market is a static-price, infinite-gold sink; see that doc’s §7).

• The Crown & Kingdom Events — greenfield (the thinnest pillar; a content layer

  • scheduler on the market, no code yet). High-level design: design/crown.md — the outside world as an environmental force: an event is a timed bundle of pushes (demand+ / supply− / supply+ / tariff) on the §3 pools; ambient events fire on a weighted timer, the relief valve (crisis import) fires reactively as the City controller’s call. Sequences after the dynamic market. Real Crown diplomacy parked.

Ownership & politics (§5)

• DynastySystems — dynasty ownership and decisions. High-level design: design/dynasty.md.

• CitySystem — the likely future home of the council/political layer, largely unbuilt (see §5 tension). High-level design: design/politics.md.

• Guilds — 100% greenfield (no code yet). High-level design: design/guilds.md — licenses gate crafts, the guildmaster seat (Elder, won by profit) pulls craft-wide levers; the fourth power arena, coupled to the council.

• (BuildingOwnerComponent — the generic ownership tag that makes symmetry possible: dynasty- and city-owned buildings run the same machinery.)

• Crime & conflict — 100% greenfield (no code yet). High-level design: design/crime.md — one pipeline (act → detection → resolution → punishment) over both the force track (abstract contest, building HP) and the legal track (the courts loop, evidence weighed by living/present witnesses); the engine the council seats, the memory ledger, and the Rogues’ Guild plug into.

• Relationships & standing — greenfield (a thin reader layer; no code yet). High-level design: design/relationships.md — two pure-derived numbers (relationship = memory’s opinion/attitude; standing = wealth/titles/guild/age) plus modifiers (Venerability, kinship); feeds bribery, votes, and trial weight. Favours / treaties / a social seat parked as future diplomacy.

Infrastructure — no pillar, and that’s correct

CameraSystems, DebugSystems, PathfindingSystems, TilemapSystems, BasicSystems, BuildingSystems, EntityInspectorSystem, BuildingUtils. Plumbing and presentation. Not design-bearing — they serve all pillars equally.

The reframe — what this document does to the recent confusion

The work that prompted this whole exercise was: “extraction buildings produce nothing, and we don’t know which system should drive them.” The honest answer was that no system did, and nobody could say which should — which is precisely the symptom of building bottom-up without this document.

With the control model in place, the question dissolves:

• Extraction is not missing an ExtractionSystem. It is missing a controller assignment. A building produces because some brain posts tasks onto it. Mines are inert because no brain is pointed at them — not because a whole new system is absent. The fix is a controller, not a subsystem.

• The “dynasty production planner” (long deferred as “Option 3”) is not a missing foundation. It is just the most sophisticated brain — one controller kind among player/auto/delegate. It is not a prerequisite for anything; it is an upgrade you can slot in once the controller concept exists.

• The execution-layer work was not done in a vacuum after all. Lifting the task-posting primitives into ProductionUtils was building the toolkit every brain shares. The bottom-up process got that part accidentally right; it only lacked the sentence at the top — this document — saying what it was for.

The path forward that this picture implies (not a plan, just the shape): introduce the controller concept, turn the hardwired WorkshopSystem into one selectable brain among several, and then “who drives extraction?” answers itself — whichever brain you point at it.