Введение

T+3M в SwiftRide. Выявление валидировано; ~42 кандидата протриажены через скоринг критичности (M1.4) → финальный список 24 CDE для целевого T+3M. CDO Office готов опубликовать реестр. Председатель audit committee задаёт: «Покажите реестр. В каком формате? Где хранится? Как мы знаем, что каждая запись была одобрена? Когда её последний раз ревьюили?»

Без модели данных реестр — это spreadsheet. Spreadsheet приемлем для маленькой команды T0, но не масштабируется + не аудит-защитим долгосрочно. ECB RDARR Guide прямо требует RDARR Guide (a-d) — все 4 элемента должны быть структурированы + версионированы + аудируемы.

Этот урок — фиксация модели данных + approval workflow. Выход — схема, применимая в OpenMetadata / Collibra / Atlan / Purview / DataHub. Лаба M4.8 — студент заполняет схему для 5 CDE SwiftRide.

Обязательные поля на запись CDE

Минимальный набор полей. Если реестр публикуется без них — не аудит-защитим.

Опциональные поля (рекомендуемые)

Стратегия версионирования

Вариант A — semver (рекомендуемый)

MAJOR.MINOR.PATCH:

• MAJOR — изменение бизнес-определения, владельца, классификации, периметра (breaking).
• MINOR — изменение технической lineage, контролей (additive).
• PATCH — корректировки (опечатка, обновление ссылки).

Пример таймлайна для CDE-SWR-001 driver_earnings_ledger:

• v1.0.0 — первичное одобрение T+3M.
• v1.0.1 — починка опечатки в business_definition T+3M.
• v1.1.0 — добавлены control refs (поставка M5) T+6M.
• v2.0.0 — смена бизнес-владельца CFO Office → Finance Data Office T+9M; ретроспектива SwiftPay 2024 добавлена в incident_history.

Вариант B — incremental

v1, v2, v3. Проще, менее информативно. Приемлемо для маленьких реестров; рекомендуется semver для программ >50 CDE.

Критично — неизменяемая история

Каждая версия сохранена. Реестр — append-only event log; текущее состояние — проекция. Аудиту нужно «как выглядел реестр в Q3 2026» — ответ всегда доступен.

State machine approval workflow

Состояния и переходы:

[start] --nominate--> proposed
proposed --start review--> under_review
under_review --approve--> approved
under_review --reject--> proposed (с правками)
under_review --kill--> killed
approved --enter operation--> maintained
maintained --request change--> under_review
maintained --schedule retire--> retiring
retiring --retire--> retired
killed --end (журнал аудита сохранён)
retired --end (журнал аудита сохранён)

Определения состояний

proposed: первичная номинация (выход валидации со стейкхолдерами M4.4). Черновик владельца; ещё не ревьюнуто.

under_review: Data Council ИЛИ подкомитет (триада технический + бизнес + compliance + аудит) ревьюит. Статус может быть under_review.technical, under_review.business, under_review.compliance, under_review.audit в более продвинутом workflow.

approved: одобрение Data Council. CDE вступил в операцию, но контроли возможно ещё не построены (forward к M5). Программа коммитится построить контроли.

maintained: контроли построены и DQ запускается операционно. Квартальная аттестация активна.

retiring: запланирован для retirement; датасет deprecated. Период для миграции downstream-потребителей. Обычно 90-180 дней.

retired: датасет декомиссионирован; запись CDE сохранена для исторической / аудит-ссылки; больше нет активных контролей.

killed: отклонён без принятой номинации (например, обнаружена некорректная классификация во время ревью). Сохранён для журнала аудита.

Требуемые одобряющие на переход

State machine — практически

T+3M реестр CDE SwiftRide — 24 записи в статусе approved. Контроли для 60% — ещё proposed (forward к M5 build). Контроли для топ-5 (приоритеты M1.7) — maintained, чтобы заземлить программу в Y+1.

Пример YAML-схемы — полный

# CDE-SWR-001 — driver_earnings_ledger
cde_id: CDE-SWR-001
name: driver_earnings_ledger
version: "1.1.0"
status: maintained
created_at: 2026-08-15T10:30:00Z
last_reviewed_at: 2026-11-15T14:00:00Z
next_review_due: 2027-02-15T00:00:00Z
retire_after: null

business_definition: |
  Канонический ledger per-driver per-period заработка — gross fare share, комиссия,
  налоговое удержание (по стране), incentive-выплаты, сумма payout. Единый источник
  правды для компенсации водителя. Прямой фид для строки P&L Driver Earnings & Incentives
  + сдачи в налоговые органы + 1099 generation (водители США) + labour-inspectorate
  отчётность (ЕС по странам).
  
  Отражает все выполненные поездки в периоде, включая completed-cancelled-disputed
  поездки, сверенные согласно применимым Terms of Service.

