Design — Relationships & Standing

High-level design for the social layer: how characters and dynasties feel about each other and how important they are. Answers the social half of ../GAME_DESIGN.md §5 and the hooks five other docs left for it. This is a design doc — the model and its rules, not an implementation plan.

Precise term definitions live in glossary.md. The two words this doc owns — relationship and standing — are defined there and used exactly throughout.

1. The model — two derived numbers

The whole social layer is two numbers, and the discipline of this pillar is that there is nothing else:

Both are pure-derived — recomputed on demand from facts that already exist, never stored. This matches the controllers’ judgments-are-reads rule and memory.md’s existing stance: a derived number can never desync from the facts.

The one principle. The social layer is two derived numbers plus facts that feed modifiers into them. There are no bespoke “buff systems.” Anything that wants to influence how people feel or how important someone is does so as a modifier on one of the two numbers — exactly like a trait or an office bonus feeds the attribute pipeline (characters.md). A modifier only differs by which number it targets.

This is deliberate. Guild 2’s social systems were flaky and over-built. This pillar ships the smallest solid base — two numbers — and earns its way up. Everything that would have made it a “social sim” (favours, treaties, diplomatic offices) is parked (§6), to be built only once the base proves solid.

2. Relationship — the edge

A relationship is a directed number: how one party feels about another. It is exactly memory.md’s existing derived readout — this doc adds no new machinery to it, only names it and records what feeds it.

• Character scope → memory.md calls it opinion (character → character / dynasty).

• Dynasty scope → memory.md calls it attitude (house → house).

• Relationship is the umbrella term for both.

Derivation (memory.md §5), unchanged:

relationship(A → B) = baseline(traits, kinship, …)  +  Σ decayed memories A holds about B

• The baseline is the trait-compatibility floor (two greedy people grate) plus standing modifiers (§4) — notably kin.

• The decaying sum is the event history: “he robbed me” lays a big, slow-fading negative; a fresh slight against a house nudges the dynasty attitude.

kin — a relationship modifier

Marrying a member of another house makes the two houses kin (dynasty.md §5). Mechanically this is not a special state or a “tie” — it is simply a modifier that warms the relationship baseline between the two houses, sourced from the marriage fact:

• It rides the same pipeline as any modifier; it just targets the relationship number instead of an attribute.

• Unlike an event memory it does not decay — it is a standing baseline shift that holds as long as the marriage/bloodline link does. This is dynasty.md’s “diplomatic residue, not a treaty system.”

• It needs no bespoke effects of its own. It raises the relationship, and everything that already reads relationship responds: the rival-AI Agenda (rival-ai.md) leans off attacking kin, kin electors favour the candidate (§5), trade leans follow. Reduced hostility, votes, and trade perks all fall out of the one number.

A kin pair can still come to loathe each other — the kin baseline is positive, but enough grievances in the decaying sum can push the relationship negative anyway. That tension is a feature, not a bug.

3. Standing — the node

Standing is how important a party is in the town, independent of who is looking. It is the genuinely new readout this pillar introduces (nobody owned “prestige” before) — but, like relationship, it is pure-derived:

standing(character) = w₁·wealth + w₂·titles/offices + w₃·guild rank

                      + w₄·age/Elder bracket + active standing modifiers

standing(dynasty)   = aggregate of its members' standing + its holdings

Every input on the right is already owned elsewhere — wealth (economy), titles/offices (positions.md), guild rank (guilds.md), age bracket (characters.md). This doc only defines the formula that combines them (weights w₁…wₙ are balancing, §9). No new stored field; it cannot desync.

Venerability — a standing modifier

The Magistrate’s passive Venerability (politics.md §2) is simply a standing modifier active while seated: holding the judge’s seat makes you more important to everyone. It is not a relationship buff (it does not change how any specific person feels about the holder) and not its own buff system — it is one entry in the standing formula’s “active modifiers” term, the node-layer twin of how kin feeds the edge.

politics.md wrote Venerability as a “relationship-standing” buff — fused wording from before the two words were split. It is a standing buff, full stop. (Reconciled in politics.md this pass.)

4. The unified pattern

The two sections above are the same shape pointed at different numbers:

There is no “relationship system” and no “standing system” to build beyond (a) the two derivation formulas and (b) letting facts register modifiers into them. That is the entire pillar.

5. Consumers — what reads the two numbers

