# Часть VII. Source и document model

## 27. Три уровня идентичности источника

Core различает:

1. `source` — абстрактный правовой или документарный Work;
2. `edition` — конкретное содержание, язык и редакция Expression;
3. `publication` — конкретный файл или опубликованное представление Manifestation.

### 27.1. `source`

```law
@id("urn:lex:kz:minister-order:343")
pub source ORDER_343 {
    kind kz.sources::MinisterOrder;
    jurisdiction KZ;
    authority entity_ref("urn:org:kz:authority:example");
    number "343";

    label kk-KZ official "...";
    label ru-KZ official "...";
}
```

`kind` является URI-addressable symbol из jurisdiction profile, а не hard-coded enum Core.

`basis` (аддитивно, DECISION-0042; повторяемое, DECISION-0046) — основание издания подзаконного акта: StableId power-нормы §127 уполномочившего акта, то есть то, что сам акт называет в преамбуле («издан в соответствии с пунктом 1 статьи 34 закона Y»). Поле **повторяемое**, и значение его — всегда массив, даже при одном основании: акты стоят на нескольких нормах сразу (приказ V2000021744 — «в соответствии с подпунктом 62) статьи 7 Кодекса ... и пунктом 1 статьи 34 Закона ...»), а форма, зависящая от их числа, заставила бы потребителя разбирать два вида одного поля.

```law
source RULES_21744 {
    kind kz.sources::MinisterOrder;
    number "V2000021744";
    basis "urn:kz:corpus:clir:osms#DetermineProcurementProcedure";
    // второе основание того же акта объявляется повторением поля
    authority entity_ref("urn:kz:corpus:clir:osms#AuthorisedBodyOfHealth");
}
```

Поле несёт СТРОКУ, а не квалифицированную ссылку `pkg::name`, и это различие содержательно: **делегация не есть импорт**. Импорт §23 втягивает программу импортируемого пакета в мир вычисления, а подзаконный акт уполномочивший закон не исполняет — он на него ссылается. Требовать импорт ради цитирования значило бы менять семантику вычисления ради провенанса.

Отсюда граница: компилятор пакета разрешимость основания НЕ доказывает — уполномочившего акта у него на входе нет. Её проверяет делегационная цепочка, читающая CLIR родителя отдельно: основание разрешается в power-норму (`LDC-E5304`), она действовала на дату принятия (`LDC-E5305`), издатель совпадает с holder (`LDC-E5306`).

Неприменимость родителя на дату принятия имеет ДВЕ разные причины, и смешивать их нельзя (DECISION-0045). Родитель мог на эту дату не действовать — это вывод о компетенции, `LDC-E5305`. Но родитель мог существовать, а корпус закрепить только более поздние его редакции: тогда о компетенции сказать нечего, и `LDC-W5303` называет пробел ДОКАЗАТЕЛЬСТВА. Признак второго — акт принят после принятия родителя, но раньше самого раннего открывающего события §31 всех закреплённых редакций. Форма эта не экзотическая: так выглядит любой корпус, пиннящий действующую консолидацию. Если `authority` задан формой, не называющей орган поимённо, сверка издателя не выполняется и говорит об этом (`LDC-W5301`) — «объявлено и не прочитано» обязано отличаться от «не объявлено».

`regulates` (аддитивно, DECISION-0043) — **предмет самого акта**: что он собой регулирует, теми же идентификаторами словаря уполномочившего акта и строками по той же причине, что и `basis`. Поле повторяемое. Цепочка сверяет включение `regulates ⊆ subject` power-нормы §127; излишек даёт `LDC-E5307`, необъявленный предмет полномочия — `LDC-W5302`. При нескольких основаниях предмет сверяется против ОБЪЕДИНЕНИЯ их предметов: акт, стоящий на двух нормах, вправе регулировать то, что дают обе, и требовать покрытия каждой по отдельности значило бы запретить обычную составную делегацию.