technical_definition: |
  Таблица-источник правды: `snowflake.dl_marts.driver_earnings_v3`
  Таблица сверки: `snowflake.dl_marts.driver_earnings_reconciliation`
  Companion налогового удержания: `snowflake.tax.withhold_per_period`
  
  Ключевые колонки:
  - `driver_id` (FK к driver service)
  - `period_start_date`, `period_end_date`
  - `gross_earnings_usd`
  - `commission_amount_usd`
  - `commission_rate`
  - `tax_withhold_amount_usd`
  - `incentive_amount_usd`
  - `payout_amount_usd`
  
  Upstream: dispatch service → kafka:trips.completed → fct_trip_records →
            billing service → fct_billing_aggregate → driver-earnings service.
  Downstream: SwiftPay payout pipeline, P&L revenue+expense, tax 1099, аттестация.

business_owner:
  role: "Finance Data Office (CFO direct report)"
  person: "Anna Müller"
  email: "[email protected]"

data_steward:
  role: "Treasury Data Lead"
  person: "Carlos Vega"
  email: "[email protected]"

classification:
  - "SOX-scope"
  - "GDPR Art. 6 (contract performance)"
  - "Confidential"

criticality_score: 4.50
criticality_dimensions:
  financial: 5
  regulatory: 4
  operational: 5
  reputational: 4
weights_used: { financial: 30, regulatory: 30, operational: 20, reputational: 20 }
weighted_calc: "(5×0.30) + (4×0.30) + (5×0.20) + (4×0.20) = 4.50"

applicable_regulations:
  - id: "SOX-404"
    article: "Section 404(a)"
    rationale: "Материальные P&L расходы + revenue offset; искажение >$10M вызывает material weakness."
  - id: "GDPR"
    article: "Art. 6(1)(b)"
    rationale: "Lawful basis исполнения контракта."
  - id: "Local tax authorities"
    article: "Per-country VAT + withholding"
    rationale: "Подачи в налоговые органы по юрисдикциям ЕС + LATAM + SEA."
  - id: "IRS"
    article: "1099-NEC (US)"
    rationale: "Генерация 1099-NEC для водителей США."

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

control_refs:
  - CTL-FIN-024 # Контроль сверки trip → earnings → payout
  - CTL-FIN-025 # SoD: маршрутизация одобрения, эквивалент payroll
  - CTL-PRIV-008 # Политика retention GDPR
  - CTL-TAX-012 # Точность генерации 1099
  
bia_refs:
  - BIA-SWP-002 # Зависимость payout SwiftPay

escalation_threshold:
  financial: "$2M misstatement / период"
  accuracy: "0.05% дельта сверки"
  
quality_tolerance:
  null_rate: "≤ 0.01% (любое required-поле)"
  reconciliation_delta: "≤ 0.05% trip-to-earnings"
  pipeline_freshness: "≤ 6h SLA"
  
retention:
  policy: "7y immutable (SOX-grade)"
  storage: "S3 с object lock; доступ через Snowflake external table"

tags:
  - financial-reporting
  - swiftpay-2024-precedent
  - pre-ipo-priority
  - q4-2026-attestation-target

incident_history:
  - incident_id: INC-2024-DACH-001
    date: 2024-09-12
    summary: "Ошибка округления в расчёте комиссии; $2.3M недоплачено водителям в регионе DACH"
    root_cause: "Конверсия типа commission_rate в pricing engine v2.1 deploy"
    remediation_completed: 2024-12-01
    
attestation_history:
  - cycle: "Q4 2026"
    date: 2027-01-10
    attestor: "Anna Müller"
    status: "signed-off"

change_history:
  - version: "1.0.0"
    date: 2026-08-15T10:30:00Z
    change: "Первичное создание"
    approvers: ["CDO", "CFO", "Data Council"]
  - version: "1.0.1"
    date: 2026-09-02T09:00:00Z
    change: "Починка опечатки в business_definition (предложение про driver-as-data-subject)"
    approvers: ["CDO Office"]
  - version: "1.1.0"
    date: 2026-11-15T14:00:00Z
    change: "Добавлены control_refs CTL-FIN-024, CTL-FIN-025, CTL-PRIV-008, CTL-TAX-012 (поставка M5)"
    approvers: ["CDO", "Data Council"]

Этот паттерн — полный референс. Подполя могут быть опущены в ожидании построения контролей / BIA (контроли в статусе proposed forward-references — приемлемо).

Кросс-ссылки — модель отношений

Реестр CDE — хаб в большой экосистеме governance:

CDE Registry  ←→  Data Catalog (технические метаданные; URI lineage)
              ←→  Control Catalog (M5; контроли, защищающие CDE)
              ←→  BIA / BCP (M6; business impact, RTO/RPO)
              ←→  Evidence Catalog (M7; квартальная аттестация; запуски контролей)
              ←→  Incident Tracker (связь incident_history)
              ←→  Business Glossary (семантическая связь термина)
              ←→  Regulatory Catalog (обогащение applicable_regulations)

