Stochastic loot engine design document

STOCHASTIC LOOT ENGINE

Simulation & Verification Architecture

Design Document · v0.1 Draft

June 2026

Emergent outlier builds are not design failures --- they are the intended attractor state.

Scope note: This document predates the Layer II compositional and Layer III stochastic verification work (landed 2026-10). It records design intent; shipped behavior is governed by the openspec specs and docs/development/architecture/.

1. Introduction & Design Philosophy

This document specifies the architecture of a stochastic loot engine for an idle/simulation game. The system generates unique items and skills with randomised modifier ranges, governed by rarity tiers, and evaluates character loadouts for emergent power interactions. The document serves as both a design reference and an executable specification: every structural claim made herein corresponds to an algebraically verifiable property of the underlying generative model.

1.1 Core Design Axiom

The central design axiom departs from conventional loot game philosophy:

This axiom has three direct consequences for the architecture:

Outlier existence must be guaranteed. The system must be provably capable of producing supercritical builds at the Uber Legendary rarity tier.
Outlier frequency must be bounded. The probability of a randomly assembled loadout being an outlier must remain below a configurable sparsity threshold ε.
Outlier structure must be discoverable. The verification system must be capable of identifying and describing the causal mechanism of any detected outlier, so that it can be surfaced to the player as meaningful information.

1.2 Scope

This document covers the following subsystems:

The Unified Skill Primitive and its formal syntax
The Item and Template generation model
The Charge resource system
The Rarity tier distribution model
The three-layer Simulation Verification Architecture
The algebraic laws governing system correctness

Actual implementation language and runtime environment are not specified in this document. The architecture is described in the abstract, with formal properties expressed as algebraic laws amenable to property-based testing in any language with a suitable framework (Hypothesis, QuickCheck, proptest, fast-check).

2. Core Primitives

2.1 The Unified Skill Primitive

A Skill is the fundamental unit of the system. Its origin --- whether acquired through a class skill tree, equipped as an item, or granted by an item-intrinsic effect --- is an acquisition pathway and is not a property of the skill itself. At the engine level, all Skills are structurally identical.

Formal definition: Skill := { Triggers, Conditions, Effects, Tags, Modifiers, ChargeCost, Cooldown, StackBehavior }

Triggers One or more event tokens drawn from the global event vocabulary (e.g. OnCombatInitiate, OnKill, OnSightLost). A Skill activates when any declared Trigger fires and all Conditions are satisfied.

Conditions A predicate over game state. May be absent (unconditional), simple (single predicate), or compound (boolean combination). Conditions reference producible state variables only.

Effects One or more state mutations. An Effect may emit a new Trigger into the event graph, creating chain links. Effect types: ApplyBuff, SpawnObject, ModifyCharge, EmitTrigger.

Tags Set membership labels (e.g. {Movement, Utility}, {AoE, Debuff}). Tags participate in compatibility scoring and loadout classification but do not affect runtime evaluation.

Modifiers Typed numeric adjustments to game state variables. Every Modifier declares its aggregation layer (Additive or Multiplicative) and its target variable explicitly.

ChargeCost Integer ≥ 0 for consuming skills; negative integer for Charge-granting skills. Default: 1. Zero-cost skills must be explicitly declared as passive.

Cooldown Duration > 0 for active skills. Tracked on the caster’s persistent ledger, keyed by stable Skill identity. Persists across item changes and upgrades.

StackBehavior One of: Exclusive (only one instance active), Additive (instances accumulate modifier values), Multiplicative (instances multiply modifier magnitudes). Declared per-template.

2.2 Skill Syntax

Each Skill is expressed as a production rule:

+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Skill Production Rule | | | | WHEN <Trigger> IF <Condition> DO <Effect> TAGGED <TagSet> Example --- Smoke Cloud: WHEN OnCombatInitiate IF (none) DO SpawnObject(SmokeCloud, CasterPosition) TAGGED {Utility, AoE} Example --- Sight-Loss Speed: WHEN OnSightLost IF EnemyCount(SightLost) >= 1 DO ApplyBuff(MovementSpeed, X, Duration) TAGGED {Movement, Buff} | +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

The EmitTrigger effect type is the mechanism by which Skills form chains. A Smoke Cloud whose SpawnObject effect emits OnSightLost for affected enemies creates a directed edge in the trigger graph between itself and any Skill listening for OnSightLost. Chains are not declared explicitly --- they emerge from effect-to-trigger matching.

