язык: усиления источников названы своими

- три клетки «что взято» правились по факту: DMN даёт политику совпадения,
  но не требует полноты; в 29148 обоснование — рекомендуемый атрибут; вывод
  про обязательность шаблона в EARS не сформулирован
- заведён раздел «Где источник усилен»: полнота таблиц, обязательность
  обоснования и вывод из EARS предъявлены как наши решения с доводами
- поправлены два места, где та же натяжка повторялась прозой: «Таблицы
  решений» и «Обоснование обязательно»

LANGUAGE.md

@@ -34,9 +34,9 @@ version: 1
 |---|---|---|
 | **BCP 14** (RFC 2119 + RFC 8174) | шкала модальности; правило «нормативно только заглавное»; сдержанность в высшей модальности; англоязычный словарь как готовый | синонимы `REQUIRED`, `RECOMMENDED`, `OPTIONAL`; `SHALL` как форма требования |
 | **ISO/IEC Directives, Part 2** | разделение «требование — рекомендация — разрешение — возможность»; запрет модальных глаголов в утверждениях о факте | списки равнозначных словесных форм («is to», «is required to», «only … is permitted») |
-| **ISO/IEC/IEEE 29148** | обоснование как обязательный атрибут; единичность нормы; проверяемость; метод верификации отдельным атрибутом | остальной аппарат требований: приоритеты, источники, матрицы трассируемости |
-| **DMN** | таблица решений с объявленной политикой совпадения и требованием полноты | исполняемая семантика и всё, что предполагает движок решений |
-| **EARS** | вывод о том, что выигрыш даёт жёсткий шаблон, а не его конкретный вид; паттерн «нежелательное поведение» — в виде таблицы | шаблоны как форма записи правила: `WHEN`, `WHILE`, `WHERE` |
+| **ISO/IEC/IEEE 29148** | характеристики хорошего требования — единичность и проверяемость; обоснование и метод верификации как отдельные атрибуты требования | остальной аппарат требований: приоритеты, источники, матрицы трассируемости |
+| **DMN** | таблица решений с объявленной политикой совпадения | исполняемая семантика и всё, что предполагает движок решений |
+| **EARS** | паттерн «нежелательное поведение» — в виде таблицы | шаблоны как форма записи правила: `WHEN`, `WHILE`, `WHERE` |
 | **OpenSpec** | четырёхчастная форма правила; адресуемость правила идентификатором; форма «условие → следствие» для стыка правил | `SHALL`; `GIVEN/WHEN/THEN` как общая форма записи |
 
 Три отклонения стоят объяснения, потому что выглядят как произвол.
@@ -56,14 +56,37 @@ version: 1
 система, и её поведение разворачивается во времени: состояние, событие,
 исход. У конвенции субъект — автор кода, и разворачивать нечего: есть
 ситуация выбора и вердикт. Это таблица, а не траектория. Тем же рассуждением
-отклонены шаблоны EARS как форма записи правила, а взят из EARS другой
-результат: измеримый выигрыш дала там сама обязательность шаблона, а не его
-конкретная форма.
+отклонены шаблоны EARS как форма записи правила, а взято из EARS другое —
+сообщённое снижение числа дефектов после введения шаблонов. Вывод, что дело в
+самой обязательности формы, а не в её конкретном виде, наш; он ниже, среди
+усилений.
 
 Исключение — стык правил, где субъект действительно система: там форма
 «условие → следствие» берётся сознательно, вместе со служебными словами под
 неё. Это единственное место, и оно описано в «Таблицах решений».
 
+## Где источник усилен
+
+Три решения идут дальше источника, и это наши решения, а не его требования.
+Названы они отдельно, чтобы довод не подменялся ссылкой: спорить с ними нужно
+по существу, а не со стандартом.
+
+- **Обоснование обязательно.** В 29148 rationale — из списка рекомендуемых
+  атрибутов требования; обязательный костяк там другой, это характеристики
+  самого требования. Здесь правило без блока ПОЧЕМУ не принимается, потому что
+  конвенция живёт годами и переживает автора: норма без причины через год либо
+  отменяется первым возражением, либо соблюдается там, где вредит.
+- **Полнота таблицы решений.** DMN даёт политику совпадения как именованный
+  атрибут, а полноты не требует: индикатор полноты был в первой версии
+  спецификации и из последующих убран, полноту проверяют валидаторы
+  инструментов. Здесь она требуется, потому что таблицу и заводят ради
+  видимости пропуска: неперечисленный случай в прозе не виден, а пустая
+  клетка видна.
+- **Вывод про обязательность шаблона.** В EARS сообщается о снижении числа
+  дефектов в требованиях после введения шаблонов. Вывод, что выигрыш даёт сама
+  обязательность формы, а не её конкретный вид, — наш: он объясняет, почему мы
+  берём из EARS результат, но не берём сами шаблоны.
+
 ## Что даёт формализация
 
 Адресуемое правило — не украшение формы, а условие работы трёх механизмов:
@@ -146,8 +169,8 @@ version: 1
 ## Обоснование обязательно
 
 Правило без блока ПОЧЕМУ не принимается. Это требование к форме, а не
-пожелание; в 29148 обоснование — атрибут требования наравне с самим
-требованием, и по тем же причинам:
+пожелание. В 29148 обоснование — отдельный атрибут требования, но из
+рекомендуемых; здесь оно обязательно, и вот почему:
 
 - **Обоснование — единственный способ увидеть, что правило устарело.**
   Норма стареет молча; причина стареет заметно. Когда причина отпала, видно,
@@ -350,8 +373,8 @@ XMIG-2, XMIG-4 — МЕХАНИЗИРОВАНО: `internal/archrules`, в нов
 которой нумеруются как подпункты правила (`XLOG-8.1`).
 
 Таблица плотнее прозы и не даёт пропустить ветку: пустая клетка видна, а
-неупомянутый случай в абзаце — нет. Два свойства такой таблицы взяты из DMN,
-где они называются и проверяются:
+неупомянутый случай в абзаце — нет. От такой таблицы требуются два свойства —
+первое названо в DMN, второе мы добавили сами («Где источник усилен»):
 
 - **Политика совпадения.** По умолчанию строки взаимоисключающи: любой
   ситуации соответствует ровно одна. Если это не так, таблица объявляет