Docs · Build

Read the result

What comes back, what each field means, and how to turn it into a plan someone can approve.

Statuses

status	Meaning
`grounding`	Your economics are being compiled and your history replayed through them. Minutes.
`queued`	Waiting for the compute queue.
`processing`	Fitting and predicting. A `runner` field carries progress.
`done`	The plan is ready.
`failed`	Terminal — stop polling and read `error_code` and `feedback`.

A done result

GET /result/{id}

{
  "status": "done",
  "menu": [
    {"key": "A001", "menu": 0, "T": 0, "qty": 3.0, "profit": 42.7},
    {"key": "A002", "menu": 0, "T": 0, "qty": 0.0, "profit": -1.2}
  ],
  "n_selected": 1,
  "predicted_profit_sum": 42.7,
  "confidence_correction": 0.0,
  "confidence_sweep": [
    {"correction": -0.1, "applied": false, "n_keys_positive": 66, "total_predicted_profit": 205.7},
    {"correction": 0.0, "applied": true, "...": "one entry per correction"}
  ]
}

Field	Meaning
`menu[].qty`	The size P34 selected for that option. `0` = do not trade.
`menu[].profit`	Predicted total profit of the option at that size.
`n_selected`	How many options were selected.
`predicted_profit_sum`	The plan's predicted profit, calibrated as a sum.
`confidence_*`, `confidence_sweep`	The threshold that was applied and what other corrections would have selected.

From result to plan

Take the rows with qty > 0 together: they are one plan. A key missing from menu means pass, exactly like qty = 0.
Check the plan against your own limits — cash, storage, account rules.
Have a person approve it, at least until a shadow test has earned trust.
Execute through your own systems: P34 places no orders.
Log what happens. Those sales are next time's history.

Predicted is not realized

predicted_profit_sum is a forecast, not a result. Judge the model on what the plan realized, over several decisions.

Tuning selectivity

confidence_correction (between −1 and 1) shifts the calibrated threshold: positive for fewer, surer picks; negative for more. Typical values are ±0.1; the result reports the value it applied. Read the confidence_sweep before paying for another fit with a different value: it shows what each setting would have selected.

When a fit fails

A failed result

{
  "status": "failed",
  "failed_stage": "grounding",
  "error_code": "grounding_input_needs_review",
  "error": "The grounding step could not interpret the supplied data reliably. …",
  "feedback": "401 of your 3,639 settled positions carry a charge that is on none of your feeds …",
  "billing": {"grounding_tokens": 0.42, "failure_kind": "input"}
}

error_code	What to do
`grounding_input_needs_review`	Do what `feedback` says — it names the columns and numbers that disagree.
`insufficient_historical_data`	Add more past decision moments with realized outcomes.
`historical_data_too_large`	Trim older history, keeping whole menus.
`grounding_service_failed`, `model_fit_failed`	Ours. Resubmit; contact support with the session id if it repeats. Not charged.
`fit_canceled`	Canceled before it finished. Submit again when ready.

billing.failure_kind says whose problem it was: input (charged for the grounding work done) or infra (not charged). After three identical input failures the service returns the last diagnosis instead of running the same request again.

Mock results are not predictions

An input test returns the real shape with placeholder numbers, marked "mock": true with a mock_note. Never act on one.

Go deeper on GitHub

Result statuses · When a fit fails · Skill: interpret results

The authoritative contract is the live API root, api.hyperc.com/v1/; field-by-field reference in P34-API-DOCS. Docs checked against the service on 6 October 2026.