Сравнение идёт **внутри одного пространства имён** (DECISION-0047). Пакетно-квалифицированный `ns#Local` называет узел своего пакета, голый URN — сущность напрямую; пара из разных пакетов общей наименовательной власти не имеет, и `health-code#AuthorizedHealthBody` против `osms#AuthorisedBodyOfHealth` — один орган под двумя именами, а не разные органы. Не сумев сравнить, цепочка даёт `LDC-W5304` с указанием звена (`organ` | `subject` | `parent`), а не вердикт: вывести нарушение из невозможности сравнить — та же ошибка, что вывести его из незакреплённой редакции. По той же причине основание адресуется родителю по пространству имён. Родителей вызов принимает НЕСКОЛЬКО (DECISION-0048), и это не удобство: пока родитель был один, у акта на двух основаниях половина предмета всегда оставалась несопоставимой, и предметная компетенция не устанавливалась ни одним вызовом. Дата и издатель считаются у своего родителя, предмет — один раз против объединения предметов всех разрешившихся полномочий. Два пробела называются порознь: основание, не адресованное ни одному поданному родителю («проверить нечем»), и поданный родитель, к которому не адресовано ни одного основания («здесь не проверено ничего»).

`basis` и `regulates` входят в semantic hash §209: это утверждения пакета о праве, а не оформление, — в отличие от меток §218, вынесенных из preimage erratой E-0010.

### 27.2. `edition`

```law
@id("urn:lex:kz:minister-order:343:2025-01-01:ru")
pub edition ORDER_343_2025_RU of ORDER_343 {
    language ru-KZ;
    officiality official;
    adopted @2024-12-01;
    published @2024-12-20;
    in_force [@2025-01-01, infinity);
    content_hash "sha256:...";
}
```

Одна редакция на двух языках обычно представляется двумя editions, связанными alignment relation. Это позволяет не предполагать автоматическую идентичность смысла.

У edition без исторической точки вступления в силу (например, Писание или
доктрина) применяется только явная запись:

```law
edition WLC of TORAH {
    language he;
    officiality unofficial;
    applicability timeless;
}
```

`timeless` означает применимость при любом `legal_time`, не создаёт принятия
или вступления в силу и ДОЛЖЕН сочетаться с пустым `lifecycle`. Смешение с
`adopted`, `in_force`, отменой либо иным lifecycle-событием — error
`LDC-E5308`: это две
несовместимые модели одной edition. В частности, отсутствие `lifecycle` БЕЗ
`applicability timeless` **не** делает edition применимой: оно сохраняет
обычное `not_yet`, чтобы неполные данные о действующем акте не стали правом
молча.

`edition` несёт `materializationStatus` — насколько байты редакции действительно закреплены (errata E-0013, PATCH-0.1.1 §9 в узкой форме):

```text
PINNED_OFFICIAL_BYTES            // закреплены байты официальной публикации
PINNED_UNOFFICIAL_COPY           // закреплена копия, официальным опубликованием не являющаяся
PINNED_EDITORIAL_RECONSTRUCTION  // закреплена реконструкция редактора; оригинала,
                                 // копией которого она была бы, не существует (errata E-0057)
DYNAMIC_OFFICIAL_PAGE            // адрес указывает на изменяемую страницу; байты не закреплены
ABSTRACT_ONLY                    // хранится только правовая абстракция статьи, текста нет
UNAVAILABLE                      // текст недоступен
```

Три первых статуса образуют ГРУППУ ЗАКРЕПЛЁННЫХ: у редакции есть байты, и их
можно сверить с названным источником. Требования профилей §8.6 читаются по
группе, а не по месту в перечне: `core-representation` допускает любой статус;
`core-auditable` требует статус из группы закреплённых; `core-production`
требует `PINNED_OFFICIAL_BYTES` безусловно. Статус ДОЛЖЕН объявляться, а не
выводиться из наличия публикации: отсутствие закреплённых байтов есть заявление
о качестве источника и обязано быть видимым в самом пакете.

