# Cross-Layer Trace Evidence

## Answer

This record distils the cross-layer trace investigation of 2026-10-30 into the claims this release relies on. Counts below were measured over the largest consumer's built model on 2026-10-30, holding 21,548 records.

Read top down, the chain breaks at the top, not at the bottom. Goal to feature: 12 of 40 features name a goal in `serves`, and all 8 goals are served, but 28 of 40 features serve no goal. Feature to problem: 40 of 40 features name `solves`, the one strong Intent hop, already required and checked. Feature to requirement: 23 of 40 features are named by any requirement, and 872 of 928 requirements name no feature, by design. Requirement to Behavior: 763 of 925 live requirements are fulfilled in the checker's sense, 53 are exempt as undelivered, 10 quality requirements are served by a technical decision, and 105 are unfulfilled, all covered by a waiver, so a reader of open findings alone sees no break. Journey to requirement: 112 of 112 journeys carry `fulfills` over 571 distinct requirements, complete but unchecked. Use case to result: 1,272 of 1,272 have a success result. Result to scenario: 3,083 of 5,413 written results have a scenario; 2,330, mostly refusals, have none. Scenario to test: 5,426 of 6,517 scenarios have a confirmed `proves` link, but every link has a null passing state, the model's test run is null, and zero of 1,272 use cases read verified. Use case to code: 1,266 of 1,272 use cases are implemented. Screen to use case: 380 of 380 screens have `offers` equal to computed `calls`.

End to end, only 19 of 925 live requirements trace to a goal through `feature` and then `feature.serves`; per goal the counts are 11, 9, 5, 1, 1, 0, 0, and 0. Of those traced requirements, only 3 reach an implemented use case with a confirmed scenario proof. Only 18 of 1,272 use cases trace to a goal, so only 18 of 1,251 handlers reach one. Every other handler reaches a requirement or a journey step and stops, because the journey above the step names its goal only as a sentence. From a route the climb stops at the same wall: screens, steps, journeys, and requirements all connect, but the journey cannot name its goal record, so a route answers which promise and never which outcome.

The requirement middle is the weak hop. Of 928 requirements, 56 name a `feature`, 164 name `basedOn` (139 constraint and 48 research citations with overlap), 209 name either, and 719 name neither. The genuinely broken set is smaller and sharper: 109 live requirements name neither anchor and are also unfulfilled, answering neither why they exist nor what keeps them. The journey hop above them is undefined, not merely empty: a goal record has no outgoing link field at all, `journey.goal` is a sentence in 112 of 112 cases, and there is no journey to goal hop in LiteSpec. The rest of the journey chain is strong: all 1,077 steps carry identity and actor, all are served, and screens serve 817 of them, with 91 known `step-screen-missing` findings and none open.

Three inconsistencies were found where specifications disagree. Eleven use cases serve a whole journey instead of a step; the link-type table allows `serves` to name a journey while the schema's `servesArray` allows only a step or a goal, so these records pass one definition and break the other. Written result identifiers drop the module while derived ones keep it, so a reader must learn two containment shapes. Route links name screens as frontend and route text rather than `screen/` identifiers, so joining a call to its screen record needs the computed `screens` array.

Governance divides sharply by home. Three product decisions all carry `decides`; 71 technical decisions govern through `follows` and `basedOn`, of which 56 name a basis, 15 draw advisory `decision-basis-missing`, and 8 draw `decision-unimplemented`. The `follows` hop has a tooling break: the model writer exports only `implements`, `calls`, and `proves`, so code to decision traceability is defined and checked but unrecoverable from the built model or the book. Constraints and research are reached unevenly through `basedOn` (24 of 29, 14 of 29), while 25 of 29 constraints cite research as free text in `source`, which no link table validates. Five of 22 waivers name neither `subject` nor `code` and govern nothing a tool can name, and no waiver subject grammar covers one journey step.

The investigation argues against mandatory `requirement.feature` as written, because it would invert the field's stated narrow meaning and duplicate the requirement page's own rationale; it supports an anchor set instead, requiring each live requirement to be fulfilled, undelivered through its feature, served by a technical decision when quality, or covered by an unexpired waiver, plus one advisory check for a requirement with no `feature`, no `basedOn`, and no deciding decision. It agrees that every feature should name its goal beside the existing `solves` rule, agrees the journey needs an identifier-typed goal link, and agrees checks should start advisory with one warning: 105 fulfilled-check results already sit parked in waivers, invisible in open findings, so a new advisory check needs a named promotion test or it will graduate into the waiver list instead of into compliance.