Перейти к основному содержимому

Data Governance And Matching — Provenance, merge policy и human-in-the-loop контроль

Версия: 1.0
Дата: 23.04.2026
Статус: Готов к обсуждению

Назначение документа​

Этот документ фиксирует data governance and matching как самостоятельный обязательный контур платформы.

Его задача — собрать в одном месте:

  • provenance;
  • matching semantics;
  • merge policy;
  • source precedence;
  • confidence model;
  • anomaly handling;
  • manual review;
  • human-in-the-loop governance;
  • policy-driven применение и отклонение supplier-derived изменений.

Без этого слоя платформа не может считаться промышленной, даже если у неё есть хорошие suppliers, ingestion, storage и API.

Опорные документы​

Почему Governance Не Является Вторичным Улучшением​

В Главные выводы и проблемные зоны платформы уже зафиксировано, что governance-слой не является вторичным улучшением. Он является обязательной частью production reality.

Это означает, что платформа не может ограничиться идеей:

  • “у нас есть matching algorithm”;
  • “у нас есть confidence score”;
  • “если что-то не сошлось, логируем и идём дальше”.

Для реальной travel-платформы этого недостаточно, потому что качество данных влияет на:

  • canonical property identity;
  • product mapping;
  • offer correctness;
  • quote stability;
  • booking feasibility;
  • partner/customer trust;
  • support cost;
  • операционную устойчивость.

Главный Принцип Data Governance​

Платформа не должна автоматически считать, что supplier-derived update может безусловно стать canonical truth только потому, что он выглядит “похожим” или “свежим”.

Любое значимое изменение должно рассматриваться через четыре вопроса:

  1. Откуда это пришло?
  2. Насколько этому можно доверять?
  3. Можно ли применить это автоматически?
  4. Что должно произойти, если автоматическая уверенность недостаточна?

Именно эта логика и образует governance layer.

Что Такое Matching В Контексте Платформы​

Matching — это не просто fuzzy search и не только hotel deduplication.

В контексте платформы matching означает controlled domain decision about correspondence between:

  • supplier property and canonical property;
  • supplier product and canonical product;
  • incoming change and existing entity;
  • candidate merge and protected canonical state.

Это доменная операция, а не чисто технический helper.

Matching Как Reviewable Process​

Платформа должна исходить из того, что matching всегда может оказаться:

  • уверенным;
  • сомнительным;
  • конфликтным;
  • потенциально опасным для canonical truth.

Поэтому matching должен быть:

  • reviewable;
  • explainable;
  • traceable;
  • replayable;
  • policy-aware;
  • overrideable by governance decision.

Что Matcher Обязан Давать​

Не только score, но и:

  • ranked candidates;
  • factors of match;
  • factors of doubt;
  • conflicting fields;
  • recommended outcome;
  • policy context;
  • link to source trace.

Классы Matching Outcomes​

На текущем этапе разумно закрепить как минимум такие outcomes:

  • auto_accept
  • auto_reject
  • review_required
  • new_entity_candidate
  • conflict_unresolved
  • manual_lock_respected

Практический Смысл​

Outcome должен определять не только запись в таблицу, но и downstream behavior:

  • обновлять ли canonical layer;
  • публиковать ли signal дальше;
  • создавать ли review case;
  • блокировать ли supplier delta;
  • поднимать ли anomaly.

Provenance И Field-Level Lineage​

Governance начинается не с review queue, а с происхождения данных.

Для Каждого Значимого Поля Нужно Понимать​

  • из какого source оно пришло;
  • когда оно пришло;
  • каким ingest run оно было обработано;
  • было ли оно применено автоматически;
  • какой rule его пропустил или остановил;
  • было ли оно когда-то зафиксировано вручную;
  • какое предыдущее значение оно заменило.

Почему Это Обязательно​

Без field-level lineage невозможно:

  • объяснить merge decisions;
  • расследовать data regressions;
  • усиливать или ослаблять supplier trust;
  • безопасно менять matching logic;
  • проводить manual adjudication.

Source Precedence​

Не все источники равны, и это должно быть формализовано как policy.

Source Precedence Может Зависеть От​

  • типа поля;
  • региона;
  • supplier class;
  • trust profile источника;
  • freshness requirements;
  • manual governance locks;
  • business criticality поля.