`PINNED_EDITORIAL_RECONSTRUCTION` (errata E-0057) отличается от
`PINNED_UNOFFICIAL_COPY` не степенью закрепления, а ОТНОШЕНИЕМ байтов к акту.
«Копия» есть утверждение о существовании оригинала, копией которого она
является: у неофициальной публикации закона такой оригинал есть — официальная
публикация, — и расхождение с ним можно в принципе установить. У реконструкции
оригинала нет ни в каком виде: издатель собирает текст из цитат в чужих
сочинениях и приписывает собранному структуру. Сверять реконструкцию не с чем,
и назвать её копией значило бы утверждать отношение, которого не существует.
Статус говорит именно это и ничего сверх: байты закреплены и сверяемы С
ИЗДАНИЕМ, но издание — не свидетель текста, а его гипотеза. Обязанность §194
(вхождение текста фрагмента) и обязанность §28 (`content_hash` фрагмента,
errata E-0024) под этим статусом действуют полностью: они спрашивают о
соответствии ЗАКРЕПЛЁННОМУ ДОКУМЕНТУ, а этот вопрос осмыслен независимо от
того, чем документ приходится акту.

Граница статуса узка, и мимо неё легко пройти в обе стороны. Реконструкция —
это документ, ВЫДАЮЩИЙ СЕБЯ ЗА ВОССТАНОВЛЕННЫЙ ТЕКСТ акта; документ ОБ АКТЕ
реконструкцией не является, даже если приводит его положения. Второй случай
выражается не статусом, а СТРУКТУРОЙ: вторичное произведение объявляется
своим `source` со своей редакцией (относительно него «копия» правдива), а у
акта остаётся редакция с честным `UNAVAILABLE`. Смешение этих двух форм
означает утверждение, что вторичный текст есть издание акта.

В каталожной метадате пакета (DECISION-0051) этому статусу соответствует
значение `sourceFidelity = "reconstruction"` — то самое, что уже существовало
как надстроечное; значения `pinned_editorial_reconstruction` там НЕТ, и
словари двух слоёв намеренно не совпадают: §27.2 говорит о закреплении байтов,
`sourceFidelity` — о происхождении текста.

### 27.3. `publication`

```law
publication ORDER_343_2025_RU_XML of ORDER_343_2025_RU {
    media_type "application/xml";
    uri "...";
    content_hash "sha256:...";
    retrieved_at @2026-08-25T09:00:00Z;
}
```

Publication identity зависит от bytes. Один edition может иметь несколько publications: XML, PDF, HTML.

**Байты публикации не входят в CLIR** (errata E-0013). Документ несёт только узел `publication` — канонический `uri`, `mediaType`, `documentHash` и `retrievedAt`; сами байты хранятся отдельным закреплённым артефактом и подаются потребителю так же, как ресурс календарного снапшота §85 подаётся рядом со своим `datasetHash`. Разрешение локального размещения байтов ведётся через `metadata` документа (§209 «local source paths») и семантикой не является: пакет, перенесённый в другое хранилище, не меняет ни semantic hash, ни один content hash узла.

`retrievedAt` фиксирует момент, когда байты были получены, и ДОЛЖЕН быть закреплённой константой артефакта. Получение документа не является частью сборки или вычисления: ни компилятор, ни evaluator не обращаются к сети (§211 — детерминизм, §60 — доступ к внешним данным только через declared capability и snapshot binding).

## 28. Fragment

```law
@id("urn:lex:kz:minister-order:343:2025-01-01:ru#art125-p3")
pub fragment BVR_125_3_RU in ORDER_343_2025_RU {
    kind paragraph;
    locator "article/125/paragraph/3";
    parent BVR_125_RU;

    text ru-KZ official """
    ... официальный текст ...
    """;

    content_hash "sha256:...";
}
```

