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, charts, metrics tables, risk attribution, stationarity tests, a rolling walk-forward section, a forward Monte Carlo section including model disagreement, and an appendix. The workbook carries Cover, Portfolio Weights, Performance Metrics, Yearly Returns, Risk Attribution, Sharpe Inference, Correlation Matrix, Spectral Decomposition and Backtest sheets with embedded charts.
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 adds per-period weights and turnover sheets.
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 and the interval-scope disclosure. 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.
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
Reports are generated asynchronously and stored in object storage. Detail responses expose short-lived signed download links rather than public URLs. For Monte Carlo and first-class backtest runs the export is best effort: a failed export never turns a completed simulation into a failed run, 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.
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.