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

Банковские данные особенно плохо переносят «примерно правильно». В веб-фиче
ошибка часто видна пользователю. В дата-продукте ошибка может выглядеть как
нормальная таблица: строки есть, поля есть, тесты зелёные, но смысл уже
сломался. Именно поэтому банковский домен удобен для обучения SDD Data: он
заставляет явно писать обещания, ограничения и доказательства.

## Где риск выше обычного

В учебном банке нас интересуют пять классов риска:

- PII и прямые идентификаторы;
- платежи и риск-сигналы;
- согласия на доступ к данным;
- кредитный портфель и просрочка;
- отчётность и воспроизводимость расчётов.

Каждый класс риска требует не только SQL, но и проверяемого правила. «Не
раскрывать персональные данные» слишком широко. Рабочее правило звучит так:
`models/marts/` не содержит колонок `pii_email`, `phone`, `passport_number` и
других прямых идентификаторов, а ревьюер проверяет это до релиза.

## Почему dbt-тестов недостаточно

dbt-тесты хорошо ловят `not_null`, `unique`, accepted values и часть
кастомных инвариантов. Но они не знают, что `customer_360` обещан как «одна
строка на клиента», если вы не записали это в спецификации. Они не знают, что
добавление `product_code` меняет потребительский контракт. Они не знают, что
`risk_flag` — учебный сигнал, а не финальное решение кредитного скоринга.

Поэтому в SDD Data есть несколько слоёв:

- dbt-тесты проверяют форму и часть фактов;
- ODCS фиксирует технический контракт;
- ODPS описывает дата-продукт и потребителя;
- спецификация модели описывает grain и приёмочные факты;
- отчёт ревьюера связывает изменение с обещаниями.

## Пример плохой спецификации

```markdown
Сделать витрину клиентов для аналитиков. Добавить полезные поля по счетам и
операциям. Проверить качество данных.
```

Проблемы:

- не указан grain;
- не сказано, можно ли раскрывать PII;
- не определены «полезные поля»;
- нет SLA и свежести данных;
- «качество данных» не превращено в факты;
- нет владельца, который принимает дрейф.

## Хорошая версия

```markdown
Дата-продукт: customer_360.
Потребитель: аналитики клиентского портфеля и филиальной сети.
Витрина: mart_customer_360.
Гранулярность: одна строка на `customer_id`.
PII: в витрине нет прямых PII.
Свежесть данных: 24 часа.
Обязательные факты: `customer_id` unique/not_null, `total_balance_rub` not_null,
`risk_event_count_7d` присутствует, проверка списка запрещённых прямых PII проходит.
```

Такая спецификация не решает весь продукт, но задаёт границы, которые агент не
должен угадывать.

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

Банковский пример выбран не ради драматизма. Он удобен тем, что почти каждое
допущение имеет последствия. В интернет-магазине ошибочная витрина тоже может
навредить, но в банке даже учебные сущности сразу заставляют спрашивать: можно
ли показывать это поле, кто имеет право менять методологию, как доказать
воспроизводимость, что случится с отчётом ниже по цепочке. Эти вопросы дисциплинируют
читателя лучше, чем абстрактный пример с продажами.

Особенно важно различать «таблица построилась» и «данные можно использовать».
Зелёный `dbt build` говорит, что граф исполним и заявленные проверки прошли. Он
не говорит, что выбрана правильная гранулярность. Он не знает, что в одной
витрине нельзя смешивать клиента и счёт. Он не видит, что поле выглядит как
скоринговый вывод, хотя на самом деле является учебным флагом источника. Это не
недостаток dbt; это граница инструмента.

Читателю полезно тренироваться на плохих спецификациях. Плохая спецификация
обычно звучит уверенно: «сделать полезную витрину», «добавить качество»,
«учесть риски». В ней мало явных ошибок, потому что она почти ничего не
обещает. Хорошая спецификация, наоборот, выглядит более узкой. Она говорит:
одна строка на клиента, прямые PII запрещены, freshness 24 часа, обязательные
поля такие-то, проверки такие-то. Узость здесь не слабость, а способ сделать
работу проверяемой.

В этой главе важно не запомнить список банковских рисков, а привыкнуть к
вопросу «как это будет доказано?». Если правило нельзя превратить в команду,
SQL-запрос, ручной шаг ревьюера или подтверждение человеком, оно пока не
готово для агента. Хороший агент не должен угадывать, что значит «корректно»;
он должен получить критерий, по которому его работу можно отклонить.

## Практика

Возьмите один mart из README и напишите для него три риска: grain, PII и
дрейф контракта. Для каждого риска сформулируйте не лозунг, а проверяемое
правило. Если правило нельзя проверить, перепишите его до команды или ручного
шага ревьюера.

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

После главы создайте короткую заметку:

```markdown
# Заметки о рисках данных

## PII
## Grain
## Freshness
## Дрейф контракта
## Подтверждения человеком
```

Заполните по одному правилу в каждый раздел. Если правило нельзя проверить,
перепишите его как команду, SQL, ревью схемы или подтверждение человеком.

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

Писать в `AGENTS.md`: «соблюдай банковские требования». Для агента это почти
бесполезно. Ему нужны конкретные запреты, разрешённые входные модели, поля
контракта и проверки.

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

1. Почему зелёный `dbt build` не доказывает правильность дата-продукта?
2. Какой дефект опаснее: синтаксическая ошибка SQL или незаметная смена grain?
3. Где лучше фиксировать политику PII: в чате, SQL-комментарии или спецификации?