14. Conformance

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

14.1 Назначение главы

Глава нормирует правила conformance claim к RENAR: кто, как и на каком основании может заявить, что проект реализует RENAR на уровне RENAR-N. Глава фиксирует:

  • Closed list уровней RENAR-1..RENAR-5 (§14.2); детальные критерии каждого уровня — в главе 12.
  • Mandatory clauses (§14.3) — нормативные положения, обязательные для любого заявления о conformance независимо от уровня; нарушение хотя бы одного — отсутствие conformance.
  • Conformance manifest (§14.4) — обязательный артефакт-декларация в substrate проекта; формат, обязательные поля, пример.
  • Self-assessment (§14.5) и third-party assessment (§14.6, опционально) — две процедуры подтверждения уровня.
  • Re-assessment cadence (§14.7) и loss of conformance (§14.8) — нормативный жизненный цикл manifest.
  • Closed list policy для уровней RENAR-N (§14.9) — запрет project-local расширений списка уровней; путь добавления нового уровня через formal change procedure стандарта.

Глава не определяет критерии каждого уровня RENAR-1..5 — это область главы 12. Глава не определяет substrate-нативные механизмы реализации проверок — это область главы 11 (capabilities) и guide/06-compliance.md (substrate-specific compliance).

14.2 Closed list уровней RENAR

Закрытый список из пяти уровней зрелости. Полные критерии — глава 12; ниже — нормативная semantic-summary для conformance claim.

УровеньКраткая семантикаConformance status
RENAR-1Ad-hoc: артефакты требований ведутся в substrate с V1–V6 (§14.3.2); без формального frontmatter schema, без lifecycle статусовМинимальный entry-level (§14.2.1)
RENAR-2Documented: requirements substrate существует; артефакты имеют базовый frontmatter; ТЗ зафиксированоConformance декларируем (§14.2.2)
RENAR-3Tracked: full frontmatter schema; lifecycle статусы используются; delta-ТЗ workflow через ADAPTConformance декларируем (§14.2.2)
RENAR-4Verified: 100 % approved артефактов имеют verified-by; pos/neg парность (§9.7); QG-2 enforced; AI-provenanceConformance декларируем (§14.2.2)
RENAR-5Optimized: adversarial critic; multi-model генерация; knowledge graph; Hallucination Rate measuredConformance декларируем (§14.2.2)

14.2.1 RENAR-1 как минимальный entry-level

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

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

14.2.2 Закрытость списка

Новые уровни (RENAR-6, RENAR-N+) не создаются project-local. Изменение списка уровней — только через formal change procedure стандарта (§14.9).

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

14.3 Mandatory clauses (универсальные для всех уровней)

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

14.3.1 SoT inversion

Реализация обязана соблюдать Source of Truth inversion (§5.3): иерархия артефактов требований — источник истины о поведении системы; код — derived артефакт реализации.

Эквивалентные нарушения:

  • Reverse-engineering поведения из кода в SR без обоснования bug-fix (§5.3.3 (1)).
  • Молчаливая адаптация SR под наблюдаемое поведение кода (§5.3.3 (4)).

14.3.2 Substrate capabilities V1–V6

Substrate проекта обязан удовлетворять capabilities V1–V6 (глава 11 §11.3):

CapabilityСтатус для conformance
V1 — Immutable historyОбязательно абсолютно: без V1 невозможен audit trail и V5
V2 — Atomic change unitОбязательно абсолютно: без V2 невозможна согласованность delta-ADAPT
V3 — Diff & reviewОбязательно абсолютно: без V3 нет gates, нет approval (§10.11.2)
V4 — Branching / change-setОбязательно абсолютно: без V4 неотделимы WIP и SoT (§10.11.2)
V5 — Cross-substrate version pinОбязательно абсолютно: без V5 невозможен verifies[].version и QG-2 (§10.3.3)
V6 — Author + timestampОбязательно абсолютно: без V6 невозможна двойная подпись ADAPT, AI-provenance (§10.11.2)

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

14.3.3 ADAPT для каждого ТЗ

Каждое ТЗ обязано иметь ровно один корневой ADAPT в статусе approved (§7.4.1). Производство BR / SR / SPEC из ТЗ без прохождения через approved ADAPT — нарушение стандарта; substrate-нативные hooks обязаны блокировать создание таких артефактов (§10.11.1 reference-validation).

