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

Offer Integrity And Publication Control — Целостность предложения и правила публикации

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

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

Этот документ фиксирует отдельный домен offer integrity and publication control.

Его задача — определить:

  • как платформа оценивает целостность offer before quote and publication;
  • какие аномалии, пропуски и contradictions должны блокировать или ограничивать публикацию;
  • как governance, commercial-model, ingestion и offer сходятся в единую publication discipline;
  • как платформа защищает себя от поставщиков, которые дают технически валидные, но коммерчески или операционно опасные данные.

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

Почему Этот Документ Нужен Отдельно​

Даже если supplier data формально получены, нормализованы и превращены в Offer, это ещё не означает, что их можно безопасно:

  • показывать пользователю;
  • превращать в Quote;
  • публиковать в partner API;
  • использовать как основу для real booking intent.

Для промышленной платформы нужен отдельный контур, который отвечает не на вопрос “пришли ли данные”, а на вопрос:

достаточно ли они целостны и безопасны для коммерческого обещания и внешней публикации.

Главный Принцип Offer Integrity​

Публикация offer — это не автоматическое следствие intake success.

Платформа должна различать:

  • technically parsed;
  • normalized;
  • matched;
  • commercially interpretable;
  • quoteable;
  • publishable;
  • transaction-safe.

Если эти уровни не различать, то в систему просочатся:

  • нулевые или абсурдные цены;
  • неполные cancellation terms;
  • supplier contradictions;
  • broken occupancy semantics;
  • invalid currency or tax structures;
  • offers, опасные для platform liability.

Основные Классы Integrity Checks​

1. Structural Integrity​

  • есть ли обязательные поля;
  • валидны ли dates and occupancy;
  • согласованы ли room/product references;
  • нет ли broken localization or content references.

2. Commercial Integrity​

  • разумна ли цена;
  • complete ли taxes/fees semantics;
  • можно ли построить commercial interpretation;
  • нет ли anomalous zero/negative/absurd amounts;
  • нет ли contradictions between price components.

3. Availability Integrity​

  • не устарело ли состояние;
  • достаточно ли confidence для publication;
  • нет ли признаков stale or degraded supplier truth.

4. Policy Integrity​

  • разрешён ли этот supplier / market / product for this tenant;
  • не нарушает ли offer tenant-specific publication constraints;
  • не попадает ли offer в blocked category.

5. Liability Integrity​

  • не создаёт ли offer непропорциональный platform risk;
  • не требует ли manual review before quote;
  • не находится ли в зоне supplier dispute or unresolved anomaly.

Publication States​

Платформа должна различать как минимум:

  • internal_only;
  • review_required;
  • commercially_blocked;
  • publishable_preview;
  • quoteable;
  • transaction_safe;
  • suppressed.

Один и тот же offer может быть видим internal operator-у, но не быть publishable наружу.

Surface-Aware Publication​

Платформа не обязана публиковать один и тот же offer одинаково на всех surface-ах.

Нужно различать:

  • internal operator visibility;
  • agency working visibility;
  • partner API publication;
  • B2C/public publication.

Важный вывод​

Publication control должен быть surface-aware и tenant-aware, а не только offer-global.

Связь С Governance​

Governance нужен не только для MDM and matching.

Он также нужен для:

  • anomaly review;
  • commercial anomaly decisions;
  • supplier-specific suppression;
  • publication holds;
  • manual approval of risky offers.

Связь С Quote​

Quote не должен рождаться из offer, который ещё не прошёл минимальный integrity threshold.

Переход offer -> quote должен быть gated.

Связь С Observability​

Платформа должна наблюдать:

  • anomaly rate;
  • blocked publication rate;
  • suppressed supplier share;
  • quote blocked by integrity;
  • booking issues caused by insufficient integrity gating.

Что Должно Быть Сделано Дальше​

После фиксации этого домена нужно:

  • синхронизировать offer-pricing-booking-semantics, commercial-model, ingestion, api-contracts, clients;
  • определить integrity state model;
  • оформить anomaly taxonomy and blocking policy;
  • связать publication discipline с tenant enablement and supplier risk profiles.

Уточнение под Фазы 4–6 (28.04.2026) — связь с canary, A/B, surface visibility, governance​

Документ опубликован 24.04.2026 (Фаза 3). После Фаз 4–6 publication control интегрирован с client surfaces, A/B экспериментами, governance, security audit; эта секция фиксирует связи.

Связь с client surfaces visibility​

reference/clients.md (Фаза 7) — каноничная truth visibility matrix per client surface:

  • Internal Operational — full lineage + governance flags;
  • Agency — sanitized + supplier name;
  • Partner Machine — contract-approved fields;
  • Partner UI/SDK — partner-tier dependent;
  • B2C — presentation-safe (no supplier name);
  • White-Label — partner-defined.

Publication control обязательно учитывает target surface при принятии решения публиковать.

Связь с A/B testing​

reference/ab-testing-platform.md (Фаза 4) — публикация offer может быть part of experiment:

  • experiment.assigned — subject получает specific offer variant;
  • feature_flag.evaluated — публикация может быть gated за feature flag;
  • guardrail metrics — публикация автоматически останавливается при degradation.

Связь с governance​

reference/data-governance-and-matching.md — publication holds:

  • governance может block publication через explicit decision;
  • Anomaly detection auto-blocks publication до review;
  • governance unblock — explicit governance.publication.released event.

Связь с booking state machine​

reference/booking-state-machine.md (Фаза 5) — integrity gate перед booking:

  • от submitted → pending_revalidation — integrity check обязателен;
  • pending_revalidation → failed — possible outcome integrity gate violation;
  • offer integrity напрямую влияет на unknown_external_state ratio.

Связь с release engineering​

operations/release-engineering-and-migrations.md — publication control интегрирован с release:

  • canary deployment может включать canary publications (small % offer ranking exposure);
  • error budget gate — publication может быть paused при превышении burn rate;
  • gradual rollout новых ranking algorithms через A/B exposure.

Связь с security audit​

reference/security-architecture.md (Фаза 10) — publication audit:

  • каждое publication decision генерирует audit event;
  • governance overrides — особый класс event с расширенным audit;
  • 7 лет retention.

Связь с metering​

reference/api-metering-and-usage-governance.md — publication frequency и volume — metric для tariff calculation per partner.

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

Publication control остаётся integrity gateway. Интеграция:

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