13. Соответствие¶

Часть RENAR Standard v1.0-draft · ← Оглавление

Плотная глава: начните с reference/08 kit; MVR↔§13.3 bijection — там же §1.

13.1 Как доказать соответствие¶

Сказать «у нас всё по RENAR» легко — доказать труднее. Эта глава о том, как проект делает проверяемое заявление: «мы реализуем RENAR на уровне RENAR-3» — и подкрепляет его так, чтобы внешний оценщик мог перепроверить. Заявление — не лозунг, а подписанный манифест со ссылками на свидетельства в носителе: вот уровень, вот доказательная база по каждому обязательному положению, вот кто и когда это подтвердил.

Глава нормирует три вопроса. Кто вправе заявить — архитектор проекта (самооценка) или независимый оценщик (третья сторона). На каком основании — закрытый список уровней RENAR-1..5 плюс универсальные положения, обязательные для любого уровня. Как заявление живёт во времени — повторная оценка по расписанию, а при нарушении — потеря соответствия. Если заявление перестаёт быть правдой, это регистрируемое событие, а не тихое умолчание.

Сами уровни даны здесь короткой семантической сводкой: полные критерии RENAR-1..5 — в главе 11, а нативные для носителя механизмы проверок — в главе 3 и guide/06-compliance.md. Здесь — правила самого заявления.

13.2 Закрытый список уровней RENAR¶

Закрытый список из пяти уровней зрелости. Полные критерии — глава 11; ниже — нормативная семантическая сводка для заявления о соответствии.

Уровень	Краткая семантика	Статус соответствия
`RENAR-1`	Ad-hoc (стихийный уровень): артефакты требований ведутся в носителе с V1–V6 (§13.3.2); без формальной `frontmatter`-схемы, без статусов жизненного цикла	Минимальный входной уровень (§13.2.1)
`RENAR-2`	Documented (зафиксированный артефактами): носитель требований существует; артефакты имеют базовый `frontmatter`; ТЗ зафиксировано	Соответствие декларируем (§13.2.2)
`RENAR-3`	Tracked (ведётся жизненный цикл и учёт связей): полная `frontmatter`-схема; статусы жизненного цикла используются; delta-ТЗ workflow через ADAPT	Соответствие декларируем (§13.2.2)
`RENAR-4`	Verified (верифицируемый): 100% `approved` артефактов имеют `verified-by`; pos/neg парность (§9.7); QG-2 обеспечивается; AI-происхождение	Соответствие декларируем (§13.2.2)
`RENAR-5`	Optimized (оптимизирующий): состязательный критик; multi-model генерация; knowledge graph; Hallucination Rate measured	Соответствие декларируем (§13.2.2)

13.2.1 RENAR-1 как минимальный входной уровень (entry-level)¶

RENAR-1 — нормативный входной уровень. Проект, в котором отсутствует носитель требований (требования живут только в ticket-системах или личной переписке), не заявляется как RENAR-1; заявление соответствия стандарту начинается с фактического наличия носителя требований.

RENAR-1 фиксируется в манифесте соответствия только если проект явно декларирует начало пути в RENAR; для проектов без намерения внедрять RENAR манифест соответствия не требуется.

13.2.2 Закрытость списка¶

Новые уровни (RENAR-6, RENAR-N+) не создаются локально на уровне проекта. Изменение списка уровней — только через формальную процедуру изменения стандарта (§13.9).

Реализация может ужесточить требования относительно уровня (declare-stricter — см. §10.10.2); это не меняет уровень и не выводит проект за пределы закрытого списка.

13.3 Обязательные положения (обязательные положения), универсальные для всех уровней¶

Нормативные положения, обязательные для любого заявления о соответствии независимо от объявленного уровня (включая RENAR-1). Нарушение хотя бы одного — отсутствие соответствия стандарту RENAR в целом.

13.3.1 Инверсия источника истины (инверсия источника истины)¶

