Core Laravel Package

Technical Evaluation

Architecture fit. stochastix/core is a Symfony-based backtesting framework rather than a Laravel package. It targets a fundamentally different runtime profile than a typical Laravel request/response application: backtests are long-running, CPU-bound batch jobs over historical time-series data. It therefore does not "fit" the Laravel application layer — it fits behind it, as a domain engine consumed by queue workers, Artisan commands, or a dedicated CLI service. Treating it as an in-request dependency is the primary architectural anti-pattern to avoid.

Integration feasibility. Technically viable but non-trivial. Laravel composes Symfony components (Console, HttpFoundation, Process, etc.), so shared-library conflicts are the concrete risk rather than conceptual incompatibility. The real integration surface is: (1) how market data is fed in (files, DB, API), (2) how results are persisted (Doctrine vs. Eloquent assumptions), (3) how the backtest is invoked (Symfony Console vs. Laravel Artisan). Each of these is likely to require an adapter layer. Expect to write glue code, not to composer require and go.

Technical risk. High, concentrated in three areas:

• Maturity signal. 14 stars, 0 dependents, and a 0.13 score indicate a pre-adoption, single-maintainer project with no observable production usage. Bus factor is effectively 1. There is no ecosystem evidence of correctness under real workloads.
• Correctness risk is business-critical. Backtesting engines are only valuable if they are right. Look-ahead bias, survivorship bias, commission/slippage modeling, and data-alignment bugs are silent — they produce plausible-looking results that are wrong. For a financial decision-support use case, an unvalidated engine is a liability, not an asset.
• API stability. At this maturity level, expect breaking changes. Any deep coupling becomes a maintenance tax on every upgrade.

Key questions.

• What is the maintainer's commitment and release cadence? Is there a roadmap, changelog, or CI/test coverage we can inspect?
• Which Symfony component versions are pinned, and do they conflict with our Laravel/Symfony baseline?
• What are the supported data-source and instrument types (equities, FX, crypto, derivatives)? Does it model commissions, slippage, and corporate actions?
• Is there a documented, reproducible validation suite — or reference results we can reconcile against a known-good engine?
• Does it assume Doctrine entities and a specific persistence layer?
• What is the license posture (MIT is fine) and are there any transitive dependencies with concerning maintenance?

Integration Approach

Stack fit. Poor on the surface, workable with deliberate isolation. The correct pattern is anti-corruption layer: define our 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 converts an uncomfortable dependency into a swappable one and is the difference between a two-week spike and a two-quarter lock-in.

Migration path. Do not migrate anything into the main application. Instead:

1. Isolated spike — a standalone Composer project (or a dedicated service directory) proving a single end-to-end backtest against our own historical dataset.
2. Correctness reconciliation — run the same strategy and dataset through a second implementation (a vectorized Python backtest, or a hand-computed reference) and diff the equity curves. This is the gate that matters.
3. Adapter + worker — wrap in the ACL interface, invoke from a queued job or Artisan command, persist results to our own schema.
4. Optional promotion — only if the spike clears correctness and the maintainer signals stability.

Compatibility. Pin an exact version. Audit composer why-not against our Laravel/Symfony constraints before committing; if versions collide, the fallback is running the engine in a separate containerized CLI with its own dependency tree, communicating via a job payload and a results table. That fallback is cheap to build and removes the dependency-conflict risk entirely — recommend designing for it from day one.

Sequencing. (1) Dependency and license audit → (2) isolated correctness spike → (3) go/no-go gate on reconciliation → (4) ACL adapter + queue integration → (5) internal documentation and a fork-and-patch contingency. Budget the spike as discovery, not delivery; the most likely outcome of step 2 is "promising but needs our own patches," which is a decision point, not a failure.

Operational Impact

Maintenance. This is the dominant cost. With one maintainer and no downstream dependents, we should assume we will eventually own the code. Plan for a vendored fork from the outset: mirror the repo, apply patches locally, and keep a diff log. Do not build a workflow that requires upstream fixes to unblock us. Assign explicit internal ownership — an unowned backtest engine that silently drifts from reality is worse than none.

Support. No commercial support, no SLA, no community to lean on for triage. Internal engineers must be able to read the source. Given a Symfony/PHP team this is realistic; given a team that is Laravel-only and framework-fluent rather than framework-internals-fluent, budget ramp-up time accordingly.

Scaling. Backtests scale with CPU and data volume, not with request concurrency. Isolate onto a dedicated queue with its own worker pool and resource limits so a large backtest cannot starve user-facing jobs. Watch memory: in-memory time-series over multi-year, multi-instrument datasets is the classic failure point. Persist intermediate results and design for resumable/segmented runs rather than assuming single-shot execution completes.

Failure modes.

• Silent numerical wrongness — the highest-severity failure; produces confident, incorrect outputs. Mitigate with reconciliation tests in CI, not one-off checks.
• Dependency drift — an upstream Symfony bump breaks the engine during a routine composer update. Mitigate by pinning and by isolating the dependency tree.
• Abandonment — repo goes quiet. Mitigate via fork contingency and a documented "we own this" assumption.
• Resource exhaustion — an unbounded backtest starves the queue or OOMs a worker. Mitigate with hard timeouts, memory caps, and input-size validation.
• Data-quality propagation — bad or misaligned historical data yields plausible garbage. Validate inputs at ingestion, not inside the engine.

Ramp-up. Expect 1–2 weeks for a competent PHP engineer to reach productive spike velocity, plus additional time for whoever owns long-term correctness to build real fluency in the engine's execution model. The learning curve is less about Laravel/Symfony and more about backtesting semantics — that is the expensive knowledge, and it does not come from the package's documentation. Recommend pairing the integration with someone who has quantitative finance background, or the correctness gate in the Integration Approach cannot be meaningfully evaluated.

Recommendation. Proceed to a time-boxed, isolated correctness spike only. Do not commit to production integration until the engine reconciles against an independent reference implementation. The licensing is permissive and the concept is sound, but the adoption signals (14 stars, 0 dependents, single maintainer) mean the burden of proof sits entirely with us, and the cost of being wrong — a silently inaccurate backtest driving a capital decision — is asymmetric.