# Часть XVII. Normative positions

## 122. Канонические modalities

Core 0.1 имеет четыре executable modalities:

```text
duty
liberty
power
immunity
```

Они покрывают две оси:

```text
behavior: duty / liberty
legal change: power / immunity
```

Юрисдикция может объявлять дополнительные surface modalities, но executable extension должна явно lowering-оваться в эти четыре либо быть `opaque`.

## 123. Duty

```text
then duty SubmitDeclaration {
    bearer taxpayer;
    beneficiary RevenueAuthority;
    goal achievement {
        condition declaration_submitted(taxpayer, period);
        window [period_end(period), due_date];
    }
};
```

Поля:

```text
bearer: Actor | Collective
beneficiary: Option<Actor | Collective>
goal: Goal
activation: optional condition/event
allocation_policy: individual | joint | several | joint_and_several | custom
discharge_policy: optional policy
violation_policy: optional policy
```

Для нескольких bearers автор обязан указать allocation policy; коллективная обязанность не разворачивается автоматически в индивидуальные обязанности каждого участника.

Поле `activation` принимает и УСЛОВИЕ, и СОБЫТИЕ; исполнимая форма второго —
§135.1. Переменная события, встречающаяся только в формуле `activation`, есть
связыватель активации: она связывается этой формулой, а не телом правила, и
§190 её не требует (§135.1, DECISION-0156).

## 124. Goal types

`achieve F during W;` задаёт цель достижения `F` в окне `W`, а
`maintain F during W;` — цель поддержания `F` в этом окне. Эти краткие
формы в `duty` эквивалентны полным блокам `goal achievement` и
`goal maintenance` с полями `condition F; window W;` (DECISION-0185).

**Составное условие цели (errata E-0218).** `condition` цели `achievement`,
`maintenance` и внутренней цели `recurring` вычисляется как пара опор §62,
а статус позиции есть проекция этой пары по §134–§138. Правило одно для
атома и для составной формулы. Лист условия — литерал: `P` или `not P` (§63
зеркалит стороны). Обёртку `established(P)`, которую понижение ставит по
умолчанию §66, лист читает как пару самого `P`. Boolean-подъём §64.1 здесь
НЕ применяется: иначе `condition not A` при неизвестном `A` давало бы
`FALSE_ONLY`, и обязанность поддержания объявлялась бы нарушенной без
accepted counterexample, которого требует §137. Листья складываются по §64:
`P and Q = (P.t and Q.t, P.f or Q.f)`, `P or Q = (P.t or Q.t, P.f and Q.f)`.
Поэтому `condition not A and not B` имеет `FALSE_ONLY` (контрпример §137),
как только установлен `A` или `B`. Опоры статуса — объединение опор тех
листьев, которые дали соответствующую сторону пары.

Листья иной формы остаются вне исполнимого подмножества, и отказ называется
issue `NON_EXECUTABLE_GOAL`. Это сравнение §64.1, status tests, кроме
`established`, кванторы §52 и временные формулы. Полнота §137 через closure
policy §70 установлена только для условия-атома. У составного условия пути
полноты нет, и после окна без контрпримера статус `UNDETERMINED`: это
консервативный отказ §2.6, а не утверждение об исполнении.

`condition` цели, читающий отношение суждения §47.3, не решается вычислением (errata E-0100): до adjudicated assertion статус позиции остаётся неопределённым ПО ПРИЧИНЕ, и документ обязан назвать её — evaluation status `REQUIRES_JUDGMENT` и типизированный `JudgmentRequest`, как у `valid_when` §127 и тела правила §98. Молчание судьи не читается ни как «условие не выполнено» (`ACTIVE`), ни как достижение. В составном условии (errata E-0218) запрос получает каждый лист-отношение суждения с парой `NEITHER`, пока `NEITHER` остаётся пара ВСЕГО условия. Если прочие листья уже решили условие, ответ судьи исхода не меняет, и запроса нет (живость, E-0101).