Реализация обязана соблюдать инверсию источника истины (§2.3): иерархия артефактов требований — источник истины о поведении системы; код — производный артефакт реализации. Эквивалентные нарушения: reverse-engineering поведения из кода в SR без обоснования bug-fix (§2.3.3 (1)); молчаливая адаптация SR под наблюдаемое поведение кода (§2.3.3 (4)).

13.3.2 Возможности носителя V1–V6¶

Носитель проекта обязан удовлетворять возможностям V1–V6 (глава 3 §3.3):

Возможность	Статус для соответствия
V1 — неизменяемая история	Обязательно абсолютно: без V1 невозможен журнал аудита и V5
V2 — атомарная единица изменения	Обязательно абсолютно: без V2 невозможна согласованность delta-ADAPT
V3 — сравнение различий и рецензирование	Обязательно абсолютно: без V3 нет gates, нет утверждения (§10.11.2)
V4 — ветвление / набор изменений	Обязательно абсолютно: без V4 неотделимы WIP и источник истины (§10.11.2)
V5 — сквозная фиксация версии между носителями	Обязательно абсолютно: без V5 невозможен `verifies[].version` и QG-2 (§10.3.3)
V6 — автор и отметка времени	Обязательно абсолютно: без V6 невозможна двойная подпись ADAPT, AI-происхождение (§10.11.2)

Негативный сценарий: носитель, в котором отсутствует хотя бы одна возможность из V1–V6, нормативно не может реализовать никакой RENAR-N — включая RENAR-1. Это структурное ограничение (§3.2), не операционное.

13.3.3 Reactive ADAPT¶

ADAPT — реактивный артефакт (§7.4.1). Каждое ТЗ обязано пройти состязательный обзор (§7.10.2) с зафиксированным в носителе вердиктом (V6 author + timestamp). Дальнейшее зависит от вердикта:

Вердикт состязательного рецензента	Требование к ADAPT	Требование к `source` для BR/SR/SPEC
«findings present» — обнаружены backward findings, term mapping clarification или scope clarification	ADAPT обязателен в статусе `approved`. Двойная подпись (Архитектор + представитель Клиента, §7.5). Lifecycle §7.4.5.	`source.adapt` mandatory; `source.tz-section` mandatory
«no findings, no clarifications» — конвертация ТЗ → RENAR однозначна	ADAPT не создаётся	`source.tz-section` mandatory; `source.adversarial-review-ref` mandatory (свидетельство вердикта)

Делегирование на состязательного рецензента — единственный допустимый способ задекларировать «ADAPT не нужен». Создание BR / SR / SPEC из ТЗ без зафиксированного вердикта — нарушение стандарта; hooks (§10.11.1 adapt-applicability validation) обязаны блокировать такие артефакты.

При наличии delta-ТЗ — то же правило (§7.6): delta-ADAPT создаётся по факту находок состязательного обзора delta-ТЗ.

Множественность и стадийная независимость. Триггер ADAPT стадийно-независим: вердикт выносится не только при импорте ТЗ, но и на стадиях деривации (BR → SR → SPEC → TC, §7.4.1.1). На одно ТЗ приходится ноль или более корневых ADAPT (кардинальность 0..N, MVR-3, §7.4.1.4); каждый фиксирует trigger-stage. Множественность соответствует стандарту и не ослабляет провенанс: каждый BR / SR / SPEC ссылается ровно на один ADAPT либо на source.tz-section.

Дезавуирование (supersession). Approved/frozen ADAPT может быть дезавуирован дезавуирующим ADAPT (§7.6.4). Соответствующее стандарту дезавуирование обязано: (1) сохранять дезавуируемый ADAPT в терминальном superseded (неизменяемо, V1) — не удалять; (2) при контрактном итоге — нести подпись клиента на дезавуирующем ADAPT; (3) перенаправить или пере-вывести все производные так, чтобы не осталось висячих source.adapt на superseded (§6.10.3). Отдельный QG не требуется — используется QG-3 (§10.8.5).

Negative scenarios (несоответствующие):

