METRICОдин числовой ряд
invalid_orders = 5
Показывает масштаб и динамику, оставляя состав пяти объектов за пределами сигнала.
Business invariants · production data
Consistique
Исполняемый контракт между кодом продукта и его реальным состоянием в production.
Разработчик поставляет функцию вместе с правилом, которое доказывает: после релиза данные остаются непротиворечивыми.
01Rules as codeПроверка поставляется вместе с изменением
02Concrete evidenceКонкретные нарушенные объекты вместо обезличенного сигнала
03Lifecycle per violationКаждый fingerprint имеет собственную историю
Контракт продукта
Проверочный код снижает цену ошибки в эксплуатации.
AI ускоряет написание кода и делает ошибку на этапе разработки дешевле. Но дефект, который дошел до production data, остается дорогим. Consistique переносит проверочный код туда, где проявляется реальное бизнес-состояние.
- 01Product change
Код изменяет бизнес-процесс, данные или интеграционный контракт.
- 02Invariant
Разработчик формулирует состояние, которое после изменения невозможно.
- 03Production check
Read-only правило проверяет текущее состояние реальных данных.
- 04Reconciliation
Движок сравнивает конкретные нарушения с предыдущим успешным запуском.
Код продукта+Проверочный код=Эксплуатируемый контракт
Другая единица наблюдения
От агрегированного сигнала к конкретным нарушенным объектам.
Метрика агрегирует поток. Инвариант возвращает конкретные бизнес-объекты, нарушающие правило, и сохраняет историю каждого нарушения.
INVARIANTМножество нарушений
{order-17, order-42, order-91, order-108, order-205}
Показывает состав, первое появление, возврат и устранение каждого нарушения.
RUN NA · B · C · D · Ecount = 5
→
RUN N + 1A · B · C · F · Gcount = 5
CONSISTIQUE2 NEW · 2 RESOLVEDСчетчик остался прежним. Состав production state изменился.
State Reconciliation Engine
Каждое противоречие имеет собственную историю.
Результат SQL нормализуется в fingerprints. Каждый успешный запуск согласует наблюдаемое множество с сохраненным состоянием.
Violation lifecycle
Изменение множества во времени
Policy: no grace · Activity 24h
fingerprint
01BaselineИсходный backlog
02I3 исправилиПропал из результата
03Появился I4Новая проблема
04I3 вернулсяПовторное появление
05Accept backlogРучное решение
I1
ACTIVE
ACTIVE
ACTIVE
ACTIVE
ACCEPTED
I2
ACTIVE
ACTIVE
ACTIVE
ACTIVE
ACCEPTED
I3
ACTIVE
RESOLVED
RESOLVED
ACTIVERETURNED
ACCEPTED
I4
—
—
ACTIVENEW
ACTIVE
ACCEPTED
01Baseline фиксирует исходный backlog
I1–I3 становятся исходным наблюдаемым множеством без массового NEW.
02NEW и RETURNED — события
Они видны только внутри выбранного Activity window.
03Accept относится к текущему backlog
Новые нарушения после accept начинают собственный lifecycle.
candidateНаблюдается
Нарушение найдено, но находится внутри grace period.
activeПодтверждено
Противоречие пережило grace и требует внимания.
acceptedПринято как долг
Текущий backlog принят вручную и остается наблюдаемым.
resolvedУстранено
Fingerprint отсутствует в успешном результате.
archivedСвернуто
История сохранена после retention period.
Три уровня состояния
Lifecycle строки не смешивается с операционным состоянием правила.
01Violation
candidate · active · accepted · resolved · archived
02Invariant
OK · SUSPECTED · BROKEN · ACCEPTED · ERROR
03Inbox
BROKEN · SUSPECTED · ACCEPTED · ERROR · STALE по выбранному environment.
TIME SEMANTICS
first_seen_at — момент обнаружения. Доменное время показывается как evidence, только если его достоверно вернуло само правило.
FAILED RUN
Lifecycle остается без изменений.
Timeout, сеть или ошибка SQL означают отсутствие нового достоверного наблюдения.
Invariant as code
Одно правило. Один reviewable файл. Явный SQL-контракт.
Definition source связывает проверку с репозиторием разработки. Изменение можно проверить, отрецензировать и продвинуть по окружениям.
- count.sql
- Заявляет точный размер полного observed set.
- items.sql
- Извлекает то же множество стабильными батчами, по умолчанию по 1000 строк.
- fingerprint
- Явный столбец либо hash всех возвращаемых полей.
- evaluation
- Full dataset или честно обозначенный sampled scope.
/* consistique
title = "Оплаченный заказ не может оставаться pending"
domain = "Orders"
source = "OrdersDb"
publishing = "manual"
grace_period = "10m"
evaluation_scope = "full"
batch_size = 1000
*/
-- @count
select count(*)::bigint as violation_count
from orders
where payment_state = 'paid'
and fulfillment_state = 'pending';
-- @items
select
id::text as fingerprint,
id as order_id,
paid_at,
fulfillment_state
from orders
where payment_state = 'paid'
and fulfillment_state = 'pending'
order by id;Скользящие временные окна не подменяют текущее observed set.
Расхождение count.sql и items.sql завершает run со статусом ERROR.
ORDER BY сохраняется при batch extraction и формировании evidence samples.
Lifecycle меняется только после успешного чтения всего результата.
Automatic rebaselineИзменение SQL создает новое поколение наблюдаемого мира.
Immutable snapshots · environment-specific promotion
ACTIVESnapshot Ngeneration 4
→
EDITSnapshot N+1UPDATE AVAILABLE
→
PROMOTEPending baselinegeneration 5
→
SWITCHТолько после successfailed baseline сохраняет generation 4
Accepted переносится только для совпавших fingerprints предыдущей generation. Новые identities проходят обычный lifecycle.
Technical architecture
Детерминированная проверка внутри. AI-обвязка снаружи.
Решение о нарушении принимает SQL или rule-код. Модель создает, проверяет и исследует правило. Детерминированный runner фиксирует результат.
INPUTProduction sources
→
Read-only connections, связанные с logical source.
EXECUTIONSQL runner
→
Count, batched items, timeout и retry policy.
STATEPostgreSQL
→
Runs, snapshots, fingerprints и lifecycle events.
CONTROLInbox · REST · MCP
Доказательства и управление catalog.
Каждый deployment запускает конкретный snapshot определения.
Одно definition работает через собственный source binding каждого окружения.
Accept, promote, publish и disable остаются явными действиями.
MCP возвращает модели ограниченные данные без credentials.
SYSTEM
Consistique проверяет собственные обещания тем же движком.
Поставляется forward-only migrations · системные definitions защищены от редактирования
Readonly environment Self-consistency сверяет deployments, run pointers, leases, accepted backlog и проекцию lifecycle state.
Product boundaries
Отдельный слой контроля бизнес-данных.
Он доказывает непротиворечивость бизнес-данных и ведет историю конкретных нарушений.
ИнструментНаблюдаетГлавный вопросРезультат
Metrics / GrafanaАгрегаты во времениНасколько изменился сигнал?График и alert
Signals / MonqОперационные сигналыКак зарегистрировать и обработать проблему?Signal lifecycle
DiagnosticsДоступность механизмаРаботает ли компонент?Pass / fail
Incident managementРеакцию командыКто устраняет последствия?Incident workflow
ConsistiqueБизнес-противоречияКакие объекты нарушают правило?Fingerprint lifecycle
AI ASSISTED
Модель формулирует и исследует. Детерминированный движок проверяет и фиксирует.
prompt → draft → validate → dry run → review → publish
Where it matters
Тихие дефекты возникают на стыке нескольких систем.
Локально корректные данные могут противоречить бизнес-смыслу процесса в целом.
- 01Платежи и заказы
Оплата подтверждена, а исполнение не продвинулось.
- 02Подписки и доступ
Право выдано без основания или осталось после его окончания.
- 03Роли и ответственность
Исполнитель не принадлежит допустимой бизнес-группе.
- 04Внешние проекции
Локальная модель расходится с фактом в системе-владельце.
- 05Callback и event flows
Источник завершил операцию, а downstream остался незавершенным.
Короткая формула
Контроль продуктовой консистентности в production data.
business invariants as code+production data verification+violation lifecycle=lower cost of production errors