**Условие цели — утверждение об ИСПОЛНЕНИИ, а не посылка нормы (errata
E-0229).** §135 создаёт позицию, когда тело порождающего правила доказано;
§136 сверяет `condition` в окне. Поэтому условие, дословно равное
положительному established-конъюнкту тела того же правила, установлено В ТОТ
ЖЕ МОМЕНТ, что и сама позиция: обязанность рождается `SATISFIED`, ничего не
требует и ни при каком деле в окне не даёт ни `ACTIVE`, ни `VIOLATED`.
Семантика этим не меняется — статус вычисляется прежним §136, — но форма
молчалива, и реализация обязана предупреждать о ней: цель `achievement` либо
`maintenance`, чьё условие (или любой лист составного условия, E-0218) есть
положительный атом с тем же предикатом и теми же аргументами, что
положительный established-конъюнкт тела, диагностируется warning `LDC-E1371`.
Уровень предупреждения, а не отказа: «обязанность, исполненная фактом» есть
законное чтение источника, и отличить её от описки статика не вправе. Цель
`forbearance` §130 в форму не входит: её предмет — действие, и совпадение с
посылкой означало бы `VIOLATED` при создании (E-0179), то есть не молчание.

### 124.1. Achievement goal

В теле `duty` допустимы краткие формы (DECISION-0185):

```text
achieve filed(declaration) during [start, due];
maintain safety_distance(project) >= required during operation_window;
```

Первая запись эквивалентна `goal achievement { condition F; window W; }`,
вторая — `goal maintenance { condition F; window W; }`. `F` — полная формула,
`W` — терм окна с прежними проверками типов; `during` и завершающая `;`
обязательны. Эти слова контекстные и не запрещают одноимённые идентификаторы
в других позициях. На верхнем уровне условия `during` завершает формулу,
в том числе после числа. Единицу с именем `during` в таком условии
отделяют скобками: `amount(x) >= (10 during) during W;`. У нормы одна цель: несколько целей или смешение краткой
и полной формы в одном `duty` отклоняются. Полная форма сохраняется для
`completeness_policy`, `termination` и других полей цели. Краткие формы
внутри `recurring` и других модальностей этим решением не вводятся.

Обе записи дают прежний AST цели (кроме координат), одинаковые CLIR,
идентификаторы и хеши. Достижение, поддержание, полнота наблюдений,
активация и доказательства исполняются по прежним правилам §124–§135.

Должно существовать accepted evidence/derivation достижения condition в window.

```text
achievement {
    condition filed(declaration);
    window [start, due];
}
```

### 124.2. Maintenance goal

Condition должна сохраняться в window.

```text
maintenance {
    condition safety_distance(project) >= required;
    window operation_window;
}
```

Наличие explicit counterexample достаточно для violation. Для доказательства полного satisfaction требуется monitoring completeness certificate, closure policy или adjudication.

### 124.3. Forbearance sugar

```text
forbearance {
    action dismiss(employer, employee);
    window protected_period;
}
```

десугаризуется в maintenance отсутствия action occurrence, но сохраняет authoring metadata для объяснений.

Для действия, выраженного вызовом отношения `P(args)`, условие поддержания —
отрицательный литерал `not P(args)` (E-0179). Его accepted support-пара
оценивается по §134/§137: установленное действие является контрпримером,
противоречие опор не заменяется соблюдением, отсутствие сведений само по себе
не доказывает соблюдение. Истечение окна не отменяет установленного нарушения;
без основания полноты наблюдения применяется `undetermined`, как у maintenance.
Исходное поле `action` сохраняется для объяснений, конфликтов и weak permission.

### 124.4. Recurrence sugar

```text
recurring every 1 month {
    achievement { ... }
}
```

создаёт отдельный position instance для каждого occurrence schedule. Schedule должен быть конечным в конкретном evaluation window.

#### 124.4.1. Исполнимое расписание (DECISION-0156)

Сахар §124.4 был зарезервирован под 0.2 (`recurring_goal` в грамматике,
DECISION-0072) и не разбирался: расписание требует якоря, границ и
идентичности экземпляров, а ни одного из трёх §124.4 не называл. Резерв
снимается аддитивно.