Манифест объявляет соответствие, но BR/SR/SPEC производятся из ТЗ без source.tz-section и без source.adapt — нарушение обязательного происхождения.
Создание BR/SR/SPEC с пропущенным source.adapt без свидетельства source.adversarial-review-ref — нарушение §7.4.1.3 «запрет молчаливого skip».
ADAPT создан при вердикте «no findings» (есть свидетельство) — противоречие: вердикт заявляет, что ADAPT не нужен, но ADAPT присутствует.
ADAPT в статусе superseded удалён из носителя — нарушение неизменяемой истории (V1).
Висячая ссылка source.adapt на superseded ADAPT (производное не перенаправлено и не пере-выведено) — невалидная цепочка прослеживаемости.
Дезавуирование решения с контрактным итогом без подписи клиента на дезавуирующем ADAPT — односторонняя отмена согласованного с клиентом, нарушение §7.6.4.

13.3.4 Закрытый список 9 типов SPEC¶

Тип SPEC обязан принадлежать закрытому списку девяти типов (§8.3): SPEC-ARCH, SPEC-API, SPEC-DATA, SPEC-INT, SPEC-PROC, SPEC-UI, SPEC-AI, SPEC-SEC, SPEC-OPS.

Проект не имеет права создавать новые типы SPEC локально. Изменение списка возможно только через формальную процедуру изменения стандарта (§8.3.1, §13.9).

13.3.5 TC pos/neg парность для нормативных утверждений¶

Каждое нормативное утверждение верифицируемого артефакта (BR / SR / SPEC / TR), охватываемое хотя бы одним TC, обязано иметь парный negative TC (§9.7). Single-TC-coverage допускается только в одном случае: утверждение само описывает negative invariant (например, SPEC-SEC STRIDE-категория).

QG-2 (§10.3.3) обязан блокировать promote артефакта в verified при отсутствии хотя бы одного парного negative TC.

13.3.6 Закрытый список Quality Gates¶

Закрытый список Quality Gates (§10.3, §10.4):

Gate	Статус в манифесте соответствия
QG-0 — Approval	Обязательно required
QG-1 — Implementation	Обязательно required
QG-2 — Verification	Обязательно required
QG-3 — Architecture (опц.)	`declared` (поддерживается) или `absent`; для проектов с обязательным ADAPT — фактически всегда `declared`, поскольку утверждение ADAPT оперирует двойной подписью QG-3 (§10.4.1)
QG-4 — Acceptance (опц.)	`declared` или `absent`; при `absent` терминальный статус артефакта — `verified` (без `accepted`)

Локальное создание новых типов gate запрещено (§10.10.2). Локальное ужесточение предусловий канонического gate разрешено (declare-stricter); локальное ослабление — запрещено.

13.3.7 Закрытые списки backward findings и SPEC-декомпозиций¶

Список категорий backward findings в ADAPT закрыт (§7.4.4) — 7 категорий; добавление новых — формальная процедура изменения стандарта (§13.9).
Закрытый список типов SPEC дополнительно фиксирует §13.3.4.
Закрытый список состояний жизненного цикла артефактов (глава 10) — не расширяется локально на уровне проекта.

13.3.8 Межуровневая прослеживаемость подсистем (`implements`-edge)¶

Для сценария «подсистема — самостоятельный продукт» (§6.8.2) реализация обязана обеспечить машиночитаемую цепочку прослеживаемости BR (подсистема) → BR (система) через типизированное ребро implements[] (§6.5.2):

Уровень соответствия	Требование
v1.0: `recommended`	Если `BR.level = subsystem` И родительская система имеет ≥1 approved BR — наличие `implements[]` рекомендовано. Отсутствие — допустимо, но требует обоснования в разделе `Контекст` со ссылкой на ADAPT§.
v1.1+: `mandatory`	Тот же триггер делает `implements[]` обязательным. Отсутствие при выполнении триггера — несоответствие.

В обеих версиях носитель обязан реализовать точку контроля implements-edge validation из §10.11.1 (target существует и в approved+, нет циклов, deprecated target → warning, implements[] не на level: system).

