Build continuity across calls

The domainless State gateway lets applications reason with evidence accumulated across calls. Use it when retained evidence and corrections improve later results. Store statements with their subject and source, then query with the current question. State returns relevant context and optional structured reasoning. Corrections replace superseded record content while retaining the record ID. These workflows use State directly without a Domain declaration.

Reconstructive retrieval and source documents

Adapt-1’s retrieval is reconstructive. It combines similarity with associative completion and learned relations to recover relevant context from retained evidence. Later evidence and corrections can change what a query recovers. Mechanisms describes how that state evolves. An application can optionally combine State with retrieval-augmented generation (RAG). Use external source retrieval to fetch original passages from a document collection when the task needs exact wording or citations. Keep source identifiers with the retrieved evidence and use State for continuing context and reasoning across interactions.

Preserve source records

Keep original timestamps, source references, artifact digests, and verification identities with each record. For generic State writes, put source metadata in context. Maintain an application ledger that maps each source event to its returned memory ID and write receipt. Resolve retrieved memory IDs through this ledger and use original artifacts for exact quotations and integrity checks. Reconnect from a fresh client with the same authorized bearer identity to retrieve retained records. Verify record IDs, source metadata, and digests against the application ledger.

Work through a project change

A project assistant has a launch review date and a dependency that affects readiness. The migration schedule changes during the project.

Record	Initial information
Launch plan	Project Atlas launch review is on 12 October.
Dependency	The rollout requires customer export support, which depends on completing storage migration.
Migration plan	Storage migration is scheduled to finish on 10 October.

The example stores these records separately and queries with a question about launch dependencies and timing. It then corrects the migration date to 15 October and repeats the same query. Both reads set update_memory_state: false so the comparison isolates the record correction. Use the API key from the quickstart. Save the following as state_project.py and run python state_project.py. Each run adds three records to the State associated with that key.

state_project.py

import json
import os
from urllib.request import Request, urlopen

key = os.environ.get("ADAPT1_API_KEY")
if not key:
    raise SystemExit("Set ADAPT1_API_KEY before running this example.")

base_url = "https://rei-neuroadapt-api.reilabs.org/api/v1/memory"


def post(operation, payload):
    request = Request(
        f"{base_url}/{operation}",
        data=json.dumps({"session_id": "ignored", **payload}).encode("utf-8"),
        headers={
            "Authorization": f"Bearer {key}",
            "Content-Type": "application/json",
        },
        method="POST",
    )
    with urlopen(request, timeout=60) as response:
        return json.load(response)


records = [
    (
        "Project Atlas launch review is scheduled for 12 October.",
        "launch-plan",
    ),
    (
        "Project Atlas rollout requires customer export support, which depends on completing storage migration.",
        "dependency-record",
    ),
    (
        "Project Atlas storage migration is scheduled to finish on 10 October.",
        "migration-plan",
    ),
]

memory_ids = {}
for statement, source in records:
    stored = post("store", {
        "user_message": statement,
        "ai_message": "",
        "context": {"source": source},
    })
    memory_ids[source] = stored["storage_result"]["memory_id"]

query = {
    "user_message": "What dependencies and timing constraints should the Project Atlas launch review take into account?",
    "top_k": 5,
    "include_reasoning": True,
    "update_memory_state": False,
}
print("Before correction:")
print(json.dumps(post("query", query), indent=2))

post("correct", {
    "memory_id": memory_ids["migration-plan"],
    "user_message": "Project Atlas storage migration is scheduled to finish on 15 October.",
    "ai_message": "",
    "context": {"source": "revised-migration-plan"},
})

print("After correction:")
print(json.dumps(post("query", query), indent=2))

Inspect the change

The program prints the actual responses before and after correction. Inspect memory_context for the relevant project records and reasoning when returned. include_reasoning: true requests structured reasoning alongside context.

Check	What to inspect
Related evidence	The review date, export dependency, and migration schedule are relevant to the question.
Corrected record	The migration record now contains 15 October; its memory ID stays the same.
Reasoning	When returned, inspect how it connects the export dependency and migration timing to the launch review. The revised completion date falls after the review.

A project application can use the returned context and reasoning in its review interface, with the supporting records available for inspection. Continue storing new project information and correct existing records when their content changes.

Choose a read operation

Need	Route	Returned information
Ranked supporting records	`POST /api/v1/memory/search`	Evidence items and ranking support
Context with reasoning	`POST /api/v1/memory/query`	`memory_context`, `confidence_score`, optional `reasoning`
Expanded explanation	`POST /api/v1/memory/explain`	Evidence, concepts, connections, `conflicts`, and `resolution`
Current state	`POST /api/v1/memory/state`	State and diagnostics for the authenticated scope
Bounded capacity summary	`POST /api/v1/memory/state/summary`	Memory-capacity summary
Stored records	`POST /api/v1/memory/list`	Records in the current scope

Query, search, and explain default to update_memory_state: true. Set it to false for a read-only comparison. Explain a result describes the response fields and their limits.

Manage the record lifecycle

Operation	Route	Behavior
Correct one record	`/api/v1/memory/correct`	Replace content while retaining its ID
Store 1–50 records	`/api/v1/memory/batch_store`	Synchronous, input-ordered, non-transactional
Preview or apply pruning	`/api/v1/memory/prune`	Start with `dry_run: true`; unique memories are protected by default
Remove one record	`/api/v1/memory/delete`	Address the stored memory ID
Clear the scope	`/api/v1/memory/clear`	Explicitly start a new State history

All operations above use POST. Inspect each batch result before retrying: records stored before a later failure remain stored. The compatibility alias /api/v1/batch_store remains available.

Preserve correction history

For annotations stored through /api/v1/memory/store, preserve history separately from the replacement:

Preserve the original annotation and its source artifact outside State.
Store a separate correction record with its own ID, the target annotation ID, original and replacement text, timestamp, source reference and SHA-256 digest, and verifier identity.
Call /api/v1/memory/correct with the original memory ID, complete replacement content, and all context fields to retain.
Check storage_result.accepted, storage_result.action, and storage_result.memory_id. Retrieve the corrected annotation and separate correction record, and verify both against their sources.

The correction record and replacement are separate writes. Record each outcome and reconcile partial or ambiguous completion before retrying. Keep typed Domain source events immutable in this workflow.

Scope, summaries, and pruning options

Hosted identity follows the bearer token. The body value session_id: ignored satisfies the compatibility contract and has no effect on tenant selection./memory/state also accepts summary_only: true. When pruning, set max_records, optional max_bytes, and include_unique deliberately. Inspect the dry-run candidates before applying them with dry_run: false.A Domain is useful when events, relations, targets, or action outcomes need a stable task contract. State and Domain histories have different reset boundaries; see Operations and retries.

Explain the result

Inspect evidence, support, and unresolved information.

Create a task-scoped learner

Add a Domain when you need a separate, observable prediction target.

Get started

Concepts

Guides

Planning

Discovery

Operations

API reference

Reconstructive retrieval and source documents

Preserve source records

Work through a project change

Inspect the change

Choose a read operation

Manage the record lifecycle

Preserve correction history

Explain the result

Create a task-scoped learner

​Reconstructive retrieval and source documents

​Preserve source records

​Work through a project change

​Inspect the change

​Choose a read operation

​Manage the record lifecycle

​Preserve correction history

Explain the result

Create a task-scoped learner

Reconstructive retrieval and source documents

Preserve source records

Work through a project change

Inspect the change

Choose a read operation

Manage the record lifecycle

Preserve correction history