Schematic state fingerprints across calls. Color distinguishes declared scope, observations, supported structure, and revision; curve shape is not a score, trajectory, or sequence of internal modules.
;
};
Adapt-1 gives software direct access to **Core**, a self-contained adaptive learning and reasoning substrate, and returns machine-readable results applications can inspect and use directly. Core maintains its own evolving state and forms task-relevant structure from observations and outcomes.
**Adapt-1 reasons by learning and learns by reasoning.** Work changes the state of the substrate. Useful structure can persist, corrections can revise it, and later calls begin from what the instance has already formed. Generated text is optional.
The Core surface can produce structured predictions, ranked hypotheses, evidence, confidence, conflicts, and state with **zero generated LLM tokens**. Separately, Adapt-1 requires no task-specific training dataset before the first operation. Explicit task configuration may still be supplied; configuration is not training data.
Adapt-1 is domain-configurable rather than domain-specific. Its public contracts define how an application interacts with Core; they do not prescribe the subject matter of the task. The examples in this documentation illustrate configurations of those contracts rather than enumerating the tasks developers may define and evaluate.
Start from the result your application needs.
Authenticate and make the first Core call.
Bring a contract-defined result into application logic without a language-generation step.
## Operating substrate
State is one part of the operating substrate. Core uses accumulated evidence and relationships to interpret new observations, form and compare hypotheses, update policies, expose uncertainty, and produce task-level results. Adapters can translate external modalities and controllers can execute operations; neither supplies the task reasoning that Core performs.
Adapt-1 is designed for streams where evidence arrives incrementally, observations may be incomplete, and outcomes may be delayed. A retrieved association, an induced hypothesis, a transition prediction, and a policy preference are different claims supported by different evidence.
| Declared task structure | Evidence-shaped state |
| ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- |
| Field meanings, entities, relations, action semantics, outcomes, candidate hypotheses, rules, and result contracts | Supporting observations, learned relationships, active alternatives, policy or transition state, uncertainty, and revision |
| Defines what information means inside the task | Changes which interpretations, predictions, or decisions receive support during use |
Explicit structure keeps task meaning stable; evidence-shaped state lets experience change what the instance supports. A current result reflects their interaction.
The important behavior is the loop between reasoning and learning:
1. An observation, event, constraint, or outcome enters the instance.
2. Core interprets it against the structure that currently exists.
3. New relationships or hypotheses can form; existing associations can remain active together, strengthen, weaken, or be revised.
4. The current state settles into a result for the task contract.
5. That result can be returned as structured data, inspected through evidence, or passed directly to downstream application logic.
6. The next call enters a changed instance.
This is why state access is not the product by itself. It exposes part of a substrate that uses state to reason and reasoning to change state.
## Domain contract
A Domain is an optional task definition for work that benefits from declared entities, relations, observables, actions, outcomes, evidence conditions, learning settings, candidate hypotheses, rules, and structured results. Optional does not mean secondary: when a task benefits from a stable public frame, a Domain makes that frame explicit and reusable while leaving task-specific structure to form from use.
Domains are not a limit on what Core can ingest, retain, revise, or organize. Core can also operate through other documented paths when an application needs continuity or direct state interaction without a Domain. One instance can use more than one Domain when distinct task definitions are useful; each Domain operation names the relevant `domain_id`.
For structured transition learning, a Domain and its events define the evidence space for that configuration. Configured paths, types, value geometry, grouping, event boundaries, and target shape determine how evidence can be reused. That transition configuration is one documented use of a Domain, not the definition of every Domain.
The interval-policy routes are Domain-scoped. They are one documented way to configure a specific adaptive output inside a Domain, not a separate architectural path or a definition of what Domains can support.
A task definition lets an application state its public vocabulary, field meanings, available actions, outcome semantics, and expected result shape. Core can then organize live evidence against the task the developer actually intends.
It defines the task; it does not provide its answer. Learning happens from the live observations, outcomes, and feedback the application provides during use, rather than from labeled examples, solved trajectories, task history, or hidden mappings supplied in advance.
Configured paths, types, value geometry, grouping, event boundaries, and target shape determine how Core reuses evidence.
The learner view can contain observable data available before the consequence and the proposed intervention. Do not include the consequence relation, preferred action, solver output, or application-only metric.
Keep three data layers separate:
| Layer | Role |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Operational record | Store all observable data from before and after the event. Also store provenance. |
| Learner view | Store observations, the intervention, and permitted derived features available before the observable consequence. |
| Application-only context | Store privileged state, preferred actions, and downstream judgments. Do not use this data in transition inputs or observation-only targets. |
User-defined field names do not give values causal meaning. Reserved fields and configured paths keep the meanings that the API defines. The client defines the event boundary and representation.
See [Design Domains for transition learning](/docs/neuroadapt/design-transition-domains) for learner admission, value geometry, grouping, target structure, support, abstention, hypotheses, and read-only calls.
## Domain contents and learned state
A Domain can declare a task definition: entities, relations, signals, event and outcome semantics, action or plan interfaces, candidate hypotheses, rules, optional policy templates, and the expected output shape.
The domain may contain meanings that are public parts of the interface. It does not supply the current episode's hidden roles, mapping, target coordinates, correct procedure, solution path, or completed world model. A fresh domain can begin without accumulated task history. As observations arrive, Core can form task-local structure, retain recurring patterns, separate persistent identity from current activity, and revise earlier assumptions when later evidence disagrees.
```text theme={null}
task contract + live observations
↓
structure forms during use
↓
structured result and evidence
```
For action-producing work, Adapt-1 can connect outcomes to prior choices, revise scoped state, form reusable action-effect models, and organize multistep action selection. Keep the observation and execution record beside those results so applications can inspect how its reasoning shaped external behavior.
## Language boundary
Core does not need to express a result as prose for the result to be useful.
| Application needs | Core-facing result |
| --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| A constraint or prior decision carried into later work | Context, confidence, and optional structured reasoning |
| A domain-level judgment | Ranked hypotheses, supporting evidence, missing evidence, and predicted observations |
| A live interval or scalar prediction through the documented interval policy | `prediction.` |
| A learned relation/policy preference | Scoped `policy_scores` |
| An audit view | Connections, `conflicts`, resolution, support, and diagnostics, using their contract-specific meanings |
The structured result can go directly to validation, application logic, a UI, or another downstream system.
Adapt-1 and Rei Chat are separate products. If users need prose, send the completed Adapt-1 result to the [Rei Chat API](/docs/api-and-sdk/index).
The input path depends on the selected gateway and the application. Adapt-1 returns the route-defined machine-readable result.
## API gateways
Adapt-1 exposes several public gateways into the same substrate. They are not isolated internal modules or sequential architectural layers.
| Gateway | Use it when | What it exposes |
| -------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **State** | Prior interactions, constraints, evidence, or decisions should affect later work | Recording, retrieval, structured reasoning, inspection, deletion, and clear controls |
| **Domains** | Work benefits from an optional declared task definition | Domain scope, events, queries, feedback, hypotheses, predicted observations, evidence, explanations, and Domain-scoped adaptive routes |
| **Domain interval policy** | A Domain needs the documented interval and scalar adaptive output | Domain-scoped interval-policy state and `prediction.` |
An application can use one path or compose several. For example, it can preserve operating constraints, work inside one or more optional Domains, incorporate outcomes, and return a structured result directly to application code.
## State persistence and revision
Core is designed around state that remains useful without becoming untouchable.
* Recurring, well-supported structure can stabilize and become available to later work.
* New observations can revise an earlier interpretation rather than merely append another record.
* Multiple active or competing associations can remain visible instead of being silently flattened into one interpretation.
* Weak or unsupported signals can lose influence.
* Corrections and outcomes can change how later inputs are interpreted.
* Each instance can expose its current state and supporting evidence through the API.
Persistence therefore means more than recall. It means future reasoning begins from a structured, revisable history.
## The application boundary
Adapt-1 does not impose one universal input pattern. Each gateway defines the request contract for that call, and applications can use the input path that fits their system. If an application already produces the accepted contract, it can send that input directly. When source formats differ, an optional boundary mapping can translate the relevant fields.
A mapping, when used, should translate formats rather than contain the task solution. Core performs the stateful reasoning and adaptation; application code decides how to consume or execute the machine-readable result.
## Inspection and diagnostics
The API exposes more than a final answer. Depending on the selected gateway, applications can inspect evidence, activated concepts, discovered connections, ranked hypotheses, conflicts, missing information, confidence, policy scores, and the current structured state.
Together, these fields form the observable behavioral surface of Core. Applications can inspect how persistent state, learned structure, support, uncertainty, and revision contribute to each result.
## Next steps
Preserve evidence and constraints, and let later evidence revise what remains relevant.
Give Core a task contract and reason over domain-shaped evidence.
Configure observable consequences for learning. Inspect evidence reuse, abstention, and failure conditions.
Close the loop between a result, its outcome, and later behavior.
Consume machine-readable results without a language-generation step.
Inspect evidence, support, conflicts, and missing information.
Handle retries, failures, and ambiguous stateful writes without corrupting the instance.
Follow acquisition, transfer, revision, execution, and external outcomes across ordered use.