Story: Extract stochastic process math from ores.synthetic into ores.analytics.quant
Table of Contents
This page documents a story in Sprint 23. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
ores.synthetic was originally built by mixing two concerns: the "pure" quant/maths content around stochastic processes and engines, and the synthetic-data-generation machinery that drives them. ores.analytics.quant now exists as the home for dependency-light, thoroughly-tested maths code. This story moves the stochastic-process code out of ores.synthetic and into ores.analytics.quant, backfilling test coverage (currently zero) and documenting each addition in the component's modeling docs, so ores.synthetic retains only generation/orchestration concerns and the maths lives where it can be reused (e.g. by a future calibration service) without pulling in the synthetic service's heavier dependencies.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 23 |
| Now | All 4 tasks done. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-07-12 |
Acceptance
IStochasticProcessmoves from ores.marketdata.api to ores.analytics.quant (header-only, zero dependencies); ores.marketdata.api and ores.synthetic update their includes accordingly.gmm_process,arithmetic_gmm_process,ou_process, andprocess_factorymove from ores.synthetic.service into ores.analytics.quant, namespaced under ores::analytics::quant (or its existing domain/service split).process_parameter_validationmoves from ores.synthetic.api into ores.analytics.quant.- ores.synthetic (service + api) is updated to consume the moved types from ores.analytics.quant instead of its own copies; no dead code left behind.
- Each moved unit has thorough Catch2 tests ported/added in ores.analytics.quant/tests (none of these five units have any test coverage today) — construction, degenerate/edge parameters, and statistical sanity of next()/current() behaviour.
- ores.analytics.quant's component_overview.org and PlantUML diagram are updated to document the additions.
- Full build and test suite (ores.synthetic, ores.analytics.quant, ores.marketdata) pass after the move.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Move IStochasticProcess interface into ores.analytics.quant | DONE | 2026-07-12 | 2026-07-12 | Relocate the header-only IStochasticProcess interface from ores.marketdata.api to ores.analytics.quant, update all includes/namespaces, keep the build green. |
| Move GMM, arithmetic GMM, and OU processes into ores.analytics.quant | DONE | 2026-07-12 | 2026-07-12 | Relocate gmm_process, arithmetic_gmm_process, and ou_process from ores.synthetic.service into ores.analytics.quant, with thorough new Catch2 tests since none exist today. |
| Move process_factory and process_parameter_validation into ores.analytics.quant | DONE | 2026-07-12 | 2026-07-12 | Relocate process_factory (service) and process_parameter_validation (api) into ores.analytics.quant, updating ores.synthetic and the Qt client's include paths, with thorough new tests. |
| Document the moved process classes in ores.analytics.quant component docs | DONE | 2026-07-12 | 2026-07-12 | Update ores.analytics.quant/modeling/component_overview.org and the PlantUML class diagram to document IStochasticProcess, the three process implementations, process_factory, and process_parameter_validation. |
Decisions
- IStochasticProcess is moved into ores.analytics.quant rather than linking analytics.quant against ores.marketdata.api or duplicating the interface. It is a pure, zero-dependency virtual interface; linking the whole of ores.marketdata.api would pull in ores.platform.lib transitively and break analytics.quant's deliberately minimal dependency footprint. If ores.marketdata.api needs the type later it can depend on ores.analytics.quant instead.
- process_factory's diagnostic warning log on an unrecognised process_type (BOOST_LOG_SEV) is dropped rather than pulling ores.logging.lib into ores.analytics.quant — ores.logging depends on ores.platform.lib, the same footprint concern as above, and no other unit in the component logs. Callers that need that diagnostic can log around the call.
Out of scope
- No behavioural change to the process maths themselves (no recalibration, no new engine types) — this is a pure relocation-plus-tests story.
- No change to the synthetic data-generation pipeline's public behaviour (dataset/account/catalog generators, messaging, repositories stay in ores.synthetic).