Markdown for LLMs
Duty: addressee, goal, window
The source Markdown for this article. Copy it into your assistant or download it as a text file.
# Duty: addressee, goal, window
> Updated 3 October 2026: `concept`, `except_when`, `claim`, `definition … sufficient`, and `default` strength have been removed, together with their special deprecation diagnostic. References below to the former behavior and corpus sources are historical. New source uses `relation`, `unless`, `duty`, a strict rule, and `defeasible`.
## 1. What it is in one sentence
`duty` is a normative position that requires of its addressee
that something be achieved, maintained, or not done within a given window: the author
reaches for it when the source says "is obliged to", "must", "ensures".
A duty always names who owes it, what is owed, and by when: one addressee, one goal, one performance window.
## 2. When to take it and when not to
| Instead | Take when | Selection rule |
|---|---|---|
| `prohibition` | the source says "is prohibited", "is not allowed" | write `prohibition`: it is a `duty` with a forbearance goal spelled the way the act speaks; do not duplicate it with a paired `maintenance` duty — you get two `VIOLATED` for one breach |
| `constraint` | a whole world must be rejected, not a person addressed | a `constraint` has neither an addressee nor a performance window; a duty always names its addressee |
| `rule strict` with an institutional head | a status is derived ("is deemed to have defaulted"), not behaviour required | a fact-head has no position lifecycle |
| `claim` | a claim "creditor against debtor" is to be recorded | avoid `claim`: write `duty` with the parties directly — the debtor in the `bearer` field, the creditor in the `beneficiary` field |
Three goal kinds: `achievement` (achieve the condition inside the window),
`maintenance` (hold the condition over the whole window), `forbearance` (not
to perform the action in the window; almost always written as `prohibition`).
A fourth kind, `recurring every`, is executable in 0.2 (E-0146); mandatory `over` gives the overall repetition interval.
## Grammar: duty, goals, norm head (EBNF verbatim from the language grammar)
The `duty` form — the addressee (bearer), the beneficiary, and a single goal:
```ebnf
duty_conclusion = "duty", [ identifier ], "{",
{ duty_item },
"}" ;
duty_item = "bearer", expression, ";"
| "beneficiary", expression, ";"
| "goal", goal, [ ";" ]
| compact_duty_goal
| "activation", formula, ";"
| "discharge_policy", reference, ";"
| "violation_policy", reference, ";"
| source_anchor_item
| metadata_item ;
```
The three base forms follow; `recurring every <step> { … } over <interval>` is executable in 0.2 (E-0146).
```ebnf
achievement_goal = "achievement", "{",
"condition", formula, ";",
"window", interval_expression, ";",
{ goal_item },
"}" ;
maintenance_goal = "maintenance", "{",
"condition", formula, ";",
"window", interval_expression, ";",
{ goal_item },
"}" ;
forbearance_goal = "forbearance", "{",
"action", expression, ";",
"window", interval_expression, ";",
{ goal_item },
"}" ;
```
The norm head — any modality with an optional template StableId annotation. A claim is written as `duty` with the parties directly — the debtor in the `bearer` field, the creditor in the `beneficiary` field:
```ebnf
norm_conclusion = { annotation },
( duty_conclusion
| liberty_conclusion
| power_conclusion
| immunity_conclusion
| prohibition_conclusion ) ;
```
Position statuses and lifecycle live on the [lifecycle page](/constructs/lifecycle-statuses/); windows as intervals and their computation — on the [deadline-calendar page](/constructs/deadline-calendar/); window syntax is not duplicated here.
## 3. Minimal example
Package `examples/duty-achievement/`: a supplier must deliver goods in
March 2026. Full code — `examples/duty-achievement/package.law`; cases and
expectations — `examples/duty-achievement/tests/01-in-window.lawtest` (scenarios
in the window) and `tests/02-after-window.lawtest` (scenarios after the window).
```law
rule DeliveryRule defeasible {
for s: Supplier;
for c: Customer;
when contract_signed(s, c);
then duty Deliver {
bearer s;
beneficiary c;
goal achievement {
condition goods_delivered(s, c);
window [@2026-03-01, @2026-03-31];
}
};
}
```
Case facts: `contract_signed(alpha, omega)`. Query `positions()`.
The engine's actual answer (see [How the engine answers](#5-how-the-engine-answers)):
- `legal_time @2026-03-15`, no delivery → `position(Deliver, ACTIVE)`,
not `VIOLATED` (before the deadline an unperformed duty is active);
- same date + `goods_delivered` → `position(Deliver, SATISFIED)`;
- `legal_time @2026-04-10`, with no facts of non-performance →
`position(Deliver, UNDETERMINED)`, not `VIOLATED` (absence
of proof of performance is not a breach);
- same date + `not goods_delivered` → `position(Deliver, VIOLATED)`.
Sensitivity check: remove `contract_signed` from the case — position
`Deliver` is never created (no body substitution); remove
`goods_delivered` from the second scenario — the answer changes from
`SATISFIED` to `ACTIVE`. The example is not vacuous.
## 4. Example across domains
The same "duty with a window" device in different domains:
- **Law:** the duty to insure cargo — `examples/duty-maintenance/`
(`KeepInsured`, `maintenance` with a March window; the counterexample
`not goods_insured` gives `VIOLATED` immediately).
- **Law:** the ban on subcontracting — the same package (`NoSubcontracting`;
`prohibition` reads as a `duty` with a forbearance goal; the fact
`subcontracts` in the window gives one `VIOLATED`).
- **Standard/protocol:** the duty to keep a unit ready
(package `us.army.training` — US Army training norms, `UnitTrainingReadiness` —
military training in the same `duty` form outside civil law).
- **Religion/ethics:** the duty to respect all religions
(package `mng.corpus.yasa` — the Mongol Yasa, `RespectAllReligions` —
the same construct for an ethical norm).
- **Custom/casework:** court duties in banking disputes
(package `kz.corpus.np_bank_loan_disputes` — Kazakh banking-dispute casework —
five duties with a `[den, infinity)` window).
Forms in detail — `corpus-forms.md`.
## 5. How the engine answers
Run output (verbatim):
```text
check OK: docs/research/constructs/10-duty/examples/duty-achievement
law test research.constructs.duty_achievement: мир research.constructs.duty_achievement
ok [research.constructs.duty_achievement#authored] tests/01-in-window.lawtest / in window without delivery — ACTIVE not VIOLATED
ok [research.constructs.duty_achievement#authored] tests/01-in-window.lawtest / delivery inside window — SATISFIED
ok [research.constructs.duty_achievement#authored] tests/02-after-window.lawtest / after window without explicit non-performance — UNDETERMINED
ok [research.constructs.duty_achievement#authored] tests/02-after-window.lawtest / after window with established non-performance — VIOLATED
итого: 4 проверено, 4 прошли, 0 не прошли, 0 не исполнены; код 0
```
```text
check OK: docs/research/constructs/10-duty/examples/duty-maintenance
law test research.constructs.duty_maintenance: мир research.constructs.duty_maintenance
ok [research.constructs.duty_maintenance#authored] tests/01-violations.lawtest / counterexample inside window violates maintenance
ok [research.constructs.duty_maintenance#authored] tests/01-violations.lawtest / established action inside window violates prohibition once
ok [research.constructs.duty_maintenance#authored] tests/02-excuse.lawtest / force majeure defeats the excusable duty
ok [research.constructs.duty_maintenance#authored] tests/02-excuse.lawtest / without force majeure the duty stays active
итого: 4 проверено, 4 прошли, 0 не прошли, 0 не исполнены; код 0
```
Position statuses: `PENDING` (before the window), `ACTIVE` (in the window,
unperformed), `SATISFIED`, `VIOLATED`, `UNDETERMINED`, `DEFEATED`
(defeated by a defeater — status literals are not published),
`EXPIRED`/`CREATED` for liberties. Observation in a test — `position(Name,
STATUS)`; the `normative_status` aggregate over several norms
answers `UNDETERMINED`. In `proof` — the support of the applying rule and the support
of the goal condition; `why_not` names the unestablished conjunct.
A window from case variables (tests "case window: ACTIVE before the deadline" and "case window: VIOLATED after the deadline with non-payment"):
| Facts | Question | Answer | Why |
|---|---|---|---|
| `invoice_issued(…, 5 March, 15 March)` | `Pay` with decision on 10 March | `ACTIVE` | window from rule variables, deadline not passed |
| same + `not paid` | `Pay` with decision on 20 March | `VIOLATED` | window closed, non-performance established |
## 6. Common mistakes
1. The goal condition repeats the rule body — the duty is always `SATISFIED`
(tautological goal; warning `LDC-E1371`).
2. Two `goal`s in one duty — rejection `LDC-E0201`.
3. A prohibition + a paired `maintenance` duty — two `VIOLATED` for one
breach.
4. A bare name as a window bound — rejection `LDC-E2115`; write a date,
a body variable, or the open floor `[@0001-01-01, infinity)`.
5. `unless` on a norm-head binds not all payload variables —
rejection `LDC-E4101` on node `<Rule>/unless/N`.
6. Rule name coincides with position name — `LDC-E1338`.
7. `condition` with `_` — `check` stays silent, execution never finds the literal
(a known open gap; see `pitfalls.md`).
Each analysed — `pitfalls.md`.
## 7. References
- The language specification defines positions, goals, neighbouring forms, the lifecycle,
defeat, the `positions` query, and test observations; this page states how to use them.
- Tutorials: `/tutorials/writing-tests/` (test observations), `/tutorials/defeaters/` (defeater versus priority).
- Details: `corpus-forms.md`, `pitfalls.md`, `boundaries.md`.