Why
Before this, multi-platform integration and catalog evidence, Yandex data ingestion, and unified business analytics definitions were advanced separately. The goal of this event was to connect them onto the same chain: to have Ozon and Yandex share the same order facts, rather than each maintaining its own definitions.
Another motivation was to make the boundary clear. The scheduler-related code has entered the deployed artifact, but "code deployed" and "running in production as planned" are two different things. This record deliberately leaves the latter blank, to avoid writing a not-yet-enabled capability as a completed running state.
What changed
The changes centered on channel integration, business analytics, and the Yandex platform adaptation: the console's channel and insights pages, the analytics library, the channel library, the Yandex platform adaptation layer, and the server-side logic.
On the data side, a foreign key constraint was added to the catalog, to protect observation evidence while not locking down the task rows themselves — this constraint has a corresponding test assertion. On the channel side, a round of RC fixes was made, covering store onboarding-related acceptance, time zones, shared secrets, and the PII allowlist.
On the documentation side, two deployments were recorded: one is the code deployment and P5 production observation of Yandex scheduler V1, and the other is the Yandex analytics main-chain integration. Both deployments are recorded in the overview document.
For specific versions, commits, deployed artifacts and digests, test counts, runtime state, and corpus counts, see the facts above.
- Version
- 20260926-yandex-sched-add2ba4 / 20260926-yaxan-1771e0c
- Main release commit
- 025b05e54469a5e8ab636915322cbe478f73131e
- Production provenance commit
- 025b05e54469a5e8ab636915322cbe478f73131e
- Deployed artifact and digest
- 20260926-yandex-sched-add2ba4 (recorded in docs/00-overview/CURRENT_STATE.md); 20260926-yaxan-1771e0c (recorded in docs/00-overview/CURRENT_STATE.md)
- Test counts
- see the catalog foreign key assertion in commit df4bb40802d4f0ee6af67d3bf7e09d74d39e7b5e
- Runtime state
- scheduler code deployed, not enabled
- Current authoring corpus
- 8 notes / 24 variants (of which 1 is still unpublished)
How we verified it
Verification had three layers. The first layer is the commit itself: the main release commit and the production provenance commit point to the same SHA, showing that the record and the deployed artifact match up.
The second layer is tests: the catalog foreign key change carries an assertion, verifying that it protects observation evidence while not trapping the task rows.
The third layer is documentation: the two deployments each have a release id and a recorded date, and land in the overview document; the architecture document separately describes the design of Yandex order scheduler V1.
What it does not mean
It does not mean the scheduler is already running in production as planned. Code entering the deployed artifact, and the scheduler being enabled, scheduled, and observed to run stably, are conclusions at different levels.
It also does not mean multi-platform integration has been wrapped up. This event connected the order facts of Ozon and Yandex to the same definitions, but the scope of integration, subsequent platforms, and coverage of operational processes are not within this evidence.
It likewise does not mean the corpus is complete. As of the current repository there are still unpublished notes; the corpus count is the repository state captured at the time of writing, and later repository growth will not change the meaning of this number.