Design — Positions (the vessel layer, authoritative roster)

The single authoritative model of a position: what every position is, the three classes of position, and the cabinet’s finalised office slate. This is the deferred “position roster, 2nd pass” promised by controllers.md §9, and it reconciles the three docs that each name “positions” from their own angle — dynasty.md §3 (offices as dynasty-wide modifiers), controllers.md §1 (offices as active controller domains, names “illustrative”), and politics.md §5 (council seats as vessels). Where those three disagree on naming or framing, this doc is the truth; they are being updated to point here.

Answers to ../GAME_DESIGN.md §2 (positions gate all action). Design doc — the model and its rules, not an implementation plan.

1. What a position is

A position is a seat a living family member holds, that grants a bundle of three things: a controller domain, optional modifiers, and posting rights.

One unified definition, shared by every class below:

(a) A controller domain — the decision logic the seat runs (post tasks/orders within its slice, query and be queried). The position is the agent, not the character in it (controllers.md §1).
(b) Zero or more modifiers — dynasty-wide or area effects that apply simply because the seat is filled, scaled by the holder’s attributes/traits (characters.md).
(c) Posting rights — which noticeboards the seat may post to (agency.md §4). Posting is per-position; this is the seat’s reach.

Holding a seat costs a family member; vacating it removes all three at once — the domain goes dark, the modifier lapses, the posting right is gone. An empty seat is a switched-off subsystem (controllers.md §1).

Properties shared by all positions

These hold regardless of class — they are the reason “position” is one concept:

Only family members hold positions. Hired workers are pure labour and can hold none (dynasty.md §2). This makes the family the hard bottleneck on how much a dynasty can run.
The holder’s traits set the seat’s strength (dynasty.md §3, politics.md §5). The seat being filled is necessary; who fills it sets the payoff — and decisions/judgments are made as the office, tinted by the occupant (“hat to hat”, controllers.md §1).
The overload rule is dynasty-internal only. It pools across the seats the dynasty assigns — cabinet offices + building managers — where spreading one member too thin thins the good and amplifies the bad (dynasty.md §3). Council seats and guild positions are exempt and do not interact with overload or with each other: winning an external contested seat (a council office, a guild license/mastership) must never punish you. So a member who is dynasty Elder and city Mayor carries only the Elder seat’s overload, not the Mayor’s.
Vacancy degrades locally, by class (§5 below) — only the Elder ties to the whole dynasty, and even that only bites at extinction (dynasty.md §4).

2. The three classes

All three are positions by §1’s definition; they differ only in how the seat is acquired and bounded:

Class	Count	Acquired by	Domain scope
Cabinet offices	fixed slate	appointed from within the dynasty	dynasty-wide intent
Building managers	dynamic — one per building	appointed per building	that one building’s operation
Council seats	fixed slate (the city’s)	won via town politics	city-wide authority

The decisive split is who grants the seat: the dynasty appoints the first two freely; the third is won from the town and the dynasty does not control its supply.

3. Class 1 — the cabinet (authoritative office slate)

The cabinet is a fixed slate of dynasty offices, appointed at will from living family members. Per the locked Fork 1:

A cabinet office = a controller (its specific domain logic) + one or more dynasty-wide modifiers — one unified seat, not two parallel things. This supersedes dynasty.md §3’s “offices are passive modifiers” framing and controllers.md §1’s “names are illustrative” caveat: the names and domains below are now authoritative.

Mapping onto the things a dynasty does — lead, fund, trade, fight (grow is parked, see Matron):

Office	Controller domain (what it decides / posts)	Dynasty-wide modifier(s)
Elder	Writes the Agenda; is the rival-AI socket (`rival-ai.md`); owns succession; and is the dynasty-advancement actuator — runs kin for council seats, buys guild licences, places & promotes family members in the town (see §3.1)	+production across all buildings, +election odds
Treasurer	Sets the spending budget split; answers liquidity judgments (“are we flush?”) (`controllers.md` §5–§6)	+loan terms (cheaper credit), lower costs
Trademaster	Trade-route discovery (“where’s the iron?”) + supply-chain routing across the dynasty’s shops (`controllers.md` §3, §7)	buy cheaper, sell dearer
Marshal	Force orders — directs the dynasty’s own guards/enforcers; HQ = the house (`controllers.md` §3)	buffs guards/enforcers, defence

Naming clashes with the town council are deliberately resolved (politics.md §2): the dynasty Treasurer is your house, the city Chamberlain is the town; the dynasty Marshal buffs your own guards, the city Sheriff points the town’s.

3.1 Dynasty-advancement lives in the Elder (Fork 2b)

The domain that maneuvers the family into the town — running members for council seats, buying guild licences, placing and promoting kin — is the Elder’s execution arm, not its own office. The Elder already decides the Agenda (“get a seat on the council”); folding the enactment into the same seat keeps strategy and its actuator together, and avoids standing up a sixth office while the political and guild layers it acts on are themselves unbuilt.

This is a deliberately movable seam. A controller is just a bundle of domain logic; if advancement later wants to be a delegatable job (a dedicated “Chancellor”/”Steward of Ambitions” a spare capable relative can hold), splitting it out is a code-move between controllers, not a redesign. Parked as the Elder’s for now; revisit when politics/guilds are real. This retires the “dynasty-advancement controller (parked)” note in controllers.md §9.