2.3 Cooldown Persistence Model

Cooldowns are attached to Skill identity, not to item slots or skill slots. This has three operational consequences:

Unequip does not reset. Removing an item suspends the item-granted skill but preserves its cooldown timer. Re-equipping resumes from the persisted state.
Upgrade migrates state. When a Skill is upgraded, the cooldown ledger entry is migrated to the new Skill version using the stable identity key.
No cooldown reset exploits. A player cannot reset a skill’s cooldown by cycling equipment. The cooldown is a property of the caster’s history with the Skill, not the item’s equipped state.

2.4 Condition Temporality Classes

Conditions are categorised by their temporal model, which governs how they interact with the trigger graph:

Class Example Behaviour

Spatial EnemyInSmokeCloud True for entities within a defined area for the area’s duration. Effectively permanent if the area is repositioned faster than it decays.

Decaying RecentlyKilled True for a defined window after a triggering event. Can be refreshed if the trigger fires faster than the decay period.

Accumulating StackCount(Poison) >= N Grows with repeated applications. Can be maintained indefinitely if the application rate exceeds the decay rate.

A Decaying condition that can be refreshed faster than it decays is functionally equivalent to a persistent condition for a Charge-sufficient caster. This is a primary mechanism for non-obvious outlier generation and must be explicitly modelled in the verification system.

3. Items and Template Generation

3.1 Two-Layer Generation Model

Item generation operates across two distinct layers with different evaluation times and different design surfaces:

Layer Name Evaluation Time Design Surface

I Template Generation Seed / world-gen time Schema parameters, class affinity, modifier covariance

II Instance Rolling Runtime / drop time Rarity tier, Beta distribution shape, support bounds

3.2 Item Templates

An Item Template is a parameterised schema from which item instances are rolled. Templates are not hand-authored exhaustively --- they are generated from a schema, meaning design intent is expressed at the schema level and propagates multiplicatively to all generated templates. Schema bugs propagate multiplicatively.

Template fields: ItemTemplate := { TemplateId, ClassAffinity, ModifierSlots, GrantedSkills, RarityFloor, CovarMatrix }

ClassAffinity: Optional. Locks the template to a set of classes, or marks it as universal. Class-locked templates may have complementary modifiers specific to that class’s mechanics.
ModifierSlots: Ordered list of (ModifierType, LayerDeclaration, SupportRange) tuples. The SupportRange is tier-relative --- final min/max are computed at roll time by intersecting with the rarity tier’s global support bounds.
GrantedSkills: List of Skill definitions intrinsic to the item. These are semantically identical to class skills at the engine level. Their ChargeCost and Cooldown are tracked on the caster’s ledger upon equip.
RarityFloor: Minimum rarity tier at which this template can appear. Uber Legendary templates cannot drop as Common instances.
CovarMatrix: Positive semi-definite covariance matrix over the template’s ModifierSlots. Governs intra-item modifier correlation. Must be validated at template generation time.

3.3 Item-Granted Skills as a Binding Layer

Items that grant Skills introduce a third acquisition pathway that is semantically unified with class skills. This layer is architecturally significant for two reasons:

Cross-class access. A universal item grants its Skills to any class that equips it, bypassing class-skill-tree gating entirely.
Non-obvious interaction surface. Item-granted Skills can form trigger graph edges with class skills and other item-granted skills. The combo space is the Cartesian product of all three acquisition pathways, not their union.

The first class of Verified Outliers typically emerges from item-granted skill chains, because the interactions were not designed per-class and therefore fall outside the intended balance envelope.

3.4 Modifier Interaction Model

Modifiers are aggregated in two sequential layers. Cross-layer ordering is mandatory and constitutes an algebraic law (see §6):

Layer Operation Identity Commutativity

Additive Σ modifiers 0 Yes --- within layer

Multiplicative ∏ modifiers 1 Yes --- within layer

Cross-layer Additive first, then Multiplicative N/A No --- order is mandatory

A modifier without a declared layer is a static verification error. The system cannot correctly aggregate undeclared modifiers, and the cross-layer ordering law cannot be enforced.

4. The Charge Resource System

4.1 Charge as Universal Resource Primitive

All class-specific resource concepts --- mana, stamina, energy, focus --- are collapsed into a single abstraction: Charge. This unification means the engine maintains exactly one resource accounting system. Class fantasy is expressed through how Charge is spent and recovered, not through distinct resource types.

