Learning from evidence and outcomes

Describe one interaction and identify what later evidence should change. Both Discovery and authored setups use a Domain. The observation, action, target, and feedback contracts below apply to either setup.

what is known before the result
current result or committed choice
what becomes observable afterward
which later result should change

The same application can use several learning workflows. Keep their targets and feedback meanings separate even when they share one Domain.

Use Discovery when supported inputs, representations, or bindings should form from evidence. Author the structure when it must remain explicit and reviewed. Choose starting state, retention, and allowed updates separately through Learning schedules.

Start from the available evidence

What the application observes	Start here	Why
Observable inputs have a measured or corrected target	Transition Discovery or explicit transition configuration	Completed records teach the requested output; queries withhold that target
Evidence or constraints should remain available for later queries	Ordinary Domain defaults	Later queries use retained Domain state
One committed choice receives its own attributable outcome	Domain feedback or contextual policy feedback	The outcome can revise that choice under the applicable scope
Earlier actions change later states, and a delayed or terminal outcome should revise those earlier actions	Sequential learning with the true episode boundary	Credit must reach state-changing choices that do not receive a sufficient immediate outcome

Start with the first matching case. Add another learning method when the application can name its observable inputs, target, consequence, and attribution boundary.

Choose a learning workflow

Question	Start here
What is supported by the evidence now?	Ordinary Domain reasoning and retained evidence
What observable state follows these inputs or this action?	Structured transition learning
How would each candidate move a bounded public state toward one numeric objective?	Bounded transition scoring
Was this committed choice useful?	Contextual policy feedback
Which earlier choices contributed to a later outcome?	Sequential learning
Which mechanism best explains the observations?	Typed, competing hypotheses

For each task, specify what the application observes and how that evidence should affect later behavior. Keep decision-time inputs separate from teaching evidence. Query with information available before the result; submit completed targets, corrections, and outcomes through the applicable learning contract. For evaluation, keep held-out answers and private evaluator information out of decision-time context.

Pattern 1: multistep action task

The application must satisfy a goal through several actions that change the state encountered next. The Domain can supply:

Goal and object vocabulary.
Observable state fields.
Public action grammar or the currently available legal choices.
Native progress, failure, and terminal outcome meanings.
Episode and reset boundaries.

Interaction loop:

current observation + available choices
selected action
exact external execution
next observation and native outcome
next selection

Use direct feedback when one action receives a sufficient attributable outcome. Use sequential learning when a later or terminal outcome should revise earlier actions that changed subsequent states. Choose the learning method from the action effects and how outcomes are attributed. Before collection, write one example of each part of the interaction. These records define the application interface for both authored and Discovery setups:

Setup choice	What to define
Current observation	Goal and available pre-action observations; preserve event order and episode boundaries when temporal context is relevant
Available choices	Stable action names, parameters, and attributes, with a direct mapping to executable operations
Decision boundary	When an action ends and a new observation becomes available
Returned evidence	The executed choice, its pre-action context, resulting state, and measured outcome
Retained and temporary state	What transfers into another episode, and what resets with the environment

For an object-handling task, preserve object type and instance identity, required quantities, completed prerequisites, and which objects have already been processed or placed. Two objects of the same type can have different roles in the current goal. Keep feature meanings and action attributes consistent between acquisition and later use. If acquisition uses recorded trajectories, preserve the available candidates and the action actually executed at each step. Reference actions or successful plans belong to a declared teaching phase using a learner contract that accepts them. During frozen execution, supply the current observation and legal choices, and advance temporary bindings and progress as actions complete. Learning schedules defines the acquisition and evaluation boundary.

Decisions beyond the next move

Adapt-1 can use consequences several steps ahead when choosing an action. Configured transition planning evaluates candidate action sequences through learned predictions of successive states, against the Domain’s goal and constraints. The planning horizon bounds how far those predicted continuations extend. An application can execute the first action, observe what actually happened, and query again from that new state. Returning one action per turn is compatible with considering several future transitions before each choice. The following settings describe different parts of this process:

Setting or boundary	What it controls
Planning horizon	How far candidate sequences extend through predicted future states
Sequential `n_step`	How many observed rewards enter a training return before bootstrapping from the successor state
Sequential `discount`	How strongly later value contributes to earlier choices
Decision boundary	When the application observes again and requests another action

