# Часть XXVII. Canonical Legal IR

## 200. IR levels

### 200.1. CST

Concrete syntax tree сохраняет tokens, comments и formatting trivia.

### 200.2. HIR

High-level IR сохраняет authoring constructs: `presumption`, `prohibition`, `definition`, nested interpretations.

### 200.3. TIR

Typed IR содержит resolved symbols, types, units и effect classes.

### 200.4. CLIR

Canonical Legal IR содержит только нормализованные constructs.

### 200.5. EPlan

Execution plan содержит indexes, strata, grounded-domain plans и incremental dependencies.

## 201. CLIR top-level node kinds

`Package` является envelope всего CLIR-document (`schemaVersion`, `semanticVersion`, package identity, locked imports, features, strata и `nodes`), а не элементом массива `nodes`.

Envelope МОЖЕТ нести `labels` (§202, `List<Label>`) — человеческое название самого пакета: того акта или свода, который он формализует (errata E-0025). Поле презентационно ровно в том же смысле, что метки узлов: оно не входит в semantic hash §209 и не может изменить ни одного вывода.

```text
SourceWork
SourceEdition
Publication
Fragment
CalendarSnapshot
DeadlinePolicy
Stage
TypeDecl
SymbolDecl
FunctionDecl
ExternalDecl
Assertion
EvidenceItem
SupportEdge
Rule
NormTemplate
PriorityRule
Interpretation
InterpretationGroup
Anchor
Revision
ClosurePolicy
Constraint
Procedure
Query
```

Runtime objects не являются program nodes:

```text
RuleApplication
PositionInstance
Conflict
ProofNode
EvaluationResult
EvaluationManifest
```

## 201.1. Узел `procedure` (DECISION-0156)

DECISION-0013 §2.1 гордился тем, что профиль §159–§164 не порождает ни одного
нового вида узла: состояния и переходы становились константами, а автомат —
тремя видами правил. Свёртка §161.1 этого не выдерживает, и не по объёму
работы. Порядок по времени со «строго более ранними» событиями, невалидность
повтора и снятие токенов при соединении §162.1 требуют отрицания по времени и
рекурсии сквозь него; §110.1 такой цикл отвергает по построению. Автомат
перестал быть записью правил и стал ДАННЫМИ, которые исполняет отдельная фаза.

Отсюда узел `procedure` со следующими полями сверх общих §202:

```text
instanceType: TypeRef
states: List<ProcedureState>
transitions: List<ProcedureTransition>

instancePredicate:    StableId          // procedure_instance §164.1
attemptedPredicate:   StableId          // attempted_transition
validPredicate:       StableId          // valid_transition
enteredPredicate:     StableId          // entered_state
leftPredicate:        StableId          // left_state
initialPredicate:     StableId          // initial_state
stateBeforePredicate: StableId          // state_before §164.2
currentStatePredicate: StableId         // current_state §164.2
completedPredicate:   StableId?         // completed §163.1; отсутствует у
                                        // процедуры без сахара §163.1

ProcedureState {
    id: StableId
    initial: Boolean
    terminal: Boolean
    regions: List<ProcedureRegion>?     // §162.1; отсутствует у простого состояния
    join: { policy: "all" | "any" | "quorum", count: Integer? }?
}
ProcedureRegion { id: StableId, states: List<ProcedureState>,
                  transitions: List<ProcedureTransition> }
ProcedureTransition {
    id: StableId
    from: StableId
    to: StableId
    on: StableId?                       // §160.1: тип события; отсутствие — любой тип
    guard: Formula?                     // `when`
    requires: List<Formula>             // §163
}
```

