> ## Documentation Index > Fetch the complete documentation index at: https://quantura.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Quantura Forecast — asynchronous ensemble API > Configure five approved time-series models, custom quantiles, and durable asynchronous execution. # Quantura Forecast The default **Forecast** workspace at `/forecasting` uses this asynchronous ensemble service. Configure the models and click **Run forecast** once; progress, final quantiles, and CSV/JSON downloads appear in the same panel. Models and custom quantiles are in Advanced settings; there is one Run forecast button. Previously saved legacy forecasts remain readable; their compatibility endpoints are unchanged. ## Free website, local-time controls and CSV uploads Guests can run available models and download their results, subject to fair-use limits and provider availability. Sign in to save to My Requests. The website prepares a single-use, 15-minute HttpOnly ownership cookie before sign-in so a guest forecast can also be saved to an existing account. API keys and collaborator resources still require account authentication, token scopes and current workspace permissions. Existing billing records are not deleted. Choose **Calendar date and time** for Data cutoff or Forecast until. Times are displayed in your device timezone and sent as explicit UTC instants in `history_cutoff_at` and `prediction_end_at`. There is no arbitrary 90-day forecast cutoff; available history still depends on the selected provider. Alternatively choose a duration or offset in days, hours or minutes. The backend converts the end time to complete future periods after the last input observation; daily NYSE requests use actual exchange sessions within the calendar window. Quotas and model horizon limits apply. Choose **Upload your own CSV** to parse a CSV of at most 2 MB / 10,000 rows. Select the timestamp and numeric target columns and observed interval. At least 40 unique valid rows are required for this upload workflow. ISO dates are UTC dates; minute-resolution local date-times use your device timezone; timestamps with seconds need an explicit offset. The upload is sent through the existing immutable inline-series API, not a new public file URL. Missing dates or values fail validation, and duplicate timestamps deterministically retain the last supplied value. Advanced settings offers approved, revision-pinned `toto_variant` values `4m`, `22m`, `313m`, `1b`, `2.5b`, from smallest to largest. The default is `4m`. Arbitrary checkpoint IDs are rejected. Larger models require more memory/startup time; TimesFM's separate access and commercial-license checks still apply. ## First-row observed quote When available, the chart marks the completed observation at the first predicted timestamp. It uses the same selected-side target as the historical chart. Missing observations are never replaced by later or forward-filled quotes. The marker is a price observation, not a buy/sell recommendation; if the forecast finished after that quote, it is labelled retrospective. Daily stock charts align closes by exchange session date, while intraday bars use completed interval timestamps. Recent minute closes are separate from final daily closes; today's daily candle is not treated as final. Source, price adjustment, session and feed are retained for overlays and refreshed requests. Calendar cutoffs are validated against the current clock at submission, not the time the page was opened. Quantura's ensemble supports these stable model identifiers: * `prophet` — Meta Prophet * `toto` — Datadog Toto 2.0 (4M by default; larger approved variants are selectable) * `granite` — IBM Granite PatchTST-FM-r2 * `chronos` — Amazon Chronos-2 * `timesfm` — Google TimesFM 3.0 At least one model must be enabled and at least one enabled weight must be positive. The backend normalizes weights independently for every quantile after excluding models that cannot produce that quantile. ## Quantile support Q Forecast and Q Screener present quantile values without buy/sell labels. The above/below P01 and P99 screener filters compare the displayed close with the published quantile, just like the P10/P50/P90 filters. Previously saved historical searches remain readable, but the website no longer starts new trade-signal searches. Prophet, Granite, and Chronos participate in requested tail quantiles when supported by their runtime. Toto and TimesFM provide native P10 through P90 quantiles and may interpolate only inside that interval. Quantura never extrapolates P01 or P99 from those bounded heads. After ensembling, deterministic monotonic rearrangement guarantees non-crossing requested quantiles. ## Durable lifecycle 1. The API validates permissions, plan, model capabilities, source data, and configuration. 2. It snapshots the authorized input and returns HTTP `202`. 3. A private worker claims the job by identifier and runs models sequentially. 4. The UI or client polls job status. 5. The completed response returns only final ensemble rows and effective weights by quantile. ## Forecast completion and ML metrics A request runs **only the requested forecast**, using all selected historical inputs. It does not withhold rows, start a second historical forecast, or wait for future prices before publishing its result. **Reproduce saved configuration** also runs only that forecast. No automatic historical-validation pass is added. MAE, RMSE, sMAPE and average weighted quantile loss describe this request's predictions only when observed prices for the **same prediction timestamps** are available after publication. Earlier training values cannot be paired with later predictions just to produce a score. No missing outcomes or accuracy scores are fabricated. Without P50, point-error metrics are undefined; weighted quantile loss is undefined when matched actual values are all zero. sMAPE uses a ratio internally and displays as a percentage; zero/zero contributes zero. Older immutable results may retain `historical_validation`, which described a **separate** historical forecast. This compatibility field is omitted from the normal quality panel, not presented as accuracy for the requested future forecast. An old queued policy does not cause the current worker to repeat validation. Reproduction creates a new job from the original input snapshot, stored configuration, and pinned model checkpoints while re-evaluating current authorization and license gates. ## TimesFM licensing Hugging Face repository access and commercial production rights are separate conditions. TimesFM is unavailable to public production users unless the server explicitly records commercial licensing. Internal non-commercial evaluation requires a separate explicit flag and is labeled evaluation-only. ## Select live games or paste a market link On Forecast, select a game in Screener or paste an HTTPS `polymarket.us` or `kalshi.com` event/market link in market search. Select the intended team/side and use the single **Run forecast** action. Kalshi YES and NO are separate contracts: NO is not automatically another team's moneyline. Soccer draw outcomes remain explicit. In **Sports / Prediction Markets**, use **Download from a market link**, choose the side(s), date range and interval, preview, then download CSV or JSON. Resolved markets can be downloaded or analyzed in explicitly labeled historical replay mode, not presented as new prospective forecasts. ### Historical cutoff and chart controls **Data cutoff** defaults to latest data. Choose minutes, hours, or days ago to exclude newer observations **before** selecting up to 500 inputs. The API accepts top-level `history_lag_minutes` (hours × 60 or days × 1440); it resolves the cutoff once to a stored UTC minute. An older cutoff can still fail if the provider no longer has that history. For example, use `history_lag_minutes: 30` and `prediction_length: 60` with `1min` data. Forecast timestamps begin after the last actual input, so gaps can shorten the part extending past now. ### Pregame, in-game and history lookback **Last N observations** controls `source.limit` (2–500 in the website; default 500), separately from elapsed time. The server applies cutoff and history filters first, then selects the latest N genuine bars. Fewer bars are used when unavailable; gaps are not filled. The immutable source stores the limit, and refresh/preset reuse preserves it. Individual enabled-model minimums still apply. Workspace datasets retain their existing complete-dataset workflow. Saved presets return these reusable settings under `configuration.history_controls` (`limit`, `history_phase`, `history_lookback_minutes`, and `history_lag_minutes` where applicable). Loading a preset restores these controls without changing the selected market or granting dataset access. Presets do not store historical rows or source-resource identifiers. Prediction-market sources accept `history_phase: "auto" | "both" | "pregame" | "in_game"`. The website defaults to `auto`: use pregame plus in-game until 32 elapsed minutes after provider-confirmed game start, then in-game only. Auto is evaluated at the input cutoff for point-in-time requests; missing start metadata keeps auto on both. Existing API clients omitting the field retain `both`. They also accept `history_lookback_minutes` (0–129600, default 0). Zero imposes no additional time restriction; 60 restricts input to the last hour, not 500 fabricated rows. `source.limit` applies afterward. For pregame, lookback ends at the earlier of game start and input cutoff. Game start is resolved from provider metadata, never trusted from client input. Unknown start times reject phase-specific requests. ```json theme={null} { "type": "prediction_market", "provider": "polymarket_us", "symbol": "MARKET_SLUG_FROM_SEARCH", "contract_id": "SIDE_ID_FROM_SEARCH", "frequency": "1min", "history_phase": "in_game", "history_lookback_minutes": 60 } ``` Polymarket pregame and in-game custom timestamp ranges are downloaded separately and joined by original timestamps. Genuine flat windows and long unchanged stretches are allowed for forecasting, with a low-information warning. Repeated display quotes are not separate trades. Missing values are not invented, and no artificial price variation is added. Successful inference is not proof of predictive skill. `source.history_quality` records input counts, pregame/in-game counts, price-change count, longest/trailing unchanged duration, `flat_window` and `low_information`. The legacy `forecast_blocked` field remains false for flatness. Existing immutable forecasts remain unchanged. Website, backtests and paper workers permit genuine flat windows. New results must not be mixed silently with earlier corpus versions. Ticker sources accept `frequency: "1Day" | "1Hour" | "1Min"`, subject to provider availability. Intraday forecasts use frequency periods; daily NYSE forecasts can use trading sessions. Cutoff units and data frequency are independent. The existing historical export endpoint `/api/sports/prediction-markets/export` also accepts `history_phase` and `history_lookback_minutes`. Its legacy `pregameOnly` parameter remains supported when `history_phase` is absent. Original rows remain downloadable, including unchanged prices. These runs are labeled **Historical replay**: generated now, not predictions published before the already-known outcomes. The chart overlays available actual observations after the cutoff, then continues updating. Live metrics exclude observations known before the new forecast completed. Reproducing a saved forecast retains its original input snapshot; **Refresh latest data & forecast** intentionally returns to current data. For minute/intraday markets, the chart initially shows the latest hour plus the forecast horizon. **Latest 60 minutes + forecast** resets the view; automatic observation updates preserve manual zoom. P10 and P90 appear as explicit dashed lines when requested. Daily stock charts retain their broader history. Advanced settings has a keyboard-accessible help dialog. Dataset frequency is configurable only for uploaded datasets; provider series use their selected interval. Search uses provider-supplied team names and event titles. For example, the Oklahoma–Michigan CFB moneyline displays **Oklahoma Sooners** and **Michigan Wolverines**, preserving Polymarket's original contract IDs. Kalshi YES/NO sides retain their actual proposition and are never relabeled as an assumed opposing team. Market lookup uses bounded, short-lived server caches; it is not an exhaustive global index. A Kalshi “Started · open” badge is inferred from official game start and open-market status, not a live score feed. Direct links resolve against the provider even when a market is outside the discovery window. Polymarket.com links are not interchangeable with Polymarket US. ### Prediction-market forecast request The authenticated ensemble endpoint accepts this source alongside ticker, workspace dataset, and programmatic series sources: ```json theme={null} { "source": { "type": "prediction_market", "provider": "kalshi", "symbol": "PROVIDER_MARKET_TICKER", "contract_id": "PROVIDER_MARKET_TICKER:yes", "frequency": "1min" }, "prediction_length": 30, "horizon_mode": "frequency_periods", "transform": "logit", "quantiles": [0.01, 0.1, 0.5, 0.9, 0.99], "models": { "prophet": { "enabled": true, "weight": 1 } } } ``` Replace identifiers with actual lookup results. History and contract identity are verified server-side; callers cannot supply arbitrary checkpoint IDs, URLs, prices or live-status claims. Existing workspace permissions, API scopes, plan limits and compute quotas apply. Use `1min`, `1h`, or `1D`. The server downloads up to 500 latest genuine observations, including available pregame observations; gaps no longer discard earlier history. Original timestamps are preserved, and missing intervals are **not** fabricated or forward-filled. Foundation models treat observations as ordered steps, so irregular elapsed-time gaps remain a disclosed limitation requiring validation. Kalshi uses the selected side's closing ask, including real book quotes in minutes without trades. Two observations permit execution, not a claim of reliable forecasting; individual models can still fail on short context under the selected failure policy. Job warnings report the actual history count. Prices use decimal probabilities, transformed with logit (epsilon `1e-6` only for transform stability), ensembled, then inverse-transformed. The output never substitutes a stock calendar for a game timeline. ## Refresh, share and compare actual observations Completed jobs return `input_row_count` and up to 500 original `history` rows. **Refresh latest data & forecast** downloads current history and creates a new immutable job (or reuses an identical cached input). **Reproduce saved configuration** intentionally retains the previous data snapshot. Both remain in **My Requests**; prior probabilities are not overwritten. **Copy workspace share link** copies the forecast URL. Recipients must sign in and currently have permission to read that workspace; this does not publish private datasets to the internet. `GET /api/v1/ensemble-forecasts/{forecast_id}/observations` requires `forecasts:read` plus current workspace/resource permission. Poll at most once per minute. It returns `rows`, `input_cutoff`, `observed_at`, `availability`, and `refresh_after_seconds`. This read-only operation overlays genuine later observations without re-running models or modifying the forecast. It is bounded to seven days after input cutoff. Uploaded immutable datasets have no automatic live provider. The chart uses the browser's timezone and AM/PM formatting. The summary compares the last downloaded quote against **end-of-horizon** quantiles and shows column averages across future steps. Any interpolated probability of finishing above the input quote is **model-implied**, not a validated win rate or a probability of profit after fees. Provider rate limits, missing history and unsupported side selections return explicit safe errors rather than a generic invalid-request message. Five registered models does not mean five participated: licensing, selected models, quantile capability and reported failures determine actual effective weights. Toto 2.0 requires **32 genuinely observed values** for its final context patch. Its capability response exposes `minimum_observed_context: 32`. A strict (`fail`) request with less history returns HTTP 422 `MODEL_CONTEXT_TOO_SHORT` before spending a compute quota. With explicit `renormalize`, eligible remaining models may execute and Toto is recorded as unavailable/failed, never as a participant. If no remaining model supports a requested quantile, the API returns 422 even under `renormalize`. Two observed values permit an attempt with compatible models; they cannot guarantee all five models participate. New forecasts use the immutable Toto checkpoint revision exposed as `checkpoint_revision` by model capabilities and saved in job `model_revisions`. Reproducing a saved forecast retains its original Toto variant and revision; changing the default does not rewrite its history. Research runs with only 1–12 minute observations still exclude Toto. A quote-by-quote study must have at least 32 genuine observations and separately validate event-time forecasting before claiming a five-model result. The larger Toto checkpoint increases memory use and loading time. Forecasts remain asynchronous, with sequential model execution on the CPU worker; a larger parameter count is not a claim of better forecasting accuracy. Context is a maximum number of **observed rows**, not necessarily elapsed minutes or calendar days when history contains gaps or closed sessions. The configured platform administrator can use the approved model set in their own workspaces under Research compute limits without changing their subscription. The ensemble API verifies the administrator's current, verified Firebase account against its server-side allowlist. Editable profile fields and client role labels cannot grant this access. API-key scopes, other workspace memberships, Viewer write restrictions, runtime availability and TimesFM's independent commercial-license/access gates still apply. ## Interval and strategy guides Forecast supports 1, 5, 15 and 30 minutes; 1 and 4 hours; daily; Monday UTC weekly; and calendar-month observations. `prediction_length` counts bars. Weekly/monthly inputs use only completed periods, and refresh retains the exact interval. See [Forecast intervals](/docs/forecast-frequencies) for aliases, end-date handling and provider limits, and [Build a quantile strategy](/docs/algorithmic-strategy) for valid backtest requests and the separate averaged-ladder methodology. [Historical forecasts](/docs/historical-forecasts) covers 120/180-day cutoffs, exact UTC dates, metadata validation and retained-history errors. Latest and historical requests use the same API; optional analytics metadata cannot block model configuration. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.