Monitor adaptation in production

Record each input and Adapt-1 response alongside the application action, observable consequence, and information returned to the API. Compare learner-state identifiers across the interaction to locate persistent updates. When behavior changes, inspect the input contract and event history as well as application logic and external-system changes. Attribute learning to admitted evidence or outcomes that produce a persistent state change capable of affecting a later result. The interaction record includes the internal diagnostics exposed by each route. What a trace exposes explains how to interpret learner identities, versions, and attribution alongside the neural state and update process they describe.

What to monitor

Connect these fields in an ordered interaction record:

Surface	Record
Input contract	Domain revision, adapter version, available actions, and every field supplied to Adapt-1
Adapt-1 result	The exact route-defined prediction, selection, hypothesis, support, or abstention consumed by the application
Application commitment	The application forwards, maps, defers, or overrides the result
Exact execution	The operation and parameters sent to the external system
Observable consequence	The after-state, change, native consequence, and event boundary
Information returned	The transition event, explicit feedback, correction, or no return signal
Learner state	Evidence IDs, relevant counters, Domain/schema revision, and learner or subsystem version

Record external observations separately from the information the application sends to Adapt-1, so the trace shows which evidence was available to the learner.

Application interaction record

The following example belongs in the application’s interaction log:

{
  "interaction_id": "interaction-0042",
  "domain_id": "sorting-line-v3",
  "domain_revision": "3",
  "adapter_version": "vision-features-12",
  "input_ref": "observation-0042",
  "adapt_1_result": {
    "route": "domain_query",
    "selected_value": "divert_left",
    "evidence_memory_ids": ["memory-18", "memory-31"],
    "selection_reason": "sufficient_support"
  },
  "selected_by": "adapt_1",
  "executed_operation": "divert_left",
  "observable_consequence": "item_entered_lane_left",
  "feedback_returned": null,
  "learner_version_before": "transition-18",
  "learner_version_after": "transition-18"
}

Use the exact fields that the selected route returns. Keep the complete response with this application record.

What to capture

Input contract

Record the exact input that Adapt-1 received before each result. Include:

Domain and schema revision.
Adapter or feature-extractor version.
Available actions and their public meanings.
Numeric normalization and categorical representation.
Derived fields added by the application.
Grouping context.
Interpretations that the application adds.

Create a new Domain revision when changes to paths, types, grouping, event boundaries, or target shape make earlier evidence incompatible.

Returned result

Store the field used by the application, the returned alternatives, and the evidence or uncertainty fields supplied by the route.The response can include these fields:

transition prediction
selected value or ranked hypothesis
policy score
evidence memory IDs
support and distance
missing evidence
selection or abstention reason
Domain and learner versions

Preserve the field names and meanings documented for the selected route.

Execution record

For every operation, record:

returned Adapt-1 result
application commitment
exact executed operation
observable consequence
information intentionally returned to Adapt-1

If the executed operation differs from the Adapt-1 result, keep both values and the reason. Use one of these typical selector values:

adapt_1 | application | controller | fallback

Consequence and feedback

A later observation can show a consequence without a judgment. Explicit feedback is a separate signal.

Signal available to Adapt-1	Meaning
No return signal	Adapt-1 receives no later observation or feedback event
Observable consequence	A transition event records what visibly changed
Explicit feedback	The application sends a judgment to revise a scoped relation or policy
Rich correction	The application returns a structured error, constraint violation, or corrected value
Application-only consequence	The consequence is retained only by the application

Keep the channels separate in the log to identify the evidence and feedback supplied for each update.

Adaptation phases

Returned state and evidence can show these operational phases:

Phase	What it looks like
No support	No eligible evidence or an explicit abstention
Formation	New relevant observations change support, a prediction, or hypothesis evidence
Reuse	Compatible inputs retrieve earlier evidence and produce a supported result
Stabilization	Repeated support makes previously formed structure remain influential across later use
Revision	New or contradictory information changes a previously supported result

Inspect evidence IDs and grouping context to check whether a result used observations compatible with the Domain contract.

Adaptation monitoring patterns

Define the complete learning-run boundary before collecting results and retain it when interpreting checkpoints.

