Тема: Часть 6. Конституция дата-платформы банка
Уровень сложности: Средний
Расчётное время изучения: 3-4 часа (теория — 1,5 ч, практика — 1,5 ч, разбор кейсов — 1 ч)
Предварительные требования: Базовое понимание архитектуры Data Lakehouse
Знакомство с принципами работы dbt и DuckDB
Понимание концепции grain, freshness и data contracts
Опыт работы с аналитическими витринами (marts)
Базовые знания о политиках PII и защите персональных данных
Цели обучения: Сформулировать миссию дата-платформы банка так, чтобы она помогала агенту принимать конкретные решения
Различать, какие правила относятся к конституции, а какие — к спецификации конкретной модели
Составить набор непереговорных правил (5–10 пунктов) с явным указанием места их фиксации
Определить порядок действий агента при обнаружении конфликта между удобством витрины и долгосрочными принципами
Проводить ревью изменений контракта с учётом ломающих изменений и требований к подтверждению человеком
Обзор: Конституция дата-платформы — это короткий, но проверяемый набор принципов, который фиксирует миссию, разрешённый стек, дорожную карту артефактов и правила поведения агента. В отличие от обычного технического стека, конституция отвечает не только на вопрос «какие инструменты используем», но и на вопрос «какие решения агент не принимает сам». Для банковской аналитики это критически важно: grain, политика PII, SLA, ломающие изменения и методология риска не должны появляться как побочный эффект SQL. В этой части рассматривается, как собрать четыре минимальных файла (mission.md, tech-stack.md, roadmap.md, AGENTS.md), какие правила должны стать непереговорными, как распознать типичную ошибку смешения конституции и спецификации витрины, и как относиться к конституции как к договору с будущим собой.
Ключевые концепции: Конституция дата-платформы: Короткий и проверяемый документ (набор из 4 файлов), который фиксирует миссию, стек, дорожную карту и правила поведения агента. Отвечает на вопрос: какие решения не нужно заново обсуждать в каждой витрине.
Mission.md: Файл, объясняющий, зачем существует платформа. Хорошая mission конкретна и проверяема: «Каждый дата-продукт должен иметь владельца, потребителя, grain, политику PII, обещание по freshness, проверочные факты и отчёт ревьюера». Плохая — звучит крупно, но не помогает принять решение.
Tech-stack.md: Файл, фиксирующий локальный стек и сопоставление с боевым контуром. Определяет, какие инструменты разрешены в учебной среде (DuckDB, dbt) и как они соотносятся с продуктивным контуром.
Roadmap.md: Файл, показывающий порядок артефактов. Ведёт агента и ревьюера по последовательности шагов: что создаётся раньше, что — позже.
Agents.md: Файл, задающий правила поведения агента. Содержит непереговорные ограничения: запрет утечки PII, требование подтверждения при изменении grain, запрет на редактирование файлов на этапе ревью.
Непереговорные правила: Принципы, которые нельзя менять внутри отдельной витрины без обновления конституционного файла. Примеры: marts не раскрывают прямые PII-поля; изменение grain требует утверждения; обязательные поля контракта нельзя удалять без заметки о ломающем изменении; dbt build --profiles-dir . — обязательная проверка; проход ревьюера не должен редактировать файлы.
Grain: Уровень гранулярности строки в витрине (например, одна строка на клиента). Изменение grain — это ломающее изменение, требующее утверждения человека.
Pii (personally identifiable information): Персонально идентифицируемая информация. Политика PII фиксируется в конституции до профилирования источников, чтобы избежать случайного раскрытия.
Ломающее изменение (breaking change): Изменение в контракте, которое может сломать потребителей: удаление обязательного поля, изменение grain, изменение типа данных. Требует отдельного утверждения и заметки.
Data contract (контракт данных): Спецификация дата-продукта: владелец, потребители, grain, поля, политика PII, SLA по freshness, проверочные факты. Описывается в YAML или в спецификации модели.
Спецификация модели: Документ, описывающий конкретную витрину (например, mart_customer_360): SQL-поля, бизнес-логика, тесты. Не должна заново выбирать стек или формулировать миссию.
Проверочные факты (check facts): Утверждения, которые пишутся до SQL и проверяются после. Позволяют зафиксировать ожидаемое поведение модели до её реализации.
Договор с будущим собой: Метафора, описывающая роль конституции: в начале проекта всё очевидно, но через десять изменений очевидность исчезает. Конституция сохраняет исходные решения в месте, где их увидит следующий проход агента и ревьюер.
Важные даты: До старта профилирования источников: Зафиксировать политику PII в mission.md или AGENTS.md, чтобы избежать случайного раскрытия при первом сканировании данных.
До написания sql: Записать проверочные факты (check facts) для каждой модели. Это правило включается в конституцию как непереговорное.
Перед изменением grain или удалением обязательного поля контракта: Остановиться, обновить конституционный файл, получить подтверждение человека, и только после этого менять SQL.
При первом появлении нового правила во время реализации: Остановиться и обновить конституционный файл, прежде чем продолжать SQL. Не оставлять правило в виде комментария в коде.
Практические упражнения: Название: Составление пяти непереговорных правил
Проблема: Составьте пять непереговорных правил для своей учебной дата-платформы банка. Для каждого правила укажите, где оно живёт: AGENTS.md, mission.md, tech-stack.md, contract YAML или спецификация модели. Правила должны быть проверяемыми, а не лозунгами.
Решение: Шаг 1. Определите пять рисков, которые чаще всего возникают при работе с банковскими витринами: утечка PII, дрейф grain, удаление обязательных полей, пропуск проверки dbt build, редактирование файлов на этапе ревью. Шаг 2. Сформулируйте каждое правило в виде утверждения, которое можно проверить в ревью. Шаг 3. Определите место фиксации:
- Правило 1 «marts не раскрывают прямые PII-поля (ФИО, телефон, email в открытом виде)» → AGENTS.md
- Правило 2 «изменение grain требует утверждения владельца продукта и заметки в roadmap.md» → AGENTS.md + roadmap.md
- Правило 3 «обязательные поля контракта (owner, consumer, grain, sla) нельзя удалять без записи о ломающем изменении» → contract YAML + AGENTS.md
- Правило 4 «перед merge запускается
dbt build --profiles-dir .; сборка должна пройти без ошибок» → tech-stack.md + AGENTS.md - Правило 5 «ревьюер не редактирует файлы, а оставляет замечания; правки вносит автор» → AGENTS.md
Шаг 4. Проверьте каждое правило: можно ли его нарушить так, чтобы это было видно в diff или в логе dbt? Если нет — переформулируйте.
Сложность: intermediate
Название: Различение конституции и спецификации модели
Проблема: Дан фрагмент документа, описывающего витрину mart_customer_360. Определите, какие строки относятся к конституции дата-платформы, а какие — к спецификации конкретной модели. Объясните, почему смешение этих слоёв — типичная ошибка.
Решение: Шаг 1. Прочитайте фрагмент и выпишите все утверждения. Шаг 2. Классифицируйте каждое утверждение:
- «Платформа использует dbt 1.8 и DuckDB 1.1 в локальном контуре, в боевом — Snowflake» → конституция (tech-stack.md), потому что это про стек в целом.
- «mart_customer_360 содержит поля customer_id, full_name, birth_date, segment_code» → спецификация модели, потому что это про конкретную витрину.
- «Marts не раскрывают прямые PII-поля; full_name маскируется как Ivanov I.I.» → конституция (AGENTS.md) + спецификация (правило маскирования именно в этой витрине).
- «Grain — одна строка на клиента; изменение grain требует утверждения» → часть про «утверждение» — конституция, часть про «одна строка на клиента» — спецификация.
Шаг 3. Сформулируйте вывод: конституция описывает общие принципы и границы, спецификация — конкретную реализацию. Смешение приводит к тому, что при появлении новой витрины приходится заново решать, какой стек использовать, и каждое решение принимается ad hoc.
Сложность: intermediate
Название: Проверяемость формулировок mission.md
Проблема: Перед вами две формулировки mission.md. Определите, какая из них лучше, и переформулируйте плохую так, чтобы она стала проверяемой в ревью.
Решение: Шаг 1. Прочитайте формулировки: A) «Сделать современную банковскую платформу данных». B) «Платформа строит воспроизводимые аналитические marts для учебного банка. Каждый дата-продукт должен иметь владельца, потребителя, grain, политику PII, обещание по freshness, проверочные факты и отчёт ревьюера». Шаг 2. Сравните: формулировка A не даёт агенту критерия для принятия решения. Формулировка B перечисляет обязательные атрибуты каждого дата-продукта — их можно проверить по contract YAML. Шаг 3. Переформулируйте A в проверяемый вид: «Платформа предоставляет воспроизводимые marts на dbt + DuckDB; каждый mart публикуется вместе с contract YAML, содержащим owner, consumer, grain, pii_policy, freshness_sla, check_facts и review_report. Отсутствие любого из семи атрибутов — блокирующее замечание ревьюера». Шаг 4. Сформулируйте правило: хорошая mission перечисляет обязательные атрибуты или действия, плохая — оперирует абстрактными ценностями.
Сложность: beginner
Название: Реакция агента на конфликт
Проблема: Агент при реализации витрины mart_transactions_daily обнаружил, что для удобства аналитика нужно добавить колонку card_pan_hash, которая является прямым PII-полем. Опишите правильную последовательность действий агента в соответствии с конституцией.
Решение: Шаг 1. Агент должен остановиться и не добавлять поле до выяснения. Шаг 2. Агент проверяет AGENTS.md: «marts не раскрывают прямые PII-поля». Поле card_pan_hash относится к PII. Шаг 3. Агент проверяет, есть ли в mission.md или AGENTS.md исключение для hash-значений. Если исключения нет — поле нельзя добавить в mart. Шаг 4. Агент формулирует запрос: либо изменить политику PII в конституции (с подтверждением человека), либо предложить аналитику альтернативу (например, агрегированную метрику count_distinct_pan). Шаг 5. Только после утверждения человеком и обновления конституционного файла агент продолжает работу с SQL. Шаг 6. Если в проекте нет конституции, агент должен остановиться и попросить её создать, а не принимать решение самостоятельно.
Сложность: intermediate
Название: Составление Qwen-запроса для создания конституции
Проблема: Составьте запрос к агенту (по образцу из главы), который поможет собрать конституцию учебной дата-платформы банка. Запрос должен быть самодостаточным и явно запрещать преждевременное написание SQL.
Решение: Шаг 1. Определите цель запроса: собрать четыре файла конституции (mission.md, tech-stack.md, roadmap.md, AGENTS.md). Шаг 2. Перечислите обязательные блоки вопросов, на которые агент должен получить ответы перед записью: миссия, стек, политика PII, дрейф контракта, подтверждения человеком. Шаг 3. Добавьте явный запрет: «SQL не пиши». Шаг 4. Итоговый запрос: «Помоги составить конституцию учебной дата-платформы банка. Перед записью файлов задай вопросы по миссии, стеку, политике PII, дрейфу контракта и подтверждениям человеком. SQL не пиши». Шаг 5. Проверьте: запрос начинается с цели, перечисляет обязательные уточнения, заканчивается запретом. Такой запрос предотвращает ситуацию, когда агент сразу пишет SQL без конституции.
Сложность: beginner
Кейсы: Название: Дрейф grain в витрине клиентских сегментов: урок для конституции
Сценарий: В учебном банке была развёрнута витрина mart_customer_segment с grain «одна строка на клиента в месяц». Через шесть итераций аналитик попросил добавить детализацию по продуктам: «одна строка на клиента и продукт в месяц». Агент, не останавливаясь, изменил SQL и обновил модель. Потребитель — дашборд сегментации — перестал работать, потому что ожидал одну строку на клиента.
Задача: Агент принял решение об изменении grain самостоятельно, без утверждения владельца продукта. В проекте не было конституционного файла, фиксирующего правило: «изменение grain требует утверждения». Каждое изменение grain приходилось обсуждать заново, и почти всегда выбирался вариант «как удобнее сейчас».
Решение: Команда остановила работу над витринами и собрала конституцию из четырёх файлов. В AGENTS.md появилось правило: «Изменение grain требует утверждения владельца дата-продукта и записи в roadmap.md. Агент не меняет grain самостоятельно». В mission.md добавили перечень обязательных атрибутов каждого дата-продукта, включая grain. В contract YAML mart_customer_segment зафиксировали grain и пометили его как обязательное поле, которое нельзя удалять без ломающего изменения.
Результат: Через две недели после введения конституции поступил новый запрос на изменение grain в mart_risk_flags. Агент остановился, сформулировал запрос на утверждение, обновил roadmap.md и только после согласия владельца изменил SQL. Дашборды продолжали работать. Время ревью изменений grain сократилось, потому что правило стало проверяемым: ревьюер видит diff grain в contract YAML.
Извлечённые уроки: Правило «изменение grain требует утверждения» должно жить в AGENTS.md, а не в комментарии SQL.
Grain — обязательное поле contract YAML; его удаление или изменение — блокирующее замечание ревьюера.
Без конституции каждое изменение grain обсуждается заново и почти всегда побеждает ближайшая задача.
Связанные концепции: Grain
Непереговорные правила
AGENTS.md
Договор с будущим собой
Название: Утечка PII через удобную колонку: как конституция остановила регрессию
Сценарий: В витрине mart_transactions_weekly аналитик попросил добавить колонку counterparty_name, чтобы видеть имена контрагентов. Агент добавил поле, не проверив политику PII. Через месяц выяснилось, что колонку начали использовать в отчётах для внешних партнёров, и часть имён утекла за периметр банка.
Задача: Политика PII существовала в виде общей фразы в README проекта: «Соблюдайте требования по защите персональных данных». Формулировка не была проверяемой, и ревьюер не мог блокировать изменение по формальному признаку. Кроме того, политика была зафиксирована слишком поздно — уже после профилирования источников, когда имена контрагентов уже были видны в сэмплах.
Решение: Команда переработала конституцию. В AGENTS.md появилось конкретное правило: «Marts не раскрывают прямые PII-поля: ФИО, телефон, email, название контрагента в открытом виде. Допускается маскированное представление (например, 'Ivanov I.I.') или агрегаты (count, sum без идентификаторов)». Политику зафиксировали до профилирования источников в следующем спринте. В contract YAML каждой витрины появилось обязательное поле pii_policy, которое заполняется автором и проверяется ревьюером.
Результат: Через три спринта поступил аналогичный запрос: добавить поле counterparty_inn (ИНН контрагента). Агент остановился, проверил AGENTS.md и обнаружил, что ИНН не входит в список прямых PII, но относится к чувствительной коммерческой информации. Агент сформулировал запрос на уточнение политики, владелец продукта подтвердил, что ИНН допустим только в маскированном виде, и policy была обновлена в AGENTS.md. Утечка прекратилась, ревьюер теперь блокирует PR без заполненного pii_policy.
Извлечённые уроки: Политика PII должна быть конкретной и проверяемой: перечислять поля, а не апеллировать к общим принципам.
Политику PII нужно фиксировать до профилирования источников, иначе первые сэмплы создают иллюзию безопасности.
Обязательное поле pii_policy в contract YAML превращает политику из лозунга в блокирующее замечание ревьюера.
Связанные концепции: PII (Personally Identifiable Information)
Непереговорные правила
mission.md
Data contract (контракт данных)
Название: Ревьюер правит SQL и ломает воспроизводимость: урок о границах ролей
Сценарий: В команде был налажен процесс: ревьюер открывает PR, вносит правки в SQL напрямую и мерджит. Через полгода обнаружилось, что часть моделей в main-ветке не воспроизводится локально: dbt build падает с ошибкой, потому что ревьюер использовал функцию, которой нет в зафиксированном стеке.
Задача: В проекте не было правила «ревьюер не редактирует файлы». Роль ревьюера была размытой: он одновременно и проверял, и правил. Проверяемость правил конституции снижалась, потому что ревьюер мог «незаметно» обойти любое ограничение, просто поправив код.
Решение: В AGENTS.md добавили правило: «Проход ревьюера не должен редактировать файлы. Ревьюер оставляет замечания в комментариях и ставит status check; правки вносит автор следующим коммитом». В tech-stack.md зафиксировали минимальную версию dbt и DuckDB, а в roadmap.md добавили шаг: «Перед merge запускается dbt build --profiles-dir .; зелёная сборка — обязательное условие».
Результат: В течение следующего месяца три PR были отклонены по формальному признаку: ревьюер оставил замечание, автор внёс правку, повторный запуск dbt build прошёл. Воспроизводимость локального контура восстановилась. Команда также зафиксировала, что любые новые зависимости сначала вносятся в tech-stack.md и только потом в код.
Извлечённые уроки: Роль ревьюера — проверять, а не править. Смешение ролей размывает конституцию.
dbt build --profiles-dir . — обязательная проверка, она должна быть зафиксирована в tech-stack.md и roadmap.md.
Версии инструментов — часть стека, а не деталь реализации; их изменение требует обновления tech-stack.md.
Связанные концепции: Непереговорные правила
tech-stack.md
roadmap.md
AGENTS.md
Советы по изучению: Держите конституцию короткой: четыре файла по 1–2 страницы лучше, чем один документ на двадцать страниц. Длинные документы не читают ни агенты, ни ревьюеры.
Перед записью mission.md задайте себе вопрос: «Может ли агент по этой mission принять конкретное решение в спорной ситуации?» Если ответ «нет» — переформулируйте.
Каждое непереговорное правило формулируйте так, чтобы его можно было проверить в diff или в логе сборки. Фраза «соблюдайте качество» — лозунг. Фраза «marts не раскрывают поле full_name» — правило.
Фиксируйте политику PII до профилирования источников. После первого сэмпла у вас уже будет иллюзия, что «всё не так страшно», и политика отложится.
При первом появлении нового правила во время реализации — останавливайтесь и обновляйте конституционный файл. Не оставляйте правило в виде комментария в SQL: следующий агент его не увидит.
Разделяйте mission.md (зачем), tech-stack.md (чем), roadmap.md (в каком порядке), AGENTS.md (что нельзя) и спецификацию модели (что именно строится). Смешение этих слоёв — главный источник ошибок.
Относитесь к конституции как к договору с будущим собой. То, что очевидно сегодня, перестанет быть очевидным через десять изменений.
Используйте запрос «Помоги составить конституцию… SQL не пиши» как шаблон: цель, обязательные уточнения, запрет преждевременных действий.
При ревью сначала проверяйте конституционные правила (PII, grain, обязательные поля), потом — SQL. Это ускоряет ревью и делает замечания блокирующими по формальному признаку.
Дополнительные ресурсы: Базовый том курса (конституция приложения): Описывает mission, стек и дорожную карту приложения в целом; часть 6 расширяет эту идею на Data Lakehouse.
Документация dbt по data contracts: https://docs.getdbt.com — раздел о контрактах данных и схемах моделей.
Документация duckdb: https://duckdb.org/docs — описание локального аналитического движка, используемого в учебном контуре.
Фреймворк «data mesh» (zhamak dehghani): Концепция domain ownership и data contracts, лежащая в основе идеи constitution файла.
Gdpr и банковские регуляторные требования: Обзор требований к защите персональных данных в финансовом секторе (для контекста политики PII).
Статья «the ten fallacies of data science»: О распространённых ошибках при построении аналитических платформ, включая отсутствие явной политики.
Резюме: Конституция дата-платформы банка — это четыре коротких файла (mission.md, tech-stack.md, roadmap.md, AGENTS.md), которые фиксируют миссию, разрешённый стек, дорожную карту артефактов и непереговорные правила поведения агента. Главная ценность конституции — в её проверяемости: каждое правило должно быть сформулировано так, чтобы его можно было применить в ревью. Плохая конституция говорит «соблюдайте качество и безопасность», хорошая — «marts не раскрывают прямые PII», «изменение grain требует подтверждения», «проверочные факты пишутся до SQL». Конституцию нужно собирать до профилирования источников, обновлять при появлении нового правила и относиться к ней как к договору с будущим собой: то, что очевидно сегодня, перестанет быть очевидным через десять изменений. Типичная ошибка — смешение конституции и спецификации конкретной витрины; этого следует избегать, разделяя общие принципы и реализацию по разным слоям документации.