diff --git a/README.md b/README.md
index e2d8694..af95275 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,7 @@
# AI-OS
+[English](README.md) | [Русский](README_RU.md)
+
[](https://github.com/sergstack/AI-OS/actions/workflows/docs-safety.yml)
AI-OS is a governed operating system for work that spans ChatGPT Projects,
@@ -67,6 +69,27 @@ The two most important separations are deliberate: a generated artifact never
becomes the semantic owner of its source, and a validated result never becomes
an accepted decision without the appropriate human authority.
+### Candidate operational reliability layer
+
+The following layer documents four candidate contracts for making operational
+evidence and failures easier to inspect across runs. It is documentation only:
+it does not add a runtime service, persistent memory, automatic policy changes,
+or a production workflow. The detailed English contract is
+[Operational Reliability](docs/OPERATIONAL_RELIABILITY_EN.md).
+
+| Общая механика | Английское название | Русское название |
+| --- | --- | --- |
+| Жизненный цикл evidence | Evidence lifecycle ledger | Журнал жизненного цикла evidence |
+| Намерение запуска | Versioned run intent | Версионированное намерение запуска |
+| Наблюдаемость отказов | Typed fault telemetry | Типизированная телеметрия сбоев |
+| Превращение сбоя в проверку | Failure-to-regression harness | Контур «сбой → регрессия» |
+
+The exact names `EvidenceUnit`, `ACTIVE`, `SUPERSEDED`, `REVOKED`, `Candidate
+Gate`, `Human Gold`, `fail-closed`, and `digest` remain contract names. Their
+meaning may be explained in Russian, but the names must not be translated or
+silently substituted. Until explicit evaluation and owner acceptance, this
+layer remains `candidate` and does not change existing repository behavior.
+
## How the system works
```text
diff --git a/README_RU.md b/README_RU.md
new file mode 100644
index 0000000..bf2a849
--- /dev/null
+++ b/README_RU.md
@@ -0,0 +1,243 @@
+# AI-OS
+
+[English](README.md) | [Русский](README_RU.md)
+
+[](https://github.com/sergstack/AI-OS/actions/workflows/docs-safety.yml)
+
+AI-OS — управляемая операционная система для работы на стыке ChatGPT Projects,
+repository delivery, validation и версионируемого Stream Deck-интерфейса. Она
+превращает широкую цель в проверяемый путь: определяет одного ответственного
+владельца, ограничивает изменение, сохраняет evidence, проверяет результат и
+оставляет acceptance и необратимые решения человеку-владельцу.
+
+> **Текущий статус:** candidate / ready for human review. Production promotion
+> остаётся запрещённым, пока не пройдены документированные sync, smoke-QA и
+> pilot gates. Этот публичный репозиторий **не является open source**; см.
+> [rights posture](docs/rights_posture.md).
+
+## Система одним взглядом
+
+```mermaid
+flowchart LR
+ A["Широкая цель или raw input"] --> B["[Inbox Router]
если маршрут неясен"]
+ B --> C["Один ответственный Project"]
+ C --> D{"Нужно изменение репозитория?"}
+ D -->|"нет"| E["Результат домена
с evidence и ограничениями"]
+ D -->|"да"| F["[Codex]
ограниченный handoff"]
+ F --> G["Codex APP
ветка и реализация"]
+ E --> H["Validation и source checks"]
+ G --> H
+ H --> I{"Решение человека-владельца"}
+ I -->|"принять"| J["Review и merge
при наличии полномочий"]
+ I -->|"не принято"| K["Исправить, остановить или откатить"]
+```
+
+Это control loop, а не autonomous agent loop: работа может продолжаться
+автоматически только в разрешённом обратимом scope. Acceptance, merge,
+production promotion и другие существенные решения остаются решениями человека.
+
+## Что отличает архитектуру
+
+Многие AI-workspace заканчиваются prompt, набором документов или agent loop.
+AI-OS делает operational boundaries явными и версионируемыми.
+
+| Проектное решение | Что оно даёт | Чего оно намеренно не утверждает |
+|---|---|---|
+| **Один ответственный destination** | Семь именованных ChatGPT Project packages разделяют routing, governance, decisions, analytics, LLM quality, implementation и corpus work. | Что один универсальный agent владеет каждым решением. |
+| **Две content surfaces** | Granular `Knowledge/` — canonical; compact `Knowledge_Bundles/` — derived upload artifacts с source fingerprints. | Что ChatGPT Project UI всегда синхронен после изменения репозитория. |
+| **Goal Mode** | Широкая цель может стать обратимым branch change с checks, risks, rollback и acceptance. | Разрешение расширять scope, merge, deploy или менять защищённые business rules. |
+| **Evidence-bearing gates** | Manifests, paths, bundle provenance, instruction length, public-repo safety, smoke QA и pilots являются разными checks. | Что passing test или generated file равен owner acceptance или production readiness. |
+| **Human authority** | Review, merge, production promotion и другие существенные действия остаются явными. | Autonomous approval, deployment или persistent production agent platform. |
+| **Версионируемые operating surfaces** | ChatGPT packages, Codex APP contracts и Stream Deck artifacts развиваются через Git review и rollback. | Скрытое runtime state вне репозитория. |
+
+Репозиторий можно проверить на каждой границе: куда должна идти задача, какой
+source владеет содержанием, какой artifact загружается, что проверено и где
+осталось решение владельца.
+
+### Пять связанных механизмов
+
+| Механизм | Какой контроль добавляет | Canonical owner |
+|---|---|---|
+| **Routing и ownership** | У задачи один primary destination; cross-domain работа использует explicit handoff, а не неявную передачу. | [Routing Rules](ROUTING_RULES.md) и [Project Registry](PROJECT_REGISTRY.md) |
+| **Knowledge provenance** | Granular sources владеют смыслом; generated bundles содержат declared source fingerprints для formal upload. | [Sync Contract](SYNC_CONTRACT.md) и project `UPLOAD_LIST.md` |
+| **Bounded delivery** | Goal Mode требует smallest useful branch change, relevant checks, rollback и acceptance reporting. | [Goal Mode](GOAL_MODE.md) |
+| **Execution traceability** | AES задаёт vocabulary для requirements, validation, defects, corrective action и closure review, не отнимая ownership у Projects. | [AES](docs/standards/AUTONOMOUS_EXECUTION_STANDARD.md) |
+| **Evidence и authority** | Repository checks, smoke QA, pilots, external sync, review и production authorization остаются разными состояниями. | [Master Status](MASTER_STATUS.md) и [Current Status](CURRENT_STATUS.md) |
+
+Два ключевых разделения намеренны: generated artifact никогда не становится
+semantic owner своего source, а validated result не становится accepted decision
+без соответствующей human authority.
+
+### Candidate operational reliability layer
+
+Этот слой документирует четыре candidate contracts, помогающие проверять
+operational evidence и failures между запусками. Это только documentation: он
+не добавляет runtime service, persistent memory, automatic policy changes или
+production workflow. Подробный русский контракт:
+[Operational Reliability](docs/OPERATIONAL_RELIABILITY.md).
+
+| Общая механика | Английское название | Русское название |
+| --- | --- | --- |
+| Жизненный цикл evidence | Evidence lifecycle ledger | Журнал жизненного цикла evidence |
+| Намерение запуска | Versioned run intent | Версионированное намерение запуска |
+| Наблюдаемость отказов | Typed fault telemetry | Типизированная телеметрия сбоев |
+| Превращение сбоя в проверку | Failure-to-regression harness | Контур «сбой → регрессия» |
+
+Точные имена `EvidenceUnit`, `ACTIVE`, `SUPERSEDED`, `REVOKED`, `Candidate
+Gate`, `Human Gold`, `fail-closed` и `digest` остаются contract names. Их смысл
+можно объяснять по-русски, но нельзя переводить или молча заменять сами имена.
+До явного evaluation и owner acceptance этот слой имеет статус `candidate` и
+не меняет существующее поведение репозитория.
+
+## Как работает система
+
+```text
+goal или raw input
+ -> route к одному accountable Project
+ -> scope, evidence и constraints
+ -> работа в домене или handoff в Codex
+ -> validation sources, artifacts и изменённого поведения
+ -> human owner review, acceptance, merge или rollback
+```
+
+`[Inbox Router]` обрабатывает неясный intake. Routed project сохраняет domain
+ownership; `[Codex]` готовит implementation work, а Codex APP меняет
+репозиторий в non-`main` branch. Canonical map —
+[`ROUTING_RULES.md`](ROUTING_RULES.md), а не этот обзор.
+
+### Семь ChatGPT Projects
+
+| Project | Используйте, когда нужно | Типичный результат |
+|---|---|---|
+| `[Inbox Router]` | Классифицировать raw request или выбрать destination. | Bounded route или handoff. |
+| `[AI OS]` | Governance, AI patterns, evidence, confidence или supported use cases. | Evidence-aware guidance и следующий owner. |
+| `[Thinking]` | Options, trade-offs, decisions, risks или Judge/Revisor pass. | Decision memo с assumptions и revisit triggers. |
+| `[Analytics]` | Deterministic calculations, data QA, reconciliations, metrics или charts. | Method, calculations, checks и limitations. |
+| `[LLM]` | Prompts, model routing, evaluation, quality gates или workflow design. | Governed prompt/workflow proposal и evaluation boundary. |
+| `[Codex]` | Implementation framing, code review, tests и release handoff. | Scoped execution package для repository work. |
+| `[Thinkers OS]` | Thinker corpus, provenance, synthesis и pattern status. | Source-aware synthesis без выдуманной attribution. |
+
+Authoritative paths, instruction limits и AES applicability находятся в
+[project registry](PROJECT_REGISTRY.md). Project packages разделены намеренно:
+strategy discussion не должна молча становиться analytics calculation или
+repository mutation.
+
+### Canonical sources и upload artifacts
+
+```mermaid
+flowchart LR
+ A["Granular Knowledge/
canonical semantic source"] --> B["Declared sources
и source fingerprint"]
+ B --> C["Generated Knowledge_Bundle
upload artifact"]
+ C --> D["Ручной ChatGPT Project
Knowledge upload"]
+ A -. "репозиторий остаётся live source of truth" .-> E["GitHub / local checkout"]
+ E -. "fresh state" .-> D
+```
+
+Репозиторий — live source of truth. ChatGPT Project Knowledge — versioned
+baseline для bootstrapping и periodic formal sync, а не live replica каждого
+commit. Загружайте только bundle files, названные в
+`Knowledge_Bundles/UPLOAD_LIST.md`; не загружайте одновременно bundles и их
+granular sources, кроме debugging sync issue.
+
+Перед ручным ChatGPT update прочтите [Sync Contract](SYNC_CONTRACT.md) и
+[Upload Guide](UPLOAD_GUIDE.md).
+
+### Goal Mode и AES
+
+[Goal Mode](GOAL_MODE.md) — default execution model для широких repository
+goals: сначала inspect, затем smallest safe scope, реализация в branch,
+relevant checks и report evidence, risks, rollback, acceptance status.
+
+[Autonomous Execution Standard (AES)](docs/standards/AUTONOMOUS_EXECUTION_STANDARD.md)
+задаёт shared execution vocabulary для requirements, validation, defects,
+corrective action, traceability и closure review. Он не отменяет project
+ownership и не разрешает agent одобрять собственную работу. AES applicability
+и ограниченное evidence по каждому Project указаны в [registry](PROJECT_REGISTRY.md).
+
+## Начало работы с AI-OS
+
+### 1. Найдите правильную точку входа
+
+| Ваша задача | Начните здесь |
+|---|---|
+| Понять репозиторий | [Repository map](docs/REPOSITORY_MAP.md) |
+| Выбрать ChatGPT Projects или Codex APP для ежедневной работы | [Operating guide](docs/guides/CHATGPT_CODEX_OPERATING_GUIDE.md) |
+| Изменить repository content | [`AGENTS.md`](AGENTS.md), затем [Goal Mode](GOAL_MODE.md) |
+| Подготовить goal или fixed task | [Goal issue template](.github/ISSUE_TEMPLATE/goal.md) или [Codex task template](.github/ISSUE_TEMPLATE/codex-task.md) |
+| Загрузить ChatGPT Project baseline | [Upload Guide](UPLOAD_GUIDE.md) и project `UPLOAD_LIST.md` |
+| Проверить evidence, maturity и open gates | [Current status](CURRENT_STATUS.md) и [Master status](MASTER_STATUS.md) |
+
+### 2. Работайте от цели, а не от предполагаемой реализации
+
+Для repository change сформулируйте desired outcome. Goal Mode ограничивает
+работу branch, minimal reversible scope, relevant checks, rollback path и
+explicit acceptance. Passing test, ready PR или generated artifact не
+доказывают, что пользовательский outcome принят.
+
+Для simple local reversible change с достаточным repository context следуйте
+applicable local instructions напрямую. Для AI-OS methodology work используйте
+canonical routing и bounded-context flow из `AGENTS.md`.
+
+### 3. Проверьте результат перед pull request
+
+В local checkout запустите readiness helper и relevant tests:
+
+```bash
+python3 scripts/sync_aios.py
+python3 -m pytest tests/ -rA
+```
+
+`sync_aios.py` проверяет project-instruction length, public-repository safety,
+Goal Mode defaults, manifest paths, Knowledge Bundles и index coverage. Он
+**не** загружает данные в ChatGPT, не push-ит в GitHub, не merge-ит PR и не
+даёт production approval.
+
+Для contribution и branch requirements используйте
+[contributing guide](CONTRIBUTING.md). Точная merge policy находится в
+[Goal Mode](GOAL_MODE.md).
+
+## Структура репозитория
+
+| Область | Назначение |
+|---|---|
+| [`ChatGPT/`](ChatGPT) | Project instructions, canonical granular Knowledge и compact upload bundles. |
+| [`Codex APP/`](Codex%20APP) | Local execution contracts, setup, runbooks и review guidance. |
+| [`StreamDeck/`](StreamDeck) | Versioned configuration, exports, generators, QA и rollback history. |
+| [`docs/`](docs) | Maps, guides, shared standards, operations, evidence и reference material. |
+| [`scripts/`](scripts) и [`tests/`](tests) | Deterministic validation и regression coverage. |
+| [`.github/`](.github) | Issue intake, PR policy, ownership, security reporting и CI workflows. |
+
+## Evidence и ограничения
+
+AI-OS различает repository consistency и external/operational proof. Passing
+checks и bounded candidate evidence не доказывают сами по себе, что каждый
+ChatGPT Project синхронизирован, каждый workflow надёжен или разрешён production
+promotion.
+
+Candidate status, smoke-QA evidence, pilot boundaries и blocked promotion items
+собраны в [Current status](CURRENT_STATUS.md). Точные validation и operational
+gates находятся в [Master status](MASTER_STATUS.md).
+
+AI-OS **не** добавляет embeddings, semantic search, vector databases, web UI,
+autonomous retrieval, agentic workflows, persistent runtime memory или
+production deployments. Public visibility не даёт reuse rights; у репозитория
+нет open-source license.
+
+## Полезные ссылки
+
+- [Repository map](docs/REPOSITORY_MAP.md)
+- [Project registry](PROJECT_REGISTRY.md)
+- [Goal Mode](GOAL_MODE.md)
+- [Sync Contract](SYNC_CONTRACT.md)
+- [Autonomous Execution Standard](docs/standards/AUTONOMOUS_EXECUTION_STANDARD.md)
+- [Current status](CURRENT_STATUS.md)
+- [Security policy](.github/SECURITY.md)
+
+## Local path placeholders
+
+В публичной документации используются placeholders вместо machine-specific paths:
+
+- `` — local AI-OS checkout
+- `` — current repository root
+- `` — local Codex APP folder
+- `` — local working artifacts outside the repository
diff --git a/docs/OPERATIONAL_RELIABILITY.md b/docs/OPERATIONAL_RELIABILITY.md
new file mode 100644
index 0000000..7b7c1ee
--- /dev/null
+++ b/docs/OPERATIONAL_RELIABILITY.md
@@ -0,0 +1,88 @@
+# Operational Reliability — кандидатный контракт
+
+[English](OPERATIONAL_RELIABILITY_EN.md) | [Русский](OPERATIONAL_RELIABILITY.md)
+
+## Статус и назначение
+
+Статус: `candidate`. Этот парный документ описывает возможный слой
+operational reliability для проверяемой фиксации evidence, run intent, faults и
+regressions. Это только documentation contract. Он не создаёт runtime service,
+persistent memory, autonomous retrieval, automatic policy change или
+production workflow.
+
+Действующие source-of-truth, routing, validation и acceptance rules репозитория
+не меняются. Если кандидат когда-либо будет activated, потребуются
+identifiable version, evaluation cases, observed results, owner acceptance и
+явное scope decision.
+
+## Четыре кандидатных контракта
+
+| Общая механика | Английское название | Русское название |
+| --- | --- | --- |
+| Жизненный цикл evidence | Evidence lifecycle ledger | Журнал жизненного цикла evidence |
+| Намерение запуска | Versioned run intent | Версионированное намерение запуска |
+| Наблюдаемость отказов | Typed fault telemetry | Типизированная телеметрия сбоев |
+| Превращение сбоя в проверку | Failure-to-regression harness | Контур «сбой → регрессия» |
+
+### 1. Evidence lifecycle ledger
+
+`EvidenceUnit` — ограниченная ссылка на observed evidence, его provenance,
+scope и lifecycle status. Точные status names: `ACTIVE`, `SUPERSEDED` и
+`REVOKED`.
+
+- `ACTIVE` означает, что unit — текущий referenced evidence для заявленного
+ scope; это не означает accepted, complete или production-ready.
+- `SUPERSEDED` означает, что позднее identified unit заменяет его в том же
+ заявленном scope; раннее evidence остаётся traceable.
+- `REVOKED` означает, что на evidence нельзя полагаться для прежнего claim;
+ причина и replacement state должны оставаться видимыми.
+
+Этот кандидат не разрешает agent выводить lifecycle status только из текста
+или удалять historical evidence.
+
+### 2. Versioned run intent
+
+Run фиксирует goal, scope, constraints, expected evidence и relevant contract
+version, которые были авторизованы для его выполнения. Intent versioned, чтобы
+поздний читатель отличал результат раннего scope от результата revised scope.
+
+Кандидатное правило — `fail-closed`, когда required intent reference
+отсутствует, двусмысленен или несовместим с requested action: остановиться и
+сообщить о недостающем решении, а не молча подставлять current intent.
+
+### 3. Typed fault telemetry
+
+Fault record использует named type, affected scope, observed evidence и
+disposition. Он делает failures reviewable, не превращая каждое warning в
+system-wide policy change. `digest` может суммировать несколько records, но не
+должен скрывать их identifiers, scope или unresolved state.
+
+`Candidate Gate` и `Human Gold` остаются точными именами, когда встречаются в
+related evaluation context. Это не синонимы; кандидат не меняет ни один gate,
+его data, criteria или owner decision.
+
+### 4. Failure-to-regression harness
+
+Когда material evidenced failure исправлен, correction должен сопровождаться
+bounded replay или deterministic check, способным обнаружить тот же failure
+class. Harness связывает observed fault, correction scope, check и result; он
+не утверждает general prevention за пределами этого scope.
+
+Нельзя выдумывать regression test, если failure нельзя воспроизвести,
+использовать unrelated passing check как proof correction или автоматически
+promote candidate change.
+
+## Границы и activation gate
+
+Этот candidate layer не меняет project routing, owner boundaries, canonical
+governance semantics, formulas, model routing или external ChatGPT Project
+state. Он не может сам авторизовать merge, deployment, production promotion,
+изменение `Candidate Gate` или решение `Human Gold`.
+
+Перед любым activation зафиксируйте: candidate version, target scope,
+evaluation cases, Judge results, applied revisions where required, final
+acceptance и owner acceptance. До этого authoritative остаются existing
+canonical documents: [Goal Mode](../GOAL_MODE.md),
+[Sync Contract](../SYNC_CONTRACT.md),
+[AES](standards/AUTONOMOUS_EXECUTION_STANDARD.md) и
+[Master Status](../MASTER_STATUS.md).
diff --git a/docs/OPERATIONAL_RELIABILITY_EN.md b/docs/OPERATIONAL_RELIABILITY_EN.md
new file mode 100644
index 0000000..83138ec
--- /dev/null
+++ b/docs/OPERATIONAL_RELIABILITY_EN.md
@@ -0,0 +1,88 @@
+# Operational Reliability — Candidate Contract
+
+[English](OPERATIONAL_RELIABILITY_EN.md) | [Русский](OPERATIONAL_RELIABILITY.md)
+
+## Status and purpose
+
+Status: `candidate`. This paired document describes a possible operational
+reliability layer for recording evidence, run intent, faults, and regressions
+in a reviewable form. It is a documentation contract only. It does not create
+a runtime service, persistent memory, autonomous retrieval, automatic policy
+change, or production workflow.
+
+The repository's active source-of-truth, routing, validation, and acceptance
+rules remain unchanged. If this candidate is ever activated, it requires an
+identifiable version, evaluation cases, observed results, owner acceptance, and
+an explicit scope decision.
+
+## The four candidate contracts
+
+| Shared mechanic | English name | Russian name |
+| --- | --- | --- |
+| Evidence lifecycle | Evidence lifecycle ledger | Журнал жизненного цикла evidence |
+| Run intent | Versioned run intent | Версионированное намерение запуска |
+| Failure observability | Typed fault telemetry | Типизированная телеметрия сбоев |
+| Turning failure into a check | Failure-to-regression harness | Контур «сбой → регрессия» |
+
+### 1. Evidence lifecycle ledger
+
+An `EvidenceUnit` is a bounded reference to observed evidence, its provenance,
+scope, and lifecycle status. The exact status names are `ACTIVE`,
+`SUPERSEDED`, and `REVOKED`.
+
+- `ACTIVE` means the unit is the current referenced evidence for its declared
+ scope; it does not mean accepted, complete, or production-ready.
+- `SUPERSEDED` means a later identified unit replaces it for the same declared
+ scope; the earlier evidence remains traceable.
+- `REVOKED` means the evidence must not be relied on for its prior claim; the
+ reason and replacement state must remain visible.
+
+This candidate does not authorize an agent to infer lifecycle status from text
+alone or to delete historical evidence.
+
+### 2. Versioned run intent
+
+A run records the goal, scope, constraints, expected evidence, and relevant
+contract version it was authorized to use. The intent is versioned so a later
+reader can distinguish a result produced under an earlier scope from one
+produced under a revised scope.
+
+The candidate rule is `fail-closed` when a required intent reference is absent,
+ambiguous, or incompatible with the requested action: stop and report the
+missing decision instead of silently substituting a current intent.
+
+### 3. Typed fault telemetry
+
+A fault record uses a named type, affected scope, observed evidence, and
+disposition. It makes failures reviewable without converting every warning into
+a system-wide policy change. A `digest` may summarize multiple records, but it
+must not erase their identifiers, scope, or unresolved state.
+
+`Candidate Gate` and `Human Gold` remain exact names when they occur in a
+related evaluation context. They are not synonyms and this candidate does not
+alter either gate, its data, its criteria, or its owner decision.
+
+### 4. Failure-to-regression harness
+
+When a material, evidenced failure is corrected, the correction should be
+paired with a bounded replay or deterministic check that can detect the same
+failure class. The harness links the observed fault, the correction scope, the
+check, and the result; it does not claim general prevention beyond that scope.
+
+It must not fabricate a regression test when the failure cannot be reproduced,
+use a passing unrelated check as proof of correction, or automatically promote
+a candidate change.
+
+## Boundaries and adoption gate
+
+This candidate layer does not change project routing, owner boundaries,
+canonical governance semantics, formulas, model routing, or external ChatGPT
+Project state. It cannot independently authorize merge, deployment, production
+promotion, a change to `Candidate Gate`, or a `Human Gold` decision.
+
+Before any activation, record: candidate version, target scope, evaluation
+cases, Judge results, revisions applied where required, final acceptance, and
+owner acceptance. Until then, existing canonical documents remain authoritative:
+[Goal Mode](../GOAL_MODE.md), [Sync Contract](../SYNC_CONTRACT.md),
+[AES](standards/AUTONOMOUS_EXECUTION_STANDARD.md), and
+[Master Status](../MASTER_STATUS.md).
diff --git a/tests/test_operational_reliability_docs.py b/tests/test_operational_reliability_docs.py
new file mode 100644
index 0000000..a2d7ec2
--- /dev/null
+++ b/tests/test_operational_reliability_docs.py
@@ -0,0 +1,62 @@
+from pathlib import Path
+
+
+ROOT = Path(__file__).resolve().parents[1]
+EN_README = ROOT / "README.md"
+RU_README = ROOT / "README_RU.md"
+EN_DETAIL = ROOT / "docs/OPERATIONAL_RELIABILITY_EN.md"
+RU_DETAIL = ROOT / "docs/OPERATIONAL_RELIABILITY.md"
+
+LANGUAGE_SWITCH = "[English]({english}) | [Русский]({russian})"
+CORRESPONDENCE_ROWS = (
+ "| Жизненный цикл evidence | Evidence lifecycle ledger | Журнал жизненного цикла evidence |",
+ "| Намерение запуска | Versioned run intent | Версионированное намерение запуска |",
+ "| Наблюдаемость отказов | Typed fault telemetry | Типизированная телеметрия сбоев |",
+ "| Превращение сбоя в проверку | Failure-to-regression harness | Контур «сбой → регрессия» |",
+)
+CONTRACT_NAMES = (
+ "EvidenceUnit",
+ "ACTIVE",
+ "SUPERSEDED",
+ "REVOKED",
+ "Candidate Gate",
+ "Human Gold",
+ "fail-closed",
+ "digest",
+)
+
+
+def test_operational_reliability_readmes_are_language_paired() -> None:
+ english = EN_README.read_text(encoding="utf-8")
+ russian = RU_README.read_text(encoding="utf-8")
+
+ assert LANGUAGE_SWITCH.format(english="README.md", russian="README_RU.md") in english
+ assert LANGUAGE_SWITCH.format(english="README.md", russian="README_RU.md") in russian
+ assert "### Candidate operational reliability layer" in english
+ assert "### Candidate operational reliability layer" in russian
+ assert "docs/OPERATIONAL_RELIABILITY_EN.md" in english
+ assert "docs/OPERATIONAL_RELIABILITY.md" in russian
+
+ for row in CORRESPONDENCE_ROWS:
+ assert row in english
+ assert row in russian
+
+
+def test_operational_reliability_detail_docs_preserve_contract_names() -> None:
+ english = EN_DETAIL.read_text(encoding="utf-8")
+ russian = RU_DETAIL.read_text(encoding="utf-8")
+
+ assert LANGUAGE_SWITCH.format(
+ english="OPERATIONAL_RELIABILITY_EN.md",
+ russian="OPERATIONAL_RELIABILITY.md",
+ ) in english
+ assert LANGUAGE_SWITCH.format(
+ english="OPERATIONAL_RELIABILITY_EN.md",
+ russian="OPERATIONAL_RELIABILITY.md",
+ ) in russian
+
+ for text in (english, russian):
+ assert "Status: `candidate`" in text or "Статус: `candidate`" in text
+ assert "does not create" in text or "не создаёт" in text
+ for name in CONTRACT_NAMES:
+ assert name in text