```law
recurring every 1 month over [@2026-01-01, @2027-01-01) {
    achievement {
        condition declaration_filed(taxpayer, occurrence.index);
        window [occurrence.start,
                add_business_days(occurrence.start, 25 calendar_day)];
    }
}
```

**Границы и якорь — клауза `over`.** Расписание отсчитывается от НАЧАЛА
интервала `over` шагом `every`; вхождение `k` (нумерация с нуля) занимает
полуинтервал `[start + k·P, start + (k+1)·P)`, обрезанный концом `over`. Шаг
`P` — `CalendarPeriod` либо `Duration` §84; календарный шаг строится
`add_calendar_period` §84.2 и календаря §85 не читает.

**`start + k·P`, а не «предыдущее начало плюс `P`».** Различие наблюдаемо и
меняет даты: якорь 31 января при шаге `1 calendar_month` даёт по первому
прочтению 31.01, 28.02, 31.03, 30.04, а по второму — 31.01, 28.02, 28.03,
28.04. Нормативно первое: начало вхождения `k` есть
`add_calendar_period(start, k·P)`, вычисленное ОДНОЙ операцией от якоря.
Переполнение дня месяца (31-е в феврале) разрешается политикой §86
`month_end`, выбранной делом, — тем же способом и тем же полем, что у всякой
другой календарной арифметики; расписание своей конвенции не заводит.

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

- **Якорь НЕИЗМЕНЕН.** Ни одна операция расписания его не двигает, и
  `start_count` §86 к нему НЕ применяется: `start_count` относится к отсчёту
  срока ОТ события («со следующего дня»), а вхождение считается от самого
  якоря. Применить его значило бы сдвинуть всё расписание на день молча.
- **Календарный шаг исполняется ТОЛЬКО `add_calendar_period` §84.2** с ЯВНОЙ
  политикой §86: `month_end` обязателен при `calendar_month` и
  `calendar_year`, и его отсутствие есть `MISSING_POLICY`, а не молчаливый
  выбор последнего числа. Своя копия календарной арифметики внутри расписания
  была бы второй семантикой §84.2, и две реализации разошлись бы на ней ровно
  так, как расходились до errata E-0029.
- **Открытость границ `over` нормативна.** У `over (D1, D2]` вхождение,
  начинающееся ровно в `D1`, в расписание не входит, а начинающееся ровно в
  `D2` — входит. Индекс `k` при этом СОХРАНЯЕТСЯ: он есть номер шага от якоря
  (`start + k·P`), а не порядковый номер уцелевшего вхождения.

**Бесконечная верхняя граница.** «Без конечной верхней границы» записывается
`over [<начало>, infinity)` — тем же ключевым словом `infinity`, каким §87
пишет открытый справа `TemporalInterval`. Форма ЗАКОННА синтаксически и
отвергается статикой (`LDC-E1346`, ниже): запретить её грамматикой значило бы
сообщать автору о конечности расписания синтаксической ошибкой вместо
диагностики §198.

**Шаг и границы обязаны быть одного рода.** Прибавление `Duration` к границе
типа `Date` даёт мгновение, и `occurrence.start` вышел бы не того типа, что
границы, — а от его типа зависят и окно цели §138, и сравнение с событием.
Совместимость поэтому закрыта таблицей:

| Границы `over` | Допустимый шаг `every` | Тип `occurrence.start` / `occurrence.end` |
|---|---|---|
| `Date` | `CalendarPeriod` (`calendar_day`, `calendar_week`, `calendar_month`, `calendar_year`) | `Date` |
| `Instant` | `Duration` (`second`, `minute`, `hour`, `day` как 24 часа) | `Instant` |

Иное сочетание — статический отказ `LDC-E1346`: `every 12 hour over
[@2026-01-01, @2027-01-01)` записан, читается и означает шаг физической
длительности по границам гражданских дат. Тип `occurrence.start` и
`occurrence.end` равен типу границ `over`; сравнение вхождения с событием,
чьё `time` записано иначе, проходит разрешение §82.1 обычным порядком.