Fragment ДОЛЖЕН иметь стабильный ID. Номер статьи является locator metadata, но не единственным основанием идентичности.

Fragment — **выборка адресуемого**, а не способ хранить документ целиком (errata E-0013). Его текст остаётся inline и входит в semantic hash полностью: это основание формализации, и его расхождение с официальным текстом §194 квалифицирует как error. Именно поэтому полнота акта НЕ добирается заведением фрагментов под неформализованные части: их текст не имеет отношения к семантике пакета, а в hash попал бы наравне с основанием нормы. Полный текст документа хранится на уровне publication (§27.3), полнота покрытия измеряется против него (§33.1).

Текст фрагмента ДОЛЖЕН байтово встречаться в закреплённой публикации своей редакции, если такая публикация есть (§194). Это единственная машинная гарантия того, что формализованный текст взят из документа, а не набран заново.

`content_hash` фрагмента отвечает на ДРУГОЙ вопрос — не «откуда взят текст», а «менялся ли он с момента закрепления», — и одно другого не заменяет: вхождение §194 проверяется подпоследовательностью, поэтому усечённый текст остаётся вхождением, а хэш такое усечение ловит. Поэтому у редакции, объявившей `materializationStatus` из группы закреплённых (§27.2), официальный текст каждого её фрагмента ДОЛЖЕН нести `content_hash`; отсутствие — error `LDC-E5205` (errata E-0024). Вне группы обязанности нет: `ABSTRACT_ONLY` означает, что текста нет вовсе, и требовать его digest не от чего. Обязанность выведена из ЗАЯВЛЕНИЯ редакции, а не из наличия публикации, — по тому же основанию, по которому §27.2 требует объявлять статус, а не выводить его.

## 29. Alignment мультиязычных фрагментов

```law
align BVR_125_3_RU with BVR_125_3_KK {
    relation corresponding_official_text;
    status reviewed;
    reviewer LEGAL_EDITOR_17;
}
```

Alignment не создаёт логическую эквивалентность формализаций.

## 30. Reference

### 30.1. Static reference

Указывает на точный edition/fragment:

```text
source_anchor BVR_125_3_RU;
```

В surface-аннотации этому соответствуют три намеренно разные формы
`@source(...)`: bare local fragment (`@source(BVR_125_3_RU)`) разрешается в
StableId текущего пакета; строка (`@source("archive:…")`) остаётся непрозрачным
внешним адресом для совместимости; `@source(pkg.name::FRAGMENT)` —
межпакетная ссылка. Последняя допускается только на `pub fragment` зависимости,
предъявленной закреплённым resolve-контекстом (§11, §23–§24): compiler сверяет
dependency pin, имя в exports и `exportKinds[FRAGMENT] == "fragment"`. Это не
обычная ссылка на symbol: provenance без конкретного публичного фрагмента не
является проверяемой связью с текстом.

### 30.2. Dynamic reference

```law
reference CURRENT_ART_125 {
    source ORDER_343;
    locator "article/125/paragraph/3";
    resolve_at legal_time;
    policy kz.sources::OfficialEditionResolver;
}
```

При evaluation dynamic reference ДОЛЖНА разрешиться в static reference. Результат записывается в EvaluationInputManifest. В 0.1 единственная ось разрешения — `legal_time` контекста (`resolve_at legal_time`); язык редакции выбирает названная `policy` по `context.language`.

## 31. Lifecycle

Lifecycle events могут включать:

```text
adopted
published
in_force
suspended
restored
repealed
expired
invalidated
```

Core не hard-code-ит юридические последствия этих labels. Jurisdiction profile определяет, какие статусы участвуют в applicability. `in_force` имеет стандартный смысл: edition потенциально применимо на legal axis, но дополнительные transition/scope rules могут ограничивать применение.

## 32. Revision graph

