Design — Dynasty, Positions & Succession

High-level design for the dynasty: its structure, its members, the positions that gate all action, succession, and how the family grows. Answers to ../GAME_DESIGN.md §2 (positions/control), §4 (generational layer), §6 (loss). Builds on characters.md (the member atom). Design doc — the model and its rules, not an implementation plan.

1. What a dynasty is

A dynasty is the player/AI-controlled house: a persistent entity that owns buildings, holds the treasury, and is staffed by characters. Per GDD §4 it is the immortal point of view — you never “die” and jump bodies — but it is mortal in substance: it exists only as long as it has living family members (§4, §6).

Assets are held centrally, at the dynasty level — gold lives in the dynasty’s own inventory, workshops are owned by the dynasty, not by individual members. This is the single most important structural fact for succession (§4): because nothing of value is owned personally, a member’s death transfers no estate. The dynasty keeps everything; death only empties the seats that member held. Succession is re-seating, not probate.

Already in code

DynastyComponent — the dynasty entity: name, central gold (in its InventoryComponent), and ownership lists (members, familyMembers, workshops). (Carries a maxMembers cap — to be removed, see §5.)
DynastyMemberComponent + WorkshopWorkerComponent — a hired worker: waged, bound to one workshop, fireable, claims only that workshop’s tasks.
DynastyFamilyMemberComponent — a family member: floats across all dynasty workshops, never fired, unwaged, permanent. Carries lineage scaffolding already: FamilyRole {Founder, Spouse, Child, Adopted}, generation, parentIds, spouseId.

So the two-class member model and the lineage data both exist. What’s missing is everything that acts on them (positions, aging, reproduction, succession).

2. Two classes of member

	Family members	Hired workers
Source	born / married in (§5)	hired off the labour market
Wage	none (free)	waged
Mobility	float across all dynasty buildings	bound to one workshop
Permanence	permanent, never fired	fireable
Can hold positions?	Yes	No
Bloodline	yes	no

The decisive line: only family members can hold positions (offices and building managers, §3). Hired workers are pure labour that fills work-slots. This makes the family the hard bottleneck on how much a dynasty can run (not how much it can staff) — and the only way to grow the family is to breed it (§5).

3. Positions — the vessel layer (GDD §2)

Every unit of control must be seated in a living family member. Two scales:

The authoritative position model now lives in positions.md — the unified definition (seat = controller domain + modifier + posting rights), the three classes, and the finalised cabinet slate. This section’s table is the modifier view of that slate; read it alongside positions.md §3, which is the truth where they differ.

Dynasty offices — the cabinet slate

Mapping onto the things a dynasty does — lead, fund, trade, fight (grow/Matron is parked, see positions.md §3.2). Each office is a **controller

this modifier in one seat, not a passive modifier alone:

Office	Domain modifier (dynasty-wide)
Elder	head; production bonus across all buildings + election odds (also the dynasty-advancement actuator, `positions.md` §3.1)
Treasurer	finance — loan terms, lower costs, treasury
Trademaster	trade — buy cheaper, sell dearer
Marshal	force — buffs guards/enforcers, defence (the crime/conflict front)

An office’s magnitude scales with the holder’s relevant attribute(s) + traits (per characters.md). So seating is a real decision — a high-charisma member is a strong Trademaster; a weak member in the seat gives a weak bonus. The seat being filled is necessary; who fills it sets the payoff.

Building managers

Before a dynasty can post any order to a building, it must seat a family member as that building’s manager. The manager’s traits modify that building’s performance, in both control modes (manual and delegated — GDD §2). No manager → the building accepts no orders.

The overload rule

One member may hold several seats, but spreading thins the good and concentrates the bad: a member’s positive traits/attributes apply at diminishing effect across their seats while negatives apply at full or amplified effect. This is the pressure that makes family size matter — you cannot run an empire off one brilliant Elder. (Exact curve: open question.)

Scope: overload is dynasty-internal — it pools only across these dynasty-assigned seats (cabinet offices + building managers). Council seats and guild positions are exempt and do not interact with it (see positions.md §1).

4. Succession

Because assets are dynasty-level (§1), succession is re-seating vacated positions, scoped by tier so death is drama, not tedium:

Elder — on death, the seat auto-passes to the oldest living family member; the player/AI may then re-seat anyone at will. No designated-heir system (it adds nothing without special heir functionality). Because there is always an oldest member to take it, the Elder seat is never transiently empty — the only way to lack an Elder is to have no members at all, which is the hard loss (§6). The drama is in the change of holder: a new Elder has different traits, so the dynasty’s bonuses shift — the house “turns a page.”
Other offices (Treasurer/Trademaster/Marshal/Matron) — on the holder’s death the bonus simply lapses until re-seated. No paralysis. Re-seat freely.
Building managers — death idles that one building until re-seated. No dynasty-wide effect. For delegated buildings, support auto-reassign-to-a-spare so it isn’t a chore.
Guild licences (see GDD §5 / future guilds.md) — expire on the holder’s death; rebuy + re-level.

So only the Elder seat ties to the whole dynasty, and even that only bites at extinction. Everything else degrades locally.

5. Growing the family

maxMembers is removed — no arbitrary population cap. The family grows by exactly two means, and regulates itself:

Marriage (medium speed) — brings in an adult spouse, immediately seatable and able to breed. Marriage difficulty scales with the partner’s value: poor, low-skill characters are easy to marry; rich/skilled ones are harder; members of other dynasties are hardest of all. This produces the intended arc — early-game urgency (marry anyone, breed fast, you have too few hands) giving way to late-game restraint (a sprawling family is its own headache).
Children (slow) — married couples produce children who inherit attribute stock and traits per characters.md, then must grow up before they can be seated. The quality play: good parents breed good members.

No adoption — it makes scaling too easy and cheapens the marriage game.

Marriage as a light alliance

Marrying a member of another house makes the two houses kin, yielding a soft relationship modifier with that house (reduced hostility / trade perk / non-aggression lean) — diplomatic residue, not a treaty system (keep it simple). Per relationships.md §2, kin is precisely this: a non-decaying modifier that warms the relationship baseline between the two houses; its perks (votes, trade lean, AI non-aggression) all fall out of the one relationship number, not a bespoke alliance system. The spouse joins your household and is seatable. Marriage and breeding are also the only defence against extinction (§6) — if the bloodline thins, this is how you survive — which makes them strategically essential, not flavour.

The “big family is a headache” pressure — management overhead (open topic)

Difficulty-scaling regulates the front of growth; the back pressure — what makes a large family something you’d want to rein in — is, for now, deliberately soft and management-flavoured: surplus members are dead weight you must tend. A member who holds no seat still has to be married off, kept safe, and generally looked after — an attention cost that grows with the family, not an active rebellion. That is enough to make “breed endlessly” feel like a chore rather than a free win, without a heavy simulation.

Left deliberately open — a future “family member sink” system: productive outlets that consume surplus members rather than letting them merely bum around. Candidate sinks (none committed): marrying a member out into another house (they leave your household — the mirror of marrying-in, and an alliance lever); sending members on ventures / expeditions; guild or military service; deliberately founding a cadet branch. A heavier direction — idle members growing discontent and splintering or turning to crime (very CK3) — remains possible but is explicitly not committed: we lean soft (management cost) first and may layer consequences later, likely alongside politics/crime.

6. ⚠ Tensions with current code

No positions at all. Offices, the office→modifier wiring, building-manager assignment, and the overload curve are entirely greenfield. The modifier pipeline exists (characters.md), so office/manager bonuses plug in; the seats do not.
No aging / death / reproduction. DynastyFamilyMemberComponent has the lineage data (role, generation, parents, spouse) but nothing ages members, kills them, or produces children. The whole §4/§5 loop is unbuilt.
maxMembers to be removed. It currently caps hired workers ("Workers: n/maxMembers"). The design wants no hard cap; the real limiter on workers is workshop work-slots, and on family is the marriage/birth rate plus the overload/headache pressure.
Manager-as-controller missing. Building-manager seating is the concrete form of the GDD §2 “controller needs a vessel” gap — WorkshopSystem drives buildings today with no manager concept.

7. Open questions (next pass)

Office slate sign-off (§3) — confirm the five (Elder, Treasurer, Trademaster, Marshal, Matron) and each one’s exact modifier.
Family member sink (§5) — the open “what to do with surplus members” system (marry-out, ventures, service, cadet branches), and whether to later layer active discontent/splinter consequences. Lean soft (management overhead) first.
Overload curve (§3) — how fast positives dilute / negatives amplify per extra seat.
Marriage difficulty formula (§5) — what “value” weighs (skill, wealth, dynasty membership) and how hard the hardest case is.
Child-Elder edge — if the oldest member is a child, they become a (weak) Elder; is that acceptable, or is there a minimum age / regency? (Lean: acceptable, no regency system — weak but alive.)
~~Alliance modifier specifics (§5)~~ — settled in relationships.md §2: kin is a non-decaying modifier that warms the relationship baseline between the houses; perks (votes, trade lean, AI non-aggression) fall out of the relationship number. Bump magnitude is balancing.