# Часть XI. Assertions, facts и evidence

## 71. Assertion

Assertion квалифицирует literal:

```law
assert "assert-acme-registered": registered(ACME) {
    valid [@2024-03-12, infinity);
    observed @2026-08-25T09:00:00+05:00;
    recorded @2026-08-25T09:00:03+05:00;
    evidence REGISTRY_RECORD_991;
    origin external_snapshot;
}
```

Explicit negative assertion:

```law
assert not registered(ACME) {
    evidence COURT_DECISION_17;
}
```

DECISION-0187 позволяет вынести строковый StableId §14 в заголовок:
`assert "assert-acme-registered": registered(ACME);`. Это то же поле `id`,
что у source-узлов и evidence (ERRATA E-0027); прежняя форма допустима:

```law
assert registered(ACME) {
    id "assert-acme-registered";
}
```

Без `id` идентификатор порождается реализацией. Явный `id` обязателен там, где
на assertion ссылаются извне его файла — premises proof graph §180 адресуют
assertion по StableId, а case-файл §168 хэшируется целиком (`case_hash` §170),
поэтому неустойчивый идентификатор менял бы хэш дела при неизменном содержании.

## 72. Temporal dimensions assertion

Минимально поддерживаются:

- `valid` — когда утверждение относится к миру/правовому состоянию;
- `observed` — когда событие или состояние было наблюдено;
- `recorded` — когда assertion вошло в систему.

Это позволяет bitemporal и audit queries.

Грубость литерала у `observed` и `recorded` — авторская: грамматика даёт им
`temporal_literal`, и допустимы обе формы, `Date` и `Instant`. Обещание тем
самым слабее, чем у `complete_as_of` §70: там значение СРАВНИВАЕТСЯ с моментом
и `Date` был бы неявным `Date -> Instant`, запрещённым §48, — здесь значение
никем не сравнивается, кроме проверки порядка §196, а она сопоставляет только
литералы ОДНОЙ грубости и молчит на разных, потому что их порядок решает
политика §82 (то же правило, что у §193). Поэтому запись даты не является
неявным преобразованием: она остаётся датой и в CLIR (`observedAt`,
`recordedAt` — `DateString | InstantString`, как у концов интервала §20).

`evidence` §74 этой свободы НЕ разделяет: там `observed_at`/`recorded_at`
описывают документ, у которого момент выдачи и момент наблюдения различимы по
существу, и реализация отвергает дату громко (`LDC-E1307`). Разная строгость
двух соседних полей — следствие разной роли, а не недосмотр.

## 73. Origin

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

```text
case_input
source_asserted
external_snapshot
derived
adjudicated
assumed_for_simulation
```

`assumed_for_simulation` не должен попадать в regulatory result без явного режима simulation.

`adjudicated` — ответ органа по каналу суждения §47.3; форма ответа и проверка органа — §47.3.1 (errata E-0089): утверждение может нести объект `judgment` {authority, request, payload}, и принимается только при совпадении органа с декларацией и формы payload с `request_schema`.

## 74. Evidence declaration

```law
@id("urn:evidence:registry:991")
evidence REGISTRY_RECORD_991: RegistryRecord {
    issuer BUSINESS_REGISTRY;
    subject ACME;
    issued_at @2026-08-25T08:59:00+05:00;
    observed_at @2026-08-25T09:00:00+05:00;
    valid [@2024-03-12, infinity);
    status verified;
    uri "...";
    content_hash "sha256:...";
}
```

Evidence schema определяется типом evidence, но все evidence items должны иметь stable ID и provenance.

## 75. Support edges

```law
support REGISTRY_RECORD_991 supports registered(ACME) {
    policy OfficialRegistryEvidence;
}

support COURT_DECISION_17 refutes registered(ACME) {
    policy BindingJudgmentEvidence;
}
```

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

```text
supports
refutes
authenticates
measures
reports
establishes
```

## 76. Evidence admissibility

Core не выводит admissibility из числового confidence. Evidence policy должна быть выражена rules/profile:

```law
rule AcceptOfficialRegistry strict {
    for e: RegistryRecord;
    when evidence_status(e) == verified
      and authentic(e)
      and current_for(e, context.legal_time);
    then accepted_evidence(e);
}
```

## 77. Burden и standard of proof

Они представляются rules над evidence graph. Бремя доказывания есть
НОРМАТИВНАЯ ПОЗИЦИЯ §134 над эпистемической целью: обязанность стороны
добиться установленности вопроса в отведённом окне.