```law
revision AMENDMENT_2026 {
    previous ORDER_343_2025_RU;
    next ORDER_343_2026_RU;
    caused_by LAW_123_2026_RU;
    relation supersedes;
    effective @2026-07-01;
}
```

Допустимые стандартные relations:

```text
supersedes amends replaces inserts deletes
suspends restores repeals invalidates consolidates derived_from
```

Revision graph ДОЛЖЕН быть immutable. Consolidated edition является новым edition с provenance chain.

## 32.1. Операции поправки

Ребро revision МОЖЕТ нести операции — формализованную дельту изменяющего акта. Ребро без операций остаётся аннотацией связи; ребро с операциями ДОЛЖНО удовлетворять инварианту консолидации (§32.2).

```law
revision LAW_123_2026 {
    previous ORDER_343_2025_RU;
    next     ORDER_343_2026_RU;
    caused_by LAW_123_2026_RU;
    relation amends;

    op replace {
        locator "article/5/paragraph/2";
        language ru;
        text """…текст пункта в редакции поправки…""";
        effective @2026-07-01;
    }
    op repeal {
        locator "article/7";
        effective @2026-07-01;
    }
}
```

Операций ровно четыре:

```text
replace     локатор существует в previous; текст заменяется
insert      локатор в previous отсутствует; фрагмент добавляется
repeal      локатор существует в previous; фрагмент изымается
renumber    локатор существует в previous; фрагмент получает новый локатор
```

**Операции экстенсиональны.** Операция несёт *результат* — текст, который фрагмент имеет после поправки, — а НЕ инструкцию изменяющего акта («слова „X“ заменить словами „Y“ в соответствующем падеже»). Инструкции естественного языка разрешает человек при формализации; машина проверяет результат (§32.2). Порождающей морфологии в ядре нет (ср. §218.1).

**Приостановление операцией не является.** Relations `suspends` / `restores` (§32) действуют на уровне редакции и выражаются событиями lifecycle §31. Операция над текстом их дублировать НЕ ДОЛЖНА.

**Обратных операций нет.** Отмена поправки, признание акта недействительным и восстановление прежнего регулирования выражаются НОВЫМ ребром вперёд, а не откатом существующего. Это следствие immutability revision graph и того обстоятельства, что отмена изменяющего акта в общем случае не восстанавливает прежнюю редакцию.

### Порядок применения

`effective` — атрибут ОПЕРАЦИИ, а не ребра: акт может вводиться поэтапно, и разные его пункты вступают в силу с разных дат. Порядок применения:

1. по возрастанию `effective`; операция без `effective` наследует `effective` ребра, а при его отсутствии применяется первой;
2. при равных `effective` — в порядке объявления операций: последовательность самого изменяющего акта авторитетна.

Порядок ДОЛЖЕН быть полностью детерминирован (§211); ambient-время в применении не участвует. Две операции с совпадающей парой *(локатор, язык)* и равным `effective` — дефект данных: `LDC-E5403`.

## 32.2. Инвариант консолидации

Для ребра с операциями ДОЛЖНО выполняться

```text
apply(previous, operations) ≡ next
```

где сравнение ведётся по проекции фрагментов §29 — множеству пар *(локатор, язык)* → байты текста. Нарушение — error `LDC-E5401`.

Инвариант ловит два различных класса дефектов одной проверкой: ошибку формализации дельты и **расхождение официально опубликованной консолидации с текстом самого изменяющего акта**.

Расхождение НЕ ДОЛЖНО разрешаться автоматическим предпочтением одной из сторон: ни вычисленная консолидация, ни опубликованная не объявляются истинной по умолчанию. Расхождение объявляется и остаётся видимым — тот же способ обращения с конфликтом, что и в §158, где расхождение аутентичных языковых редакций сообщается, а не устраняется выбором.

Проверка выполняется по текстам фрагментов CLIR и файловой системы не требует. Соответствие этих текстов байтам закреплённой публикации — отдельная проверка §194 (`LDC-E5202`), и она не подменяется настоящей.

