ORE Studio Sprint 25 – Release Notes

• Drift baseline, per component: ores.dq, ores.iam, ores.synthetic, ores.compute, ores.analytics and ores.reporting bound to profiles, with zero-diff regeneration verified. ores.trading was listed here too; its regeneration was never drift-clean and the claim is retracted.
• Template fixes: history provenance fields, compound-key gating, pagination, junction templates, RLS policy emission and the history-provider registrar.
• Model hygiene: redundant explicit properties removed; the has_parent_id feature moved to the entity root so that profile bindings take effect.
• Checks: the populate reference drift check, the drift checks in CI, and the compiler warnings (-Wall, -Wextra) the code assumed.
• Protocol: IAM and refdata messages generate from one model into C++ and TypeScript.

• oresmd: the legacy market_series qualifier and ore_key are gone, and every ORE quote type has an oresmd identifier.
• FOMC short end: calendar events, a unified tenor resolution (FOMC, IMM and tenor), and the bootstrap segment.
• Process engines: G2++ and Black-Karasinski are wired end to end. BDT, affine, HJM, LMM and Quadratic Gaussian engines exist, but they are not wired yet.
• Classification: asset classes and series subclasses are refdata catalogs, a series can belong to more than one asset class, and the classifier covers the whole ORE corpus.
• Feeds: one asset-class-agnostic control plane, and per-party consumption of the shared simulated market.

• The holding company has FX and CRM visibility, a Group Treasury book, and a manual section.
• The ACME fit-for-purpose review fixed tenant scoping, a TimeZone-dependent bitemporal sentinel, and silent provisioning failures.
• Synthetic data has scope (system, tenant, party) and binding mode (bound, sandboxed).

• systemd: per-environment isolation and resource limits across the fleet, and a smaller database connection pool for each service.
• Remote WSL: compass deploys the runtime and a compute node to a remote host.
• Testing: an injectable environment provider, rerunnable test databases, and a hardened eventing chain.
• PR flow: GitHub CI no longer gates pull requests. Targeted local checks and a local review run before a PR is raised, and the PR body carries a mandatory Testing section.
• ores.shell: split into api and application parts.
• ORE: the examples and XSD are synced to v1.8.17.0, and the engine package is vendored beside v1.8.16.0.

23 hotfix stories closed this sprint. 11 of them fixed Windows or MSVC builds, and two fixed gcc-only diagnostics. Continuous Windows was red from 2026-09-04 to 2026-09-17. Most of these defects compiled on Linux clang and failed on another compiler after the merge.

• High throughput: 316 PRs merged and 80 stories closed DONE.
• The drift method worked. Each component followed the same steps and reached zero drift.
• PRs merged fast, with a median of 1.9 hours from open to merge.
• The close reset recorded every abandoned story with a reason, so sprint 26 starts from a clean board.

• The sprint ran 52 days against a 7-day plan. It did not close at the lull, so a second full sprint of work went into the same document.
• The mission did not change when the work moved to ores.web and TypeScript. The mission then described less than half of the work.
• 31 stories were STARTED at the close review, 10 of them with every task done. The documents did not show the real work in progress.
• 23 hotfixes. Cross-compiler failures were found by the scheduled CI runs, after the merge.
• Many approaches to the codegen problem ran at the same time, and none of them finished.

• Close the sprint at day 7. A lull ends a sprint; it does not stretch it.
• Change the mission when the direction changes, or open a new sprint.
• Follow one order: codegen sync and drift for each module, then user journeys, then UX.
• Run a gcc or MSVC build before a merge that touches CMake, headers or compiler flags.
• Close a story when its last task closes.

Dual-axis bar chart. PRs (left axis) and commits (right axis) per day. A high commits-to-PR ratio may indicate scope creep.

Lines added (green) and deleted (red) per day. Building work produces mostly additions; refactoring produces a mix.

Hours from PR open to merge, one bar per PR. Long bars indicate review bottlenecks.

Line chart tracking stories marked DONE during the sprint. Steady upward slope is healthy; plateauing signals a stall.