When feedback changes the system

A support team changes its routing rule: any request marked “urgent” goes to a specialist queue. In an illustrative example, agents soon mark more requests urgent because that queue answers faster. The rule still runs exactly as written. The input it receives has changed because people adapted to it.

A discussion of complex systems distinguishes fixed parts from systems whose components respond to one another. Its broad historical claims are not needed here. The practical question is narrower: did our intervention change the behavior that supplies our data?

A rule can be correct and still change the evidence

In a simple pipeline, a field arrives, a mapping transforms it and the destination stores the result. If the source field has a stable contract, the mapping can remain ordinary deterministic code. Repeated runs should give the same output for the same input.

Now consider a threshold that affects people. If “urgent” requests receive quicker service, staff have an incentive to use that label. The proportion of urgent requests rises. A dashboard may show that the specialist queue handles many urgent cases and conclude that the rule is needed more than ever. But the dashboard is measuring behavior under the rule, not the untouched world that existed before it.

The same problem can appear across SaaS systems. A marketing platform may label customers “high intent” based on clicks, then send more messages to that segment. More messages can create more clicks. If clicks are fed back into the segment without care, the system can reinforce its own classification. That is an illustrative mechanism, not a claim that any particular platform does this.

Question	Fixed-path check	Feedback check
Did the rule execute?	Compare input and output against the contract	Still necessary
Did the outcome improve?	Check the intended result	Check behavior changes and other causes
Is the input stable?	Validate schema and values	Examine whether the rule changed who produces the input
Can we undo a mistake?	Recompute or roll back	Consider effects already induced in people or campaigns

The table is a conceptual diagnostic. It does not make every integration a complex-systems problem.

Look for the loop, not the buzzword

A feedback loop has a specific shape: an action affects behavior, that behavior changes a future input, and the changed input influences the next action.

1. Routing decision

   priority assigned
   affects
2. Service

   response changes
   influences
3. People adapt

   future labels change
   feeds
4. Next routing decision

   adapted labels become input

Draw those arrows before invoking a theory. If there is no plausible path from output back to input, keep the design simple.

For the support queue, the loop is visible. Routing priority affects response time. Response time affects how agents label requests. Labels determine routing priority. The team can test the loop by comparing labels, actual severity, wait times and reclassifications before and after the rule. A rise in urgent labels alone cannot tell whether customer problems got worse or labels became more attractive.

This distinction also protects against overreaction. A temporary spike after a policy change might be a backlog clearing, a reporting change or a real shift in demand. A single graph cannot identify the cause. Keep the original records and annotate changes to the rule so later readers know which system generated the data.

Watch only rules that can change their own inputs

Stable mappings do not need a social-science study. The extra work belongs where a rule changes a person’s incentives, a customer’s experience or the future data used to judge that same rule. A simple trigger can identify candidates: can anyone upstream see or feel the rule’s output and change what they send next? If yes, name one outcome and one possible adaptation to watch.

Some behavior changes are desirable. If clearer error messages cause users to correct bad records earlier, the input stream improves. The goal is not to freeze behavior. It is to avoid mistaking a response to the system for independent evidence about the world.

Review the rule at a cadence that matches its consequences. A low-risk queue label may need a weekly look. A campaign suppression rule tied to consent must be enforced immediately and audited differently. Feedback analysis never relaxes permission or consent requirements.

There is another useful test: compare a rule’s input before and after the people affected by it learn the rule. If the distribution moves, interview the operators before assigning a cause. They may have discovered a clearer label, worked around a delay, or encountered a genuinely different mix of requests. Keep an immutable record of the rule version and its effective time so a later analyst can reconstruct which policy shaped which data. This is the same discipline a workflow integration plan needs for ordinary data ownership, extended here to behavior that changes because the workflow itself changed.

A rule is part of its environment once people can react to it. Keep the exact mechanics deterministic. Keep the outcome test awake.