# Часть XVIII. Norm lifecycle, fulfillment и violation

## 134. PositionInstance statuses

Statuses не являются mutable enum. Они являются temporal institutional literals:

```text
created(position)
active(position)
satisfied(position)
violated(position)
...
```

и получают обычные `TRUE_ONLY / FALSE_ONLY / BOTH / NEITHER` support states.

Стандартные Duty status kinds:

```text
created
pending
active
satisfied
violated
waived
suspended
terminated
expired
```

Power/liberty/immunity status kinds (errata E-0239 сужает прежнюю таблицу):

```text
created
active
suspended
terminated
expired
```

Лестница одна на все три модальности: `active` отвечает и за окно доступности
власти/свободы/иммунитета, `suspended`/`terminated`/`expired` — за её
приостановку, прекращение и истечение по §135–§138, как у duty.

**Действительность осуществления §127 — свойство события, а не статус
позиции (errata E-0239).** Прежняя редакция называла `available`,
`exercised`, `validly_exercised`, `invalidly_exercised` отдельными Power
status kinds; ни одна реализация их так не производит, и не может: одна и та
же `active`-позиция власти осуществляется exercise-событием (§127) любое
число раз — ни разу, один раз, повторно, — и каждая попытка валидна или
невалидна САМА ПО СЕБЕ, независимо от соседних. Один статусный литерал ОДНОЙ
позиции такую множественность не выражает, и лестница §134 её не берёт: она
остаётся про жизнь позиции (§135 Activation), а не про исход конкретной
попытки. Исход попытки читается двумя наблюдениями за самим событием, не за
позицией:

- невалидная попытка (valid_when не выдержан, §127) публикует в store
  std-литерал `invalidly_exercised(position)` (канал `materialize_effects`,
  §143.1) и issue `POWER_INVALID_EXERCISE` (severity `info`); эффект не
  материализуется, событие остаётся установленным;
- валидная попытка молча материализует legal effect; симметричного
  литерала-подтверждения `validly_exercised(position)` 0.2 не несёт —
  наступление effect само есть наблюдаемый исход.

Образец наблюдения (`.lawtest`, §267.4):

```text
evaluate positions();
expect position(<PowerTemplate>, ACTIVE);

evaluate truth(<эффект-литерал-полномочия>(...));
expect truth_status == NEITHER;
expect issue(POWER_INVALID_EXERCISE);

evaluate truth(invalidly_exercised(<position>));
expect truth_status == TRUE_ONLY;
```

Значения `AVAILABLE`, `EXERCISED`, `VALIDLY_EXERCISED`, `INVALIDLY_EXERCISED`
перечня `NormativeStatus` (схема `evaluation.schema.json`) этой правкой не
удалены — они остаются ЗАРЕЗЕРВИРОВАНЫ синтаксисом (`position(T, S)` §267.4
их принимает), но ни одна реализация 0.2 их не производит: положительное
ожидание такого статуса в тесте проходит вакуумно, а не «держится» (§267.4).

API summary `normative_status` принимает перечисленные значения плюс:

```text
UNDETERMINED
CONFLICTED
DEFEATED
```

`CONFLICTED` возвращается, когда для одного evaluation instant установлены несовместимые status literals (например, `satisfied` и `violated`) либо релевантный status literal сам имеет `BOTH`. Result ДОЛЖЕН дополнительно содержать `normative_status_supports` с status kind, truth status, valid interval и proof refs; summary никогда не уничтожает исходную поддержку.

### 134.1. `DEFEATED` — позиция, чьё производящее применение побеждено

`DEFEATED` возвращается, когда КАЖДОЕ ground application, выводившее позицию,
побеждено по §107 — например, порождённым клаузой `unless` дефитером (§149) с
норм-головой. Значение отличается от остальных по природе, и различие
существенно: `pending`, `active`, `satisfied`, `violated`, `expired` описывают
жизнь позиции, которая ЕСТЬ право; `DEFEATED` говорит, что позиция правом не
стала.

Отсюда два требования, и второе не выводится из первого:

1. **Позиция видна и адресуема.** Она присутствует в `positions` результата с
   `status: DEFEATED`, несёт свой payload и `createdBy`, а proof graph
   показывает победившее application (§109 требует именно этого: «proof graph
   показывает, какие именно applications были побеждены»). Скрыть её значило
   бы отвечать «нормы нет» там, где норма написана и изъята, — а это разные
   ответы, и различить их обязан уметь тот, кто спрашивает.

2. **У побеждённой позиции НЕ публикуется ничего** (§140) — ни статусный
   literal, ни связочный (`instance_of`, `bearer_of`, `beneficiary_of`).
   Публикация есть то, чем позиция становится доступна обычным правилам
   следующей итерации (§143), и дать её выводу без выжившего кандидата значило
   бы обойти §108 через презентационный слой: у вывода без выжившего кандидата
   нет accepted support. Побеждённая позиция видна в ответе и не участвует в
   выводе; `normative_status` по ней возвращает `DEFEATED`, а не `NEITHER`.

`DEFEATED` не является status kind ни одной модальности: он не перечислен ни
среди duty kinds, ни среди power kinds, потому что относится не к жизненному
циклу позиции, а к её ОСНОВАНИЮ. По той же причине его нет в
`statusHistory`: перехода в него не существует — позиция такой создаётся.

## 135. Activation

Position становится `active`, когда:

1. creating rule application accepted;
2. activation condition/event установлены;
3. context/time scope удовлетворены;
4. position не blocked higher-priority position/effect.

### 135.1. Активация событием (DECISION-0156)

Пункт 2 §135 называет два разных основания одним словом: «activation
condition/event установлены». Условие исполнялось (`DutyPayload.activation` —
формула, §123 и схема), СОБЫТИЕ не исполнялось ни одной реализацией
(`norm_lifecycle`, DECISION-0003: «activation events — вне среза»), и разница
между ними не оформление, а время: условие спрашивает «истинно ли сейчас»,
событие — «когда именно».

Формула активации читает событие ТЕРМОМ — своей третьей позицией у предиката
профиля §164.1 либо любым другим отношением, несущим событие:

```text
then duty FileReport {
    bearer operator;
    activation entered_state(project, UnderReview, e);
    goal achievement {
        condition report_filed(project);
        window [e.time.start, add_business_days(e.time.start, 10 calendar_day)];
    }
};
```

*Блок остаётся `text` и после S3 (DECISION-0156): он есть фрагмент тела
правила, а не декларация верхнего уровня, и компилятор его не разбирает —
причина не стадийная. Целиком та же норма, разобранная компилятором, стоит
вектором `EVT-ACT-WINDOW-FROM-EVENT`.*

Нормативно:

- позиция становится `ACTIVE` С НАЧАЛА канонического интервала `time`
  события-носителя, а не с `legal_time` дела и не с момента, когда факт попал
  в дело. Носитель связывается с bearer и предметом самой формулой активации:
  переменная события связывается ею и видна окну цели;
- **экземпляры позиции существуют по НОСИТЕЛЯМ.** Если формула активации
  связывает переменную события, экземпляр позиции создаётся один на носителя, и
  носитель входит в его runtime instance ID §133 (`activation_event`). До
  ПЕРВОГО носителя экземпляра нет вовсе — не потому, что его прячут, а потому,
  что его нечем построить: без носителя у позиции нет ни идентичности §133, ни
  начала окна цели. Применение правила при этом не пропадает и молчаливым не
  становится: оно видно в proof-графе обычным узлом `rule_application` §180, и
  ответ «правило применилось, позиция ещё не имеет носителя» отличим от ответа
  «правило не применялось». `PENDING` (обязанность, запрет) либо `CREATED`
  (полномочие, иммунитет, свобода) у такого экземпляра означает: носитель есть,
  но момент «по состоянию на» раньше `e.time.start`. Начало носителя есть
  САМОСТОЯТЕЛЬНАЯ граница активации, а не частный случай начала окна: до
  `e.time.start` позиция держит эти статусы ДАЖЕ ТОГДА, когда окно цели §138
  уже открыто. Окно называет срок исполнения, носитель — момент, с которого
  норма вообще связала это лицо, и смешивать их значило бы объявлять
  обязанность активной до события, её породившего. Формула активации, НЕ
  связывающая события, ведёт себя как прежде: позиция создаётся сразу, видна и
  адресуема до наступления условия, и находится в той же тройке статусов §134,
  что и до открытия окна §135 п. 3;
