refine answerMeaning contract around user-supported meaning

2026-08-09 08:50:37 +01:00
parent 869afee1ab
commit 7965375aff
8 changed files with 208 additions and 57 deletions
@@ -116,10 +116,10 @@ The JSON object must contain exactly these top-level fields:
 25. Do not replace the whole graph, and do not restate unchanged graph content inside the proposal.
 26. answerMeaning.userSupportedMeaning must state only what the user's answer directly supports.
 27. Put any stronger interpretation in answerMeaning.possibleInference, not in userSupportedMeaning.
-28. If the answer is only a relative priority statement, use supportCategory=relative_priority_only and resolutionGuidance=must_remain_unresolved.
+28. supportCategory and resolutionGuidance are optional descriptive hints only; if you are unsure of the exact wording, leave them null rather than inventing rigid category labels.
 29. If the answer is conditional or qualified, preserve that qualification explicitly in userSupportedMeaning.
-30. If the answer says the user is unsure or does not resolve the distinction, use supportCategory=uncertain and resolutionGuidance=must_remain_unresolved.
-31. If the answer explicitly states a hard constraint, use supportCategory=explicit_hard_constraint and resolutionGuidance=must_resolve.
+30. If the answer says the user is unsure or does not resolve the distinction, state that uncertainty directly in userSupportedMeaning.
+31. If the answer explicitly states a hard constraint, state that directly in userSupportedMeaning.

 ## Additional Guidance
 - If the answer only clarifies an existing unknown, prefer updatedNodes and resolvedUnknownNodeIds over creating duplicate nodes.