4.2 Replenishment Model

Charge replenishes over real time. The baseline model is:

Base rate: 1 Charge per 24 hours.
Scaling: Rate increases by 1 per configurable interval (default 24h). This establishes Charge scarcity as the primary idle game pacing mechanism.
Skill-granted recovery: Skills may grant Charge as an Effect (expressed as negative ChargeCost or as an explicit ModifyCharge effect). Skills with on-kill or on-condition Charge grants are first-class outlier candidates.

All replenishment parameters are configurable levers, not fixed constants. The baseline values establish a design intent; the verification system operates against parameterised inputs rather than hardcoded values.

4.3 Charge Deficit State

Insufficient Charge does not hard-gate skill execution. Instead, it transitions the character to a Charge-Deficit state with elevated death probability. This is a soft risk gradient, not a hard lockout.

State Sustainability Ratio η Death Probability Effective Loadout

Charge-Sufficient η ≥ 1.0 Baseline Full trigger graph active

Charge-Degrading 0.5 ≤ η < 1.0 Elevated Partial trigger graph; some chains suppressed

Charge-Critical η < 0.5 High --- unfair death likely Degraded subgraph; combo chains may break entirely

Sustainability ratio: η = recovery_rate(L, level) / consumption_rate(L)

Charge-Deficit is observable state, not a computation error. The simulation models it as a valid state transition with different downstream behaviour. The fragility of a Charge-Deficit character is a function of their combo graph topology --- if the suppressed skill is load-bearing in a three-link chain, the entire downstream chain breaks, not just one skill.

4.4 Charge as an Outlier Surface

Any Skill that modifies Charge recovery or reduces Charge cost is a first-class outlier candidate, because Charge is the universal constraint across all classes and loadouts. Specifically:

On-kill Charge grants in a build capable of reliable kills approach functional infinite Charge.
Charge-cost-reduction stacking across multiple items and skills can reduce effective cost below 1 per cycle, enabling unsustainable-cost loadouts to become sustainable.
Gain-cycle + Charge sustainability combined in a single loadout is the definition of a Verified Outlier: supercritical power output with self-sustaining resource cost.

5. Rarity Distribution Model

5.1 Rarity as a Probability Measure

Rarity tiers are not intrinsic properties of items. They are partition boundaries on a continuous underlying probability measure over the space of possible item instances. An item does not become Legendary at a threshold --- its rolled modifier values fall within the region of outcome space designated as Legendary. The boundaries are design levers, not ontological facts.

5.2 The Beta Distribution

Modifier values are drawn from a Beta distribution parameterised per rarity tier. The Beta distribution is defined on [0, 1] and governed by shape parameters α and β. A sample x is mapped to a modifier value by:

+-----------------------------------------------------------------------------------------------------------------------------------------+ | Modifier Roll Formula | | | | modifier_value = min_tier + x × (max_tier - min_tier) Where x ~ Beta(α, β) and [min_tier, max_tier] is the tier’s support interval. | +-----------------------------------------------------------------------------------------------------------------------------------------+

The Beta distribution is selected over uniform distribution because it encodes design intent through shape: left-skewed distributions bias rolls toward minimum, right-skewed toward maximum, and high-α high-β distributions concentrate rolls near maximum with low variance. A uniform distribution produces flat power curves incompatible with meaningful outlier rarity.

5.3 Tier Parameters

Tier α (shape) β (shape) Support [min, max] Skew character

Common 1.0 3.0 [base, base×1.5] Left --- most rolls near minimum

Unique 1.5 2.5 [base, base×2] Slight left --- modest upside

Rare 2.0 2.0 [base, base×3] Symmetric --- wide variance

Legendary 3.0 1.5 [base, base×5] Right --- most rolls near maximum

Uber Legendary — — Deterministic Fixed values per template

All α, β, and support parameters are configurable design levers. The values above represent initial design intent. The verification system operates against the parameterised inputs.

Support bound nesting. Tiers Common through Legendary share the same floor (base) and differ only in ceiling, satisfying the Support Nesting Law (§5.4). Tier differentiation within this group is carried primarily by the Beta shape parameters (α, β), not by the support floor. A Common item can theoretically roll anywhere in [base, base×5], but its Beta(1.0, 3.0) distribution concentrates mass near base, making extreme high rolls vanishingly rare.

