Evaluate an item

Evaluates one item against a decision: answers each question over the item’s state (each question sees only the values its reads paths name, such as state.message or state.order.customer.tier, nested as in the state), evaluates the aggregations, and returns every answer, every aggregation’s value and the result’s status, value and outcome, with version (the structure that ran: its hash, and its number once registered) and model (the setting’s model id, what answered, the setting’s revision and an opaque profile). Many items under one version are a run: POST /v1/decisions/{decision_id}/runs (the MCP tool create_run). The structure travels inline (questions, attributes, aggregations, result) or by hash in moonbounce.structure_hash, never both. The request is a superset of System One’s POST /v1/systemone: a plain System One request plus a result and the moonbounce object is a valid call. model asserts the decision’s model rather than choosing one (see model); choose the model with PUT /v1/decisions/{decision_id}/model (the MCP tool set_model). In an environment where nobody chose one, a decision runs on the deployment’s default model, stored as the setting’s revision 1 the first time a version is registered there: by POST /v1/decisions (the MCP tool register_decision), or by any evaluate, run or import_examples call that is not a dry run, inline or by hash. A call refused for its model or for a question the model cannot answer registers no version and stores no setting, and neither does an inline structure whose content is refused. Questions are for judgments a model makes; facts your app already knows, such as an order total or a refund count, belong in attributes and are compared exactly by rules conditions (gte, lt, is, in). Spends model calls and, with moonbounce.dry_run: true, stores no evaluation; otherwise stores an evaluation. Questions with the same reads share one System One call (cost.calls lists each). Fresh responses include recorded cost. A dry run stores only usage, returns a dry_ id and dry_run: true, and accepts and ignores Idempotency-Key: a retried dry run runs, and is billed, again. It does not register an inline structure (so version.number is null for a structure nobody registered), store a model setting or cache answers. Otherwise an inline structure is registered on first sight and the response follows the evaluation commit. A replay with the same Idempotency-Key returns the first result with the Idempotent-Replayed header. Each request has a 10 s budget; Prefer: wait=<seconds> shortens it. A body with items or cases is a 400 that points at the runs endpoint.