Skip to main content
Use this Python standard-library client to fit an initial Adapt-1 value model, stage a candidate, inspect predictions, and request promotion with your application’s measured outcomes. You supply the task’s configuration, observations, fitting options, and evaluation data as JSON files. The example uses target or outcome observations. It warm-starts the later candidate from the installed model. Native continuation rows have a separate installation restriction; this example does not demonstrate that installation path.
Before integration, check /version at the API host root and confirm the response shapes for your deployment. The client checks training.request_id, the installed and candidate model hashes, numeric predictions, and evaluator.model_sha256. It stops when these checks fail.

Prepare your environment and files

Create a fresh Domain using the Domain setup workflow, then set these environment variables. Use the same dedicated Domain for all three commands. Prepare these files from your application. The JSON files contain the object or array described below, without a session_id wrapper. Use informative observations and a suitable episode split. Four rows is the minimum for the explicit observation_ids array used here; it does not guarantee that a model passes validation. Choose a compatible representation and model and retain the same input meanings across the workflow. The client validates input-file roles, IDs, supervision, finite numeric values, and request sizes before writes. Deployment-specific schema and model checks still apply. Observation requests contain at most 50 rows and use a 900 KiB client margin. The 60-second request timeout and default 600-second fit wait are client settings, not service limits.

Save the Python client

Save the following code as value_client.py. Each command requires a new output directory. It saves request bodies, response receipts, and the last inspected state, without recording the authorization header. These local files contain your application data; redact them before sharing. It sends each mutation once and stops on a refusal or uncertain response.
value_client.py

Run the workflow

1

Fit and inspect the first model

Configure the fresh Domain, upload the selected observations, fit with warm_start: false and install: true, and predict on your probe inputs.
The command checks that the reported job matches its generated request_id, completed as trained, and installed a model. Inspect run-initial/last-state.json and run-initial/probe-results.json before preparing another fit.
2

Stage a candidate and compare predictions

Supply the complete earlier-plus-new observation selection. The client replays the rows unchanged, checks admission counts, and sends their IDs explicitly to training. It uses warm_start: true, warm_start_source: installed, the incumbent hash, and install: false.
The command requires a completed candidate result with the incumbent unchanged. It predicts with both models on the same inputs, checks the returned hashes and prediction counts, and saves model-pair.json and probe-results.json.Compare the probe predictions to identify functional changes. A changed SHA alone does not establish changed predictions or better decisions.
3

Measure application outcomes and request promotion

Evaluate the saved incumbent and candidate on paired application cases under the same conditions. Use the saved hashes to bind each evaluation. Keep the actual outcomes and the mapping from outcomes to utility in your application record.Write paired-cases.json as an object with the following fields:This is a client file format. The script maps those hashes to the API’s expected_current_model_sha256 and expected_model_sha256 fields. Supply finite utility values in [0,1]. The example chooses minimum_cases: 16 and required_improvement: 0; the server still decides whether the canary demonstrates sufficient improvement. Prediction values from the previous step are not measured application outcomes.
The command verifies that the current model pair still matches the evaluated pair, submits the canary once, and reads state back to confirm that the candidate became the installed model. Follow promotion checks when selecting your application measure and interpreting a refusal.

Handle a stopped command

Inspect the output directory before another mutation. last-response.json preserves the most recent response or transport failure, and last-state.json preserves the latest successful state inspection. The numbered training request file records the generated request_id. Keep the selected observations, actual model pair, and evaluation outcomes together when continuing to another candidate round. The explicit promotion command does not implement the separate registered application_cases and application_outcomes automatic-adoption flow.