Типы Precedence Policy​

  • preferred source by field;
  • preferred source by supplier class;
  • preferred source by region;
  • most-recent-wins only for selected volatile fields;
  • never-overwrite-protected-field;
  • overwrite-only-if-confidence-threshold-met;
  • manual-review-required for protected domains.

Что Нельзя Делать​

  • применять один global precedence rule ко всему объекту;
  • считать “самое новое” автоматически лучшим;
  • позволять слабому supplier-у разрушать manually curated canonical state.

Merge Policy​

Merge должен пониматься как policy-driven reconciliation process, а не как технический upsert.

Merge Может Затрагивать​

  • identity-related fields;
  • content fields;
  • geo fields;
  • amenity fields;
  • policy fragments;
  • supplier-product relationships;
  • derived commercial relevance.

Merge Policy Должна Отвечать На Вопросы​

  • можно ли поле обновить автоматически;
  • допускается ли partial merge;
  • какие поля защищены;
  • нужно ли создавать review case;
  • можно ли публиковать обновление downstream;
  • какой audit event должен быть сохранён.

Merge Не Должен Делаться Целиком На Уровне “Вся Запись”​

Потому что разные поля одной и той же сущности могут иметь:

  • разные источники;
  • разную критичность;
  • разную степень доверия;
  • разные precedence rules.

Confidence Model​

Confidence нужен, но он не должен быть единственным механизмом принятия решения.

Confidence Должен Быть​

  • explainable;
  • field-aware or factor-aware;
  • policy-aware;
  • not the sole source of truth.

Confidence Может Использоваться Для​

  • auto-accept thresholds;
  • review routing;
  • anomaly severity hints;
  • monitoring quality drift;
  • deciding whether replay or manual review is required.

Confidence Нельзя Использовать Как Магическое Оправдание​

Фраза “score выше 0.8, значит применяем” — недостаточна для production-grade governance.

Manual Review And Adjudication​

Платформа обязана иметь нормальный human-in-the-loop path.

Review Нужен Для​

  • uncertain property matching;
  • product ambiguity;
  • geo conflicts;
  • content regressions;
  • protected field overwrite attempts;
  • supplier anomalies;
  • conflicting merge candidates;
  • questionable precedence outcomes.

ReviewCase Должен Содержать​

  • source trace reference;
  • current canonical snapshot;
  • candidate values;
  • matching candidates;
  • explanation factors;
  • proposed action;
  • diff view;
  • history of related decisions;
  • affected downstream risk.

Review Outcome Должен Быть Явным​

  • approved
  • rejected
  • mapped_to_existing
  • created_as_new
  • deferred
  • escalated

Anomaly Handling​

Аномалии — это не “ошибки парсинга”. Это отдельный operational signal.

Conflict Resolution Playbook​

Этот раздел сводит уже описанные governance-механизмы (Source Precedence, Merge Policy, Confidence Model, Manual Review) в операционный playbook для типовых сценариев конфликта данных от нескольких поставщиков.

Раздел добавлен после внешнего архитектурного ревью 30.04.2026, в котором отмечено, что отдельные governance-концепты у нас зафиксированы каждый по отдельности, но не сведены в единый сценарный путеводитель «что делать когда два supplier'а противоречат друг другу». Без этого playbook'а ingestion на 50 supplier'ов рискует получить «гнилой фундамент» — каноническая модель наполнится дублями и противоречиями, обнаруженными post-factum.

Принцип Playbook​

Конфликт данных — это не редкий corner-case, а постоянная норма работы ingestion'а. Платформа должна обрабатывать конфликты автоматически в большинстве случаев и передавать в human review только реальные неопределённости. Этот принцип реализуется через комбинацию четырёх уже задокументированных механизмов:

  1. Source Precedence — у каждого поля каждого типа сущности зафиксирован канонический источник или иерархия источников. Это первый фильтр.
  2. Confidence Model — каждое поле получает field-level confidence в зависимости от источника, согласованности с другими источниками, age данных и анамнеза изменений.
  3. Merge Policy — правила автоматического обновления для каждого класса полей: какие auto-update, какие protected, какие требуют review.
  4. Manual Review — для случаев, где автоматика не имеет уверенности достаточной для принятия решения.

Каноничные классы конфликтных сценариев​

Перечисленные ниже сценарии — основные классы, для каждого зафиксирована каноничная политика разрешения. Перечень не закрытый — новые классы добавляются по мере накопления операционного опыта.

Сценарий 1: расхождение в географических координатах​