**Конечность — по построению, а не по проверке.** `over` без конечной верхней
границы (`infinity`) либо непозитивный период (`every 0`, отрицательная
величина) — статический отказ `LDC-E1346` там, где обе величины литеральны, и
fatal `RECURRENCE_UNBOUNDED` до вывода, когда границы вычисляются термом:
бесконечное расписание породило бы бесконечное число позиций, и документ
обязан отказать, а не усечь молча.

Порядок проверки нормативен: границы `over` суть ТЕРМЫ (§18), и они сначала
ВЫЧИСЛЯЮТСЯ, а уже потом решается вопрос конечности. Ground-запись
(`month_start_of(@D)`, константа §87, вызов функции) есть законная граница, и
объявлять её «неконечной» значило бы читать §18 как «только литерал» — тот же
дефект, который errata E-0090 сняла у границ окна §135.

**Предел числа вхождений — не бесконечность.** Расписание с вычисленными
границами и положительным шагом КОНЕЧНО; когда вхождений больше предела
`maxOccurrences` §238, документ получает `RESOURCE_LIMIT` с этим счётчиком, а
не `RECURRENCE_UNBOUNDED`. Разница не косметическая: у первого отказа есть
осмысленный ответ автору («предел мал для этого расписания»), у второго —
только «расписание бесконечно», что было бы неправдой. Предел ЯВНО задаваем
делом (`options.limits.maxOccurrences`) и исполняется обеими реализациями как
всякий иной семантический лимит §238; умолчание — 4096. Считается он при
построении расписания — после `maxFacts` входных фактов и до создания позиций
§135 (§238).

**Мета-термы вхождения.** Внутри тела `recurring` видны неявные мета-термы
`occurrence.start` (`Instant` либо `Date` — по типу границ `over`),
`occurrence.end` (исключающая граница вхождения) и `occurrence.index`
(`Integer`, с нуля). Они — та же природа, что `higher`/`lower` §117: имена,
связываемые конструкцией, а не объявленные автором.

**Форма мета-терма в CLIR** — `FieldTerm` над `RefTerm` `const_ref`
`urn:law:std#occurrence`: доступ к полю имени, связываемого конструкцией.
`VarTerm` формой служить не может — §201 ограничивает `var` шаблоном
`^v[0-9]+$`, и образец `higher`/`lower` §117 (`v0`/`v1`) здесь неприменим:
номер переменной пришлось бы выдумывать, и он столкнулся бы с переменными
самого правила. Форма закрыта здесь, а не оставлена реализации, потому что
§204 канонизирует терм, а два разных представления одного мета-имени дали бы
разные `contentHash` у одной и той же нормы. Без них окно ВХОЖДЕНИЯ
было бы неотличимо от окна всей повторяемости, и норма «не позднее 25 числа
месяца, следующего за отчётным» выражалась бы только перечислением двенадцати
обязанностей руками — ровно то, что корпус и делает сегодня.

**Две формулы активации применяются ОБЕ.** Внешняя `DutyPayload.activation`
§123 и внутренняя `RecurringGoal.activation` живут в разных полях и отвечают
на разные вопросы: первая — «связала ли норма это лицо», вторая — «какому
вхождению принадлежит носитель». Каждая действует в своей области, и ни одна
не поглощает другую: ложная внешняя оставляет ВСЕ вхождения в статусах §135
п. 2 (`PENDING` либо `CREATED`), сколько бы носителей ни нашла внутренняя.
Запрет развилки F14 («связывателей активации не более одного») действует при
этом СУММАРНО на обе формулы: носитель входит в runtime instance ID §133 одним
полем, и считать связыватели по каждой формуле отдельно значило бы допустить
два поля там, где §133 объявил одно.

**Идентичность экземпляров.** Каждое вхождение даёт ОТДЕЛЬНЫЙ экземпляр
позиции §133 с детерминированным id: к `norm_template_id`,
`rule_application_id`, носителю и `evaluation_input_semantic_hash` добавляется
`occurrence.index`. ХВОСТ такого id нормативен и записывается
`…:occurrence:<n>`, где `<n>` — десятичный индекс вхождения без ведущих нулей.
Закреплён он затем, что индекс обязан быть ЧИТАЕМ из ответа: без шаблона
«позиции различимы» и «позиции различимы ПО ВХОЖДЕНИЮ» — разные утверждения,
и первое выполняет любой счётчик применений правила. §133 уже называет `activation_event/time` частью runtime
instance ID — индекс вхождения занимает ту же позицию и по той же причине:
без него два вхождения одной обязанности неразличимы, и второе молча
затирало бы первое.

