FORKB_ANALYSIS_MECHANICS_ECONOMY_2026-07-27.md

pipelines/FORKB_ANALYSIS_MECHANICS_ECONOMY_2026-07-27.md

FORK B deep dive — AXIS: MECHANICS + ECONOMY

The death-choice state machine and its balance surface

Read-only analysis. Every claim below carries its citation; every "does not exist" is a

positive-controlled absence (the search that could have matched is named). Nothing was written

to either repo.

THE DIRECTION UNDER ANALYSIS (Josh, 2026-07-27, verbatim intent): "after death, allow the

user to choose to revive at last checkpoint, or wait to see if one of their support companions

who may have been trained or taught resurrection may be able to revive the user, but this can

only happen out of combat."

---

0. HEADLINE FINDINGS (the eleven that matter)

1. The direction requires a PLAYER DOWNED state, and canon already has the word for it.

Three revival abilities exist and all three are phrased "restores a downed ally to combat

consciousness with reduced vitality" [A_A_009 Breath of Life, A_C_003 Vril Revival, A_C_004

Vril Mass Revival — T1_Ability_Tree [ACTIVE v1.4] L848/L922/L924 + T0_Ability_Tree_Registry

rows 53/72/73]. Josh's direction is the inversion of an already-canonical mechanic (player

revives downed ally → ally revives downed player). That is the smallest possible canon step,

not a new system.

2. The single largest balance defect is PATH ASYMMETRY, and it is already latent in canon.

All three revival abilities are integrity-gated to L1/L2; the GDD is explicit — "Some abilities

are learned only through kindness — Vril Healing, Vril Revival, Vril Mass Revival"

[docs/original_predclaude/extracted/GDD_Humanity_Game_Complete.md L12630]. If ally-revive is

THE death-mitigation system, the Truly Good path gets an entire safety layer the Evil path

cannot buy. That directly violates §8.11.9 ("every path bucket must field a full and viable

build space… a path whose surviving bench collapses the player into one workable composition is

a balance defect") and CVD §17.4's equal-weighting scope. **The fix is already authored in

principle and unauthored in fact:** "the L4 and L5 evil paths access alternate revival mechanics

through different element routing" [T1_Ability_Tree L848]. Positive control: I searched

T0_Ability_Tree_Registry for every reviv|resurrect row — three rows, all L1/L2. **The evil

revival lane does not exist as data.** Minting it is a required authoring task, not a fork.

3. **The uncertainty Josh wants ("may be able to") should come from SIMULATION, not from a dice

roll.** A hidden revive-percentage on death is the classic feel-bad, it invites retry-farming

against the anti-grind doctrine, and as an RNG event it falls under HL_0061 / CVD §17.13

(±1σ bound, anti-streak floor, mandatory ceiling, reset on drop) — a lot of machinery bought to

purchase a worse feeling. The better source of uncertainty is the fight itself: *can your ally

survive, disengage, and reach you?* That answer is already determined by the §12 build the

player made.

4. THE WAIT IS THE ALLY-BUILD SCORECARD, PLAYED BACK AS A SCENE. This is the strongest

argument for the direction and the reason it is worth the engineering. The wait is the one place

in the game where the player watches the team they built fight without them. §8.11.8's three

INT domains — pattern detection, proactivity, awareness — become *visible* exactly here: the

high-INT support disengages, kites, survives, and comes back; the low-INT bruiser you built

dies beside you. Josh's INT-as-AI axis (ruled 2026-07-26) has had no player-facing showcase

until now. This is it.

5. **There is no in-combat / out-of-combat authority in the runtime, and building one pays four

existing debts.** Positive control: grep -i "InCombat|CombatState|bIsInCombat" across

C:/dev/Humanity/Humanity/Source returns only per-enemy aggro/leash comments — no global

predicate. Four already-canonical rules are silently unenforceable without it: RAGE "decays out

of combat", STAMINA "regenerates quickly outside combat" [T1_Combat_System_Spec §Resource

economy], loadout-set switching "never available mid-encounter" [T1_Combat_System_Spec §14],

and every T0_Ally_Behavior_Policy predicate that needs to know whether a fight is running.

The out-of-combat gate is not a cost of this feature — it forces us to finally pay a debt.

6. **The out-of-combat gate makes the boss-arena case SELF-LIMITING; a blanket ban is the wrong

call.** On a chain-meter boss the win_condition is a *player-performed read* (counter-class

chain, the FREE integrity route) — an ally cannot satisfy it, so the encounter cannot end while

you are down and the wait resolves to attrition. The mechanic disarms itself on exactly the

encounters where it would do the most damage. Recommend a per-row data override, not a rule.

7. The choice must not be DOMINATED. If waiting is free and the checkpoint stays available

throughout, every player always waits and the "choice" is theatre. The cost that fixes it is

already the ruled doctrine: death advances the world — so waiting advances it more, because

the checkpoint is instantaneous and the wait is not. Choosing to wait is choosing to let more of

the world happen without you.

8. Frequency limiting needs NO new counter. The canon-native limit is the ally's vril pool

(cost class high / extreme on the revival rows), refilled at the vril site — which is

already the save + recharge + loadout sanctum [T1_Combat_System_Spec §14]. So "revive at last

checkpoint" and "restore your ally's ability to save you" are the same place. That is an

exceptionally tight loop, it is entirely diegetic, and it needs zero cooldown UI (a visible

cooldown timer would violate the natural-voice doctrine anyway).

9. **The consolation must pay ONCE per encounter instance, and the two branches should pay in

different voices.** The checkpoint branch is a death: the world advances, death_reward fires

as ruled [R1.6; HumanityCharacter.cpp L268-278/L362-370]. The revive branch is a death

*averted* — a "logs his stalk cadence for the retry" line is structurally wrong when there is

no retry. The natural answer, and the natural-voice-perfect one: **the ally who revived you

tells you what they saw while you were down.** Same content, different deliverer, and it makes

the INT investment legible in a sentence.