Триггер: два или более supplier'а вернули разные координаты для одного и того же property.

Каноничная политика:

  • Authoritative source для координат — внешний geo-сервис (Google Places, Mapbox, OpenStreetMap), не supplier. Координаты supplier'а используются только для сопоставления и valid-range проверки, не для записи в canonical model.
  • Если authoritative source недоступен или не возвращает координат — применяется majority voting среди не менее трёх supplier'ов с порогом согласия 80%.
  • Если порог не достигнут (два supplier'а X, один Y) — confidence ниже порога auto-accept, ReviewCase создаётся.
  • Расхождение более чем на 500 метров между confirmed координатами и любым новым супplier-input'ом — anomaly trigger (coordinate_drift_anomaly).

Сценарий 2: расхождение в звёздности (star_rating)​

Триггер: разные supplier'ы возвращают разные значения star_rating для property.

Каноничная политика:

  • Authoritative source — supplier с самой длинной историей бесконфликтной информации по этому property (track record), либо manual curation для верхнего сегмента (premium / luxury hotels).
  • Стандартное расхождение в одну звезду между двумя supplier'ами — известная норма (разные классификационные системы); применяется voting и сохранение обеих записей в provenance с пометкой источника.
  • Расхождение более одной звезды — ReviewCase, не auto-update.
  • star_rating относится к protected field для уже верифицированных property — overwrite только через manual review.

Сценарий 3: один supplier поменял координаты — поправка ошибки или новая локация?​

Триггер: конкретный supplier, который раньше давал координаты X, теперь стабильно даёт Y.

Каноничная политика:

  • Если новые координаты Y совпадают с координатами от других supplier'ов и/или authoritative geo-source — это поправка ошибки supplier'а: canonical model не меняется (она и так правильная), но в provenance фиксируется что supplier «исправился», его trust score для координат возрастает.
  • Если новые координаты Y расходятся со всеми остальными supplier'ами и authoritative source — это подозрение на supplier identity drift: возможно supplier теперь продаёт другое property под тем же ID. Создаётся ReviewCase класса supplier_identity_drift_suspected с заморозкой merge до решения модератора.
  • В обоих случаях движение координат фиксируется как coordinate_change_event с before/after для audit trail.

Сценарий 4: три источника, два говорят X, один Y​

Триггер: majority/minority конфликт без явного authoritative source.

Каноничная политика:

  • Не действует общее правило «большинство выигрывает». Потому что:
    • три supplier'а могут все быть низкого качества;
    • один supplier minority может быть единственным authoritative для этого типа поля;
    • majority может отражать общее заблуждение рынка (например, все три копируют ошибочную информацию из общего публичного источника).
  • Применяется weighted voting: голос каждого supplier'а взвешивается на его field-level trust score (накопленный за прошлые наблюдения за этим типом полей этого supplier'а).
  • Если weighted majority превышает порог auto_apply_threshold (по умолчанию 0.7) — auto-apply.
  • Если ниже — ReviewCase, поле остаётся в текущем canonical state до решения.

Сценарий 5: supplier-specific поля без аналога у других supplier'ов​

Триггер: supplier даёт уникальное поле (например, internal_supplier_promotion_flag), которого нет у других.

Каноничная политика:

  • Уникальные supplier-specific поля не копируются в canonical model. Они хранятся в SupplierDerivedEntities (см. reference/domain-model.md, 7 групп каноничных сущностей) с явной supplier-attribution.
  • Каноничная модель содержит только поля, которые семантически выражают что-то одно независимо от того, какой supplier их даёт.
  • Бизнес-логика, которой нужны supplier-specific поля, явно работает с SupplierDerivedEntities слоем, а не с canonical model.

Сценарий 6: цепочка изменений (drift over time)​

Триггер: поле постепенно меняется на small increments через несколько ingestion-циклов; ни одно отдельное изменение не превышает auto-apply threshold, но кумулятивно поле уехало далеко от изначального canonical value.

Каноничная политика:

  • Каждое изменение поля сравнивается не только с предыдущим значением, но и с baseline (значение N циклов назад или manual-curated значение).
  • Если кумулятивный drift превышает cumulative_drift_threshold (по умолчанию для координат — 200 м, для star_rating — 0.5 звезды, для price — 30%) — anomaly trigger независимо от размера каждого отдельного шага.
  • Anomaly создаёт ReviewCase класса cumulative_drift_detected с историей всех incremental изменений.

