Контроль качества и контракт MCP

Приборная панель для проверки золотого стандарта перед выводом в production. Это read-only линзы над корпусом — не отдельные данные, а срезы существующих БД (Нормативы, Источники, Концепты, Метрики). Задача — увидеть дыры раньше, чем стандарт уедет на клиента.

Что показывает каждый прибор:

• Зрелость нормативов — доска по стадии (черновик → валидировано внутри → … → опубликовано). Главный вход в свод зрелости: видно, что ещё в черновике.
• Без обоснования — нормативы, не опирающиеся ни на один концепт. Разрыв провенанса «стандарт без теории».
• Без метрики — нормативы без привязанной EEQ-метрики. Норму нельзя измерить.
• Воронка источников — источники по статусу (нашли → в обработке → интегрировано). Что ещё не доведено до концептов.
• Карта концептов — концепты по зрелости + тип утверждения и источник. Ловит NOTA-синтез без опоры на источник.
• Покрытие EEQ — метрики по категориям Федоренко (результативность / эффективность / качество). Виден перекос.

Пусто в «дырных» приборах = чисто. Это и есть критерий готовности.

Это дизайн-контракт первого интерфейса Слоя 1 — MCP-сервера, отдающего золотой стандарт агентам и людям. Статус: дизайн замкнут, реализация не начата. Расширяет раздел 7 README. Опирается на дисциплину корпуса (README раздел 5) как на контракт между корпусом и интерфейсом.

1. Три режима поверх одного корпуса

MCP-сервер — не «оголённые 7 баз как CRUD», а набор глаголов под трёх потребителей корпуса (человек-автор работает в Notion мимо сервера).

Режим генерации (retrieval / few-shot). Агент строит артефакт и спрашивает у стандарта «как должно быть»: концепты, нормы с рубрикой, эталонные примеры, разрешение терминов. Read-heavy, низкий риск.

Режим оценки (diff). Агенту дают артефакт реальной компании — он выносит вердикт против нормы: уровень по рубрике + обоснование + чего не хватает. Ядро ценности продукта.

Режим консультации (guide). Человек ещё думает — стандарт ведёт его сократически по методологическому маршруту. Самый коварный режим: опасность — протечка эрудиции подключённой LLM вместо grounding в корпус. Поэтому каждое содержательное утверждение тянется к концепту→норме→источнику.

Замыкание: консультант = diff (где ты сейчас) + метод-маршрут (как двигаться) + provenance (из стандарта, не из эрудиции). missing_signals из вердикта — это повестка разговора.

2. Архитектурные решения (фундамент)

• Сервер читает не живой Notion, а скомпилированный снимок. Скорость, развязка от Notion rate limits, воспроизводимость (вердикт против снимка известной версии). Notion — авторская среда; снимок — рантайм стандарта.
• Read-only к стандарту. Запись в корпус — работа автора в Notion, мимо сервера.
• Вердикты клиента = Слой 2, не Слой 1. Сервер их возвращает, но не персистит. У себя сервер ведёт только служебный judgment log (телеметрия суждений для калибровки).
• Асимметрия толщины. judge-soft толстый (своя процедура суждения ради контроля и калибровки); guide тонкий (диалог ведёт подключённая модель, сервер stateless). Где нужен воспроизводимый вердикт — процедура внутри; где живой диалог — процедуру ведёт потребитель.

3. Build-пайплайн: Notion → снимок

Контур: Notion (9 баз, авторская истина) → компиляция → иммутабельный версионированный снимок → сервер держит в памяти.

Денормализация в коды. Notion отдаёт relation как page-URL; build переписывает их в канонические коды и собирает разнесённое по 9 базам в самодостаточные документы. Норма встраивает eval-контракт, метрики и few-shot инлайн; метод встраивает шаги по порядку. Цепь провенанса предвычисляется.

Версия снимка. Semver корпуса + хэш + timestamp, ортогонально semver отдельных норм. Снимок иммутабелен, старые хранятся. Вердикт привязан к тройке (norm_code, norm_version, snapshot_version).

Build-gate. Сборка прогоняет инварианты из README раздел 5 (норма без обоснования, концепт без источника, норма без метрики/eval-set, relation на безкодовый узел, дубль кода). Это машинная версия страницы «Контроль качества». prod-канал не соберётся при нарушении; dev-канал предупреждает.

