Move generic quant primitives to ores.analytics
Table of Contents
This page is a capture in the deferred bucket of the product backlog — a pre-sprint idea, not yet pulled into a sprint as a story.
What
While building the synthetic market-data generation feature we added
generic quant primitives to ores.synthetic — notably the stochastic
price processes under
projects/ores.synthetic/service/src/processes/ (gmm_process,
arithmetic_gmm_process, the process_factory, and the
IStochasticProcess abstraction currently in
projects/ores.marketdata.api/domain/i_stochastic_process.hpp). These
are general quantitative building blocks (Gaussian mixture models,
Brownian-motion engines, RNG-driven path generation) that are not
specific to synthetic-data generation. Audit ores.synthetic (and
ores.marketdata) for such quant code and relocate it to
ores.analytics, leaving ores.synthetic to depend on
ores.analytics for the maths and keep only the data-generation
orchestration (feed configs, GMM component persistence, the simulate
handler wiring).
Why
ores.analytics is the designated home for quantitative/analytical
code; ores.synthetic is specifically about generating synthetic
datasets. Keeping reusable quant primitives in ores.synthetic buries
them where other components (pricing, risk, scenario analytics) cannot
discover or reuse them, and blurs the component boundaries. Moving them
to ores.analytics makes the maths reusable across the system and keeps
each component's responsibility crisp.
References
projects/ores.synthetic/service/src/processes/gmm_process.{hpp,cpp}— GMM stochastic price process.projects/ores.synthetic/service/src/processes/arithmetic_gmm_process.{hpp,cpp}— arithmetic Brownian variant.projects/ores.synthetic/service/src/process_factory.{hpp,cpp}— engine factory.projects/ores.marketdata.api/domain/i_stochastic_process.hpp— the process abstraction.