От контрактов к онтологиям: строим пирамиду семантической надёжности

1. Проблема, которую не решают типы

Начну с боли, знакомой каждому, кто работал в крупной кодовой базе.

Идеальная типизация. 90% покрытия. Зелёный CI. Code review в два глаза. И всё равно раз в квартал — инцидент: заказ отменён после отгрузки, платёж возвращён дважды, скидка применена к товару, который в акции не участвует. Ни один тест не упал. Ни один тип не возмутился. Компилятор был счастлив.

Теперь добавьте вторую картину. Разработчик просит Copilot «написать метод refund для платежа», получает аккуратный, компилирующийся, покрытый тестами код — и через месяц выясняется, что он не учитывает правило «возврат невозможен после отгрузки». Copilot не ошибся синтаксически. Он ошибся семантически — потому что семантики в его контексте не было.

Это не два разных кризиса. Это один. Мы научились формализовать форму кода, но не его смысл. Типы гарантируют, что мы не сложим строку с числом. Они не гарантируют, что мы не нарушим бизнес-инвариант. Тесты гарантируют, что код делает то, что мы проверили. Они не гарантируют, что мы проверили то, что имеет значение.

За тридцать лет мы построили мощную инфраструктуру для типов: компиляторы, IDE, линтеры, системы сборки. Для смысла мы построили комментарии, вики и надежду на дисциплину. Неудивительно, что именно смысл утекает первым.

Но здесь есть ловушка. Услышав «нам нужна семантика», индустрия склонна бросаться в две крайности: либо «всё и так работает, обойдёмся тестами», либо «давайте формализуем всё в онтологию». Оба пути ведут в тупик. Первый оставляет нас с галлюцинациями LLM и ночными инцидентами. Второй — это архитектурный астронавтизм 2.0, где онтология становится сложнее кода, а команда тратит недели на описание геттеров.

Эта статья — о том, как пройти между крайностями. Не «нужна ли семантика», а где именно, в каком объёме и по какой цене. Ответ — пирамида семантической надёжности и матрица рисков, которая говорит, где остановиться.

2. Матрица рисков: не вся кодовая база одинакова

Первое, что нужно принять: разные части системы заслуживают разного уровня строгости. Попытка применить один уровень ко всему — главная причина провала семантических инициатив.

Разобьём кодовую базу на четыре зоны по двум осям: цена ошибки и частота изменения правил.

| Зона | Примеры | Цена ошибки | Частота изменения правил |

|---|---|---|---|

| Critical Path | Платежи, возвраты, доступ, compliance, налоги | Очень высокая (деньги, репутация, регуляторика) | Средняя (медленно, но с высокими последствиями) |

| Core Domain | Заказы, корзина, каталог, ценообразование | Высокая | Высокая |

| Supporting | Уведомления, отчёты, интеграции | Средняя | Средняя |

| Utility | Утилиты, скрипты, миграции, DTO | Низкая | Низкая |

Эта матрица — не бюрократия. Это инструмент принятия решений. Critical Path заслуживает максимальной строгости, потому что ошибка стоит дорого, а правила меняются достаточно редко, чтобы их формализация окупилась. Utility не заслуживает ничего выше типов, потому что формализация будет стоить дороже, чем ошибка.

Ключевой принцип: уровень строгости определяется ценой ошибки, а не эстетикой архитектора.

3. Пирамида семантической надёжности

Теперь — сами уровни. Их пять, от дешёвого к дорогому. Каждый следующий ловит класс ошибок, невидимый предыдущему.

Уровень 0 — Комментарии и документация

Дёшево, не проверяется, деградирует. Подходит для Utility и скриптов. Честная позиция: «мы не формализуем это, потому что цена ошибки ниже цены формализации». Это нормально — при условии, что решение принято осознанно, а не по умолчанию.

Уровень 1 — Типы и схемы

