experiment: define semantic action contract placement

2026-08-12 06:23:21 +01:00
parent 9425e7b2d6
commit 51da4b973f
2 changed files with 375 additions and 1 deletions
@@ -1186,4 +1186,46 @@ This is ACTUAL CONTRACT ENFORCEMENT because the validator compares a declared bo

 **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.
+**Convergence:** Ready for bounded implementation. One boolean field + one invariant check. No new semantic taxonomies, no keyword/synonym logic, provider-agnostic.
+
+### Experiment 57J.66 — Where `structuralActionRequired` Belongs and What Contradictions Reject (Read-Only Architecture Decision)
+
+**Classification: READ-ONLY DECISION. NO PRODUCTION CODE CHANGED.**
+
+57J.65 established that the minimum missing declaration is a boolean (`structuralActionRequired`) but recommended placing it inside `answerMeaningSchema`. This experiment re-evaluated that recommendation and resolved four remaining design questions.
+
+**Part 1 — Field placement: TOP-LEVEL (graphUpdateSchema), NOT inside answerMeaning.**
+
+`structuralActionRequired` expresses *graph-mutation intent*, not semantic meaning. It validates against structural arrays (addedNodes, updatedNodes, addedEdges), not meaning fields. Placing it at the proposal level keeps semantic analysis separate from structural action decisions and aligns with where the validator evaluates it. `selectedQuestion` already sits at this level as another structural decision — `structuralActionRequired` is a peer.
+
+**Part 2 — Meaning/action independence:**
+- Meaning populated + true → VALID (extracting meaning AND claiming action needed)
+- Meaning populated + false → VALID (extracting meaning AND deciding no action needed)
+- Meaning null + true → VALID ONLY UNDER SPECIFIC EXISTING CASE (maintenance/cleanup scenarios where structural action is needed without fresh meaning extraction)
+- Meaning null + false → VALID (simplest no-op case)
+
+**Part 3 — Meaningful mutation: REUSE existing definition.** `hasMeaningfulChange` (5 conditions: new nodes, status changes, value changes, added edges, removed edges) directly maps to the boolean. No separate definition needed or desirable.
+
+**Part 4 — Contradiction matrix:**
+- true + mutation → PASS (contract fulfilled)
+- true + no mutation → REJECT (declaration violated)
+- false + no mutation → PASS (intentional no-op)
+- false + mutation → ACCEPT, **advisory** (model declares minimum; going further is useful, not harmful)
+
+The contract semantics are **ADVISORY** — the boolean is a minimum intent declaration, not an exact action spec. Producing more structure than declared does not cause semantic loss or misrepresentation.
+
+**Part 5 — Transition policy: B.** Missing/null + populated userSupportedMeaning → reject. Missing/null + no meaning → retain existing "no meaningful change" behavior. This prevents silent degradation of noncompliant outputs while preserving backward compatibility for existing tests and fixtures.
+
+**Part 6 — Semantic truth boundary:** Deterministic code can verify contract consistency (boolean matches proposal shape) but **cannot prove semantic correctness**. The boolean guarantees explicit declaration + consistency, not that the model made the right semantic judgment. This distinction is fundamental: semantic truth requires re-reading English; contract consistency only checks structured fields against structured arrays.
+
+**Part 7 — false + empty no-op:** ACCEPTED for non-meaning inputs. Architecturally significant: deterministic code trusts the model's structured declaration rather than independently proving correctness. For meaning-populated inputs, intentional no-ops are valid when `structuralActionRequired = false`.
+
+**Part 8 — Prompt obligation: SUFFICIENT.** Two minimum rules suffice: "set true when answer requires graph progress" and "set false only when existing state fully represents user-supported meaning or no progress is justified." No additional principle needed.
+
+**Implementation decision: D — top-level field + advisory false/mutation handling.**
+- New field: `structuralActionRequired` in `graphUpdateSchema`, nullable during transition
+- Nullable during transition: YES (mandatory once prompt adds it and when userSupportedMeaning is populated)
+
+**READY FOR BOUNVED IMPLEMENTATION: YES.** All decisions resolved: field location, strict/advisory semantics, null transition, contradiction matrix. No remaining ambiguity for bounded implementation.
+
+Full record in `docs/experiment-57j66.md`.