> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reilabs.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Learning schedules

> Choose the starting state and whether learning continues during a run.

Adapt-1 can use the same Domain contract under several learning schedules. This page distinguishes how task-specific learner state is earned relative to a declared evaluation or operating run.

<Warning>
  Do not call state “pre-acquired” only because it exists before a later episode, pass, or decision. State earned earlier inside the same run is still state earned during that run.
</Warning>

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.

Fix the run boundary before inspecting results.

If learner state is retained across episodes or passes and those episodes or passes contribute to one reported zero-start learning result, they belong to the same run. A new environment episode does not automatically start a new learning run.

If learner state is reset for every independently redrawn task, each task can be its own task-local learning run.

<Info>
  A later checkpoint inside a run can use state accumulated earlier in that run. This shows retention and improvement inside the run. It does not turn the checkpoint into a warm start or a separately trained evaluation.
</Info>

## Choose among four setups

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 neither inherits task-specific learned state nor forms it from current outcomes            |
| 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** | State earned outside the run provides a true warm start, and current outcomes continue changing it |

“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

<span id="the-central-distinction" />

<Accordion title="The central distinction">
  Use **separate acquisition** when the current run should begin with competence earned from other records.

  ```text theme={null}
  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.

  ```text theme={null}
  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
  ```

  The second case can span many episodes or passes. State before episode 10 or pass 3 is retained **in-run state**, not separately acquired state, when the complete run began empty.
</Accordion>

<span id="when-separate-acquisition-makes-sense" />

<Accordion title="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 from zero. “Separately acquired” describes where the state was earned relative to the current run, not whether the acquisition phase used pretraining.
</Accordion>

<span id="when-zero-start-learning-during-the-run-makes-sense" />

<Accordion title="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 rather than transfer from a teaching phase.

  Zero-start learning has two common state scopes:

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

  Both are zero-start learning. Retaining state across episode boundaries does not make later episodes separately pretrained.
</Accordion>

<span id="what-a-true-warm-start-requires" />

<Accordion title="What a true warm start requires">
  A true warm start requires both of these conditions:

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

  ```text theme={null}
  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.

  Do not call a later episode or pass a warm start when all state was earned earlier inside the same zero-start run.
</Accordion>

## Frozen can still be interactive

Frozen applies to retained learner state. It does not freeze the external task.

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.

OOD is another independent property. A run can be frozen and OOD, frozen and in-distribution, or online and OOD.

<span id="keep-schedule-state-scope-relationship-and-structure-source-separate" />

<Accordion title="Keep schedule, state scope, relationship, 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?  |
  | **Evidence relationship**   | 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 all happen during a zero-start run. They can also form during a separate acquisition phase and then be used frozen or continued online. These relationships describe what the evidence teaches. They do not determine when the state was earned.

  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 means supported learner-facing structure forms from admitted evidence instead of being fully authored. It does not mean task-local, zero-start, online-only, or unfrozen.
</Accordion>

<span id="what-acquisition-records-must-preserve" />

<Accordion title="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.

  A corpus is one way to conduct separate acquisition. It is not a learning relationship and does not make the task sequential.
</Accordion>

<span id="when-ordered-interaction-needs-sequential-learning" />

<Accordion title="When ordered interaction needs sequential learning">
  Sequential learning is an evidence-relationship choice. Use it only when both conditions hold:

  1. An earlier action changes the state encountered later.
  2. 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.

  A demonstration corpus, a long multistep task, or an interactive frozen episode does not by itself require sequential learning. Use direct feedback, transition learning, retained evidence, or another relationship when those better match what the records teach.

  See [Sequential learning, advanced](/docs/neuroadapt/sequential-learning) for transition tuples, validation gates, episode requirements, and model diagnostics.
</Accordion>

<span id="scenario-map" />

<Accordion title="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                    | True warm-started continued adaptation              |
  | Produce independent results without inherited state or learner writes                             | Empty                   | No                     | Cold use                                            |
</Accordion>

<span id="scientific-experiment-setup" />

<Accordion title="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.

  Use zero-start task-local learning when each material, process, or target has an independently redrawn hidden mapping and local interventions reveal that mapping before the final result. Reset at the declared independent-task boundary.

  Use zero-start retained learning when one continuing experimental program begins empty and should improve across its own trials. Later trials use in-run state, not separately acquired state.

  Use a true warm start when an external acquisition set forms the starting state and new experiments should continue revising it.

  Whether an experiment teaches direct utility, a transition, delayed credit, predictive structure, or a typed mechanism is a separate relationship choice. See [Choose how a Domain learns](/docs/neuroadapt/learning-patterns-for-domains#other-task-shapes).
</Accordion>

<span id="four-complete-protocols" />

<Accordion title="Four complete protocols">
  <span id="cold-use" />

  **Cold use**

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

  <span id="zero-start-learning-during-the-run" />

  **Zero-start learning during the run**

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

  <span id="separate-acquisition-then-frozen-use" />

  **Separate acquisition, then frozen use**

  ```text theme={null}
  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
  ```

  <span id="separate-acquisition-then-continued-adaptation" />

  **Separate acquisition, then continued adaptation**

  ```text theme={null}
  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
  ```
</Accordion>

## 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 |
| **True warm-started adaptation**            | Separately acquired state exists at run start and current-run outcomes continue updating it                               |

A successful write proves only that the API accepted or stored a record. It does not prove that the intended learner used it. Preserve the declared starting state, run boundary, admission diagnostics, subsystem sample counts, learner versions, decisions, executed actions, measured consequences, and state fingerprints where applicable.

<CardGroup cols={2}>
  <Card title="Choose how a Domain learns" href="/docs/neuroadapt/learning-patterns-for-domains">
    Choose what each observation or outcome should change.
  </Card>

  <Card title="Use Discovery" href="/docs/neuroadapt/discovery">
    Let Adapt-1 form learner-facing structure from admitted evidence.
  </Card>

  <Card title="Author a Domain ontology" href="/docs/neuroadapt/build-a-domain-aware-assistant">
    Define explicit reviewed learner-facing structure.
  </Card>

  <Card title="Verify adaptation" href="/docs/neuroadapt/evaluate-adaptation">
    Confirm the declared starting state, allowed writes, and later behavior.
  </Card>

  <Card title="Monitor adaptation" href="/docs/neuroadapt/measure-online-adaptation">
    Preserve state versions, decisions, outcomes, and lifecycle evidence.
  </Card>
</CardGroup>
