Specify the trace and check chapter 16's three properties on it #48

Parent

#35

What to build

The Resolved Deployment metamodel carries a trace: for each layer-2 value and each Deliverable field, the declarations and pinned facts it came from and the rule that derived it. Chapter 16's three properties become checks over a trace:

1. every rendered object and field has at least one source;
2. no field has two declaring sites;
3. every declaration reaches something.

The checks are implemented and tested on trace fixtures now. They run over real renders when the resolver lands, and the registry lists them as pending until then. Chapter 16's claim that the renderer's attribution table suffices is rewritten; attribution becomes one field of a trace link. A diagnostic raised in layer 2 or layer 3 can name the authored line through the trace.

Parity

(Amended 2026-09-14 for the revised proposal, #102.) The trace is part of the Resolved Deployment metamodel, so it is part of every resolved.json oracle, which binds the production implementation only. The model-driven implementation is not required to emit it. Trace links name rule identifiers from #47 and sources as JSON Pointers into the canonical input documents, so the trace carries nothing implementation-specific. The three checks are defined over the canonical trace; the trace fixtures are canonical JSON both implementations can load.

Acceptance criteria

• A trace fixture with an orphan Deliverable fails check 1, one with a field declared twice fails check 2, and one with a dead declaration fails check 3.
• Chapter 16 names the trace, not the attribution table, as what the properties are checked over.
• The trace fixtures are canonical JSON, and a trace link names only rule identifiers and JSON Pointers.

Blocked by

• Give the Resolved Deployment a metamodel and validate the worked projection #42
• Name every derivation and generate the authority table #47