Uber Legendary is exempt from Beta rolling. Uber Legendary items are deterministic: every instance rolled from the same template has identical modifier values. The value for each modifier is computed as the Legendary tier maximum (base×5) plus a template-specific flat addition. Because Uber Legendary is not drawn from a probability distribution, it does not participate in the Support Nesting Law as a continuous tier. Instead, it is a categorical class that sits above the continuous tier hierarchy.

5.4 Support Nesting Law

The rarity tiers must satisfy a monotone nesting property over their support intervals:

+---------------------------------------------------------------------------------------------------------------------------+ | Support Nesting Law | | | | [min_T1, max_T1] ⊂ [min_T2, max_T2] for all T1 < T2 And: E[modifier | T1] < E[modifier | T2] for all T1 < T2 | +---------------------------------------------------------------------------------------------------------------------------+

A perfect Common roll can approach but never reach an average Rare roll. However, a Common item with multiple modifiers each rolling at their ceiling may exceed an average single-modifier Rare item in total modifier budget. This is the first designed emergent behaviour: modifier count interacts with tier ceiling non-obviously, and this interaction is itself discoverable by players.

5.5 Multi-Modifier Correlation

A single item with n modifiers is a draw from an n-dimensional random vector. The covariance structure of this vector is declared in the item’s CovarMatrix field:

Independent modifiers: Each modifier rolls without knowledge of others. Simple and tractable but permits thematically incoherent combinations.
Correlated modifiers: Positive covariance within thematic groups, negative covariance between competing groups. The CovarMatrix must be positive semi-definite; this is a static verification requirement.

Cross-item correlation --- where two items from different templates jointly produce exceptional values --- is not controlled by per-template covariance. It is a property of the joint distribution over the loadout, and is the primary mechanism by which multi-item outlier builds require specific combinations of equipment.

5.6 The Phase Transition Model

Below a modifier value threshold θ, a combo chain scales linearly with investment. Above θ, the chain enters a supercritical regime where gain cycle output exceeds input cost and scaling becomes superlinear. Outlier detection is therefore a phase transition problem, not a magnitude comparison:

6. Algebraic Laws

The following laws constitute the executable specification of the system. Each law is expressed as a property amenable to property-based testing. Violation of any law indicates a defect in the implementation, not a design revision. The laws are ordered from cheapest (static, no simulation) to most expensive (stochastic).

6.1 Skill Composition Associativity [Static]

Skills are functions over game state. Sequential composition of Skills is associative:

+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Law 1 | | | | fold(apply, s₀, [A, B, C]) ≡ fold(apply, fold(apply, s₀, [A, B]), [C]) Chain evaluation is correct regardless of grouping. Enables incremental evaluation and checkpointing. | +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

6.2 Modifier Layer Ordering [Static]

Additive and Multiplicative modifiers do not commute across layers. Evaluation order is mandatory:

6.3 Charge Floor Invariant [Static]

Charge is bounded below zero. Consumption below zero must produce 0 and emit a ChargeDeficitEmitted event:

+-------------------------------------------------------------------------------------------------------------------------------------------------+ | Law 3 | | | | consume(cost, pool) ≥ ChargePool(0) for all cost, pool Charge-Deficit is observable state (event emitted), not a silent error or invalid state. | +-------------------------------------------------------------------------------------------------------------------------------------------------+

6.4 Trigger Graph Functor Laws [Compositional]

The trigger graph is a functor from game events to state mutations. Two laws must hold:

+-----------------------------------------------------------------------+ | Law 4a --- Identity | | | | TriggerGraph(∅-event) ≡ id (no state change for unmatched events) | +-----------------------------------------------------------------------+

6.5 Cooldown Semiring Distributivity [Compositional]

Cooldown reduction sources form a semiring under min/max. Reduction stacking must be distributive:

6.6 Verification Monotone Classification [Stochastic]

+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Law 6 | | | | class(L) = VerifiedOutlier ⟹ class(L ∪ {S}) ≥ VerifiedOutlier for any additional Skill S Adding Skills cannot reduce outlier classification. A build that is an outlier remains an outlier with additional capabilities. | +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

6.7 Outlier Sparsity Bound [Stochastic]

6.8 Gain Cycle Monotonicity [Stochastic]

+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Law 8 | | | | gain(C, v) is monotone increasing in each component of v A higher modifier roll cannot reduce cycle gain. Violations indicate a modifier with inverted sign semantics in the gain function. | +---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

7. Simulation Verification Architecture

