Choose how a Domain learns

Do not start by authoring an ontology or naming a learner. Start by drawing one event and asking what later evidence should change. When the task boundary is clear but the useful learner-facing structure is not, start with Discovery.

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

The same application can contain several relationships. Keep their targets and feedback meanings separate even when they share one Domain.

This page chooses the evidence relationship. It does not classify how state was earned. Use Choose a learning setup to fix the complete learning-run boundary and distinguish zero-start learning inside that run from state formed in a separate acquisition phase. A later episode or pass is not a warm start when its state was earned earlier inside the same zero-start run.

Start with three common cases

What the application observes	Start here	Why
Evidence or constraints should remain available, but there is no attributable action outcome	Ordinary Domain defaults	Later queries can use retained Domain state without inventing a reward or delayed-credit objective
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 a specialized relationship only when the application can name its observable inputs, target, consequence, and attribution boundary.

Complete relationship map

Question	Relationship
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

These relationships are not task categories or internal architecture modules. They describe what the application can observe and what it wants later behavior to use.

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.

The Domain should not supply:

The correct current action.
Hidden object locations or roles.
A solved action sequence.
An oracle plan or private world state.

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. A long episode can still use ordinary feedback. A two-action episode can require sequential credit. Length does not decide the relationship.

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

The application can choose interventions, observe resulting measurements, and must predict a held-out value. It may also need to return 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.

The Domain should not supply:

The hidden dependency graph.
Unknown equations or coefficients.
The held-out target value.
A preferred experiment chosen using hidden state.

Interaction loop:

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

The event order matters because evidence accumulates, but that fact alone does not require sequential credit. Structured transition learning can model:

before measurements + intervention -> after measurements

Typed hypotheses can represent competing mechanisms. Sequential learning is appropriate when a later objective should assign delayed value to earlier experiment choices, rather than merely because the experiments occurred in a sequence.Keep final prediction accuracy and mechanism quality as separate outputs. A correct endpoint can coexist with a wrong explanation, and a plausible qualitative mechanism can miss the quantitative result.

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.

The Domain should not supply:

Answer coordinates or target paths.
A preferred operation derived from private ground truth.
Labels unavailable to the application at query time.
A post-execution effect disguised as a pre-execution feature.

For independent items, use structured prediction, ordinary feedback, or a stateless route. Do not enable sequential learning merely because the items are processed in order.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. A scalar, categorical relation, coordinate set, rigid pose, and variable-length path have different target geometry and evaluation meaning. A common source image does not make those contracts interchangeable.

History is not delayed credit

Recent history can be included as observable context without creating a sequential objective.

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.

Specialized relationships

Combine transition and policy evidence

One executed action can produce two different teaching relationships:

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 relationships 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

This is not general next-state prediction and it is not delayed-return learning. Its configuration is nested under learning.sequential.bound_transition, but that location does not make every bounded-scoring task a sequential-credit task. Do not use it for hidden state, an undefined objective, or an ordinary context-to-outcome decision.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.

Free-form notes can help an application preserve context, but a scored mechanism needs a typed result that can be compared consistently.

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 Domain states without blending them.

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 or source pairs 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

Do not copy advanced controls from another task. Event boundaries, input geometry, target shape, grouping, support, and delayed-credit horizons express specific evidence relationships.

Validate the lifecycle, not only the score

Separate these stages:

Stage	Writes allowed?	Question answered
Cold start	Yes, after the first call	What does the contract produce before task history accumulates?
Online adaptation	Yes	Does admitted evidence change later behavior?
Held-out transfer	Depends on the protocol	Does state formed from a separate acquisition partition help on new instances with the same public semantics?
Frozen evaluation	No	What does the retained state produce without further learning?

Frozen describes the write policy during inspection. It establishes transfer from separately acquired state only when the acquisition and evaluation split was fixed before state formation. If the state was earned earlier inside the same zero-start run, a later frozen checkpoint is a within-run frozen read. A successful API write does not prove learner admission. Preserve raw responses, event IDs, applicable sample counts, learner versions, external truth, and harness-derived metrics separately. During frozen evaluation, verify that the applicable learner state does not change.

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 without assuming a Discovery-only 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 posterior sources and source pairs add predictive utility.

Learn from outcomes

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

Verify adaptation

Test cold, adaptive, transfer, and frozen behavior without mixing the claims.

Get started

Build

Advanced Domain design

Operate

Modalities

Domains

Interval policies

State

System

Spatial Vision API

Start with three common cases

Complete relationship map

Pattern 1: multistep action task

Other task shapes

History is not delayed credit

Specialized relationships

One Domain or several

Start with the smallest configuration

Validate the lifecycle, not only the score

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 with three common cases

​Complete relationship map

​Pattern 1: multistep action task

​Other task shapes

​History is not delayed credit

​Specialized relationships

​One Domain or several

​Start with the smallest configuration

​Validate the lifecycle, not only the score

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 with three common cases

Complete relationship map

Pattern 1: multistep action task

Other task shapes

History is not delayed credit

Specialized relationships

One Domain or several

Start with the smallest configuration

Validate the lifecycle, not only the score