Skip to main content
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. Record the executed decision and its consequence alongside the feedback payload. Compare the scoped learned signal before feedback with its value in later responses, and record how the application uses it.

​
Classify the run before scoring

Fix the complete learning-run boundary and record the applicable task-specific learner state at its start.
  • Zero-start adaptation: the complete run begins with empty applicable learned state and earns state from its own outcomes.
  • Separate acquisition: the starting state was formed from records outside the run under a split fixed before evaluation.
  • Frozen transfer: separately acquired state is used with no learner writes during the new run.
  • True warm start: separately acquired state exists at run start and learner writes continue.
State earned earlier inside the same zero-start run is within-run retention. See Choose a learning setup.

​
Monitoring loop

  1. read current scoped state
  2. consume or commit a policy
  3. observe the application consequence
  4. submit explicit feedback
  5. read the updated scoped state
  6. monitor later use

​
Decision binding

Keep an application-owned record beside the API calls:
Build the feedback payload from the selected route’s accepted fields, keeping application-only values in the interaction record. A policy identifies the behavior or preference that feedback updates. The application may map it to an external operation or use an operation identifier as its value. Preserve the returned policy value and the operation actually executed.

​
Update scope

If the route contract requires structured metadata, store the values that identify the specified update:
The request path identifies domain_id; structured fields identify the relation and policy. After feedback, check whether:
  • The specified scoped entry changed.
  • Entries outside the intended scope changed.
  • 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, retain the complete entry for the committed relation and policy. Preserve other explanation fields under their documented names and meanings. Confidence and support fields follow their own route contracts.
Verify the policy-score change in the response, then inspect the application record to establish which operation ran and what consequence followed.

​
Check action coverage before freezing

Inspect admitted evidence for each permitted policy in the contexts where it will be used. A large total sample count can hide policies with very few measured outcomes. Count executed interactions, submitted feedback records, and acknowledged learner admissions separately. Record outcomes withheld by the experiment before submission. Before collecting acquisition data, check that the split leaves reachable training trajectories and enough eligible episodes. A filter that excludes held-out states can discard whole trajectories when intermediate states overlap. For sequential learning, compare distinct episodes represented in retained admitted feedback with minimum_episodes. For each policy, retain the observed reward range, relevant context coverage, admission results, and the support or effective-sample diagnostics the route actually returns. Keep raw record counts separate from weighted or effective counts. When a weakly supported policy ranks above well-measured alternatives, inspect priors, transferred evidence, reward scaling, and the source of the score. Collect additional measured outcomes for poorly covered choices during the acquisition phase, then validate on held-out cases before freezing. Set coverage requirements from the task’s variability and validation results. See Learning schedules for the acquisition boundary and Monitor adaptation for the complete interaction record.

​
Ties and absent preferences

Define application fallback behavior for tied policy entries and absent preferences. Record:
Attribute fallback choices to the application in the interaction record.

​
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. See Learn from feedback and consequences and Design Domains for transition learning.

​
Interval-policy state

The interval-policy routes use:
Monitor that workflow through its prediction.<output_key> response field.

​
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.