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

# Explore Domain learning patterns

> Compare explored ways to organize observations, outcomes, feedback, and evaluation inside a Domain.

export const HybridInstanceFigure = () => {
  const domains = [{
    id: "domain_id: domain-a",
    detail: "task contract + evidence + learned state",
    active: false
  }, {
    id: "domain_id: domain-b",
    detail: "task contract + evidence + learned state",
    active: true
  }, {
    id: "domain_id: domain-c",
    detail: "task contract + evidence + learned state",
    active: false
  }];
  return <figure className="not-prose my-8 overflow-hidden rounded-2xl border border-stone-200 bg-white shadow-sm dark:border-zinc-800 dark:bg-zinc-950" aria-labelledby="hybrid-instance-caption">
      <div className="flex flex-wrap items-start justify-between gap-3 border-b border-stone-200 px-5 py-4 dark:border-zinc-800">
        <div>
          <div className="text-xs font-semibold uppercase tracking-widest text-amber-700 dark:text-amber-400">Multiple-Domain use</div>
          <div className="mt-1 text-sm font-semibold text-stone-900 dark:text-zinc-100">Multiple Domains coexist; one participates per operation</div>
        </div>
        <span className="rounded-full border border-stone-200 bg-stone-50 px-3 py-1 font-mono text-xs text-stone-600 dark:border-zinc-700 dark:bg-zinc-900 dark:text-zinc-400">one Core instance</span>
      </div>

      <div className="grid gap-px bg-stone-200 dark:bg-zinc-800 lg:grid-cols-3">
        <section className="bg-white p-5 dark:bg-zinc-950 lg:col-span-2" aria-label="Domains retained in the instance">
          <div className="mb-3 text-xs font-medium text-stone-500 dark:text-zinc-400">Domains retained in the instance</div>
          <div className="grid gap-3 sm:grid-cols-3">
            {domains.map(domain => <div key={domain.id} className={`rounded-xl border p-4 ${domain.active ? "border-amber-400 bg-amber-50 dark:border-amber-700 dark:bg-amber-950" : "border-stone-200 bg-stone-50 dark:border-zinc-800 dark:bg-zinc-900"}`}>
                <div className={`font-mono text-xs ${domain.active ? "text-amber-800 dark:text-amber-300" : "text-stone-600 dark:text-zinc-400"}`}>{domain.id}</div>
                <div className="mt-3 text-xs leading-5 text-stone-500 dark:text-zinc-500">{domain.detail}</div>
                <div className="mt-4">
                  {domain.active ? <span className="rounded-full bg-amber-600 px-2 py-1 text-[10px] font-semibold uppercase tracking-wide text-white">addressed now</span> : <span className="rounded-full border border-stone-200 px-2 py-1 text-[10px] uppercase tracking-wide text-stone-400 dark:border-zinc-700 dark:text-zinc-500">available later</span>}
                </div>
              </div>)}
          </div>
        </section>

        <section className="bg-stone-50 p-5 dark:bg-zinc-900" aria-label="Current operation">
          <div className="text-xs font-medium text-stone-500 dark:text-zinc-400">Current operation</div>
          <div className="mt-4 rounded-xl border border-amber-300 bg-white p-4 dark:border-amber-800 dark:bg-zinc-950">
            <div className="font-mono text-xs text-amber-700 dark:text-amber-400">request path</div>
            <div className="mt-2 font-mono text-sm font-semibold text-stone-900 dark:text-zinc-100">domain_id: domain-b</div>
            <div className="mt-3 text-xs leading-5 text-stone-600 dark:text-zinc-400">Only the addressed Domain supplies the task contract and state for this operation.</div>
          </div>
          <div className="mt-3 text-xs leading-5 text-stone-500 dark:text-zinc-500">A later operation can address another Domain without merging the two.</div>
        </section>
      </div>

      <figcaption id="hybrid-instance-caption" className="border-t border-stone-200 px-5 py-3 text-xs leading-5 text-stone-500 dark:border-zinc-800 dark:text-zinc-400">
        One instance can retain multiple distinct Domains. Coexistence is instance-level; each operation remains scoped to one <code>domain_id</code>.
      </figcaption>
    </figure>;
};