Отвергнутые здесь якоря: окно внутренней цели как окно всей повторяемости
(тогда срок ВНУТРИ периода невыразим) и активирующее событие §135.1 как якорь
(расписание переставало бы существовать, пока событие не наступило, а
ежемесячная обязанность существует и до первого платежа).

**Активация событием внутри расписания: связь пишет АВТОР.** Формула активации
§135.1, записанная ВНУТРИ тела `recurring`, связывает носителя с вхождением
ЯВНО. Пространством подстановок служит произведение «носитель × вхождение», и
сужает его ровно формула — никакого автоматического выбора вхождения по
времени НЕТ.

Нормативно:

- внутри тела `recurring` формула активации видит и переменную события, и
  мета-термы `occurrence.start` / `occurrence.end` / `occurrence.index`;
- экземпляр позиции создаётся на КАЖДУЮ пару «носитель, вхождение», на которой
  формула активации истинна. Идентичность экземпляра §133 —
  `(activation_event, occurrence.index)`, то есть оба члена пары;
- пара, на которой формула ложна, экземпляра не даёт. Носитель, не связанный
  формулой ни с одним вхождением, не активирует НИЧЕГО — это обычная ложная
  посылка, а не дефект дела;
- формула активации, записанная ВНЕ тела `recurring`, мета-термов не видит и
  активирует расписание ЦЕЛИКОМ, как всякая другая активация позиции;
- **две формулы живут в РАЗНЫХ полях CLIR**: внутренняя (видящая
  `occurrence.*`) — необязательное поле `activation` узла `RecurringGoal`
  §201.1, внешняя — прежнее `activation` у `DutyPayload` §123. Одним полем они
  не обходятся: область видимости мета-термов и есть различие между ними, а
  форма, в которой она не записана, оставляла бы «носитель × вхождение» и
  «носитель × расписание» неотличимыми в каноне §204.

Связь записывается любым термом, каким право её и устанавливает. Три формы
встречаются в актах, и все три законны:

| Как норма связывает событие с периодом | Запись формулы активации |
|---|---|
| по времени события | `meter_read(m, e) and e.time.start >= occurrence.start and e.time.start < occurrence.end` |
| полем самого события | `correction_filed(r, e) and e.period == occurrence.index` |
| отношением дела | `report_for(r, p) and period_index(p) == occurrence.index` |

Контрпример, ради которого автоматическая привязка по времени отвергнута:
уведомление, поданное 5 ФЕВРАЛЯ, об исправлении ЯНВАРСКОГО отчёта. Привязка по
`e.time.start` отнесла бы его к февральскому вхождению и объявила бы
обязанность не о том периоде — то есть соврала бы о праве, ничего не сказав.
Явная формула читает поле события (`e.period`) и связывает его с январём, а
норма, которая действительно означает «в том месяце, когда сняты показания»,
пишет сравнение с полуинтервалом сама — первой строкой таблицы, и это ровно
столько же символов.

Отвергнутые здесь варианты: активация только расписанием целиком (окно
вхождения перестало бы отсчитываться от события) и АВТОМАТИЧЕСКАЯ привязка по
`e.time.start` (умолчание, которое в случае «исправление прошлого периода»
молча даёт неверный период, а автор не имеет способа его переопределить).

Цена выбранного варианта названа: формулу связи автор пишет РУКАМИ, и забытая
связь даёт декартово произведение — по позиции на каждую пару. Это видно в
ответе (число экземпляров позиции), тогда как неверно угаданный период — нет.

## 125. Liberty

```text
then liberty AppealPermission {
    holder person;
    against Authority;
    action submit_appeal(person, decision);
    window appeal_period(decision);
};
```

