Markdown for LLMs

Interpretation pitfalls

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

# Interpretation pitfalls

Wrong forms, silent outcomes, diagnostics, typical formalizer
mistakes, and how to detect them. "Confirmed by running" items were
reproduced by running the examples.

## 1. `include` brought a rule without its generated nodes (fixed)

Previously `include R` brought one root StableId, while
`R/alt/N`, `R/unless/N` with priority edges, `R/norm/*`, and `R/head/N`
stayed outside every reading: a generated `unless` defeater acted
in all readings at once. Today the whole canonical
expansion comes in. Detection: a defeater firing under a "foreign"
reading.

## 2. A qualified `include` of another's rule

`include pkg::R` is rejected: lowering computes from the declaration,
and the consumer has no neighbour's declaration — an import carries the interface, not
nodes. Silently it would bring one root and leave the generated nodes outside
the reading. Fix:
the owner declares a `pub interpretation` and includes the rule there;
the consumer names the reading in `extends` or in `alternatives`.

## 3. A nested rule with an unbound head (fixed)

Previously the connectedness pass walked only the top level, and
an unbound head inside a reading lived to runtime. Today
a nested rule's connectedness is checked by the same rules and sounds
with the same `LDC-E4101` code, and the diagnostic name is the one
lowering gives (`Reading/Rule`). Detection: `law engine check`.

## 4. A status with no group: a "disputed" reading always applies

`status disputed` alone selects nothing: the selection
policy is set by the jurisdiction profile. A fork with a choice is only
an `interpretation_group`. The corpus pairs above (TR, IR, Yasa) honestly
carry `disputed` TOGETHER with a group — the status describes, the group decides.
The mistake is reading `disputed` as "switched off until the dispute resolves".

## 5. Expecting an answer "under the first" with no choice (confirmed by running)

With `selection exactly_one` and no `interpretation …;` line in the context
a dependent query answers `INTERPRETATION_REQUIRED`, not the first
alternative's answer: the language has no "first/last" order.
Reproduction: `examples/unresolved-group/tests/01-dependent-blocked.lawtest`
(`expect evaluation_status == INTERPRETATION_REQUIRED` — passes).

## 6. An independent query extinguished with the document (fixed)

Previously an unresolved `exactly_one` group extinguished the whole
document. Today an independent truth query gets `COMPUTED` and its
`truthStatus`; the `INTERPRETATION_REQUIRED` issue stays in the document
regardless. Reproduction:
`examples/unresolved-group/tests/02-independent-computed.lawtest`
(`TRUE_ONLY` + `COMPUTED` with no choice). The mistake is demanding a choice from
a query that needs no reading.

## 7. Traps for automated authors

- `exclude` without `extends` removes the wrong thing: `exclude R` removes the same
  expansion that `include R` brings, and stays local
  for the same reason. Excluding from another's reading is written as `extends` with
  an explicit `exclude` visible in provenance (set composition, not
  mutation).
- A cycle across two alternatives of one `exactly_one` group is statically
  unreported — it cannot realize; the same cycle inside one reading
  or through `any_of` is reported. Static silence
  here is the norm, not a gap.
- Silent outcome: `NEITHER` under a selected "foreign" reading is not
  a package defect but a blocked alternative. Check the
  `interpretation …;` line in the case context first.
- `weak_permission` and calendar operations keep the document status:
  no dependence defined for them — never build forks on them.