Предикаты §164.1 остаются `symbol_decl` и объявляются как прежде: меняется
только их арность и то, ЧЕМ они производятся. Но узел `procedure` называет их
ПОИМЁННО — восемью обязательными полями выше и девятым необязательным,
`completedPredicate` (§163.1): сахар `completed(P, y)` есть предикат пакета, и
распознавать его структурно — по форме первого аргумента — нельзя, потому что
под такую догадку подпадает всякое двухместное отношение, случайно принимающее
имя процедуры первым аргументом. Основание то же, что у самого
узла: без них принадлежность факта процедуре выводилась бы догадкой по имени
предиката, а при двух процедурах одного пакета имена квалифицируются
(DECISION-0013 §2.3, `A__procedure_instance`), и догадка становится неверной.
Фаза свёртки читает эти поля, а не строит имена по шаблону; §201.1 снимает
последнее место, где структура акта выводилась из формы порождённых id, и
оставлять такое место здесь значило бы вернуть его под другим именем. Правил профиля
(`<P>/initial`, `<P>/<T>/valid`, `<P>/<T>/enters`) десугаризация больше не
эмитирует — их место занимает фаза свёртки, стоящая одной стратой §111 между
strict-замыканием входных фактов и правилами, читающими §164.

Таблица членов пакета — «голое имя → член» по всем узлам `procedure`
документа, рекурсивно по областям `states[].regions[]` §162.1 (вложенные
состояния и переходы — члены наравне с корневыми); однозначность таблицы
обеспечена статически §160.2 (`LDC-E1351`).

Четыре следствия, названные явно.

1. **`schemaVersion` сдвигается** — узел новый, и документ с ним не читается
   реализацией прежней версии. Сдвиг производится тем изменением, которое
   впервые ЭМИТИРУЕТ узел (стадия S3 DECISION-0156), а не объявлением схемы.
2. **`terminal` перестал быть маркером исходника.** DECISION-0052 §2 объявлял
   границей то, что по CLIR нельзя отличить законный терминал от тупика:
   терминальность проверял компилятор (`LDC-E1313`) и в узлы не переносил.
   Теперь она — поле узла, и `SINK_STATE` инструмента становится настоящей
   находкой, а не заметкой.
3. **Proof-граф получает два новых вида узлов.** `rule_application` §180
   требует пары «правило + подстановка», и у выводов свёртки её нет; у
   `current_state(x, S)` нет и проверяемого основания — он есть проекция конца
   истории. Виды `procedure_step` (шаг: процедура, экземпляр, носитель,
   ПЕРЕЧЕНЬ переходов шага §161.1, состояние перед, исход каждого перехода и —
   при невалидности — какое из четырёх условий §161.1 не выполнено) и
   `procedure_history` (итог: экземпляр,
   упорядоченный список носителей, итоговые состояния, завершённость)
   определены §180.2 и объявлены в `evaluation.schema.json`. Без них ответ о
   состоянии дела был бы фактом без обоснования, чего §179 не допускает.
4. **Инструменты трека О читают узел, а не восстанавливают автомат из правил.**
   Восстановление по трём видам правил (DECISION-0052 §1, `lawref/process.py`)
   и чтение имени процедуры из строки id перестают быть нужны. Это упрощение,
   а не потеря: оно снимает единственное место, где структура акта выводилась
   догадкой о форме порождённых id.

**Форма имени состояния и перехода в опубликованном атоме (E-0148).**
Состояния и переходы остаются ДОМЕННЫМИ константами §54 (DECISION-0013 §2.1):
десугаризация объявляет каждое `symbol_decl` вида `constant` типа `<P>State`
либо `<P>Transition` со значением `entity_ref` на собственный StableId — имя,
денотирующее себя. Отсюда обязательство фазы свёртки: атомы профиля §164.1,
которые она публикует (`initial_state`, `entered_state`, `left_state`,
`state_before`, `valid_transition`, `current_state`, `completed`), несут
состояние и переход в ТОЙ ЖЕ форме, какую остальная программа видит ПОСЛЕ
предпрохода §54.1, — то есть значением константы, если она объявлена, и
`const_ref` в ручном CLIR, где её нет. Публиковать имя там, где программа
объявила константу, нельзя: предпроход §54.1 разыменовывает `const_ref` в
вопросе и в фактах дела, свёртка публиковала бы неразыменованное имя, ключи
атомов разошлись бы, и вопрос о состоянии понижённого пакета отвечался бы
`NEITHER` при зелёных `check`, `lower` и пустых `issues`. Молчание права без
единой диагностики — тот же класс отказа, ради которого §54 заведён
предпроходом, а не разыменованием по месту.