Негативный сценарий: проект объявляет соответствие RENAR-N с BR.level = subsystem и approved родительским BR в той же системе, но без implements[] и без обоснования в Контексте — несоответствующий начиная с v1.1; на v1.0 — прогнозируемо-несоответствующий при upgrade (§13.9 руководство по миграции).

13.4 Манифест соответствия¶

13.4.1 Расположение и формат¶

Манифест соответствия хранится в корне носителя требований проекта под именем RENAR-CONFORMANCE.yaml. Формат — YAML 1.2; альтернативная сериализация (.json) допустима как дополнительный артефакт, не замена.

Манифест является неизменяемым в смысле V1: каждое заявление о соответствии создаёт новую версию манифеста (manifest-version инкрементируется); предыдущие версии не удаляются, остаются в носителе как журнал аудита. Замена манифеста через replaced-by указывает на новую версию.

13.4.2 Обязательные поля¶

# RENAR Conformance Manifest schema (mandatory fields, v1.0)
renar-version: "1.0"           # версия стандарта RENAR, к которой заявляется conformance
senar-version: "1.0"           # версия SENAR, на которую опирается реализация (обязательно, MVR-7)
manifest-version: 3            # инкрементируется при каждом обновлении; не пере-используется
manifest-id: "CFM-2026-001"    # стабильный нативный для носителя идентификатор (V1)

# Уровень conformance
level: "RENAR-3"               # из closed list §13.2 (RENAR-1..RENAR-5)
level-target: "RENAR-4"        # опционально: следующий целевой уровень (для path planning)

# Assessment metadata
assessment-mode: "self"        # self | third-party
assessment-date: "2026-05-13"  # ISO-8601 даты завершения текущей оценки
assessor:
  id: "architect-andrey-y"     # V6 author identifier
  role: "architect"            # роль из §13.5 (architect | authorized-role-holder | external-assessor)
  signature-ref: "<нативный для носителя pointer на signature event>"
next-assessment-due: "2026-08-13"  # §13.7

# Mandatory clauses подтверждение (§13.3)
mandatory-clauses-confirmed:
  sot-inversion: true                              # §13.3.1
  substrate-v1-v6: { v1: true, v2: true, v3: true, v4: true, v5: true, v6: true }   # §13.3.2
  adapt-per-tz: true                               # §13.3.3
  spec-types-closed-list: true                     # §13.3.4
  tc-pos-neg-pairing: true                         # §13.3.5
  quality-gates-closed-list: true                  # §13.3.6
  closed-lists-backward-findings: true             # §13.3.7

# Quality gates declaration (§10.4.3)
quality-gates:
  qg-0: required               # required (обязательно)
  qg-1: required
  qg-2: required
  qg-3: declared               # required | declared | absent
  qg-4: absent

# Декларация возможностей носителя (§13.3.2)
substrate-capabilities:
  v1-immutable-history: declared
  v2-atomic-change-unit: declared
  v3-diff-review: declared
  v4-branching: declared
  v5-version-pin: declared
  v6-author-timestamp: declared
  substrate-id: "<нативный для носителя pointer на guide/03..06>"   # cross-ref на guide

# Spec types support (§13.3.4)
spec-types-supported: ["SPEC-ARCH", "SPEC-API", "SPEC-DATA", "SPEC-INT",
                       "SPEC-PROC", "SPEC-UI", "SPEC-AI", "SPEC-SEC", "SPEC-OPS"]
# Все 9 типов обязательны как minimum-supported; declaration «type X не используется в проекте» допустима,
# но НЕ может быть declaration «type X не поддерживается нативно для носителя».

# Опциональные поля
declared-stricter:             # §13.2.2, §10.10.2 — локальное ужесточение
  - clause: "QG-2"
    override: "required-negative-tc-per-clause"
    rationale: "regulated industry, double safety margin"
  - clause: "tc-pos-neg-pairing"
    override: "100% (без single-TC исключения для security)"
    rationale: "обязательное требование внутреннего ISMS"