```law
rule ClaimantBears defeasible {
    for c: Case;
    for p: Party;
    for i: Issue;
    when claims(c, p, i) and not_known(established_issue(c, i));
    then duty ProveIssue {
        bearer p;
        goal achievement {
            condition established_issue(c, i);
            window [@2026-01-01, @2026-06-01);
        }
    };
}
```

Предмет доказывания — ТЕРМ, а не пропозиция. Ссылочного вида на утверждение
0.1 не определяет, и запись `bears_burden(a, eligible(a, b))` есть
статическая ошибка `LDC-E2109` (errata E-0078/E-0079): вопросы дела
реифицируются собственным типом — перечислением §38 либо entity, — а связь
«вопрос ↔ предикат» пишет норма пакета. Утверждение живёт формулой: `unless`
§150, статус-тест §65, `not_known` §67.

Перенос бремени презумпцией §146 — второе правило и priority §116 над первым,
а не отдельная конструкция.

Proof standard является policy, определяющей, какие support structures
достаточны для `established(P)`. 0.1 не hard-code-ит уголовные, гражданские
или административные стандарты. Там, где достаточность решает орган, она
записывается каналом суждения §47.3 (`external judgment relation … { authority
Court; }`): при недостигнутом стандарте вычисление возвращает
`REQUIRES_JUDGMENT` с типизированным запросом, а ответ приходит adjudicated
assertion §73.

Мост «не доказано → правовой исход» ядро не строит: §136 п. 3 требует для
`violated` явного non-performance, completeness certificate либо adjudication,
и без него статус закрытого окна — `undetermined`. Non liquet разрешает сам
акт — замыканием §70 либо adjudication, — и это и есть содержание института
бремени, а не пробел реализации.

## 78. Provenance

Каждый public semantic node и runtime result ДОЛЖЕН поддерживать:

```text
was_derived_from
was_generated_by
was_attributed_to
used
was_revision_of
was_invalidated_by
```

Canonical IR может сериализовать эти отношения собственным compact representation и экспортировать их в W3C PROV-compatible form.

## 78.1. Epistemic acceptance phase

Raw assertion и accepted logical support — не одно и то же. Перед normative evaluation evaluator применяет выбранную EvidencePolicy:

1. проверяет origin, validity, knowledge cutoff и evidence status;
2. строит support/refutation edges;
3. применяет admissibility, burden и proof-standard rules;
4. помечает assertion как accepted, rejected либо disputed;
5. только accepted assertions формируют начальные `F+` и `F-`.

Case input может приниматься без документа только если mode/policy это явно разрешает. `assumed_for_simulation` никогда автоматически не становится accepted support в regulatory mode. Proof graph сохраняет весь переход raw evidence → accepted assertion.


EvidencePolicy исполняется в отдельном epistemic dependency layer. Она МОЖЕТ зависеть от raw evidence metadata, pinned registries, authentication results и binding adjudications, но НЕ ДОЛЖНА циклически зависеть от normative conclusion, начальную acceptance которой она определяет. Такой цикл (`accept P because duty(P)`, при этом duty создаётся только из P) является `LDC-E4701 EPISTEMIC_ACCEPTANCE_CYCLE`. Если standard of proof требует judicial judgment, judgment поступает как отдельный signed/adjudicated input либо `judgment` capability result, а не скрытый self-support.

---


## 78.2. Исполнимый профиль EvidencePolicy `law.core.evidence-policy/0.1`

§78.1 описывает acceptance-фазу как обязанность реализации, но не задаёт ни
носителя политики, ни её входов, ни формы решения. Настоящий раздел задаёт
**один** исполнимый профиль. Профиль — машинерия ядра; сама политика есть
данные пакета (правила CLIR), и ни одно правило конкретной политики не живёт
в реализации.

### 78.2.1. Носитель: декларация `evidence policy`

```law
evidence policy ExpenseEvidenceV1 {
    profile "law.core.evidence-policy/0.1";
    accepts accepted_support;
    protects paid;
    input edge   support_edge_in;
    input status evidence_status_in;
    field amount doc_amount;
    rule AcceptBankPayment;
}
```

Декларация понижается в узел CLIR `evidence_policy` (`legal-ir.schema.json`)
и является ОБЫЧНЫМ узлом программы: она покрыта `theoryHash` §209 и не может
быть подменена делом.

Пункты декларации:

