Введение

Шесть предыдущих уроков построили фреймворк. Эта лаба — первое практическое применение: вы как CDO SwiftRide в T+1M, scoring 10 кандидатов из портфеля для первого Data Council meeting в T+2M. Результат — short-list топ-5 CDE, который используется в M4 для построения реестра.

Лаба — doc-centric (обязательная). Output — заполненная markdown-таблица или spreadsheet. Опционально (opt-in): импорт результатов в Atlan или custom properties OpenMetadata (sketched в конце).

Inputs

Портфель из 10 кандидатов (подмножество из M0.4)

Используем 10 датасетов для сфокусированного периметра (полные 15 — в M4):

Параметры фреймворка

• Веса: SwiftRide T0 рабочие — financial 30%, regulatory 30%, operational 20%, reputational 20%.
• Шкала scoring: 1-5 на dimension (см. M1.3 для anchor descriptions).
• Thresholds: ≥3.5 = CDE подтверждён; 2.5-3.5 = borderline; <2.5 = не CDE.
• Порядок tie-breaking (по M1.4): regulatory wins, затем financial, затем срочность дедлайна, затем история инцидентов, затем готовность владельца, затем лексический.
• Materiality reference: group-level $20-25M; threshold CDE-программы$10M; SwiftCapital отдельно $1-2M; AML / sanctions / unlawful — автоматически material независимо от величины.

Шаблон лабы

Заполните таблицу (рекомендуется сохранить в labs/m1-cde-scoring/results.md, если у вас есть локальный workspace для курса):

| # | Кандидат | D1 Fin | D1 Rationale | D2 Reg | D2 Rationale | D3 Op | D3 Rationale | D4 Rep | D4 Rationale | Weighted | Verdict |
|---|-----------|--------|--------------|--------|--------------|-------|--------------|--------|--------------|----------|---------|
| 1 | trip_records | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| 2 | driver_earnings_ledger | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |

Rationale на ячейку — 1-2 предложения. Обязательное поле; пустой rationale = scoring неприменим к submission.

Шаги выполнения

Шаг 1: По кандидату — прочитать контекст

Для каждого из 10 кандидатов перечитайте релевантный контекст:

• Сквозной кейс (M0.4) — что делает SwiftRide, какие бизнес-юниты затронуты этим датасетом
• Regulatory landscape (M0.4 + M1.3) — какие регуляции применимы
• Materiality framework (M1.2) — какие SAB 99 qualitative factors триггерятся
• Failure scenarios — SwiftPay 2024 rounding (для driver earnings), вопросы Big 4 по SwiftCapital ECL (для loan portfolio), pricing engine AI Act exposure

Шаг 2: Score 4 dimensions на кандидата

Используйте интерактивный виджет для быстрых экспериментов + захвата в шаблон:

Правило продуктивного scoring: не фиксируйтесь на одном ответе. Если между 3 и 4 — выбирайте осознанно (например, 4 если regulatory leaning, 3 если internal-leaning). Документируйте rationale.

Шаг 3: Напишите rationale на ячейку

Примеры хорошего rationale:

• D1=5: «Прямой фид в revenue recognition; потенциал ошибки за один день >$15M на consolidated, превышает$10M threshold CDE»
• D2=4: «Subject to AMLR + GDPR Art. 30 + PCI-DSS; multi-regulator, штрафы >$50M при breach»
• D3=2: «Annual onboarding cycle; driver может работать, если training не renewed; нет real-time зависимости»
• D4=5: «Front-page риск: AML failure в US или EU — вероятность приостановки лицензии + media coverage»

Примеры плохого rationale (избегать):

• «Это critical» (нет конкретики)
• «Important for compliance» (какая регуляция, какой штраф?)
• «5/5 obvious» (нет defensible basis на audit позже)

Шаг 4: Вычислить weighted score на кандидата

Формула:

weighted = (D1 × 0.30) + (D2 × 0.30) + (D3 × 0.20) + (D4 × 0.20)

Округлить до 2 десятичных.

Шаг 5: Verdict на кандидата

• weighted ≥ 3.5 → CDE подтверждён
• 2.5 ≤ weighted < 3.5 → Borderline (эскалация по дереву M1.4)
• weighted < 2.5 → Не CDE

Шаг 6: Применить tie-breakers, если нужно

Отсортируйте всех CDE-подтверждённых кандидатов по weighted score по убыванию. Определите топ-5. Если ties (например, два кандидата на 4.5), применить порядок tie-breaker из M1.4:

1. Regulatory dimension (D2) выше выигрывает
2. Если равный D2 — financial (D1) выше выигрывает
3. Если всё ещё tied — imminent regulatory deadline выигрывает
4. Ссылка на past incident выигрывает
5. Готовность владельца выигрывает
6. Лексический (candidate ID) — last resort

Шаг 7: Подготовить финальные outputs

• Полная scored таблица (10 строк, 4 dimensions scored, rationale зафиксирован)
• Топ-5 CDE short-list с weighted scores
• Список borderline с предлагаемым обоснованием эскалации (past incident? deadline?)
• Список Not-CDE с кратким обоснованием

Критерии self-check

Pass criteria для этой лабы:

• Все 10 кандидатов scoring по всем 4 dimensions
• Каждая ячейка имеет rationale (1-2 предложения, конкретное)
• Weighted score вычислен правильно по формуле
• Топ-5 определён, с применённым tie-breaking, если нужно
• Минимум один borderline case определён (правильное применение фреймворка обычно даёт 1-2 borderline cases из 10)
• Verdict соответствует threshold правилам

Sanity checks для вашего scoring

Sanity check 1: Были ли какие-то из этих scoring как CDE? Если да — пересмотреть.

• compliance_training_records (вероятно score около 2.5, не CDE на T0)
• swiftads_attribution_data (вероятно score около 2-2.5, borderline / не CDE)

Sanity check 2: Были ли какие-то из этих scoring как not-CDE? Если да — пересмотреть.

• driver_earnings_ledger (должен быть 4.5+, CDE подтверждён)
• kyc_profile (должен быть 4.5+, CDE подтверждён; multi-regulator + Art. 9)
• swiftcapital_loan_portfolio (должен быть 4.5+, CDE подтверждён; IFRS 9 ECL напрямую)
• aml_alerts_dispositions (должен быть 4.5+, CDE подтверждён; AMLR + FATF напрямую)
• revenue_gmv_aggregates (должен быть 5.0, CDE подтверждён; SOX 302/404 напрямую)

Sanity check 3: Получил ли card_data_tokens scoring как CDE? Tricky — PCI scope технически охватывает системы, держащие CHD (Card Holder Data). Сами токены — не CHD по PCI-DSS Glossary, если правильно tokenized (truly random tokens, не encryption). Решение: CDE, потому что они фидят payment processing flow и представляют отношение CHD, даже если сами токены вне CHD-scope. Этот нюанс — именно того рода, что Data Council должен обсудить.

Ожидаемый результат — топ-5 CDE для SwiftRide T+1M

Следуя фреймворку строго, топ-5 вероятно (ваши числа могут немного отличаться):

Borderline:

• swiftads_attribution_data (около 2.2-2.5) — вероятно defer; пересмотреть, если SwiftAds становится reportable segment
• compliance_training_records (около 2.3-2.5) — borderline; safety angle может эскалировать

Не CDE:

• (обычно ни один из этих 10 явно не попадает в not-CDE на T+1M — все кандидаты были pre-filtered в портфеле)

Замечание: Топ-5 list — не ваш финальный inventory CDE SwiftRide. M4 расширяет до 24 CDE для T+3M target. Лаба здесь — first-pass scoring для наиболее критичного подмножества.

Типичные ошибки — избегать

1. Scoring без rationale. Самая частая ошибка. Пустая ячейка rationale — scoring не defensible на audit позже. Потратьте лишние 30 секунд на ячейку, чтобы написать обоснование из 1 предложения.

2. Путаница «important» с «material». Каждый dataset кажется важным. Material = material по SAB 99 — quantitative + qualitative. Перечитайте M1.2, если scoring дрейфует к all-5s.

3. Забывание регуляторных multipliers. Multi-regulator data (KYC = AML + GDPR + PCI) должны score D2=5, не 4. Каждая регуляция добавляет независимый риск; aggregate — мультипликативный.

4. Путаница operational vs financial. Tier-1 operational (RTO <4ч) — D3=5, но не автоматически D1=5. Trip matching критичен operationally, но не напрямую material financially (revenue impact аккумулируется через fare records, не через matching decisions).

5. Игнорирование reputational dimension. Легче всего забыть, потому что сложнее всего квантифицировать. Используйте прокси: % затронутых пользователей, диапазон регуляторного штрафа, оценка recovery cost.

6. Несоответствие scoring между похожими datasets. trip_records и revenue_gmv_aggregates оба фидят revenue — должны scoring похоже по D1. Если scores расходятся, проверьте rationale.