3.2 Matron — parked

A family-growth office (childbirth, child-raising, and the natural home for the marriage approval/veto that agency.md §7 leaves open) was proposed as a fifth seat. It is parked — its use isn’t yet clear, and the breeding loop it would govern (dynasty.md §5) is greenfield. Revisit alongside the family/breeding pass; until then the marriage-approval query in agency.md §7 has no fixed owner.

4. Class 2 — building managers (dynamic)

A dynamic class: one manager position is created with each workshop or extraction site the dynasty owns, and destroyed with it. Per controllers.md §2 and dynasty.md §3:

Every operating building needs a seated manager (a family member). No manager → the building is inert and posts nothing.

Domain — that one building’s operation: the manager is a strategist whose objective is “keep this shop profitable” (controllers.md §7), choosing what to produce, stocking cheap inputs, timing sales. It also applies the accept/decline judgment gate to orders addressed to it (controllers.md §3).
Modifier — the manager’s traits modify that building’s performance (a master smith’s shop crafts faster), in both Auto-on and Auto-off modes.
Posting rights — its own personal board + its building’s board (agency.md §4).
Count grows and shrinks with buildings owned — the only structurally special thing about this class.

5. Class 3 — council seats (acquired)

Council seats (politics.md) are positions by §1’s definition, but the dynasty does not grant them — they are won from the town through elections, and their supply is the city’s, not the dynasty’s.

The slate is the city’s, not the dynasty’s — Mayor, Chamberlain, Magistrate, Procurator, Sheriff (politics.md §2). A dynasty holds as many as it can win bodies into; a rival holds the rest.
Domain = city-wide authority — set tax, command the town guard, run the courts, banish (real mechanical power over the whole town, politics.md §1).
Acquired via politics, not appointment — field a member + pay the application fee + win the vote (politics.md §3, §5). This is the one class a dynasty cannot simply fill at will.
Holding one is itself a dynasty-advancement goal. The loop closes with §3.1: the Elder posts “get a seat on the council” as advancement intent → a family member campaigns and wins → that member now holds a council position. So this class is the output of the Elder’s advancement domain.
One council seat per member, but council seats are exempt from overload (§1, politics.md §5) — they are an external contested class, not a dynasty-assigned job, so holding one adds no overload.

6. Vacancy & succession, by class

Death/removal empties seats; the blast radius is scoped by class so loss is drama, not tedium (dynasty.md §4):

Class	On the holder’s death/removal
Elder	Auto-passes to the oldest living member; never transiently empty (the only way to lack an Elder is extinction — the hard loss). The drama is the change of holder: new traits, the house “turns a page.”
Other cabinet offices	Modifier lapses + domain goes dark until re-seated. No paralysis.
Building managers	That one building idles until re-seated. No dynasty-wide effect; delegated buildings can auto-reassign to a spare.
Council seats	By-election (`politics.md` §3, §4) — the town contests the vacancy immediately; the dynasty may or may not win it back. Conviction can also strip a non-immune seat.

7. Already in code

CityRole { Worker, Guard, Mayor } and FamilyRole { Founder, Spouse, Child, Adopted } exist as enums, but neither is a position in this doc’s sense — they are role tags, with no seat, domain, modifier, or posting right behind them. Mayor is a lone enum value with no council behind it (politics.md §7).
WorkshopWorkerComponent / DynastyFamilyMemberComponent carry the family-vs-hired split (§1’s “only family hold positions”) and lineage scaffolding, but nothing seats a member into an office or manager slot.
WorkshopSystem drives buildings today gated on ownership, not on a seated manager — the §4 “mandatory manager” rule inverts this.

So the vessel layer is almost entirely greenfield: the modifier pipeline exists (characters.md) so seat bonuses can plug in, but the seats — and the appointment/overload/vacancy machinery — do not exist.

8. ⚠ Tensions with current code

No seats of any class. Cabinet offices, manager slots, and council seats are all unbuilt; this is the shared greenfield gap behind dynasty.md §6, controllers.md §8, and politics.md §7 — one solution serves all three.
The overload curve is one cross-class lever (§1) but does not exist; it must be defined once and applied to dynasty offices, managers, and council seats together.
Ownership-gated, not manager-gated. WorkshopSystem posts work for any owned building; §4 requires a seated manager, a real change to the posting gate.
maxMembers cap to be removed (dynasty.md §6) — the real limit on positions filled is family size × the overload pressure, not a hard cap.

9. Open questions (next pass)

The overload curve — how fast positives dilute / negatives amplify per extra seat. Shared open question with dynasty.md §7 and politics.md §8.
Matron / the family-growth office (§3.2) — whether it returns, and whether it owns the marriage-approval query (agency.md §7). Tied to the breeding pass.
Dynasty-advancement as its own seat (§3.1) — revisit splitting it out of the Elder once politics/guilds are built.
Non-shop positions’ buildings (controllers.md §9) — the Marshal’s HQ / house equivalent.
Appointment UI/flow — how the player seats and re-seats members across the three classes (appointment for 1 & 2; candidacy for 3).