Monitor adaptation in production

Track Adapt-1 inputs, results, application actions, outcomes, feedback, and learner-state changes over time.

Adapt-1 can change when applications send observations, events, or feedback. The operational record must show each change. Record the input, Adapt-1 result, application action, observable consequence, and information sent to Adapt-1.

Operators must be able to identify the cause of a change. Possible causes include the input contract, new evidence, feedback, application logic, and external systems.

Reasoning can occur without changing state. Attribute learning only when an eligible observation or measured outcome produces a persistent change capable of affecting a later result.

What to monitor

Keep one ordered interaction record that connects seven items:

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

Adapt-1 does not automatically receive all information that the application has. Record external observations and information returned to Adapt-1 separately.

Application interaction record

The record below belongs to the surrounding application. It is not a universal Adapt-1 response schema.

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

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.

This record lets operators identify changes in the input. Make a new Domain revision for a change to paths, types, grouping, event boundary, or target shape. Do not mix evidence from incompatible representations.

Returned result

A single status does not show the evidence or uncertainty. Store the field that the application used. Also store the returned alternatives.

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

Do not call every result a policy score. Keep the documented field names and meanings for each 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

This record shows when application logic or a fallback rule selected the operation.

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 application records the consequence but does not send it to Adapt-1

Record these channels separately. Operators can then identify the signal that can change state.

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

Evidence reuse is valid only for compatible input under the Domain contract. Keep evidence IDs and grouping context. These values show incompatible evidence and unsupported results.

Adaptation monitoring patterns

Applications can arrange state, exposure, writes, and inspection in different ways to observe how adaptation forms, carries forward, and changes. These are monitoring patterns around a workflow, not Domain types or Domain rules.

Pattern	How to structure it	What it makes observable
Cold start	Begin from fresh relevant state and preserve the first result before any task-specific observation, outcome, or feedback enters that state	Initial behavior, absence of support, and the beginning of formation
Prequential online	For each interaction, preserve the result before returning the real consequence or feedback, then continue with the same state	Change across live use without a separate teaching phase
Teaching phase	Supply a declared sequence of teaching observations or outcomes and checkpoint results and learner state throughout it	Acquisition, coverage, and the effect of the supplied teaching sequence
Frozen read	After an exposure phase, inspect a fixed set with documented non-mutating calls and verify that learner state remains unchanged	Retained behavior without further adaptation during inspection
Held-out monitoring	After teaching, inspect genuinely unobserved cases without writes during scoring	Whether formed structure carries beyond the teaching cases
Repeated fresh state	Repeat the same monitoring schedule from independently fresh state histories	Consistency and sensitivity to ordering or early experience

Cold, teaching, frozen, and held-out describe different parts of a monitoring condition. A frozen read is not held out if the instance has already observed those cases. When comparing monitoring patterns, keep the task contract, input representation, available actions, feedback interpretation, and scoring rule fixed.

Monitor transition learning

For structured transitions, watch two questions separately:

1. Did the event enter the transition learner?
2. Did later queries retrieve the intended evidence?

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
Result has high confidence but causes an incorrect application action	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

This record makes online adaptation observable. Operators can see each change and the evidence that Adapt-1 reused. They can also see application actions and learner revisions.