Native planning options and evaluator selection

Configure native Adapt-1 planning through the request’s options object and its request-level evaluator fields. Match the search limits to the application’s transition unit, then inspect the completed work and evaluator identity in the response. The integration guide describes HTTP graphs and streaming expansion.

Types and ranges below come from archived schema-version-5 build 0136121bd2cf9d4cdbcb114565c7e1ffb74c5a63. For nullable options without an explicit default in that schema, the null defaults below come from the 6 November 2026 report for build af6670b. A schema does not establish an undocumented pruning, extension, caching, or stopping algorithm. Those unresolved behaviors are identified below. The HTTP reference describes the captured request fields.

Select the evaluator

evaluator_source belongs at the request level, alongside relation, policy, root, and options.

Value	Selection
`domain_model`	Default evaluator source for the Domain path
`value_model`	Installed value learner
`value_candidate`	Value candidate under evaluation

Use expected_model_sha256 to bind the expected model identity where the planning contract supports it, and check the returned evaluator identity. Do not infer that a sequential sequential_q_mlp model can act as a frontier evaluator merely because it is installed in the Domain; that compatibility still needs confirmation. Completed successors can supply exact terminal_value scores, which take precedence over learned estimates. Keep a record of whether terminal scores or learned frontier values determined a choice. See value learning for fitting the value evaluator.

Bound search work

Option	Schema default	Use and interpretation
`max_depth`	`3`	Integer from `1` to `16`. Ordinary search-depth limit; first define one application transition.
`branch_width`	`null`	Null or an integer from `1` to `256`. Full width by default; the child-ranking and pruning rule needs confirmation.
`max_evaluations`	`4096`	Integer from `1` to `100000`. Inspect the response’s `evaluations` and budget diagnostics.
`max_transitions`	`200000`	Integer from `1` to `1000000`. Inspect the response’s `transitions` and budget diagnostics.
`timeout_seconds`	`30`	Number from `1` to `300`. Inspect `deadline_reached` as well as the completed search.

Treat these as separate limits. A requested depth does not establish that the search completed it. Read completed_depth, budget_exhausted, and deadline_reached; do not assume an undocumented precedence rule when more than one limit is reached. The following fragment makes the schema’s depth and work defaults explicit. It is an options object, not a complete planning request.

Planning options fragment

{
  "max_depth": 3,
  "branch_width": null,
  "max_evaluations": 4096,
  "max_transitions": 200000,
  "timeout_seconds": 30,
  "max_extensions": 0,
  "exploration_probability": 0
}

Extensions, proof bounds, and rechecks

Option	Schema default	Contract detail
`max_extensions`	`0`	Integer from `0` to `8`. Inspect `extensions` and `completed_extensions` alongside traces and work counts.
`extension_mode`	`all`	Accepted values: `all`, `competitive`, `equilibrium`. The conditions that trigger each mode are not yet specified in the available contract.
`terminal_proof_bounds`	`null`	Null or an array of exactly two numbers. The ordering and proof semantics of the pair need confirmation.
`recheck_pruned_branches`	`false`	The branches revisited, timing, and budget accounting need confirmation.
`stability_tolerance`	`0`	Nonnegative number. The measured quantity and effect on stopping or extension need confirmation.

Extension counts are not extra-ply counts. Do not add max_extensions to max_depth and report the sum as achieved search depth. Until the optional mode semantics are confirmed for your deployment, retain the documented defaults rather than interpreting the names as algorithm specifications.

Reuse, value scaling, and exploration

Option	Schema default	Contract detail
`reuse_tree`	`false`	Tree reuse is opt-in. Its lifetime and boundaries across calls, sessions, Domains, and model changes need confirmation.
`cache_values`	`false`	Value caching is opt-in. Cache keys, lifetime, and invalidation after a model change need confirmation.
`exploration_probability`	`0`	Number from `0` to `1`. Confirm returned attribution for an explored action before relying on it in audit logic.
`exploration_seed`	`null`	Optional nonnegative integer, with an upper bound in the schema. Its presence does not establish whole-search reproducibility across builds.
`temporal_discount`	`1`	Number greater than `0` and at most `1`. The backup rule and interaction with value-target discounting need confirmation.
`neutral_value`	`0.5`	Planner setting; keep the declared value perspective consistent with the evaluator and terminal scores.
`complementary_total`	`null`	The perspective-conversion rule for a non-null value needs confirmation.

Planning options and value-observation fields belong to different requests. Do not assume that temporal_discount changes stored training targets or that continuation discount enables a blend with an observed outcome. See value observations for target construction. For a controlled comparison, hold planning options and the transition interface fixed while changing the evaluator. Use exploration_probability: 0 when evaluating the planner’s selected action without exploration. Track model identities independently of cache counters.

Inspect the result

Record the requested options, returned action, legality check, evaluator identity, completed depth, extensions, evaluation and transition counts, cache counters, and stopping diagnostics. evaluator.learning_updates reports evaluator updates within the call; it is separate from search work. Native planning routes use /api/v1/domains/{domain_id}/planning/adversarial and the corresponding /stream WebSocket. The route name supports tasks with only maximizing decisions as well as opposing decisions. HTTP and contracts explains authentication and request addressing.

Get started

Concepts

Guides

Value learning

Planning

Discovery

Operations

API reference

Select the evaluator

Bound search work

Extensions, proof bounds, and rechecks

Reuse, value scaling, and exploration

Inspect the result

​Select the evaluator

​Bound search work

​Extensions, proof bounds, and rechecks

​Reuse, value scaling, and exploration

​Inspect the result

Select the evaluator

Bound search work

Extensions, proof bounds, and rechecks

Reuse, value scaling, and exploration

Inspect the result