Markdown for LLMs

Choosing a construct

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

# Choosing a construct

## Task and place

After vocabulary fixes what the model talks about, construct choice fixes how each norm behaves: what the machine establishes by itself, what it checks without deriving, and what stays silent. This stage sits before rule drafting and after vocabulary. Every close call it settles goes on a decision record in the next stage.

## Inputs

- The reviewed vocabulary from the previous stage.
- The included inventory rows with their content units.
- The [decision record template](/handbook/files/templates/decision-record.md) for close calls.

## Actions

- Ask the deciding question first: may the system establish this by itself? If the act merely requires things to be so, the answer is a check; if the act makes it so by its word, the answer derives.
- Route each norm through the table below and name the rejected neighbor.
- For close neighbors, write the distinguishing scenario before drafting: the smallest fact set that yields different answers under each candidate.
- Prefer the weaker behavior that still satisfies the act: derive only what the act establishes, and check the rest.

| The act says | Behavior needed | Construct | The machine |
|---|---|---|---|
| this follows, always | establish the conclusion with no exceptions | strict rule | derives |
| this follows, unless excepted | establish the conclusion, removably | defeasible rule with an escape | derives, removably |
| remove support, asserting nothing | block without denying | defeater | silences, never denies |
| this is one who dots, and back | abbreviate with two-way meaning | exact definition | derives and checks the converse |
| sort into a class, with exceptions | qualify defeasibly | defeasible classification | derives, removably |
| with this there must be that | check, derive nothing | constraint | reports, never derives |
| this counts as that | recognize an institutional fact | fiction | derives an institutional fact |
| one value from inputs | compute | function | derives a value |
| inputs route to outputs by rows | route under a hit policy | decision table | derives a value |
| events move a case through states | track a lifecycle | procedure | moves state, derives nothing |
| repeated derivation in rounds | index the derivation | derivation stage | derives per round |

## Decisions

- The construct for each norm, with the rejected neighbor named in the construct map.
- Which close calls need a decision record. In the running example the tariff shape needs one (EAI-D1); the records themselves are written in the next stage.

## Artifact

The artifact is a construct map: each norm paired with its construct and its distinguishing scenario. The scenario pairs below are the map's core; each row is read as same facts, then the one fact that tells the neighbors apart.

| Neighbors | Same facts | Discriminating fact | Outcomes |
|---|---|---|---|
| escape versus denial versus defeater | a resident driver | suspension, or outstanding fines, or a fraud flag | silence, or denied, or support removed without denial |
| exact definition versus defeasible classification | a qualifying senior-parking applicant | a fraud flag | stays established under the definition; returns to neither under the classification plus defeater |
| constraint versus consequence rule | an issued permit with the fee unpaid | the fee fact itself | an issue reported beside the standing fact versus a total derived with nothing reported |
| function versus decision table | a twelve-month application | overlapping rows | one computed value versus the routed row; an overlap complains under the unique policy |
| procedure versus derivation stage | a station in review, an allotment in rounds | a filing event versus the round index | the event moves the case versus round two reading round one |
| plain fact versus admission versus closure | a resident on file | a verified document edge versus register completeness | asked directly versus admitted through conjuncts versus absence-becoming-denial inside the domain |

## Worked example

The running example maps all five touched articles to strict rules (plus two assumed inputs — the insured sum under Article Sixteen and the risk-class attribution under Article Seventeen point 3), since none admits exceptions. The map reads:

| Norm | Construct | Why not the neighbor |
|---|---|---|
| Employer duty, Article Eight | strict rule from employment facts to the institutional duty | no exception in the article; nothing to check without deriving |
| Tariff rows, Article Seventeen | twenty-two strict rules, one per class | each row carries its own source label; recorded as EAI-D1 |
| Premium, Article Seventeen | three strict rules: base as insured sum times rate, then base-or-floor split on one comparison | the amount must be derived; a constraint would check without producing it — recorded as EAI-D4 |
| Payout, Article Nineteen | strict rule with inclusive guards | the bounds are applicability conditions in the body; below thirty the rule stays silent rather than denying |
| Penalty, Article Nine | strict computation rule, unpaid times rate times days | same as the premium: derive, not check |

The class twenty-two premium test and the thirty-versus-twenty-nine payout pair are the distinguishing scenarios made executable: they are the facts that would read differently under the rejected neighbors.

## Pitfall

The costliest mistake is writing a rule where the act needs a check: an issued document that must have a return term, written as a rule, would establish a term nobody assigned. Its mirror is checking where the act establishes: a constraint on the premium would leave the amount underived. When in doubt, return to the deciding question.

## Verification

The stage is done when the suite passes seven of seven and the boundary pair straddles: thirty percent qualifies while twenty-nine does not. Observed run with tool version `law` 0.1.0, semantics law.core/0.2:

```text
law test kz.corpus.employee_accident_insurance: мир kz.corpus.employee_accident_insurance
  ok   [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-EMPLOYER-MUST-INSURE
  ok   [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-MINING-CLASS-22-PREMIUM
  ok   [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-LOSS-THIRTY-QUALIFIES
  ok   [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-LOSS-TWENTY-NINE-IS-NOT-INSURER-PAYOUT
  ok   [kz.corpus.employee_accident_insurance#authored] tests/core.lawtest / EAI-SPECIAL-LATE-PAYMENT-PENALTY
  ok   [kz.corpus.employee_accident_insurance#authored] tests/goals.lawtest / GoalEstablishedCapacityLossHasPayout-world
  ok   [kz.corpus.employee_accident_insurance#authored] tests/goals.lawtest / urn:kz:corpus:clir:employee-accident-insurance#GoalEstablishedCapacityLossHasPayout
итого: 7 проверено, 7 прошли, 0 не прошли, 0 не исполнены; код 0
```

[translation] The header line names the tested world; the summary line reads: seven checked, seven passed, zero failed, zero unexecuted, exit code zero.

Criterion: all seven lines read ok, and the two boundary tests disagree in the expected direction. A construct change that collapses the boundary pair fails here.

## Limits

The machine checks the form of the choice, never its fidelity to the act: a strict rule where the act allows exceptions still passes. Close calls stay author judgment, which is why they need records.

## Next step

Continue with [Recording decisions](/handbook/decisions/), which writes the records for the close calls found here.

## Sources

- [Northbridge course](/tutorials/northbridge/) — the neighbor-construct drills this stage leans on.
- [Definitions and friends](/tutorials/definitions/) — which shapes derive and which only check.
- [Language reference](/constructs/) — syntax and semantics of every construct.
- [Vocabulary first](/handbook/vocabulary/) — the previous stage.