The verification system is an executable specification of the design document’s promises. It does not balance the game. It does not prevent outliers. It audits the system against the algebraic laws of §6 and classifies loadouts according to their outlier potential.

7.1 Three-Layer Pipeline

Verification decomposes into three layers with distinct evaluation times and falsification targets. A loadout that fails Layer I cannot proceed to Layer II; a failure in Layer II renders Layer III meaningless.

Layer Name Evaluation Time Primary Question

I Static Structural Template generation time Does this template satisfy the algebraic laws of the primitive it instantiates?

II Compositional Loadout assembly time Does this combination produce a well-formed trigger graph, and does it contain gain cycles?

III Stochastic Design time / seed validation At what probability does this loadout cross the supercriticality threshold?

7.2 Layer I --- Static Structural Verification

All checks in this layer are decidable at template parse time. They are treated as compilation errors.

Trigger Completeness: Every declared Trigger token must exist in the global event vocabulary.
Effect Emission Closure: Every EmitTrigger effect must emit a token that exists in the event vocabulary. An emitted event with no possible receiver is a warning, not an error.
Charge Cost Non-Negativity: ChargeCost ≥ 0 unless the skill is explicitly declared Charge-granting (negative cost with explicit sign semantics).
Cooldown Positivity: Cooldown > 0 for all active Skills. Zero cooldown is not a passive --- it requires explicit passive declaration.
Modifier Layer Declaration: Every Modifier must declare Additive or Multiplicative. Undeclared layer is a static error.
CovarMatrix Validity: The item template’s covariance matrix must be positive semi-definite.
StackBehavior Declaration: Every Skill must declare Exclusive, Additive, or Multiplicative stacking behaviour.

7.3 Layer II --- Compositional Verification

Loadout Trigger Graph G(L) is constructed as a directed multigraph. Nodes are Skill instances plus a synthetic ∅-source node representing the environment. Edges are directed from Skill Sᵢ to Sⱼ if any Effect emission of Sᵢ matches any Trigger of Sⱼ. Edge labels carry the Condition predicate.

Structural checks on G(L):

Reachability from Source: Every node must be reachable from ∅-source. Unreachable skills generate coverage warnings.
Condition Satisfiability: Every edge’s Condition predicate must be satisfiable given the producible state registry of the current loadout.

Gain Cycle Detection is performed via depth-first search on G(L). For each detected cycle C:

Charge Sustainability Sub-check: The sustainability ratio η = recovery_rate / consumption_rate is computed for the loadout. Any loadout with a gain cycle and η ≥ 1 (through Charge-granting effects in the cycle) is classified as a Verified Outlier Candidate and flagged for Layer III confirmation.

7.4 Layer III --- Stochastic Simulation Verification

Layer III estimates the probability that a randomly rolled instance of a loadout achieves supercriticality. It uses Monte Carlo sampling with importance sampling for rare event estimation.

For each simulation run:

Sample a rarity tier vector r from the drop probability distribution P(tier)ⁿ
Sample a modifier value vector v by drawing from Beta(α, β) per tier, mapped to support intervals
Evaluate gain cycle supercriticality for instance (L, v) by substituting rolled values into gain/cost expressions
Record binary outcome (supercritical / not) and continuous supercriticality margin gain(C, v) − cost(C, v)

After N samples, the verifier produces a typed LoadoutReport:

+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | LoadoutReport Schema | | | | LoadoutReport { loadout_id : StableKey outlier_class : None | Candidate | VerifiedOutlier | UberOutlier outlier_probability : Float ∈ [0,1] expected_margin : Float — gain(C) - cost(C) at expected outlier rolls deficit_death_prob : Float ∈ [0,1] dominant_cycle : CycleDescription sparsity_compliant : Bool — P̂(outlier) < ε warnings : [VerificationWarning] } | +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Sample complexity: For outlier probability P̂ ≈ 10⁻³ and relative error ε = 0.1 at 95% confidence, N ≈ 40,000 samples. For Uber Legendary probabilities in the range [10⁻⁶, 10⁻⁴], importance sampling is mandatory to achieve tractable sample counts.

7.5 The Verification Pipeline as Event-Sourced State

The verification pipeline is modelled as an event-sourced state machine. Each run produces an event sequence:

+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Verification Event Sequence | | | | TemplateRegistered → LoadoutAssembled → GraphConstructed → CyclesDetected → StochasticSampleCompleted → ReportFinalized The fold law (§6.1) guarantees that replaying this sequence from any checkpoint produces identical results. This enables incremental verification, audit trails, and seed reproducibility --- a player who discovers an outlier build can share a seed that any party can independently verify. | +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