export const PatternExplorer = () => {
  const patterns = [{
    name: "Structured targets",
    question: "What target follows these inputs?",
    shape: "configured inputs + optional action → observable target",
    detail: "Declare observable input and target paths. Include an action only when it belongs to the relationship, and keep every predicted target out of the inputs.",
    example: "Illustrative state change, region prediction, or structured action geometry.",
    href: "/docs/neuroadapt/design-transition-domains",
    link: "Transition Domain design",
    tone: "border-sky-200 bg-sky-50 dark:border-sky-900 dark:bg-sky-950",
    dot: "bg-sky-500"
  }, {
    name: "Contextual outcomes",
    question: "Which choice works here?",
    shape: "decision context + executed policy → outcome",
    detail: "Bind the context available at decision time to the executed choice and the result returned to Adapt-1.",
    example: "Illustrative routing, allocation, recovery, or operating-mode setup.",
    href: "/docs/neuroadapt/make-behavior-improve-from-feedback",
    link: "Feedback and outcomes",
    tone: "border-amber-200 bg-amber-50 dark:border-amber-900 dark:bg-amber-950",
    dot: "bg-amber-500"
  }, {
    name: "Bounded objectives",
    question: "Which action moves a public state toward the goal?",
    shape: "bounded state + candidate action → successor state → objective",
    detail: "Use bounded transition scoring only when the state, action mapping, numeric bounds, and objective are public.",
    example: "Illustrative inventory, battery, distance-to-target, or set-point control.",
    href: "/docs/neuroadapt/make-behavior-improve-from-feedback#bounded-transition-scoring",
    link: "Bounded transition scoring",
    tone: "border-teal-200 bg-teal-50 dark:border-teal-900 dark:bg-teal-950",
    dot: "bg-teal-500"
  }, {
    name: "Delayed outcomes",
    question: "Must a later result revise an earlier choice?",
    shape: "state + action → next state → delayed or terminal outcome",
    detail: "Use sequential learning only when actions change later states and later outcomes carry information about earlier decisions.",
    example: "Illustrative route planning, multistage control, inventory, game, or hidden action-effect task.",
    href: "/docs/neuroadapt/make-behavior-improve-from-feedback#sequential-feedback-for-delayed-outcomes",
    link: "Sequential feedback",
    tone: "border-indigo-200 bg-indigo-50 dark:border-indigo-900 dark:bg-indigo-950",
    dot: "bg-indigo-500"
  }, {
    name: "Controlled interventions",
    question: "What does each action do?",
    shape: "matched state + assigned action → consequence",
    detail: "Use safe, comparable trials when normal action choice is biased by operating conditions. This is a collection pattern, not automatic causal proof.",
    example: "Illustrative intervention block around a transition learner.",
    href: "/docs/neuroadapt/design-transition-domains",
    link: "Transition Domain design",
    tone: "border-violet-200 bg-violet-50 dark:border-violet-900 dark:bg-violet-950",
    dot: "bg-violet-500"
  }, {
    name: "Contrastive outcomes",
    question: "Where does each choice fail?",
    shape: "context + policy → positive, partial, or negative result",
    detail: "Use successes and failures when positive examples leave several policies equally plausible.",
    example: "Illustrative policy comparison with visible counts and fallback behavior.",
    href: "/docs/neuroadapt/make-behavior-improve-from-feedback",
    link: "Feedback and outcomes",
    tone: "border-rose-200 bg-rose-50 dark:border-rose-900 dark:bg-rose-950",
    dot: "bg-rose-500"
  }, {
    name: "History and phase",
    question: "Does recent order change the result?",
    shape: "state + bounded history + visible phase + action → next observation",
    detail: "Keep history length and field order stable. Supply phase only when it is observable at prediction time. Bounded history is an input design, not delayed credit.",
    example: "Illustrative staged workflow or repeated-control setup with an observable recent window.",
    href: "/docs/neuroadapt/design-transition-domains",
    link: "Transition Domain design",
    tone: "border-emerald-200 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950",
    dot: "bg-emerald-500"
  }];
  return <div className="not-prose my-8">
      <div className="grid gap-3 md:grid-cols-2 xl:grid-cols-3">
        {patterns.map(pattern => <section key={pattern.name} className={`rounded-xl border p-4 ${pattern.tone}`}>
            <div className="flex items-center gap-2">
              <span className={`h-2.5 w-2.5 rounded-full ${pattern.dot}`} />
              <h3 className="text-sm font-semibold text-stone-900 dark:text-zinc-100">{pattern.name}</h3>
            </div>
            <div className="mt-3 text-sm text-stone-700 dark:text-zinc-300">{pattern.question}</div>
            <div className="mt-4 rounded-lg border border-white/70 bg-white/70 p-3 font-mono text-xs leading-5 text-stone-600 dark:border-zinc-800 dark:bg-zinc-950/70 dark:text-zinc-400">{pattern.shape}</div>
            <div className="mt-4 border-t border-stone-200/80 pt-4 dark:border-zinc-800">
              <div className="text-xs leading-5 text-stone-600 dark:text-zinc-400">{pattern.detail}</div>
              <div className="mt-3 text-xs leading-5 text-stone-500 dark:text-zinc-500">{pattern.example}</div>
              <a href={pattern.href} className="mt-3 inline-flex text-xs font-semibold text-amber-700 no-underline hover:underline dark:text-amber-400">{pattern.link} →</a>
            </div>
          </section>)}
      </div>
    </div>;
};

