Design — Crime & Conflict

High-level design for the game’s crime & conflict pillar: the criminal act, how it is detected into evidence, how a confrontation resolves (by force or by law), and what punishment follows. Answers to ../GAME_DESIGN.md §5 (the force front + the law/justice response), and ties together threads the other docs already reserved: politics.md (the court seats), memory.md (the isProof evidence substrate), guilds.md (the Rogues’ Guild), dynasty.md/characters.md (the Marshal + martial positions). Design doc — the model and its rules, not an implementation plan.

This pillar is the engine the others plug into. The seats that pull crime levers, the ledger that stores evidence, and the guild that wraps criminal trades are all defined elsewhere; crime.md defines what a crime is and how it plays out. It covers both tracks — direct force and the legal loop — in one doc, because they share the same act and detection substrate and only diverge at resolution.

1. The pipeline

Everything in this pillar flows through one spine. The two tracks diverge at resolution and re-converge at outcome — which is what lets one doc hold both without them tangling:

  1. THE ACT  ──►  2. DETECTION  ──►  3a. FORCE resolution (abstract contest)
  (an illicit       (witnessed?           ──────────────────────────────────────
   task fires)       → evidence)     ──►  3b. LEGAL resolution (the courts loop)
                                            ──────────────────────────────────────
                                       ──►  4. PUNISHMENT / OUTCOME

The defining tension between the tracks: force is fast but leaves evidence; law is slow but buries you in proof. A brute who torches a rival’s warehouse may be seen doing it (§2) and dragged into court (§3b); a schemer who works the courts needs witnesses and a captured Magistrate. Choosing a track is a real decision.

2. The act — a crime is a task

A crime is a task — same lifecycle and the same posted-through-a-position mechanism as any other task (production, movement). Nothing about its source is special. What makes a task criminal is three properties it carries: a victim (a character / building / treasury it harms), an illegal payoff (gold or damage), and a detection risk (it can be witnessed → evidence, §2).

There is no parallel “crime system” that posts tasks a different way. Crimes are posted through the existing position layer; the only variation is the rules about who may post which crime, where, and at what target. Those rules sort crimes into three categories:

¹ Corruption, embezzlement, and bribe-taking already exist as isProof memory kinds (memory.md §2); crime does not re-invent them — it reads them as evidence and lets the court loop act on them.

The split is purely trigger + intent, not two machines: a Rogues’ den churns out pickpocket tasks the way a smithy churns out sword tasks (autonomous, untargeted, income); “burn that rival’s warehouse” is a deliberate command a Marshal issues at a target, which then posts an execution task. Only the economic category feeds the guild profit metric — keeping that metric clean of one-off aggression.

3. Detection & evidence

When a crime-task’s illicit step actually executes — the pickpocket moment, the torch hitting the wall — detection runs:

1. gather every character within a witness radius (~20 tiles — balancing);

2. roll per character: perception-ish attributes + traits − perpetrator's skill/stealth − distance + random → did they see it;

3. each character who passes gets a memory of it.

So crime quality buys secrecy — a master pickpocket generates few witnesses, often zero. The victim is just another witness: a clean theft leaves even the victim with only “I lost money, this sucks” — a memory with no perpetrator identity, which is no prosecutable proof, just a grumble.

What detection writes

A crime fires two different memory effects, and detection gates only the second:

• Opinion effects (the victim dislikes the robber; the house’s attitude dips) fire regardless of witnesses — the victim knows they were wronged.

• The isProof entry is what the witness roll produces. No identified witness → no court-usable proof. A witness → an isProof entry (subject = the perpetrator / their house) is written to the dynasty bank, carrying a new witnesses field — the character ids who saw it (a crime-pass extension to the memory.md §3 anatomy).

Evidence “strength” is computed at trial, never stored

There is no stored strength number (The Guild 2 had one; we don’t need it). A proof’s weight is derived fresh when the Magistrate rules — “judgments, not facts,” the same discipline as the rest of the design — from the base decayed magnitude × per-witness factors:

This reconciles cleanly with memory.md §2’s “proof outlives a murdered witness”: the proof-fact persists in the dynasty bank, but a dead or absent witness makes it weak. Killing a witness no longer erases evidence — it guts its weight. That is more interesting: the proof still exists to accuse with; it just will not convict. The witness-tampering fantasy falls out for free.