10. There is no companion capability table — but the direction needs no new table.

T0_Familiar_Bond_Ability is the familiar home (5 rungs, grants_class, integrity_band_gate,

command_permission). The companion equivalent does not exist. The least-new-schema answer is

T0_Bonus_Pool_Registry / T0_Bonus_Option_Registry, which already carry pick_class, lane,

gate_index, unlock_gate_quest_ref, spec_purpose_refs, and respec_class — i.e. Josh's

"trained or taught" maps one-to-one onto an existing schema: *taught* = the

unlock_gate_quest_ref, *trained* = the MAJOR pick that competes with other majors.

11. **The whole feature is blocked on two things that do not exist: an ally actor runtime, and the

non-boss aggro spec.** No AHumanityCompanionCharacter / ally pawn exists (positive control:

enumerated every class HUMANITY_API A* in Source/Humanity/Public — there is none), and

DESIGN_GAP_REGISTER #1 (non-boss engagement/aggro, MISSING, owner W-SPACE) is now a

blocking dependency, because "what an enemy does to a downed player" has no spec at all.

The buildable-now subset is real and worth landing anyway (§10 below).

---

1. THE GROUNDED BASELINE — what already exists (all positive-controlled)

1.1 The ruled defeat axis (player side)

• D-DEFEAT-AXIS RESOLVED (Josh overruled the recommendation, 2026-07-24): "Rated M game.

Things will die. Health 0 is death." Protected-only 1-HP withdrawal; per-boss pips at threshold

[docs/PRE_5090_BUILD_PLAN_VOL2.md L1569-1580].

Scope correction worth surfacing: the 1-HP withdrawal is per-BOSS-ROW

(defeat_protected, "rare, canon-cited"), *not* per protected CHAPTER. In the Ch 2-5 slice

exactly one row carries it — Naga Padoha, on his own J10 cosmic-subdual Batak binding

[VOL2 L1622-1633]. Any brief that says "protected chapters carry 1-HP withdrawal" is reading a

boss column as a chapter policy.

• SL-1 (PG-9): death/respawn = graduated persistence. On death write a graduated ws.* delta;

respawn at the last recharge checkpoint with the world ADVANCED, never reset; no progression

flag hard-gated on a kill [VOL2 L802].

• The Hades loop. "HADES LOOP everywhere: canon's own graduated-consequence failure states

(T1_Combat L343-347) make death advance the world… antagonist-narrative rewards fire on loss

too" [docs/proposals/boss_roster_rows.json]. Pre-journal (before Ch 13) death-learning surfaces

as "remembered tells" on retry.

• Reward on win AND on death [CH_02 §9; HL_0078; TODO_CANON L207-216]. death_reward

populated ⇒ the boss is KILLABLE and both outcomes are live.

1.2 The shipped death shell (the incumbent)

AHumanityCharacter::OnPlayerHealthChanged → HandlePlayerDeath() → capture consolation

(ResolveActiveFightConsolation, R1.6) + telemetry + 0.55 s fade, 0.9 s hold → timer →

RespawnAtNearestSite() → nearest AHumanitySiteMarker (fallback = spawn point) → Health set to

Max → fade back in → consolation shown for ConsolationDisplaySeconds

[Source/Humanity/Private/Core/HumanityCharacter.cpp L216-371]. Both constants are declared

ILLUSTRATIVE under the Phase-5M tuning firewall [TODO_CANON L242].

There is no choice, no downed state, no wait, and no ally in this path.

1.3 The revival canon (the mechanic Josh is inverting)

All three: cast_pattern=instant, eam_pair_eligibility=EAM-on-bonded-{Heart,Crown}, prose

"downed ally … reduced vitality" [T0_Ability_Tree_Registry [ACTIVE v0.1]/Sheet1.csv rows 53/72/73;

T1_Ability_Tree §11.4/§11.7]. Prereq chain: Vril Healing (T4, Ch 6 Sri Lanka) → Vril Revival

(70-99 Philosophus) → Mass Revival (100 Adeptus Minor).

The Ether design note from the originals: "Proper use of Ether abilities may allow successful

completion of the game without harming good or neutral NPCs" [ELEMENTS_MATRIX_RECOVERED.md §Ether].

Revival sits inside the non-kill DNA of the original vision, not beside it.

Resurrection already exists in the boss vocabulary too: Ch 73 Annwn — "a second strike on a

downed Hafgan resurrects him" [docs/proposals/AAA_REARCHITECTURE_PROPOSAL.md L90]. The

player-side mechanic rhymes with an authored boss mechanic; that is a free thematic anchor.

1.4 The ally architecture at HEAD (§§7-12 integrated into tier docs 2026-07-27)

• Stat spreads the PLAYER builds on the canonical six attributes (Str/Dex/Con/Agi/Acc/Int),

specialties and combat styles derived, not assigned; equipment influence continuous with the

spread [T1_Integrity_Paths_Worldstates_Master §8.11.7].

• INT buys behavior quality in three domains — pattern detection / proactivity / awareness —

and competes with the combat attributes on the same spread. Two disciplines bind it:

behavior quality never gates progression, and behavior quality is a **build property, never

an integrity property** [§8.11.8].

• Loadout parity + investment protection: companions carry the player's set slots, pools and

spec purposes; a DEPARTED companion returns gear + imprints + consumables (transferable), keeps

levels/spread/proficiencies (intrinsic) [§8.11.6; T1_Combat_System_Spec §14].

• The departure contract: WAVERING at trigger−15, DEPARTED must sustain across two chapter

nodes, every DEPARTED event carries a non-empty rerouted_paths set (no-dead-end) and the

investment return — "the two clauses are one contract" [§8.11.2].

• §1.4 familiar behavior — already autonomous and already protective: on L1/L2 the familiar

"cannot be used to attack until the familiar steps in **voluntarily at 50% or less player

health… the player cannot override this behavior**". On L4/L5 a sufficiently-bonded familiar

"steps in to protect at 50% or less health and **will not run away or lose loyalty if it dies

