robbond/confidence-engine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

experiment: trace update provenance boundary

Browse Source
This commit is contained in:
robbond
2026-08-07 13:39:09 +01:00
parent 7e74ad86f2
commit ec167f2689
2 changed files with 108 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/current-handoff.md
+2 -2
View File
@@ -126,6 +126,6 @@ Answer before continuing:
*Created by Experiment 34. Updated by Experiments 38–53, 54A. Branch: `feature/user-workspace-ux-v0.7`.*
### Return-to-Work Note (Experiment 53 → 54A → 54B)
### Return-to-Work Note (Experiment 53 → 54A → 54B → 54C)
Experiment 53 proved semantic separation was possible; 54A inspected whether the current SituationGraph preserves that distinction from source code alone (confirmed: it does not); 54B traced both flows to find where provenance is lost and whether it is recoverable. The key finding: supplied-versus-inferred provenance EXISTS upstream in evidenceRecordSchema (evidenceType enum) but is LOST at buildInitialGraph because the node schema has no provenance field and only IDs are added to evidenceIds as bare string references without type metadata. For updates, the answer survives through to applyValidatedProposal but carries no provenance onto nodes/edges. Provenance recovery from graph state alone is NOT possible — it requires access to upstream evidence arrays. What remains open: creating (not merely preserving) a node-level provenance field and propagating evidenceType through both buildInitialGraph and applyValidatedProposal. First file to inspect when resuming: `lib/reconstruction/schema.js` line 116-121 for the upstream evidenceType enum, then `lib/graph/builder.js` lines 61-70 (dead code), then `lib/graph/apply-proposal.js` lines 2719-2882 (update path with no provenance attachment).
Experiment 53 proved semantic separation was possible; 54A confirmed the SituationGraph cannot recover provenance from graph state alone; 54B showed supplied-versus-inferred distinction exists upstream in evidenceRecordSchema but is lost at buildInitialGraph because the node schema has no provenance field and evidenceIds carries only bare ID references. 54C inspected the normal answer-update boundary and found that while the raw user answer and validated model proposal are explicitly separate parameters at applyValidatedProposal's call site (orchestrator.js:683), they cannot be deterministically mapped to individual graph nodes within the proposal — the LLM independently generates additions from answer context with no provenance mapping. First function/file to inspect when resuming: `lib/graph/orchestrator.js` line 633 (buildGraphUpdatePrompt) to assess whether prompt structure carries any origin markers.