Adapt-1 API overview

Use Core directly through structured APIs that retain, revise, and expose task-relevant state.

Adapt-1 is the direct programmatic surface of Core. It lets an application send observations and outcomes, receive structured results, and carry useful, revisable state into later work.

Default path: choose the route that returns the result your application needs and use the service defaults. No task-specific training dataset, generated language, or learner tuning is required to begin.

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 shape the next task-level consequence. Adapters can translate external modalities and controllers can execute operations; neither supplies the task reasoning that Core performs.

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 instance settles into a current interpretation, prediction, policy view, or decision under the task contract.
5. The application can inspect that moment, use it in its own work, or pass it onward without forcing a language layer.
6. The next call enters a changed instance.

This is why reading state or receiving a response is not the product by itself. Both expose selected aspects of a substrate that uses state to reason and reasoning to change state.

Domain contract

A Domain declares the public task structure a workflow needs, such as entities, relations, observable fields, available actions, native outcomes, and the expected result. Candidate hypotheses, custom rules, policy templates, and specialized learner mappings are optional.

Adapt-1 resolves omitted learning settings. Start with the smallest stable task contract, then add an override only when an observed integration requirement calls for it.

A Domain defines the task; it does not provide the current answer, hidden mapping, preferred action, or solved trajectory. Live observations, outcomes, and feedback determine which structure receives support during use.

Structured transition learning is one specialized Domain configuration. When a workflow needs it, Design a transition Domain explains learner inputs, event admission, target structure, support, and abstention.

Domain contents and learned state

A Domain can declare whichever parts of the stable task grammar the workflow uses: entities, relations, signals, event and outcome semantics, action or plan interfaces, and an output contract. Candidate hypotheses, custom rules, policy templates, and specialized learner mappings are optional.

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
              ↓
current interpretation, support, and revisable state

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 turn its work into prose to be useful. Adapt-1 gives software access to the current reasoning context through contract-specific views, each reflecting the work of the continuing instance in a different way.

Application needs	What Core can make available
A constraint or prior decision carried into later work	Context, confidence, and relevant supporting 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

A current result can inform validation, application logic, a UI, or another downstream system. What matters is its relationship to the continuing instance and task contract.

Adapt-1 and Rei Chat are separate products. When people need prose, Rei Chat can articulate a completed Core result; language remains a boundary around the reasoning, not its owner.

The input path depends on the selected gateway and the application. Adapt-1 exposes the contract-defined view that fits that work.

API gateways

Adapt-1 exposes several public gateways into the same substrate. They are ways to take part in or inspect continuing work, rather than 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	The task benefits from declared entities, relations, hypotheses, rules, signals, or explanations	Domain scope, events, queries, feedback, hypotheses, predicted observations, evidence, and explanations
Interval policy	The documented interval and scalar policy should update from ordered observations	Interval-policy state and prediction.<output_key>

An application can use one gateway or compose several. For example, it can preserve operating constraints, reason inside a declared Domain, incorporate outcomes, and use the current decision in 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 interpret, use, or execute the current result.

This flexibility makes Adapt-1 usable in systems where prose would be unnecessary overhead: monitoring, prediction, allocation, classification, control, personalization, and other application domains.

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

Use Ways to use Adapt-1 to compare the available workflows, or go directly to the Adapt-1 quickstart for authentication and first calls.