### Диагностики

```text
LDC-E5401 CONSOLIDATION_MISMATCH        apply(previous, operations) != next
LDC-E5402 OPERATION_TARGET_NOT_FOUND    replace/repeal/renumber несуществующего локатора;
                                        insert существующего
LDC-E5403 OPERATIONS_OVERLAP            две операции на (локатор, язык) без порядка
LDC-E5404 MIGRATION_BASE_MISMATCH       операция применяется к редакции, не являющейся previous
LDC-E5405 DANGLING_LOCATOR              после renumber в next остались ссылки на старый локатор
```

Неизменяемое ядро источника проверяется на множестве операций ДО применения — множество затронутых положений получается из самих операций, и указание на нарушение адресует конкретную операцию конкретного акта. Затрагивание защищённого locator-а есть error `LDC-E5301 ENTRENCHED_FRAGMENT_CHANGED`; это отдельный код диапазона source/provenance, а не неформальная оговорка рядом с графом revision. Декларация защищённого положения, область действия по source work и временное окно определены в §32.3.

## 32.3. Entrenchment

Пакет МОЖЕТ объявить неизменяемое положение источника так:

```law
entrenchment EQUAL_SENATE_SUFFRAGE {
    source US_CONSTITUTION_1787;
    locator "article/V/last-proviso";
    window [@1789-03-04, infinity);
}
```

`source` называет `source_work` §27; `locator` защищает ровно это положение и его потомков по сегментам `/` (поэтому `article/2` защищает `article/2/paragraph/7`, но не `article/20`). `window` задаёт legal-time интервал: начало включительно или исключительно в точности как записано, конец `)` не входит. Тем самым срочная оговорка выразима без второго расширения, например `window [@1789-03-04, @1808-01-01)` означает «защищено до 1808 года».

Для каждого `revision` с operations компилятор и оракул ДОЛЖНЫ до применения операций сопоставить source work его `previous` edition с `source` декларации. Если операция затрагивает защищённый locator в момент её `effective` (либо `effective` ребра при отсутствии собственного), она ДОЛЖНА быть отклонена `LDC-E5301`. Отсутствующий момент трактуется консервативно: операция не считается заведомо вне временной защиты. Проверка ограничена текстовой дельтой §32.1: добавление отдельного locator-а, семантически противоречащее защищённому положению, само по себе ею не обнаруживается и должно быть видно в форме конфликта литералов §115.

## 33. Anchor

Любой semantic node МОЖЕТ иметь несколько anchors:

```text
@source(BVR_125_3_RU, relation = formalizes, coverage = exact)
@source(BVR_125_3_KK, relation = formalizes, coverage = exact)
rule BVR_DISTANCE defeasible { ... }
```

Стандартные relations:

```text
formalizes
interprets
quotes
paraphrases
derives_from
applies
limits
invalidates
distinguishes
```

Coverage:

```text
exact partial contextual disputed
```

Anchor не доказывает юридическую корректность формализации; он обеспечивает трассировку.

### 33.2. Цитата места нормы и узел `anchor` (DECISION-0358, errata E-0240)

Якорь на пункт целиком отвечает «откуда норма», но не «из какого места пункта».
Именованный атрибут `quote` называет это место точной цитатой:

```law
@source(BVR_125_3_RU, relation = formalizes, coverage = partial,
        quote = "дистанция должна позволять избежать столкновения")
rule BVR_DISTANCE defeasible { ... }
```

`quote` — строковый литерал с escape §17 либо text block. Цитата ДОЛЖНА быть
**непрерывной подстрокой** `text` хотя бы одного из текстов фрагмента, байт в
байт, без нормализации (§13) — та же дисциплина, что у вхождения §194:
проверяется вхождение, а не смещение, потому что смещения плывут при каждом
перезакреплении публикации, а вхождение нет. Несовпадение, пустая цитата и
нестроковое значение — error `LDC-E5208` (§194). Проверка ведётся по паре
*(аннотация, локальный фрагмент файла)* и файловой системы не требует; чужой
фрагмент (`pkg::F`) и непрозрачный строковый якорь не проверяются — их текста
у компилятора нет. Цитата на аннотацию с несколькими фрагментами обязана
входить в каждый из них. Цитата необязательна: `coverage = partial` без
`quote` остаётся законной формой.

