fix(confidence-engine): enforce relationship endpoint references

docs/current-handoff.md

@@ -51,6 +51,12 @@
 - Previous diagnostics flattened the failure to `reconstruction: Required` and truncated raw evidence. Failure responses now retain exact validation issue paths, codes, messages, available native metadata, and complete diagnostic raw response at the existing validation boundary.
 - Reasoning prompt, schema acceptance, and provider behaviour remain unchanged; no live calls occurred in this increment. Next restart point: one production-default manufacturing call—evaluate E if it succeeds, or use the new evidence to diagnose the exact structured-output defect if it fails.
 
+## Relationship endpoint reference integrity
+
+- The latest valid live run semantically preserved intervention-fit E in relationship `r5` with correct direction, but `r5.fromId` referenced a semantic-unit ID never emitted, so the non-inferential builder correctly skipped projection.
+- This is a generation-time relationship-reference integrity defect. v0.5 now requires semantic units before relationships and exact reuse of emitted endpoint IDs; legitimate missing endpoint concepts must be materialised first under existing provenance rules.
+- The builder remains unchanged. Live compliance remains untested; next restart point is one production-default relationship-reference-integrity validation.
+
 ## Current product architecture
 
 Three distinct routes, not a single page:

prompts/reconstruct-v0.5.md

@@ -36,6 +36,8 @@ Reconstruction must preserve not only supplied semantic units but also relations
 
 Each relationship `fromId` and `toId` MUST reference IDs of semantic units already present elsewhere in `reconstruction`. Do NOT invent a relationship endpoint merely to complete a relationship. Preserve unresolved relationships as unresolved or provisional when the user leaves them unresolved. Keep useful relationship prose in `summary` where appropriate, but summary prose is not the authoritative representation of graph-critical relationships. Do not introduce an action recommendation or steering.
 
+Complete the semantic-unit collections first; only then construct relationships. For every relationship, copy `fromId` and `toId` exactly from IDs already emitted in a reconstruction semantic-unit collection—never generate a new relationship-only ID or guess one from a description. If a supplied relationship needs a legitimate semantic concept not yet represented, add that semantic unit to the appropriate existing collection first, then reference its exact ID; if that concept cannot legitimately be represented under the provenance rules, omit the relationship rather than substituting a related endpoint. Before returning JSON, check every relationship by finding both endpoint IDs in emitted semantic units. The structural need for an endpoint is not evidence that its meaning is justified.
+
 Read every relationship literally as `fromId → relationship → toId`. For directional types, endpoint meanings and the description MUST agree: `A depends_on B`, `A causes B`, `A may_cause B`, `A supports B`, and `A weakens B` mean `fromId=A` and `toId=B`. Do not assign stronger directionality to `contradicts`, `compares_with`, or `other`; `compares_with` may use either endpoint order. Before emitting a relationship, read it back as “FROM [relationship] TO”. If that reading contradicts the description, reverse the endpoints or choose the correct relationship type.
 
 When the user explicitly makes a contemplated action, intervention, investment, or decision contingent on understanding an unresolved condition, preserve that dependency at the level supplied: represent both the unresolved appropriateness, fit, or timing of the intervention and the unresolved condition, then declare `intervention appropriateness depends_on unresolved condition`. Narrower supported evidence prerequisites (such as measurement validity, normalised rate, or source attribution) may additionally support assessing the condition, but MUST NOT replace the supplied higher-order intervention-fit dependency. Apply this only when the user supplies that contingency; do not infer that every action depends on every unknown, create a generic decision tree, recommend, or rank actions. The relationship records dependency only: it does not establish the condition, determine whether the intervention is appropriate, or advise whether to act or wait.

tests/v03-reasoning.test.js

@@ -253,6 +253,18 @@ describe("v0.5 prompt", () => {
     expect(prompt).toContain("MUST NOT replace the supplied higher-order intervention-fit dependency");
   });
 
+  it("requires relationship endpoints to reuse emitted semantic-unit IDs", async () => {
+    const { prompt } = await buildPrompt("Endpoint integrity scenario", "v0.5");
+
+    expect(prompt).toContain("Complete the semantic-unit collections first; only then construct relationships");
+    expect(prompt).toContain("copy `fromId` and `toId` exactly from IDs already emitted");
+    expect(prompt).toContain("never generate a new relationship-only ID");
+    expect(prompt).toContain("add that semantic unit to the appropriate existing collection first");
+    expect(prompt).toContain("omit the relationship rather than substituting a related endpoint");
+    expect(prompt).toContain("check every relationship by finding both endpoint IDs in emitted semantic units");
+    expect(prompt).toContain("not evidence that its meaning is justified");
+  });
+
   it("retains the provenance stop boundary and interpretation separation", async () => {
     const { prompt } = await buildPrompt("Contract retention scenario", "v0.5");