docs(web): fold the specification relation into the existing model pages

Connections gains what a connection actually relates, and the three
kinds of strain gain their derivation rather than standing as an
observed list.

Canonical execution gains a step: criteria are derived from the Request
before the replay runs, so neither party to the comparison authored the
bar. That is the mechanism the "can the comparison indict the workflow"
question was asking for, and open-questions now says so — along with
what it does not answer.

Also records the topology-universality question raised in design
discussion: the artifact catalog and unit-of-change edges look portable,
governance targets are local by construction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NVUmAFcaehyGJRUSxUUtFU

Author: unional

apps/web/src/content/docs/model/canonical-execution.md

@@ -1,6 +1,6 @@
 ---
 title: Canonical execution
-description: How confluence is bought — distill a change to a Request, replay it, compare
+description: How confluence is bought — distill a change to a Request, derive its criteria, replay it, compare
 ---
 
 :::caution[Design, not implementation]
@@ -26,18 +26,40 @@ landed. It is lifted, distilled, and replayed:
 1. **Lift** the raw diff from lines into artifact-set vocabulary.
 2. **Distill** it to a **Request** — the intent behind the change, separated from the
    particular expression of it — together with the workflow that applies.
-3. **Replay** the Request through that workflow from its starting point.
-4. **Compare** the replayed delta against the change that arrived.
+3. **Derive the criteria** the settled state must satisfy, from the Request.
+4. **Replay** the Request through that workflow from its starting point.
+5. **Compare** the replayed delta against the change that arrived.
 
 The replay is an *independent derivation*. It does not read the incoming change as an
 answer; it derives its own and then looks.
 
 **Status: Thesis.** Flagged by its author as needing further design and analysis. The
 loop's shape is agreed; several of its parts are not.
 
+## Criteria are derived before the replay, not after
+
+Step 3 is ordered deliberately, and the order is the whole of its value.
+
+A [specification](/cyber-truss/model/specification/) is intent plus criteria, and the
+comparison in step 5 is a comparison of criteria. If those criteria were read off the
+replay's output, the comparison would be checking the workflow against itself and could
+only ever conclude *"the incoming change is wrong."*
+
+Derived from the Request instead, the criteria are authored by neither party to the
+comparison. A workflow that produces something conforming-but-wrong now fails criteria it
+did not write. This is the same move SDD makes by freezing the `.feature` suite before the
+implementation exists, generalized from one gate to every crossing.
+
+It does not close the question below — criteria derived from a misread Request are wrong in
+the same direction as everything downstream of them. It replaces *hope that the comparison
+is honest* with a mechanism that can be inspected.
+
+**Status: Thesis.** The ordering is agreed; what "derive the criteria" consumes beyond the
+Request is not.
+
 ## The inversion
 
-Step 4 changes what the incoming change *is*.
+Step 5 changes what the incoming change *is*.
 
 The designer's mockup is not the deliverable. It is a **prediction of the settled state**,
 and the replay is the independent derivation that checks it. The comparison is where the
@@ -133,4 +155,9 @@ The comparison step is the only protection, and it works only if disagreement is
 as evidence about **the workflow** as often as about the change. A comparison that can
 only conclude *"this change is wrong"* will launder a defective workflow indefinitely.
 
-**Status: Settled** as a requirement on the comparison. **Open:** how it is enforced.
+Deriving criteria [ahead of the replay](#criteria-are-derived-before-the-replay-not-after)
+is the mechanism proposed against this. It is not yet a full answer, because it moves the
+exposure up to the Request rather than removing it.
+
+**Status: Settled** as a requirement on the comparison. **Open:** whether independently
+derived criteria are enough to enforce it.

apps/web/src/content/docs/model/connections.md

@@ -29,6 +29,16 @@ same one.
 
 **Status: Settled.**
 
+## What a connection relates
+
+Two artifact-sets, at their [specifications](/cyber-truss/model/specification/) rather than
+their implementations. There is no diff between a TypeScript module and a Figma frame, so a
+connection stated over implementations could never be evaluated; stated over criteria, both
+ends are written in one vocabulary.
+
+**Status: Settled.** The argument is on the
+[Specification](/cyber-truss/model/specification/#the-problem-this-solves) page.
+
 ## Connections are undirected
 
 A connection is a relation between two artifact-sets. It is **not** an arrow.
@@ -95,6 +105,12 @@ Axis 2. *This skill violates the agent-instruction guidelines.*
 
 State-driven, evaluable on a cold repository, and requires no delta.
 
+The three are not an arbitrary list. Read through the specification relation they are the
+three ways a specification and its implementation can fail to meet: both in hand and
+disagreeing, the implementation elsewhere, or no implementation in the delta at all. That
+derivation is on the [Specification](/cyber-truss/model/specification/#what-the-roles-explain)
+page.
+
 **Status: Settled** that the three are distinct and block differently. **Open:** the
 precise boundary conditions on each.
 

apps/web/src/content/docs/model/open-questions.md

@@ -72,7 +72,14 @@ defective workflow converges reliably on the same wrong answer, and normalizes a
 ad-hoc changes that would have revealed it.
 
 The comparison must be able to conclude *"the workflow is wrong"* and not only *"this
-change is wrong."* How that is enforced — rather than merely hoped for — is unresolved.
+change is wrong."*
+
+The mechanism now proposed is
+[deriving the criteria from the Request before the replay runs](/cyber-truss/model/canonical-execution/#criteria-are-derived-before-the-replay-not-after),
+so that neither party to the comparison authored the bar it is judged against. That is a
+real mechanism where there was previously only a requirement, but it relocates the exposure
+rather than removing it: criteria derived from a misread Request are wrong in the same
+direction as everything downstream of them. Whether the relocation is enough is unresolved.
 
 ## Where does the controller interface sit?
 
@@ -97,3 +104,16 @@ for settling it before there is more than one controller rather than after.
   differently shaped, should be run through the model before it is fixed.
 - **What form does provenance take** on deltas produced by canonical execution, so they
   do not re-trigger it?
+- **How are specification levels identified across artifact types?** Two specifications are
+  comparable when they sit at
+  [the same rung](/cyber-truss/model/specification/#specifications-exist-at-every-level) —
+  function, module, product, system. What fixes the rung for an artifact type that has no
+  obvious analogue of a function is undefined.
+- **How much of the artifact topology is universal?** The catalog of artifact *roles* looks
+  close to portable across repositories, and so do most
+  [unit-of-change](/cyber-truss/model/artifact-sets/#axis-1--unit-of-change) edges, which
+  follow from what the artifacts mean.
+  [Governance targets](/cyber-truss/model/artifact-sets/#axis-2--governance-target) are
+  local by construction — they are a team's opinion about which criteria apply where. If
+  that split holds, the product ships a default topology that repositories extend and
+  override rather than a blank page. Empirical, and untested against a second repository.