Learning schedules

Adapt-1 can use the same Domain contract under several learning schedules. Declare when task-specific learner state is acquired relative to the evaluation or operating run.

Classify state by the run in which it was acquired. State earned earlier inside the current run is in-run state.

The learning schedule is independent of the Domain design. Discovery, an authored ontology, and a mixed Domain can each start empty, use separately acquired state, run frozen, or continue learning.

Fix the learning-run boundary first

A learning run is the complete interval from a declared starting learner state to the endpoint used for one evaluation claim or operating period. A run can contain:

one task with several observations or interventions;
several passes over related work;
many environment episodes; or
a continuing production stream.

A complete protocol can contain more than one run or phase. In a separate-acquisition protocol, the acquisition phase forms a checkpoint first. The new evaluation or operating run begins after that checkpoint at a boundary fixed before scoring. Episodes or passes that retain state and contribute to one reported zero-start learning result belong to the same run. If learner state is reset for every independently redrawn task, each task can be its own task-local learning run.

A checkpoint inside the run records the state accumulated up to that point. Compare later behavior with earlier results to measure retention and improvement within the run.

Choose a starting state and write policy

Classify the setup from the state at the start of the complete run and the writes allowed inside it.

Applicable task-specific learned state at run start	Learner writes during the run	Setup	Fair interpretation
Empty	No	Cold use	The run uses the base capabilities and declared contract with task-specific learning disabled
Empty	Yes	Zero-start learning during the run	The run earns state from its own observations, actions, and outcomes
Separately acquired	No	Separate acquisition, then frozen use	State earned outside the run is available from the first important decision and remains unchanged
Separately acquired	Yes	Separate acquisition, then continued adaptation	The run starts with acquired state and continues updating it from current outcomes

“Empty” means no applicable task-specific learned state. A Domain contract, public action space, target schema, authored ontology, or base Adapt-1 capability can still exist. “Separately acquired” means the records that formed the starting state belong to a declared acquisition phase outside the current evaluation or operating run. The split must be fixed before evaluation.

Choose and implement a protocol

Acquisition boundaries

Use separate acquisition when the current run should begin with competence earned from other records.

fresh acquisition state
-> admit approved acquisition records
-> form and validate task-specific state
---------------- declared run boundary
-> begin new work using that state

Use zero-start learning during the run when the reported or deployed stream itself should earn the state.

empty task-specific learned state
---------------- declared run boundary
-> observe, act, and receive outcomes
-> update learner state
-> later work in the same run uses what earlier work taught

A zero-start run can retain state across episodes or passes. Label each checkpoint as in-run state when it was acquired during that run.

When separate acquisition makes sense

Use a separate acquisition phase when most of these conditions hold:

The first important decision in the new run should already benefit from task experience.
The current task cannot provide enough useful evidence before important decisions occur.
Exploration or avoidable failure during the new run is costly, unsafe, slow, or unavailable.
Approved examples, demonstrations, resolved cases, transitions, trajectories, or earlier operations share the same public meanings as the new work.
Evaluation should measure transfer from acquisition records onto held-out work.
A reviewed learned state must remain stable during deployment.

After acquisition, choose between:

frozen use, when the new work must not change learner state; and
continued adaptation, when the acquired state is only a starting point and current outcomes should still update it.

A separate acquisition phase can itself start with empty task-specific state. Declare its starting state and record the boundary before evaluation.

When zero-start learning during the run makes sense

Use zero-start learning during the run when most of these conditions hold:

The run can produce useful observations or attributable outcomes before later decisions.
Improvement across the run is part of the claimed or required behavior.
The application can safely expose the observation, decision, execution, consequence, and feedback boundary.
Local conditions can change during operation.
A hidden relationship can be discovered through evidence produced inside the task.
The intended result is adaptation from an empty task-specific state.

Choose the retention scope for zero-start learning:

State scope	Meaning
Task-local	Start empty for one independently redrawn task, learn before its final result, then reset
Retained across the run	Start the complete run empty, then carry state across compatible passes, episodes, or operating events

