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.

{
  "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:

{
  "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 for aliases, end-date handling and provider limits, and Build a quantile strategy for valid backtest requests and the separate averaged-ladder methodology.

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.