Witness strength flows through three gates

The same number gates the whole legal track:

1. Will the wronged house even prosecute? An isProof with an empty/weak witness list → low chance the Elder bothers; a richly-witnessed one → they run to court. This decision is the Elder’s Agenda call (rival-ai.md; memory.md §2: the family remembers, the Elder decides what to do) — no new machinery.

2. How present/alive at trial (the table above).

3. How heavily it weighs in the verdict (§3b).

3a. Force resolution — an abstract contest

When a force-action lands, it resolves as a quick stat contest — a DnD-style dice roll, not tactical map combat (deliberately simple for 1.0; expandable later):

  attacker force                 defender force
  (Marshal buff + enforcer  vs   (guards present + their       + RNG  ─►  outcome
   attributes / numbers /         buffs + the target's
   traits)                        defenses)

The outcome is a structured value on a spectrum: clean success (damage to a building’s HP, a character robbed / wounded / killed) → partial → failure (the attacker is wounded, captured, or killed). A narrative story is generated from that structured outcome as a pure presentation layer — flavor over the dice, zero mechanical weight, trivial to add or skip.

• Building HP / destruction is a force-track outcome (you physically raid and torch). This is distinct from the court’s forfeiture punishment (§4): same target, two routes — destroy it by force, or have it confiscated by law.

• A force-action is itself a witnessable crime-act (§2). A botched arson in a crowded street generates witnesses → an isProof against you → the victim can drag you into court. This is the interlock that makes the force-vs-law choice real.

The actors are positions, not a new concept: enforcers are martial members a dynasty seats (characters.md §5.1) and the Marshal dispatches; your own guards (Marshal-buffed) and the town watch (Sheriff-commanded, politics.md §2) are the defenders.

3b. Legal resolution — the courts loop

The flow reuses the council seats already specced in politics.md §2:

  Procurator         (date set)        Magistrate         Sheriff
  (accuse:     ──►   witnesses    ──►  (rule:       ──►   (enforce the
   Inquisition)       summoned          convict /          sentence, §4)
                      to court          acquit)

Witnesses are summoned by a task. When a trial date is set, every living witness gets a “come to court” task; whether they actually arrive falls out of systems we already have — how busy they are, distance, willingness, and (emergent) whether someone kept them busy or intimidated them. Presence then feeds the weight calc (§3).

The Magistrate decides; evidence sets the stakes

The verdict is not an auto-resolved roll. The Magistrate seat-holder (player / AI) chooses convict or acquit — but the evidence governs the consequence of ruling against the facts:

• The weighed evidence (§3) produces an expected verdict — what the proof points to.

• The Magistrate’s actual ruling is free. The gap between ruling and evidence = the corruption magnitude. Rule with the evidence → no cost (the honest path; the “fair trial” is just this special case). Rule against it → backfire scaled by how blatant the gap is:

  • acquit despite strong proof → standing hit + an isProof for corruption against the Magistrate’s house + fuel for a guild-recall (guilds.md §5 lever 3);

  • convict on empty proof (a trumped-up charge) → the same backfire lands on the accuser / judge if it is flagrant.

The Law Severity dial (the Magistrate’s policy lever) shades the expected-verdict threshold and the punishment harshness (§4). Defendant standing / charisma + bribes feed the defense side of the calc.

Immunity (Mayor, Magistrate — politics.md §2/§4) short-circuits the whole flow: they cannot be brought to trial at all. That is why the guild-recall is their only check.

The elegant closure: corruption is just another crime written to the same ledger. Abusing the court generates proof against you, prosecutable by the same loop (or recall-able by the guilds). No special anti-corruption system.

4. Punishment & outcomes

A crime → punishment map drives sentencing — a data row per crime giving a min/max punishment range; the Law Severity dial picks within the range (lenient town → min, harsh town → max). The Magistrate does not hand-pick a sentence per trial — its levers are the dial (set once, shades everything) and the binary convict/acquit (§3b). “This town is harsh” emerges from the dial.

The court-sentence menu