protecting the player" [T3_Familiars_Named [ACTIVE v1.0] §1.4]. A familiar dying for you is

already canon.** Extending "steps in before you go down" to "steps in after you go down" is one

step, and it is thematically exact.

• The balance doctrine: OP builds allowed, META-COLLAPSE banned; hundreds-to-thousands of

equally viable builds; a pool option no sweep run selects is a balance DEFECT, fixed by

*widening the option, never removing it* [T1_Combat_System_Spec §15].

1.5 The live schema rail (what is already minted, 2026-07-27)

T0_Ally_Behavior_Policy (8 seed rows), T0_Role_Axis_Registry, T0_Role_Composition_Rule,

T0_Spec_Purpose_Registry, T0_Bonus_Pool_Registry, T0_Bonus_Option_Registry,

T0_Loadout_Set_Definition, T0_Familiar_Bond_Ability, T0_Imprint_Affix, T0_Rarity_Grade,

T0_RNG_Drop_Table, T0_Status_Table, T0_Vril_Site_Registry.

Gates: harness/check_ally_build.py (Gate 29 — budget coherence, bond-ladder coverage, **predicate

lint**, disposition legality, the two firewalls), harness/check_build_space.py,

harness/check_no_dead_end.py, harness/check_reveal_discipline.py,

harness/check_grand_sage_silence.py, harness/check_registry_extensions.py.

T0_Ally_Behavior_Policy seed rows already encode exactly the shape this feature needs:

An ally-revive row is action_ref = revive_downed_ally, domain = proactivity,

autonomy_band = autonomous, disposition_legal_set = protective — structurally identical to

AP_0001. The policy table is ready; only the predicate and the action are missing.

---

2. THE STATE MACHINE

2.1 States

**Terminal conditions that force RETURNING (the honest "may *not* be able to"):**

• Party wipe — every capable ally is itself DOWNED or dead. (Requires DOWNED to be

*party-wide*, §2.5.)

• No capable ally — nobody on the bench has the capability, or the one who did DEPARTED.
• Enemy execute — an enemy with the execute downed-target policy finishes the body (§5.2).
• Encounter policy denies it — ally_revive_policy = denied on the encounter row (§6).
• Ally vril exhausted — the resource limit, not a counter (§8).

2.2 The invariant that makes this safe

**Option A (checkpoint) never fails and is available from the first frame of DOWNED to the

last.** Therefore no configuration of enemies, allies, arenas, integrity bands, or bad luck can

produce a dead end. The two-option structure satisfies check_no_dead_end.py's

non-gating invariant by construction, and that should be written into the gate as an

assertion rather than left as a property nobody checks.

This is the design's best structural property and it should be stated in the ruling: the wait is

always a *pure upside attempt over a guaranteed floor* — which is precisely why the wait must

carry a monotonic cost, or it is a dominated choice (§7.2).

2.3 The choice surface (not a modal, not a menu)

Recommended shape, derived from the natural-voice doctrine + the always-available-skip rule

[docs/NATURAL_VOICE_DOCTRINE.md §1; docs/proposals/PRESENTATION_DOCTRINE.md Fork B]:

• No two-button modal. DOWNED opens with the camera held on the body (see §2.6) and a single

quiet prompt to *let go* — hold-to-accept, available from frame one, never a timer the player

races. Everything else is the world: your allies are still fighting.

• Waiting is the default, not a chosen option. The player does not pick "wait" — the player

simply has not let go yet. That removes an entire decision-UI surface, matches the fiction

exactly, and is what a person would actually experience.

• No greyed-out tease. When no ally can help, the prompt is the only thing there. The mechanic

is taught by content (the first time an ally does it), never by a disabled button.

• No mode taxonomy, no system words. Not "REVIVE / RESPAWN". The prompt is a thought or the

world's own words. Avoid the word "resurrection" on the surface entirely — it is a

theological term and a reveal risk (§2.7); it is fine as the internal token.

• The hold is not skippable-away. Per the skip discipline the *consolation read* must be

skippable from its first frame; the *hold to accept* is the opposite — a deliberate commitment.

2.4 Timing shape (all magnitudes Phase-5M; shapes only)

• DOWNED has no fixed duration. It ends on an event, never on a clock. A countdown would

convert the choice into a race and would read as a computer's voice.

• The revive itself is cast_pattern = instant per the ability rows — but the ally must *reach*

you, and that traversal is where the drama lives. The cast is instant; the journey is not.

• On REVIVED, the player returns at reduced vitality — canon's own word, three times over.

Recommend it also carries a short lingering impairment (a T0_Status_Table entry) so a second

down in the same encounter is genuinely worse than the first (§8.3).

2.5 DOWNED must be party-wide, not player-only

This is forced, not chosen: canon's revival abilities target *downed allies*, and Vril Mass Revival

is multi-target, so allies must have a downed state for the player's own kit to mean anything. The

rule that falls out is clean and symmetric:

Party members (protagonist, companions, familiars) go DOWN at 0. Hostiles DIE at 0.

That asymmetry is not a contradiction of the rated-M ruling — D-DEFEAT-AXIS is explicitly *the boss

HP=0 defeat model*, and the player side has always been separately owned by SL-1. It should be

stated in the ruling so no later reader treats it as drift. The in-world justification is already

there: the protagonist is a vril vessel that empties, and "return to combat consciousness" is

canon's existing phrase for refilling it.

2.6 Presentation — this direction SETTLES Fork B by splitting it

PRESENTATION_DOCTRINE.md §0.B is currently escalated with four options (0 = the shipped 0.55 s

fade, 1 = hard cut + diegetic return, 2 = dissolve both ways, 3 = hold on the body). **Josh's

direction resolves it per-branch, which none of the four options anticipated:**

• The wait branch *requires* Option 3 — you cannot watch your allies fight through a fade. The

camera stays with the body (or lifts a little and stays live).

• The checkpoint branch is where Option 1's hard cut belongs — the moment the player lets go is

the moment the world cuts.

