Skip to main content
This guide continues the two-actuator example in Schemas and configuration. Use its production URL, authentication, and Python helpers. The API fields follow the reference schema and client; the planar adapter is an illustrative application you supply.

Configure the acquisition stage

Create/configure once for a fresh run, not at every episode. Keep this Domain ID across compatible attempts.

Request one sequence

POST to https://rei-neuroadapt-api.reilabs.org/api/v1/domains/{domain_id}/trajectory/propose:
These numeric inputs illustrate the four-state/two-goal schema. In the runner, replace them with the actual reset observation and requested goal. The reference client consumes decision_id and actions from the response. actions is a nonempty matrix with one row per proposed command and action_dimensions columns. It also reads reference_state and reference_valid when applying an explicit geometric retargeting transform. An action proposal is not evidence that the action was executed.

Implement the application adapter

The following are application functions, not API endpoints: For this example, normalize each actuator command to [-1, 1]. Keep the physical mapping and 0.5-second hold duration fixed. Pad a proposal shorter than eight commands with neutral [0.0, 0.0] commands before execution. These are real applied commands and belong in the returned trace. Preserve the original proposal separately. Store physical commands alongside the native numeric coordinates so the actual applied operation is reconstructable.

Align the observation arrays

For T commands actually executed: The T/T+1 alignment is enforced by the runner pattern, not fully expressed by the JSON schema. Check it before sending. For an early physical stop, return only the executed prefix. Never append unexecuted proposal rows to make the array reach the configured horizon. If no command executed, do not send an empty or fabricated observation. Preserve the pending decision and use supported cancellation when appropriate. Keep invalid measurements separate from a valid physical attempt with a poor outcome.

Connect the loop

This code depends on the adapter hooks above and the request helper from the configuration guide. It supplies no task-solving controller or simulator.
The observation route is POST /domains/{domain_id}/trajectory/observe, relative to the production base. Do not send this body to generic Domain /feedback. Report neutral padding only when it actually executed. A safety stop takes precedence over completing the eight-slot window. Validate outcome range and direction in measure_outcome. json.dumps(..., allow_nan=False) in the shared transport rejects non-finite values before dispatch. If safety logic changes an action, retain both proposal and actual execution and the reason; do not claim the original proposal was executed unchanged.

Revisit an acquired context

The optional context workflow asks the learner for a retained acquisition reference:
Send it to POST /domains/{domain_id}/trajectory/context. The client reads response.request; when non-null, it uses request.record_id to restore the associated environment context and supplies that same ID as acquisition_reference in the next proposal. Maintain an authoritative native-record-ID to local-reset mapping. Record IDs are not guaranteed to equal attempt counters. If the mapping is unavailable, do not invent it. Ordinary reset sampling can continue without this optional context-revisit feature.

Continue

Stop acquisition at the application-owned budget boundary, reconcile pending work, and export a stable retained source for selection, deletion, and ordering. To use the acquired state directly, see Retained use and recovery.