- **переменная события есть СВЯЗЫВАТЕЛЬ АКТИВАЦИИ.** Переменная, встречающаяся
  в правиле ТОЛЬКО в формуле `activation`, связывается этой формулой при
  создании экземпляров позиции, и правило range-restriction §190 на неё НЕ
  распространяется. Основание прямое: §190 требует, чтобы всякая переменная
  головы была связана положительным литералом ТЕЛА, а формула активации есть
  часть головы — payload нормативного шаблона §123, — и до 05.09.2026 такой
  переменной в языке не существовало вовсе. Требовать её связывания телом
  значило бы заставлять автора повторять посылку `entered_state(x, S, e)`
  дважды: в теле, чтобы связать `e`, и в активации, чтобы указать носителя, —
  причём чтение из тела шло бы ВЫШЕ свёртки, а чтение из активации внутрь неё,
  то есть два одинаковых с виду литерала означали бы разное. В CLIR такая
  переменная объявлена в `variables` правила наравне с прочими (§201) и
  связывается формулой активации; проверка §190 её пропускает, а не
  «разрешает исключением». То же и в теле `recurring` §124.4.1, где формула
  активации связывает пару «носитель, вхождение»;
- **связыватель активации в правиле РОВНО ОДИН.** Формула активации связывает
  НЕ БОЛЕЕ ОДНОЙ переменной типа события §79; две и более — статический отказ
  `LDC-E1350` (DECISION-0156, развилка F14). Основание — идентичность
  экземпляра §133: носитель входит в runtime instance ID полем
  `activation_event`, поле это ОДНО, и при двух связывателях у позиции не было
  бы ни единственного носителя, ни единственного начала окна цели
  `[e.time.start, …]`; выбирать между двумя моментами пришлось бы движку —
  молча и за автора. Считаются именно связыватели: переменная события,
  встречающаяся в правиле ТОЛЬКО в формуле `activation`. Переменная события,
  связанная положительным литералом ТЕЛА, связывателем не является, под §190
  подпадает как всякая обычная переменная и числом не ограничена. Норма,
  соединяющая два события («обязанность возникает после подписания И
  вручения»), пишется поэтому ОДНИМ носителем и УСЛОВИЕМ на второе событие:
  носителем берётся то событие, от которого норма отсчитывает срок, а второе
  входит сравнением времён — `delivered(x, e)` в активации при
  `signed(x, e2) and e2.time.start < e.time.start` в теле, либо тем же
  сравнением внутри самой формулы активации, если `e2` связана телом. Позиция
  при этом одна, и `activationEvent` у неё — вручение, а не подписание;
- окно цели §124 отсчитывается от `e.time.start` обычными термами §84 и §86 —
  `window [e.time.start, …]`. Это та же форма, что `window blast.time` §272
  сквозного примера, только граница берётся полем, а не интервалом целиком;
- **доступ к `time` КАНОНИЧЕН независимо от места связывания.** Канон §79.1
  есть свойство ЗНАЧЕНИЯ события, а не формулы, которая его связала: `e.time`
  читается интервалом и у переменной, связанной формулой активации, и у
  переменной, связанной положительным литералом ТЕЛА правила. По той же
  причине `activation_event` §133 публикуется в обоих случаях: когда формула
  активации событие ЧИТАЕТ, но не связывает (связыватель — тело), носитель
  экземпляра назван ею так же однозначно, и прятать его из id значило бы
  ставить идентичность позиции в зависимость от того, в какой половине правила
  автор написал посылку;
- **границы окна сравниваются ЗНАЧЕНИЯМИ, а не строками записи.** `Instant`
  есть МОМЕНТ (E-0048): `2026-03-02T09:00:00+05:00` и `2026-03-02T04:00:00Z`
  суть одно и то же время, а лексикографический порядок их записей произволен.
  `Date` против `Instant` сравнивается через политику §82.1 (`b(D)`),
  `Date` против `Date` — лексикографически, и политика при этом не
  спрашивается (§82.1: отказ поднимается только при потребности). Открытость
  ОБЕИХ границ окна читается: у `[start, end)` последний момент в окно не
  входит, и ровно в него окно уже закрыто;
