Adapt-1 foundations

A self-contained adaptive learning and reasoning substrate that forms, revises, and applies structure while it operates.

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.

Choose what to build

Start from the result your application needs.

Make the first call

Authenticate and make the first Core call.

Use a direct adaptive result

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

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

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

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

I need continuity

Preserve evidence and constraints, and let later evidence revise what remains relevant.

I need domain reasoning

Give Core a task contract and reason over domain-shaped evidence.

I need transition learning

Configure observable consequences for learning. Inspect evidence reuse, abstention, and failure conditions.

I need adaptation from outcomes

Close the loop between a result, its outcome, and later behavior.

I need machine-actionable output

Consume machine-readable results without a language-generation step.

I need an audit view

Inspect evidence, support, conflicts, and missing information.

I need reliable operation

Handle retries, failures, and ambiguous stateful writes without corrupting the instance.

I need to monitor adaptation

Follow acquisition, transfer, revision, execution, and external outcomes across ordered use.