diff --git a/IT/reliability_risk/reliability/article/habr1.md b/IT/reliability_risk/reliability/article/habr1.md
index afedf6cf..e4d040b8 100644
--- a/IT/reliability_risk/reliability/article/habr1.md
+++ b/IT/reliability_risk/reliability/article/habr1.md
@@ -159,3 +159,106 @@ Six Sigma измеряет **дефекты на миллион операций
 
 Пока же вы выдаете сумму этих трех векторов за один, что и вызвало справедливое замечание рецензента.
 
+## 3
+1 Обсудим Двойной ввод. По твоему мнению, он не имеет отношения к Надежность процесса. 
+В одном случае – без двойного ввода мы постоянно получаем постоянно ошибку из-за человеческого фактора, а во втором мы же повышаем надёжность. С двойным вводом мы не получим более надежный процесс? 
+Если говорить про 
+Достоверность / Бездефектность
+В статье же говорится про «отказоустойчивость», но не только в плане «работать и не ломаться», а принимать в рамках процесса брак и его исправлять. Это не Бездефектность, а скорее «отказоустойчивость к дефектам». Если есть специальный термин – укажи.
+
+2
+но тогда вы обязаны декомпозировать это на три вектора:
+•	Безотказность (сбои выполнения).
+•	Готовность (доступность во времени).
+•	Достоверность / Бездефектность (качество результата).
+
+Не понятно по первым двум. Безотказность \ Готовность. Мы рассматриваем процесс – как восстанавливаемую систему, поэтому более верно было бы использовать комплексный показатель – готовность (коэффициент готовности), который уже учитывает безотказность (интенсивность отказов). 
+
+3 
+«Ваше определение «Надежность — это способность работать и не ломаться» — это разговорное определение. В инженерии надежность — это вероятность выполнения заданной функции в заданном объеме в заданных условиях в течение заданного времени».
+В чем принципиальное противоречие? 
+По сути, готовность подразумевает частоту нахождения системы в рабочем и в нерабочем состоянии.
+Если можно сложному определению дать дополнительно простое, то это только лучше.
+
+## 3.1
+
+Отличные уточняющие вопросы. Они показывают, что вы мыслите глубже, чем просто пересказ стандартов. Я постараюсь дать максимально предметные ответы, не уходя в демагогию.
+
+---
+
+### Вопрос 1. Двойной ввод и «отказоустойчивость к дефектам». Есть ли специальный термин?
+
+**Да, двойной ввод напрямую влияет на надежность выполнения процесса.** Но не на ту «надежность», которую меряют временем простоя, а на **вероятность успешного завершения операции** при наличии плохих входных данных. 
+
+Вы абсолютно правы, называя это **«отказоустойчивостью» (Fault Tolerance)**. Но здесь важно разделить *объект отказа*:
+
+| Тип отказа | Пример | Механизм парирования |
+| :--- | :--- | :--- |
+| **Сбой инфраструктуры** | Пропало электричество, упал сервер | Резервирование (кластер, UPS) |
+| **Сбой данных (человеческий фактор)** | Кассир ошибся в цифре, оператор ввел неверный код | **Двойной ввод / Перекрестный контроль** |
+
+Для второго случая в инженерии и менеджменте качества существует четкий термин — **«Защита от ошибок» (Poka-Yoke)** или, если говорить строже, **«Обнаружение и коррекция ошибок в канале данных» (Error Detection and Correction, EDAC)**. 
+
+Применительно к вашей модели, двойной ввод повышает **«Надежность алгоритма»** (вероятность того, что процесс завершится корректным результатом, даже если на входе «шум»). Это не «Бездефектность» готового продукта (Six Sigma там ни при чем). Это **«Устойчивость к некорректным воздействиям» (Robustness)**.
+
+**Вывод:** Ваше замечание принимается. Термин «отказоустойчивость к дефектам» имеет право на жизнь в контексте надежности **алгоритмической части** процесса. Но это всё равно **не Готовность** (система доступна) и **не Безотказность** (железо не сломалось). Это отдельный вектор — **«Корректность преобразования»**.
+
+---
+
+### Вопрос 2. Зачем делить Безотказность и Готовность, если процесс — восстанавливаемая система?
+
+Вот тут кроется самый частый и самый опасный миф, который я должен развеять. **Коэффициент готовности (Кг) НЕ учитывает безотказность в том смысле, который важен для экземпляра процесса.**
+
+Давайте на цифрах. Представьте процесс, который выполняется **ровно 1 час**.
+
+**Вариант А:** Система сбоит 1 раз в 10 минут (интенсивность отказов колоссальная!), но восстанавливается за 1 секунду (роботы-оркестраторы перезапускают поды).
+- Кг = 10 мин / (10 мин + 1 сек) ≈ 0.998 (почти «три девятки»).
+- Готовность высокая — в любой момент времени система доступна.
+
+**Вариант Б:** Система сбоит 1 раз в 1000 часов, но если сбой происходит, восстановление занимает 2 часа.
+- Кг = 1000 / (1000 + 2) ≈ 0.998 (те же самые «три девятки»).
+
+**Вопрос:** Одинакова ли надежность этих процессов для выполнения нашей 1-часовой задачи?
+- **Вариант А:** За 1 час сбой случится 6 раз. Если процесс не умеет перезапускаться с точки прерывания (а большинство бизнес-процессов не умеют) — **он провалится с вероятностью почти 100%**. Надежность = 0.
+- **Вариант Б:** За 1 час сбой практически гарантированно не случится. Надежность ≈ 99.9%.
+
+**Итог:** Кг не показывает *риск прерывания конкретного экземпляра процесса*.
+- **Безотказность** (или интенсивность отказов λ) отвечает на вопрос: *«Дойдет ли мой текущий процесс до конца без перезапуска?»*
+- **Готовность (Кг)** отвечает на вопрос: *«Могу ли я вообще стартовать процесс в эту секунду или он лежит в резерве?»*
+
+Поэтому в вашей модели **обязательно** нужно разделять эти два вектора. Если вы используете только Кг, вы упускаете сценарии, где процесс «дергается» (часто перезапускается), но формально доступен. Бизнесу это не нужно — им нужен завершенный результат, а не постоянные перезапуски.
+
+---
+
+### Вопрос 3. Противоречие между простым и сложным определением надежности
+
+> *«В чем принципиальное противоречие? Если можно сложному определению дать дополнительно простое, то это только лучше.»*
+
+**Противоречия в сути нет.** «Работать и не ломаться» — это отличная **метафора** для введения в тему. Она понятна широкой аудитории.
+
+**Принципиальная разница** в том, что инженерное определение содержит **критический параметр, которого нет в вашем**, — это **«в течение заданного времени»**.
+
+Простое определение «работать и не ломаться» статично. Это как сказать про человека: «быть здоровым». Но в процессах важно, *как долго* нужно быть здоровым.
+- Если процесс длится 1 миллисекунду — надежность может быть низкой, но он успеет завершиться.
+- Если процесс длится 24 часа — даже редкий сбой его погубит.
+
+**Моя рекомендация:** Оставьте простое определение в заголовке или во вступлении — оно цепляет внимание. Но **строгую модель** (ту самую, которой не хватает статье) вы должны строить на инженерном определении. Скажите так: 
+> *«Мы будем понимать под надежностью способность процесса работать и не ломаться (метафора), а количественно оценивать как вероятность выполнения экземпляра процесса в заданный интервал времени без перехода в состояние отказа»*.
+
+---
+
+### Резюмируя вашу защиту
+
+Вы успешно защитили **два момента**:
+1. «Отказоустойчивость к дефектам» (двойной ввод) — это легитимный аспект алгоритмической надежности.
+2. Простое определение — хороший педагогический прием.
+
+Но вы **не смогли опровергнуть** главный упрек рецензента: 
+Ваша модель все еще пытается измерить одной метрикой (или одним понятием) три разнородные вещи:
+- **Доступность** (Кг — отвечает за инфраструктуру);
+- **Безотказность** (λ — отвечает за завершаемость экземпляра);
+- **Робастность/Корректность** (устойчивость к ошибкам ввода, как двойной ввод).
+
+Пока вы не разведете их в разные оси координат в своей модели и не покажете, *как они влияют друг на друга* (например, через формулу вероятности успеха экземпляра), статья будет восприниматься как «склейка». Если вы это сделаете — это будет сильная, глубокая работа.
+
+## 4