**`RecurringGoal` получает необязательное поле `activation: Formula`** —
внутреннюю формулу активации §124.4.1, единственную, которая видит мета-термы
`occurrence.*`; внешняя активация расписания целиком остаётся полем
`activation` у `DutyPayload` §123. Поля два, потому что различаются они ровно
областью видимости, и держать обе формы в одном поле значило бы, что канон
§204 не отличает «носитель × вхождение» от «носитель × расписание».

Отвергнутые здесь варианты: прежняя десугаризация в правила с
конъюнктами-маркерами, которые узнаёт evaluator (маркер, не влияющий на
семантику правила, есть та же фаза свёртки, только спрятанная в форму, которую
§204 обязан канонизировать как обычную формулу); новый ВИД ФОРМУЛЫ
«упорядоченная свёртка» (формула обязана быть истинностной на подстановке, а
свёртка производит факты и не имеет истинностного значения).

## 202. Common node fields

```text
id: StableId
kind: NodeKind
package: StableId
sourceSpan: SourceSpan?
labels: List<Label>
annotations: JsonObject
anchors: List<StableId>
provenance: List<ProvenanceEdge>
contentHash: Digest
```

Root envelope содержит полный `PackageRef` (`name`, `version`, `namespace`, `semanticHash`). Поле `package` каждого node является стабильным namespace/ID пакета, а не повтором полного объекта; для локальных nodes оно равно `root.package.namespace`. Такое разделение уменьшает размер IR и не допускает расхождения нескольких копий package metadata.

`Label` имеет поля `language`, `status`, `text` и необязательный `grammaticalForms` (§218.1); список, а не map, позволяет одновременно хранить official/unofficial/translation labels на одном языке. `ProvenanceEdge` является нормализованным ребром provenance graph.

`ParameterDecl` (DECISION-0001) — элемент `SymbolDecl.parameters`, а не узел: `{ id: StableId; name: String; type: TypeRef; role: StableId?; optional: Boolean; labels: List<Label>? }`. Поле `labels` (errata E-0153, DECISION-0161) сериализуется только непустым — параметр без меток остаётся прежними байтами — и подчиняется той же дисциплине, что метки узла: оно вне `semanticHash`, `theoryHash` и `artifactHash` (§209, исключение E-0010 рекурсивно на всех носителях) и внутри `contentHash` узла-владельца — того `symbol_decl`, в массив `parameters` которого параметр входит; собственного `contentHash` у параметра нет. `name` параметра вне semantic hash по DECISION-0001 п. 4 независимо от меток. Массивы `parameters` у `function_decl`, `definition` и `query` — связанные переменные, не `ParameterDecl`, и меток не несут.

`sourceSpan` исключается из semantic content hash узла, чтобы formatting не менял его смысл. `labels` исключаются из `theoryHash` и `artifactHash` (§209): перевод и переформулировка метки не являются ни изменением теории, ни новым provenance-артефактом; в `contentHash` самого узла метки входят. `anchors` и `provenance` входят в `contentHash` и `artifactHash`, но не входят в `theoryHash`. Узел `anchor` (§33.2, DECISION-0358) — материализация атрибутов связи `relation`, `coverage`, `quote` — подчиняется тому же режиму целиком: он входит в `artifactHash` и в legacy `semanticHash`, но исключён из `theoryHash` как узел провенанса, наравне с `publication`.

Перечень исключений выше ЗАКРЫТ: всякое иное поле `NodeCommon` входит в content hash СВОЕГО узла — в частности `anchors` (§33), наравне с `labels` и `visibility` (§24). Существенно здесь не то, какие поля перечислены, а то, что состав хэша не зависит от ПУТИ, которым поле проставлено: якорь, поставленный конвертом декларации, и якорь, поставленный самим понижением, обязаны давать один и тот же `contentHash`. Errata E-0054 закрыла зазор ровно этой формы — конвертный путь дописывал `anchors` уже после вычисления хэша, и одна и та же программа получала узлы двух несравнимых конвенций в зависимости от вида декларации.

Разведение идентичностей принято DECISION-0111 §2.6: якорь обеспечивает трассировку (§33), поэтому его перенос меняет `artifactHash`, но не меняет `theoryHash`. Legacy `semanticHash` 0.1 сохраняет прежний preimage только в режиме совместимости 0.1.


Generated child IDs используют parent explicit ID и детерминированный semantic suffix. Compiler НЕ ДОЛЖЕН использовать source line number, declaration order, filesystem inode или machine path при формировании semantic ID.