`liberty` является explicit/strong permission. Она может участвовать в priority conflict с prohibition/duty to forbear.

## 126. Weak permission

Weak permission не является norm, а query result:

```text
weakly_permitted(actor, action, context)
```

Он может быть `true` только относительно явно выбранных:

- rule universe;
- source/time snapshot;
- interpretation;
- closure policy по применимым prohibitions.

По умолчанию отсутствие запрета возвращает `UNDETERMINED`, а не permission.

## 127. Power

```text
then power IssuePermitPower {
    holder AuthorityX;
    over applicant;
    exercise issue(AuthorityX, permit, applicant);
    effect create(valid(permit));
    valid_when (competent(AuthorityX, permit_type)
      and procedure_completed(application));
};
```

Power описывает способность создать legal effect при valid exercise.

`subject` (аддитивно, DECISION-0043) — **предмет полномочия**: конечное перечисление того, что делегат вправе урегулировать, идентификаторами словаря самого уполномочившего акта.

```text
then power DetermineProcurementProcedure {
    holder AuthorisedBodyOfHealth;
    exercise procurement_procedure_act(AuthorisedBodyOfHealth, service);
    valid_when procedure_follows_statutory_principles(service);
    effect procurement_procedure_established(service);
    subject ProcurementProcedureInInsuranceSystem;
};
```

Поле повторяемое: предметов бывает несколько, а списка грамматика 0.1 не несёт. Идентификаторы принадлежат словарю уполномочившего акта по необходимости — подзаконного акта в момент принятия закона ещё нет, и назвать его понятия закон не может.

Конечность перечисления **существенна**, а не является ограничением реализации: §105.1 запрещает выводить «норма A охватывает норму B вообще», и предметная компетенция проверяется принадлежностью объявленного предмета акта (§27.1 `regulates`) объявленному предмету полномочия — сравнением двух перечислений, а не выводом из текста. Излишек даёт `LDC-E5307`.

Отсутствие `subject` означает, что предмет **не объявлен**, а не что он любой: делегация без объявленного предмета не должна проходить предметную проверку легче, чем объявившая его, поэтому пропуск сообщается (`LDC-W5302`).

Exercise event сам по себе не создаёт effect, пока не установлены:

- holder identity;
- scope/competence;
- valid_when;
- temporal validity;
- отсутствие применимого immunity/invalidity rule.

Standard norm runtime выполняет power в два шага:

1. rule создаёт/активирует `Power` position до exercise;
2. когда accepted event соответствует `exercise` pattern, evaluator проверяет availability, `valid_when`, temporal scope и immunity; только затем constitutive rule создаёт legal effect.

Шаг 2 исполняется norm runtime §280.3 ПОСЛЕ всех strata §280.2, и созданный эффект входит в strict least fixed point следующего шага §143.1. Отсюда две видимости эффекта в одном документе (errata E-0134): строгие `established`-читатели `P` и выводимых из него строго предикатов видят его; status-sensitive читатели (`not_known`/`unknown`/`refuted` §67/§113) и поражаемые правила §104 — нет, потому что вычислены до материализации и не повторяются. Первое — отклоняемая форма (`LDC-E4103` / `NON_EXECUTABLE_RULE`, §111), второе — названный остаток 0.2 (DECISION-0021 §4.3, §111.1). Строгий `established`-читатель, видящий эффект, отклоняется и сам, если его голова — комплемент головы defeasible-кандидата: его опора пришла бы после того, как conflict group этого предиката уже решена, и документ получил бы `BOTH` вместо поражения §107 п. 1 (errata E-0238, §111).

`valid_when`, читающий отношение суждения §47.3, не решается вычислением: до
поступления adjudicated assertion он остаётся неопределённым ПО ПРИЧИНЕ, а не
по нехватке фактов. Эффект в этом случае не материализуется по общему правилу
выше, но документ обязан назвать причину — evaluation status
`REQUIRES_JUDGMENT` и типизированный `JudgmentRequest` (errata E-0100, §47.3).

