experiment: define semantic action contract
This commit is contained in:
+36
-1
@@ -1151,4 +1151,39 @@ Configured Ollama: none used. **Production code changed:** NO.
|
||||
- MODEL: supply one valid candidate when new unresolved unknowns are added
|
||||
- ENGINE: validate candidate, retain deterministic priority/scoring ownership
|
||||
|
||||
Configured Ollama: none used. **Production code changed:** prompt + tests only. **Ollama calls:** 0.
|
||||
Configured Ollama: none used. **Production code changed:** prompt + tests only. **Ollama calls:** 0.
|
||||
|
||||
### Experiment 57J.65 — Smallest Enforceable Semantic-to-Mutation Contract (Read-Only Deterministic)
|
||||
|
||||
**Objective:** What is the smallest structured contract that lets the model declare whether graph action is required, and lets deterministic code verify that the actual proposal fulfils that declaration? **Classification: B — BOOLEAN STRUCTURAL-ACTION CONTRACT.**
|
||||
|
||||
**Part 1 — Existing fields:** C — NEW ACTION DECLARATION REQUIRED. The existing fields encode *what changed* but not *what was intended*. When all mutation arrays are empty, there is no field saying "I intentionally declare zero graph action." The validator's current check (populated userSupportedMeaning + empty mutations → REJECT) treats model silence as error rather than accepting intentional no-op.
|
||||
|
||||
**Part 2 — Minimum distinction:** `MUTATION REQUIRED` vs `NO MUTATION REQUIRED`. Reuse/refine existing, add new unknown, resolve existing, other structural mutation are all DERIVABLE FROM PROPOSAL SHAPE (validator checks each independently). Only "no structural change" MUST BE DECLARED because empty arrays alone cannot distinguish intent from omission.
|
||||
|
||||
**Part 3 — Three designs evaluated:**
|
||||
- **Option A (boolean):** Prevents no-op = PARTIAL, checks mutation = YES, schema concept = BOOLEAN, validator complexity = LOW, model-compliance risk = MEDIUM
|
||||
- **Option B (enum):** Prevents no-op = PARTIAL, checks mutation = YES, schema concept = SMALL ENUM, validator complexity = MEDIUM, model-compliance risk = MEDIUM-HIGH
|
||||
- **Option C (existing fields only):** Prevents no-op = PARTIAL, but accepts every noncompliant zero-mutation output silently — HIGH model-compliance risk
|
||||
|
||||
**Part 4 — No-change case:** YES with new structured declaration. Model sets `structuralActionRequired = false` + empty mutations → validation PASSES by checking actual empty state. Model sets `true` + empty → REJECTS (contradiction). Without the field, intent is unverifiable.
|
||||
|
||||
**Part 5 — Relationship to supportCategory:** INDEPENDENT. `supportCategory = "uncertain"` does NOT mean `add new unknown`. Same category can map to different actions depending on graph state (v0.21 identity rule: reuse existing equivalent).
|
||||
|
||||
**Part 6 — Deterministic invariants:**
|
||||
1. `structuralActionRequired = true` + empty mutations → REJECT
|
||||
2. `structuralActionRequired = false` + meaningful mutation → ACCEPT with diagnostic note
|
||||
3. Missing field + populated userSupportedMeaning → REJECT
|
||||
4. `false` + empty mutations → PASS (valid "semantic agreement, no structural change")
|
||||
|
||||
**Part 7 — 57J.63 walkthrough:**
|
||||
- Case A (successful): declares `true`, addedNodes non-empty → PASS by shape comparison
|
||||
- Case B (no-op): declares `false`, empty arrays → PASS by explicit declaration + confirmed zero mutation
|
||||
|
||||
This is ACTUAL CONTRACT ENFORCEMENT because the validator compares a declared boolean against actual proposal shape — no semantic parsing needed. Noncompliant zero-mutation outputs cannot hide behind empty arrays (they must also declare `true`, which fails validation). Intentional no-ops are valid when equivalent structure exists.
|
||||
|
||||
**Part 8 — Recommendation: B (boolean structural-action contract).** One new nullable boolean field in `answerMeaningSchema`. One validator invariant check during transition: missing field + populated userSupportedMeaning rejected. After transition, the field is the enforcement mechanism.
|
||||
|
||||
**Transition policy: B — missing new field + populated userSupportedMeaning is rejected.** Accepting zero-mutation without the field would make every noncompliant output valid again.
|
||||
|
||||
**Convergence:** Ready for bounded implementation. One boolean field + one invariant check. No new semantic taxonomies, no keyword/synonym logic, provider-agnostic.
|
||||
Reference in New Issue
Block a user