Every routing rule in the engine gateway began as a judgment call wearing YAML: this task type prefers that engine, because it seemed right on the day the rule was written. There is nothing wrong with starting that way; there is no evidence before the first run. What rots a policy file is not that its rules started as guesses. It is that nothing ever forces the guesses to face the runs that came after them.
One rule in the gateway shipped with its own alarm clock. The architecture-critique rule carried re_evaluate_after_runs: 5: a declared promise that after five confirmed real runs, the assumption behind the rule would be re-examined against what actually happened, not against how confident anyone felt.
The trigger fires
Five confirmed runs accumulated, each one a real architecture-critique task with a human-confirmed outcome in the run ledger. The trigger fired, and the review was held as part of the phase that hit it. The question on the table: should this task type keep preferring the cloud manual engine, or had the evidence opened the door to a local model?
The answer was to keep the rule as it was, and to defer local-model testing until far larger local capacity exists on this machine. On paper that looks like nothing happened. In the file, everything that matters happened: the rule’s reason and evidence fields were rewritten from the five runs, so the policy now records not just what it prefers but why, and on what observed basis. The session log called it out in one line: the first routing policy rule updated from run evidence rather than upfront assumption. An independent review of the same phase confirmed the loop closed correctly, and quietly deleted a non-standard field that had crept in beside it.
Why the counter is the interesting part
Most config files get revisited under exactly two conditions: something broke, or someone remembered. Both are terrible schedulers. The counter moves the revisit decision out of memory and into the artefact itself: the rule names the amount of evidence that makes its own assumption stale, and the system counts.
The shape only works because all three fields live together. A trigger without a reason field re-opens a debate with no record of the original argument. A reason without a trigger is a plaque, polished once and never questioned. Together they make the rule a small experiment: hypothesis, sample size, and a slot where the result gets written back.
The part worth stealing
Pick one value in your own config that was written from judgment: a timeout, a model choice, a retry count, a threshold. Add the second field: the condition under which you will look at it again, in checkable terms (N uses, a date, an incident). And when the condition fires and the answer is “keep it”, write the evidence back anyway. The cheapest governance you will ever install is a rule that knows how old its own reasoning is.
What Next
The Typo That Meant "No Restrictions"
Also in this series: the same gateway's privacy gate, and the day an expert panel found out what it did with a word it didn't recognise.