exceptions: []                 # заявленные исключения относительно базового уровня (с обоснованием в журнале аудита)

# Внешние записи conformance к §14.4 (опционально; поле значения см. ключ `claim` ниже — носитель §14.6)
external-claims:
  - standard: "ISO/IEC 5338:2023"
    clause-ref: "§2.4.x"
    claim: "partial"           # full | partial | aligned
  - standard: "NIST AI RMF 1.0"
    clause-ref: "§2.4.x"
    claim: "aligned"

replaced-by: null              # нативный для носителя pointer на следующую версию manifest, если выпущена
replaces: "CFM-2026-001@v2"    # нативный для носителя pointer на предыдущую версию manifest

13.4.3 Семантика полей¶

renar-version — версия стандарта; соответствие заявляется к конкретной точке стандарта; при выпуске minor-версии стандарта (§13.9) — обязателен re-assessment (§13.7) с обновлением renar-version.
senar-version — версия SENAR, на которую опирается реализация; обязательна по MVR-7 (§0.5); её отсутствие в манифесте — несоответствие (§13.8).
manifest-id — V1 immutable identifier; не переиспользуется даже после replaced-by.
level — закрытый список §13.2; нарушение обязательные положения (§13.3) — соответствие отсутствует независимо от level.
level-target — необязательное декларирование пути развития; не является нормативным обязательством.
assessment-mode — self (§13.5) или third-party (§13.6); third-party обязан содержать формальную ссылку на внешний assessment-act.
assessor — V6 author + role; для third-party — внешний участник с явной идентификацией.
next-assessment-due — assessment-date + cadence (§13.7); просрочка — триггер потери соответствия (§13.8).
quality-gates — обязательно содержит все пять gate-ids; статус qg-0..qg-2 ∈ {required}; qg-3, qg-4 ∈ {required, declared, absent}.
mandatory-clauses-confirmed — каждое поле true обязательно для любого заявления о соответствии; false — манифест невалиден.
declared-stricter — список локальных ужесточений; обязан содержать clause, override, rationale.
exceptions — список заявленных исключений относительно базового уровня; каждое исключение требует обоснования в журнале аудита и не может затрагивать обязательные положения.
external-claims — опциональный список записей соответствия внешним нормативным ссылкам (§14.4, §14.6); каждая запись содержит standard, clause-ref, поле claim (значение: full | partial | aligned) — технический ключ схемы, без замены термина в манифесте.

13.5 Процедура самооценки (Self-assessment)¶

13.5.1 Участник (actor)¶

Самооценка проводится архитектором проекта или уполномоченным лицом (глава 5), явно объявленным ответственным за соответствие.

13.5.2 Методология¶

Шаги: (1) контрольный список по §13.3 — участник проверяет каждое обязательное положение; результат в mandatory-clauses-confirmed; хотя бы одно false → оценка не завершается, формируется план устранения нарушений; (2) контрольный список по главе 11 §§11.4-11.8 для объявленного level — каждый критерий уровня = отдельная проверка с доказательной базой в носителе; (3) заполнение манифеста (все обязательные поля §13.4.2; level не выше пройденного контрольного списка); (4) подпись и публикация — участник подписывает манифест нативным механизмом (V6 author + timestamp); манифест становится частью источника истины через V3-рецензирование (для самооценки самоодобрение допустимо, доказательная база обязана фиксироваться).

13.5.3 Доказательная база (evidence)¶

Каждая проверка обязательного положения обязана сопровождаться ссылками на свидетельства в audit-trail/CFM-<id>/<clause>.md (V1 — стабильный идентификатор на конкретные артефакты, прогоны, события). Свидетельства хранятся бессрочно (V1 + §10.13.3 retention).

13.5.4 Периодичность¶

Первое заявление (kickoff); периодичность §13.7; триггер §13.8 (потеря соответствия); выпуск minor-версии стандарта (§13.9).