Принцип hub-and-spoke: CDE — основная сущность; другие каталоги — вспомогательные, ссылки в обе стороны. Кросс-ссылки — first-class поля в реестре, не скрытые join.

Версионирование хранения: ИЛИ встраивание кросс-ссылок в YAML реестра (удобство одного файла); ИЛИ join во внешнем бэкенде каталога (Collibra / Atlan / OpenMetadata). Production-ready — бэкенд.

Дизайн схемы SwiftRide

Поставки T+3M:

• Канонический YAML схемы хранится в Git (registry/cde/CDE-SWR-{NNN}.yaml).
• Зеркалирован в OpenMetadata 1.12.x как custom asset type CriticalDataElement.
• Кросс-ссылки на существующие сущности Table в OpenMetadata (через lineage_refs).
• 24 записи CDE опубликованы; semver v1.0.0 каждая.
• Approval workflow операционен — квартальный цикл Data Council (M4.7).
• Control_refs изначально пусты / статус proposed (M5 строит T+6M).
• BIA_refs изначально пусты (M6 строит T+9M).

Паттерн реализации OpenMetadata (предпросмотр для M4.6 + M4.8):

from metadata.generated.schema.entity.classification.tag import Tag
from metadata.generated.schema.entity.data.glossaryTerm import GlossaryTerm
from metadata.generated.schema.type.tagLabel import TagLabel

# Создать custom property set для CDE-атрибутов на Table
# Поля для regulator-mandatory data: business_definition, classification,
# criticality_score, applicable_regulations, control_refs, ...

# Прикрепить к таблице:
ometa.patch_extension(
    entity=Table,
    entity_id=table.id,
    extension_data={
        "cde_id": "CDE-SWR-001",
        "criticality_score": 4.5,
        "business_owner": "Finance Data Office / Anna Müller",
        "classification_label": "SOX-scope",
        # ... и т.д.
    }
)

Лаба M4.8 — студент выполняет этот паттерн для 5 CDE.

Антипаттерны

Только-spreadsheet реестр

Симптом: Excel / Google Sheets — канонический store; не версионирован; не аудируемый журнал изменений.

Исправление: YAML / бэкенд каталога; версионирование Git; неизменяемая история.

Поля-как-комментарии

Симптом: required-поля заполнены placeholder «TBD» / «N/A» вместо реальных значений.

Исправление: TBD — невалидный статус; форсировать решение до approve.

”Одобрение было встречей”

Симптом: одобрение зафиксировано только в meeting minutes; не в change_history реестра.

Исправление: одобрение = переход состояния в state machine; зафиксировано в change_history со списком approvers + timestamp.

Кросс-ссылки односторонние

Симптом: реестр CDE ссылается на контроли; каталог контролей не ссылается на CDE — двусторонняя связь сломана.

Исправление: двусторонние ссылки enforced в бэкенде каталога. Проверка целостности ссылок на save.

Отсутствует версия + отсутствует дата ревью

Симптом: реестр без поля version; ревью «когда нужно» — фактически = никогда.

Исправление: version + last_reviewed_at + next_review_due — required-поля. Каденс квартального ревью (M4.7) enforced автоматически.

”killed без журнала аудита”

Симптом: кандидат отклонён; запись удалена; нет исторической трассы.

Исправление: статус killed сохраняет запись; запись никогда не удаляется из реестра — append-only event log.

Итоги

• 17 обязательных полей + 13 опциональных. ECB RDARR Guide мандатирует все 4 элемента (inventory + владельцы + определения + lineage / DQ); минимум 5-полей НЕ комплаентен.
• Версионирование — semver MAJOR.MINOR.PATCH (рекомендуется); incremental приемлемо для маленьких.
• Неизменяемая история — append-only event log; текущее состояние — проекция.
• State machine approval workflow — proposed → under_review → approved → maintained → retiring → retired (+ killed). Требуемые approvers на переход; кворум Data Council ≥60%.
• Кросс-ссылки hub-and-spoke — реестр CDE в центре; Data Catalog / Control Catalog (M5) / BIA (M6) / Evidence (M7) / Incident Tracker / Glossary / Regulatory Catalog — спицы. Двунаправленно.
• YAML-схема — полный референс, применимый для SwiftRide. Зеркалирование в OpenMetadata / Collibra / Atlan / Purview / DataHub.
• Поставка SwiftRide T+3M — 24 записи CDE v1.0.0; канонический YAML в Git; зеркалирован в OpenMetadata; control_refs / bia_refs изначально пусты (forward к M5 / M6).
• Антипаттерны: только-spreadsheet; TBD-поля; одобрение только-встречей; односторонние ссылки; отсутствует версия / даты ревью; killed без журнала аудита.
• Следующий урок (M4.6): глубокое сравнение каталожных инструментов — OpenMetadata / Collibra / Atlan / Alation / DataHub / MS Purview / Atlas / Informatica / IBM. CDE как примитив vs tag-based. Дерево решений по тулингу SwiftRide.