That is a strictly better answer than any single option, and it disarms Fork B's strongest

objection ("making death the one routine hard cut trains the player to read a cut as failure"):

the cut now reads as *the player's own decision to stop*, not as the game punishing them.

Cross-axis note for the presentation lane.

2.7 Reveal discipline on a death surface

DOWNED is a metaphysically loaded moment and the two standing gates

(check_reveal_discipline.py, check_grand_sage_silence.py) must scope its strings.

• No afterlife, no threshold, no "reader", no Grand-Sage register, no L3 vril-consciousness

theology. Ever.

• Astral framing is a trap. "You float above your body" is diegetically available only from

Ch 15 (Astral Projection, tomb artifact) and leaks a Crown-seat capability the player does not

have. Pre-Ch-15 the read must be *body-and-senses*: the world greys, sound muffles, the edges go

soft. Not a soul leaving — a vessel emptying.

• The ally's revive line is the highest-risk string in the feature (a healer talking about bringing

someone back is one adjective away from theology). It goes through the natural-voice rewrite pass

with string_status tracked, and through the reveal gate.

---

3. THE WAIT — what it costs and what it shows

3.1 What the player watches

The party fighting without them. Not a cutscene, not a spectator camera with a UI — the same live

world, from a body on the ground. This is the payoff (§0.4) and it is also the entire cost

structure, because the thing being spent is time in a world that is advancing.

3.2 What the wait actually costs — three real currencies, no new ones

1. World time. Ruled doctrine: death advances the world. The checkpoint is instantaneous; the

wait is not. Objective clocks keep burning, the ambient world clock (LW-1) advances, the

encounter keeps resolving. **The player who waits and then takes the checkpoint anyway has paid

strictly more than the player who took it immediately.** This is the anti-domination cost and it

costs nothing to build — it is emergent from a ruling already in force.

2. Ally resources and ally risk. Your allies fight a fight they were not built to win alone.

They spend vril, they take damage, they can go down. A revive that succeeds still leaves the

party depleted going into whatever comes next — and depletion is real because the refill is at

the vril site (§8.1).

3. The revive itself. The ally's vril, the reagent, or the bond charge — spent, and refilled

only at the sanctum.

3.3 What the wait must NOT be

• Not a countdown bar. No timer UI. (Computer voice; also converts a choice into a race.)
• Not a hidden percentage. See §0.3 — and note that if it *were* a roll it would fall under

HL_0061's σ-bound + anti-streak + reset-on-drop discipline, which is heavy machinery for a worse

outcome.

• Not an AFK farm. If allies keep clearing the zone while you lie there, a player can farm

from the floor. **Mitigation, which is also correct behavior under §8.11.8 awareness: allies do

not initiate new engagements while the player is downed.** They finish what is on them and come

for you. One rule, closes the exploit, improves the fiction.

• Not a difficulty death-spiral. The world-demand dials (UHumanityTellSlackGE,

UHumanityPunishWindowGE, UHumanityRechargeLatencyGE, UHumanityAnswerPruningGE — these exist

in Source/Humanity/Public/Combat/HumanityWorldDemandGE.h) are a *tempting* way to express "the

world presses harder while you're down". Flagged as a candidate, not recommended without

Phase-5M evidence: pressing harder on a party that is already losing is how you build a spiral.

3.4 The interruption question

Yes — the revive can be interrupted, and it should be, but not by an RNG check. The ally must

survive, disengage, and reach you; anything that stops that stops the revive. An enemy that peels

onto your healer *is* the interruption. That is the mechanic doing its own job with no new system.

---

4. OUT-OF-COMBAT-ONLY — the enforcement problem

4.1 The authority does not exist (positive control)

grep -rEi "InCombat|CombatState|bIsInCombat|Aggro|Leash|Disengage" over

C:/dev/Humanity/Humanity/Source returns: per-enemy perception/leash state machine on

AHumanityEnemyCharacter (EHumanityEnemyState{Idle,Patrol,Pursue,Attack,Return}, IsAggroed(),

AggroRadius=1400, DeAggroRadius=2200, LeashRadius=3000, all ILLUSTRATIVE), the boss-side

aggression_meter/add_wave in COMBAT_ENCOUNTER_SYSTEM §4.2/§4.6, and AHumanityEncounterVolume.

No global or party-scoped combat-state predicate anywhere.

4.2 The recommended authority: UHumanityCombatStateSubsystem (ENGINE, reusable)

Derived, not authored:

EncounterActive = ( any hostile registered to the active encounter volume
                    with State ∈ {Pursue, Attack} OR bPerceivedThisFrame )
                  OR ( an active boss encounter whose win_condition is unresolved )

plus a settle hysteresis (combat ends N seconds after the last aggro drops) so a momentary LOS

break mid-fight is never mistaken for peace. The existing DeAggroRadius already implements

hysteresis at the perception layer — the settle timer is its encounter-scoped twin.

Declare it ENGINE, not CANON (per the engine-reuse standing rule): a combat-state authority

with settle hysteresis is game-agnostic. What is CANON is which encounters it scopes and the

per-row policy that reads it.

It pays four debts on landing (§0.5): RAGE decay, STAMINA out-of-combat regen, the

loadout-switch ban, and the ally policy predicates. That is the argument for scheduling it now.

4.3 What ENDS combat around a downed body — the four cases

4.4 The grammar problem (a real, small schema finding)

The §9.5 mini-grammar (harness/condition_expr.py, the spec the C++ evaluator ports) supports

has(local.key), at(site_id), flag(local.key), ws.key with ==/>=/<=/in, read(surface),

and boolean &/|. Positive control: in_combat = 0 occurrences, encounter = 0 occurrences.

Worse, the grammar's contract is **produce-before-consume — "every consumed flag or local key must

be produced by a prior beat's out:"**. A combat-state flag is produced by the *runtime*, not by a

beat, so flag(local.encounter_resolved) would either fail the produce-before-consume lint or

require a fake producer beat.

Recommendation: add a first-class runtime-surface token rather than faking a flag — either