Сценарий 7: supplier'ы конфликтуют по display_name​

Триггер: разные supplier'ы возвращают разные названия property — «Hotel California Beach», «Hotel California», «California Beach Resort».

Каноничная политика:

  • Display name — protected field для верифицированных property. Auto-update запрещён.
  • Каноничное имя устанавливается через manual curation на этапе onboarding property.
  • Supplier display names хранятся в SupplierDerivedEntities как aliases — они используются для matching новых ingestion-batches и для search relevance ranking, но не подменяют canonical display name.
  • Только manual review может изменить canonical display name.

Provenance Trail для Каждого Конфликта​

Каждое разрешение конфликта (auto или manual) создаёт provenance entry в field-level lineage canonical поля:

  • field_change_id — UUID этого изменения;
  • field_path — путь поля в canonical entity;
  • previous_value / new_value;
  • decision_path — какой механизм принял решение (source_precedence, weighted_voting, manual_review, protected_field_overwrite);
  • confidence_at_decision — confidence score на момент решения;
  • participating_sources — список supplier'ов и их вклад в решение;
  • reviewer_id — для manual решений;
  • applied_at / published_downstream_at — таймлайн.

Это даёт возможность полного re-tracing любого спорного значения в canonical model, ответ на вопрос «почему сейчас такое значение и кто его таким сделал».

Связь с Replay Policy​

Если policy эволюционирует (например, мы понимаем что supplier X стал недоверенным для координат и нужно понизить его trust score), это не должно триггерить автоматический пересмотр всех уже принятых решений по координатам.

Каноничный подход:

  • Policy change применяется только к новым ingestion-batches с момента изменения.
  • Уже принятые canonical values не пересматриваются автоматически.
  • Может быть запущен opt-in replay для конкретного класса записей (например, replay координат property, у которых ингестировались данные от supplier X в последние 90 дней) — но это отдельная operations процедура, не side-effect policy change.

См. также раздел Replay And Policy Evolution выше.

Метрики Качества Conflict Resolution​

Для мониторинга работы playbook'а трекаются следующие метрики:

  • conflict_rate_per_field — доля полей в конфликте от общего числа ingestion-events.
  • auto_resolution_rate — доля конфликтов, разрешённых автоматически.
  • review_queue_lag — среднее время от создания ReviewCase до его закрытия.
  • false_auto_resolution_rate — доля auto-решений, которые позже были изменены через manual review (метрика качества policy).
  • cumulative_drift_anomaly_rate — частота срабатывания anomaly по cumulative drift.

Эти метрики связаны с SLI операционного слоя (см. operations/sla-and-on-call-model.md) и с supplier quality dashboard'ом (см. раздел Governance И Supplier Quality выше).

Обоснование (тезисы)​

Тезис 1. Конфликт данных от нескольких supplier'ов — это постоянная норма работы ingestion'а, а не аварийное событие.

Альтернативы: (а) считать конфликт ошибкой и отбраковывать; (б) считать конфликт нормой и обрабатывать playbook'ом; (в) ad-hoc подход для каждого supplier'а.

Trade-off: вариант (а) приводит к потере данных и невозможности работать с реальностью; вариант (в) не масштабируется на десятки supplier'ов; вариант (б) — каноничный подход верхнеуровневых платформ работающих с множеством источников.

Тезис 2. Voting не должен быть единственным механизмом принятия решения.

Альтернативы: (а) majority всегда выигрывает; (б) Source Precedence приоритетнее voting'а, voting только для полей без явного authoritative source; (в) confidence-only без voting.

Trade-off: вариант (а) уязвим к кооперативному заблуждению supplier'ов и не учитывает trust score; вариант (в) скрывает логику в score без объяснимости; вариант (б) — каноничный, баланс предсказуемости и адаптивности.

Тезис 3. Каждое разрешение конфликта оставляет provenance trail.

Альтернативы: (а) хранить только финальное canonical value; (б) хранить provenance каждого field-level изменения с decision path; (в) хранить только аудит manual review.

Trade-off: вариант (а) делает невозможным re-tracing и эволюцию policy; вариант (в) теряет 95% операционных решений (большинство — auto); вариант (б) — каноничный, основа для quality monitoring и replay.

