Human decisions, interpretations and scenarios

Some answers do not exist until a human acts. A disputed reading waits for whoever the procedure names to choose it; an evaluative question waits for the authority the canon names to judge it; a what-if question waits for someone to say which inputs are only supposed. The agent prepares each of these and makes none of them. This page shows what each looks like in an answer, what exactly it blocks, and how to keep hypothetical runs apart from the case.

Four kinds of human input

Input	Who gives it	What it settles	How it enters the engine
Case facts	the user or their documents	what happened — accepted as case input, which is not proof of real-world truth	facts with origin case_input
Assumptions	the user, for a what-if	what would follow if an input held	facts with origin assumed_for_simulation, kept in a separate run
Reading choice	whoever the procedure names	which named interpretation applies	selectedInterpretations in the request
Judgment	only the authority the canon names	the evaluative question itself	an adjudicated fact from that authority

The four never substitute for each other. User consent is not the authority’s judgment; a reading choice is not a fact; an assumption is not a finding. Each question goes to its proper subject, and the record shows who answered what.

Named interpretations

Where a provision admits several readings and the canon keeps them, each reading is a named interpretation with a stable identifier. Readings are grouped, and the group states a selection policy:

• exactly_one — the case must select exactly one reading of the group;
• any_of — readings may hold side by side; no selection is forced.

The physics package openstax.second_law_readings (Newton’s second law in two readings: F = ma at constant mass, after OpenStax University Physics, against change of motion, after the Principia) declares an exactly_one group SecondLawReadings with alternatives OpenStaxReading and PrincipiaReading. Its author’s reason: the formulations differ, so “which law are you computing by” is a question to the case, not a package default. By contrast, the CISG formation package intl.uncitral.cisg_formation keeps LastShotReading and KnockOutReading for the battle of forms under any_of: no selection is forced there.

The agent finds readings before asking: law_rules for the predicate lists the applicable readings, and its machine contract mode (contract: true) names the inputs the question needs, so the agent does not reconstruct requirements by reading rules by hand. The request carries the choice:

JSON

// labeled pseudocode: law_ask with a reading selected
{ "kind": "truth", "package": "<package>", "predicate": "<predicate>",
  "args": ["..."], "facts": ["..."], "legalTime": "<date named by the human>",
  "selectedInterpretations": ["<one StableId from law_rules or law_packages>"] }

Status: the selectedInterpretations field and its rule (“for an exactly_one group, select exactly one identifier from law_packages or law_rules”) were read in the published law_ask input schema on 2026-10-04; a live call with a selected reading was not run for this page.

What INTERPRETATION_REQUIRED covers — precisely

When the case does not select exactly one reading of an exactly_one group, the specification gives the status INTERPRETATION_REQUIRED. It is a status of a result, not of the whole evaluation document:

• Only dependent results get it. A truth question depends on the group when its goal predicate lies in the closure, through rule bodies, of the heads produced by the blocked readings (negation, not_known and quantifiers included). A collect question depends on it when any predicate of its comprehension lies in that closure. A positions question depends on it when a blocked reading contains a rule producing a position, or an active producer reads a dependent predicate.
• Independent results are answered normally. A question outside that closure gets COMPUTED and its own truth status: the choice of reading cannot change it, and demanding a choice would answer the wrong question.
• The issue stays in the document. The evaluation document still carries an INTERPRETATION_REQUIRED issue as a fact about the input, even when the result the agent asked for is COMPUTED.
• Precedence. INTERPRETATION_REQUIRED, UNRESOLVED_NORMATIVE_CONFLICT and REQUIRES_JUDGMENT are not masked by a term-computation error in a candidate rule. The full status table and its precedence are in Read answers.

What this means for the agent:

1. Read the status of the result it asked for, not the list of issues in the document. An INTERPRETATION_REQUIRED issue does not by itself void an independent COMPUTED answer.
2. An independent COMPUTED answer does not show that no reading is needed elsewhere in the case. If the issue is present, say in the report that the case leaves a reading open, and name the group.
3. A dependent result with INTERPRETATION_REQUIRED has no outcome to report. The next step is to prepare the choice for the person the procedure names — not to pick a reading, and not to report the truth status as if it were an answer.

A related signal comes from the MCP server: when a truth answer is NEITHER, the why-not report has no blockers, and the only rules that could derive the goal are included by readings the case did not select, the answer carries interpretationGated naming those readings. It means “rules exist, but the reading selection switched them off” — never “the canon has no rule”. (Read in the server source on 2026-10-04.)