export const EvaluationStrip = () => {
  const checks = [{
    label: "Admit",
    detail: "Confirm the intended learner accepted the record.",
    tone: "border-sky-200 bg-sky-50 dark:border-sky-900 dark:bg-sky-950"
  }, {
    label: "Compare",
    detail: "Reuse a frozen set of seen and held-out queries.",
    tone: "border-amber-200 bg-amber-50 dark:border-amber-900 dark:bg-amber-950"
  }, {
    label: "Control",
    detail: "Mask or shuffle the relationship while preserving the record.",
    tone: "border-violet-200 bg-violet-50 dark:border-violet-900 dark:bg-violet-950"
  }, {
    label: "Repeat",
    detail: "Use fresh Domains and verify read stability without writes.",
    tone: "border-emerald-200 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950"
  }];
  return <figure className="not-prose my-8 overflow-hidden rounded-2xl border border-stone-200 bg-white dark:border-zinc-800 dark:bg-zinc-950" aria-labelledby="evaluation-strip-caption">
      <div className="grid gap-px bg-stone-200 dark:bg-zinc-800 sm:grid-cols-2 lg:grid-cols-4">
        {checks.map(check => <section key={check.label} className={`p-4 ${check.tone}`}>
            <div className="font-mono text-xs font-semibold uppercase tracking-widest text-stone-700 dark:text-zinc-300">{check.label}</div>
            <div className="mt-3 text-xs leading-5 text-stone-600 dark:text-zinc-400">{check.detail}</div>
          </section>)}
      </div>
      <figcaption id="evaluation-strip-caption" className="border-t border-stone-200 px-5 py-3 text-xs leading-5 text-stone-500 dark:border-zinc-800 dark:text-zinc-400">
        Storage, learner admission, fit, nearby held-out behavior, and read stability answer different questions.
      </figcaption>
    </figure>;
};

Domain design is open-ended. A Domain declares a stable task interface, but it does not prescribe one way to organize observations, actions, outcomes, feedback, or learning.

A Domain can support more than one form of learning. Each observation or outcome affects only the learning surfaces whose evidence conditions it satisfies.

<Info>
  The patterns below cover one explored slice of the design space. They are not API modes, a taxonomy, a capability boundary, or the only ways to teach Adapt-1 inside a Domain. If none fits, design another setup around the observable relationship the application needs.
</Info>

## Start from the task relationship

Before choosing learner settings, describe the task in ordinary language:

* What can the application observe?
* What objects, states, actions, and outcomes need names?
* What result should Adapt-1 return?
* Does each choice receive its own immediate outcome?
* Does an action change the state encountered next?
* Must a later outcome revise the value of an earlier choice?

These questions determine the useful Domain shape more reliably than the length of a run or the order in which records arrive.

## The Domain supplies the vocabulary, not the solution

A fresh Core instance enters the declared task scope without pretrained task-specific priors, a solved policy, or accumulated task history. It does not already know which action works, which hidden rule governs the task, which sequence reaches the goal, or which output is correct.

This does not mean zero configuration. A Domain gives Core the public vocabulary and task interface needed to participate.

| Domain element          | Plain-language meaning               | Examples                                                           |
| ----------------------- | ------------------------------------ | ------------------------------------------------------------------ |
| **Entities**            | The kinds of things that can appear  | ticket, customer, machine, package, container                      |
| **Relations**           | How those things may be connected    | assigned to, above, compatible with, moves toward                  |
| **Signals**             | Observable measurements or state     | urgency, temperature, rank, position, inventory level              |
| **Actions or policies** | Choices available to the application | escalate, adjust, move left, reorder, place object                 |
| **Events**              | Occurrences that may be recorded     | observation, execution, transition, feedback                       |
| **Outcomes**            | The public meaning of a result       | resolved, failed, advanced, collided, reward received              |
| **Result contract**     | What the application expects back    | selected action, predicted value, coordinates, ranked alternatives |

A Domain may declare that `escalate`, `reply`, and `request_information` are available support actions. It may declare that `resolved` is a successful native outcome. It should not predeclare which action is best for the current ticket unless that preference is intentionally part of the public contract.

The same boundary applies to physical and sequential tasks. A Domain can define what an object, movement, coordinate, operating state, or reward represents without supplying the hidden action-effect mapping that Core is expected to form from experience.

<Info>
  A Domain vocabulary is an interface, not task training data. It provides public meanings and available operations. Task-specific mappings, useful choices, supported explanations, and reusable structure must still form from live evidence.
</Info>

## Choose by the kind of task

