docs← Back to article

Markdown for LLMs

Human decisions, interpretations and scenarios

The source Markdown for this article. Copy it into your assistant or download it as a text file.

Download this articlePlain text ↗
# 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](/agent-engineering/handle-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:

```text
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](/agent-engineering/task-guides/).

## 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`](/agent-engineering/files/evals/behavior-runs/raw-2026-10-04/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`](/agent-engineering/files/evals/behavior-runs/raw-2026-10-04/sc7-ask-assumed.json)): `COMPUTED`, `NEITHER`, no derivation steps, and one warning per fact:

```text
- Предупреждение `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.

```text
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`](/lawql/lints/interpretation-without-group/).

## Validation record

| 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](/agent-engineering/handle-answers/)
Next: [Follow a task guide](/agent-engineering/task-guides/)