Два канала из одного пайплайна. Фильтр по зрелости — параметр сборки. dev = весь корпус с пометкой зрелости; prod = только зрелость ≥ порога. Совпадает с границей «черновик в Notion / опубликованный стандарт».

Триггер — не realtime. По кнопке (автор закончил, промотировал) + опционально ночная сборка. Стандарт не должен дёргаться от каждой авторской правки.

Хранение. Иммутабельные JSON-документы в immutable store. Корпус мал — сервер грузит prod-снимок целиком в память, get_* отвечают мгновенно. Пересборка → hot reload.

4. Формат снимка

Принцип: строгая нормализация в Notion, контролируемая денормализация в снимке. Единственный источник истины каждой сущности — её документ по коду. В родительские документы build встраивает компактные проекции зависимостей ради ответа одним lookup; проекции порождаются из источника одним проходом, рассинхрон невозможен.

Граница встраивания: рубрика/сигналы/вопросы → внутрь нормы целиком; шаги → внутрь метода; few-shot и метрики → компактной проекцией; концепт-обоснование, источник, термин, граф «опирается на» → только кодом.

Документ нормы (ядро):

{
  "code": "COMPASS.DIAGNOSIS.N1", "type": "norm",
  "title": "...", "module": "COMPASS", "area": "...",
  "as_should_be": "...",
  "rubric": [{"level":"отсутствует","signs":"..."}, ...4 уровня],
  "signals": "...", "assessment_questions": "...",
  "hardness": "soft",            // роутер evaluate
  "verdict_type": "градация",      // шкала level
  "version": "0.1.0", "maturity": "валидировано внутри",
  "grounding": ["COMPASS.DIAGNOSIS.C1"],
  "metrics": [{"code":"...M1","eeq":"качество","measure":"..."}],
  "examples": [{"code":"...N1.E1","input":"...","expected_level":"частично"}],
  "depends_on": [],
  "provenance": "Rumelt 2011 → ...C1 → ...N1"
}

Документ метода:

{
  "code": "COMPASS.CASCADE.P1", "type": "method",
  "goal": "...", "source_concept": "COMPASS.CASCADE.C1",
  "steps": [
    {"n":1,"title":"Выигрышная аспирация","elicit":"...",
     "ready_signal":"...","concept":"...C1","norm":"COMPASS.CASCADE.N1"},
    ...5 шагов, каждый с привязанной нормой
  ]
}

Остальные типы: концепт (distillation, claim_type, authority_tier, source, depends_on/basis_for, terms, provenance); источник (publisher, authors, year, tier); метрика (eeq, measure); пример (norm, input, expected_level); термин (short_def, concept); модуль (why/how/what + индексы кодов + покрытие EEQ).

5. Контракт глаголов

Сквозное: каждый ответ несёт код узла и snapshot_version; краткий провенанс инлайнится в узлы.

Группа 0 — Навигация

• `list_modules()` → ромб целиком, 5 модулей.
• `get_module(name)` → карта модуля: направления, концепты, нормы, методы, покрытие EEQ.

Группа 1 — Resolve

• `resolve_term(term)` → краткое определение + код концепта (pointer discipline).
• `search_corpus(query, filter?)` → семантический ретрив. Отложен в v2 (единственный глагол, требующий вектора).

Группа 2 — Retrieve

• `get_concept(code)` → узел теории + провенанс + граф зависимостей.
• `get_norm(code)` → полный eval-контракт (рубрика, сигналы, вопросы, жёсткость, метрики, примеры).
• `get_method(code)` → цель + упорядоченные шаги с elicit-вопросами и привязанными нормами.
• `list_methods(module)` → перечень маршрутов (кандидат на схлопывание в get_module).
• `get_examples(norm_code)` → eval-set для few-shot.
• `get_provenance(code)` → полная цепь Источник→Концепт→Норматив→Метрика.
• `get_source(code)` → издатель/авторы/год/тир (опционально для v1).

Группа 3 — Judge

• `evaluate(artifact, norm_code)` → вердикт (ниже). Роутер по жёсткости.
• `evaluate_against_module(artifact, module)` → профиль соответствия по всем нормам модуля. Движок самооценки сайта и диагностики CVD.

