Введение

Семь предыдущих уроков построили методологию + модель данных + дерево решений по тулингу. Эта лаба — первый практический синтез: вы как SwiftRide CDO Office на T+3M, строите реестр для топ-5 CDE (выход лабы M1.7). Каждая запись CDE — YAML со всеми required-полями (M4.5); регуляторный маппинг (M3.10); кросс-ссылки на контроли M5 (forward) + BIA M6 (forward); lineage-ссылки на OpenMetadata + Marquez.

Лаба — doc-centric (обязательно). Выход — 5 YAML-файлов + индекс реестра + матрица кросс-ссылок. Опционально opt-in: Docker-compose OpenMetadata 1.12.x; загрузка через REST API / UI.

Входы

Топ-5 CDE из лабы M1.7

Регуляторная матрица из M3.10

40 ячеек (5 CDE × 8 регуляций) классифицированы. X-ячейки — полная применимость с 4-6 конкретными data requirements на ячейку.

Референс схемы

M4.5 — 17 required-полей + 13 опциональных. См. M4.5 для полного референса.

Шаблон лабы

Создайте директорию labs/m4-cde-registry/:

labs/m4-cde-registry/
├── registry/
│   ├── CDE-SWR-001-revenue_gmv_aggregates.yaml
│   ├── CDE-SWR-002-kyc_profile.yaml
│   ├── CDE-SWR-003-driver_earnings_ledger.yaml
│   ├── CDE-SWR-004-swiftcapital_loan_portfolio.yaml
│   └── CDE-SWR-005-aml_alerts_dispositions.yaml
├── index.md              # Сводка реестра
├── cross-references.md   # Матрица кросс-ссылок
└── self-check.md         # Самооценка

Шаблон YAML на CDE

# CDE-SWR-{NNN} — {name}
cde_id: CDE-SWR-{NNN}
name: {name}
version: "1.0.0"
status: approved
created_at: 2026-08-15T10:30:00Z
last_reviewed_at: 2026-08-15T10:30:00Z
next_review_due: 2026-11-15T00:00:00Z
retire_after: null

business_definition: |
  {2-5 предложений бизнес-смысла}

technical_definition: |
  {схемы / таблицы / колонки / upstream / downstream}

business_owner:
  role: "{role}"
  person: "{person}"
  email: "{email}"

data_steward:
  role: "{role}"
  person: "{person}"
  email: "{email}"

classification:
  - "{например SOX-scope}"
  - "{например GDPR Art. 9}"

criticality_score: {1.00-5.00}
criticality_dimensions:
  financial: {1-5}
  regulatory: {1-5}
  operational: {1-5}
  reputational: {1-5}
weights_used: { financial: 30, regulatory: 30, operational: 20, reputational: 20 }

applicable_regulations:
  - id: "{reg-id}"
    article: "{article}"
    rationale: "{конкретное обоснование}"
    data_requirements:  # из cell-level анализа M3.10
      - "{requirement 1}"
      - "{requirement 2}"

lineage_refs:
  - {OpenLineage URI}
  - {Marquez run ID}
  - {ссылка на dbt model}

control_refs:  # M5 forward; placeholder OK
  - {CTL-... или "proposed"}

bia_refs:  # M6 forward; placeholder OK
  - {BIA-... или "proposed"}

escalation_threshold:
  financial: "{например $X misstatement / period}"
  accuracy: "{например X% дельта}"

quality_tolerance:
  null_rate: "{например ≤ 0.01%}"
  reconciliation_delta: "{например ≤ 0.05%}"
  pipeline_freshness: "{например ≤ 6h SLA}"

retention:
  policy: "{например 7y immutable SOX-grade}"

tags:
  - {tag1}
  - {tag2}

change_history:
  - version: "1.0.0"
    date: 2026-08-15T10:30:00Z
    change: "Первичное создание по лабе M4"
    approvers: ["CDO", "Data Council"]

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

Шаг 1 — На CDE: собрать входы

Для каждой из 5 CDE открыть референс:

• Лаба M1.7 — скор критичности + обоснование на dimension.
• Cell-level анализ регуляторной матрицы M3.10 — 4-6 data requirements на X-ячейку.
• Running case SwiftRide M0.4 — бизнес-контекст + ownership БЕ.
• Risk-фреймворки M2 — Three Lines подотчётность на роль.
• M3.1-M3.9 — конкретные регуляторные цитаты на применимую регуляцию.

Шаг 2 — На CDE: написать бизнес- + технические определения

Примеры:

CDE-SWR-001 (revenue_gmv_aggregates) business_definition:

Ежедневные и ежемесячные агрегаты выручки + GMV по БЕ (Rides / Delivery / SwiftPay / SwiftCapital / SwiftAds) и стране. Прямой фид для строки Net Revenue Income Statement S-1 / 10-K + раскрытия GMV. Основной якорь для отчётности инвесторам + квартальной аттестации SOX 302 CEO/CFO. Удовлетворение performance obligation ASC 606 / IFRS 15 отслеживается на выполненную поездку / транзакцию.

technical_definition:

Каноническая fact-таблица: snowflake.dl_marts.fct_revenue_daily (грануляция per-day) + snowflake.dl_marts.fct_revenue_monthly (ежемесячный агрегат).
Ключевые колонки: business_unit_id, country_code, revenue_date, net_revenue_usd, gmv_usd, take_rate_pct, trip_count, transaction_count.
Upstream: trip records (fct_trip_records) + delivery records (fct_delivery_records) + SwiftPay txn (fct_swiftpay_txn) + SwiftCapital interest (fct_swiftcapital_interest) + SwiftAds revenue (fct_swiftads_attribution).
Downstream: дашборды Looker (Revenue Dashboard, Investor Dashboard), источники данных колоды для борды, генератор 10-K / S-1, интеграция Workiva (планируется).

Шаг 3 — На CDE: назначить ownership

По RACI M4.4 + выходу интервью:

Используйте нейтральные имена (Anna, Carlos, Priya, Yuki, …) по конвенции RUNNING_CASE.md.

Шаг 4 — На CDE: применимые регуляции (M3.10 cell-level)

По M3.10 X-ячейки извлечь 4-6 data requirements. Примеры:

CDE-SWR-003 (driver_earnings) × SOX 404:

applicable_regulations:
  - id: "SOX-404"
    article: "Section 404(a) (немедленно post-IPO) → 404(b) (accelerated filer)"
    rationale: "Прямой фид P&L Driver Earnings & Incentives + revenue offset. Искажение >$10M вызывает material weakness. Прецедент SwiftPay 2024 ($2.3M недоплачено водителям в регионе DACH ошибка округления)."
    data_requirements:
      - "Field-level lineage trip → earnings → payout"
      - "7-летнее retention неизменяемых доказательств"
      - "Независимый контроль сверки (M5)"
      - "Квартальная аттестация Business Owner (M7)"
      - "Трасса доказательств сверки в IPE testing (AS 1105 ¶.10)"
      - "Отслеживание дефицитов AS 1305"

Продолжить на регуляцию на CDE. Ссылаться на интерактивную матрицу M3.10.

Шаг 5 — На CDE: ссылки на lineage

По M4.2 — URI OpenLineage + Marquez run ID + SHA dbt model.

Примеры (шаблонные ссылки; не фактические production-endpoints):

lineage_refs:
  - "openlineage:dataset://snowflake/dl_marts/driver_earnings_v3"
  - "marquez:lineage/run/4a92...e9f0"
  - "dbt:model.swiftride.driver_earnings_v3"
  - "openmetadata:table/snowflake.dl_marts.driver_earnings_v3"

Задокументировать, какие ссылки фактически полные (текущий SwiftRide T+3M); которые placeholder (пробел lineage в ожидании инструментации T+6M).

Шаг 6 — На CDE: control refs + BIA refs (forward placeholders)

M5 и M6 ещё не построены; placeholders приемлемы:

control_refs:
  - status: "proposed"
    intent: "Контроль сверки trip → earnings → payout (дизайн M5 T+6M)"
  - status: "proposed"
    intent: "Автоматизированная политика retention GDPR (M5 + M7 T+6M)"

bia_refs:
  - status: "proposed"
    intent: "BIA зависимости payout SwiftPay (M6 T+9M)"

Задокументировать forward-зависимости; аудитор / Big 4 reviewer ожидает placeholders с intent, не пустые массивы.

Шаг 7 — На CDE: escalation + quality + retention

Примеры — применить фреймворк материальности M1.2:

escalation_threshold:
  financial: "$2M misstatement / период (≈ 1% порог материальности M1.2)"
  accuracy: "0.05% дельта сверки (обоснование M1.7)"

quality_tolerance:
  null_rate: "≤ 0.01% (любое required-поле)"
  reconciliation_delta: "≤ 0.05% trip-to-earnings"
  pipeline_freshness: "≤ 6h SLA"

retention:
  policy: "7y immutable (SOX-grade; PCAOB AS 1105 retention)"
  storage: "S3 с object lock; доступ через Snowflake external table"

Шаг 8 — Индекс + матрица кросс-ссылок

index.md:

# Реестр CDE SwiftRide — baseline T+3M