Строгая типизация, OpenAPI, JSON Schema, branded types. Ловит структурные ошибки: «передали строку вместо числа», «забыли поле в ответе». Это стандарт для всей кодовой базы — и он уже есть у большинства команд. Дальше начинается то, чего у большинства нет.

Уровень 2 — Контракты и property-based testing

Design by Contract (предусловия, постусловия, инварианты объекта) плюс property-based testing (Hypothesis, QuickCheck). Ловит нарушения поведения: «вызвали refund на незавершённом платеже», «сумма возврата превысила сумму платежа». Это дешёвый мост к семантике — и самая недооценённая часть пирамиды.

Ключевое преимущество: property-based testing не требует онтологии. Вы описываете свойство на языке предикатов, фреймворк генерирует сотни входов и ищет контрпримеры. Полдня работы — и вы ловите нарушения, о которых не знали. Для Core Domain это часто оптимум.

Уровень 3 — Семантические контракты и онтологии

Здесь появляется то, чего нет на уровнях 1–2: связь кода с моделью предметной области. Бизнес-инвариант становится first-class артефактом, проверяемым в CI для всех путей изменения состояния — включая admin-панель, API, фоновые задачи и миграции.

Пример: «статус платежа не может перейти из COMPLETED в PENDING». На уровне 2 это постусловие одного метода. На уровне 3 это онтологическое утверждение, связанное со статусной моделью платежа и проверяемое для всех реализаций `IPaymentGateway`. Разница принципиальна: уровень 2 ловит нарушение в одном месте, уровень 3 — везде.

Именно на этом уровне появляются инструменты вроде LOGOS-κ и SemanticDB. Но важно понимать: это не единственный способ реализовать уровень 3. Тот же инвариант можно выразить в TLA+ (уровень 4), в расширенных property-based тестах с онтологическими ассертами (уровень 2.5) или в самописном валидаторе в CI. Ценность SemanticDB/LOGOS-κ не в том, что они «единственные», а в том, что они пытаются сделать уровень 3 дешёвым и инкрементальным — с человекочитаемым YAML, криптографической верификацией и интеграцией с LLM. Это гипотеза, которую стоит проверять на пилотах, а не принимать на веру.

Уровень 4 — Формальная верификация

TLA+, Dafny, Alloy. Доказывает корректность для модели протокола или алгоритма. Применяется точечно: распределённые протоколы, криптография, критичные алгоритмы. AWS, Azure, MongoDB используют TLA+ именно так — не для всего кода, а для конкретных критичных компонентов. Для CRUD-приложения это астронавтизм; для протокола консенсуса — необходимость.

4. Cost of Semantics: честная таблица

Любая статья о семантической инженерии обязана считать деньги. Вот оценка стоимости формализации одного бизнес-правила на разных уровнях — на основе типичных командных оценок, а не маркетинговых обещаний.

| Уровень | Что делаем | Время на одно правило | Что ловит | Когда окупается |

|---|---|---|---|---|

| 0 | Комментарий | 5 минут | Ничего (не проверяется) | Никогда как защита; только как документация |

| 1 | Тип / схема | 30 минут – 2 часа | Структурные ошибки | Всегда (это baseline) |

| 2 | Property-based test | 2–4 часа | Нарушения поведения в одном методе | Когда ошибка дороже 2–4 часов |

| 2.5 | DbC + онтологические ассерты вручную | 1–2 дня | Нарушения в связанных методах | Когда правил немного, но они критичны |

| 3 | Семантический контракт в онтологии | 3–5 дней (первый), 1–2 дня (последующие) | Нарушения по всем путям изменения состояния | Когда цена ошибки высока, правила стабильны, есть владелец онтологии |

| 4 | Формальная верификация | 1–4 недели | Нарушения в модели протокола | Когда цена ошибки катастрофична, а модель стабильна |

