Ponder/Decision models

Decision models

Preview · Requires a qualified exact model and runtime. A draft, guide or saved configuration does not establish execution or serving availability.

Train and score defined choices with a typed decision model.

A Decision model scores every allowed choice for defined questions about a structured state. The current implementation continues the released Bespoke-Nimble-9B adapter with its exact Qwen3.5-9B base and tokenizer. It is not a claim to reproduce a different company's decision-model architecture.

For example, score refund, troubleshoot and escalate for a support request. The output is a typed candidate distribution, not generated prose that happens to contain JSON.

Define a question

A task's input contains state and ordered questions. Keep training labels out of the input:

json

{
  "state": {"request": "The parcel arrived damaged", "daysSinceDelivery": 2},
  "questions": [{
    "id": "route",
    "type": "choice",
    "description": "Which support action should be taken?",
    "choices": [
      {"value": "refund", "description": "Issue a refund"},
      {"value": "troubleshoot", "description": "Continue troubleshooting"},
      {"value": "escalate", "description": "Ask a specialist to review"}
    ]
  }]
}

The expected output is the map {"route":"refund"}. Each training task needs one approved matching demonstration, in the training split. Dataset policy instructions must match state.instructions when present; the projection does not silently discard extra policy context.

Question IDs are distinct, start with a letter and contain letters, digits, underscores or hyphens. Use 1–8 questions and 2–26 distinct choices per question. Boolean questions use ordered false/true typed values; integer levels use strictly increasing integers. State is finite JSON, at most 64 KiB. The current runtime rejects prompts over its 2,048-token bound rather than truncating them.

Set up Train or Score

Choose New → Decision model in Experiments.

Tab	Train	Score
Model	Select Train and a compatible starting model.	Select Score and an exact compatible saved version.
Data / Questions	Choose the reviewed Decision batch.	Enter state and ordered questions without labels.
Settings	Steps, learning rate and prompt limit; expert parameters in Advanced settings.	Forward-work and duration bounds.
Review	Prepare and approve actual optimization.	Review and approve the actual scoring request.

Creating a Decision draft is possible without a GPU. A trained saved Model requires actual successful optimization/export; an unrun draft is not one.

Review, run and recover

Use Review → Prepare review to resolve the exact inputs, compatible runtime and maximum spend. Inspect the retained preparation before approving Start. Opening the editor, changing tabs and saving a draft do not start paid compute. Preparing a run is separate from starting it.

If a response is lost, reopen the same experiment and retained execution before retrying. Preserve its operation identity and revision; creating a second run can duplicate work and charges. Use the existing refresh, retry or cancellation controls. Cancellation is a request: follow the execution through cleanup and inspect remaining capacity and funding before treating it as finished.

Runtime discovery is authoritative. A selectable action or saved configuration does not prove that a checkpoint/image/GPU combination is qualified. Unsupported combinations cannot start simply because sufficient credits are available.

Save and serve

After a successful execution with verified artifacts, choose Save Model. The saved version retains its exact base, modification and artifact identity. Saving is separate from allocating serving capacity. Open the saved Model, review compatible serving and approve activation explicitly. Use Stop and verify released capacity when finished.

Measure a baseline and candidate on the same held-out tasks and grader versions. Training loss, successful export and a working endpoint do not establish better answers. Keep runtime correctness and task quality as separate checks.

Read and use scores

Inspect all candidate logits/probabilities and the exact question/choice order. Probabilities are model-relative scores, not automatically calibrated truth or a guarantee that an action is safe. Test held-out states and distribution shift. A two-choice scoring request is not equivalent to sampling one chat answer.

Use the typed scoreDecisionModel operation with its exact saved version hash, request identity, input and limits. Do not replace unavailable typed scoring with a base-model chat response or partial generated-token log probabilities.

API, SDK and harness

Use compileDecisionExecution, prepareDecisionExecution and startDecisionExecution. CLI commands use training hosted-compile-decision, hosted-prepare-decision, hosted-start-decision and hosted-decision-execution. Use hosted-save-decision-model, hosted-control-decision-serving and hosted-score-decision for the saved version and typed scoring.

Use the official CLI with your configured account and workspace. Run openpond training --help and the selected command's help for the current request schema; start from the SDK's typed draft/request builders rather than inventing an unversioned JSON payload. Web, API, TypeScript/Python SDKs and the CLI retain the same preparation, execution and Model identities. Paid Start and serving activation require explicit approval; a harness should retain these identities for recovery.

View as Markdown