Features
Reports and Exports
Three workflows produce three report families: portfolio optimization, walk-forward backtesting, and forward Monte Carlo. Each has a dedicated PDF and a dedicated Excel workbook, because each answers a different question and a single combined document would bury two of them.
The three report families
Optimization
What the portfolio a method produced looks like. The PDF carries a cover, executive summary, cumulative return and drawdown charts, metrics tables, risk attribution, stationarity and cointegration tests, a section for each method and an appendix. A run with constraints adds a Constraint Attestation section. Walk-forward and Monte Carlo results are not repeated here: each has its own report. The workbook carries Cover, Portfolio Weights, Performance Metrics, Yearly Returns, Risk Attribution, Sharpe Inference, Correlation Matrix, Spectral Decomp, Backtest and Constraints sheets with embedded charts. The tab names here are the tab names in the file.
Walk-forward backtest
How the method behaved when it had to keep producing portfolios out of sample. The dedicated PDF has its own cover and run-information pages, parent and child identities, submitted configuration, frozen-input provenance, queue and worker timing, a paired equity-versus-benchmark chart, headline and full metric suites, Sharpe inference with the recorded Deflated Sharpe trial scope, and every rebalance period. The dedicated workbook carries Cover, Equity, Metric Suite, Sharpe Inference, Periods, Weights, Turnover, Control Arm, Policy Comparison and Constraints sheets. Control Arm is separate from Metric Suite on purpose: its numbers are differences against a second arm, and mixing them into a sheet of single-arm metrics invites a reader to subtract the wrong pair.
When the backtest re-optimizes less often than it rebalances, both covers state the re-optimize frequency. Each period then shows whether it refit, the reason, the date of the fit its target came from, and the drifted turnover it actually traded. The Turnover sheet and the PDF turnover chart add the drifted trade. A default backtest renders as before.
Both state on the cover that every number comes from the hold windows only, and that a walk-forward result is one realized historical path rather than a distribution. A run without a rolling backtest produces no workbook, which is reported as not applicable rather than as a failure.
Monte Carlo
The forward distribution. The PDF renders the goal ladder, the annualized return distribution, per-path risk metric quantiles, annual goal attainment, the metric suite, cost attribution, the model disagreement, parameter-uncertainty and calibration-window disclosures, and the interval-scope disclosure. Every number in it is conditional on the selected generator, the frozen optimizer-time inputs, the effective configuration, the engine version and the seed, and the Assumptions sheet of the workbook states this. The workbook carries cover, distribution, metric suite, cost attribution, wealth fan, goal ladder, weight paths, scenarios and assumptions sheets.
A run with the paired frozen-weight control arm carries the same set for that arm, plus two-arm histograms on shared bin edges, so every distribution can be shown for both arms on the same axes. Showing both arms is not a claim that either weight rule performs better.
One run-information header, built once
Every run carries a run_information header assembled once by the engine. The results page, the PDF, the Excel export and the MCP tools all read that single block, so they cannot drift apart by each assembling their own version of the same facts.
| Run identity | Simulation or backtest run id, and the parent optimization run id |
| Method | The parent optimization method whose weights are being carried forward |
| Generator | The selected return process, for Monte Carlo runs |
| Rebalance policy | Frequency, mode, and the re-optimization grid where it differs |
| Horizon and scale | Horizon in years, path count, asset count |
| Calibration window | A closed start and end date pair, not a duration |
| Risk-free benchmark | The resolved rate and where it came from, or an explicit unavailable reason |
| Provenance | Engine version and seed |
| Timing | Observed queue wait and worker execution time, reported separately |
Every field comes from the echoed immutable configuration and the frozen input panel, never from the wall clock. A replay therefore renders an identical header. Queue wait and worker execution time are reported as observations, not as a service level.
Metric parity across surfaces
The optimizer, the backtester and Monte Carlo report the same headline metric suite under the same key names. The naming is reconciled structurally rather than clerically: the backtest suite is produced by the same function the optimizer runs, so a metric renamed in one place is renamed in both and the two cannot silently diverge.
The suite covers CAGR, volatility, Sharpe, Sortino, Calmar, maximum drawdown, Ulcer index, VaR and CVaR, skewness and kurtosis, benchmark beta, alpha, tracking error and information ratio, plus the full Sharpe inference payload: Probabilistic Sharpe, minimum track record length, the Sharpe confidence interval, the Sharpe Stability Ratio and the Deflated Sharpe Ratio.
Monte Carlo carries the same suite computed per path and reported as the distribution across paths, because a Sharpe on pooled paths is the Sharpe of an average no investor can hold. Two members are deliberately absent there, with machine-readable reasons rather than blank cells: no search happened across simulated paths, so there is nothing for the Deflated Sharpe to deflate for, and rolling-Sharpe variation on a simulated path measures the generator rather than the portfolio.
Every surface also names the benchmark series a run used: the price index, or the Total Return Index, which counts the dividends of the index companies. Against a price index, alpha and the information ratio are overstated by about the index dividend yield, and each surface marks those two values.
What the PDF renders, and what it leaves to the screen
Which artifact blocks the PDF renders and which it deliberately leaves to the interactive surface is a checked manifest, not a paragraph of intent. A test generates a real run and fails if any block has no parity decision recorded, so adding a block without deciding what the report does with it cannot pass silently.
The rule behind the omissions is a single property applied consistently: a block whose value is reading a shape over time or over a dense grid belongs to a chart, and a block that answers a question with a number belongs in the report. A wealth fan across 40 years of monthly points is the former. A goal probability with its confidence band is the latter.
Delivery and access
All three PDFs are generated asynchronously on request and stored in object storage. Each workbook is built as soon as its run completes. Detail responses expose short-lived signed download links rather than public URLs. Every workbook is best effort: a failed export never turns a completed run into a failed one, and the run detail says which artifacts exist.
Free-tier reports are watermarked. Every report that prints a Deflated Sharpe Ratio prints its trial-count basis on the same page, rather than in a footnote a reader will not reach. Every report and workbook, on every plan, closes with the same sentence: “Not investment advice. Past performance is not indicative of future results.”
The same files are reachable over MCP through get_report_files, get_run_artifacts and request_pdf_report. See AI assistants for the full tool surface.
The deterministic golden fixture
One cross-renderer artifact is generated by the real engine with fixed data and seeds, and its canonical JSON digest is pinned in both the backend generator and the frontend contract suite.
The backend sends that exact generated payload through the complete PDF assembly path, while the frontend sends the checked-in bytes through its TypeScript data preparation and DOM charts. Schema or numeric drift therefore requires an explicit fixture regeneration, and the two renderers cannot end up testing different examples under the same name.
Related pages
Rolling walk-forward backtest covers the workflow behind the backtest reports. Monte Carlo output statistics defines each reported block, and the results API documents how to fetch artifacts programmatically.