Verify feedback-driven adaptation

Confirm that scoped feedback changes the intended learned signal and later application behavior.

This page describes feedback-driven scoring for one (relation, policy) entry. Use this method when application feedback must change a later preference in the same Domain.

Use operational monitoring to record the exact decision, consequence, feedback write, and learned signal. Operators can then see the change and its application use.

Monitoring loop

read current scoped state
-> consume or commit a policy
-> observe the application consequence
-> submit explicit feedback
-> read the updated scoped state
-> monitor later use

Step	Route	What to preserve
Create or identify the Domain	POST /api/v1/domains	domain_id and Domain revision
Read current state	POST /api/v1/domains/{domain_id}/query	Complete response and the relevant policy_scores entry when returned
Submit feedback	POST /api/v1/domains/{domain_id}/feedback	Feedback payload, status, stable interaction ID, relation, and policy
Read later state	POST /api/v1/domains/{domain_id}/query	Updated scoped entry, evidence, and learner-state metadata

Decision binding

Keep an application-owned record beside the API calls:

{
  "interaction_id": "interaction-0042",
  "domain_id": "routing-v2",
  "relation": "destination_zone",
  "policy": "route_left",
  "returned_value": "route_left",
  "executed_operation": "route_left",
  "observable_consequence": "item_arrived",
  "feedback_returned": "positive"
}

Submit only the fields that the selected route accepts. Keep application-only fields in the application record. Do not put these fields in the feedback payload.

A policy is the context-dependent preference or rule that feedback changes. The application can map a policy to an external operation. The application can also store an operation identifier in the policy field. In both cases, keep the returned value and executed operation separately.

Update scope

If the route contract requires structured metadata, store the values that identify the specified update:

{
  "metadata": {
    "run_id": "production-line-a",
    "relation": "destination_zone",
    "policy": "route_left"
  }
}

The path contains domain_id. Do not copy it to unrelated fields. Do not put the relation and policy only in free text.

After feedback, monitor:

• The specified scoped entry changed.
• Unrelated entries did not change.
• A later application decision used the updated value.
• The application recorded the operation and consequence.
• corrections or later feedback changed the preference again.

If an unrelated entry changes, examine the metadata, filtering, Domain boundaries, and feedback payload.

Learned signal

If the route returns policy_scores, use the entry for the committed relation and policy. Keep the complete object. Do not keep only one number.

The route can also return supporting memories, Core support, hypotheses, missing evidence, or other explanation fields. Keep the documented meaning of each field. Do not interpret a confidence or support field as a policy score.

A changed policy score shows scoped adaptation. It does not prove that the application used the policy. It does not prove that the external operation was successful. Connect the later result to commitment, execution, and consequence.

Ties and absent preferences

If policy entries have equal values, the application must select the fallback behavior. The application must also select a fallback when no learned preference exists. Record:

returned policy state
selected_by = application | controller | fallback
fallback rule
executed operation

Record a fallback choice as application behavior. Do not record it as learned Adapt-1 behavior.

Transition evidence and feedback

The application can record an observable consequence without a positive or negative value. Feedback is a separate signal that changes a scoped relation or policy.

API operation	Purpose
Domain transition event	Record what visibly changed
Domain feedback	Return an explicit judgment or correction
Domain query	Read the current route-defined learned state
Domain explain	Inspect evidence and uncertainty around the result

See Learn from feedback and consequences and Design Domains for transition learning.

Interval-policy state

The interval-policy routes use:

POST /api/v1/domains/{domain_id}/adapt/events
POST /api/v1/domains/{domain_id}/adapt/predict

Monitor that workflow through prediction.<output_key>. Do not rename its result to policy_scores.

Operational checklist

• Stable Domain, interaction, and event identifiers
• One writer for ordered state
• Exact relation and policy scope
• Complete result consumed before feedback
• Committed and executed operation
• Observable consequence
• Exact feedback returned
• Scoped learned signal before and after the interaction
• Unexpected changes outside the intended scope
• Application fallback provenance when no preference is available
• Learner-state and subsystem versions
• Ambiguous writes reconciled before resubmission

For the complete input-to-execution record, see Monitor online adaptation across use.