## 203. Canonical literal

```json
{
  "kind": "literal",
  "polarity": "positive",
  "predicate": "urn:kz:law#registered",
  "args": [
    { "kind": "entity_ref", "id": "urn:entity:acme" }
  ]
}
```

## 203.1. Canonical norm-template reference

Surface `then duty/liberty/power/immunity` создаёт отдельный `NormTemplate` node. Rule head содержит:

```json
{
  "kind": "norm_template_ref",
  "id": "urn:kz:law#SubmitDeclarationDuty"
}
```

Это исключает дублирование norm template внутри нескольких rules и упрощает stable references.

StableId узла `NormTemplate` — explicit `@id` вложенной нормы (§14: аннотация
перед ключевым словом модальности, `then @id("…") duty Name { … }`), иначе
`<namespace>#<имя шаблона>`. Голова `norm_template_ref` несёт тот же id.
StableId правила-производителя от id шаблона не зависит и берётся по своим
правилам (§14, §204; при явном `@id` правила — от него). Поэтому пара
«правило `…#R` + шаблон `…#R/norm`» выразима ручной записью, и развёртка
профиля §279.1 обязана давать те же байты (DECISION-0209 Р1).

## 204. Canonical rule

```json
{
  "kind": "rule",
  "id": "urn:kz:law#R1",
  "strength": "defeasible",
  "variables": [
    { "id": "v0", "type": "urn:law:Person" }
  ],
  "body": {
    "kind": "status",
    "status": "established",
    "formula": {
      "kind": "literal",
      "polarity": "positive",
      "predicate": "urn:kz:law#eligible",
      "args": [{ "kind": "var", "var": "v0" }]
    }
  },
  "head": { "kind": "literal", "...": "..." },
  "scope": { "kind": "boolean", "value": true },
  "effective": { "...": "..." },
  "interpretations": ["urn:interpretation:I1"],
  "anchors": ["urn:anchor:A1"]
}
```

## 205. Alpha normalization

Variables canonicalize в `v0`, `v1`, ... по порядку first binding. Переименование local variable не меняет semantic hash.

## 206. Rule splitting

Surface rule с N heads компилируется в N canonical rules. Child ID выводится из parent stable ID и short hash canonical head:

```text
R#head-a91f2c
R#head-38bc10
```

Поэтому простая перестановка независимых heads не меняет их IDs. Два идентичных heads после normalization дедуплицируются с warning либо отклоняются strict lint policy. Source order сохраняется только как authoring metadata.

### 206.1. Дизъюнкция в теле порождаемого правила (errata E-0217)

Тело canonical rule есть КОНЪЮНКЦИЯ конъюнктов §98. Дизъюнкция, достижимая
от вершины условия через `and`, в тело узла не попадает: условие приводится
к дизъюнктивной нормальной форме, и каждая ветвь даёт СВОЙ canonical rule с
тем же `head`, `variables`, `strength`, `scope`, `effective`, `governs` и
`anchors`. Id ветви — `<id>/alt/N`, где `<id>` — id, который узел получил бы
без дизъюнкции, а `N` считается от 1 в порядке ДНФ (дистрибуция слева
направо, альтернативы — в порядке записи). Условие без `or` даёт один узел с
прежним id.

Правило одно на все конструкции, порождающие узел `rule`: `when` правила
(литеральная голова и norm template §123–§128), условие клаузы
`unless`/`except_when` §149/§150 — голой и контрарной, `when` презумпции,
фикции §147, классификации §148 и `sufficient`-направления определения §151.

Основание — §66 и §65: голый литерал в теле есть `established(P)`, то есть
тело — Boolean-комбинация status tests, и `established(A) or established(B)`
выполнено ровно тогда, когда выполнена одна из ветвей. Развёртка смысла не
меняет; она переводит его в форму, которую определяет §98.

Следствия, которые обязаны быть названы:

1. **Цепочка исключений §150.** Контрарная ветвь клаузы берёт direct
   priority над КАЖДЫМ узлом предыдущего уровня, а следующая клауза — над
   каждой ветвью этой. Id рёбер образуются от id ветви по прежним правилам.
