Explore Domain learning patterns

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Design transition Domains

Configure event boundaries, evidence geometry, targets, support, and abstention.

Learn from outcomes

Bind decisions, execution, consequences, and scoped feedback.

Monitor the resulting behavior

Follow admission, evidence reuse, learner state, execution, and revision.