При наличии delta-ТЗ — каждый delta-ТЗ обязан иметь свой delta-ADAPT (§7.6).

14.3.4 Closed list 9 SPEC types

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

Project-local создание новых типов SPEC запрещено. Изменение списка возможно только через formal change procedure стандарта (§8.3.1, §14.9).

14.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.

14.3.6 Quality Gates closed list

Closed list Quality Gates (§10.3, §10.4):

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

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

14.3.7 Closed lists backward findings и SPEC-decompositions

  • Список категорий backward findings в ADAPT закрыт (§7.4.4) — 7 категорий; добавление новых — formal change procedure (§14.9).
  • Closed list типов SPEC дополнительно фиксирует §14.3.4.
  • Closed list lifecycle-состояний артефактов (глава 10) — не расширяется project-local.

14.4 Conformance manifest

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

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

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

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

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

# Уровень conformance
level: "RENAR-3"               # из closed list §14.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"            # роль из §14.5 (architect | authorized-role-holder | external-assessor)
  signature-ref: "<substrate-native pointer на signature event>"
next-assessment-due: "2026-08-13"  # §14.7

# Mandatory clauses подтверждение (§14.3)
mandatory-clauses-confirmed:
  sot-inversion: true                              # §14.3.1
  substrate-v1-v6: { v1: true, v2: true, v3: true, v4: true, v5: true, v6: true }   # §14.3.2
  adapt-per-tz: true                               # §14.3.3
  spec-types-closed-list: true                     # §14.3.4
  tc-pos-neg-pairing: true                         # §14.3.5
  quality-gates-closed-list: true                  # §14.3.6
  closed-lists-backward-findings: true             # §14.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

# Substrate capabilities declaration (§14.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: "<substrate-native pointer на guide/03..06>"   # cross-ref на guide

# Spec types support (§14.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 не поддерживается substrate-нативно».

# Опциональные поля
declared-stricter:             # §14.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: []                 # claimed exceptions относительно baseline уровня (с обоснованием в audit trail)

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

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

  • renar-version — версия стандарта; conformance заявляется к конкретной точке стандарта; при выпуске minor-версии стандарта (§14.9) — обязателен re-assessment (§14.7) с обновлением renar-version.
  • manifest-id — V1 immutable identifier; не переиспользуется даже после replaced-by.
  • level — закрытый список §14.2; нарушение mandatory clauses (§14.3) — conformance отсутствует независимо от level.
  • level-target — необязательное декларирование пути развития; не является нормативным обязательством.
  • assessment-mode — self (§14.5) или third-party (§14.6); third-party обязан содержать формальную ссылку на внешний assessment-act.
  • assessor — V6 author + role; для third-party — внешний actor с явной идентификацией.
  • next-assessment-due — assessment-date + cadence (§14.7); просрочка — trigger loss of conformance (§14.8).
  • quality-gates — обязательно содержит все пять gate-ids; статус qg-0..qg-2 ∈ {required}; qg-3, qg-4 ∈ {required, declared, absent}.
  • mandatory-clauses-confirmed — каждое поле true обязательно для любого conformance claim; false — manifest невалиден.
  • declared-stricter — список локальных ужесточений; обязан содержать clause, override, rationale.
  • exceptions — список заявленных исключений относительно baseline уровня; каждое исключение требует обоснования в audit trail и не может затрагивать mandatory clauses.

14.5 Self-assessment procedure

14.5.1 Actor

Self-assessment проводится архитектором проекта или authorized role-holder (глава 04 роли), явно объявленным как ответственный за conformance.

14.5.2 Методология

  1. Checklist по §14.3 — actor проверяет каждую mandatory clause; результат фиксируется в mandatory-clauses-confirmed. Хотя бы одно false — assessment не завершается, manifest не выпускается; формируется план остранения нарушений.
  2. Checklist по главе 12 §12.X — для объявленного level. Каждый критерий уровня — отдельная проверка с фиксацией evidence в substrate.
  3. Manifest заполнение — все обязательные поля §14.4.2; level соответствует пройденному checklist уровню (не выше).
  4. Подпись и публикация — actor подписывает manifest substrate-нативным механизмом (V6 author + timestamp); manifest становится частью SoT через V3 review (для self-assessment — самоодобрение допустимо, но evidence обязано фиксироваться).

