Design implementation
The normative contract is the repository-root DESIGN.md.
Production boundary
Production uses stock-default Zensical runtime chrome from zensical.toml. The technical repository graph uses assets/graph.css and assets/wiki.js; the secondary Ask tool uses the .wiki-ask-scoped assets/ask-wiki.css and assets/ask-wiki.js. Ask output is navigational synthesis and has no evidence authority. The isolated assets/layout-width.css and assets/layout-width.js pair adds a desktop Standard/Wide control: Standard retains Zensical's native grid; Wide expands the shared header, navigation/content/page-outline and footer grid with one-rem viewport gutters. At desktop widths the site title follows the article's left rail while the logo stays on the outer header rail, and Search follows the page-outline text rail. The preference is local to the browser and narrow layouts remain native. These bounded assets must not otherwise restyle evidence findings, Defence registers or renderer navigation states.
The former customised interface is isolated as the frozen, non-production zensical.sunset.toml plus assets/theme.css profile. It shares content and navigation with production but is not served by the always-on service.
Reader model
The navigation is organised as Evidence base, Findings, Defence application, Methods and assurance, Outputs, and About and tools. This sequence mirrors the authority and use path from source material to bounded synthesis and then analytical application. Repository operations and graphs are secondary because they explain how the wiki works rather than what the evidence shows.
The complete report corpus is browsed through generated profile, catalogue, selection-flow, assurance, counter-position, response and map pages. Individual generated report records are linked and searchable but are not all placed in the left navigation. Representative case narratives remain available as readable anchors.
Home exposes the Executive summary and a compact glossary. Methods groups review design/audits, analytical lenses and evidence controls, each with its own overview; Requirements and testing uses the finding crosswalk as its overview. ICMM material remains a single nested output family. These groupings reduce a long flat navigation list without changing the evidence-first reader sequence.
Traceability model
primary source → report → claim → mechanism → candidate requirement → assurance test
The evidence profile, catalogue, assurance dashboard, counter-position page, report records and case–mechanism/evidence map are generated views of canonical records. The repository graph is a separate technical Graphify view and has no evidence authority. Its 2D and force-directed 3D renderers share one complete enriched dataset; document, source-reference, navigation and filesystem edges describe repository structure rather than evidential support.