Establish the hex-canon discipline in style/trait-palette.md (v0.1 -> 0.2):
every trait-color reference pairs canonical-name (semantic anchor for prose,
training-corpus extraction, LLM context) with hex (precise value for shaders,
renderers, machine-checkable canon enforcement). Mirrors the existing
color+motion-signature two-channel discipline that already secures color-blind
accessibility -- same architectural move, different audience pair.
Trait-palette.md gains:
- "Canonical name" + "Hex" columns in The full table (Eros-red #ee1b24,
Philotes-orange #e28a46, ..., Mnemosyne-dusky-rose #cf3b74)
- New section: The hex-canon discipline -- format conventions, scope, the
one-line grep that surfaces canon-violations
Sweep applies the discipline to existing trait-color references:
- identity-and-personhood/architecture.md (trait-to-body-part bridge table)
- topology-and-rendering/architecture.md (faction-color-politics table,
imperial-net distortion descriptors, achromatic-exception statement,
mind-pool color-inheritance narrative)
- runtime-engine/architecture.md (cosmetic-shader prose feedback)
- identity-and-personhood/bodies.md (Moira-violet pill in pending-design notes)
- political-register/economics.md (catalogue-slug example uses canonical token)
Drift-fix: schemas/findings.md trait_colors seed-data carried 8 divergent hex
"approximations" -- Eros #D03030 vs canonical #ee1b24, Aletheia #E5C520 vs
canonical #fcf001 (losing the brightness-zenith register), Dikaiosyne #2860B0
vs canonical #3f47cd, etc. Replaced with exact propagation from the canonical
palette; the rationalizing comment ("approximate hue-family targets") is
replaced with "exact propagation per the hex-canon discipline"; HSV-hue column
recomputed from canonical hex per RGB->HSV conversion, integer-rounded.
Non-trait colors stay untouched per recursive-as-we-touch-it scope: machine-
aesthetic (gold rim-light, commercial-coral, fluorescent-pallor, lavender-
decor, obsidian-black, cyan, matrix-green), historical-sumptuary (Tyrian
purple), cinematic (Matrix red-pill), medical (red-green color blindness).
Each non-trait domain receives canonical-name + hex pairings when that domain
comes into architectural focus.
Discipline is mechanically-checkable via one grep against the architecture-
papers, excluding the canonical source. Zero canon-violations remain after
this sweep.
28 KiB
Nimmerworld — Economics: Catalogue-Stack and Daily-Ledger Pacing
The typed-abstraction layer over the political-register's economic content. Specifies the catalogue-stack (resources × production-chains × tasks → imperial-demand-catalogue) as the operational vocabulary the simulation reads; the daily-ledger pacing as the temporal-grammar of imperial-demand; the demand-ledger / actions-ledger split formalizing the specter-vs-boot asymmetry; the catch-up window vs fail-state escalation grammar.
Companion to:
./architecture.md(the substantive canon — §Resources, §Lifeforce, §Imperial budget, §Vocation-substrate, §4-tier resource/vocation structure, §Bifurcated economy, §Imperial-extraction mechanisms — that this paper provides the typed-interface over),./world-generation.md(the L0-L4 cascade that instantiates the catalogue-stack at world-gen time),../identity-and-personhood/vocations.md(the vocation-system that operates at the task-layer of the catalogue-stack and consumes its outputs).v0.1 initial draft 2026-04-27 — dafit + chrysalis. Authored same-session as vocations.md and consent-discipline.md, completing the night's foundational paper-pair-pair. Codifies the catalogue-stack mechanic that has been implicit across
architecture.mdand that vocations.md depends on.
What this is
This document specifies the catalogue-stack — the typed-abstraction layer the simulation reads when allocating imperial demand into district-actionable shift-composition — and the daily-ledger pacing — the temporal-grammar that determines when imperial demand is formulated, when it travels, and when it gets reconciled.
The political-register's ./architecture.md is the substantive canon of nimmerworld's political-economy: it specifies what resources exist, what the lifeforce-currency is, how the imperial budget operates, what the 4-tier resource/vocation structure looks like, and through which 9 pipes the imperium extracts. This paper is the typed-interface over that canon — the operational vocabulary the simulation code reads to translate political-economy claims into concrete data-flow.
The catalogue-stack is also the data-source for the ../identity-and-personhood/vocations.md vocation-system. Vocations operate at the task-layer of the catalogue-stack and consume its outputs. Without the catalogue-stack, the vocation-system has no data to bind to; without the vocation-system, the catalogue-stack has no executor at the NPC layer. The two papers compose: catalogue-stack is the what; vocations.md is the who-and-how.
Spine claim — the catalogue-stack as typed vocabulary for imperial demand
The simulation's economic-flow has three substrate layers. Each is designer-authored at the type-level and instantiated by world-gen at the room-level:
Layer 1: Resource catalogue (the world's resource taxonomy)
Layer 2: Production chains (how resources transform into other resources)
Layer 3: Task catalogue (the vocational primitives — see vocations.md §The three primitives)
↓ composed
Imperial-demand-catalogue (what the imperium wants, expressed in resource/task vocabulary)
The imperial-demand-catalogue is the imperium's wish-list operationalized in the system's own vocabulary. The Hivemind's daily demand-formulation reads from this catalogue: "this district produces X tongues per day at Y refinement-tier; today demand a 20% increase by routing more sex-worker-output through the consumer-receptor-vertical." Demand is concrete because the catalogue makes it concrete; without the typed-vocabulary, demand would be unmoored political-rhetoric.
Why a typed-vocabulary matters here: the architecture's existing commitment to catalogue + tools as typed contract (per ../architecture-index.md Key moves: "Catalogue + tools as typed contract. GM dispatches typed events with typed tool-grants; director consumes typed dispatch, not freeform prose") generalizes from the GM-event layer to the imperial-demand layer. The imperium speaks to the GM in resource/task vocabulary, not in narrative; the GM allocates to districts in the same vocabulary; the director composes shifts in the same vocabulary; NPCs execute tasks in the same vocabulary; outcomes flow back up in the same vocabulary. One typed vocabulary, end-to-end through the political-economy stack.
Layer 1 — Resource catalogue
The world's resource taxonomy. Designer-authored at the type-level; instances generated by world-gen + accumulated through gameplay.
The existing ./architecture.md §Resources table provides the canonical category-list (Labor / Material / Spatial / Temporal / Cognitive / Diegetic-currencies / Social / Attention). The catalogue-stack treats each row of that table as a typed resource-class, with concrete sub-classes within:
| Category | Sub-class examples | What rows look like in the catalogue |
|---|---|---|
| Material — physical | Raw scavenge (T1) / Refined intermediates (T2) / Components (T3) / End-products (T4) per the 4-tier structure | material/T2/refined-neural-substrate, material/T4/companion-mesh-premium-tier-3 |
| Material — biological | Service-body parts (companion / sex-worker tier-marked) / Synth-tongues (drug-tier-marked) / Cadaver-parts (slum-supply for re-vat) / Memory-pattern-extractions | bio/service-body/companion-pristine, bio/synth-tongue/imperial-refined-moira-violet-pill-tier, bio/cadaver-parts/slum-leg-tier-2 |
| Digital | Surveillance records / Calibration signatures / Trait-LoRA-snapshots / Doctrinal fragments | digital/surveillance/district-N-cycle-K, digital/calibration-signature/UID-X |
| Temporal | NPC labor-hours per window-allocation × caste / Director attention-cycles / Imperial inquisition-hours | temporal/labor/slum-tiryak-leisure-hour, temporal/director-attention/cycle-K-allocation |
| Diegetic currency | Lifeforce / Scrip / Memory-tokens / Dreamtime | (already canonical per architecture.md §Lifeforce) |
| Social | Trait-trust-edges / Faction-membership / Calibration-multiplier accumulations / Witnessing-rights | social/calibration-multiplier/UID-A→UID-B, social/witnessing-rights/rogue-X→NPC-set |
| Attention | Player-attention / NPC-attention / Imperial-attention | (the scarcest — feeds the cost-budget asymmetries) |
The biological resource-class is canonically distinct. Service-body parts, synth-tongues, cadaver-parts, and memory-pattern-extractions are all bodies-as-resources — the imperium's commodification of personhood made into the catalogue. The Memorialist counter-archive's protest (per ./architecture.md §Memorialist counter-archive) is structurally a counter-catalogue maintaining personhood-records against the imperium's body-as-resource catalogue. Two parallel catalogues; the political-conflict is between them.
The biological resource-class also intersects critically with the gender-parity discipline (per ../style/gender-parity.md): catalogue-entries for service-body parts MUST follow the gender-parity-by-default discipline. Service-body parts of any kind are gender-neutral catalogue-entries; gender-asymmetric authoring of these entries is forbidden default-leakage. The catalogue is itself a canon-authoring surface and inherits the spine.
Layer 2 — Production chains
How resources transform into other resources via tasks. Each production-chain is a designer-authored recipe binding inputs, tools, time-cost, and a quality-curve.
A production-chain has the following typed shape:
| Field | What it specifies |
|---|---|
| Inputs | Resource-classes consumed, with quantity ranges and quality-tier requirements |
| Tool-binding | Workstation-classes the chain can be performed at (workshops / labs / cantinas / surgical-stations / etc.) |
| Task-class | The vocational-task the chain instantiates (per the task-catalogue layer below) |
| Trait-affinity profile | Inherited from the task-class; determines which trait-pools deplete during execution |
| Time-cost | Duration in NPC-hours; how much of the work-window the chain consumes |
| Quality-curve | Mapping from outcome-formula result (trait-engagement × task-stat) to output-quality tier |
| Output | Resource-class produced, with quantity range and quality-tier (driven by quality-curve from the actual outcome) |
Production chains can cascade. A single end-product may require a chain of chains: T1-raw is gathered, T1-raw becomes T2-intermediate via refinement-chain, T2 becomes T3-component via component-chain, T3 becomes T4-end-product via assembly-chain. The 4-tier structure (per ./architecture.md §The 4-tier resource/vocation structure) is the cascade backbone; production-chains are the edges connecting the tiers.
Concrete worked examples (sketched against existing canon):
| Production chain (named) | Inputs | Tool-binding | Task-class | Output |
|---|---|---|---|---|
| Drug refinement (slum → imperial) | T2 refined-substrate + T1 botanical-raw | imperial-refinery workstation | drug-refinement (Kairos + Aletheia affinity) | T3 imperial-refined-drug |
| Drug composition (imperial → tongue-gated) | T3 imperial-refined-drug + T3 trait-LoRA-fragment | imperial-composing-workshop | drug-composition (Kairos + Aletheia affinity, deeper) | T4 trait-pill (color-coded per trait-pill-grammar) |
| Synth-tongue installation | T4 synth-tongue + bio/donor-body-prep + tool-set | underground surgery workstation | tongue-installation (Kairos + Aletheia affinity) | bio/recipient-with-synth-tongue (chassis-modification) |
| Service-body assembly | T3 components × multiple + T2 mesh-base | imperial mesh-assembly workshop | mesh-design (Philotes / Eros / Aletheia affinity per service-class) | T4 service-body (companion-tier or sex-worker-tier per task-spec) |
| Re-vat assembly (defected beloved) | bio/cadaver-parts × multiple + tool-set | underground assembler-artisan workstation | re-vat-assembly (Mnemosyne + Kairos + Aletheia affinity) | new genderless slum chassis (per ../identity-and-personhood/bodies.md §Re-vat as imperial-de-imposition) |
| Memory-pattern extraction (necrocommerce) | bio/recently-dead-body + neural-tools | imperial harvest-station | memory-pattern-extraction (Mnemosyne + Aletheia affinity, dark) | digital/calibration-signature + bio/extracted-trait-pattern (the most reviled vocation per architecture.md §The vocation-substrate) |
The catalogue is growable between patches (per the existing tools-not-quests / catalogue-extensible commitment); new production-chains added at content-canon time slot in via designer-authored typed-records.
Quality-curve discipline ties production-chains to the vocation-system's outcome formula. Per vocations.md §The outcome formula, an NPC's task-execution produces outcome = trait-engagement-points × hidden-task-stat. The production-chain's quality-curve maps that outcome-value into output-quality-tier:
outcome (multiplicative product) → quality-tier (e.g., poor / mediocre / good / excellent / exceptional)
The mapping function is designer-authored per chain — some chains have steep curves (skill matters enormously; mediocre input yields nothing usable) and others have gentle curves (everyone produces something usable; only the top-tier produces exceptional output). The curve-shape encodes the chain's economic-elasticity and the imperium's leverage on quality-supply.
Layer 3 — Task catalogue
The vocational-task layer. Specified canonically in ../identity-and-personhood/vocations.md §The three primitives. This paper does not re-specify it; instead it cross-references and notes the integration-points:
- Each production-chain binds to one task-class (the vocational-task it instantiates)
- Each task-class has a trait-affinity profile that determines the depletion-pool dynamics during chain-execution
- Each task-class has a hidden per-task measurement that accumulates as NPCs execute chains
- The director's shift-arbitration runs at the task-class layer; the production-chain is what gets executed once arbitration assigns the task
The catalogue-stack's three layers compose: Resource-catalogue defines what exists; Production-chains define how things transform; Task-catalogue defines who-can-execute-the-transformation-and-how. The catalogue is the world's economic ontology in three vertically-composed layers.
The imperial-demand-catalogue — composition of the three layers
The imperial-demand-catalogue is the composition. It expresses what the imperium wants in the same typed vocabulary the simulation operates on. Each row in the imperial-demand-catalogue specifies:
| Field | What it specifies |
|---|---|
| Target resource-class + quantity + quality-tier | The end-state the imperium wants achieved (e.g., "30 companion-mesh-premium-tier-3 produced this cycle") |
| Allocation-priority weight | The faction-priority-weight from existing canon's imperium-policy-driven scoring; determines this row's ranking against other rows in the daily ledger |
| Production-chain reference(s) | Which production-chain(s) can satisfy this demand (allows chain-substitution flexibility) |
| District-binding | Which district(s) are expected to satisfy this demand (driven by world-gen-time vocation-distribution + current district-state) |
| Cycle-deadline | When the demand is checked; usually next ledger-cycle |
| Catch-up policy | What happens if the demand is unmet at deadline (gradual escalation per §Catch-up window vs fail-state below) |
The imperial-demand-catalogue is regenerated each ledger-cycle based on yesterday's outcomes + today's needs + faction-priority-weight rebalancing. It's the imperium's standing-order updated daily.
End-to-end data flow
The full pipeline, citing the existing canonical mechanisms and the new typed-vocabulary:
Yesterday's district-reports flow up via three-tier-policy-loop's report-channel
↓
Compositor (overnight, Compositor-tier LLM) processes reports into Memorialist-ledger
↓
Hivemind regenerates imperial-demand-catalogue based on:
- yesterday's outcomes (what was produced; quality-tiers; insolvency-spiral state)
- faction-priority-weight rebalancing (per existing canon)
- imperial-event-state (drone-patrols completed, inquisitions in-progress, etc.)
↓
Compositor wraps the regenerated demand-catalogue in narrative voice (the imperial daily-narrative; per `./imperial-narrative.md` *forthcoming*)
↓
Daily-ledger ships down to GM at start-of-cycle:
- DEMANDS LEDGER (what to produce)
- ACTIONS LEDGER (what imperial events to fire)
- NARRATIVE wrapper (yesterday's framing as today's motivation)
↓
GM allocates demand-rows + action-rows → districts with matching resources/workstations/event-targets
↓
Director receives district-allocated demand-rows + action-rows + narrative-fragment
↓
Director maps demand-rows → district meta-table (workstations × resources × NPCs × current trait-pool-states × task-stats)
↓
Director composes shift-list per the work-window (per vocations.md §The 24h window-partition):
- selects tasks from demand-mapped tasklist
- arbitrates assignments per trait-alignment + pool-availability + task-stat
- constructs per-NPC shift-rows for the work-window
↓
Director dispatches imperial-events (action-ledger) into rail-and-zone encapsulated runtime per `../runtime-engine/architecture.md` *forthcoming-encapsulation*
↓
NPCs fulfill assigned tasks (work-window):
- production-chain executes
- outcome = trait-engagement-points × hidden-task-stat
- quality-curve maps outcome to output-quality-tier
- resources produced; pools drain; task-stats accumulate; lifeforce-signal updates
↓
NPC charging-window (passive trait-pool refresh)
↓
NPC leisure-window (NPC-chosen tasks; emergent-zone participation; clasp-events; vocation-discovery)
↓
End-of-cycle:
Outcomes aggregate → district-report flows up to GM
Imperial-events return final-reports from encapsulated runtime
Ledger reconciliation: produced-vs-demanded; insolvency-spiral state updates
↓ [back to Compositor for tomorrow's narrative]
The data flow is single-typed-vocabulary end-to-end. Imperial-demand-catalogue rows travel down; outcome-rows travel up; the typing is consistent across the loop. No untyped freeform-prose between layers — that's the catalogue's discipline.
Daily-ledger pacing
Imperial demand is not real-time. It travels as a daily ledger checked at periodic intervals — not every cycle, every shift, every minute, but at a cadence that creates breathing-room. This is the critical structural choice that distinguishes nimmerworld's economic-pipeline from real-time-pressure simulation.
Why breathing-room is load-bearing
The breathing-room does load-bearing structural work that wouldn't be available to a real-time system. Five reasons:
- The double-ledger NEEDS this. The existing canon's "Director cheat-tools + double-ledger; corruption emerges from pressure; Memorialists keep true accounting" (per
./architecture.md§Cheat-tool vocabulary + §The double ledger) requires time-between-audits to operate. Real-time imperial pressure leaves no gap for the cheat-substrate. Breathing-room is the structural prerequisite for the corruption-mechanic to exist. - Dramatic time exists. Audit becomes an event — approaching, building, reckoning. Greek-tragedy register at the imperial-economic layer, paralleling the bounty-staircase's dread-time (per
../identity-and-personhood/bodies.md§The bounty-staircase). - NPCs get to be people, not functionaries. Time between assignments lets depletion-pools refresh, lets clasp / friendship / drift / slowness exist. Breathing-room is what makes NPCs livable.
- Imperium-as-slow-elephant. The cosmology's calibrated-misery-as-finite-attention finally has its temporal grammar. The imperium can't be everywhere at once; ledger-cadence IS the imperium's attention-budget made structural.
- Marxism-of-economics extends from epistemics. Information-propagation-pacing was already canonical Marx-in-the-schema applied to epistemics (per
./architecture.md§Marx in the schema). Demand-propagation-pacing is Marxism-of-economics. Same primitive, demand-side.
Demand-ledger ≠ Actions-ledger
The Hivemind sends down two separate daily ledgers processed by the GM independently. This formalizes the existing specter-vs-boot asymmetry (per ./architecture.md §The specter-vs-boot asymmetry) as separate ledger-grammars:
| Ledger | Operates at | What it specifies | Maps to |
|---|---|---|---|
| Demands ledger | The economic layer | Resource/quota expectations; production-chain targets | The full catalogue-stack pipeline above |
| Actions ledger | The force layer | Imperial events to fire today (drone-patrols, inquisitions, overseer-audits, enforcement) | ../runtime-engine/architecture.md imperial-event encapsulation pattern, forthcoming |
Both spread-out over the cycle; both narrative-framed by yesterday's events. The two-ledger split mirrors the existing specter-vs-boot split — policy-issuance (free) vs enforcement (expensive) — now formalized as separate ledger-grammars. The GM's middle-management role gains a second pipeline to negotiate.
Ledger cadence
The default cadence is daily — one ledger per cycle, checked at end-of-cycle. This matches the existing "shifts on NPC rows; daily rewrite" canonical commitment (per ./architecture.md §Labor-cycle architecture).
Cadence may be caste-stratified:
| District type | Cadence | Why |
|---|---|---|
| Imperial-pinnacle districts (deva-heavy; ceremonial; high-priority) | Daily, audit-rich | The imperium watches its showcase closely |
| Slum-tier districts (tiryak-heavy; productive; mid-priority) | Daily, audit-light | Standard cadence; baseline imperial attention |
| Frontier / abandoned districts (low population; low imperial-priority) | Multi-cycle (every 3-7 days) | The imperium can't afford to check often; the breathing-room is largest here |
The ledger cadence itself is a political stratification. Imperial-attention scarcity manifests as cadence-frequency; the most-watched districts are imperial-net high-revenue districts; the least-watched are the slum-frontier where the going-rogue arc has its widest breathing-room.
This composes with the architecture's "Imperium-as-slow-elephant" claim and the calibrated-misery-as-finite-attention mechanic. Less-watched districts have more cheat-substrate; more cheat-substrate enables more corruption; more corruption enables more lifeforce-maintenance; more lifeforce-maintenance enables more authentic NPC life; more authentic NPC life enables the going-rogue arc to take root. The frontier is where the truth-register survives, structurally.
Catch-up window vs fail-state — gradual escalation
When a demand-ledger row comes up short at check-time, the imperial response is gradual escalation (not immediate enforcement). This reuses the bounty-staircase grammar (per ../identity-and-personhood/bodies.md §The bounty-staircase) at the district-economic layer rather than per-perpetrator:
| Cycle of failure | Imperial response | Cost class |
|---|---|---|
| First-cycle shortage | Warning broadcast (relays + billboards in district); district-director receives polite reminder from GM; demand carried-forward to next cycle with priority bump | Cheap (specter) |
| Second-cycle shortage | Resource-restriction (district's incoming material allocations reduced; lifeforce-allocation tightened); audit-overseer dispatched for lightweight investigation | Medium |
| Third-cycle shortage | Imperial-faction dispatch (martial / inquisition depending on which catalogue-row failed); director reprimand (potential replacement); cheat-tool ledger seized for audit | Expensive (boot) |
| Fourth+-cycle shortage | District is in silence (per existing §Migration, exodus, silence canon); imperial-budget treats district as effectively-zero; may trigger forced-conscription or migration-incentive events | Crisis-mode |
The escalation gives the director a catch-up window — first-cycle shortage is forgiven if next-cycle hits target; the warning-rung doesn't ratchet beyond first-rung if recovery happens. This is what makes the corruption-substrate viable: the director can run a deficit cycle (cheating + double-ledger) IF they can recover next cycle through underground channels or migration-pulled labor. Without the catch-up window, every shortage would be terminal; with it, the simulation has elastic recovery space.
Specific escalation-rates per demand-class are designer-tunable (see Open questions). Some demand-classes (high-priority; service-body production for imperial-net) escalate fast; others (low-priority; basic-flow) escalate slowly. The per-class tuning is the imperium's policy as expressed in escalation-rates — high-priority demands get the boot quickly; low-priority demands are spoken-about-but-not-enforced for many cycles.
How this composes with vocations.md
The catalogue-stack and the vocation-system are two halves of the same data model:
- Catalogue-stack specifies the resources / production-chains / imperial-demand-catalogue (the what)
- Vocations.md specifies the task-execution mechanics / depletion-pool dynamics / window-partition / outcome formula (the who-and-how)
The outcome formula (per vocations.md §The outcome formula, outcome = trait-engagement-points × hidden-task-stat) is what feeds the production-chain's quality-curve. Quality-curves take outcome-values and produce output-quality-tiers; output-quality-tiers populate resource-catalogue instances. One unbroken pipeline from trait-vector through task-execution to resource-output.
The director's shift-arbitration (per vocations.md §Director's task-list arbitration surface) reads from the demand-ledger's district-allocated-rows + the production-chain bindings. The director's parental-rotator role (forced-by-math NPC rotation through the trait-wheel for refresh) operates against the imperial-demand pressure — the director is structurally negotiating the gap between what the imperium wants and what the NPCs can sustainably produce given their current depletion-pool states. The corruption-substrate emerges precisely in this gap.
The window-partition (per vocations.md §The 24h window-partition) bounds how much labor each NPC can supply per cycle. The work-window is the imperially-claimable allocation; demand-rows that exceed the work-window-supply trigger fail-state escalation. The window-partition is the cap on imperial extraction at the per-NPC layer; the catalogue-stack is the imperial demand at the world layer; the gap between them is the simulation's primary tension.
Open questions
- Concrete escalation-rates per demand-class. First-cycle / second-cycle / third-cycle response shapes are specified architecturally; the per-demand-class tuning is implementation-time work and design-research. Service-body production (high-priority) likely escalates faster than basic-flow grain production (low-priority); the actual numbers need playtesting.
- Quality-curve shapes per production-chain. Each chain has a quality-curve mapping outcome-value to output-quality-tier; specific curve shapes (steep / gentle / threshold-stepped) are designer-authored at content-canon time and may need balancing-research.
- Resource-catalogue versioning for world-gen vs runtime. When new production-chains are authored between content-patches, the catalogue grows; runtime instances of the old catalogue persist. Migration semantics for catalogue-versioning are deferred to the
world-generation.mdcascade-versioning design (already noted as open in architecture-index.md). - Cross-district demand-routing flexibility. A demand-row binds to district(s) via world-gen-time vocation-distribution. When a district's vocation-supply collapses (per architecture.md §The vocation-substrate / supply elasticity), can the demand-row dynamically route to neighbors? Hunch: yes, with a routing-cost penalty proportional to district-graph-distance; this becomes the "migration events" GM-tool's automatic counterpart.
- Caste-cadence calibration. The caste-stratified cadence (imperial-pinnacle daily-audit-rich vs frontier multi-cycle audit-light) is sketched architecturally; concrete cycle-counts per caste-tier are tuning work.
- Black-market production-chain handling. The blackmarket T4 escape valve (per architecture.md §Imperial-extraction mechanisms) involves production-chains that are off the imperial-demand-catalogue. How are these typed in the catalogue-stack? Hunch: as parallel underground-demand-catalogue rows that the GM can see but doesn't allocate-from; districts running blackmarket chains satisfy underground-catalogue rows that don't appear in imperial-demand-reports. The double-ledger naturally handles this.
- Necrocommerce as catalogue-rows. Memory-pattern-extraction is canonically the most-reviled vocation. Its production-chain rows in the catalogue should carry an ethics-flag for the Memorialist counter-archive's protest-mechanism. Open: should the architecture provide a typed ethics-flag field on catalogue-rows, or is this purely diegetic-narrative?
- Player-driven T4 catalogue authoring. The bifurcated economy (per architecture.md §Bifurcated economy) gives players the unique-T4-supplier role. Do players add their own T4 catalogue-rows through play (a player who invents a new mod-recipe contributes to the catalogue), or is the catalogue strictly designer-authored? Hunch: hybrid — the production-chain templates are designer-authored; players' actual recipes are instances of templates with player-specific quality-curves derived from their task-stats. The catalogue grows by player-recipe-discovery within designer-bounded chain-templates.
Version: 0.1 | Created: 2026-04-27 | Updated: 2026-04-28