14.5.3 Evidence

Каждая проверка mandatory clause обязана сопровождаться evidence-ссылками в audit-trail/CFM-<id>/<clause>.md substrate проекта. Evidence — substrate-native pointer (V1 stable identifier) на конкретные артефакты, прогоны, события подтверждающие clause.

Evidence хранятся бессрочно (требование V1 + §10.13.3 retention).

14.5.4 Frequency

Self-assessment проводится:

  • При первом заявлении conformance (kickoff).
  • По cadence §14.7 (re-assessment).
  • При срабатывании trigger §14.8 (loss of conformance).
  • При выпуске minor-версии стандарта (§14.9).

14.6 Third-party assessment (опционально)

Third-party assessment — опциональный путь подтверждения conformance внешним assessor’ом. Применяется в контекстах с регуляторными требованиями к внешнему audit (медицина, финтех, госсектор, AI-критические системы) или при контрактных обязательствах перед клиентом.

14.6.1 Actor

External assessor — независимый actor с правом read-only substrate-доступа на период assessment. Формальная квалификация assessor — substrate-specific и фиксируется в assessor.signature-ref (например, внешний аудитор сертифицированной organisation).

14.6.2 Методология

Та же что §14.5.2 (checklist §14.3 + checklist главы 12 для уровня), плюс:

  1. Audit log — все действия assessor (read-events) фиксируются substrate-нативно для прозрачности.
  2. Independent verification — assessor самостоятельно проверяет evidence без полагания на self-assessment результаты проекта.
  3. Result — signed manifest (assessor подписывает substrate-нативным V6 механизмом) или denial с обоснованием и списком конкретных нарушений mandatory clauses / уровневых критериев.

14.6.3 Дополнительные поля manifest

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

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

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

Third-party assessment не отменяет self-assessment cadence (§14.7) — оба пути совместимы. Проект может вести self-assessment ежеквартально и third-party assessment ежегодно; manifest версионируется отдельно по каждому пути с разными manifest-id.

14.7 Re-assessment cadence

14.7.1 Default

Default cadence для self-assessment — квартально (каждые 3 месяца от assessment-date); для third-party — ежегодно. Конкретный cadence объявляется в next-assessment-due поле manifest.

14.7.2 Override

Cadence может быть override в declared-stricter:

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

Ослабление cadence (override: "annual" для self при default quarterly) — запрещено как нарушение §14.3.1 SoT inversion (скрытое ослабление cadence == hiding lost-conformance event; audit trail SoT обязан фиксировать факт затягивания re-assessment).

14.7.3 Immediate re-assessment triggers

Помимо cadence, immediate re-assessment обязателен при:

  1. Выпуск minor-версии стандарта RENAR (renar-version сдвигается).
  2. Нарушение mandatory clause (§14.3) — trigger loss of conformance (§14.8).
  3. Существенное изменение substrate (например, замена substrate целиком) — V1-V6 declaration пересматривается.
  4. Существенное изменение scope проекта (новый класс артефактов, новый SPEC-type начинает использоваться).

14.8 Loss of conformance

14.8.1 Triggers

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

TriggerОписание
Mandatory clause нарушенаЛюбая из §14.3.1–§14.3.7 перестала выполняться (например, появилась BR без ADAPT; substrate потерял V3 после миграции)
Substrate capability degradationV1, V2, V3, V4, V5 или V6 более не обеспечивается substrate (например, миграция на substrate без diff & review)
Manifest expirednext-assessment-due прошёл без выпуска новой версии manifest
Level criteria нарушеныКритерии заявленного уровня (см. главу 12) перестали выполняться без формального downgrade
Metric threshold violationКритическая метрика главы 13 превысила нормативный порог для уровня (например, Hallucination Rate > 5 % на RENAR-4 — §13.3.3 line 94 explicit trigger)
External denialThird-party assessor вернул denial с обоснованием

