- Is stochastix/core actually a Laravel package?
- It is presented as the foundational Laravel package layer for Stochastix, providing shared service providers, configuration, and utilities, but the underlying engine is Symfony-based. It targets long-running, CPU-bound batch jobs over historical time-series data rather than a typical Laravel request/response flow. The practical conclusion is that it fits behind your Laravel application as a domain engine, not inside the application layer. Treating it as an in-request dependency is the main architectural anti-pattern to avoid.
- How do I install stochastix/core with Composer?
- Install it with composer require stochastix/core and pin an exact version rather than floating on a caret constraint. Before committing, run composer why-not against your Laravel and Symfony constraints to surface any collisions up front. Do not assume a require-and-go experience; expect to write glue code for data input, result persistence, and invocation. An isolated spike project or dedicated service directory is the safest first step.
- Which Laravel and Symfony versions work with stochastix/core, and will it conflict with my app?
- Laravel composes Symfony components such as Console, HttpFoundation, and Process, so shared-library version conflicts are the concrete risk rather than conceptual incompatibility. Inspect the pinned Symfony component versions in the package's composer.json and audit them with composer why-not against your own baseline before adopting. There is no published Laravel support matrix to rely on at this maturity level. If versions collide, the fallback is running the engine in a separate containerized CLI with its own dependency tree.
- Can I run a Stochastix backtest inside a Laravel controller or HTTP request?
- No, that is the primary architectural anti-pattern for this package. Backtests are long-running, CPU-bound batch workloads over historical data, which will exhaust request timeouts and worker capacity in a normal web request. Invoke the engine from a queued job, an Artisan command, or a dedicated CLI service instead. Your HTTP layer should only dispatch the job and read the persisted results.
- How do I integrate stochastix/core with Laravel Artisan commands and queue workers?
- Use an anti-corruption layer: define your own BacktestEngine interface in the Laravel domain, implement it with a StochastixAdapter, and never let stochastix/core types leak into controllers, models, or domain services. That single decision turns an uncomfortable dependency into a swappable one. Invoke the adapter from a queued job or Artisan command and persist results into your own schema. Keep the invocation path thin so upgrades stay cheap.
- How do I store backtest results in MySQL with Eloquent?
- The engine is likely to assume Doctrine-style entities and its own persistence layer, so do not expect Eloquent integration out of the box. Map its result objects to your own tables and models inside the adapter, keeping your schema authoritative. Treat Persistence as one of the three real integration surfaces, alongside data input and invocation. Confirm any Doctrine assumptions with the maintainer before designing your tables.
- What market data sources and instrument types does stochastix/core support?
- The available documentation does not specify supported data feeds or asset classes such as equities, FX, crypto, or derivatives. How market data is fed in, whether via files, a database, or an API, is one of the integration points most likely to require an adapter. Check the repository README and issue tracker, and ask the maintainer directly about instrument coverage and data alignment rules. Validate the format assumptions against your own historical dataset in a spike.
- Does stochastix/core model commissions, slippage, and corporate actions?
- This is not documented in the material available, so verify it in the source or with the maintainer before relying on any result. These modelling details matter because look-ahead bias, survivorship bias, and slippage errors are silent and produce plausible-looking but wrong equity curves. If commissions, slippage, or corporate actions are absent or incomplete, you will need to layer them on yourself. For financial decision support, an unvalidated cost model is a liability rather than an asset.
- Is stochastix/core production-ready and actively maintained?
- The signals are pre-adoption: roughly 14 stars, zero dependents, and a single-maintainer project with no observable production usage, so the bus factor is effectively one. Expect breaking changes at this maturity level and budget for them if you couple deeply. Before adopting, inspect the changelog, release cadence, roadmap, CI configuration, and test coverage. Keep the dependency isolated so you can replace it without a rewrite.
- How do I verify a backtest from stochastix/core is actually correct before using it?
- Run the same strategy and dataset through a second implementation, such as a vectorized Python backtest or a hand-computed reference, and diff the resulting equity curves. Treat that reconciliation as the gate that matters before any promotion into production. Start with a standalone spike proving one end-to-end backtest against your own historical data. Only after correctness is confirmed should you wrap the engine in the adapter and wire it to a queued job.