- формула активации, не связывающая ни одного события, остаётся обычным
  условием §123: активация условием не отменена и не заменена;
- **носителя без времени в системе нет.** Всякое значение-событие §79.1 несёт
  обязательное `time`, поэтому `e.time.start` в окне цели читается всегда.
  Начальное вхождение процедуры носителя не имеет вовсе и живёт отдельным
  предикатом `initial_state(x, S)` арности два (§161.1, §164.1): формула
  активации `entered_state(x, Draft, e)` его НЕ связывает и окном
  `[e.time.start, …]` не захватывает. Обязанность «отчитаться в течение 10 дней
  после ВОЗВРАТА в `Draft`» поэтому и означает возврат: начальное состояние в
  неё не попадает, а окно отсчитывается от момента, который у носителя есть.
  Автор, которому нужно «прошло через `Draft` в том числе изначально», пишет
  `initial_state(x, Draft) or entered_state(x, Draft, e)` явно — и сам решает,
  откуда берётся начало окна.

**Момент «по состоянию на»: право и «сейчас» — разные вопросы, и оси у них
разные (errata E-0212).** `legal_time` §82 отвечает на вопрос «КАКОЕ ПРАВО
ДЕЙСТВУЕТ»: им выбираются редакции §92, окна
`effective` §87 правил и ограничений, значения параметров во времени.
Статусы §134–§138 спрашивают другое — «НАСТУПИЛ ЛИ СРОК, истёк ли он,
исполнено ли обязательство», — и это вопрос на момент вынесения результата,
для которого §82 держит собственную ось `decision_time`. До errata E-0212 обе
величины были одной: момент «по состоянию на» брался у `legal_time`, и дело,
закрепившее право на одну дату, а решение выносящее на другую, получало
статус «на дату права» там, где норма говорит о дате решения. Спросить «право
по состоянию на L, а статус обязанности — на D» было нельзя вовсе.

Нормативно:

- моментом «по состоянию на» для статусов §134–§138 служит `decision_time`,
  когда дело его НАЗВАЛО; иначе — `legal_time`. `legal_time` сохраняет свою
  работу целиком: выбор действующего права от этой правки не зависит;
- `decision_time`, дозаполненный техническим умолчанием (§5.1, issue
  `CONTEXT_FIELD_DEFAULTED`), названным НЕ является: дело о нём ничего не
  сказало, а отвечать за него константой значило бы дать ответ о праве по
  величине, которой в деле нет;
- ГРАНУЛЯРНОСТЬ момента остаётся гранулярностью `legal_time`, потому что
  гранулярность есть заявление ДЕЛА о том, с какой точностью оно спрашивает
  (абзац об `AMBIGUOUS_AS_OF` ниже). При `legal_time` типа `Date` моментом
  служит КАЛЕНДАРНАЯ ДАТА `decision_time`, при `Instant` — сам
  `decision_time`;
- календарная дата `decision_time` читается полем записи — в том смещении, в
  котором ось записана делом, — и политика §82.1 при этом НЕ спрашивается:
  дата с мгновением здесь не сравнивается, а это единственная потребность,
  поднимающая отказ §82.1. Цена названа прямо: дело, записавшее решение органа
  из `+05:00` мгновением с `Z`, получит дату UTC; дело пишет то смещение,
  которое имеет в виду;
- семантика 0.1 заморожена (§240): в ней моментом «по состоянию на» остаётся
  `legal_time`. Документ, у которого `decision_time` не назван либо его дата
  совпадает с `legal_time`, байтово тот же, что и до errata, в любой версии.

Ось `knowledge_time` §82 этой правкой не затронута: она остаётся cutoff-ом
известных системе данных и о сроке не говорит ничего. Календарные вопросы
§86 (`deadline`, `add_business_days` и прочие) берут дату из САМОГО вопроса и
ни одной оси контекста для неё не читают — их эта правка не касается тоже.

**Дальше в этом параграфе «момент «по состоянию на»» означает величину,
выбранную выше, а не `legal_time`.** Позиция активируется мгновением
`e.time.start`. Когда этот момент записан `Date`, две величины разной
гранулярности, и без правила ответ зависел бы от того, какое мгновение внутри
суток выбрал движок: событие в 09:00 того же дня даёт `PENDING` в начале суток
и `ACTIVE` в конце.

