Часть 6. Конституция дата-платформы банка

Конституция дата-платформы отвечает на вопрос: какие решения не нужно заново обсуждать в каждой витрине. В базовом томе конституция фиксировала миссию, стек и дорожную карту приложения. Здесь она фиксирует миссию DataLakeHouse, локальный стек, границы сопоставления с боевым контуром, политику PII и правила изменения контрактов.

Минимальные файлы

specs/mission.md
specs/tech-stack.md
specs/roadmap.md
AGENTS.md

mission.md объясняет, зачем существует платформа. tech-stack.md говорит, какие инструменты разрешены. roadmap.md показывает порядок артефактов. AGENTS.md задаёт правила поведения агента.

Что должно быть в mission

Хорошая mission для учебного банка:

Платформа строит воспроизводимые аналитические marts для учебного банка.
Каждый дата-продукт должен иметь владельца, потребителя, grain, политику PII,
обещание по freshness, проверочные факты и отчёт ревьюера.

Плохая mission:

Сделать современную банковскую платформу данных.

Она звучит крупно, но не помогает агенту принять решение.

Непереговорные правила

Запишите правила, которые нельзя менять внутри отдельной витрины:

• marts не раскрывают прямые PII-поля;
• изменение grain требует утверждения;
• обязательные поля контракта нельзя удалять без заметки о ломающем изменении;
• dbt build --profiles-dir . — обязательная проверка, если dbt

доступен;

• проход ревьюера не должен редактировать файлы.

Если такое правило появляется впервые во время реализации, остановитесь и обновите конституционный файл, прежде чем продолжать SQL.

Разбор для читателя

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

В отличие от обычного технического стека, конституция говорит не только «какие инструменты используем», но и «какие решения агент не принимает сам». Для банковских данных это особенно важно. Grain, политика PII, SLA, ломающие изменения и методология риска не должны появляться как побочный эффект SQL.

Если агент предлагает изменить один из этих пунктов, он должен остановиться и попросить подтверждение, а не объяснять изменение постфактум.

Хорошая конституция короткая, но проверяемая. Плохая говорит: «соблюдай качество и безопасность». Хорошая говорит: «marts не раскрывают прямые PII», «изменение grain требует подтверждения человеком», «проверочные факты пишутся до SQL». Такие правила можно применить в ревью. Если правило нельзя проверить, оно остаётся лозунгом и не помогает агенту.

Читателю полезно относиться к конституции как к договору с будущим собой. В начале проекта всё кажется очевидным: Customer 360 — это одна строка на клиента, согласия считаются отдельно, риск-флаг учебный. Через десять изменений очевидность исчезает. Конституция сохраняет исходные решения в месте, где их увидит следующий проход агента и следующий ревьюер.

Практика

Составьте пять непереговорных правил для своей дата-платформы. Для каждого правила укажите, где оно живёт: AGENTS.md, mission.md, tech-stack.md, contract YAML или спецификация модели.

Qwen-запрос

Помоги составить конституцию учебной дата-платформы банка.

Перед записью файлов задай вопросы по миссии, стеку, политике PII, дрейфу контракта
и подтверждениям человеком.
SQL не пиши.

Минимальный выход

После главы:

• specs/mission.md описывает назначение платформы;
• specs/tech-stack.md фиксирует локальный стек и сопоставление с боевым контуром;
• specs/roadmap.md ведёт по артефактам;
• AGENTS.md запрещает утечку PII и неутверждённый дрейф контракта.

Типичная ошибка

Смешивать конституцию и спецификацию конкретной витрины. mission.md не должен перечислять SQL-поля mart_customer_360; спецификация модели не должна заново выбирать DuckDB или dbt.

Контрольные вопросы

1. Какие решения должны жить в конституции, а какие в спецификации модели?
2. Почему политику PII лучше фиксировать до профилирования источников?
3. Когда изменение поля контракта требует отдельного утверждения?