Record resets and retention at the declared scope boundary.

Start from acquired state and continue learning

To continue adaptation from acquired state:

The starting task-specific state was earned from a declared acquisition phase outside the current run.
Learner writes remain enabled during the current run.

separate acquisition phase
-> validated starting checkpoint
---------------- declared run boundary
-> begin from acquired state
-> admit current outcomes
-> continue adapting

Keep a fixed copy of the starting checkpoint when you need to measure the value added by current-run adaptation.Classify later episodes that use state earned inside a zero-start run as within-run retention.

Interactions during frozen use

Frozen use keeps the applicable learner state fixed across queries. During frozen use, all of these can still change:

the current observation;
available legal actions;
inventory, location, or external process state;
temporary episode context; and
the result requested at each step.

The applicable learner state, discovered structure, samples, model state, and learner identity must remain unchanged. Completed evaluations have applied acquired state to held-out combinations of operating conditions, recent history, and phase. The frozen state supported different choices as those observations changed. Matched controls that omitted or scrambled relevant inputs lost distinctions used by the acquired state. Pausing learning therefore still allows current observations to select different predictions or actions from what was learned earlier. The reports in Further reading describe acquisition, frozen evaluation, and continued adaptation alongside their recorded evidence. Declare the evaluation distribution separately. Both frozen use and online adaptation can be evaluated on in-distribution or out-of-distribution (OOD) inputs.

Keep schedule, state scope, learning method, and structure source separate

Design choice	Question answered
Acquisition schedule	Was task-specific state earned outside the run or from evidence inside it?
Write policy	May the current run update learner state?
State scope	Do in-run updates reset after one task or persist across compatible work?
Learning method	What should each observation or outcome change?
Structure source	Is learner-facing structure discovered, authored, or mixed?
Evaluation distribution	Is the new work seen, held out, shifted, or OOD relative to acquisition?

Contextual, transition, structural, temporal, and sequential learning can form state during a zero-start run or a separate acquisition phase. Specify the acquisition schedule for the chosen learning method.Discovery is also independent of the schedule:

Structure source	Zero-start during run	Separate acquisition then frozen	Separate acquisition then continue
Discovery	Supported	Supported	Supported
Authored ontology	Supported	Supported	Supported
Mixed	Supported	Supported	Supported

Discovery forms supported learner-facing structure from admitted evidence. Apply the selected state scope and write policy to that structure.

What acquisition records must preserve

A separate acquisition phase can use resolved examples, demonstrations, observations and targets, decisions and direct outcomes, transitions, or complete trajectories.Preserve all applicable information:

what was observable before the result or action;
the exact result or action produced and used;
the observable target, transition, or consequence available afterward;
stable field names, types, units, action meanings, and outcome semantics;
true order and reset boundaries when history matters;
representative coverage of cases, conditions, and alternatives;
a held-out split by entity, scenario, or episode before ingestion; and
no future observation, target-derived value, correct-action label, or private evaluator output in the pre-result input.

Replay only approved acquisition records into fresh acquisition state. Inspect learner admission and validate the resulting state before starting the held-out or deployment run.For corpus-based acquisition, choose how to learn from the observations and outcomes in each record.

When ordered interaction needs sequential learning

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.

Sequential Discovery can operate inside a zero-start multi-episode run. It can also form from a separate trajectory acquisition phase and then be frozen or continued.Use direct feedback, transition learning, retained evidence, or another learning method when those match what the records teach.See Sequential learning, advanced for transition tuples, validation gates, episode requirements, and model diagnostics.

Scenario map