Открытые вопросы​

  • Где живёт Source Precedence config? Hardcoded в коде ingestion'а, в DB как configurable policy, или в отдельном governance-сервисе как rule engine? Решение определяет насколько быстро меняется policy без redeploy. Текущая позиция: configurable policy в DB с history change tracking.
  • Cold start: как определить trust score для нового supplier'а до накопления истории? Вариант — наследовать default trust score от supplier class, корректировать после первых 1000 ingestion-events.
  • Должны ли мы публиковать domain event при каждом field-level conflict resolution? Это нагрузка на event bus, но даёт downstream'ам полное понимание data quality. Текущая позиция: публиковать только конфликты, разрешённые с low confidence и через manual review.

Типовые Аномалии​

  • резкое изменение координат;
  • резкое изменение звездности;
  • исчезновение важных content fields;
  • внезапное дублирование canonical candidates;
  • невозможный price or availability jump;
  • supplier identity drift;
  • policy contradiction;
  • systematic degradation from one source.

Anomaly Workflow Должен Включать​

  • registration;
  • classification;
  • severity assignment;
  • affected entity linkage;
  • possible automatic mitigation;
  • review routing;
  • downstream publication control;
  • closure with reason.

Governance Queue Model​

Внутренний operational surface должен работать не с хаотичным списком проблем, а с нормализованными governance queues.

Базовые Типы Очередей​

  • property matching review;
  • product mapping review;
  • protected field overwrite review;
  • anomaly review;
  • supplier quality investigation;
  • merge conflict adjudication.

Для Каждой Очереди Нужны​

  • priority;
  • tenant/supplier/entity scope;
  • aging policy;
  • assignee or ownership model;
  • SLA or review target;
  • escalation path.

Governance И Supplier Quality​

Governance касается не только canonical entities, но и supplier trust itself.

Governance Может Влиять На​

  • supplier precedence;
  • supplier domain trust;
  • quarantine of source updates;
  • forced review for source domain;
  • publication suppression;
  • alerting and escalation;
  • source capability profile updates.

Практический Вывод​

Governance layer должен уметь менять поведение платформы по отношению к поставщику, а не только “исправлять отдельные записи”.

Governance И Downstream Publication​

Не каждое supplier-derived изменение должно немедленно становиться доступным downstream системам.

Governance Должен Уметь Решать​

  • публиковать ли обновление немедленно;
  • публиковать ли только часть изменения;
  • блокировать ли downstream propagation;
  • запускать ли invalidation and rebuild;
  • создавать ли operator-visible warning.

Это особенно критично для полей, которые влияют на:

  • search relevance;
  • offer correctness;
  • quote validity;
  • booking feasibility;
  • client-facing trust.

Replay And Policy Evolution​

Governance не должен быть разовым ручным решением без возможности последующего пересмотра.

Платформа Должна Поддерживать​

  • replay after matching logic changes;
  • replay after precedence policy changes;
  • replay after protected field policy changes;
  • review of past decisions;
  • comparison of “old policy vs new policy” outcomes.

Почему Это Важно​

Потому что governance logic будет эволюционировать, и без replay model платформа застрянет в наследии старых решений.

Governance Truth​

Governance создаёт собственный слой истины.

К Нему Относятся​

  • mapping decisions;
  • merge decisions;
  • precedence rules;
  • manual locks;
  • anomalies and their resolution;
  • review outcomes;
  • field lineage.

Этот слой не должен растворяться ни в supplier tables, ни в canonical entity tables.

Что Нельзя Больше Путать​

После фиксации этого документа ошибкой должно считаться смешение:

  • matching и merge;
  • confidence и decision;
  • supplier trace и canonical truth;
  • automatic update и governed update;
  • parse error и anomaly;
  • review queue и просто лог ошибок;
  • precedence и “берём самое новое”.

Связь С Уже Переписанными Документами​

Suppliers​

Suppliers Layer — Поставщики, source boundaries и управление внешней реальностью задаёт supplier-side trust and risk context. Этот документ определяет, как платформа управляет этим контекстом.

Ingestion​

Ingestion Layer — Приём, нормализация, маппинг и governance описывает processing path. Этот документ делает governance part of that path explicit and authoritative.

Domain Model​

Domain Model — Центральная доменная модель платформы уже ввёл ReviewCase, MergeDecision, FieldLineage, SourcePrecedenceRule, Anomaly. Здесь раскрыт их смысл.

Database Schema​

Database Schema — Каноническая модель хранения платформы уже выделяет контур governance. Этот документ объясняет, почему он нужен и как должен использоваться.

Clients​