Аннотация `@source`, несущая хотя бы один именованный атрибут (`relation`,
`coverage`, `quote`), материализуется узлом `anchor` (§28, §202) — по одному
на каждый свой фрагмент и каждый узел, порождённый декларацией (в тех же
границах, что поле `anchors`: у интерпретации — только её собственный узел):

```json
{ "kind": "anchor", "id": "<StableId узла>/anchor/<k>",
  "semanticNode": "<StableId узла>", "sourceFragment": "<StableId фрагмента>",
  "relation": "formalizes", "coverage": "partial", "quote": "…" }
```

`k` — позиция фрагмента в массиве `anchors` узла, с единицы. Умолчания:
`relation` → `formalizes`; `coverage` → `partial` при наличии `quote`, иначе
`exact`. Голый `@source(F)` без атрибутов узла НЕ порождает: поле `anchors`
остаётся единственным носителем связи, и документ без атрибутов не меняется
ни байтом. Развёртка §210.2 наследует только позиционные якоря (E-0183) и
узлов `anchor` не порождает. Узел `anchor` — слой провенанса: он вне
`theoryHash`, внутри `artifactHash` и legacy `semanticHash` (§209); документ
с таким узлом пишется `schemaVersion: "law.core.ir/0.4"` (§209). Вербализация
узла цитату не печатает; proof-граф и мера §33.1 читают поле `anchors` и от
узла не зависят.

## 33.1. Formalization coverage

Для честного утверждения о покрытии каждый fragment получает один или несколько уровней:

```text
SOURCE_ONLY   // текст сохранён и адресуем
ANCHORED      // есть связь с semantic node
STRUCTURED    // выделены участники, условия, последствия, ссылки
SEMANTIC      // задана формальная интерпретация
EXECUTABLE    // входит в core-executable profile
VERIFIED      // прошёл юридические, технические и conformance проверки
DISPUTED      // существуют конкурирующие интерпретации/возражения
```

`DISPUTED` является orthogonal flag и может сочетаться с `SEMANTIC` или `EXECUTABLE`. Coverage report должен считать отдельно text coverage, semantic coverage и executable coverage. Система не должна выдавать «100% формализовано», если часть фрагментов имеет только `SOURCE_ONLY`/`ANCHORED`.

Уровни `SOURCE_ONLY`, `ANCHORED`, `SEMANTIC` и `EXECUTABLE` **вычисляются из самого CLIR** и авторской разметки не имеют (errata E-0013): наличие `anchors`, наличие ссылающегося semantic node, вхождение этого узла в `core-executable`. Авторскими остаются только `VERIFIED` и ортогональный `DISPUTED` — у них нет машинного признака. С принятием контура утверждений (`decisions/0006-approvals.ru.md`) у `VERIFIED` появляется **необходимый** машинный признак: действующее утверждение вербализованного блока статуса `approved`, не перешедшее в stale (`LDC-E8202`). Достаточным он не является — уровень по-прежнему требует технических и conformance-проверок, и разметка `VERIFIED` без них остаётся авторским утверждением. Разметка уровня руками означала бы, что ошибка автора молча меняет отчёт о полноте, то есть ровно то утверждение, ради честности которого §33.1 существует.

**Text coverage измеряется против байтов закреплённой публикации** (§27.3): доля документа, покрытая текстами фрагментов. Без закреплённой публикации text coverage не определён, и отчёт обязан сообщать это, а не показывать 100 % по множеству заведённых фрагментов.

---