5 CDE опубликовано v1.0.0 каждый. Статус: approved. Следующее ревью: T+6M.

| ID | Name | Owner | Score | Status |
|---|---|---|---|---|
| CDE-SWR-001 | revenue_gmv_aggregates | CFO Office | 5.00 | approved |
| ...

## Методология
{Hybrid top-down + bottom-up по M4.1-M4.3}

## Approval workflow
{State machine по M4.5}

cross-references.md:

# Кросс-ссылки — CDE × контроли × BIA × регуляции

## На регуляцию
| Регуляция | Кандидаты CDE | Источник урок M3 |
|---|---|---|
| SOX 404 | CDE-SWR-001, CDE-SWR-003, CDE-SWR-004 | M3.1 |
| GDPR Art. 9 | CDE-SWR-002 | M3.5 |
| ...

## На предстоящий модуль
- M5 (контроли T+6M): запланировано 24 контроля по control_refs реестра
- M6 (BIA T+9M): запланировано 5 записей BIA по bia_refs реестра
- M7 (доказательства T+9M): квартальные циклы аттестации

Шаг 9 — Self-check assessment

Прогнать критерии self-check (следующая секция). Задокументировать пробелы + план ремедиации.

Opt-in тулинг-лаба — Docker-compose OpenMetadata 1.12.x

Для мотивированных студентов. Пропустить, если doc-centric выхода достаточно.

mkdir -p ~/swiftride-cde-lab
cd ~/swiftride-cde-lab
curl -O https://raw.githubusercontent.com/open-metadata/OpenMetadata/main/docker/development/docker-compose.yml
docker-compose up -d

import yaml
from metadata.ingestion.ometa.ometa_api import OpenMetadata
from metadata.generated.schema.entity.services.connections.metadata.openMetadataConnection import (
    OpenMetadataConnection,
    AuthProvider,
)
from metadata.generated.schema.security.client.openMetadataJWTClientConfig import (
    OpenMetadataJWTClientConfig,
)

server_config = OpenMetadataConnection(
    hostPort="http://localhost:8585/api",
    authProvider=AuthProvider.openmetadata,
    securityConfig=OpenMetadataJWTClientConfig(jwtToken="<your-bot-token>"),
)
ometa = OpenMetadata(server_config)

# Загрузить YAML CDE
with open("registry/CDE-SWR-001-revenue_gmv_aggregates.yaml") as f:
    cde_data = yaml.safe_load(f)

# Найти ассоциированную сущность Table (предполагая pre-ingested OpenMetadata table)
table = ometa.get_by_name(
    entity=Table,
    fqn="snowflake.dl_marts.fct_revenue_daily"
)

# Применить custom properties CDE на Table
ometa.patch_extension(
    entity=Table,
    entity_id=table.id,
    extension_data={
        "cde_id": cde_data["cde_id"],
        "criticality_score": cde_data["criticality_score"],
        "business_owner_role": cde_data["business_owner"]["role"],
        "business_owner_person": cde_data["business_owner"]["person"],
        "classification": ", ".join(cde_data["classification"]),
        "applicable_regulations": ", ".join(
            r["id"] for r in cde_data["applicable_regulations"]
        ),
        "registry_status": cde_data["status"],
        "registry_version": cde_data["version"],
    }
)
print(f"Uploaded {cde_data['cde_id']} → {table.fullyQualifiedName}")

from metadata.generated.schema.entity.classification.classification import Classification
from metadata.generated.schema.entity.classification.tag import Tag

# Создать classification "CDE", если не существует
cde_classification = Classification(name="CDE", description="Critical Data Elements")
# Создать тег "CDE-SWR-001" под этой classification
cde_tag = Tag(name="CDE-SWR-001", description="revenue_gmv_aggregates", classification="CDE")
# Применить к таблице
ometa.apply_tags(entity=Table, fqn=table.fullyQualifiedName, tags=[cde_tag])

docker-compose down -v  # удаляет контейнеры + volumes

Критерии self-check

Полнота

• 5 YAML-файлов созданы (CDE-SWR-001 до CDE-SWR-005).
• Все 17 required-полей заполнены на CDE.
• Бизнес- + технические определения ≥ 2 предложений каждое, конкретные (без общих фраз).
• Business Owner + Data Steward названы (нейтральные имена по running case).
• Classification включает все применимые регуляторные dimensions (SOX-scope, GDPR Art. 9, PCI-scope, AI Act Annex III и т.д.).
• Скор критичности совпадает с выходом лабы M1.7.
• Applicable regulations включают 4+ на CDE (мульти-регулятор); каждая с rationale + data_requirements (из M3.10).
• Lineage refs включают URI OpenLineage / Marquez / dbt / ссылки на каталог (placeholder OK для пробелов инструментации).
• Control refs + BIA refs включают proposed / forward placeholders с intent.
• Escalation threshold количественный (USD или %).
• Quality tolerance количественный (null rate, дельта сверки, SLA свежести).
• Политика retention указана (7y SOX-grade или per-регуляции).
• Change history включает первичный v1.0.0 с approvers.