Execution is a triggered death — the existing succession machinery (dynasty.md §4) handles it (seats empty, Elder auto-passes); it is the aging-death path fired on purpose. Losing a family member to the axe is a real loss (family is the bottleneck) — that is the deterrent on going loud, and it leaves a heavy grudge against whoever pushed the conviction.

Banish is not a court sentence

Banish is the Mayor’s active ability (politics.md §2) — extra-judicial, no trial. It exiles a rival character from town for the duration of the banishing Mayor’s tenure; the banished return when the Mayor changes (election / death / resignation). Refinement to politics.md §2, which currently reads “permanent.” Tying the exile to the seat gives rivals a concrete reason to unseat that Mayor — to bring their people home. Distinct from jail (a temporary court sentence) by being permanent-for-the-term and trial-free.

5. The roster — a data-driven table

Crimes are a data-driven table, not a hardcoded list — exactly like the memory kinds (memory.md §4) and DB entries. Each row:

  crime kind → category · who-may-post · payoff · detection-difficulty · severity → punishment (min/max)

A starter set is seeded (the examples in §2’s table); the concrete final list is content / balancing, kept open on purpose — adding a crime is a row, not new machinery, and readers (the profit metric, the courts) opt into it. This matches how the guild levers and memory kinds were left.

6. Already in code

The pillar is 100% greenfield — there is no crime, combat, court, evidence, or punishment concept in the code today. But it builds almost entirely on substrate the other docs define or reuse, rather than new machinery:

• The task system — every crime, force-action, and “come to court” summons is a task (TaskComponent + payload), already a working substrate.

• The memory ledger (memory.md) — isProof entries are the evidence; this pillar adds the witnesses field to the entry anatomy (§3) and many new crime memory kinds (rows in the §4 kinds table).

• The position layer (positions.md) — Marshal, Sheriff, Procurator, Magistrate, building managers, and martial enforcers are all seats; crime posts tasks and pulls levers through them.

• The profit ledger (guilds.md §4) — economic-crime gold is net treasury income like any other, so it feeds the Rogues’ Guild metric unchanged.

• The modifier pipeline (characters.md) — Marshal buffs, guard strength, and the contest’s force totals plug into the existing attribute/trait modifiers.

What is genuinely new is small and additive: the detection roll, the abstract contest, the verdict/corruption formula, the crime→punishment map, and destructible building HP (the one substantial unbuilt piece — see CHALLENGES.md).

7. ⚠ Tensions with current code

• Destructible building HP does not exist. Buildings have levels, not health; the force track (§3a) needs an HP pool and a damage/destruction path. The single biggest unbuilt piece.

• No combat resolution of any kind. strength/dexterity/constitution exist as attributes (characters.md §5.1) but nothing contests them; the §3a roll is new (small — a formula, not a combat engine).

• No courts, no evidence, no memory. The entire legal track rides on the greenfield memory substrate (memory.md §7) and the greenfield council (politics.md §7). Crime cannot ship before those.

• No martial positions / enforcers. CityRole::Guard is a tag with no behaviour; enforcers as seated members with dispatchable attack tasks are unbuilt (positions.md §7).

• The witnesses field is a memory-schema change. Adding it touches the entry anatomy, serialization, and the id_index care for the witness cross-references.

8. Open questions (next pass)

• Detection numbers (§2) — witness radius, the roll weights (perception vs. stealth vs. distance). Balancing.

• Contest formula (§3a) — how attacker/defender force totals combine, the RNG spread, the outcome thresholds. Balancing.

• The corruption formula (§3b) — how the ruling-vs-evidence gap converts to a backfire magnitude, and the standing/recall consequences’ exact size.

• The crime→punishment map (§4/§5) — the seeded list, each crime’s detection-difficulty and min/max sentence. Content + balancing.

• Jail duration & interrogation (§4) — how long a sentence idles a member, and what the Sheriff’s interrogation actually extracts (a confession → more proof? an informant turn?).

• Witness standing weighting (§3) — how much wealth/title tilts a proof’s weight. The standing value itself is now defined in relationships.md §3 (derived from wealth/titles/guild/age); how much it tilts proof weight remains balancing here.

• Narrative generation (§3a) — the flavor-text layer; nice-to-have, parked.