13.6 Оценка третьей стороной (Third-party assessment, опционально)¶

Опциональный путь подтверждения соответствия внешним оценщиком. Применяется в регуляторных контекстах (медицина, финтех, госсектор, AI-критические системы) или при контрактных обязательствах перед клиентом.

13.6.1 Участник (actor)¶

Внешний оценщик — независимый участник с read-only доступом к носителю на период оценки. Формальная квалификация специфична для носителя и фиксируется в assessor.signature-ref (внешний аудитор сертифицированной организации).

13.6.2 Методология¶

Та же что §13.5.2 (контрольный список §13.3 + контрольный список главы 11), плюс: журнал аудита — все действия оценщика (read-events) фиксируются нативно; независимая проверка — оценщик самостоятельно проверяет свидетельства без полагания на результаты самооценки; итог — подписанный манифест (оценщик подписывает нативным V6 механизмом) или отказ с обоснованием и списком конкретных нарушений.

13.6.3 Дополнительные поля манифеста¶

При assessment-mode: third-party обязательны:

third-party:
  assessor-organisation: "<наименование>"
  assessor-qualification-ref: "<pointer на квалификационный документ>"
  audit-report-ref: "<pointer на полный audit report>"
  audit-log-ref: "<pointer на read-events log>"

13.6.4 Соотношение self / third-party¶

Third-party не отменяет периодичность самооценки (§13.7); пути совместимы. Проект может вести самооценку ежеквартально и third-party ежегодно; манифест версионируется отдельно по каждому пути с разными manifest-id.

13.7 Период повторной оценки (Re-assessment cadence)¶

13.7.1 По умолчанию (Default)¶

Самооценка — квартально (каждые 3 месяца от assessment-date); third-party — ежегодно. Объявляется в поле next-assessment-due манифеста.

13.7.2 Переопределение (Override)¶

Периодичность может быть переопределена в declared-stricter:

declared-stricter:
  - clause: "re-assessment-cadence"
    override: "monthly"
    rationale: "AI-критический проект, eval-зависимость"

Ослабление периодичности (override: "annual" для self при default quarterly) запрещено — нарушение §13.3.1 инверсии источника истины (скрытое ослабление = сокрытие события потери соответствия).

13.7.3 Немедленные триггеры повторной оценки¶

Выпуск minor-версии стандарта RENAR (renar-version сдвигается); нарушение обязательное положение (§13.3, триггер потери соответствия §13.8); существенное изменение носителя (замена носителя — V1-V6 пересматривается); существенное изменение области применения (новый класс артефактов, новый SPEC-type).

13.8 Потеря соответствия (Loss of conformance)¶

13.8.1 Триггеры¶

Соответствие считается потерянным при наступлении любого из:

Trigger	Описание
Обязательное положение нарушено	Любая из §13.3.1–§13.3.7 перестала выполняться (например, появилась BR без ADAPT; носитель потерял V3 после миграции)
Деградация возможности носителя	V1, V2, V3, V4, V5 или V6 более не обеспечивается носителем (например, миграция на носитель без diff & review)
Манифест истёк	`next-assessment-due` прошёл без выпуска новой версии манифеста
Критерии уровня нарушены	Критерии заявленного уровня (см. главу 11) перестали выполняться без формального downgrade
Превышение порога метрики	Критическая метрика главы 12 превысила нормативный порог для уровня (например, Hallucination Rate > 5% на RENAR-4 — §12.3.3 явный триггер строки 94)
Внешний отказ	Внешний оценщик (third-party assessor) вернул отказ с обоснованием

13.8.2 Процедура¶

Шаги: (1) регистрация события потери (loss-event) в журнале аудита (audit-trail/CFM-<id>/loss-events/<timestamp>.md); (2) формальный downgrade или декларация unknown-state — downgrade (новая версия манифеста с level ниже текущего, если обязательные положения выполнены) либо unknown-state (явная декларация в публичных коммуникациях; манифест помечается replaced-by: "<unknown-state>" sentinel-значением, отличается от default null; повторная оценка обязательна для восстановления); (3) план восстановления — recovery/CFM-<id>-<timestamp>.md с указанием срока и обязательные положения / уровневых критериев; (4) повторная оценка после плана восстановления — обязательно самооценка §13.5 с обновлённым манифестом; для third-party — повторная внешняя оценка.