2. **Норм-голова.** Каждая выполненная ветвь — отдельное применение правила,
   а `rule_application_id` входит в идентичность позиции §133. Поэтому две
   выполненные ветви дают две `PositionInstance` одной нормы. Каждая несёт
   своё доказательство, а статусы у них одинаковы, потому что цель общая.
3. **§190 и §149.1** применяются к КАЖДОЙ ветви как к отдельному правилу.

Дизъюнкция под `not`, под квантором §52 и внутри operand status test §65 этим
правилом не затрагивается: operand status test — literal. Дизъюнкция в
generator-е comprehension остаётся в терме и исполняется по §52.1
(errata E-0219). Canonical rule,
у которого `or` всё же оказался в теле (рукописный CLIR), остаётся вне
исполнимого подмножества: оценщик отвечает `NON_EXECUTABLE_RULE` и не
подставляет своего чтения.

## 207. Explicit defaults

CLIR не содержит implicit defaults. В нём всегда явно присутствуют:

- strength;
- body condition mode;
- temporal intervals;
- selected unit canonicalization;
- rounding;
- source resolver result либо unresolved marker;
- interpretation membership;
- external effect class.

## 207.1. Formula normalization

Canonicalizer:

- flatten-ит associative `and`/`or`;
- сортирует commutative operands по semantic hash;
- удаляет точные дубликаты operands;
- сохраняет explicit polarity;
- нормализует units/currencies/Decimals;
- не применяет contraposition или domain-specific algebraic rewrites;
- не считает две solver-equivalent, но синтаксически разные formulas одинаковыми без отдельного proved-equivalence artifact.

Source order хранится в HIR/source map для объяснений.

`collect v: T where F` нормализуется в `ComprehensionTerm(variable=v, element=v, generator=F, distinct=true)`. Дополнительные surface binder-ы записываются в `ComprehensionTerm.binders`; они локальны generator-у и не меняют element. Generator formula сохраняет обычную status semantics; default для bare literals — `TRUE_ONLY`.

### 207.2. StableId анонимного assertion

В `law.core/0.2` assertion без `id` получает StableId
`<package-namespace>#assert-h<sha256>`, где `h` синтаксически отделяет digest
от запрещённого позиционного `assert-N`, а digest вычисляется над каноническим
нормализованным фактом вместе с его `origin`, evidence, временными полями,
`anchors` и `provenance`. Из preimage исключены `id`, package envelope,
`contentHash`, `sourceSpan`, annotations и labels. Путь, имя файла, строка и
позиция декларации в StableId не входят.

Два точных анонимных дубля имеют один preimage и статически отклоняются
`LDC-E1331`; автор, которому нужны два различимых утверждения одинакового факта,
обязан задать им явные `id`. Любая digest-коллизия обрабатывается тем же отказом,
а не порядковым суффиксом. Режим 0.1 сохраняет позиционные `assert-N` только как
совместимость.

## 208. Canonical serialization

`.lawir.json` использует:

- UTF-8;
- Unicode NFC;
- object keys в lexicographic order;
- top-level unordered node sets сортируются по stable ID;
- semantic sets сортируются по canonical element hash;
- operands commutative `and`/`or` сортируются по semantic hash — нормативно, в соответствии с §207.1 (errata E-0002); source-order хранится отдельно для объяснений;
- ordered constructs (`List`, `first` decision rows, procedural sequence) сохраняют порядок;
- arrays в явно определённом semantic order;
- Decimal как canonical non-exponent string: `0`, `-12`, `0.125`, `-3.5`; без leading zeros, trailing fractional zeros и negative zero;
- source `12.50`, `1.25e3` normalizes соответственно в `12.5`, `1250`;
- Rational как несократимая дробь `<числитель>/<знаменатель>` со строго положительным знаменателем (§35, errata E-0005/E-0213): `15/100`, `1/-2`, `-3/-6` и `0/7` normalizes соответственно в `3/20`, `-1/2`, `1/2` и `0/1`;
- Instants рекомендуются в UTC `Z` representation — рекомендация автору, не нормализация канона (errata E-0214: смещение есть часть записи значения, см. ниже);
- explicit timezone metadata отдельно;
- без insignificant whitespace для hash form;
- SHA-256 baseline digest.