read(combat_state) under the existing read(surface) form (cheapest; the form already exists) or

a new in_combat predicate. Whichever lands, harness/condition_expr.py must learn it and

check_ally_build.py B3 (predicate lint) will then hold the line: "a malformed predicate must

fail loudly, never silently match nothing" — which is exactly the failure mode this feature cannot

afford (an out-of-combat gate that silently never matches = a revive that silently never fires).

---

5. THE ENEMY SIDE — the blocking gap

5.1 The gap, cited

DESIGN_GAP_REGISTER #1 — "Non-boss engagement / aggro spec", lens wow, class MISSING,

owner W-SPACE, ruling No (i.e. the loop rules and applies). "No design governs how ordinary

encounters are spaced or engaged: aggro radius, detection channel, patrol path, leash/reset, and

camp/group clustering… T1_Combat_System_Spec [ACTIVE v1.0] has zero threat/aggro/pull/leash…

T0_Creature_Roster has no aggro column." Confirmed in-engine: "TG-12: the roster has NO

aggro/patrol/leash/flee columns" [HumanityEnemyCharacter.cpp L252].

This direction promotes that gap from "highest-leverage improvement" to "blocking dependency",

because the wait's entire outcome distribution is decided by what enemies do to a body.

5.2 The one new column that decides everything: downed_target_policy

Proposed enum on T0_Creature_Roster (rides the aggro block the register already recommends):

execute is the most important value in this analysis. It is the reason the wait is not free,

it is register-correct for a rated-M game, it creates the single best moment the feature can

produce (your ally peels the executioner off you at the last instant — §8.11.8 proactivity made

visceral), and it does it without a die roll. It also fixes the "enemies wander off ⇒ free revive"

leak in §4.3 case 2, because the encounters that matter carry execute or guard.

Anti-softlock note: guard looks dangerous but is not, because Option A never fails (§2.2). A

guarding enemy does not trap the player; it *removes the wait as an option*, which is a legitimate

design statement about that enemy ("this thing will not let your people reach you"). The gate to

assert is: **no encounter may set ally_revive_policy = denied AND have no checkpoint reachable —

which is unfalsifiable today because the checkpoint is always reachable.** Assert it anyway so a

future change cannot break it silently.

5.3 Symmetry: can enemies revive each other?

The world's rules should be symmetric — canon already runs on "all sides wield both" (real physics +

real magic), and Ch 73's Hafgan resurrects. Enemy healers who revive their own downed create

interrupt-the-healer play, which is genuine content and which the high-INT ally is exactly built to

handle (pattern detection → "interrupt a cast worth interrupting", §8.11.8 verbatim). **Recommend

as an authoring capability on the roster, explicitly out of slice scope.**

---

6. THE BOSS-ARENA CASE

**Recommendation: NOT a blanket checkpoint-only rule. A per-row data flag defaulting to allowed,

with the mechanic self-limiting on the encounters that matter.**

6.1 Why a blanket ban is wrong

• It forces the choice surface to suppress Option B in every boss fight, which teaches the player

the mechanic is fake at exactly the moments they care most.

• It deletes the single best memory the feature can produce (the party finishes the boss while you

are down).

• It is unnecessary, because of §6.2.

6.2 Why the mechanic disarms itself on chain-meter bosses