Status: the scope rules above are from the specification’s part on interpretations and theories. The openstax package’s committed scenario “no reading chosen” asks the head with the same facts as the passing OpenStax case and expects NEITHER; that scenario does not pin the evaluation status. A live INTERPRETATION_REQUIRED answer is NOT RUN for this page. Reproduction: ask motion_change_accounted_for over openstax.second_law_readings with the scenario’s facts, once without selectedInterpretations (read the result’s evaluationStatus and the document issues), then once per reading.

Compare readings side by side

When readings exist, the agent asks once per candidate and reports every outcome side by side, never only the preferred one. Each entry holds the reading identifier, the full answer under it (call, evaluation and truth axes), and the rules that fired. Results under different readings are never mixed into one answer. The comparison goes to the person named for the choice; the agent does not vote. Where a reading belongs to no group, the record says so: the choice is by bare name, not from a closed list, and the comparison cannot claim completeness.

Authorized judgment

Some relations are judgment channels: the canon delegates an evaluative question (“substantially violated rights”, “without good reason”) to a named authority. Until that authority’s adjudicated fact arrives, the result carries evaluationStatus REQUIRES_JUDGMENT and a typed request in judgmentRequests that names the authority. The specification adds that a request is issued only where the authority’s answer could still change the outcome; a rule already dead on the case names no judge.

The truth axis and the evaluation axis are independent. A committed scenario of the Family Code of the Republic of Uzbekistan (package uz.family_code) shows it: birth in marriage with the husband named derives the paternity presumption as TRUE_ONLY, yet the same result requires judgment, because the exception to the presumption reads the court channel:

Output

evaluate truth(paternity_presumed(...));
expect result_kind == PROPOSITION;
expect truth_status == TRUE_ONLY;
// the exception reads the court channel: without the court's word
// the outcome requires judgment.
expect evaluation_status == REQUIRES_JUDGMENT;

(Comment translated; the file’s own wording is Russian.) Status: fixture, read 2026-10-04; NOT RUN here. Reproduction: run the package’s scenario file for the paternity tests on a local build, or ask the predicate over an MCP profile that serves the package.

A second channel: in the Code of Administrative Offences of the Republic of Kazakhstan (package kz-administrative-code) the Article 507 obstruction relation is declared an external judgment relation whose authority is the adjudicating body; the “substantial violation of rights” assessment arrives only as that body’s word. Status: declaration read 2026-10-04, not executed.

Rules for the agent:

• A required judgment is never performed by the agent and never inferred from case facts, even when the truth axis already leans one way.
• If the user says “take it as substantially violated”, the agent records a case-input claim from the user, not the judgment; the status stays REQUIRES_JUDGMENT until the authority’s adjudicated fact arrives.
• The agent never asks the authority for mere facts, and never asks the user for the authority’s judgment.

When the human decision is about facts

Not every stop is a judgment channel. In the recorded behavior pass of 2026-10-04 (feeding-break question, kz-labour-code), the user’s documents disagreed on the number of children — and the count decides whether the 30-minute or the one-hour minimum applies. The agent read the rules, did not ask the engine, and stopped: it named the decision, the two options (the user says which document controls, or resolves the conflict off-record) and whose decision it was, without assuming a count. That is the shape of every human-decision stop: the decision, the options, the consequence of each, the person — and no invented input.

A chosen parameter that the human fixes on purpose enters as a recorded fact with its origin. In the measurement-uncertainty task guide, the case “k chosen by a person” supplies the coverage factor coverage_factor(..., 2.0) as case_input rather than letting the package pick it. Status: fixture; that branch currently stops on a documented TYPE_ERROR in the combined-uncertainty step, see Follow a task guide.

Scenarios and assumptions

A scenario asks about inputs that may not be true: what if the break lasted twenty minutes, if there were two children, if the application had arrived a day earlier. The engine can compute such questions only when the supposed inputs are kept apart from the case.

Item	Base case	Scenario
Fact set	accepted record facts only	record facts plus marked assumptions
Question	what is established	what would be established if
Stored answer	the case result	a conditional result, never filed as the case result

Mark assumptions at the source

Every fact carries an origin, and the origin decides whether the run mode accepts it. The specification is explicit: assumed_for_simulation must not reach a regulatory result without an explicit simulation mode, and never becomes accepted support automatically.

The worked pair, both via the public MCP endpoint (root route) on 2026-10-04, same question and the same two facts (25 minutes, one child), date of law 2026-09-01:

• Facts marked case_input (raw file sc5-ask-25.json): COMPUTED, TRUE_ONLY, the one-child rule of Article 82 fired.
• The same facts marked assumed_for_simulation (raw file sc7-ask-assumed.json): COMPUTED, NEITHER, no derivation steps, and one warning per fact:

Output

- Предупреждение `ASSERTION_NOT_ACCEPTED`: assertion urn:mcp:case#fact-1 with origin=assumed_for_simulation not accepted by mode=audit policy (SPEC §73) — связанных узлов: 1.
- Предупреждение `ASSERTION_NOT_ACCEPTED`: assertion urn:mcp:case#fact-2 with origin=assumed_for_simulation not accepted by mode=audit policy (SPEC §73) — связанных узлов: 1.

Nothing about the canon changed between the calls; only the provenance of the inputs did. The public server runs in audit mode and refuses simulation-marked facts loudly rather than ignoring them. A NEITHER after such warnings means “the canon had nothing to read”, not “no” and not “the opposite is proven”. As observed, law_ask takes no mode selector, so the accepting side — a simulation mode that takes these facts — is NOT RUN here.

Compare variants without mixing them

When the question is “which variant wins”, give each variant its own pinned input set and compare answers side by side. The native shapes are the counterfactual pair law.core.counterfactual-input/0.1 (a finite set of candidate worlds pinned to a program hash and a case hash, each with its own inputs) and law.core.counterfactual-result/0.1 (the outcome per candidate). Status: schema identifiers read 2026-10-04; a counterfactual run is NOT RUN here.

• One candidate, one input set, one result — never merge results across candidates.
• A rule that does not fire in one variant proves nothing about the opposite in another.
• An empty result is distinct from a zero value and from proven absence; each query defines what its own emptiness means.
• Screening a list of candidates is not completing the check on any of them.

Return to factual inputs

A scenario ends by going back to the pinned base snapshot, never by promoting its assumptions:

1. Pin the base snapshot before the scenario runs: package version, date of law, mode, record facts.
2. Re-ask the same predicate over that snapshot — a fresh call, not the scenario set with rows deleted. In the worked pair both facts were assumptions, so deleting them leaves an empty set, not the record.
3. File only this answer as the case result; keep the scenario answer beside it, labeled with the assumptions it depended on.

If an assumed fact is later confirmed, that is a separate acceptance with its own grounds — a proposal, its evidence, an acceptance — not a promotion of the assumption. The scenario answer stays conditional in history.

Read a positive conditional result

If a simulation run returns TRUE_ONLY, read it as “established, if the assumed inputs held”:

• COMPUTED is not positive: the computation can complete with NEITHER.
• The condition never drops off — not in storage, not in summaries, not when the answer is passed on. A reader who sees TRUE_ONLY without the assumption list will misfile it as found.
• No simulation output replaces a required judgment, and the user’s consent to run the scenario is not the authority’s decision.

Output

base snapshot: pinned record facts (kept for the return)
  -> scenario: base + marked assumptions
    -> ask (conditional result + assumption list)
  -> re-ask over the base snapshot (case result)
  -> store both, each labeled; never one in place of the other

How to verify

Over MCP, repeat the worked pair (each fact first as case_input, then with "provenance": {"origin": "assumed_for_simulation"}) and compare truthStatus and warnings. For the interpretation scope, ask a dependent and an independent predicate of one case without selecting a reading of an exactly_one group, and compare each result’s status with the document issues. Locally, law query --list names the lint interpretation-without-group.

Validation record

Show commands, versions and results

Check	Result
INTERPRETATION_REQUIRED scope, REQUIRES_JUDGMENT request rule, assumed_for_simulation acceptance	Read in the specification 2026-10-04
law_ask schema (selectedInterpretations), law_rules schema (contract)	Read in the server’s tool definitions 2026-10-04
interpretationGated condition	Read in the server source 2026-10-04
openstax exactly_one group and “no reading chosen” scenario; CISG any_of group; Uzbek paternity scenario; Article 507 relation; GUM “k chosen” case	Read 2026-10-04 (fixtures, not run)
case_input vs assumed_for_simulation pair; documents-disagree stop	Ran via public MCP endpoint (root route) 2026-10-04 in the recorded behavior pass
Live INTERPRETATION_REQUIRED, live REQUIRES_JUDGMENT, simulation-mode acceptance, counterfactual run	NOT RUN

Previous: Read answers Next: Follow a task guide