State Axes and Thresholds
Status: authoritative design contract for the three named state axes.
Feature discovery axis: authoritative — FeatureDiscoveryState enum is
committed in Generated/Territories/FeaturePlacement/FeaturePlacementTypes.cs
and aligns with gd-feature-generation-contract.md.
The forward-compat int DiscoveryIntensity nuance field on FeatureData
was added in Wave R-3 (2026-05-10); threshold semantics within each
ladder label remain TBD per a future balance pass.
Territory knowledge axis: current — TerritoryKnowledgeState enum is
committed in Generated/Territories/TerritoryKnowledgeTypes.cs and aligns
with the "Knowledge Values" block in
gd-territory-generation-contract.md.
The prototype int Explored field was retired in Wave R-1 (2026-05-10);
TerritoryData.KnowledgeState plus the forward-compat
TerritoryData.KnowledgeIntensity are the runtime state-storage points.
Site state axis: current prototype shape via TerritoryContentState enum
in Generated/Territories/FeaturePlacement/FeatureContentTypes.cs; numeric
intensity field is not yet implemented. Status terms follow
pr-status-and-sync-policy.md.
Purpose
This document defines the three state axes used across the Valenar world model: the Feature discovery axis, the Territory knowledge axis, and the Site state axis. Each axis is a named ladder with labels, optional numeric intensity, and a single owning subsystem. This document is the authoritative reference for which subsystem owns each axis and what the committed labels are.
A state axis answers a "how known / how progressed" question for a particular world entity. The three axes are independent: a Feature can be Surveyed inside a Territory that the player has only Sighted; a Site can be Developed inside a Territory that the player Claimed. Cross-axis rules are described at the end of this doc and are explicitly TBD.
Feature Discovery Axis
Owner: Feature generation system, gd-feature-generation-contract.md.
Committed enum: FeatureDiscoveryState in
Generated/Territories/FeaturePlacement/FeaturePlacementTypes.cs. The
nine committed labels, in ladder order, are:
Hidden— feature exists but the player has no knowledge of it.Hinted— the player has a clue but not the real identity.Discovered— the player knows the Feature category or name.Surveyed— quality, risk, blockers, and main outputs are known.Handled— threat or obstacle has been resolved, but the site may not be developed.Secured— controlled and protected.Developed— owned or used as an ongoing Site/improvement.Depleted— resource exhausted or inactive (terminal for productive Features).Destroyed— the Feature has been removed from the world (terminal for destructive endings).
These labels are the committed runtime vocabulary. They match the
ladder in
gd-feature-generation-contract.md
under "Existence Versus Discovery". Do not introduce alternate labels
in live docs without updating both this page and the enum.
Numeric intensity: the design intent is that each non-terminal
label corresponds to an intensity range on a 0–100 scale, allowing
sub-label partial progress (e.g., Discovered at intensity 30 is
further along than Discovered at intensity 25). The intent ranges
are:
Hidden— intensity 0Hinted— intensity 1–24Discovered— intensity 25–49Surveyed— intensity 50–74Handled— intensity 75–89Secured— intensity 90–95Developed— intensity 96–100
Numeric thresholds (1–24, 25–49, ...) are target thresholds; TBD in balance pass — they are not committed values. Use these ranges as design guidance, not as runtime constants.
Numeric intensity field: int DiscoveryIntensity on FeatureData.
Default 0. Bare integer per the unified convention established by
R-1's KnowledgeIntensity and R-2's StateIntensity. The field is
wired through H.DiscoveryIntensity in Generated/Hashes.cs +
Generated/Declarations.cs and read/written via the Feature branch of
HostBridge (Wave R-3, 2026-05-10). The field tracks intensity on the
DiscoveryState ladder. Numeric thresholds within each ladder label
remain TBD per a future balance wave; until those thresholds are
committed, DiscoveryIntensity is a transparent nuance field that
consumers can display without acting on. Wire projection
(FeatureSnapshot.discoveryIntensity) is deferred to a future Server
wave, mirroring the deferral pattern from R-2 (SiteSnapshot).
Resolved drift (Wave Q): the Interacting state listed in prior versions of
gd-feature-generation-contract.md and gd-territory-generation-contract.md
has been removed from those docs' recommended state ladders. The committed
FeatureDiscoveryState enum in FeaturePlacementTypes.cs remains the
9-state form; it does not carry Interacting. The recommended ladder
now matches.
Depleted and Destroyed are terminal labels and do not participate
in the 0–100 intensity scale.
Territory Knowledge Axis
Owner: Territory system, gd-territory-generation-contract.md.
Committed enum: TerritoryKnowledgeState in
Generated/Territories/TerritoryKnowledgeTypes.cs. The eight committed
labels, in ladder order, are:
Unknown— fog of war; the player has no knowledge of the territory.Sighted— the player has seen the territory at a distance or via a lead, but has not investigated it.Scouted— the player has visited and surveyed the immediate surroundings.Surveyed— quality, risk, blockers, and main outputs are known (note: shares a label with the Feature axis; context disambiguates by axis owner — Territory vs Feature.)Secured— controlled and protected.Claimed— the player owns the territory through settlement designation.Cleansed— taint, threat, or hostile occupation has been resolved.Developed— the territory is built up as part of an owned settlement or outpost.
These labels are committed runtime vocabulary (Wave R-1, 2026-05-10).
The committed TerritoryData.KnowledgeState field (type
TerritoryKnowledgeState) is the runtime state-storage point. The
forward-compat TerritoryData.KnowledgeIntensity field (int) carries
sub-label nuance and is committed but its threshold semantics remain
TBD.
Numeric intensity: the generation contract names a
surveyProgress field as part of the knowledge-values block. The
runtime carries this as TerritoryData.KnowledgeIntensity (default 0
on every territory, including the start camp). Numeric thresholds —
for example, the intensity range that maps to each ladder rung — are
TBD per future balance pass. Until those thresholds are committed,
KnowledgeIntensity is a transparent nuance field that consumers can
display without acting on. The previous int Explored prototype drift
was closed by Wave R-1; see
pr-code-sync-audit.md.
Site State Axis
Owner: Site system, gd-sites-and-dungeons.md.
Committed enum: TerritoryContentState in
Generated/Territories/FeaturePlacement/FeatureContentTypes.cs. The ten
committed labels, in ladder order, are:
Hidden— site exists but the player has no knowledge of it.Hinted— the player has a clue or partial sign of the site.Discovered— the player knows the site exists and its category.Surveyed— site interior or yields are partially mapped.Active— site is currently in active use, exploration, or combat.Handled— primary threat or blocker resolved.Secured— site is controlled and protected.Developed— owned or used as an ongoing Site/improvement.Depleted— site yield exhausted (terminal for productive sites).Destroyed— site removed from the world (terminal).
These labels are committed runtime vocabulary. SiteData carries two
TerritoryContentState fields — DiscoveryState (visibility/discovery
axis) and State (progress ladder). StateIntensity tracks intensity
on the State axis. The Site State Axis is the State ladder, not the
DiscoveryState ladder.
Numeric intensity: int StateIntensity on SiteData. Default 0.
Bare integer per the unified convention established by R-1's
KnowledgeIntensity. The field is wired through H.StateIntensity in
Generated/Hashes.cs + Generated/Declarations.cs and read/written
via the Site branch of HostBridge. Numeric thresholds within each
ladder label remain TBD per a future balance wave; until those
thresholds are committed, StateIntensity is a transparent nuance
field that consumers can display without acting on. Wire projection
(SiteSnapshot) is deferred to a future Server wave.
Cross-Axis Relationships
The three axes are independent. Examples of valid combinations:
- A Feature can be
Surveyedinside a Territory that is onlySighted— knowing one feature in a Territory well does not mean the Territory itself is fully scouted. - A Site can be
Developedinside a Territory that isClaimed(not yetCleansed) — improvement of one Site does not require the whole Territory to be cleansed. - A Feature can be
Hiddeninside aSurveyedTerritory — survey effort does not automatically reveal every Feature.
Cross-axis rules — for example, "a Site cannot be in Developed state
unless the containing Territory is at least Sighted" — are TBD and
are not yet committed. When such rules are added, this section will
become normative.
Cross-Links
- generation/feature-generation-contract.md - the Feature discovery axis owner; "Existence Versus Discovery" section.
- generation/territory-generation-contract.md - the Territory knowledge axis owner; "Knowledge Values" section.
- systems/sites-and-dungeons.md - the Site state axis owner; "Discovery Path" section.
- gd-state-machines-and-transitions.md - canonical state-machine hub cites FeatureDiscoveryState, TerritoryKnowledgeState, and TerritoryContentState as existing precedents for the 12-column transition-row schema.
- implementation/status-and-sync-policy.md - status vocabulary used in this doc's status block.
- implementation/code-sync-audit.md -
drift tracker for the Territory knowledge axis (
int Exploredvs ladder) and Site numeric intensity (no committed field). - implementation/open-questions.md - open questions about state-axis numeric-intensity conventions.