Введение
В уроке 3 мы определили 4-мерный фреймворк. Рабочий инструмент требует пяти дополнительных компонентов: шаблон scoring sheet, правила tie-breaking, механизм калибровки, выбор инструмента, и (в уроке 7) фактическое применение на портфель кандидатов.
Этот урок строит каждый из пяти. К концу вы можете либо открыть spreadsheet и через час получить scored портфель из 15 кандидатов, либо настроить scoring tag-set в catalog tool (Atlan, Collibra, OpenMetadata) для развёртывания на всю программу.
Weighted scoring sheet — шаблон
Это minimum viable scoring sheet. Production-версия может расширяться, но эти 14 колонок — non-negotiable:
| # | Колонка | Описание | Пример |
|---|---|---|---|
| 1 | candidate_id | Внутренний ID (стабильный между версиями) | swiftride-cde-2026-001 |
| 2 | dataset_name | Human-readable | driver_earnings_ledger |
| 3 | physical_location | Где живёт | Snowflake / swiftpay.dl_marts.driver_earnings_v3 |
| 4 | proposed_owner | Кандидат на Data Owner | VP Finance, Marketplace BU |
| 5 | D1_financial_score | 1-5 | 5 |
| 6 | D1_rationale | 1-2 предложения обоснования | Прямой фид в revenue recognition; экспозиция $40M+ при ошибке |
| 7 | D2_regulatory_score | 1-5 | 4 |
| 8 | D2_rationale | Какие регуляции затронуты | SOX 404 (после IPO), labor (по странам), IRS 1099 |
| 9 | D3_operational_score | 1-5 | 5 |
| 10 | D3_rationale | Tier и базис RTO | Tier-1; payouts блокируют driver app |
| 11 | D4_reputational_score | 1-5 | 4 |
| 12 | D4_rationale | Прокси public exposure / штрафа | Споры по driver earnings — media-covered (прецедент DACH 2024) |
| 13 | weighted_score | Вычислено: Σ(score × weight) | 4.5 |
| 14 | proposed_status | CDE / borderline / not-CDE | CDE подтверждён |
Дополнительные production-колонки:
scoring_date,scored_by,reviewed_by— audit trailweights_version— какие веса применены (изменяемые между циклами)back_test_incidents— исторические инциденты, через которые back-testing проходилdecision_council_minutes— ссылка на запись о решении советаnext_review_date— минимум ежегодная рецертификация
Формат — обычно spreadsheet (Excel / Google Sheets) для первого цикла, потом — экспорт в каталог (см. блок про инструменты ниже).
Правила tie-breaking
Сценарий: два кандидата получают одинаковый score (например, оба weighted 3.5). Resource constraints не позволяют treat обоих одинаково на T+3M. Какой приоритизировать?
Отраслевые tie-breakers, по порядку:
- Regulatory dimension (D2) выигрывает ties. Если D2_A > D2_B при равном weighted, приоритизируйте A. Обоснование: пропущенный regulatory deadline > пропущенное внутреннее улучшение.
- Financial dimension (D1) — второй tier breaker. При равном D2 — D1 выигрывает.
- Активный regulatory deadline. Если один кандидат привязан к дедлайну в следующие 6 месяцев (например, AML data к AMLR 10 Jul 2027), он выигрывает.
- Ссылка на существующий инцидент. Если один кандидат привязан к past incident (SwiftPay 2024), он получает приоритет — это back-tested CDE.
- Готовность владельца. Если у одного кандидата уже identified, engaged Data Owner — проще launch, приоритизируйте.
- Лексический (по
candidate_id). Последний tie-breaker — alphabetical / numeric. Не оптимально, но детерминистично — лучше, чем рандом.
Зафиксируйте правила в CDE policy document до начала первого scoring cycle. Если правила вводятся ad-hoc — каждое решение подвержено спору.
Калибровка через back-testing
Scoring framework, который не back-tested, — это гипотеза. Калибровка — это превращение гипотезы в валидированный инструмент.
Процедура back-testing:
-
Соберите список past incidents за 2-3 года, которые точно были «material per SAB 99» или близко к этому. Для SwiftRide:
- Underpayment по SwiftPay rounding 2024 ($2.3M DACH)
- Вопросы Big 4 по ECL-модели SwiftCapital (T-1Q)
- Разрыв в adoption каталога OpenMetadata (хронический, не инцидент)
- Pricing engine AI Act exposure (ожидаемый, не прошлый)
-
Идентифицируйте датасеты, которые были involved в каждом инциденте.
-
Применить текущий scoring framework к этим датасетам — представьте, что вы scoring их за 3 месяца до инцидента.
-
Проверьте verdict — был бы датасет classified как CDE?
| Past incident | Dataset | Scored как CDE? | Outcome |
|---|---|---|---|
| SwiftPay rounding 2024 | Outputs commission calculation engine | Да (score 4.5+) | Фреймворк поймал |
| Вопросы по SwiftCapital ECL | Inputs loan portfolio (PD, LGD, EAD) | Да (5.0) | Фреймворк поймал |
| Разрыв adoption каталога | Метаданные OpenMetadata сами по себе | Нет (2.0) | False negative — meta-CDE не пойман текущим фреймворком |
В этом back-test фреймворк поймал 2 из 3, пропустил 1 (метаданные каталога сами по себе). Это finding для итерации фреймворка: добавить критерий «является ли dataset governance-foundational?» либо tag-set для категории meta-data.
Частота калибровки: минимум ежегодно. Trigger-based: крупный инцидент, регуляторное изменение, M&A.
Выбор инструмента: spreadsheet vs catalog-integrated
Реальный выбор — где живёт scoring-инструмент:
Плюсы: ноль setup, мгновенная продуктивность, нет vendor lock-in, удобно для маленьких команд (<5 assessors), хорошо для первого цикла.
Минусы: нет audit trail из коробки (можно добавить через Sheets revision history), versioning ручной, нет интеграции с каталогом, нет автоматического триггера re-scoring.
Рекомендация SwiftRide T0: использовать spreadsheet для первого scoring cycle (T+1M). Перенести в catalog-integrated инструмент в T+6M, после того, как фреймворк стабилизировался.
Плюсы: scoring как атрибуты Asset metadata; теги на каждую dimension; вычисляемый weighted score через формулу; bulk re-scoring API; интеграция со Slack / Jira для approvals.
Минусы: vendor lock-in; кривая обучения для GRC-команды; стоимость (enterprise pricing).
Использовать когда: программа зрелая (>50 CDE); несколько бизнес-юнитов scoring параллельно; интеграция с broader data fabric.
Плюсы: first-class объект «Critical Data Element» domain object; workflows для approval; интеграция со stewardship workflows; сильный UX для GRC-команды.
Минусы: более тяжёлое развёртывание; цена; менее developer-friendly, если data-команда — engineering-led.
Использовать когда: программу ведёт GRC-команда; существующее развёртывание Collibra; compliance-heavy индустрия (банки, healthcare).
Плюсы: open-source; SwiftRide уже использует; custom properties feature позволяет добавить scoring fields; API-first.
Минусы: нет встроенной формулы scoring (вычислять снаружи или через custom plugin); workflows менее зрелые, чем у Collibra; UI меняется быстро.
Использовать когда: программу ведёт engineering; предпочтение open-source; уже развёрнут; команда комфортно работает с API + custom dev.
Плюсы: CDE — first-class объект в Unified Catalog (логический контейнер, mapped to physical columns); native Azure integration; policies + DQ rules attached нативно.
Минусы: Azure-tilted (работает лучше всего в M365 / Azure shop); более новый вход на рынок enterprise governance.
Использовать когда: Azure-heavy stack; интеграция M365 governance ценна.
Решение SwiftRide (иллюстративно): Spreadsheet → custom properties OpenMetadata → опциональная миграция Collibra в T+9-12M, если рост программы это оправдывает. Skip Atlan / Microsoft Purview с учётом current stack alignment.
Интерактивный scoring-инструмент — попробуйте
Ниже — рабочий виджет scoring. Поиграйте со scoring и весами для одного из кандидатов SwiftRide:
Поставь оценки по 4 dimensions и подкрути weights. Score обновляется в реальном времени
Предлагаемые эксперименты:
- Driver earnings ledger — попробуйте 5/4/5/4 с весами 30/30/20/20 → ожидайте 4.5 (CDE подтверждён).
- SwiftAds attribution data — попробуйте 2/3/1/2 с теми же весами → ожидайте 2.2 (не CDE).
- Pricing engine outputs — попробуйте 3/5/5/4 с весами 25/35/25/15 (regulatory-leaning) → ожидайте 4.2 (CDE подтверждён).
- Сдвиньте веса к 40/20/20/20 (financial-dominant) на те же scores → посмотрите, как меняется verdict. Это иллюстрирует, что веса имеют значение.
Дерево решений для tie cases
Когда автоматизированное scoring возвращает «borderline» (2.5-3.5 weighted), нужен human review. Дерево решений:
Что делать с кандидатами, попадающими в диапазон weighted score 2.5-3.5
Правило бюджета времени: Borderline review не должен занимать больше 30 минут на case. Если больше — scoring framework нуждается в уточнении (критерии слишком расплывчатые), не case нуждается в большем обсуждении.
Лог калибровки (calibration audit log)
Каждый scoring cycle создаёт calibration audit entry:
calibration_audit:
cycle_id: "swiftride-cde-cycle-2026-q2"
date_run: "2026-05-15"
weights_applied:
financial: 30
regulatory: 30
operational: 20
reputational: 20
framework_version: "v1.2"
candidates_scored: 15
outcomes:
cde_confirmed: 9
borderline_reviewed: 4
not_cde: 2
back_test_incidents_passed: 2/3
framework_improvements_identified:
- "Add criterion 'governance-foundational dataset' to catch meta-CDE (per back-test miss)"
reviewed_by: ["cdo@swiftride", "head-internal-audit@swiftride", "head-data-platform@swiftride"]Эта запись — evidence для аудита впоследствии. Без неё ответ на «как вы делали scoring?» — без traceable basis.
Типичные ошибки scoring
1. Scoring без rationale. Пустая ячейка rationale = score без defensible basis. Обязательное поле. Если assessor не может написать одно предложение rationale — score неверный.
2. Scoring «по интуиции». Assessor чувствует «это CDE» и ставит 5/5/5/5. Это не применение фреймворка — это обход фреймворка.
3. Несогласованный scoring между assessors. Assessor A ставит trip records 4/4/4/4, assessor B — 5/5/5/4. Калибровочная встреча (раз в квартал) — пройти через 5 кандидатов коллективно, выявить drift.
4. Пропуск back-test. Фреймворк развёрнут без back-testing past incidents. Первый крупный инцидент вскрывает gap в фреймворке, что embarrassing на аудите.
5. Инструмент развёрнут до того, как фреймворк стабилизировался. Collibra сконфигурирован с весами, потом веса меняются — Collibra требует переконфигурации, программа тормозит. Стабилизируйте фреймворк в spreadsheet, потом мигрируйте.
6. Нет audit trail. Решения задокументированы только в головах. Когда аудитор спрашивает «почему датасет X classified как not-CDE» — ответа нет. Используйте calibration audit log.
Итоги
- Шаблон scoring sheet — 14 обязательных колонок; production-версия добавляет audit trail, версия весов, ссылки на back-test.
- Правила tie-breaking задокументированы в policy (regulatory wins, затем financial, затем срочность дедлайна, затем история инцидентов, затем готовность владельца, затем лексический). Определите до первого цикла.
- Калибровка через back-testing — прогнать исторические инциденты через фреймворк, выявить gaps. Минимум ежегодно + trigger-based.
- Прогрессия инструментов: Spreadsheet (первый цикл) → catalog-integrated (Collibra / Atlan / OpenMetadata custom / Microsoft Purview), когда программа стабилизировалась. Не разворачивайте инструмент до готовности фреймворка.
- Borderline cases (2.5-3.5 weighted) — структурированная эскалация: past incident? imminent deadline? input owner + compliance? Data Council batch review. Максимум 30 минут на case.
- Calibration audit log — обязательный артефакт на цикл. Evidence для аудитора.
- 6 типичных ошибок: нет rationale, intuition scoring, несогласованный scoring между assessors, нет back-test, tooling-first, нет audit trail.
- Превью лабы: в уроке 7 будете scoring 10 кандидатов SwiftRide с шаблоном из этого урока. Дальше (урок 5) — классификации: CDE vs PII vs Master Data vs Reference Data vs Confidential.