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

experiment: audit evidence source linkage

Browse Source
This commit is contained in:
robbond
2026-08-07 15:11:57 +01:00
parent 455d6f4c84
commit d2d84656fe
2 changed files with 116 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/design-evolution-log.md
+112
View File
@@ -5679,3 +5679,115 @@ Answer: **both**. The provenance gap has two independent causes:
### Status
**Pending Rob's review.** Source-inspection complete. No production code changed. Working tree clean before commit.
## Experiment 54G — Do Evidence Records Contain Deterministic Source Linkage Back to User Words? (2026-08-07)
### Objective
Answer one narrow provenance question: does the current reconstruction output contain enough source information to deterministically prove that an evidence record came from the user's actual words, without trusting the LLM's `evidenceType` label? Source-audit only. Do not implement provenance.
54F established that `evidenceType` is model classification, not reliable provenance. 54G tests whether evidence records nevertheless retain deterministic linkage to the user's actual words — such as exact text, character offsets, turn ID, source path, or other structural location data.
### Hypothesis
An evidence record may already preserve enough source material — such as exact text, quote, source excerpt, source ID, character range, source path, turn ID, or input reference — for deterministic code to verify that a record is directly grounded in the user's supplied text. If no such information exists, then evidence-record identity alone cannot establish user provenance.
### Files Inspected
- `lib/reconstruction/schema.js` — `evidenceRecordSchema` definition (lines 113–127); `reconstructionV2Schema` (line 182)
- `prompts/reconstruct-v0.3.md` — evidence record output format (lines 126–136); CRITICAL RULE 7 (line 155)
- `lib/reconstruction/compatibility.js` — `normaliseAnalysisResponse` function (full file); source null-handling (lines 31–38)
- `tests/reconstruction/compatibility.test.js` — real evidence-record shapes from tests (lines 36–44, 54–72, 107–115, 137–147)
- `lib/analysis.js` — `analyseScenario` function (full file); confirms raw scenario is NOT returned alongside evidence records (lines 173–188)
### Evidence-Record Source-Related Fields
From `evidenceRecordSchema`:
| Field | Type | Provenance potential |
|-------|------|---------------------|
| `id` | `z.string().min(1)` | None — free-form, LLM-generated. No structural reference to input. |
| `description` | `z.string().min(1)` | None — model-generated summary of the evidence, not user text. |
| `evidenceType` | enum (5 values) | None — model classification, per 54F. Not structural provenance. |
| `source` | `z.string().optional()` | Partially — prompt says "who/where this came from". But: it is free-form text generated by the LLM, not deterministic production code output. In tests, it appears as `"report"` (free label) or `null` (removed by normalisation). No character offsets, turn IDs, span data, or source record references are structured into it. |
| `attribution` | `z.string().nullable().optional()` | None — test fixtures show `null` by default. When populated, it is free-form model text describing who said what, not a deterministic production-code identifier back to input. |
| `confidence` | enum | None — subjective confidence level, not source data. |
| `importance` | enum | None — semantic weight, not source data. |
### Does Raw User Statement Coexist with Reconstruction Result?
**No.** The raw user statement (`scenario`) is the input parameter to `analyseScenario`. It is used only for prompt building (line 59 of analysis.js). It is NOT included in the return value alongside `evidence` records or the validated reconstruction. At validation time, deterministic code has:
- the evidence records (with model-generated descriptions and types);
- but NOT the raw user statement itself.
Even if deterministic code had the scenario text available at validation time, the evidence records still lack any field containing verbatim user text or structural location back to it.
### Does Evidence Record Preserve Exact User Wording?
**No.** The `description` field is a model-generated summary/paraphrase of the evidence — not the user's actual words. The `source` field, when non-null, is free-form text like `"report"` (a label, not a quote). No evidence record contains verbatim or near-verbatim user text.
### Does Evidence Record Preserve Source Location / Span / Turn Identity?
**No.** None of the evidence record fields contain:
- character offsets within user input;
- sentence or line index;
- turn or message ID;
- source record ID owned by production code;
- any structural reference to a specific location in the original input.
The `source` field prompt description says "who/where this came from" but it is free-form, inconsistently populated (sometimes null), and produced by the LLM not deterministic code.
### Who Creates Evidence Record IDs?
**The LLM.** The prompt template (line 128 of reconstruct-v0.3.md) says `"id": "<any unique string>"`. The schema only requires `z.string().min(1)`. No production code generates or constrains the ID beyond non-emptiness. The ID is opaque and carries no provenance semantics.
### Can Evidence Records Be Verified Against Raw User Input?
**No.** Deterministic verification would require:
1. Raw user text available at validation time — NOT present in result;
2. Each evidence record containing verbatim user text or a deterministic structural reference to a location within it — neither present.
The `description` field is model-generated paraphrase, not verbatim text. The `source` field is free-form model output, not a structured pointer. No field survives from the raw input to the result in a form that code can verify.
### Trace: Raw User Statement → Evidence Record → Source Verification
| Stage | Raw source identity available? | Exact source wording/location? | Deterministic verification possible? |
|-------|-------------------------------|-------------------------------|-------------------------------------|
| Raw user statement | explicit (input parameter) | explicit (raw text) | N/A — this is the ground truth |
| Reconstruction prompt | absent (scenario pasted as {{SCENARIO}} with no structural markers) | partial (present in prompt body but unlabelled and indistinguishable from system instructions) | No |
| LLM evidence record | absent (all source identity lost to model generation) | absent (description is model paraphrase; source/attribution are free-form model text or null) | No |
| Validated result (analysis.js return) | absent (scenario not returned alongside evidence) | absent | No |
### Trace: Evidence Record → Source Verification
| Step | Status |
|------|--------|
| Get evidence record fields | present |
| Check description against user text | impossible — no verbatim text to compare |
| Check source/attribution as structured location | impossible — free-form model output, not production-code identifiers |
| Check id for provenance semantics | impossible — opaque LLM-generated string |
| Verify evidenceType independently | impossible — no source text to verify against |
### Does Current Reconstruction Schema Contain Enough Information for Deterministic Provenance?
**No.** The schema fields `source` and `attribution` exist as free-form optional strings, but neither is deterministic (they are model-generated), nor do they contain structured location data. The raw user statement is not returned alongside the evidence records. Even if it were, no evidence record field contains verbatim text or structural reference to it.
### Primary Source-Linkage Gap
Evidence records carry no verbatim user text and no deterministic structural reference (character offsets, turn/message IDs, source record references) back to the original input. The only candidate fields (`source`, `attribution`) are free-form model-generated strings that may be null, and which cannot be independently verified against user input. Additionally, the raw user statement itself is not returned with the validated reconstruction result at validation time.
### Experiment 54G Conclusion
**Existing evidence records do not contain deterministic source provenance.** Neither verbatim user text nor structured location references (character offsets, turn IDs, source record references) survive into the evidence records. The `source` and `attribution` fields are free-form model-generated text that may be null — they cannot establish deterministic linkage to user-supplied words. The raw user statement is not returned alongside the validated reconstruction result. Therefore, deterministic code cannot verify that any evidence record was produced from the user's actual words without trusting the LLM's `evidenceType` label.
### Limitations
- Source-inspection audit only; no live execution tested
- Inspected only the initial reconstruction path (v0.3 prompt) and the analysis pipeline
- Did not inspect whether evidence records are stored with graph nodes in a way that could later be recovered
- Did not inspect the update path which uses different prompts and potentially different provenance characteristics
- Conclusions apply to the v0.3 reconstruction output as currently implemented
### Status
**Pending Rob's review.** Source-inspection complete. No production code changed. Working tree clean before commit.