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

experiment: choose declaration recovery boundary

Browse Source
This commit is contained in:
robbond
2026-08-12 13:27:02 +01:00
parent a40a3e343e
commit a78f3edb10
2 changed files with 288 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/current-handoff.md
+4
View File
@@ -1679,3 +1679,7 @@ This satisfies 57J.77's boundary A recommendation: a committed update-only path
### Experiment 57J.85 — Null Semantic/Action Architecture Diagnosis (Read-Only)
**Objective:** Diagnose why `answerMeaning=null + structuralActionRequired=null + meaningful mutation` is accepted through the current pipeline, and whether this compatibility path should remain open. Read-only diagnosis across prompt contract, schema, validator, and apply-proposal validation layers. **Classification: B — TRANSITION COMPATIBILITY.** The null/null/mutation path persists because: (1) Zod schema allows nullable fields for backward compatibility; (2) validator rules are scoped to only reject when meaning IS populated (rule 1), leaving null-meaning mutations unguarded; (3) the model produces useful data through this path (57J.84: £2m/year on reported_claim node); (4) tightening without a deterministic recovery/retry path would discard that information. Architectural choice A — keep the null transition path for now, pending deterministic recovery capability before tightening becomes safe. Smallest next boundary: implement a deterministic recovery mechanism for proposals with meaningful mutations but unpopulated semantic/action fields. No production code changed; no Ollama calls; documentation-only diagnosis.
### Experiment 57J.86 — Smallest Recovery Contract for Null Semantic/Action with Good Mutation (Read-Only Design)
**Objective:** What is the smallest recovery contract that lets the engine preserve a good mutation while recovering missing semantic/action declarations, without regenerating or discarding the mutation? Read-only design evaluation of four options (deterministic action fill, declaration-only repair call, full regeneration, keep transition path). **Classification: B — DECLARATION-ONLY REPAIR CALL.** structuralActionRequired is PARTIALLY recoverable from structure via hasMeaningfulChange=true (but this changes field semantics from model declaration to engine inference). answerMeaning fields are NOT recoverable from mutation structure alone. Existing code has zero repair capability — validator only validates, orchestrator returns errors on rejection with no retry/repair path. Option B chosen: one bounded second-stage repair call that preserves mutation arrays exactly and recovers all missing declarations (answerMeaning + structuralActionRequired) through model declaration. Repair receives raw answer + original proposal as context; forbidden from changing any mutation arrays. Repair classified as SECOND-STAGE REPAIR, not RETRY or NORMAL SECOND CALL — existing call accounting cannot cleanly distinguish repair calls without tooling change. Non-negotiable invariants all met: original mutation preserved, no keyword logic, no regeneration, exactly 1 bounded additional call, provider-agnostic, 57J.84 information survives full recovery. No production code changed; no Ollama calls; documentation-only design.