| Пункт | Кратность | Смысл |
|---|---|---|
| `profile "…"` | ровно один | версия исполнимого профиля; неизвестная — `LDC-E4705` |
| `accepts R` | ровно один | принимающая голова: унарное отношение над StableId опоры (`Text`) |
| `protects R` | ≥ 1 | защищённый эмпирический предикат (§78.2.4) |
| `input <слот> R` | ≤ 1 на слот | привязка слота проекции к отношению пакета |
| `field <ключ> R` | ≤ 1 на ключ | привязка ключа payload evidence к отношению пакета |
| `arg <n> R` | ≤ 1 на позицию | привязка n-го аргумента пропозиции `to` опоры |
| `target P R` | ≤ 1 на предикат | маркер «опора адресует предикат `P`» |
| `rule N` | ≥ 1 | правило acceptance-фазы; состав ЗАКРЫТ этим перечнем |

Открытых metadata у декларации нет: всё, что влияет на результат, названо
пунктом. Неизвестный пункт — `LDC-E4705`.

Профиль `law.core.evidence-policy/0.2` (DECISION-0169) аддитивен к 0.1: он
добавляет слот `input source R` — происхождение документа по композиции
§168.5. Пункт `input source` при `profile "…/0.1"` — `LDC-E4705`;
политики 0.1 исполняются без изменений. Отсутствие факта `source` у
документа не означает доверия: правило политики называет источник
положительно.

### 78.2.2. Единица решения — ОПОРА, а не документ и не факт

Решение принимается для ребра `support_edge` §75, а не для документа §74 и не
для литерала. Один документ может быть принят опорой одного утверждения и не
принят опорой другого.

- принятая опора `supports` даёт положительную поддержку литерала `to`;
- принятая опора `refutes` даёт отрицательную поддержку литерала `to`;
- непринятая опора не даёт поддержки НИ В ОДНО множество, и в частности **не
  является доказательством отрицания** `to`;
- отсутствие сведений о допустимости есть «недостаточно данных», а не
  доказанная недопустимость.

**Полярность (закрытая таблица профиля).**

| `relation` | `to.polarity` | Итог |
|---|---|---|
| `supports` | `positive` | кандидат на F+ |
| `refutes` | `positive` | кандидат на F− |
| `supports` / `refutes` | `negative` | опора отвергается, причина `NEGATED_PROPOSITION` |
| `authenticates`, `measures`, `reports`, `establishes` | любая | не исполнимая связь профиля, причина `RELATION_NOT_EXECUTABLE` |

Отрицательный `to` отвергается явно, чтобы `refutes not P` не вводило
неописанного двойного отрицания. Прочие relations §75 остаются законным
transport-ом и сохраняются в CLIR; исполнимой связью профиля они не являются,
и молчания об этом нет — каждая такая опора называется в отчёте.

**Собственные поля ребра §75 читаются, а не игнорируются.** У `support_edge`
есть `policy` и `valid`, и профиль обязан их рассмотреть: поле, которое
принимается транспортом и молча не влияет ни на что, есть ложное обещание
работы.

| Поле ребра | Условие | Итог |
|---|---|---|
| `policy` отсутствует | — | опора рассматривается выбранной политикой |
| `policy` = StableId выбранной политики | — | то же |
| `policy` = другой StableId | всегда | опора отвергается, причина `EDGE_POLICY_MISMATCH` |
| `valid` отсутствует | — | ограничения по дате права у САМОЙ связи нет |
| `valid` объявлен | покрывает `legalTime` §20 | опора рассматривается |
| `valid` объявлен | не покрывает `legalTime` | опора отвергается, причина `EDGE_NOT_CURRENT` |

Отсутствие `valid` у РЕБРА не равно отсутствию `valid` у ДОКУМЕНТА: документ
без срока годности слота `current` не получает (§78.2.3), а связь без
собственного интервала — законная бессрочная связь. Это разные утверждения о
разных объектах, и правило «нет сведений — нет вывода» относится к первому.

### 78.2.3. Входы политики: типизированная проекция

Профиль строит проекцию сырых evidence/support/verification в ОБЫЧНЫЕ факты
отдельного хранилища. Слоты `input` закрыты профилем:

| Слот | Форма факта | Источник |
|---|---|---|
| `edge` | `R(edgeId: Text, evidenceId: Text, relation: Text)` | каждое ребро §75 |
| `status` | `R(evidenceId: Text, status: Text)` | `evidence_item.status` |
| `issuer` | `R(evidenceId: Text, issuer: Text)` | `evidence_item.issuer`, канонические байты терма |
| `observed` | `R(evidenceId: Text, at: Instant)` | `observedAt` |
| `recorded` | `R(evidenceId: Text, at: Instant)` | `recordedAt` |
| `available` | `R(evidenceId: Text)` | `recordedAt` (при отсутствии — `observedAt`) ≤ `knowledgeTime` |
| `current` | `R(evidenceId: Text)` | объявленный `valid`-интервал документа покрывает `legalTime` |
| `authentic` | `R(evidenceId: Text, verifier: Text, outcome: Text)` | закреплённая проверка подлинности |
| `knowledge` | `R(at: Instant)` | `context.knowledgeTime` |
| `source` (профиль 0.2) | `R(evidenceId: Text, package: Text, case: Text)` | документ, пришедший по `case.sources[]` §168.5; у локального документа факта нет |

Документ относится к источнику `S` из `case.sources[]`, если его StableId
назван в поле `evidence` хотя бы одной записи из `S.records` либо документ
является `from` опоры, экспортированной вместе с такой записью — то есть
относящейся к ней по таблице отбора §168.5 (пропозиция без полярности,
`supports`/`refutes`) И принадлежащей пространству имён поставщика
`S.package.namespace` (поле `package` узла, при его отсутствии — префикс
StableId до `#`). Собственная опора потребителя к той же пропозиции — не
импорт, и её документ факта `source` не получает. Документ,
пришедший из ДВУХ снимков, получает ДВА факта `source`: выбор «первого»
скрыл бы половину происхождения, а слияние в одну запись подменило бы два
утверждения одним. `package` — имя пакета непосредственного поставщика,
`case` — имя его дела; цепочку дальше показывает `provenance[]` записи, а
не этот слот.

Слоты `available` и `current` — единственная временная арифметика профиля.
Оба сравнения ВКЛЮЧАЮТ границу (`≤`, покрытие интервала по §20). Документ без
`valid`-интервала `current` НЕ получает: отсутствие сведений о сроке
годности не есть сведение о годности. Документ без `recordedAt` и без
`observedAt` `available` НЕ получает по той же причине. Часы хоста не читаются
нигде; обе оси приходят из материализованного контекста §89.1.

Слот `field <ключ>` проецирует ОДИН ключ `payload` документа: `R(evidenceId:
Text, value: <объявленный тип>)`. Значение переносится тем же термом, каким
оно записано в CLIR, и проходит ту же сверку сигнатуры §189/§48, что
утверждение дела (E-0046); несовпадение типа — причина `FIELD_TYPE_MISMATCH`
на документе, а не молчаливый пропуск.

**Пропозиция опоры доезжает до правил разобранной, а не термом.** Пункт
`arg <n> R` проецирует n-й аргумент литерала `to`: `R(edgeId: Text, value:
<объявленный тип>)`. Пункт `target P R` проецирует маркер `R(edgeId: Text)`
для каждой опоры, чей `to.predicate` есть `P`. Этой пары достаточно, чтобы
политика сказала «банковское подтверждение подходит опорой ОПЛАТЫ ТОЙ ЖЕ
покупки, о которой документ»: правило соединяет `arg 0` опоры с `field
purchase` документа. Ни `accepted_support`, ни любое другое правило политики
пропозицию как ТЕРМ не получают — §77 (предмет доказывания есть терм, а не
пропозиция) не нарушается.

**Проверки подлинности** приходят отдельным закреплённым входом дела
(`case.verifications`): `{id, evidence, documentHash, verifier, outcome,
recordedAt}`. Профиль проецирует запись в слот `authentic` при выполнении
ОБОИХ условий — привязки к документу и доступности во времени.

| Условие записи | Итог |
|---|---|
| `documentHash` записи = `evidence_item.documentHash` | привязка есть |
| `documentHash` записи ≠ `evidence_item.documentHash` | причина `AUTHENTICATION_HASH_MISMATCH` |
| у документа нет `documentHash` | причина `AUTHENTICATION_UNBOUND` |
| `recordedAt` ≤ `knowledgeTime` | запись доступна |
| `recordedAt` > `knowledgeTime` | причина `AUTHENTICATION_NOT_AVAILABLE` |