14.8.2 Процедура

  1. Регистрация loss-event — substrate-нативная запись о факте потери conformance в audit trail manifest (audit-trail/CFM-<id>/loss-events/<timestamp>.md).
  2. Формальный downgrade или декларация unknown-state — два варианта:
    • Downgrade: выпуск новой версии manifest с level ниже текущего (если нарушены критерии заявленного уровня, но mandatory clauses выполнены).
    • Unknown-state: явная декларация в публичных коммуникациях проекта что conformance временно отсутствует; manifest помечается replaced-by: "<unknown-state>" (sentinel-value, отличается от default null активного manifest); повторный assessment обязателен для восстановления conformance.
  3. Recovery plan — обязательная регистрация плана восстановления (substrate-нативный артефакт recovery/CFM-<id>-<timestamp>.md) с указанием срока и mandatory clauses / уровневых критериев, требующих восстановления.
  4. Re-assessment — после реализации recovery plan; обязательно self-assessment (§14.5) с обновлённым manifest. Для third-party-mode — обязательно повторное external assessment.

14.8.3 Public communication

Потеря conformance, если уровень заявлен публично, обязана быть зарегистрирована публично в течение разумного срока (substrate-specific notification cadence фиксируется в guide/). Скрытие факта потери — нарушение mandatory clause §14.3.1 (audit trail SoT).

14.9 Closed list policy для уровней RENAR-N

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

Closed list уровней RENAR-1..RENAR-5 (§14.2) не расширяется project-local. Любой проект, заявляющий conformance, обязан указать level ∈ {RENAR-1, RENAR-2, RENAR-3, RENAR-4, RENAR-5}.

14.9.2 Что запрещено

ДействиеЗапрещено?Почему
Project-local создание уровня (RENAR-6, RENAR-PRO)ЗапрещеноНарушает закрытый список; conformance становится не-портируемой
Локальное переопределение критериев уровня (например, ослабление RENAR-4 без формального downgrade)ЗапрещеноНарушает контракт стандарта
Локальное ужесточение критериев уровня (declare-stricter)РазрешеноСм. §14.4.2 declared-stricter
Заявление уровня выше фактически достигнутогоЗапрещеноНарушает mandatory clause §14.3.1 (SoT inversion для самой conformance machinery)
Заявление conformance без manifestЗапрещено§14.4 mandatory
Промежуточные уровни типа RENAR-3.5ЗапрещеноСписок дискретный

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

Добавление нового уровня (например, RENAR-6) — только через formal change procedure стандарта:

  1. Research draft — обоснование необходимости нового уровня; типология критериев; сравнение с существующими уровнями RENAR-N.
  2. Public review — открытое обсуждение в форуме стандарта; срок и форма фиксируются политикой версионирования стандарта.
  3. Minor-version bump — новый уровень включается в следующую minor-версию стандарта (v1.X или v2.0).
  4. Migration guidance — для существующих conformant проектов выпускается миграционная инструкция (изменения в self-assessment checklist, новые поля manifest).

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

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

ГлаваСвязь
05 Положение в типологии методологий§5.3 SoT inversion — mandatory clause §14.3.1; §5.7 conformance implication явно отсылает к этой главе
06 Иерархия требованийFrontmatter артефактов (BR / SR / TR) — критерии level RENAR-2/-3 проверяются по §6.5–§6.7 (глава 12)
07 ADAPTMandatory clause §14.3.3 (ADAPT для каждого ТЗ); §7.4.4 closed list backward findings — §14.3.7
08 SpecificationsMandatory clause §14.3.4 (9 SPEC types closed list); §8.3.1 closed list policy — §14.9
09 Test casesMandatory clause §14.3.5 (pos/neg парность); §9.10 QG-2 — §14.3.6
10 Lifecycle и QG§10.3 canonical gates, §10.4.3 conformance manifest fragment — расширяется здесь до полного manifest schema; §10.10 closed list policy для gates параллельна §14.9 для уровней
11 Substrate versioningMandatory clause §14.3.2 (V1–V6 declared); §11.4 mapping таблица — не-нормативная, информационная
12 Maturity modelДетальные критерии уровней RENAR-1..5 — здесь §14.2 содержит semantic-summary; полный checklist по уровню — в §12.X
13 MetricsМетрики, на которых строится self-assessment (approved-without-verified, pos-neg-pairing-percent, и др.) — конкретизируются здесь как input для §14.5