System Health
System Health is the architectural portrait of the build that produced this Guide. It is not runtime telemetry, request monitoring, or an operations dashboard. Instead, it answers a narrower and more useful developer question: what does this build of Musewoods currently expose, and do the implementation, validation rules, fixtures, and Field Manual still agree about that surface? The answer has two categories that must not be conflated: the four publishing fields and cross-field system layers. Navigation is now an implemented v9 system layer: Trailhead v2 has a semantic journey grammar and Trailmap v9 has a graph registry, validation, projection, and Explorer interaction model. Resonance is also registry-backed for its relationship and circulation responsibilities. Clearing remains documented as a normative design direction and should enter capability counts only when its registries and validators exist in code.
The page is intentionally thin because the authoritative inventory is rendered from the capability model below. Human prose explains what the bands mean; the platform remains responsible for current counts and PASS/FAIL state.
Implementation Status
The rendered status groups information into four kinds of evidence. Implementation identifies the build being described. Capability Counts summarize the registered public surface without treating cross-field systems as additional publishing fields. Integrity exercises selected validators and shipped fixtures to make sure the architecture still hangs together. Coverage compares the implementation vocabulary, including Navigation and Resonance system contracts, with the Field Manual's coverage ledger so capabilities cannot quietly disappear from documentation or survive there after the implementation has removed them.
The important property is directionality in both ways. A new public capability without Guide coverage is a documentation defect; a documented public capability that no longer exists is a stale-contract defect. System Health therefore turns documentation drift into something the build can detect rather than something a future reader must notice by accident.
For the rule that distinguishes a real live specimen from a fenced source example, see Coverage on Authoring Grammar. For the validation boundaries behind the integrity checks, see Architecture & Validation.
Implementation
Musewoods v9.0schema v1build 305f78b4109a
Capability Counts
- Publishing fields
- 4
- Global navigation destinations
- 6
- Story motifs (public / total)
- 51 / 55
- Grove motifs (public / total)
- 23 / 26
- Grove native motifs
- 17
- Journal editorial markers
- 25
- Viewgraph renders
- 10
- Shared editorial motifs
- 3
- Analytical primitives
- 3
- Chart families
- 14
- Interaction modes
- 5
- Grounds
- 2
- Ground token roles
- 16
- Visibility modes
- 2
- Journal statuses
- 3
- Grow states
- 8
- Palette roles
- 34
- Analytical series
- 8
Integrity
- Capability model resolves
- Story movement integrity2 Story spine(s) one-to-one
- Journal validation"Musewoods Developer Guide — Journal Specimen" — 179 words, status published
- Guide demo content presentStory · Journal · Viewgraph · Grove all present
Coverage
- Developer Guide coverageregistry − ledger = ∅ (both ways)
- Chart family coverage6 live / 8 via canonical gallery