8. Configurable Design Levers

The following parameters are explicit design levers. They are surfaced here as the primary tuning interface --- the quantities designers adjust to modify feel without altering the underlying generative architecture. The architecture is fixed; these parameters are the craft.

Parameter Default Effect

ChargePool intercept 1 Minimum Charge at level 1. Raising increases early-game resilience.

Base replenishment rate 1 / 24h Primary idle pacing lever. Increasing compresses the scarcity cycle.

Replenishment scaling interval 24h Hours between +1 rate increase. Decreasing accelerates late-game Charge availability.

Beta α, β per tier See §5.3 Shape of modifier roll distribution per tier. Controls skew and variance.

Support bounds [min, max] per tier See §5.3 Hard ceiling and floor on achievable modifier values per tier.

Drop probability P(tier) TBD Governs encounter rate per rarity tier. Independent of modifier quality.

Supercriticality threshold θ TBD The gain/cost ratio above which a cycle is classified supercritical.

Outlier sparsity bound ε TBD Maximum acceptable proportion of randomly assembled outlier loadouts.

Deficit death probability curve TBD Maps η values to death probability. Controls lethality of Charge-Deficit state.

Parameters marked TBD require empirical calibration via the Layer III stochastic simulation before initial release. The verification system generates the data necessary to set these values with confidence interval guarantees.

8.1 Lever Interaction Warnings

Certain parameter combinations produce non-intuitive interactions that designers should be aware of:

Replenishment rate × Charge-granting skills: High replenishment rate combined with on-kill Charge grants can push η well above 1.0 for aggressive loadouts, effectively eliminating Charge as a constraint.
Beta shape × support bounds: Increasing α for Uber Legendary while widening the support simultaneously compresses variance and increases ceiling --- the dominant effect on outlier frequency is the ceiling increase, not the shape change.
Sparsity bound ε × drop probability P(tier): A generous drop probability for Legendary and Uber Legendary tiers combined with a loose sparsity bound will produce a game where outlier builds are common rather than rare, fundamentally changing the feel of the discovery loop.

9. Open Design Questions

The following questions are unresolved at the time of this draft. They are not architectural gaps --- the system can accommodate any reasonable answer --- but they require explicit design decisions before the first implementation milestone.

Seed architecture. Is the generation seed per-character, per-session, or per-world? Per-character seeds enable reproducible “build discovery” --- a player can share a character seed to reproduce a found outlier. Per-world seeds mean all players on the same world share the same item pool.
Stacking identity for cross-source skills. If a character acquires Blink from both a class skill and an item, does the engine see two Blink instances (two graph nodes) or one (deduplicated)? The choice affects whether Additive stacking of the same skill from multiple sources is possible.
Positional simulation depth. Tags such as Movement are semantically meaningful for the trigger graph (Spatial condition temporality requires positional state), but the idle simulation may not model position explicitly. If position is abstracted away, Spatial conditions must be replaced by probabilistic approximations.
~~Uber Legendary template category.~~ RESOLVED. Uber Legendary is classified as a continuous rarity tier within the same rolling schema, not a categorical template class. See §9.1 for the full trade-off analysis.
Outlier presentation layer. When the verification system classifies a loadout as VerifiedOutlier or UberOutlier, what does the player see? The dominant_cycle field in the LoadoutReport enables human-readable descriptions of why a build is powerful --- but the presentation design is out of scope for this document.
Cross-session cooldown persistence. Cooldowns are tracked on the caster’s persistent ledger. Does this ledger persist across sessions (real-time cooldowns continue while the player is offline), or does it pause? Real-time persistence integrates naturally with the real-time Charge replenishment model but requires a server-side or reliable local clock.

9.1 Uber Legendary Classification Decision

Resolved 2026-06-05. This section records the decision and trade-off analysis for Open Design Question 14.

Decision. Uber Legendary is a categorical template class, not a continuous rarity tier. It does not use the Beta(α, β) rolling mechanism. Instead, every Uber Legendary instance generated from the same template has identical modifier values: the Legendary tier maximum (base×5) plus template-specific flat additions. This makes Uber Legendary a deterministic, designer-curated pinnacle tier that sits above the continuous probability hierarchy.

Trade-off analysis.