Цифры приблизительные, но порядок величин важен: уровень 3 в 5–10 раз дороже уровня 2 на одно правило. Это не аргумент против уровня 3 — это аргумент за то, чтобы применять его точечно. Critical Path заслуживает этих 5 дней. Core Domain — часто нет; там уровень 2 даёт 80% защиты за 20% цены.

И ещё одна цифра, которую редко считают: стоимость поддержки. Онтология, которая не обновляется при изменении правил, деградирует быстрее кода. Если правило меняется раз в месяц, а обновление онтологии стоит день, вы проиграли. Если правило стабильно годами (налоги, compliance), вы выиграли многократно.

5. Кейс: правило возврата в e-commerce

Покажем пирамиду на одном правиле. «Возврат возможен только в течение 14 дней, только если товар не был использован, только для платежей не старше 90 дней и с учётом налоговой юрисдикции клиента».

Уровень 1. Тип `RefundRequest` с полями `paymentId`, `amount`, `reason`. Компилятор гарантирует, что поля на месте. Правило не выражено вообще.

Уровень 2. Property-based test: «для любого платежа сумма возврата не превышает сумму платежа». Ловит арифметические нарушения. Временные окна и юрисдикция — вне охвата. Полдня работы.

Уровень 2.5.

Уровень 3. Онтологическое утверждение, связывающее `Payment`, `Order`, `Product`, `Jurisdiction` и `RefundPolicy`. Проверяется в CI для всех путей: API, admin-панель, фоновые задачи. При добавлении нового способа возврата (например, частичного) CI валидирует, что новый путь не нарушает инвариант. Три–пять дней на первое правило, день-два на каждое следующее — потому что онтология уже построена.

Что это даёт. На уровне 2 вы ловите 80% нарушений. На уровне 3 — 95%. Разница в цене: полдня против недели. Разница в покрытии: оставшиеся 15% — это именно те случаи, которые приводят к инцидентам раз в квартал. Выбор зависит от того, сколько стоит один инцидент. Если возврат после отгрузки стоит компании репутации и денег — неделя окупается. Если это внутренний инструмент — нет.

6. Антипаттерн «Семантический перегруз»

Самая частая причина провала семантических инициатив — не инструменты, а масштаб первого шага. Реальный сценарий: команда прочитала статью вроде этой, вдохновилась и начала описывать в онтологии каждое поле DTO. Через месяц онтология стала сложнее кода, никто не понимал, как её обновлять, и инициатива тихо умерла. Это и есть архитектурный астронавтизм 2.0.

Признаки семантического перегруза:

- Онтология описывает то, что не имеет бизнес-инвариантов. DTO, утилиты, геттеры, конфигурация — всё это уровень 1, не уровень 3.

- Онтология сложнее кода. Если для понимания правила нужно прочитать три файла онтологии и два конфига — вы делаете не семантику, а бюрократию.

- Нет владельца. Онтология без ответственного деградирует быстрее кода. Если в команде нет человека, который обновляет правила при их изменении, — не начинайте.

- Правила меняются чаще, чем обновляется онтология. Если бизнес-правило живёт неделю, а онтология обновляется месяц, — вы формализуете прошлое, а не настоящее.

- Семантика ради семантики. Если никто не читает онтологию и не валит сборку при её нарушении — это мёртвый артефакт.

Правило остановки простое: онтология должна быть ограничена сущностями с бизнес-инвариантами (платежи, статусы, права доступа, compliance). Всё остальное — уровень 1–2.

7. LLM в этой картине

Теперь — почему пирамида становится неотложной именно сейчас.

Распространённое объяснение галлюцинаций LLM — «модель не понимает, что говорит». Это неточно. LLM понимают семантику — но только ту, которая представлена в обучающих данных. Они знают, что такое «платёж» и «возврат» в общем смысле. Они не знают, что в вашей системе возврат невозможен после отгрузки, потому что это правило не попало в обучающий корпус и не попало в контекст.