**JSON-число канона (errata E-0202).** Число канонической проекции есть
ЦЕЛОЕ в знаковом 64-битном диапазоне и только оно. Binary floating point не
является типом ядра (§18), а целое вне диапазона носителя (§49.1, §58 с
errata E-0075) каноном не представимо; `Decimal`, `Money`, `Quantity` и
`Rational` записываются СТРОКОЙ (§35, §50). Всякое другое число — отказ
канонизации, а не значение: документ не собирается вовсе, и реализация
отвечает error-объектом `{"error": {"code": "CanonError", "message": …}}`
(§172), **одними байтами у обеих реализаций**. Сообщение имеет форму

```text
<путь>: JSON-число вне канона §208: только целое знакового 64-битного диапазона (SPEC §18: binary float не тип ядра; Decimal — строкой)
```

где `<путь>` — путь от корня канонизируемого значения в записи `$`, `.<ключ>`,
`[<индекс>]`, той же, что у отказа по NFC.

**Лексика строковой записи значения (errata E-0202).** У видов, чьё значение
канон несёт СТРОКОЙ, законна ровно каноническая запись, и читатель её НЕ
НОРМАЛИЗУЕТ. Алфавит — ASCII; `_` есть нотация ИСХОДНИКА (§18, `5_000_000`),
а не канона IR, и в записи значения незаконен; пробельный символ в записи
незаконен в любой позиции; `Infinity`, `-Infinity`, `NaN`, `sNaN` не являются
записями `Decimal` — точная десятичная семантика §18 таких значений не знает.
Грамматики:

```text
Decimal | Money.value | Quantity.value ::= [+-]? ( digit+ ("." digit*)? | "." digit+ ) ( [eE] [+-]? digit+ )?
Rational | Bounds.lower | Bounds.upper | Magnitude.value ::= [+-]? digit+ "/" [+-]? digit+
digit ::= "0".."9"
```

Экспонента, хвостовые нули, ведущие нули, знак `+` и сократимая дробь в записи
ВХОДА остаются законными и нормализуются на выходе по правилам выше (§35,
E-0005): это уже сказано и не сужается. Незаконная запись есть ошибка
литерала `TYPE_ERROR`, а не значение.

**Запись значения принимается в двух формах, печатается в одной (errata
E-0213).** У вида, чьё значение канон несёт СТРОКОЙ, поле `value` законно и
JSON-СТРОКОЙ, и — у `Decimal`, `Money` и `Quantity` — целым JSON-числом в
пределах диапазона выше; вторая форма есть ЗАПИСЬ той же величины, и канон
печатает её той же канонической строкой, что первую. Поэтому `1000000` и
`"1000000"` суть одно значение, один узел §202 и одна теория §209.
Дробь JSON-числом не записывается: число не есть запись `<n>/<d>`, и канон
подменять её собой не вправе. Отказ на float и на целое вне диапазона
остаётся прежним и на этих видах тоже: принимается ЦЕЛОЕ, а не всякое число.

Канон дроби §35 приводит запись к несократимой паре и переносит знак в
ЧИСЛИТЕЛЬ — той же формой, какую §168.1 уже требует от ground-позиции
утверждения (`LDC-E1324`: «числитель и знаменатель взаимно просты,
знаменатель положителен»). Нуль имеет ровно одну запись `0/1`, и
отрицательного нуля у дроби нет, как нет его у `Decimal`. **Сокращение не
меняет ВИД значения:** `10/2` канонизируется в `5/1`, а не в `5` — вид не
зависит от значения (§58), и единичный знаменатель остаётся записанным.
Нулевой знаменатель канонической формы не имеет вовсе: такая запись проходит
канон невредимой и получает диагностику читателя литерала (§48, E-0152) —
нормализация не подменяет собой отказ.

**Мгновение входит в идентичность КАК ЗАПИСАНО (errata E-0214).** Смещение
есть часть записи значения, а не её оформление: канон мгновение в UTC не
переводит, долей секунды не снимает и записи не сверяет. Поэтому
`@1945-05-08T23:01:00+01:00` и `@1945-05-08T22:01:00Z` — ОДНО значение и ДВЕ
идентичности: §57 (errata E-0048) сравнивает и упорядочивает моменты, и
`eq` двух записей истинно, а `semanticHash`, `theoryHash` и `resultHash`
документов различны. Строка выше про UTC `Z` есть рекомендация автору: тому,
кому нужна одна идентичность на два авторства, предписано писать `Z`.