Глаголы ложатся на документы снимка один-к-одному; сервер почти не имеет логики сверх чтения индекса по коду. Ум — в компиляции, не в рантайме.

Контракт вердикта

{
  norm, norm_version, snapshot_version,
  level,                  // из рубрики; шкала по verdict_type
  verdict_type,           // machine_deterministic (crisp) | machine_draft (soft)
  status,                 // autonomous | requires_human_confirmation
  confidence, rationale,
  evidence[],             // цитаты из артефакта
  missing_signals[],      // чего не хватает до следующего уровня
  provenance
}

crisp → автономный детерминированный вердикт. soft → assisted draft через LLM с зашитым контрактом (рубрика+сигналы+few-shot), статус requires_human_confirmation, пока не открыта автономия (раздел 6).

Compass: все 10 норм — soft. Значит консультация/diff по Compass идёт только через soft-ветку; чистый self-serve по Compass невозможен, пока машина-rater не наберёт κ.

6. Калибровочный контур: машина как rater

Машина входит в существующий протокол межоценочного согласия как ещё один оценщик.

• Правило «оценщик-не-автор» — машина не писала корпус, пара «человек + машина» легитимна.
• Правило слепого пула — критично для машины. few-shot встроены в норму снимка; калибровать κ на тех же примерах = мерить подсмотренный ответ. Инвариант build-gate: eval-set (в снимке, машина видит) и калибровочный пул (вне снимка, как few-shot не подаётся) не пересекаются.

judgment log (служебный mutable store): artifact_id, norm_code, norm_version, snapshot_version, rater=machine, level, confidence, rationale, missing_signals, is_calibration, ts.

БД «Прогоны согласия» (из протокола): строка = (норматив × артефакт × оценщик × уровень × дата). Машина добавляет себя как значение rater. κ Коэна (quadratic-weighted) считается машина↔человек тем же аппаратом, что человек↔человек.

κ привязан к версии. Измеряется для тройки (norm_code, norm_version, snapshot_version) — смена рубрики поднимает версию и обнуляет старый κ.

Лестница автономности (те же пороги, что для людей):

• κ < 0.6 — машина по норме не годится; soft-вердикты всегда requires_human_confirmation. Сигнал: рубрику доработать либо норма CVD-зависимая по природе.
• 0.6 ≤ κ < 0.7 — draft полезен как черновик, статус остаётся requires_human_confirmation.
• κ ≥ 0.7 устойчиво — можно поднять автономию: вердикт autonomous. soft-норма становится self-serve не ослаблением требований, а накоплением доказанного согласия.

Автономность — не глобальный флаг, а вычисляемое поле на тройке (норма, версия, снимок).

Почему это измерение отчуждаемости, а не её обход. Человек-CVD может неосознанно тянуть смысл из головы автора. Машина видит только текст нормы. Согласие машины с человеком на κ≥0.7 = доказательство, что вердикт держится на тексте стандарта, а не на носителе. Машина-rater реализует определение отчуждаемости «без головы автора» в чистом виде.

7. Принятые решения и открытые развилки

Решено:

• Вектор (search_corpus) — отложен в v2. v1 — навигационный сервер на кодах и relation-обходе.
• Judge-цикл — атомарный, без consult_step. Оркестровку ведёт подключённая модель.
• Сервер read-only к стандарту; вердикты клиента — Слой 2.

Открыто на реализацию:

• get_source / list_methods — кандидаты на схлопывание (источник — через провенанс, методы — через get_module).
• Выбор LLM для soft-draft и его стоимость на soft-вызов.
• Порог зрелости для prod-канала снимка.

8. Граница и следующие шаги

Дизайн замкнут без разрыва: дисциплина корпуса → build-gate → снимок → глаголы → judge (soft/crisp) → judgment log → машина-rater в inter-rater → автономность по κ → расхождения растят версию нормы → обратно в дисциплину.

Реализация не начинается, пока Compass не пройдёт inter-rater (финальные ворота в production). При первом прогоне завести БД «Прогоны согласия» с полем rater (человек/машина), чтобы машинная калибровка шла с первого дня тем же аппаратом.