Clients Layer — Клиентские поверхности и рабочие модели требует internal review and anomaly handling surfaces. Этот документ задаёт их доменный смысл.

Что Должно Быть Перепроверено После Этого Документа​

Теперь, когда второй обязательный слой почти собран, можно возвращаться к углублённой стабилизации и синхронизации:

  • api-contracts.md
  • database-schema.md
  • storage.md
  • clients.md
  • operations/deployment.md
  • development/roadmap.md

Именно после governance layer такие возвраты уже можно делать безопаснее и системнее.

Текущий Практический Вывод​

Data governance and matching в vitiana-api-platform должны мыслиться не как вспомогательная техника ingestion, а как самостоятельный контур управления качеством и происхождением данных.

Это означает:

  • matching — reviewable domain decision;
  • merge — policy-driven reconciliation, а не upsert;
  • precedence — explicit rule system;
  • confidence — вспомогательный сигнал, а не автоматический verdict;
  • anomaly handling — отдельный workflow;
  • manual review — обязательная часть production reality;
  • governance truth — самостоятельный persistent слой платформы.

Именно этот документ замыкает второй несущий круг архитектурной документации, без которого suppliers, ingestion, domain model, identity, offer/booking semantics и client surfaces оставались бы концептуально неполными.

Связанная Документация​

Уточнение под Фазы 4–6 (28.04.2026) — связь с isolation, security audit, compliance​

Документ опубликован 23.04.2026 (Фаза 3). После Фаз 4–6 governance-контур интегрирован с tenant isolation, security audit, compliance review processes; эта секция фиксирует связи.

Связь с уровнями тенантной изоляции​

reference/multi-tenant-isolation-strength.md (Фаза 5) — governance decisions имеют per-tenant boundary:

  • MappingDecision, MergeDecision per tenant_id;
  • cross-tenant mapping (например, supplier обслуживает несколько tenants) — explicit governance policy с k-anonymization;
  • IsolationBoundaryCheck events могут потребовать governance review при detection cross-tenant data leak.

Связь с security audit logging​

reference/security-architecture.md (Фаза 10) — каждое governance decision генерирует audit event в immutable WORM storage:

  • governance.review.started, governance.review.completed;
  • governance.mapping.applied, governance.merge.applied;
  • governance.publication.held, governance.publication.released;
  • governance.manual_override.executed — особый класс event с расширенным audit trail.

Retention 7 лет (Tier 1 storage class).

Связь с compliance — privacy review hooks​

reference/compliance-and-legal.md (Фаза 4) — каждое governance решение, затрагивающее PII (например, merge profiles конкретного customer), проходит privacy review как part of governance flow:

  • automatic check data_field_inventory для изменяемых полей;
  • explicit lawful basis check;
  • DSR-friendly: governance decisions retrievable через DSR API.

Связь с booking governance​

reference/booking-state-machine.md (Фаза 5) — состояние unknown_external_state (8-е каноничное) trigger'ит governance review обязательно:

  • governance reviewer проверяет supplier reality;
  • принимает MergeDecision (если supplier responsibility),либо CancellationDecision (если manual recovery);
  • Booking не покидает unknown_external_state без явного governance действия.

Governance — operational gateway для critical incidents.

Связь с runbooks​

operations/runbooks-incident-playbooks.md (Фаза 6) — 8 канонических incident classes, для каждого governance может быть mandatory escalation step:

  • supplier degradation → governance может выпустить supplier suppression;
  • stale offer state → governance может force re-publication;
  • governance queue overload — отдельный incident class с runbook (см. runbooks-incident-playbooks.md).

Связь с data platform — events tracking​

reference/data-platform-and-events-tracking.md (Фаза 4) — governance events попадают в отдельный operational class event stream:

  • guarantees: at-least-once + ordered per ReviewCase;
  • retention: 7 лет (Tier 1);
  • access: только governance team + security audit + compliance officer.

Связь с ML platform — explainability​

reference/ml-platform.md (Фаза 4) — governance interfaces с ML:

  • anomaly detection в ingestion (ML use case) → создаёт Anomaly для governance review;
  • content moderation (ML use case) → governance может override ML decision;
  • GDPR right not to be subject to automated decision-making — governance reviewer involved для high-impact decisions.

Каноничный итог уточнения​

Governance остаётся самостоятельным контуром с человеком в цикле. Реализация:

Уточнение выполнено через no-destruction.