13.8.3 Публичные коммуникации¶

Потеря соответствия, если уровень заявлен публично, обязана быть зарегистрирована публично в течение разумного срока (периодичность уведомления — guide/). Скрытие факта потери — нарушение §13.3.1 (журнал аудита источника истины).

13.9 Политика закрытого списка уровней RENAR-N¶

13.9.1 Нормативное правило¶

Закрытый список уровней RENAR-1..RENAR-5 (§13.2) не расширяется локально на уровне проекта. Любой проект, заявляющий соответствие, обязан указать level ∈ {RENAR-1, RENAR-2, RENAR-3, RENAR-4, RENAR-5}. Настоящая политика — специализация §1.7 политики закрытого списка для уровней зрелости; master-индекс — §1.7.5.

13.9.2 Что запрещено¶

Действие	Запрещено?	Почему
Локальное создание уровня на уровне проекта (`RENAR-6`, `RENAR-PRO`)	Запрещено	Нарушает закрытый список; соответствие не-портируемо
Локальное переопределение критериев (ослабление RENAR-4 без формального downgrade)	Запрещено	Нарушает контракт стандарта
Локальное ужесточение критериев (declare-stricter)	Разрешено	См. §13.4.2 `declared-stricter`
Заявление уровня выше фактически достигнутого	Запрещено	Нарушает §13.3.1 инверсия источника истины
Заявление о соответствии без манифеста	Запрещено	§13.4 обязательно
Промежуточные уровни типа `RENAR-3.5`	Запрещено	Список дискретный

13.9.3 Путь добавления нового уровня¶

Только через формальную процедуру изменения стандарта: исследовательский черновик (обоснование, типология критериев, сравнение с существующими RENAR-N) → публичное обсуждение → повышение minor-версии (v1.X или v2.0) → руководство по миграции (для существующих соответствующих проектов: изменения в чек-листе самооценки, новые поля манифеста).

Локальные для проекта расширения остаются за пределами соответствия — допустимы как internal-практики (declared-stricter), но не влияют на формальный level в манифесте.

13.10 Связь с другими главами¶

Глава	Связь
02 Положение в типологии методологий	§2.3 инверсия источника истины — обязательное положение §13.3.1; §2.7 следствие для соответствия явно отсылает к этой главе
06 Иерархия требований	`frontmatter` артефактов (BR / SR / TR) — критерии уровня RENAR-2/-3 проверяются по §6.5–§6.7 (глава 11)
07 ADAPT	Обязательное положение §13.3.3 (ADAPT для каждого ТЗ); §7.4.4 закрытый список backward findings — §13.3.7
08 Specifications	Обязательное положение §13.3.4 (закрытый список 9 типов SPEC); §8.3.1 политика закрытого списка — §13.9
09 Test cases	Обязательное положение §13.3.5 (pos/neg парность); §9.10 QG-2 — §13.3.6
10 Жизненный цикл и QG	§10.3 канонические gates, §10.4.3 фрагмент манифеста соответствия — расширяется здесь до полной схемы манифеста; §10.10 политика закрытого списка для gates параллельна §13.9 для уровней
03 Версионирование носителя	Обязательное положение §13.3.2 (V1–V6 declared); §3.4 mapping таблица — не-нормативная, информационная
11 Maturity model	Детальные критерии уровней RENAR-1..5 — здесь §13.2 содержит семантическую сводку; полный контрольный список по уровню — в §§11.4–11.8 (по одной секции на уровень)
12 Metrics	Метрики, на которых строится самооценка (`approved-without-verified`, `pos-neg-pairing-percent`, и др.) — конкретизируются здесь как входные данные для §13.5