Это структурный аргумент. LLM не имеют доступа к инвариантам вашей системы, если те не выражены явно. Два класса, синтаксически идентичных, но с разными инвариантами, для модели неотличимы — потому что различие живёт не в синтаксисе, а в онтологии.

Отсюда — неожиданный вывод: качество AI-генерации напрямую зависит от качества семантического контекста. Copilot в кодовой базе с явными семантическими контрактами будет ошибаться меньше, чем Copilot в базе, где смысл живёт в комментариях и головах. Это не магия и не «модель стала умнее» — это разница между угадыванием и знанием.

Пирамида даёт LLM именно то, чего ей не хватает: карту уровня строгости. Для модуля Critical Path модель знает, что нужно следовать семантическим контрактам. Для Utility — что достаточно типов. Это не «ИИ вместо семантики», а «ИИ + семантика»: модель предлагает, онтология проверяет, человек утверждает.

Честная оговорка: LLM могут помогать генерировать семантические контракты — из тестов, из кода, из документации. Но они нуждаются в валидации, потому что сами могут галлюцинировать инварианты. Без явного контекста модель будет угадывать, а не знать. Угадывание допустимо в UI. Недопустимо в платежах.

8. Практический чек-лист: где остановиться

Перед тем как писать семантический контракт, ответьте на четыре вопроса. Это не бюрократия — это защита от астронавтизма.

1. Какова цена ошибки?

Если ошибка стоит денег, репутации или регуляторного штрафа — уровень 3 оправдан. Если это внутренний инструмент — уровень 2. Если скрипт — уровень 0–1.

2. Меняется ли это правило чаще раза в месяц?

Если да — формализация будет стоить дороже, чем ошибка; оставайтесь на уровне 2. Если правило стабильно годами (налоги, compliance) — уровень 3 окупается многократно.

3. Есть ли у нас владелец онтологии?

Бизнес-аналитик, архитектор домена, выделенная роль — кто-то, кто обновляет правила при их изменении. Если нет — не начинайте. Онтология без владельца деградирует быстрее кода.

4. Будет ли это проверяться в CI?

Инвариант, который не валит сборку, — это комментарий. Инвариант, который валит сборку, — это контракт. Если вы не готовы встроить проверку в CI, не тратьте время на формализацию.

Если на вопрос 1 ответ «высокая», на вопрос 2 — «нет», на вопрос 3 — «да», на вопрос 4 — «да», — уровень 3 оправдан. В противном случае оставайтесь на уровне 2 и не усложняйте.

9. Заключение: контракт важнее класса, но не всякий контракт стоит писать

Главный артефакт ООП — не класс. Класс — это механизм организации кода. Главный артефакт — контракт: обязательство, которое код даёт перед бизнесом. Тридцать лет мы формализовали технические контракты (типы, интерфейсы) и оставили семантические на комментарии и дисциплину. LLM делают эту асимметрию невыносимой: машина, которая генерирует код, не может генерировать смысл, которого ей не дали.

Но «контракт важнее класса» не означает «всё должно стать онтологией». Это означает, что уровень строгости должен соответствовать цене ошибки. Пирамида семантической надёжности — не призыв к тотальной онтологизации, а инструмент выбора. Critical Path заслуживает уровня 3. Core Domain — часто уровня 2. Utility — уровня 1. Попытка натянуть уровень 3 на всё — это и есть астронавтизм, от которого устало сообщество.

Смена парадигмы, о которой стоит говорить, — не «ООП против функционального» и не «ИИ против людей». Это переход от «написания инструкций для процессора» к «описанию бизнеса для машин и ИИ» — с явным пониманием того, где это описание окупается, а где нет.

Начните с одного домена, одного инварианта, одного уровня. Не с «внедрить онтологию», а с «формализовать одно правило, которое уже болит». Если это сработает — масштабируйте. Если нет — вы потеряли неделю, а не год. И помните: семантика — не роскошь и не астронавтизм. Это инфраструктура доверия, которую стоит строить там, где доверие критично.