`recordedAt` записи ОБЯЗАТЕЛЕН (`InstantString`; неявного `Date → Instant`
нет — §48). Результат проверки подлинности есть такое же сведение о мире, как
сам документ, и подчиняется тому же срезу знания §72: исторический расчёт не
вправе опираться на проверку, которой на момент знания ещё не существовало.
Совпадения хэша для этого недостаточно — хэш отвечает «о том ли документе
запись», а не «была ли она доступна». `documentHash` §74 не смешивается с `contentHash`
узла CLIR: первое — хэш документа, второе — хэш узла. Кем проверка выполнена,
решает ПОЛИТИКА: `verifier` доезжает до правил как значение, и допустимый
перечень проверяющих есть данные пакета.

Поля `issuer`, `status`, `documentHash`, извлечённые из самого документа, себя
не удостоверяют. Профиль не придаёт ни одному значению этих полей привилегии;
`status verified` без основания, названного правилом политики, ничего не
принимает.

### 78.2.3.1. Идентичность входов: один StableId — одно содержание

Документы, рёбра и записи проверки приходят двумя путями — узлами программы и
полями дела — и складываются в таблицы по StableId §14. Совпадение
идентификаторов разрешается СОДЕРЖАНИЕМ, а не порядком массива:

- две записи одного StableId с побайтово равным каноническим содержанием §208
  суть одна запись; дубль сворачивается, причина не возникает;
- две записи одного StableId с РАЗЛИЧНЫМ содержанием — fatal issue
  `EVIDENCE_ID_COLLISION`, фаза не исполняется, результата нет.

Правило одинаково для `evidence_item`, `support_edge` и `case.verifications`,
и одинаково для пары «узел программы + запись дела». С errata E-0158 оно
действует и для `assertion` дела: два утверждения одного StableId с
разным содержимым — fatal `ASSERTION_ID_COLLISION`, равные — одна запись. Оно существует не ради
аккуратности: при разрешении «побеждает последний» перестановка элементов
входного массива МЕНЯЕТ ПРАВОВОЙ ВЫВОД, оставляя оба документа предъявленными
и не сообщая ничего. Разный `caseHash` у разного порядка §170 допустим и
ожидаем; подмена содержания под стабильным идентификатором — нет.

Отказ здесь fatal, а не «отвергнутая опора»: коллизия означает, что
предъявленное дело не задаёт однозначного мира, и выбирать за автора нечего.

### 78.2.4. Полнота границы доверия

При выбранной политике предикат из `protects` НЕ МОЖЕТ войти в `F+`/`F−`
никаким путём, кроме принятой опоры:

1. `assertion` дела с защищённым предикатом не принимается ни при каком
   `origin` (включая `adjudicated` и `external_snapshot`); причина
   `PROTECTED_PREDICATE_REQUIRES_EVIDENCE` записывается в отчёт;
2. `assertion` самой программы (импорт, snapshot-производный узел) — так же;
3. защищённый предикат не может быть головой нормативного правила
   (`LDC-E4703`) и не может быть предметом `closure` §70 (`LDC-E4704`) —
   иначе вывод обошёл бы фазу, оставаясь формально нормативным;
4. параметры вопроса не подтверждают факты: запрос не является входом
   поддержки ни в каком профиле.

### 78.2.5. Порядок исполнения и запрет цикла

Acceptance-фаза исполняется ПОСЛЕ материализации контекста §89.1, разрешения
констант §54 и выбора прочтений §152, но ДО нормативного ingest §71. Она
использует обычный strict-механизм §103 над ОТДЕЛЬНЫМ хранилищем фактов,
видящим только проекцию §78.2.3. Общий `evaluate` рекурсивно не вызывается.

Правила перечня `rule` обязаны быть `strict` (`LDC-E4702`). Транзитивное
замыкание предикатов их тел обязано лежать в объединении «слоты проекции» ∪
«головы правил того же перечня»; всякое иное вхождение — в том числе через
импортированный предикат и через нормативный вывод — есть
`LDC-E4701 EPISTEMIC_ACCEPTANCE_CYCLE` (§78.1). Запрет структурен и потому
ловит цикл `accept P because duty(P)` независимо от того, сколько звеньев
между `accept` и `duty`.

Результат фазы не кэшируется: он зависит от дела, времени, выбранной политики
и её закреплённых входов. Переиспользуются только проверенные структуры
программы.

### 78.2.6. Конфликт принятых опор

Две ПРИНЯТЫЕ противоположные опоры одного литерала сохраняются обе. Итог —
обычная пара поддержки §61: `BOTH` при `on_accepted_conflict` по умолчанию и
`CONFLICTED_INPUTS` §112 при `halt`. Ни при каком режиме итогом не является
`NEITHER`: «опора рассматривалась и не принята» и «поддержка литерала
конфликтна» — разные состояния разных объектов (errata E-0128, уточнение
`disputed` §78.1).