Sequential learning allows later outcomes to teach the value of earlier choices. Transition planning uses learned consequences to evaluate future choices. Both can contribute within a configured Domain. Planning can also use exact rules for state changes and a learned evaluator for unfinished states. The transition source determines what can happen next; the value source determines how useful that continuation is. Learning and planning covers this combination, including opposing choices and a single shared objective. Search-derived targets belong to an explicit training process. A planned estimate can be combined with an observed outcome at an actually observed state. Record that construction separately from executed transitions, and distinguish the target-generation horizon from later gameplay or control depth. Keep this value-training process distinct from the sequential-learning configuration. For a turn-based game, make the following explicit:

State: expose the player to move, legal choices, and a board representation or measured features that preserve strategically relevant differences between positions.
Step: define whether one transition covers a single player’s move or the agent’s move followed by the opponent’s reply. This determines what “two moves ahead” means.
Opponent response: specify how replies enter the predicted continuation. Record the actual reply and resulting state when returning execution evidence.
Objective and ending: define how wins, losses, draws, intermediate outcomes, and terminal positions are represented.

For example, when one transition runs from one agent decision to its next decision after the opponent responds, three transitions span three such decision intervals. Document which opponent replies are considered when comparing candidate continuations. Use the transition guide for the prediction contract and sequential configuration for delayed-return settings. Compare supported planning horizons on the same held-out positions and opponent protocol, with learned state frozen, to measure the effect on decisions and game outcomes.

Choose when to observe again

Place a decision boundary where new observations can change the useful action. For example, a simulated agent may see an obstacle before a jump but only see the gap beyond it during the jump. A second query can use that new view while a correction is still possible.

Decision boundary	Available observations	Permitted choices
Before takeoff	Current speed, nearby obstacles, visible ground	A declared movement macro
Near the top of the jump	Newly visible gap, current speed, rise time and height	Continue, brake, or pull back

This is an application design example. The executor defines when each boundary occurs and which controls remain available. Use separate Domains when the phases have incompatible action meanings or feedback contracts; retain each decision’s context, selected action, execution, and attributed outcome. If similar query inputs repeatedly require different actions, inspect which distinguishing information is missing and when it becomes observable. A later observation boundary or a more informative measured input may resolve the ambiguity. Both phases can query fresh observations during frozen use, with learner writes and exploration disabled.

Other task shapes

Optimize repeated experiments

Use contextual policy feedback when each experiment has a measurable result that belongs to that choice.

Experimental concept	Domain role
Material, batch, instrument, and pre-trial conditions	Decision context
Permitted solvent, catalyst, temperature, dose, duration, or procedure	Policy and optional policy features
The exact experiment performed	Executed policy
Yield, selectivity, purity, cost, duration, or safety result	Measured reward components

Use transition learning when the main result is the measured output expected from the conditions. Use typed hypotheses when the mechanism itself must remain inspectable. Use sequential learning only when an early experiment or process step changes the state used by later steps and a later result should revise that early choice.A separate acquisition phase helps when choice meanings and outcome scales transfer into future experimental runs. Zero-start task-local learning fits when each target has a different hidden mapping that should be discovered through local interventions and reset afterward. See Choose a learning setup for the complete schedule and boundary rules.

Discover a hidden process

Use interventions and resulting measurements to predict how a process behaves or build a typed mechanism that explains the evidence.The Domain can supply:

Variable names, units, and observable ranges.
Which variables are controllable.
The public meaning of an intervention.
The experiment budget and episode boundary.
The result schema for an intervention, numeric prediction, and typed hypothesis.
A public functional family when the task interface intentionally discloses it.

For hidden-process evaluation, keep the unknown mechanism and held-out target out of the query context.Interaction loop:

prior measurements
-> choose one permitted intervention
-> observe resulting measurements
-> revise the current hypothesis
-> choose another intervention or submit the final prediction

Preserve event order as measurements accumulate. Structured transition learning can model:

before measurements + intervention -> after measurements

Typed hypotheses can represent competing mechanisms. Use sequential learning when a later objective should assign delayed value to earlier experiment choices.Evaluate final prediction accuracy and mechanism quality separately against their respective targets.

Structured scene or object reasoning

The application must return a relation, scalar, coordinates, pose, grasp, path, or another structured result from observable scene information.The Domain can supply:

Public object identities and observable features.
Coordinate conventions, units, and reference frames.
Available operations or candidate objects when applicable.
The exact result grammar and validity constraints.
Native outcomes when a returned operation is actually executed.

Do not use post-execution values as pre-execution features.For independent items, use structured prediction, ordinary feedback, or a stateless route according to the result and feedback contract.When the result is externally executed, preserve the complete record:

observable scene
-> returned operation
-> committed operation
-> exact execution
-> observable after-state and native outcome

Different outputs may need separate learner views or Domains to preserve their target geometry and evaluation meaning. Define the result contract for each scalar, categorical relation, coordinate set, rigid pose, or variable-length path.To build a learning loop around a structured output:

Define the output format. Define coordinate units, reference frame, normalization, point ordering, and output validity. For a variable-length result, define its count and how absent elements are represented. Use the same conventions in queries, teaching events, and execution.
Choose the input setup. Declare eligible event types and observable targets. Use Transition Discovery to form eligible input paths from evidence, or explicit transition configuration to supply reviewed paths. Group evidence only where public contexts have incompatible meanings.
Return the target after prediction. Query with the target withheld, preserve the prediction, and score it. When an observed or corrected target is available for learning, submit an eligible event containing the original input fields and that target. Preserve its source and timing.
Learn selection when alternatives exist. Define executable candidates and how each produces its output. A supported learned output can be a candidate alongside fixed geometric procedures. Submit measured utility through decision-bound feedback for the candidate actually used.
Check both updates. Inspect target admission and later prediction support separately from policy-feedback admission and selection changes.

Target events teach output geometry. Utility feedback teaches which candidate works in context. A scalar success score alone does not supply corrected coordinates. Define each channel only when the application has that evidence.Retain compatible Domain state across passes intended to use earlier corrections. Repeated items measure reuse of earlier evidence. Reserve separate cases before acquisition when measuring transfer, then evaluate them with learning stopped.

History and delayed credit

Bounded recent history can be included in the current observation.

Design	Meaning
Add recent observations to the current input	Later queries can condition on bounded history
Record events in chronological order	Provenance and evidence accumulation are preserved
Assign a later outcome back to earlier actions	Sequential credit changes the value of earlier choices

Use sequential learning when both conditions hold:

An earlier action changes the state encountered later.
A later or terminal outcome should revise that earlier action.

If the current choice receives its own sufficient outcome, ordinary contextual feedback is usually the correct starting point. The application can also compute a return and attribute it to an earlier decision before submitting contextual feedback. In that setup, the application owns delayed-credit calculation. See application-computed returns.

Additional learning workflows

Combine transition and policy evidence

One executed action can teach an observable transition and its measured utility:

transition evidence: before state + action -> observable after-state
policy evidence: committed action -> measured usefulness or native outcome

Do not put correct_action, a reward judgment, or a preferred policy into an observation-only transition target. Do not treat a next-state prediction as proof that the action was useful.Compatible learning methods can coexist inside one Domain when they share the same public task semantics and lifecycle. They should still use separate targets, admission rules, and diagnostics.

Compare candidates against a bounded objective

Use bounded transition scoring when the application must compare candidate actions by how each is expected to change an explicit public numeric state toward one declared objective. All of these should be true:

The relevant state is public and numerically bounded.
Each candidate identifies the state and action it would affect.
Feedback can return the observed successor state.
One declared state feature is the objective.

current bounded state + candidate action
-> predicted state change
-> projected distance or progress toward the objective

Configure bounded transition scoring under learning.sequential.bound_transition. Delayed-return learning requires its own sequential configuration. The scoring contract requires public bounded state and an explicit objective.For this optional scoring path, map the candidate’s object and tool selectors to their current observable fields. Declare the public operation roles and objective scale. Outcomes teach the effects associated with those bindings. A public effect family can constrain possible changes while leaving the active action-effect mapping to be learned. The bound-transition setup walks through these choices.The feedback and outcomes guide documents the exact mapping.

Return a typed mechanism

Use candidate hypotheses when the mechanism itself should remain inspectable or evaluable. Good candidates:

Compete over the same declared relation.
Predict different observable consequences.
Can receive supporting evidence and counterevidence.
Use the same public schema.
Do not encode a preferred answer.