**Форма `valid_when` (errata E-0190).** `valid_when` — формула; исполнимое подмножество 0.1 — литерал (в том числе под статусной обёрткой §65) либо конъюнкция таких литералов, вложенные `and` читаются одним плоским списком в порядке записи. Конъюнкция читается как тело правила §98: условие выполнено, когда КАЖДЫЙ конъюнкт выдерживает свой статус-тест, и опоры всех конъюнктов входят в посылки узла эффекта в порядке записи. Иначе — попытка exercise без эффекта по общему правилу (`POWER_INVALID_EXERCISE`). Статус-тест конъюнкта (errata E-0191) — тот же, что у конъюнкта тела правила (§65, §66, §67): голый литерал и `established(P)` — ровно `TRUE_ONLY`; `supported(P)`/`monotone(P)` — `TRUE_ONLY` или `BOTH`; `not_known(P)` — положительной опоры нет (`NEITHER` или `FALSE_ONLY`); `refuted(P)` — ровно `FALSE_ONLY`; `unknown(P)` — ровно `NEITHER`. Обёртка НЕ читается как свой операнд: `not_known(P)` при отсутствующем `P` выполнено, при установленном — нет. Статусные виды `opposed`/`conflicted` в `valid_when` не исполняются — форма вне подмножества, как ниже. Операнд обёртки — литерал (§65). Канал §47.3 читается по живости E-0101: не выдержавший тест конъюнкт — отношение суждения при паре `NEITHER` даёт `REQUIRES_JUDGMENT` и запрос, пока НИ ОДИН другой не выдержавший тест конъюнкт не имеет определённой пары (`TRUE_ONLY`, `FALSE_ONLY`, `BOTH`): такой конъюнкт делает полномочие мёртвым, ответ судьи ничего не изменит, запроса нет, и `POWER_INVALID_EXERCISE` выпускается, а неопределённый конъюнкт (`NEITHER`) полномочие не убивает; выдержавший тест конъюнкт (в частности `not_known` над молчащим судьёй) запроса не порождает. Граница: `valid_when` со статус-тестом, чувствительным к добавлению опоры (`not_known`/`unknown`/`refuted`), читает снимок на момент материализации эффекта; над предикатом, достижимым от головы эффекта полномочия (§67, E-0134), результат зависит от порядка материализации — такое чтение вне гарантий 0.1 (статического отказа для `valid_when` нет). Форма вне подмножества (`or`, `not`, сравнение, вычисляемый терм) НЕ исполняется молча как «условие не выполнено»: движок выпускает `NON_EXECUTABLE_RULE` (warning, `relatedNodes` — позиция) для каждой активной позиции такого полномочия независимо от того, осуществлено ли оно, и эффект не создаётся. Синтаксис: `valid_when` без скобок принимает парсер только для одного атома; конъюнкцию записывают в скобках (`valid_when (A and B);`), голая форма — `LDC-E0201` (реестр `grammar-fuzz-findings.json`, GF-018).

Попытка exercise при недоступном power сохраняется как empirical event и может породить `invalidly_exercised`, но не обязана создавать effect. Core не предполагает автоматически `void ab initio`: jurisdiction profile может отдельно вывести provisional, voidable или сохраняющийся до отмены effect.


Если применимые `Power(E)` и `Immunity(E)` после defeat остаются одновременно непобеждёнными, Core использует conservative effect materialization:

- empirical exercise event сохраняется;
- effect `E` не получает автоматически accepted institutional support;
- transformation query получает `UNRESOLVED_NORMATIVE_CONFLICT`;
- proof graph содержит обе позиции, priority closure и причину несравнимости.

Jurisdiction profile МОЖЕТ явно задать `effect_conflict_policy` (`provisional_effect`, `presumed_valid_until_invalidated`, `no_effect_until_resolved` и т. п.). Такая policy является семантически активной, должна быть pinned в EvaluationInputManifest и иметь source/interpretation anchors. Без неё default всегда `no_effect_until_resolved`.

## 128. Immunity

```text
then immunity NoRetroactiveHarsherPenalty {
    holder person;
    against State;
    protected_effect impose_harsher_penalty(person, offence);
    window [offence_time, infinity);
};
```