Нормативно:

- при моменте «по состоянию на» типа `Instant` им служит САМ этот
  момент; правило ниже не применяется вовсе;
- при моменте «по состоянию на» типа `Date D` рассматриваются гражданские сутки
  `[b(D), b(D + 1 calendar_day))` политики §82.1. Если РЕЛЕВАНТНЫЙ статус
  позиции §134–§138 не меняется НИ В ОДНОЙ точке этих суток, ответом служит
  этот статус: спрашивать, какое мгновение выбрано, незачем — ответ один на
  все;
- если релевантный статус позиции внутри тех же суток МЕНЯЕТСЯ — событие
  активации, истечение окна §138, `left_state`, снятие или прекращение
  позиции, — документ получает `AMBIGUOUS_AS_OF` (severity `fatal`, область —
  документ). Ответа на дату не существует, и выдумывать его запрещено.

**Как это проверяется.** Релевантный статус кусочно постоянен и меняется
только в точках, которые его и определяют. Множество таких точек закрыто:
начало канонического интервала `time` носителя активации §79.1; обе границы
окна цели §138; обе границы `payload.window` §127/§128 у полномочия,
иммунитета и свободы. Проверка состоит в вычислении лестницы §134 в начале
суток `b(D)` и в КАЖДОЙ из этих точек, попавшей строго внутрь суток (у
границы, включённой в интервал, — в ней самой и в следующем за ней моменте:
статус за такой границей меняется ПОСЛЕ неё, а не в ней). Совпали все
значения — ответ на дату определён и равен им; разошлись — `AMBIGUOUS_AS_OF`.

Отсюда два следствия, названные явно. Первое: наличие границы внутри суток
отказом НЕ является — обязанность, исполненная в 10:00 при сроке 18:00,
`SATISFIED` и утром, и вечером, и гасить документ не за что. Второе: проверка
относится к СТАТУСУ, а не к позициям с носителем — свобода §125, чьё
`payload.window` закрывается в 15:00, ответа на дату не имеет так же, как
полномочие с событием.

Отказ поднимается только при РЕАЛЬНОЙ смене статуса, а не при всяком событии
дня: событие, которое статуса позиции не меняет (чужая процедура, попытка, не
породившая эффекта, факт, к позиции не относящийся), молчит. Разные статусы,
державшиеся в разные моменты суток, НЕ смешиваются в `CONFLICTED` §134:
конфликт есть свойство права в один момент, а здесь моментов два, и объявлять
их конфликтом значило бы называть противоречием обычное течение времени.

Основание выбора — контрпример, который иначе неисправим: полномочие активно с
утра и прекращено в 15:00 того же дня. Конец суток отвечает «прекращено» и
теряет утро; начало суток отвечает «ещё не возникло» и теряет вечер; оба ответа
о дне, в который позиция и возникла, и прекратилась, ложны наполовину и не
показывают этого. Отвергнутые здесь варианты — конец гражданских суток
`b(D + 1 calendar_day)` исключительно («на такое-то число» читалось бы как
итог дня, но утро исчезало бы молча) и начало суток `b(D)` (ответ «ещё не
активна» о событии того же дня читается как ошибка).

Отказ этот — не мелочь исполнения, а требование к ДЕЛУ: `legal_time`,
записанная датой, есть заявка, что внутри суток ничего не менялось. Когда
менялось, дело обязано назвать момент — `legal_time` мгновением, — и текст
кода говорит об этом прямо (§5 DECISION-0156). Требование адресовано именно
`legal_time` и после E-0212: гранулярность момента «по состоянию на» задаёт
она, и `legal_time`, записанная мгновением, переводит в мгновение и ответ о
статусе — им становится сам `decision_time`.

Если событие активации есть носитель перехода, свёртка §161.1 уже упорядочила
его; позиция создаётся один раз на носителя, а повторный вход в состояние
(§161.1) даёт ВТОРУЮ позицию с другим носителем — как и должно быть: вторая
проверка порождает вторую обязанность отчитаться, а не продлевает первую.

## 136. Achievement satisfaction

Achievement duty `satisfied`, если accepted support подтверждает condition в window.

Она `violated`, если:

1. window закрыто;
2. satisfaction не установлено;
3. explicit non-performance, completeness certificate или adjudication позволяет установить отсутствие достижения;
4. duty не waived/suspended/terminated.

Без пункта 3 статус `undetermined`, а не `violated`.

## 137. Maintenance satisfaction

Maintenance duty `violated`, если существует accepted counterexample в window.

Она `satisfied`, если:

- имеется complete monitoring certificate; либо
- applicable closure policy охватывает весь window; либо
- binding adjudication устанавливает compliance.

Иначе после окончания window возможен `undetermined`.

## 138. Deadline

До due time невыполненная achievement duty обычно `active`, не `violated`. Jurisdiction profile может определить anticipatory breach как отдельное правило.

## 139. Waiver, suspension, termination

Они создаются обычными constitutive/normative rules и должны иметь source, scope и time. Status derivations append-only внутри EvaluationInputManifest; history не перезаписывается. Новые evidence/source snapshots создают новый manifest/result. Correction связывается `was_revision_of`/`invalidates`, но старый auditable result остаётся воспроизводимым.

## 140. Violation

Violation является derived institutional fact о position instance:

```text
violated(POSITION_INSTANCE_17)
```

Нарушение не является логическим конфликтом и не возникает только из наличия противоположной нормы.

## 141. Reparation

```law
rule RepairDamage defeasible {
    for v: Violation;
    when violation_of(v, SafetyDuty)
      and caused_damage(v, damage);

    then duty RepairDuty {
        bearer violator(v);
        beneficiary victim(damage);
        goal achievement {
            condition compensated(victim(damage), amount(damage));
            window [decision_time(v), reparation_due(v)];
        }
    };
}
```

## 142. Sanction

Sanction моделируется новым norm/effect rule, triggered установленным violation. Range, mitigation и aggravation являются typed calculations/rules, а не специальной магией evaluator-а.

## 143. Chains

```text
primary duty -> violation -> reparative duty
reparative duty -> violation -> sanction duty/effect
```

Каждый шаг имеет отдельный rule application и proof node.

### 143.1. Шаг через эффект полномочия и нумерация позиций

Шаг цепочки не обязан быть нарушением. Эффект валидно осуществлённого
полномочия (§127, шаг 2) создаёт institutional-факт; тот входит в strict
least fixed point (§111, шаг 1) и в тела правил следующего шага — в том
числе ТОГО ЖЕ правила с норм-головой на новой подстановке. Так записывается
субделегирование: обладатель роли передаёт её, получатель становится
обладателем и сам получает полномочие передать. Это не цикл §110: рёбра §110
связывают правила через предикаты тел и голов, а эффект полномочия головой
правила не является — его материализация есть отдельный шаг runtime §127,
повторяемый до фикспойнта в пределах `maxNormChainDepth` (§238). Compiler
такую программу не отклоняет; исчерпание глубины — `RESOURCE_LIMIT` до
вывода, а не частичный ответ.

Позиции append-only (§139): одно ground-применение правила с норм-головой
создаёт позицию один раз, на каком бы шаге оно ни встретилось повторно
(ключ идемпотентности — сматченные посылки, DECISION-0017 §8). Новое
ground-применение на позднем шаге создаёт НОВУЮ позицию и новый узел
`norm_creation` (§180). Идентификатор позиции `urn:position:<правило>:<sha256>`
(форма `<правило>` — §180, errata E-0097) адресуется подстановкой применения
(§133, errata E-0247): разные ground-применения одного правила различаются
подстановкой и получают разные id на любом шаге цепочки, а повтор того же
применения на позднем шаге даёт тот же id и новой позиции не создаёт. Счётчика
применений у id нет, и обнулять между шагами нечего: дефект E-0133 (повторный
рабочий id узла `norm_creation` при счётчике, обнуляемом на каждом шаге) этой
формой исключён по построению. Узлы `norm_creation` и эффекта §127 адресуются
содержимым (§180) и называют позицию этим id в `conclusion` и
`attributes.power`. Порядок создания детерминирован: шаги — по возрастанию
глубины, внутри шага правила — по StableId, применения одного правила — в том
же порядке перечисления решений тела, что у `rule_application` §180; на id
позиции порядок больше не влияет.