Use a typed result to score mechanisms consistently. Free-form notes can preserve additional application context.

One Domain or several

Use one Domain when evidence should interact under one stable contract. Use several Domains when state must remain isolated because the public semantics, result geometry, feedback meaning, retention scope, or evaluation lifecycle differ.

Keep one Domain	Split Domains
New episodes change only live observations	The result types have incompatible geometry or validity rules
The same actions and outcomes keep the same meaning	The same label or action means something different by task
One evidence history should support later queries	Evidence from one workflow must never support another
Several query types inspect one shared mechanism	Feedback and reset boundaries differ

Every operation addresses one domain_id. One Core instance can retain several isolated Domain states.

Start with the smallest configuration

Need	Configuration direction
Retain evidence, constraints, or hypotheses	Ordinary Domain defaults
Bind an attributable outcome to a committed decision	Domain feedback or contextual policy feedback
Add bounded recent history to the current learning context	Enable temporal context projection with real episode and step paths
Learn which posterior sources and combinations add predictive utility	Enable counterfactual utility plasticity after at least two posterior sources can become usable
Predict an observable result when the useful inputs are not yet known	Enable transition Discovery and omit authored `input_paths`
Predict an observable result from a reviewed fixed input surface	Enable `learning.transition` with explicit `input_paths`
Compare candidate actions against a bounded public numeric objective	Configure `learning.sequential.bound_transition` using the documented state, action, and objective mappings
Let later outcomes revise earlier state-changing decisions	Enable sequential learning and configure the true episode boundary; use Sequential Discovery when supported action-value structure should form from evidence
Prevent incompatible transition evidence from mixing	Add grouping only for the incompatible public context
Return a mechanism	Add typed, distinguishable hypotheses
Produce one independent result	Use the applicable stateless route when retained adaptation is unnecessary

Configure event boundaries, input geometry, target shape, grouping, support, and delayed-credit horizons for the application’s learning task.

Check the learning loop

Confirm learner admission from the route’s diagnostics, then inspect whether a later result uses the intended state. Preserve raw responses, event IDs, applicable sample counts, learner versions, and measured outcomes. Keep derived metrics separate from the raw record. During frozen use, verify that the applicable learner state does not change. See Verify adaptation for evaluation checks and Learning schedules for starting-state and update policies.

Choose a learning setup

Fix the run boundary and distinguish zero-start learning from separately acquired state.

Use Discovery

Let Adapt-1 form learner-facing structure from admitted evidence.

Author a Domain ontology

Define explicit reviewed task-facing structure when you need it.

Sequential learning

Configure delayed credit for earlier state-changing actions in an authored, discovered, or mixed Domain.

Transition learning, advanced

Configure event admission, evidence geometry, targets, support, grouping, and abstention.

Use TCP

Add bounded episode history to contextual memory, model inference, and posterior selection.

Use CUP

Learn which registered sources and combinations add predictive utility.

Learn from outcomes

Connect the returned value, application commitment, execution, and measured result.

Verify adaptation

Evaluate each starting-state and write policy under a declared protocol.

Get started

Concepts

Guides

Planning

Discovery

Operations

API reference

Start from the available evidence

Choose a learning workflow

Pattern 1: multistep action task

Decisions beyond the next move

Choose when to observe again

Other task shapes

History and delayed credit

Additional learning workflows

One Domain or several

Start with the smallest configuration

Check the learning loop

Choose a learning setup

Use Discovery

Author a Domain ontology

Sequential learning

Transition learning, advanced

Use TCP

Use CUP

Learn from outcomes

Verify adaptation

​Start from the available evidence

​Choose a learning workflow

​Pattern 1: multistep action task

​Decisions beyond the next move

​Choose when to observe again

​Other task shapes

​History and delayed credit

​Additional learning workflows

​One Domain or several

​Start with the smallest configuration

​Check the learning loop

Choose a learning setup

Use Discovery

Author a Domain ontology

Sequential learning

Transition learning, advanced

Use TCP

Use CUP

Learn from outcomes

Verify adaptation

Start from the available evidence

Choose a learning workflow

Pattern 1: multistep action task

Decisions beyond the next move

Choose when to observe again

Other task shapes

History and delayed credit

Additional learning workflows

One Domain or several

Start with the smallest configuration

Check the learning loop