Защитимость

• Можете ли вы провести Big 4 reviewer через каждую запись реестра CDE без пробела?
• Можете ли вы защитить скор критичности?
• Можете ли вы объяснить регуляторную применимость на ячейку?
• Можете ли вы описать обоснование ownership?
• Можете ли вы объяснить план forward placeholders (M5 / M6)?

Целостность кросс-ссылок

• На CDE, applicable_regulations совпадает с матрицей M3.10.
• На CDE, controls_refs forward к будущим задачам M5 задокументированы.
• На CDE, bia_refs forward к будущим задачам M6 задокументированы.
• Index.md суммирует всё; матрица cross-references.md согласована.

Методология

• Методология обнаружения (M4.1) задокументирована (hybrid / top-down + bottom-up).
• RACI на CDE по M4.4.
• State по state machine M4.5 (proposed → approved).
• Каденс обновления по M4.7 задокументирован (Q1 ежегодное + change-триггеры).

Шаблон submission

# Лаба M4 — mini-CDE Registry SwiftRide

**Студент:** [ваше имя]
**Дата:** [дата]
**Метод:** Doc-centric (обязательно) + opt-in тулинг OpenMetadata [yes/no]
**Использованные инструменты:** [YAML-редактор / OpenMetadata 1.12.6 и т.д.]

## Сводка реестра

5 CDE опубликовано v1.0.0 каждый. Методология: hybrid (top-down + bottom-up по M4.1-M4.3).

| ID | Name | Owner | Score | Status |
|---|---|---|---|---|
| CDE-SWR-001 | revenue_gmv_aggregates | [владелец] | 5.00 | approved |
| CDE-SWR-002 | kyc_profile | [владелец] | 4.80 | approved |
| CDE-SWR-003 | driver_earnings_ledger | [владелец] | 4.50 | approved |
| CDE-SWR-004 | swiftcapital_loan_portfolio | [владелец] | 4.50 | approved |
| CDE-SWR-005 | aml_alerts_dispositions | [владелец] | 4.40 | approved |

## Вердикт self-check

- Полнота: [pass / partial / gaps]
- Защитимость: [pass / partial / gaps]
- Целостность кросс-ссылок: [pass / partial / gaps]
- Методология: [pass / partial / gaps]

## Пробелы + план ремедиации

| Пробел | Ремедиация | Владелец | Цель |
|---|---|---|---|
| [пример] Placeholder lineage для SwiftAds attribution | Инструментация OpenLineage | Data Engineering | T+6M |
| ... | ... | ... | ... |

## Forward-зависимости

- Контроли M5: запланировано 24 контроля по control_refs реестра (T+6M)
- BIA M6: запланировано 5 записей BIA по bia_refs реестра (T+9M)
- Доказательства M7: квартальный цикл аттестации (T+9M)

## Извлечённые уроки

[Рефлексии]

Типовые ошибки

Общее business_definition

Симптом: «Trip records — критичные данные о поездках»; «KYC profile — KYC-данные».

Почему плохо: не защитимо; аудитор не может валидировать ownership / скоуп / регуляторную применимость из общих фраз.

Исправление: конкретные 2-5 предложений — что содержит, кто потребляет, какие решения управляет, регуляторные импликации.

Пустые applicable_regulations

Симптом: массив содержит 1-2 регуляции; пропускает мульти-регуляторные dimensions.

Почему плохо: пропускает скоуп; аудитор находит пробел, когда видно пересечение (KYC имеет AML + GDPR + PCI + биометрию AI Act — минимум 4 регуляции).

Исправление: ссылаться на матрицу M3.10; типично минимум 3-4 регуляции на CDE в контексте SwiftRide.

Отсутствуют data_requirements на регуляцию

Симптом: applicable_regulations перечисляет регуляцию, но не специфицирует data_requirements на ячейку.

Почему плохо: без специфики контроли M5 не могут быть выведены — циклически «нам нужны контроли, потому что регуляция» без того, что контроли делают.

Исправление: скопировать 4-6 конкретных data_requirements из cell-level анализа M3.10 на X-ячейку.

Общий placeholder controls_refs