| If the task sounds like this                                                          | Illustrative applications                                                                                                          | Start with                                                                                                                  |
| ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Keep evidence and constraints organized for one continuing case                       | Equipment incidents, investigations, changing project constraints, competing explanations                                          | An ordinary Domain with defaults. Specialized learner configuration is not required merely because information accumulates. |
| Choose among actions and receive a result attributable to that choice                 | Escalate or answer a support ticket, select a recovery procedure, route a current job, make a visible-state higher-or-lower choice | Ordinary contextual policy feedback                                                                                         |
| Predict an observable output from current inputs                                      | Predict the next temperature band, landing position, object region, normalized coordinates, or resource state                      | Structured transition learning                                                                                              |
| Compare how candidate actions change a bounded public state toward a numeric goal     | Move inventory toward an operating range, improve a battery level, reduce distance to a target, approach a declared set point      | Bounded transition scoring                                                                                                  |
| Let a later or terminal outcome revise earlier choices that changed subsequent states | Warehouse routing, multistage process control, inventory decisions with delayed shortages, games, hidden action-effect tasks       | Sequential learning                                                                                                         |
| Process independent items whose actions do not affect later items                     | Classify documents, label unrelated images, answer independent visual questions, score recommendations with immediate feedback     | Ordinary feedback or structured prediction, not sequential learning                                                         |
| Return a specialized result once without retained adaptation                          | Answer or point from one image, calculate a frozen structured result, inspect a fixed input                                        | A stateless route may be sufficient. A learning Domain may not be needed.                                                   |

## Similar-looking tasks can require different designs

Episode length does not determine the learning relationship.

* A long episode with an immediate result after every independent choice can use ordinary contextual feedback.
* A chronological dataset of unrelated samples is not sequential.
* Adding recent history as an input feature does not automatically create delayed credit.
* A two-step task is sequential when the first action changes the later state and the final outcome must revise that first action.
* Predicting the next observation and deciding whether that transition was useful are different relationships.
* Compatible relationships can coexist inside one Domain, but they should not be collapsed into one learner view.

<Note>
  Ask whether the action changes what happens next and whether later information must revise an earlier decision. If both are true, sequential learning may fit. If the current choice receives its own sufficient outcome, ordinary contextual feedback is usually the correct starting point.
</Note>

## Multiple Domains per instance

One Core instance can retain multiple distinct Domains. Their contracts, evidence, and learned state coexist, but every operation addresses one `domain_id`. Applications can switch Domains across calls without blending their state or executing them simultaneously.

<HybridInstanceFigure />

## Example patterns

Use these cards as questions about evidence shape, not as a menu of permitted Domain types. Open a card only when its setup is relevant.

<PatternExplorer />

## Pattern variations

The examples can be changed without turning them into a closed taxonomy:

| Design move                            | What can change                                                                                                  |
| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Modify one learner view**            | Representation, event boundary, history, grouping, target, support, or feedback horizon                          |
| **Compose evidence inside one Domain** | Add compatible context, contrast, or explicit history to the setup used for that operation                       |
| **Use multiple Domains**               | Retain multiple distinct Domains in one instance and address the appropriate `domain_id` one operation at a time |
| **Create a new setup**                 | Start from a different observable relationship and define its information condition, route, and result contract  |

There is no final list of Domain setups. A new setup does not need a name or a place on this page. It needs a clear information boundary, an applicable route contract, and an evaluation that shows what its evidence can and cannot support.

## Record separation

| Record                       | Keep here                                                                                                  |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Operational record**       | Complete before and after observations, execution details, timestamps, provenance, and application metrics |
| **Learner view**             | Configured observations and permitted derived fields available before the consequence                      |
| **Application-only context** | Hidden state, preferred actions, solver labels, ground truth, and downstream acceptance logic              |

## Validation

A successful write does not prove learner admission or useful reuse. Start from a cold checkpoint, preserve a frozen evaluation set, and keep coverage separate from repetition.

<EvaluationStrip />

Keep raw API responses, environment truth, harness-derived metrics, and the final claim separate. Repeat the frozen read set without writes and verify that the applicable learner state remains unchanged.

<CardGroup cols={3}>
  <Card title="Design transition Domains" href="/docs/neuroadapt/design-transition-domains">
    Configure event boundaries, evidence geometry, targets, support, and abstention.
  </Card>

  <Card title="Learn from outcomes" href="/docs/neuroadapt/make-behavior-improve-from-feedback">
    Bind decisions, execution, consequences, and scoped feedback.
  </Card>

  <Card title="Monitor the resulting behavior" href="/docs/neuroadapt/measure-online-adaptation">
    Follow admission, evidence reuse, learner state, execution, and revision.
  </Card>
</CardGroup>