Pattern	How to structure it	What it makes observable
Cold first result	Begin the declared run from empty applicable task-specific learned state and preserve the first result before any learning evidence enters	Initial behavior and the beginning of state formation
Zero-start prequential run	Begin the complete run empty; preserve each result before returning its consequence or feedback; retain state across the declared passes, episodes, or stream	Acquisition from zero, improvement during the run, and within-run retention
Zero-start task-local run	Reset to empty applicable state for each independently redrawn task; learn from local evidence before its final result; reset afterward	Task-local acquisition without cross-task transfer
Separate acquisition phase	Use only records outside the new evaluation or deployment run to form and validate a starting checkpoint	How the starting state was earned and whether the acquisition split is clean
Frozen transfer run	Begin from a separately acquired checkpoint; use non-mutating calls; verify learner state remains unchanged throughout new work	Transfer from state earned outside the run without current-run adaptation
True warm-started run	Begin from a separately acquired checkpoint and keep learner writes enabled during the new run	The combined effect of external acquisition and continued adaptation
Repeated fresh runs	Repeat the full declared protocol from independently fresh starting histories	Consistency and sensitivity to ordering or early experience

Reuse of state accumulated inside a zero-start run is within-run retention. Held-out evaluation requires cases excluded from the learner’s earlier observations. Keep the task contract, input representation, available actions, feedback interpretation, scoring rule, and declared run boundary fixed when comparing patterns.See Choose a learning setup for the classification rule.

Monitor transition learning

For structured transitions, inspect learner admission after ingestion and evidence retrieval in later queries. Record event storage, learner admission, sample-count change, skip reason, evidence identity, support distance, and raw prediction. Also record structural validity and reconstructed state when the contract returns them. Keep the processed state separate. Inputs with no support or low support must follow the Domain abstention contract. Change the learner geometry if unrelated observations supply support. Change grouping if support contains incompatible modes. Do not use the result until the support is correct. See Design Domains for transition learning.

Monitor feedback-driven policy change

When the application uses scoped feedback, keep the committed relation, policy, and exact feedback. Also keep the learned signal that the route later returns. Connect the changed signal to later application decisions. See Monitor feedback-driven policy adaptation.

Diagnostics

Observed behavior	Inspect first
Stored event does not affect transition state	Required paths, types, event kind, learner-admission status, and skip reason
Evidence comes from the wrong context	Input geometry, category representation, group values, and support distances
Application action is incorrect despite high reported confidence	Evidence identity, disagreement, missing evidence, and the confidence contract
Application action differs from the result	Commitment mapping, override, controller, or fallback rule
State changes during a read-only inspection	Query flags, route side effects, and the subsystem version that moved
Behavior changes after deployment	Domain revision, adapter version, input distribution, returned feedback, and learner-state history

If a Domain gives unexpected results, process the recorded events in a temporary diagnostic Domain. Change one configuration item at a time. Keep diagnostic state separate from application state.

State lifecycle

Use one writer for ordered online state.
Keep stable interaction and event identifiers.
Persist the last confirmed response.
Reconcile ambiguous writes before resubmitting them.
Use the clear or reset route that controls the applicable state.
Do not reset between interactions that are meant to share learning.
Use read-only query and explanation calls for inspection. Check the learner-state versions before and after the calls.

See Operate stateful and adaptive workflows.

Operational checklist

Exact input supplied to Adapt-1
Domain, schema, and adapter revision
Complete route response
Result actually consumed by application code
Commitment, override, or fallback provenance
Exact executed operation
Observable consequence and event boundary
Feedback actually returned
Evidence IDs, support, and abstention reason
Learner-state change across the interaction
Transport failures kept separate from application behavior

Get started

Concepts

Guides

Planning

Discovery

Operations

API reference

What to monitor

Application interaction record

What to capture

Monitor transition learning

Monitor feedback-driven policy change

Diagnostics

State lifecycle

Operational checklist

​What to monitor

​Application interaction record

​What to capture

​Monitor transition learning

​Monitor feedback-driven policy change

​Diagnostics

​State lifecycle

​Operational checklist

What to monitor

Application interaction record

What to capture

Monitor transition learning

Monitor feedback-driven policy change

Diagnostics

State lifecycle

Operational checklist