Граница названа прямо: **воспроизводимость документа здесь есть свойство
БАЙТОВ входа, а не смысла программы** — реплей требует байтовой копии входа,
а не тождества значений. Граница выбрана не ценой перевыпуска, а нормой: (i)
ответ от записи не страдает, его держит §57; (ii) errata E-0212 сделала
смещение оси `decision_time` семантически значимым — §135.1 читает дату
решения «в том смещении, в котором ось записана делом», и перевод в UTC
сдвинул бы календарную дату статуса позиции, то есть исход дела; (iii) §35
имеет `OffsetDateTime` ровно для случая «запись со смещением как отдельное
значение», а `de.surrender.act1945` и `intl.minsk.package_2015` записали
смещение НАМЕРЕННО, выведя его из текста акта («Central European time»,
«киевское время»).

Отсюда и расхождение схем, которое НЕ является противоречием: `InstantString`
у `legal-ir` и `evaluation` смещение разрешает, потому что судит запись
ЗНАЧЕНИЯ; `InstantString` у `parameter-dataset` требует `Z`, потому что судит
границу ПОКРЫТИЯ A3 — ось, а не значение, и у оси одна запись по построению
(§188). Два определения одного имени отвечают на два разных вопроса, и
сведение их к одному сделало бы ось либо двусмысленной, либо значение
неканоничным.

До errata запись читалась средствами языка реализации (класс E-0076, E-0197):
`decimal.Decimal` снимал пробелы, разрешал `_` и принимал `Infinity`/`NaN`;
`int()` снимал юникодные пробелы, разрешал `_` и читал любую категорию Unicode
`Nd`, отчего `"١/٢"` и `"１/２"` становились значением `1/2`; `BigInt::from_str`
принимал `_`; а валидатор десятичной записи движка судил ОБРЕЗАННУЮ строку и
возвращал НЕОБРЕЗАННУЮ — пробел доезжал до хэшируемых байтов, и `resultHash`
двух реализаций на одном документе расходился без единой диагностики с обеих
сторон.

Величина в сообщение НЕ ПЕЧАТАЕТСЯ, и два рода отказа — float и выход за
диапазон — НЕ РАЗЛИЧАЮТСЯ. Оба запрета следуют из того, что к моменту
канонизации число уже разобрано JSON-парсером хоста, и разбор необратим:
целое `-9223372036854775809` приходит в реализацию, чей `Number` хранит
i64/u64/f64, как `-9.223372036854776e18` — напечатанная величина была бы не
той, что в файле, а род отказа читался бы у одной реализации и не читался у
другой. Различение по хосту есть свойство языка реализации, а не канона
(§170: байты документа и формулировки его сообщений — контракт). Место
нарушения полностью называет путь.

## 209. Theory hash и artifact hash

Начиная с `law.core/0.2`, один `semanticHash` разделён на два независимых
ключа. `theoryHash` идентифицирует право, `artifactHash` — конкретный CLIR с
его provenance. Оба — SHA-256 канонической проекции §208; оба поля записаны в
CLIR и EvaluationManifest, поэтому `resultHash` связывает юридический ответ с
обеими идентичностями.

`theoryHash` включает:

- normalized declarations;
- exact imported package semantic hashes;
- feature set;
- language semantics version.

Ревизия семантики (errata E-0156, DECISION-0166 §4.5) — ТОЧНАЯ строка: `semanticsId` реестра `spec/feature-registry.json` для объявленной версии языка (`0.1` → `0.1.0`, `0.2` → `0.2`); нормализации префикса, читавшей `0.1*` как одну ревизию, нет — версия вне реестра отвергается (`LDC-E1401`). Стандартная библиотека `law.std` есть часть языка: её словарь (`packs/std/`, §257–§266) не входит в список хэшей импортированных пакетов, и идентичность std держится ЭТОЙ ревизией — семантическая проекция каталога заморожена под ней хэшем в `packs/std/index.json`, а расширение std требует новой ревизии в реестре языка (ворота `check_std_catalogue`).

