Feedback can change the rule behind the next action¶
Cross-Domain EchoesShared pattern · Feedback
A busy exception desk can reveal that the standard workflow was drawn around the wrong assumptions. An interactive system can discover that its current user model predicts poorly as later behavior becomes available. In both, feedback can return to the rule or representation that shaped the original action. This differs from simply handling one more exception or showing one more recommended item. The diagrams trace the full return path: a model guides action, the resulting activity yields evidence, and that evidence can revise the model used next time. The signal still needs interpretation; neither a diverted parcel nor a click automatically explains what went wrong.
Choose a role to see its counterpart in both examples. The diagrams show relationships, not measured quantities.
Operations design
Exceptions can revise the normal-flow rule
Read Exception ManagementDomain-specific abstraction
Exception frequency and type are returned upstream when they show that the standard path is systematically mis-specified.
In this example: The exception channel still handles genuine edge cases. More diverted work does not automatically mean the normal rule should be rewritten.
Human–computer interaction
Later evidence can revise a user representation
Read User modelingDomain-specific abstraction
Observed interactions update an uncertain user model; its predictions select assistance or interface behavior, and later evidence can correct model errors.
In this example: An interaction is not a transparent statement of a person’s identity or preference. The model is instrumental and uncertain.
This internal representation helps determine what the system does next.
Written comparison
The current rule or representation
Operations design
A declared normal-flow specification
Human–computer interaction
An uncertain model of a user
This internal representation helps determine what the system does next.
The action it shapes
Operations design
Normal-path processing or exception diversion
Human–computer interaction
Selected content, assistance or interface behavior
The resulting activity supplies evidence partly within a context the system itself selected.
The evidence returned
Operations design
Exception frequency and type
Human–computer interaction
Observed interactions and later evidence
Signals require interpretation before being treated as evidence of a systematic mismatch.
The return that closes the loop
Operations design
Modify the normal-flow specification
Human–computer interaction
Correct represented attributes or predictions
The evidence affects a subsequent input to action by changing the rule or model, not only the current output.
What carries across
Find where the feedback returns. Repairing the current output and revising the rule that keeps producing it are different interventions.
Where the comparison stops
Exception routing uses declared process criteria; a user model infers uncertain characteristics of a person. A click is not equivalent to a confirmed off-plan shipment.
- The sources establish correction pathways, not guaranteed convergence, unbiased observations or improvement on every revision.
- User control, explanation, privacy and evaluation remain specific requirements of personalization; no inference about a person is justified by this analogy alone.
Conditions for this comparison
- Exception patterns warrant upstream revision only when they indicate systematic mis-specification rather than ordinary edge cases.
- The user model remains revisable and errors can be tested against later evidence.
- The diagram shows a correction-capable implementation, not every recommender or every exception desk.
Source entries
Shared pattern
Feedback
Prime
Core Idea
Feedback is the structural arrangement in which a portion of a system's output is routed back to influence its subsequent input, closing a loop between cause and effect. The essential commitment is that the system's own behavior becomes a driver of its own behavior on the next cycle: the present depends not only on the external input but on the system's prior output. Every feedback arrangement specifies (1) the variable being measured or tapped at the output, (2) the path by which that signal returns to the input, (3) the sign and strength of the coupling — whether the returned signal opposes, reinforces, or conditionally modifies the input — and (4) the timescale on which the loop closes.
Operations design
Exception Management
Domain-specific abstraction
Core Idea
The pattern's four-part skeleton is: a *deviation detector* that classifies arriving items as on-plan or off-plan according to declared criteria; a *diversion mechanism* that routes off-plan items out of the normal flow before they disrupt it; a dedicated *exception channel* with its own latency targets, staffing, tooling, and escalation rules; and a *feedback loop* that propagates exception frequency and type back upstream to modify the normal-flow specification when the exception rate signals a systematic mis-specification rather than a random deviation.
Human–computer interaction
User modeling
Domain-specific abstraction
Core Idea
A user model is an uncertain instrumental representation rather than the person, inferred traits can drift or be wrong and adaptation raises transparency, privacy and feedback-loop concerns. Explicit profile data and observed interactions update a structured or probabilistic model, whose predictions select content, assistance or interface behavior and whose errors are corrected through later evidence.