# 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`.