The pip/counter-class boss is the design centrepiece [R2; Josh's puzzle-boss ruling], and its

win_condition is a player-performed read: 5-7+ correct counter-class reads in a row on a

visible pip meter that wipes on a mistake. An ally cannot perform that read. Likewise Rangku's FREE

route is an *integrity choice* only the player can make [R1.2/R1.3/R1.4], and Naga Padoha's

defeat_protected resolution is a cosmic subdual [VOL2 L1632]. **On precisely the encounters where

an ally-undo would be most damaging, the encounter cannot end while the player is down** — so the

wait resolves to attrition and then to the checkpoint. No rule needed; the design already does it.

6.3 Where the data flag earns its place

A new T0_Boss_Encounter_Registry column ally_revive_policy ∈ {allowed, denied}, landed on the

proven registry-extension rail (docs/registry_extensions.json, combat-encounter ownership —

the exact vector used for the four pip columns, schema-dictionary annotated, fidelity re-baselined

in the same commit) [VOL2 L1622-1633]. Set denied only where canon requires the player's own

resolution and the encounter *could* otherwise end without them. Default allowed; **empty means

not-yet-populated, never denied** — the same discipline the pip columns already carry ("empty =

not-yet-populated, NEVER kill-only").

6.4 The Composure interaction

Boss state persists across a player death today ("the boss remembers" — graduated persistence,

HumanityCharacter.cpp L348-351). During a wait the boss is *live*, not paused, so its Composure

and phase state simply continue. Nothing new is required; but the ruling should say so explicitly,

because a reader could reasonably assume DOWNED pauses the fight, and it must not.

---

7. THE ECONOMY — costs, and the domination problem

7.1 The revive's direct cost

Vril, per canon, is the primary cost and it is already specified: high (Vril Revival, Breath

of Life), extreme (Mass Revival). No new resource. The ally spends from their own pool, which

means an ally built for support (§8.11.7 spread) can do it more than once and an ally built as a

wall cannot — the tradeoff lands on the spread, exactly where §12 wants it.

Three routes, all costed (see §9.2 for why three):

7.2 THE DOMINATION PROBLEM (the #1 economy defect to avoid)

If waiting is free and the checkpoint remains available throughout, waiting strictly dominates

and the choice is theatre. Three teeth, in preference order:

1. World time (recommended, free). Waiting advances the world more than letting go does — the

ruled doctrine, already in force, needs only to be *made visible*.

2. Depletion carried forward (recommended). A successful revive leaves the party spent going

into the next encounter, refillable only at the sanctum.

3. execute (recommended). Waiting can end *worse* than letting go — the body is finished, and

whatever the wait already cost is spent for nothing.

Explicitly reject: a wait timer, a hidden roll, an XP/loot penalty on the wait, and any

"you may only choose once" lockout. The last one is worth naming: **letting go must stay available

for the entire wait**. A player who waits ninety seconds and then decides to take the checkpoint

must be able to. That is both the no-dead-end floor and simple respect.

7.3 Does a revive cheapen the Hades economy?

Honestly: somewhat — and that is what Josh is buying. A comeback fantasy is worth some death-weight.

The compensation is that the *weight moves* rather than disappearing: the world still advanced, the

party is still spent, and the thing that saved you was a build you made and a relationship you kept.

Two disciplines keep it honest:

• The consolation pays once per encounter instance, on either branch. Otherwise you get

farm-the-revive. This needs a small durable ledger (§9.1 item 10).

• The two branches pay in different voices (§0.9): the checkpoint branch fires death_reward

as ruled; the revive branch delivers the same knowledge **as a line from the ally who watched the

fight while you were down**. That is natural-voice-perfect, it converts INT investment into an

audible payoff, and it costs one string per encounter that the schema already has a field for.

7.4 Reduced vitality is the third lever

Canon says revival returns you at reduced vitality — three times, in three ability rows. Lean on it:

the revived player is fragile, so the revive is a *second chance*, not a reset. Successive downs in

one encounter return progressively less (§8.3). No counter, no UI, entirely diegetic.

---

8. FREQUENCY LIMITING WITHOUT GRIND

8.1 The recommendation: the vril pool + the sanctum, and nothing else

No per-rest counter, no per-chapter cap, no cooldown timer.

• The ally spends vril; the pool refills at the vril site — canon's save + recharge + loadout

sanctum [T1_Combat_System_Spec §14; AHumanityVrilRechargeZone is built for Ch 2].

• Therefore: **"revive at last checkpoint" and "restore your ally's ability to save you" are the

same place.** The loop closes on itself with zero new systems.

• Against the anti-grind canon this is clean: rested-XP is a positive-controlled zero and explicitly

rejected as an import [DESIGN_GAP_REGISTER #9 — "do not import it"]; "mindless

rune-grinding is explicitly not a mechanic" [T1_Combat_System_Spec §Resource economy]. A

resource that refills at the place you already go is the anti-grind-native answer.

8.2 Why per-chapter and per-rest are both wrong

• Per-chapter invites save-scumming and collides with chapter-length variance (combat density

runs "in the dozens of designed encounters" per chapter, T1_Combat_System_Spec §Combat Variety).

• Per-rest is the WoW/BG3 shape, but there is no rest system (gap #9 is WEAKER and explicitly

bounded), and building one to limit a revive is backwards.

8.3 The one escalation to add: diegetic exhaustion, not a cap

Successive revives within a short window return progressively lower vitality and leave a lingering

impairment on the *ally* — a T0_Status_Table entry, riding the status framework already scheduled

[COMBAT_PROGRAM_ADDENDUM §3]. The second revive is meaningfully worse than the first, so chaining

is self-defeating without a counter the player can game or a number the UI must show.

---

9. ANTI-META-COLLAPSE — the balance surface (the core of this axis)

9.1 Three distinct collapse vectors

(A) Team-composition collapse. If ally-revive is strictly the best insurance, every player

fields a revive-capable support and the axis §12 just opened ("team composition is CONTENT")

collapses to one slot. This is verbatim the banned failure mode [§10: "you only have 1 or 2 viable

options and nothing is actually customizable"].

(B) Path-asymmetry collapse. Detailed at §0.2. This is the sharpest one because it is already

latent in shipped canon, and because it does something worse than unbalance a build: it converts

the integrity axis into a difficulty setting, teaching players to pick Good for mechanical

safety. That inverts what §8.11.8 explicitly protects when it firewalls behavior quality from

loyalty ("investment can never buy loyalty immunity") — the same logic must apply here: *the moral

path must not buy survival immunity.*

(C) INT-axis collapse. If resurrection *requires* high INT, then INT stops being a tradeoff and

becomes a tax, and §12's mandatory competition ("can't all be in intelligence or they won't be very

strong") is deleted on the one stat that matters most.

9.2 The fix for (B): three routes to one mechanic

Mint the two missing lanes so the mechanic is path-agnostic:

1. Compassion route — the existing L1/L2 rows. Vril cost, no external cost.

2. Extraction route — L4/L5, "alternate revival mechanics through different element routing"

[T1_Ability_Tree L848], Ether-Crown / Soul Drain adjacency (A_C_007 Soul Drain exists;

the evil revival row does not — verified). It takes vitality from something living: cheap in

vril, expensive in the world (community ripple, faction, persona memory). **Same slot, opposite

moral cost.** This is not a softening of the evil path — it is the evil path's own idiom, and it

is more interesting than the good path's version.

3. Craft route — a reagent or inscription any ally can carry, no integrity gate, gated

instead by the trade economy (Alchemy / Herbalism / Inscription) and the drop tables. This is the

keystone: it is the L3 Drifting answer, it is the bench-independence answer when your healer

DEPARTS (§9.5), and it is the reason revival is not a build-slot tax.

9.3 The fix for (A) and (C): access is TAUGHT, reliability is TRAINED

Josh said "trained or taught". Read them as two layers rather than two options:

• TAUGHT = access. A questline / gate crossing unlocks the capability. Content, discoverable,

EXAMPLES-NOT-LIMITS expandable per region. **Schema: T0_Bonus_Pool_Registry.unlock_gate_quest_ref

— the column already exists.**

• TRAINED = reliability. The ally's INT + support-role weighting + bond rung + spec purpose

determine how *well* they do it: whether they judge the moment correctly, survive to reach you,

and how much vitality they return.

So: any taught ally can attempt it; only a built ally does it well. INT gates the *decision

quality*, never the *access* — which is exactly §8.11.8's three domains applied to one high-stakes

decision, and which produces Josh's "may be able to" from simulation instead of dice.

9.4 The build cost, landed where the doctrine wants it

On the companion side the capability is a MAJOR pick on a support pool:

pick_class=major, lane=B, gate_index = the crossing, unlock_gate_quest_ref = the healer

questline, spec_purpose_refs → a new SPEC_VRIL_REVIVE_ALLY token in T0_Spec_Purpose_Registry

(distinct from the existing SPEC_VRIL_HEAL_PERSONAL, because revival is the role that makes

glass-cannon protagonist specs viable — that is a different function, and §14A wants it tagged).

Taking it means not taking a damage/utility major. That is the anti-collapse tradeoff expressed

entirely in the ruled architecture, and it is measurable: harness/check_build_space.py reports

per-option pick rates, and per §15 *both* extremes are defects —

• never picked ⇒ the revival option is too weak / the cost is wrong;
• always picked ⇒ meta-collapse, the exact banned failure mode.

Fix by widening the competing options, never by removing the revival option [§15 verbatim].

Recommend a named sweep assertion: the build-space sweep must report the revival-major pick

rate per path bucket (L1/L2, L3, L4/L5) — a rate near 100% in one bucket and near 0% in another is

the path-asymmetry defect showing up as a number instead of as an argument.

9.5 The DEPARTED interaction (a feature, with one guardrail)

If your revive-capable companion departs over your integrity, you lose the insurance mid-chapter.

That is the integrity thesis working perfectly and it should absolutely be allowed to happen.

The guardrail is §8.11.9's "every path bucket must field a full and viable build space": the craft

route (§9.2 item 3) is bench-independent, so a departure narrows the player's options without

deleting the mechanic. Record that as a *requirement on the craft route's existence*, not as a

nicety.

Gear-return composes cleanly: if the capability rides an imprint on issued gear, the departing

companion returns it per the investment-protection contract [§8.11.6], and the player re-issues it

to someone else. The capability comes home; the person does not.

9.6 The two firewalls this feature must not breach

check_ally_build.py B5 already encodes them and will catch violations:

• (i) Behavior quality is a BUILD property, never an integrity property — "no policy

condition_expr may read a loyalty ws key". **Therefore the revive policy may not be

loyalty-gated.** A companion who is wavering still tries to save you. That is both the gate's

rule and, on reflection, the better fiction.

• (ii) policy_source is a CLOSED enum with no player-authored member — the gambits-busywork

guard. The player may not author the revive policy. They build the ally; the ally decides.

This is also §1.4's existing rule for L1/L2 familiars ("the player cannot override this

behavior"), so the feature inherits a discipline that is already canon rather than inventing one.

9.7 One more collapse risk worth naming

If revival is the *only* thing that makes glass-cannon protagonist specs viable, then glass-cannon

specs become "revival specs" and the composition space narrows from the other direction. Counter:

T0_Role_Composition_Rule exists precisely to encode composition legality/precedence, and the

sweeps read it. Worth one rule row asserting that at least one viable glass-damage composition

clears the bar without a revive-capable ally.

---

10. FAMILIAR PARITY

• The behavioral precedent is already canon and already autonomous. §1.4: the L1/L2 familiar

steps in voluntarily at ≤50% player health and the player cannot override it; the L4/L5

sufficiently-bonded familiar does the same and **"will not run away or lose loyalty if it dies

protecting the player."** Extending "steps in before you go down" → "steps in after you go down"

is the smallest step in this entire analysis, and it lands on both integrity poles, which

incidentally gives the path-asymmetry problem (§9.1B) a *second* independent fix on the familiar

side.

• Schema home: T0_Familiar_Bond_Ability. Row shape: bond_level = a high rung,

grants_class=active, integrity_band_gate, command_permission=autonomous,

ability_effect_summary in natural voice, eam_pair_ref where the Crown/Heart pairing applies.

• The gate constrains the design in a useful way. check_ally_build.py B2 requires every

familiar to carry all five rungs exactly once (target 22 × 5 = 110). So a revival grant cannot

be sprinkled across the roster — it occupies *one rung on some familiars*, and those familiars'

peers grant something else at the same rung. That is automatically anti-collapse: not every

familiar can revive, so the familiar choice stays a genuine spec decision [§8.11.5].

• check_ally_build.py B4 bars aggressive in the L1/L2 disposition set; a revive policy is

protective — compliant.

• Adjacent canon that fits beautifully: Shell's Bond-100 ultimate amplifies the *party's entire

vril capacity by 150%* for an encounter [T3_Familiars_Named §2 W1]. A familiar that boosts party

vril is one step from a familiar that enables a second revive. Worth wiring deliberately.

• Flag: the path-variable 22nd slot is an endgame build axis of its own [§8.11.5]. A

revival-capable 22nd on the good path would *amplify* path asymmetry rather than fix it —

authoring note, not a blocker.

---

11. SCHEMA MAP — every mechanic to the row that must carry it

Gates that must gain teeth: check_ally_build.py (B3 predicate lint covers #7 automatically;

add a revive-specific must-fire fixture), check_build_space.py (per-path revival pick rate, §9.4),

check_no_dead_end.py (assert the §2.2 invariant explicitly), check_reveal_discipline.py +

check_grand_sage_silence.py (scope the new death-surface strings), check_registry_extensions.py

(#11/#12), check_ws_value_form.py (#3, #14), registry_fidelity.py --emit-baseline in the same

commit as any registry edit.

---

12. RUNTIME BUILD MAP — what must be built, and what is honestly blocked

12.1 ENGINE (reusable, declare as such per the standing engine-reuse rule)

• UHumanityCombatStateSubsystem — the in/out-of-combat authority with settle hysteresis (§4.2).

Pays four existing debts on landing.

• A generic incapacitated/downed state on the character base + a revive interaction.
• A "last activated site" ledger on the save.

12.2 CANON (data + the specific policies)

• Which encounters deny ally revive; which creatures execute/guard; which allies and familiars carry

the capability; the strings.

12.3 The honest blocker

No ally pawn exists. Positive control: every class HUMANITY_API A* in

Source/Humanity/Public was enumerated — AHumanityArenaHazard, AHumanityEncounterVolume,

AHumanityTraceTellSequence, AHumanityCharacter, AHumanityBossCharacter,

AHumanityEnemyCharacter, AHumanitySiteMarker, AHumanityWaterVolume, AHumanityGatherNode,

AHumanityVrilRechargeZone. There is a UHumanityFamiliarAbility verb class but **no companion or

familiar actor**. The addendum already homes this correctly: "the post-slice companion AI runtime

(INT-tiered behavior trees)" [§12 OWNER line].

Therefore the buildable-now subset — which is worth landing on its own merits:

1. UHumanityCombatStateSubsystem (pays the four debts regardless of this feature).

2. The DOWNED state replacing the immediate fade+timer in HandlePlayerDeath().

3. The hold-to-let-go surface + the held camera (which also settles Fork B, §2.6).

4. The checkpoint branch redefined as last activated vril site rather than nearest site marker

(§13.1) + the save field.

5. downed_target_policy on the enemy state machine (a small branch in an existing machine).

6. All sixteen schema items in §11 — data work, zero-token, no model budget.

7. The QA fixtures (§12.4).

With the ally runtime absent, the wait branch resolves to "nobody can reach you" — which is honest,

no-dead-end, fully testable, and becomes the real mechanic the moment allies exist. **Nothing is

wasted and nothing is faked.**

12.4 QA (the machine is the only player — the evidence bar)

Must-fire automation tests, homed in HumanityCombatAutomationTests / HumanityEncounterAutomationTests:

• letting go is available on the first frame of DOWNED and on the last;
• DOWNED → party wipe → forced checkpoint, no softlock;
• DOWNED → combat settles → revive fires → player is ALIVE at reduced vitality;
• a guard enemy never softlocks (the let-go path still resolves);
• an execute enemy ends the wait and routes to the checkpoint;
• the consolation pays exactly once per encounter instance across both branches;
• the out-of-combat predicate does not fire during a momentary LOS break (the hysteresis test —

this is the one most likely to be wrong and least likely to be noticed);

• check_ally_build.py --self-test fixtures for the new predicate and the new policy rows.

---

13. OPEN ITEMS FOR THE DIRECTOR (with recommendations — no bare questions)

13.1 "Last checkpoint" vs "nearest site" — a real semantic fork

Josh said last. The shipped code does nearest (RespawnAtNearestSite). These differ

materially: a player who ran past a site and died beyond it is sent *backward* by "last" and

*forward-ish* by "nearest".

RECOMMEND: last ACTIVATED vril site, falling back to the chapter entry anchor. Reasons — it is

what Josh said; it makes touching a site a deliberate act, reinforcing the sanctum loop and the §14

loadout siting; and it is the same place the ally's vril comes back (§8.1), which closes the loop.

Strongest objection: it can send the player further back than the current behavior, which reads

as harsher. Mitigation: sites are dense by design (save + recharge + loadout), so "last touched"

and "nearest" converge in practice, and the difference shows up mainly when the player *chose* to

skip a site — which is a decision that should have a consequence.

13.2 Does the choice UI appear when Option B is impossible?

RECOMMEND: no greyed tease. Show what is possible. The mechanic is taught by content (the first

time an ally does it), never by a disabled button — per the natural-voice doctrine's "never sounds

like a computer wrote it" and the no-mode-taxonomy rule.

Strongest objection: a player may never discover the mechanic. Mitigation: the taught-access

questline is the discovery vector, and the first ally revive is authored as a beat.

13.3 Blanket boss ban vs per-row flag

RECOMMEND: per-row ally_revive_policy, default allowed (§6). The chain-meter bosses

self-limit; the flag exists for the rare authored exception.

13.4 The evil-path revival lane

Not a fork — an authoring task the loop rules and applies, cited to T1_Ability_Tree L848 which

already declares it exists. The only genuinely Josh-tier question inside it is the *flavor* of the

extraction cost, and even that is creative-within-vision.

13.5 Cross-axis notes for other lanes

• Presentation (Fork B): this direction resolves it per-branch (§2.6) — held camera on the wait,

hard cut on the let-go. Better than any of the four options; worth folding into that fork's brief.

• W-SPACE / aggro spec: DESIGN_GAP_REGISTER #1 is promoted from "highest-leverage" to

blocking, and gains a specific new column (downed_target_policy) that the register does not

currently name.

• Phase-5M/5H: the build-space sweeps gain a named per-path revival pick-rate assertion (§9.4).
• Doc-map discipline: any new artifact needs its docs/DOC_MAP.md row and a named consumer, or

it is an orphan.

---

14. THE ONE-PARAGRAPH RECOMMENDATION

Build the direction as a party-wide DOWNED state rather than as a death menu: at 0 the

protagonist goes down, the camera stays with the body, the let-go prompt is available from the first

frame to the last, and *not letting go is the wait* — no second button, no timer, no roll. The

wait's outcome is decided by the fight the player already built: allies with the capability

taught (a questline gate) and the reliability trained (INT + support weighting + bond rung)

must survive, disengage, and reach you, while enemies carry a new downed_target_policy whose

execute value is the mechanic's teeth. Gate it on a real UHumanityCombatStateSubsystem — which

pays four existing canon debts on landing — and cost it in ally vril refilled at the vril site,

so the checkpoint and the ally's ability to save you are the same place. Protect the balance surface

with three routes to one mechanic (compassion L1/L2, extraction L4/L5 — **which canon promises and

has never authored**, craft/reagent with no integrity gate), make the revival capability a MAJOR

pick that competes with other majors, and measure it: a per-path revival pick rate near 100% is

meta-collapse and near 0% is a dead pick, and both are defects fixed by widening the competing

options. The whole thing is buildable in two stages, and the first stage — the downed state, the

combat-state authority, the checkpoint semantics, the enemy policy, and all sixteen schema rows —

is worth landing even before an ally pawn exists.

Generated by harness/site/structure_site.py — the URL path is the repo path. review root