Observable protocol	State at full run start	Writes during full run	Correct label
Teach on excluded records, then execute unseen interactive tasks without updates	Separately acquired	No	Separate acquisition, then frozen transfer
Start empty and improve across several retained passes	Empty	Yes	Zero-start online learning retained across passes
Start empty and improve across many compatible episodes	Empty	Yes	Zero-start online learning retained across episodes
Start empty for each independently redrawn hidden task, gather local evidence, answer, then reset	Empty per task	Yes	Zero-start task-local learning
Begin from an excluded acquisition checkpoint and continue learning from production outcomes	Separately acquired	Yes	Continued adaptation from acquired state
Produce independent results without inherited state or learner writes	Empty	No	Cold use

Scientific experiment setup

Use separate acquisition when earlier experiments share the same variable meanings, intervention semantics, measurement protocol, and transferable relationship, and the first experiment in the new run should already benefit from them.When each material, process, or target has an independently redrawn hidden mapping, choose zero-start task-local learning to infer that mapping through local interventions before the final result. Reset at the declared independent-task boundary.A continuing experimental program can begin empty with zero-start retained learning across its own trials. Later trials use the state acquired earlier in that program.Start from externally acquired state when prior experimental records should inform the first choice, then enable updates if new experiments should revise it.Choose whether the experiment should teach direct utility, a transition, delayed credit, predictive structure, or a typed mechanism. See Choose how a Domain learns.

Implementation protocols

Cold use

start the declared run with empty applicable task-specific state
supply current inputs
request and use results
do not admit the run as learning evidence

Zero-start learning during the run

start the declared run with empty applicable task-specific state
query or act from current observations
observe real consequences
admit eligible evidence
let later work in the same run use the updated state
reset or retain at the declared state-scope boundary

Separate acquisition, then frozen use

split acquisition and new work before ingestion
-> build state only from acquisition records
-> validate and fingerprint the learned state
---------------- declared run boundary
-> stop learner-state writes
-> execute new work from the acquired state
-> verify learner identity remains unchanged

Separate acquisition, then continued adaptation

build and validate state from a separate acquisition phase
-> save a fixed starting checkpoint
---------------- declared run boundary
-> begin new work from that checkpoint
-> admit new observations and measured outcomes
-> compare later state and behavior with the starting checkpoint

Evaluation names must match the protocol

Claim	Required protocol
Cold behavior	Empty applicable task-specific state at run start and no learner writes in the run
Zero-start online adaptation	Empty applicable state at the start of the complete run; results precede outcomes; eligible in-run evidence updates state
Zero-start task-local adaptation	Empty state for each declared independent task; updates occur inside the task; state resets afterward
Within-run retention	A later pass or episode uses state earned earlier inside the same zero-start run
Transfer from separately acquired state	Acquisition and evaluation or deployment are split before state formation
Frozen transfer	Separately acquired state is used with no event, feedback, discovery, memory, or training-state writes during the new run
Continued adaptation from acquired state	Separately acquired state exists at run start and current-run outcomes continue updating it

Check learner-admission diagnostics after a successful write. Preserve them with the declared starting state, run boundary, subsystem sample counts, learner versions, decisions, executed actions, measured consequences, and state fingerprints where applicable.

Choose how a Domain learns

Choose what each observation or outcome should change.

Use Discovery

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

Author a Domain ontology

Define explicit reviewed learner-facing structure.

Verify adaptation

Confirm the declared starting state, allowed writes, and later behavior.

Monitor adaptation

Preserve state versions, decisions, outcomes, and lifecycle evidence.

Get started

Concepts

Guides

Discovery

Operations

API reference

Fix the learning-run boundary first

Choose a starting state and write policy

Choose and implement a protocol

Interactions during frozen use

Evaluation names must match the protocol

Choose how a Domain learns

Use Discovery

Author a Domain ontology

Verify adaptation

Monitor adaptation

​Fix the learning-run boundary first

​Choose a starting state and write policy

​Choose and implement a protocol

​Interactions during frozen use

​Evaluation names must match the protocol

Choose how a Domain learns

Use Discovery

Author a Domain ontology

Verify adaptation

Monitor adaptation

Fix the learning-run boundary first

Choose a starting state and write policy

Choose and implement a protocol

Interactions during frozen use

Evaluation names must match the protocol