The demand side that stubbed this pillar. Each is now a clean read of one or both numbers; none needs new machinery here.

Bribery (politics.md deferred the formula here)

A bribe is an act (a task) targeting an official/elector. Its memory effects are already specified — memory.md’s canonical dual-write example:

bribe → + "I got paid" (private, decays fast) and isProof "our man was bought" (a slow-decaying liability, a court exhibit).

This pillar supplies only the wiring and the formula:

• On success, the + "I got paid" entry lands → it feeds the official’s relationship toward the briber → which biases their vote/verdict through the normal relationship path (§5 vote, courts). No special “bought vote” channel — it rides the one number.

• Success / backfire is keyed on the target’s traits (Honest resists, Greedy accepts) + the bribe amount + the briber’s standing / charisma, versus the target’s resistance.

• Backfire = refusal + the isProof corruption entry surfaces — a standing hit and court fuel, exactly crime.md’s corruption path.

Favours were considered as the object a bribe mints and a vote spends, and cut (§6) — a bribe rides the relationship number instead.

Vote weighting (politics.md §3)

An elector’s vote for a candidate reads:

charisma(candidate) + relationship(elector → candidate's house)

   + standing(candidate's house) + campaign spend + bribes
   + guild favour/disfavour modifier

Both numbers feed it. “Relationship standing” stops being politics.md’s flat stub — it is now the real derived relationship plus the candidate-house standing.

Trial weighting (crime.md §3 — already written there)

crime.md already specified that a witness’s court weight is decayed magnitude × alive / present × **standing**, and that the defendant’s standing + charisma feed the defense. This pillar simply supplies the standing value those calcs read; crime.md owns the trial math.

6. Deliberately parked — the “go carefully with social” cuts

Guild 2’s flaky social features are the cautionary tale. Each of these was considered and cut from 1.0 to keep a solid base; they form one coherent future diplomacy layer to build only on top of a proven relationship/standing base.

• Favours — a directed, spendable obligation (“B owes A one”), minted by a service/bribe and consumed on a vote/task. A whole mint/spend/decay lifecycle for one nice-to-have. Bribery rides the relationship number instead.

• Formal pacts / treaties / alliances — declared, stored inter-house states. rival-ai.md already deferred exactly this (“alliances/pacts beyond a memory-sourced attitude number… unaddressed”). Marriage gives the only alliance in 1.0 (the kin modifier, §2).

• Feud as a stored state — collapsed into the relationship scalar: a feud is just a relationship below a hostile threshold, which the Agenda already reads as a grudge. No declared-vendetta mechanic.

• A social / diplomatic council seat (Seneschal) — politics.md parked it “pending the relationship system.” But a seat needs levers, and a social seat’s natural levers are the diplomacy parked above. It stays parked, the natural home and council seat for the future diplomacy layer if it is ever built.

7. Already in code / what it reuses

• Greenfield as a pillar, but it reuses everything: the memory ledger (relationship = its derived opinion/attitude), the attribute/modifier pipeline (standing modifiers ride it), and existing facts (wealth, offices, guild rank, age, marriage) as standing inputs.

• The only genuinely new readout is the standing formula — a pure read over data that already exists. No new stored component is required for the base.

8. ⚠ Tensions with current code

• No standing readout exists. Wealth, offices, and age exist as data, but nothing combines them into a standing value; the formula and its call sites are new (all reads).

• Relationship rides on memory, which is itself greenfield. memory.md’s banks, decay, and derived opinion/attitude are unbuilt; relationship cannot ship before memory.

• kin needs a marriage fact to read. dynasty.md’s marriage/household system is greenfield; the kin modifier has nothing to derive from until it exists.

• Build order: memory → relationship; positions/guilds/economy data → standing. This pillar is a thin reader layer that sits on top of several other greenfield substrates, so it sequences late.

9. Open questions (next pass)

• Standing formula weights (§3) — the w₁…wₙ mix of wealth / titles / guild / age, and how a dynasty aggregates its members. Balancing.

• Relationship baseline magnitudes (§2) — the kin baseline bump size and the trait-compatibility floor (shared with memory.md’s balancing).

• Bribery formula tuning (§5) — the traits/amount/standing curve and the backfire probability. Balancing.

• The future diplomacy layer (§6) — if/when favours, formal pacts, and a Seneschal seat are built, they live together here; not before the base is solid.