Building with Core

Ways to connect Core to products, tools, and applications.

Core can supply a prediction, a supported explanation, a decision informed by outcomes, or retained context within a larger application. Adapt-1 exposes those results through structured APIs.

Application directions

These are possible integrations to explore, not reports of deployed products. Each needs its own task evidence and evaluation.

Application	Possible role for Core	The surrounding product supplies
Support operations	Learn which route works for an observed request	Request fields, available queues, execution, and resolution outcomes
Troubleshooting	Compare explanations as new observations arrive	Measurements, task-defined hypotheses, and confirmed findings
Process monitoring	Predict a declared output from completed records	Consistent measurements and later observed outputs
Personalized tools	Keep explicit preferences and corrections available	User controls, records, and isolation between users
Interactive systems	Learn task-specific choices or numeric routines through interaction	Observable state, permitted actions, an executor, and measured outcomes

Open Application ideas for more concrete workflows, including the scope of control evidence, and links to the relevant guides.

From an application to a contract

Start with the result the product will actually use. For support routing, that could be a choice among available queues. Record the route executed and its measured outcome, then return eligible feedback so later related requests can use retained experience.

A troubleshooting tool may instead need ranked explanations and evidence. A process monitor may need a prediction from completed records. A single application can combine these relationships when their inputs, outcomes, and state scopes remain clear.

The application boundary

Input boundary

External systems

Records, sensors, parsed content, events, or interactions supplied through the chosen interface

→

Reasoning substrate

Core

The continuing instance forms and revises task-relevant structure

→

Result boundary

Application

Inspect, validate, display, route, or execute the current result and its supporting evidence

This is the application contract around Core, not an ordering of Core’s internal processes. Supported workflows can return structured outcome feedback through the same declared boundary, while application-side validation and outcome measurement remain outside Core.

Applications can supply input directly through the selected interface. When a source format differs from a route’s request contract, an optional adapter can translate the boundary format; it should not contain the task solution. Core has no native visual component. A detector or visual encoder is an upstream observation source, not part of Core.

A fair adapter may expose literal or deterministic facts: coordinates, colors, tracked components, available operations, exact deltas, or public action meanings. It should not label the current goal, choose the action, or encode the episode’s hidden mapping. Record the adapter as part of the system being evaluated.

Domain contract

In Adapt-1, a Domain declares the stable grammar of a task: object and relation types, signals, event and native outcome semantics, action or plan interfaces, candidate hypotheses, rules, and the expected result shape.

It does not contain the current episode’s hidden mapping, target coordinates, correct procedure, or solution path. Structure still has to form from the observations and outcomes presented during operation. This lets a fresh Domain begin without accumulated task history while keeping public interface semantics separate from the answer.

For action-producing tasks, preserve state -> committed decision -> exact action -> transition -> native outcome as an observed trace. Scoped feedback can assign credit to the intended relation/policy; a reusable causal mechanism remains a stronger claim that requires later predictive evidence.

State revision

Early state	Revision	Later work begins with
Candidate structure has partial support	Repeated evidence strengthens it	The supported structure remains active
Several interpretations remain plausible	Their associations stay active together	Multiple alternatives remain available
A weak signal is present	Weak support loses influence	The signal has reduced weight

Several interpretations can compete until the current result settles provisionally; later observations then meet an already changed state.

Persistent state can also preserve incorrect structure. Use isolation, reset controls, ordered event handling, evidence review, and explicit feedback when operating stateful workflows.

Structured outputs

Depending on the domain and gateway, an application can consume:

• state estimates and structured predictions;
• ranked hypotheses, policies, assignments, or other domain-shaped results;
• evidence, conflicts, missing information, and confidence;
• inspectable state changes for later review.

Natural language can be added after that result exists. Rei Chat demonstrates the articulation boundary; Adapt-1 exposes the structured contract directly.

Interfaces

Adapt-1

Direct access to Core for stateful reasoning, adaptive behavior, evidence, and machine-actionable outputs.

Rei Chat

A conversational demo where a language model articulates Core’s structured result.