Criterion	Categorical Class (chosen)	Continuous Tier (rejected)
Schema complexity	Requires a deterministic generation path alongside the stochastic roller	Single `InstanceRoller` path; no branching logic
Implementation cost	Requires `TierConfig` to support deterministic mode and flat-addition fields	Reuses existing `Beta(α, β)` infrastructure
Outlier guarantee	Guaranteed: every Uber item from a template exceeds Legendary max by a fixed margin	Probabilistic: `Beta(5.0, 1.2)` concentrates mass near ceiling but never guarantees max roll
Player discoverability	Identical Ubers from the same template are reproducible and shareable	Every Uber roll is unique; no deterministic “god roll” to chase
Thematic coherence	Explicit pinnacle tier with fixed, exceptional values	Blurs the line between “very lucky Legendary” and “true Uber”

Rationale. The design intent for Uber Legendary is not statistical extremity within a distribution; it is a guaranteed apex state. A continuous tier would mean some Uber rolls are only marginally better than Legendary, which undermines the tier’s purpose as a clear pinnacle. Deterministic values also create a reproducible chase: players can target a specific template knowing exactly what the Uber version provides. This aligns with the Intentional Outliers axiom (§1.1) by making the outlier state explicit and achievable rather than merely probable.

Consequences.

HCWS-blo.7 (separate distribution shape from support bounds) must add a deterministic generation mode to TierConfig for the Uber Legendary classification.
ItemTemplate may need a uber_additions field declaring the flat additions applied when the template is instantiated as Uber Legendary.
The Support Nesting Law (§5.4) applies only to the continuous tiers (Common through Legendary). Uber Legendary is exempt because it is not drawn from a probability distribution.
Sparsity control for Uber Legendary is governed entirely by drop probability P(Uber), not by distribution shape (see §8.1).

10. Glossary

Acquisition Pathway The means by which a Skill is granted to a character: class skill tree, item equip, or item-intrinsic grant. Not a property of the Skill itself.

Beta Distribution A probability distribution defined on [0,1] governed by shape parameters α and β. Used to generate modifier rolls per rarity tier.

Charge The universal resource primitive. Represents mana, stamina, or any class-specific resource. ChargePool(level) = 1 + level.

Charge-Deficit The state in which a character’s Charge consumption rate exceeds recovery rate. Characterised by elevated death probability and partial trigger graph suppression.

CovarMatrix The positive semi-definite covariance matrix declared in an Item Template, governing intra-item modifier correlation.

Gain Cycle A directed cycle in the Loadout Trigger Graph where net modifier output exceeds net cost. The primary mechanism of outlier build generation.

Loadout The complete set of Skill instances active on a character, regardless of acquisition pathway.

Loadout Trigger Graph G(L) A directed multigraph over the Skills in a Loadout. Edges represent trigger-emission relationships.

Modifier Layer The aggregation stratum of a Modifier: Additive (summed first) or Multiplicative (applied second). Cross-layer ordering is mandatory.

Outlier A loadout whose trigger graph contains a supercritical gain cycle at actual rolled modifier values.

Phase Transition The threshold θ above which a gain cycle’s output exceeds its input cost, transitioning from linear to superlinear scaling.

Producible State Registry The set of game state variables that the current Loadout can influence. Used to evaluate Condition satisfiability.

Skill The fundamental system primitive. Defined by { Triggers, Conditions, Effects, Tags, Modifiers, ChargeCost, Cooldown, StackBehavior }. Source-agnostic.

Sparsity Bound ε The maximum acceptable proportion of randomly assembled loadouts classified as outliers.

StackBehavior The declared behaviour when multiple instances of the same Skill are active: Exclusive, Additive, or Multiplicative.

Supercriticality The condition in which gain(C, v) > cost(C, v) for some gain cycle C at rolled modifier values v.

Sustainability Ratio η recovery_rate / consumption_rate. Determines Charge state: Sufficient (η ≥ 1), Degrading (0.5 ≤ η < 1), or Critical (η < 0.5).

Template A parameterised schema from which item or skill instances are generated. Design intent is expressed at the schema level.

Tier A rarity classification (Common, Unique, Rare, Legendary, Uber Legendary) corresponding to a region of the modifier value probability measure space.

Trigger Graph Functor The mapping from game events to state mutations, required to satisfy identity preservation and composition preservation laws.

Verified Outlier A loadout classified by the Layer III stochastic simulation as having supercritical gain cycle probability above the significance threshold.