7. Пропуск back-test. Получил ли dataset инцидента SwiftPay 2024 (driver_earnings_ledger) scoring CDE через ваш framework? Если нет — проблема калибровки framework.

8. Не зафиксирован borderline rationale. «Borderline» без rationale эскалации = застрял. По M1.4: past incident? imminent deadline? input owner + compliance?

Opt-in: импорт результатов в Atlan / OpenMetadata

Полная hands-on tooling-лаба — в M4 (CDE Inventory). Sketch здесь для motivated students:

from pyatlan.client.atlan import AtlanClient
client = AtlanClient(api_key="...", base_url="https://...")

asset = CdeCandidate.creator(
    name="driver_earnings_ledger",
    qualified_name="default/cde-candidate/driver_earnings_ledger",
)
asset.attributes.d1_financial_score = 5
asset.attributes.d1_rationale = "Direct feed revenue recognition; SwiftPay 2024 precedent"
asset.attributes.weighted_score = 4.5
asset.attributes.verdict = "CDE confirmed"
client.asset.save(asset)

from metadata.ingestion.ometa.ometa_api import OpenMetadata
ometa = OpenMetadata(config=...)
table = ometa.get_by_name(entity=Table, fqn="snowflake.swiftpay.dl_marts.driver_earnings_v3")
ometa.patch_extension(entity=Table, entity_id=table.id, extension_data={
    "cde_d1_financial": 5,
    "cde_weighted_score": 4.5,
    "cde_verdict": "CDE confirmed",
})

Tooling-лаба — opt-in; обязательная часть — doc-centric шаблон + scoring + short-list. M4 покрывает полный build реестра с интеграцией tooling.

Шаблон submission (для self-tracking)

# M1 Лаба — SwiftRide CDE scoring

**Студент:** [ваше имя]
**Дата:** [дата]
**Применённые веса:** Financial 30 / Regulatory 30 / Operational 20 / Reputational 20
**Версия framework:** v1.0 (M1.3-M1.4 baseline)

## Scored таблица

(вставьте сюда заполненную таблицу на 10 строк)

## Топ-5 CDE short-list

1. ...
2. ...
3. ...
4. ...
5. ...

## Borderline cases с обоснованием эскалации

- кандидат X: обоснование эскалации
- кандидат Y: обоснование эскалации

## Не-CDE с обоснованием

- кандидат Z: rationale (обычно: re-evaluate через N месяцев trigger)

## Замечание по back-test

Поймал ли framework dataset инцидента SwiftPay 2024 (driver_earnings_ledger)? [Да / Нет, и обоснование]

## Запись calibration audit log

```yaml
cycle_id: "m1-lab-cycle-1"
date_run: [дата]
weights_applied:
  financial: 30
  regulatory: 30
  operational: 20
  reputational: 20
framework_version: "v1.0"
candidates_scored: 10
outcomes:
  cde_confirmed: 5-7
  borderline_reviewed: 1-3
  not_cde: 0-2
```

Итоги

• 10 кандидатов scoring через framework из M1.3-1.4. Шаблон — 14 минимальных колонок (на кандидата: ID, name, D1-D4 scores + rationales, weighted, verdict).
• Шаги: прочитать контекст → score 4 dims → написать rationale → вычислить weighted → verdict → tie-break при необходимости → подготовить outputs.
• Критерии self-check — все 10 scoring, rationale на ячейку, применены threshold правила, tie-breakers задокументированы, 1-2 borderline cases определены.
• Sanity checks — known-CDE (driver earnings, KYC, ECL, AML, revenue aggregates) все должны быть CDE подтверждены; known-not-CDE (compliance training, SwiftAds attribution) должны быть borderline / not-CDE.
• Ожидаемый результат топ-5 для SwiftRide T+1M: revenue_gmv_aggregates, kyc_profile, driver_earnings_ledger, swiftcapital_loan_portfolio, aml_alerts_dispositions.
• 8 типичных ошибок избегать: нет rationale, important≠material, недооценка regulatory, путаница op-fin, пренебрежение reputational, несоответствие между datasets, нет back-test, нет rationale эскалации.
• Opt-in tooling sketch: Atlan / OpenMetadata bulk import. Полная tooling-лаба — в M4.
• Следующий модуль (M2): Risk frameworks — COSO ERM, ISO 31000, Three Lines Model, IIA Standards 2024. Основания для M3 regulatory deep-dive.