Immunity блокирует соответствующую legal transformation, но не обязательно запрещает физическое действие органа. Invalid exercise может всё равно фактически произойти и иметь отдельные последствия.

## 129. Correlative views

Следующие конструкции являются query/surface views:

```text
claim_right(holder, against, content)
    <-> duty(bearer = against, beneficiary = holder, content)

liability(holder, to, change)
    <-> power(holder = to, over = holder, effect = change)

disability(holder, against, change)
    <-> immunity(holder = against, against = holder, effect = change)
```

Core не создаёт дубликаты norm instances; views ссылаются на один canonical position.

### 129.1. Claim sugar

```text
then claim FairTrial {
    holder accused;
    against tribunal;
    goal achievement {
        condition fair_trial_afforded(accused, charge);
        window trial_period(charge);
    }
};
```

десугаризуется в duty по отображению §129, то есть со сторонами **крест-накрест**: `holder` становится `beneficiary`, `against` становится `bearer`. `modality` узла — `duty`: притязание не является пятой modality §122, оно есть view одной канонической позиции.

Обязательны все три поля. `beneficiary` у `DutyPayload` факультативен, но вид §129 трёхместен, и притязание без держателя притязанием не является; притязание без `against` не имеет обязанной стороны.

Обратное направление (`duty` → `claim_right`) остаётся видом запроса и узла не порождает — иначе одна позиция дала бы два экземпляра, что §129 запрещает.

Поверхностная запись `claim { … }` депрекирована (errata E-0071): это синоним duty с переставленными сторонами, пятой модальности §122 не существует, и обе записи дают равный semantic hash §209; view §129 при этом остаётся видом ЗАПРОСА и erratой не затронут. Реализация отвечает предупреждением `LDC-E1328`; в 0.2 запись станет ошибкой. Prohibition sugar §130 сохранён: тот же механизм, но словарь акта («запрещается») совпадает с формой записи, и корпус употребляет её 238 раз против одного `claim`.

## 130. Prohibition sugar

```text
then prohibition ProtectedDismissal {
    bearer employer;
    beneficiary employee;
    action dismiss(employer, employee);
    window protected_period(employee);
};
```

десугаризуется в duty с forbearance goal.

## 131. Entitlement sugar

`entitlement` должен явно выбрать lowering:

- claim against identified bearer;
- power to demand/claim;
- constitutive eligibility fact;
- комбинация перечисленного.

Голое `entitlement X` без lowering является static error.

## 132. Discretion

Discretion не является пятой modality. Оно представляется:

- power с несколькими допустимыми exercises/effects;
- liberty выбора;
- constraints/goals для законности выбора;
- evaluative predicates (`reasonable`, `proportionate`) при необходимости.

## 133. Norm template identity

Norm template имеет stable ID. Runtime instance ID включает:

```text
norm_template_id
rule_application_id
bearer
counterparty/beneficiary
activation_event/time
evaluation_input_semantic_hash
```

**Форма id (DECISION-0156).** Кортеж выше называет СОСТАВ идентичности; форма
записи закреплена так: `urn:position:<rule>:<sha256>`, где `<rule>` — полный
StableId правила, а `<sha256>` — шестнадцатеричный SHA-256 канонических байтов
§208 подстановки применения: объекта переменная → значение с ключами по
возрастанию, того же, что поле `substitution` узла `rule_application` §180
(errata E-0247; прежде здесь стоял порядковый номер применения). При наличии носителя активации
§135.1 к ней добавляется компонента `:event:<первые 8 hex-знаков sha256 от
`id` события>`, а хвост вхождения §124.4.1 `:occurrence:<n>` остаётся
последним. Компонента носителя КОРОТКАЯ намеренно: полный StableId события
сделал бы id позиции длиннее самой нормы, а хэш от него детерминирован и не
зависит ни от порядка дела, ни от числа позиций. Позиция без носителя
сохраняет прежний вид id: `activation_event` у неё нет, и приписывать ей
пустую компоненту значило бы двигать идентичность там, где §133 ничего не
поменял.

---