Симптом: controls_refs: ["TBD"] без forward intent.

Почему плохо: будущий автор M5 не знает, какой контроль нужен на каждый CDE.

Исправление: placeholder с intent: proposed: "Контроль сверки trip → earnings → payout (дизайн M5 T+6M)".

Пропуск детализации criticality_dimensions

Симптом: criticality_score: 4.50 без разбивки dimensions.

Почему плохо: нельзя защитить скор; нельзя проследить выход лабы M1.7; нельзя проследить tie-break логику по M1.4.

Исправление: массив dimensions + использованные веса + weighted_calc явно.

Lineage refs как «N/A»

Симптом: lineage_refs пуст; «у нас ещё нет OpenLineage инструментированного».

Почему плохо: молчаливый пробел (антипаттерн M4.2).

Исправление: явный placeholder + план инструментации: lineage_refs: [] + комментарий “OpenLineage instrumentation pending T+6M; placeholder; tracking ticket DATAOPS-1234”.

Один владелец на БЕ, не на CDE

Симптом: все CDE-SWR-XXX имеют business_owner: “CFO”.

Почему плохо: CFO не может быть Accountable на CDE по RACI (один Accountable на роль на CDE по M4.4). Практический владелец — делегированный Domain Lead.

Исправление: роль Business Owner на CDE по M4.4 — KYC = DPO + Compliance Lead; Driver Earnings = Finance Data Office; SwiftCapital = SwiftCapital Risk Officer.

Забыли про retention

Симптом: поле retention отсутствует.

Почему плохо: SOX-grade evidence требует 7-летнего retention; SwiftRide SOX-готовность заблокирована, если retention не задокументирован.

Исправление: политика retention указана на требование регуляции (7y SOX; 5-7y AMLR; по юрисдикциям GDPR).

Устаревшие даты ревью

Симптом: last_reviewed_at = next_review_due = одна и та же дата.

Почему плохо: next_review_due должен быть в будущем (обычно +3M по квартальному каденсу M4.7).

Исправление: next_review_due = created_at + квартальный цикл = обычно +3M.

Версионирование пропущено

Симптом: version: “1” или пусто.

Почему плохо: будущий change_history не может версионировать; аудитор «когда изменилось business definition» — ответ только «не знаем».

Исправление: semver “1.0.0” первичный; bump на изменение.

Связь с M5 + M6 + M7

Выход этой лабы → M5 (дизайн контролей) — каждый forward placeholder control_refs реестра становится задачей дизайна контроля M5. Лаба M5 строит контроли для топ-3 CDE.

Выход этой лабы → M6 (BIA / BCP) — каждый forward placeholder bia_refs реестра становится записью BIA M6. Лаба M6 строит BIA для SwiftPay wallet (пересекается с CDE-SWR-003 driver_earnings + CDE-SWR-005 aml_alerts).

Выход этой лабы → M7 (доказательства + аттестация) — каждый attestation_history реестра заполняется через квартальные циклы. M7 строит evidence pipelines, питающие записи реестра.

Реестр — центральный артефакт, связывающий M4 → M5 → M6 → M7. Без baseline реестра downstream-модули не могут привязать контроли / BIA / доказательства к конкретным записям CDE.

Итоги

Выход лабы (цель):

1. 5 YAML-файлов — CDE-SWR-001 до CDE-SWR-005 — полная схема по M4.5.
2. Index.md — сводка реестра, методология, approval workflow по M4.5.
3. Cross-references.md — матрица CDE × регуляции; forward к M5 / M6 / M7.
4. Self-check.md — полнота + защитимость + кросс-ссылки + методология pass/partial/gap.
5. Шаблон submission — имя студента, дата, инструменты, пробелы + ремедиация, уроки.
6. Opt-in развёртывание OpenMetadata 1.12.6 — Docker-compose + загрузка REST API + верификация UI (опционально).

Типовые ошибки — общие определения; пустые applicable_regulations; отсутствие data_requirements; общие placeholders; пропуск criticality_dimensions; lineage refs как N/A; один владелец на БЕ; забыли retention; устаревшие даты ревью; версионирование пропущено. Избегать через кросс-ссылку на M1.7 + M3.10 + M4.5 + RACI M4.4 явно на CDE.

Реестр — центральный артефакт M4. Forward к M5 (контроли), M6 (BIA), M7 (доказательства). Без baseline downstream-модули не могут привязаться.

Следующий модуль (M5): Controls Design — таксономия контролей (preventive / detective / corrective), матрица контролей на CDE, SoD, паттерны dbt + GE, дизайн доказательств audit-grade. M5 строит контроли для топ-3 CDE из этой лабы.