> ## Documentation Index > Fetch the complete documentation index at: https://docs.reilabs.org/llms.txt > Use this file to discover all available pages before exploring further. # 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. ```json theme={null} { "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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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](/docs/neuroadapt/design-transition-domains). ## 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](/docs/neuroadapt/evaluate-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](/docs/neuroadapt/operational-behavior-and-retries). ## 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.