docs/architecture/orders/ingestion.md

@@ -106,6 +106,25 @@ JSON-объектом с точным набором ключей: `order_id`, `
 - `_load_id` — какой запуск Airflow принял строку;
 - `_load_ts` — когда строка приехала в хранилище.
 
+У выжившей после схлопывания строки три последние координаты означают меньше,
+чем кажется. Версию выбирает только `updated_at`; заказ, не менявшийся
+несколько дней, приезжает в нескольких слепках одинаковыми деловыми полями, и
+какая из этих строк переживёт схлопывание — не обещано. Поэтому её
+`snapshot_date` — *один из* дней, когда источник показывал эту версию, не
+обязательно последний; то же с `_load_id` и `_load_ts`. Замер 22 августа
+2026 года (#137): у 86 заказов стартового мира выжил даже не крайний день, а
+серединный. Вопрос «когда заказ наблюдался в последний раз» задаётся сырью STG,
+пока его не съел срок жизни, — а не одной строке ODS.
+
+Вся схема версий стоит на одном свойстве источника: уточнение заказа поднимает
+`updated_at`. Наш генератор моделирует источник с триггерной меткой и это
+свойство гарантирует; замеры 22 августа 2026 года его подтвердили — во всех
+парах строк с равным `updated_at` деловые поля совпали побайтово, а по слепкам
+метка не убывала ни разу. Это допущение, а не закон природы: источник, умеющий
+уточнить строку тихо — правка мимо приложения, миграция, ручной `UPDATE`, —
+эту схему ломает, и тогда версии по метке времени уже не хватает, нужна сверка
+самих полей (в терминах dbt snapshots — стратегия `check` вместо `timestamp`).
+
 Обычное чтение `_dist` показывает физически сохранившиеся версии и нужно для
 диагностики. Их число зависит от фоновых слияний: ODS не служит архивом истории.
 `ods.order_v` сохраняет те же источник-ориентированные поля без обогащения

sql/ddl/20-ods-tables.sql

@@ -163,7 +163,10 @@ ENGINE = Distributed('clickstream_cluster', 'ods', 'event_errors_rep', cityHash6
 -- updated_at — какая бизнес-версия новее; snapshot_date — в слепке какого
 -- модельного дня источник показал строку; _load_id — какой запуск Airflow её
 -- принял; _load_ts — когда она приехала в хранилище. Ключом сущности не
--- становится ни одна из трёх последних: они про наблюдение и загрузку.
+-- становится ни одна из трёх последних: они про наблюдение и загрузку. Версию
+-- выбирает только updated_at, поэтому у выжившей после схлопывания строки
+-- snapshot_date — один из дней, когда источник показывал эту версию, не
+-- обязательно последний (docs/architecture/orders/ingestion.md).
 --
 -- PARTITION BY toDate(created_at) — по дню создания строки в источнике. Он
 -- неизменен у всех версий заказа, поэтому версии лежат в одной партиции и