Исключение одной из двух независимых опор одного литерала оставляет вторую:
поддержка литерала есть МНОЖЕСТВО опор, а не флаг. Точный дубль опоры
(побайтово равные `from`, `relation`, `to`) даёт один StableId §75 и
достаточности не увеличивает.

### 78.2.7. Доказательство

Принятие есть ДОКАЗАННЫЙ переход, а не безусловный лист. Граф §180 получает:

- `evidence_projection` — лист на каждый спроецированный факт; несёт
  `evidence` (StableId документа либо ребра) и не имеет посылок;
- `rule_application` правил политики — обычные узлы над этими листьями;
- `support_admission` — узел решения: `conclusion` есть ПРИНЯТЫЙ литерал
  нужной полярности, `premises` — узел вывода `accepted_support(edge)`,
  атрибуты несут `policy`, `profile`, `edge`, `relation` и `documents`.

Нормативный факт, принятый политикой, имеет `support_admission` среди своих
оснований; узла `assertion` §180 у него нет. Поэтому подделать принятый факт,
не предъявив опору и правило, нельзя структурно.

Непринятые кандидаты живут в типизированном отчёте `evidenceAcceptance`
результата (`evaluation.schema.json`), а не в графе: они ничего не доказывают
и не должны читаться как доказательство отрицания.

**Где живёт объяснение.** Объяснение принятия — в графе: узел
`support_admission` называет опору, документ, политику и применённые правила.
Объяснение НЕПРИНЯТИЯ — в отчёте: у каждой опоры закрытый перечень причин, у
каждого документа — доступность, действие на дату права и перечень проверок
подлинности с признаком привязки к хэшу. `why_not` §185 профилем не
расширяется: он объясняет НОРМАТИВНУЮ цепь, а отчёт — эпистемическую («почему
предъявленный документ этой посылкой не стал»). Смешивать их значило бы дать
одному ответу два разных предмета.

**Причина `NO_ACCEPTANCE_RULE_APPLIED` обязана быть РАЗЛОЖЕНА.** Сама по себе
она говорит лишь «ни одно правило не сработало» и не отличает «документ о
другой покупке» от «неизвестный издатель» — то есть не отвечает на вопрос, за
которым к отчёту и обращаются. Поэтому у каждой опоры, дошедшей до правил и не
принятой, отчёт несёт `blockers`: для КАЖДОГО правила политики — его
`applicability`, сводный `trigger` и перечень конъюнктов с состоянием каждого,
тем же разбором §185, но над хранилищем ФАЗЫ, а не нормативным. Порядок — по
id правила (§211).

Отсюда следует граница ответственности: назвать несовпавший реквизит обязан
отчёт ДВИЖКА, а не имя сцены демонстрации и не догадка хоста. Хост, не знающий
политики заранее, получает причину из результата.

### 78.2.8. Выбор политики, идентичность и совместимость

Политика выбирается осью контекста `evidencePolicy` (§89) — StableId узла
`evidence_policy` закреплённой программы. Неразрешимая ссылка, неподдержанный
профиль, `layer` L0/L1 при выбранной политике — отказ ДО вычисления, не
fallback.

Манифест §170 при выбранной политике получает три ключа: `evidencePolicy`
(ссылка), `evidencePolicyProfile` (версия профиля) и `evidencePolicyHash`
(хэш замыкания: сам узел, его правила и связанные отношения). Записи
`case.verifications` покрыты `caseHash`.

Без выбранной политики поведение и БАЙТЫ результата прежние: acceptance-фаза
не исполняется, три ключа манифеста отсутствуют, отчёта в документе нет.
Наличие `case.evidence` само по себе новую семантику не включает — evidence
без политики остаётся transport-ом §61.

Профиль требует `semanticVersion` 0.2 либо 0.3; на 0.1 — отказ
(`EVIDENCE_POLICY_UNSUPPORTED_SEMANTICS`), потому что 0.1 заморожена байтово.

### 78.2.9. Граница профиля 0.1

За профилем остаются: бремя доказывания §77 (позиция §134 над эпистемической
целью — выражается нормой, а не профилем), стандарты доказывания сверх
«хотя бы одна принятая подходящая опора», вероятностные веса, подсчёт
большинства документов, исполнение криптографии, инкрементальный пересчёт.
Проверка подлинности входит закреплённым результатом и ядром не вычисляется.