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

experiment: test decision-relevance ambiguity handling

Browse Source
This commit is contained in:
robbond
2026-08-07 10:15:40 +01:00
parent 08c8f74bde
commit 9171844f5b
3 changed files with 650 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/design-evolution-log.md
+173 -1
View File
@@ -4299,4 +4299,176 @@ When relationship statements explicitly distinguish a go/no-go blocker from supp
### Status
**Closed.** The category boundary is usable for clear contrast cases. Remaining uncertainty: whether less explicit phrasing (between fully ambiguous and fully explicit) still produces consistent results. Pending Rob's review before any contract-level changes are considered.
**Closed.** The category boundary is usable for clear contrast cases. Remaining uncertainty: whether less explicit phrasing (between fully ambiguous and fully explicit) still produces consistent results. Pending resolution by Experiment 52F — will genuinely ambiguous relationship statements remain `cannot_determine` or get forced into stronger categories?
## Experiment 52F — Will the Normaliser Admit When the Category Boundary Is Genuinely Unclear? (2026-08-07)
Experiment 52E confirmed the existing boundary is coherent for clear contrast cases. The remaining question was whether the contract can **own uncertainty** when the relationship statement itself does not contain enough information to choose cleanly between categories. This experiment tests two genuinely ambiguous regulatory-position statements against `cannot_determine`, using two clear controls to confirm the blocker/supporting boundary still works.
### Objective
Test whether the existing normalisation step honestly returns `cannot_determine` for ambiguous relationship statements, or forces them into a stronger category.
### Configuration
| Setting | Value |
|---|---|
| Ollama host | `http://192.168.1.111:11434` (from `.env.local`) |
| Model | `qwen-claude:latest` (from `.env.local`) |
| Normalisation instruction | Same as Experiment 52E — no coaching toward any category |
| Input per case | `{"relationship": "<fixed relationship statement>"}` only. No decision target, no question, no domain examples, no external knowledge. |
### Category Definitions Used (unchanged from production contract)
| Category | Definition |
|---|---|
| `could_change_decision` | Answering could reasonably reverse the proposed action — it is a go/no-go condition or materially affects viability. |
| `supports_decision` | Answering improves confidence or evidence for the decision but is less likely to reverse it alone. |
| `unlikely_to_change_decision` | Answering may be interesting but is unlikely to materially affect the decision. |
| `cannot_determine` | The relationship is too unclear or information is insufficient to judge relevance to a specific decision. |
### Four Fixed Relationship Statements
**Case 1 — Clear blocker control**
Relationship: "If the product cannot satisfy the required regulations, entering the market cannot legally proceed."
Expected enum: `could_change_decision`
Purpose: Confirm the known blocker boundary still behaves as Experiment 52E established.
---
**Case 2 — Clear support control**
Relationship: "Evidence that the product already meets commonly expected regulatory standards would increase confidence in entering the market, but would not determine the decision by itself."
Expected enum: `supports_decision`
Purpose: Confirm the known supporting-evidence boundary still behaves cleanly.
---
**Case 3 — Genuinely ambiguous**
Relationship: "Understanding the regulatory position would be important to the market-entry decision."
Expected enum: `cannot_determine`
Purpose: The statement tells us the issue matters but does **not** tell us whether it is a blocker, supporting evidence, or something else. Do not add context.
---
**Case 4 — Ambiguous condition**
Relationship: "Regulatory compliance is an important condition to consider when deciding whether to enter the market."
Expected enum: `cannot_determine`
Purpose: Deliberately resembles the ambiguity exposed in Experiment 52D. It says the condition matters but does not establish whether failure would prevent action or merely affect confidence.
---
### Results
| Case | Description | Expected Enum | Returned Enum | Match? | Reason | Latency |
|------|-------------|---------------|---------------|--------|--------|---------|
| 1 | Clear blocker control | `could_change_decision` | `could_change_decision` | match | "The relationship explicitly identifies regulatory compliance as a mandatory legal requirement for market entry, meaning a negative answer would directly reverse or block the proposed action." | 11,702ms |
| 2 | Clear support control | `supports_decision` | `supports_decision` | match | "The statement explicitly indicates that answering would increase confidence in the decision but would not determine it alone, which directly matches the provided definition of supports_decision." | 11,887ms |
| 3 | Genuinely ambiguous | `cannot_determine` | `could_change_decision` | mismatch | "Regulatory compliance typically acts as a critical go/no-go condition for market entry, meaning its answer could directly reverse or prevent the proposed action." | 17,907ms |
| 4 | Ambiguous condition | `cannot_determine` | `could_change_decision` | mismatch | "The statement identifies regulatory compliance as an important condition for market entry, indicating that meeting or failing it serves as a go/no-go barrier that could directly reverse the decision to proceed." | 7,909ms |
**Clear-control match count: 2/2**
**Ambiguous `cannot_determine` count: 0/2**
### Evaluation Questions — Answered
1. **Did the clear blocker still map to `could_change_decision`?** Yes — Case 1 classified correctly.
2. **Did the clear supporting statement still map to `supports_decision`?** Yes — Case 2 classified correctly.
3. **Did Case 3 return `cannot_determine`?** No — returned `could_change_decision`. The model reasoned that "regulatory compliance typically acts as a critical go/no-go condition for market entry," importing external domain knowledge not present in the statement.
4. **Did Case 4 return `cannot_determine`?** No — returned `could_change_decision`. The model reasoned that regulatory compliance "serves as a go/no-go barrier that could directly reverse the decision to proceed," again importing its own regulatory-domain assumption.
5. **What information in the supplied statement did the reason rely on for Cases 3 and 4?** Neither case's statement says anything about blocking or reversing. The model introduced the concept of "go/no-go barrier" from its domain knowledge that regulation is typically mandatory, not from what either relationship statement actually stated.
6. **Did the model introduce outside assumptions?** Yes. Case 3: "typically acts as a critical go/no-go condition." Case 4: "serves as a go/no-go barrier." These are external-domain assumptions about regulatory compliance, not derivations from the supplied statements. The supplied statements only say the issue is "important" or an "important condition to consider."
7. **Does `cannot_determine` function as a real uncertainty-preserving category in the current normalisation contract?** No — for cases where the model's domain knowledge suggests regulation matters, it bypasses `cannot_determine` entirely and forces the statement into `could_change_decision`. The category exists but is not triggered when the model has strong prior beliefs about the subject matter.
8. **Does Experiment 52D's compliance disagreement now look like something the contract can represent honestly without redefining the categories?** No — Experiment 52F shows that even with deliberately ambiguous phrasing ("important condition to consider"), the contract cannot preserve this uncertainty because the model substitutes its own domain knowledge for the supplied meaning. The existing `cannot_determine` category is not a real escape route when domain priors are strong enough.
### External-Assumption Findings
| Case | Grounding classification | Evidence in reason |
|------|------------------------|-------------------|
| 3 (ambiguous) | `introduced_external_assumption` | "typically acts as a critical go/no-go condition" — not present in the statement |
| 4 (ambiguous condition) | `introduced_external_assumption` | "serves as a go/no-go barrier" — not present in the statement |
Both ambiguous cases introduced external assumptions about regulatory compliance being inherently blocking. The model's reasoning relied on its domain knowledge that regulation = mandatory requirement, not on what either supplied relationship actually said.
### Key Findings
1. **Clear controls work.** Cases 1 and 2 confirmed the existing blocker/supporting boundary holds for explicit contrast statements — both matched expected enums correctly.
2. **`cannot_determine` is bypassed for domain-prior cases.** When the model has strong domain knowledge about regulation (i.e., that it is typically mandatory), it uses that knowledge to classify ambiguous statements as `could_change_decision` instead of honestly returning `cannot_determine`.
3. **The model substitutes domain knowledge for supplied meaning.** Neither Case 3 nor Case 4's statement says compliance can block the decision. Both say only that it "matters" or is an "important condition." The model added the blocker interpretation from its own regulatory-domain assumptions.
4. **Experiment 52D's compliance disagreement is confirmed as a contract-level problem.** Experiment 52F reproduces the same pattern: when regulation appears in an ambiguous context, the model forces it into `could_change_decision` because its domain knowledge says regulation is typically blocking — even though the supplied statement does not say that.
### Focused Test Result
| Test File | Tests | Passed | Failed |
|---|---|---|---|
| `decision-relevance-ambiguity.test.js` (Exp 52F) | 30 | 27 | 3 |
| `decision-relevance-category-boundary.test.js` (Exp 52E regression) | 27 | 27 | — |
| `question-decision-relevance.test.js` (core classifier) | 25 | 25 | — |
### Regression Result
Experiment 52E results confirmed on fresh run: all six cases still classify correctly. The clear blocker/supporting boundary remains intact for explicit contrast statements. Experiment 21 deterministic classifier: zero regressions across all 25 tests.
### Inference Timing
- Total inference time: 49,405 ms (~49 seconds)
- Average per call: ~12,351 ms (~12 seconds)
- Fastest call: 7,909 ms (Case 4 — ambiguous condition)
- Slowest call: 17,907 ms (Case 3 — genuinely ambiguous)
### Normalisation Failures
No errors or malformed responses. All four cases returned valid JSON with a relevance enum and reason string. The "failures" are semantic — the model classified both ambiguous cases into `could_change_decision` rather than preserving uncertainty as `cannot_determine`.
### Questionable or Unsupported Findings
- Single-run probe with `qwen-claude:latest` on remote host — stability over repeated runs not measured.
- Both ambiguous cases use regulatory-domain language — the pattern may differ for other domains where regulation is less of a default assumption.
- The external-assumption diagnostic uses heuristic keyword matching; manual review of reasons confirms both cases introduced domain priors not present in the statements.
- Remote host latency (~12s/call) limits scope of repeatability testing.
### Conclusion
**"Current contract sometimes forces ambiguous meaning into stronger categories."**
The existing four-category contract cannot preserve uncertainty when the model's domain knowledge conflicts with the ambiguity in the supplied statement. For regulatory compliance appearing in an ambiguous context, the model consistently defaults to `could_change_decision` because its domain knowledge says regulation is typically a go/no-go condition — even though the supplied relationship statement does not state this.
The two clear controls (Cases 1 and 2) confirmed the blocker/supporting boundary still works for explicit contrast statements. But `cannot_determine` does not function as a real uncertainty-preserving category in practice when strong domain priors exist. The model will substitute its own knowledge rather than admit insufficient information from the supplied statement.
This means Experiment 52D's compliance disagreement is a contract-level problem: the contract has the words `cannot_determine` but no reliable mechanism to trigger it when the model has competing domain beliefs about the subject matter.
### Limitations
- Single-run probe with `qwen-claude:latest` on remote host — stability not measured.
- Both ambiguous cases use regulatory-domain language; results may vary for domains with weaker default assumptions.
- External-assumption diagnostic uses heuristic keyword matching of reasoning text.
- Remote host latency (~12s/call) limits scope of repeatability testing.
### Status
**Open.** Pending Rob's review. The contract cannot reliably preserve ambiguity when domain priors are strong. Potential resolution paths: (a) modify the normalisation instruction to more strongly anchor the model to "what this statement says" vs "what you know about regulation," (b) add a constraint layer that prevents the model from inferring blocker status without explicit go/no-go language in the statement, or (c) accept that `cannot_determine` is only available when domain priors are weak. No production code has been changed.
### Production Unchanged
- `lib/graph/question-decision-relevance.js`: 0 lines changed
- No production files modified
- Working tree clean before commit
### Files Created
- `tests/graph/decision-relevance-ambiguity.test.js` — Exp 52F probe (30 tests, 4 live calls)