Он не включает:

- comments;
- whitespace;
- local source paths;
- diagnostics;
- non-semantic annotations;
- labels (§218);
- `anchors`, `provenance` и `sourceSpan`;
- `publication`-узлы (§27.3);
- узлы `anchor` (§33.2, DECISION-0358).

`artifactHash` включает точный нормализованный CLIR, в том числе `anchors`,
`provenance`, `sourceSpan`, annotations, metadata и publication-узлы. Из его
preimage исключаются только производные поля хэшей (`contentHash`,
`semanticHash`, `theoryHash`, `artifactHash`) и рекурсивные `labels`:
presentation-перевод не создаёт новый юридический или provenance-артефакт.
`SourceEdition.documentHash` входит в обе проекции.

Legacy `semanticHash` и его preimage ниже являются контрактом режима 0.1;
писатель 0.2 их не использует как идентичность теории.

**`supersedes` события §81.1 исключением `provenance` НЕ покрыт.** Исключение
выше снято с ПОЛЯ УЗЛА `provenance` (§202) — слоя происхождения артефакта.
Поле `supersedes` конструктора события есть поле ЗНАЧЕНИЯ, и оно меняет
исполняемую историю: голова цепочки версий определяет и порядок событий
§79.1, и привязку попытки перехода §161.1, то есть исход дела. Поэтому оно
входит в каноническую проекцию §208 и в обе проекции §209 наравне с `time`;
два события, различные только `supersedes`, суть разные значения. Слово
«провенанс» в §81 описывает НАЗНАЧЕНИЕ поля для читателя, а не его место в
хэше (DECISION-0156, errata E-0147).

Annotation должна объявить `semantic = true`, чтобы попасть в hash; это возможно только для imported feature profile.

`Publication` исключены как слой манифестации (errata E-0013). §27.3 определяет publication как конкретный файл: identity публикации зависит от bytes, и один edition может иметь их несколько (XML, PDF, HTML). Ни одно из этих обстоятельств не меняет ни одной нормы, поэтому повторное получение того же документа, замена формата и добавление второй публикации той же редакции НЕ ДОЛЖНЫ менять semantic hash пакета. Исключение НЕ распространяется на `SourceEdition`: `documentHash` редакции — идентичность Expression, то есть того, что формализовано, и остаётся в hash полностью. Целостность самой публикации обеспечивается её content hash узла (§202) и проверками §194, а не идентичностью пакета.

Узлы `anchor` исключены как слой провенанса (DECISION-0358, errata E-0240). Узел материализует атрибуты связи `@source` — `relation`, `coverage` и цитату `quote` §33.2 — и уточняет трассировку, а не право: перестановка цитаты или смена `coverage` не меняет ни одного вывода, и по тому же основанию, по которому DECISION-0111 §2.6 вывел поле `anchors` из идентичности теории, узел вне `theoryHash`. В `artifactHash` он входит целиком; legacy `semanticHash` 0.1 и построенный на нём `programHash` манифеста §170 включают его как любой узел — постановка цитаты есть перевыпуск провенанса пакета, видимый пинам `law.lock` потребителей при неизменных исходах. Документ с узлом `anchor` пишется `schemaVersion: "law.core.ir/0.4"` по правилу DECISION-0156 §2.9: конверт объявляет минимального читателя, документ без такого узла остаётся 0.2/0.3 байт в байт. Конверт входит в preimage теории, поэтому первый узел `anchor` в пакете сдвигает `theoryHash` версией документа — как первый узел `procedure` сдвигал его на 0.3; сами узлы `anchor`, их число и текст цитат `theoryHash` не меняют.

Labels исключены как презентационный слой (errata E-0010). §218 закрепляет, что смена отображаемого языка не меняет IDs и semantics; следовательно, добавление перевода метки и переформулировка её текста НЕ ДОЛЖНЫ менять semantic hash. Исключение действует рекурсивно — на всех носителях поля `labels`, включая элементы внешних datasets. Официальный текст меткой НЕ является: `Fragment.texts` и его content hash (§13, §194) входят в semantic hash в полном объёме. Метки остаются в content hash узла (§202): правка метки видна инкрементальности (§212) и потребителям, привязанным к content hash узла, но не является изменением семантики программы.

---