The previous post laid out what the Commander can see and what it is allowed to do. This one is about the part that decides what it should do, which is where the design decisions matter most and where I made nearly every mistake worth writing down.
Everything below — every failure mode, every reward-hacking episode, every behavioral property — was observed in simulation during offline training. None of it happened on a production cluster. That is by construction: at a 60-second tick, the roughly five million steps this policy needed to converge would take about nine and a half years of wall-clock time to collect from the real thing. Training in production is not inadvisable here, it is arithmetically impossible. Shadow mode on production contributes under one percent of what the policy knows, and none of that percent is on-policy.
The Commander’s Reward Function
The Wrong Reward: Average SLO Adherence
My first implementation used average SLO adherence across domains:
R_commander = α × mean(slo_adherence[D]) - β × cluster_cost
This looks reasonable. I want domains to meet their SLOs, and I want to do it efficiently.
The problem emerged during training: the Commander learned to consistently sacrifice one domain to optimize the average. It allocated most of the cluster budget to the four highest-traffic domains, leaving Domain 5 (Internal Platform) persistently under-resourced. Domain 5’s SLO adherence was poor. That barely moved the average, because Domain 5 has fewer pods and lower traffic.
Had that policy ever governed production, it would have left internal engineering tooling permanently under-resourced — not a trade I would make. But the average-based reward does not distinguish between “all domains slightly below SLO” and “four domains excellent, one domain in serious trouble.”
The Right Reward: Worst-Domain Penalty
The fix is to use the worst-performing domain, not the average:
degradation(d) = max(
latency_p99(d) / latency_SLO(d) - 1,
error_rate(d) / error_budget(d) - 1,
0
)
R_commander = (
w_slo * cluster_slo_adherence_score # primary: SLOs met
- w_cost * cluster_cost_per_min # secondary: cost efficiency
- w_deg * max(weighted_degradation[D]) # worst domain, not average
- w_thr * node_provisioner_thrash # node churn penalty
+ w_pro * forecast_proactivity_bonus # acting on forecast before spikes
- w_flr * floor_proximity_penalty # domain near minimum floor
)
Coefficient priority: w_slo > w_deg >> w_cost > w_thr ≈ w_pro ≈ w_flr.
That cost term used to be cost_per_pod_per_min, and changing it was not cosmetic. Per-pod cost is a bin-packing metric, not a footprint metric: fixed cluster costs get divided by pod count, so adding pods to already-provisioned nodes lowers it. I had written a term that paid the Commander to pack toward the node ceiling and barely noticed provisioning more of it. Absolute cluster cost per minute is the quantity I actually wanted to regulate.
Both SLO terms are clipped before weighting — degradation at 1.0, which is a latency ratio of 2.0. That clip value is not arbitrary, and I got it wrong the first time. degradation is ratio − 1, so a clip at 1.0 saturates at a latency ratio of 2.0 — which is exactly where the graduated rollback pulls the policy off the domain entirely. Above the clip the reward stops distinguishing bad from worse, and a domain already at twice its SLO costs nothing more to abandon. That would be a serious flaw if the policy were still in charge there. It is not. I originally clipped at 2.0, which put the blind spot at 3× SLO — a full multiple past the point where the policy is removed — and that gap was real rather than designed.
Tightening it cost me something elsewhere, which I did not notice for a while. The clip applies before priority weighting, so Internal Platform’s contribution to the worst-domain term now tops out at 0.3: its weight times the clipped maximum. Once Payment is more than 30% past its SLO, Payment’s term alone exceeds 0.3 and Internal Platform cannot be the worst domain the Commander sees, however badly it is doing. Under the old clip that crossover sat at 60% over. Now it is 30%, which is inside the P0 alert band and a fairly ordinary afternoon.
Adherence still carries Internal Platform, so this is not abandonment. But the term I added specifically to stop the Commander sacrificing a domain is the first one to go blind to that domain, and it goes blind sooner than it used to because I fixed something else. One caveat I owe the reader: the coincidence holds on the latency branch. degradation takes a max over latency and error-budget breach, and the rollback ladder is keyed to latency multiples alone, so a domain breaching on errors can reach the clip with no guardrail underneath it.
The priority ordering as I stated it is not quite right either. cluster_slo_adherence_score is a mean over the five domains, so its per-domain leverage is w_slo / 5. The degradation term is not undiluted either: it is clipped and priority-weighted, so its slope on the worst domain is w_deg × priority_weight(d). Dominance therefore requires w_slo > 5 × priority_weight(d) × w_deg — five times for Payment, but only one and a half times for Internal Platform. And it holds only above the SLO; below it, w_deg contributes nothing at all while the adherence gradient steepens toward the boundary. Written as w_slo > w_deg, the ordering describes the terms rather than the behavior, and the behavior depends on which domain is worst and which side of its SLO it sits on.
Stage 3 of training uses only w_slo, w_cost, and w_deg — the core trade-off. Stage 4 adds w_thr, w_pro, and w_flr as shaping signals, on the theory that the secondary terms would distort early learning before the policy had the fundamentals of SLO protection. I still think the instinct was right, but calling it a curriculum flatters it. It is a single step change at one boundary, and it is the same boundary where five Soldier policies unfreeze. Two things change at once — the objective and the environment — which means when Stage 4 destabilizes, the per-term reward logging cannot tell me which of them caused it. I was briefly tempted to call it three, counting the simulator’s drop from roughly 100× real time to 50×, but that is not independent: throughput falls because five previously frozen networks now need gradients computed alongside the Commander. It is the same event wearing a different hat. The non-stationarity everyone reaches for first is not a third cause either — that is simply what unfreezing the Soldiers means. Annealing the shaping coefficients in over the first stretch of Stage 4, rather than switching them on, is the obvious fix and I did not do it.
Priority Weighting
I further extended degradation to weight by domain priority:
weighted_degradation(d) = priority_weight(d) × degradation(d)
priority_weight = {
Domain 1 (Payment Processing): 1.0 # P0 — auth failure = immediate revenue loss
Domain 2 (Fraud Detection): 0.9 # P0/P1 — inline with auth; degradation = regulatory exposure
Domain 3 (Merchant Services): 0.8 # P1 — contractual SLAs with large merchants
Domain 4 (Data Pipelines): 0.5 # P2 — batch tolerant, but feeds fraud models
Domain 5 (Internal Platform): 0.3 # P3 — lowest priority, but starvation blocks deploys
}
This means a P0 domain at 10% above its latency SLO generates a higher penalty than a P3 domain at 30% above its SLO. The Commander learns to protect P0 domains more aggressively during contention.
It also, and I did not see this until much later, partially re-opens the exact door the worst-domain penalty was built to close. Internal Platform carries weight 0.3, so its weighted degradation only exceeds Payment’s when it is more than three times further past its SLO. Concretely: with Payment sitting 20% over, Internal Platform can sit 66% over and still not be the worst domain the Commander sees. The max protects whichever domain is worst after weighting, and weighting is precisely a statement that some domains are allowed to be worse.
That is a deliberate trade — I do want the Commander protecting authorization ahead of internal tooling during genuine contention — but it is a trade, not a free improvement, and presenting worst-domain-max as “the fix” and then priority weighting as “an enhancement” obscures that. The two sections are in tension. Hold onto this, because the first reward-hacking episode below is the direct, predictable consequence of it, and I spent a while treating it as a surprise.
I am not fully comfortable with this decision. The priority weights I used (1.0, 0.9, 0.8, 0.5, 0.3) were set by judgment, not measured. If the true relative cost of a P0 vs P1 SLO breach is different from what those weights imply, the Commander has been optimizing for the wrong objective the whole time. There are ways to learn priority weights from incident cost data. I did not do that, and I think I should have.
The Forecast Proactivity Bonus
Without this term, the Commander learned to ignore the traffic forecast. The policy converged to “wait for CPU to climb, then reallocate budget.” Faster than HPA’s downscale stabilization window and metric lag, but not proactively superior — and precision matters here, because HPA’s own control loop runs every 15 seconds, four times faster than the Commander ticks. What makes HPA slow is not its loop. It is the five-minute stabilization window and the metric lag in front of it.
The forecast_proactivity_bonus rewards the Commander for allocating budget in advance of an arriving spike:
# shown here in its original form — two gates get added to this later,
# after it turned out to be gameable
forecast_proactivity_bonus = (1/D) × Σ_d [
I(forecast_t15[d] > rps_current[d] × 1.2) # spike predicted
× I(budget_delta[d] > 0) # agent increased budget
× (1 - clamp(degradation_at_t15(d), 0, 1)) # SLO held after spike
]
This is a continuous, gated product averaged over domains. All three conditions must be satisfied for a domain to contribute: a spike was predicted, the Commander increased budget in advance, and SLOs were preserved when the spike arrived. The third term provides gradient through the degradation clamp — it is not binary, so the Commander gets partial credit when degradation is small and no credit when degradation is severe.
“Bonus” is a word that makes a reward modification sound harmless. Two things about this one.
It is not potential-based shaping. The classical guarantee — that shaping leaves the optimal policy untouched — holds only when the added term has the form γΦ(s') − Φ(s) for some potential function over states. This term depends on the action taken and on an outcome fifteen ticks in the future, so it cannot be written that way. It is a change to the objective, not a nudge toward the existing one, and it should be read as me deciding that proactive positioning is worth distorting the optimum for.
And I(budget_delta[d] > 0) is magnitude-blind. Any increase collects the full per-domain contribution, so the cheapest way to farm this term is the smallest budget bump that clears the 2% dead-zone, applied to every domain with a forecast spike, funded from the reserve. I did not catch that until reading the term back much later. A saturating function of budget_delta relative to the forecast gap is the obvious replacement.
The Thrash Penalty
Node provisioners do not like being told to add nodes and then immediately remove them. The cost is real: provisioning latency, API server load, pod scheduling disruption. I penalize the Commander for decisions that lead to rapid provision/deprovision cycles:
thrash = count_of(node_provision_events followed by
deprovision_event within 10 minutes)
R_commander -= w_thr × thrash
The more uncomfortable question is whether the Commander should be charged for node churn at all, because it does not control node provisioning. Between a budget directive and a node event sit the Soldier’s interpretation, a replica delta, an HPA write, pods going Pending, the scheduler, and finally the provisioner’s own policies — three hops and two controllers I do not own, with a scale-down clock longer than my attribution window.
I kept the term, and I think that is right: the alternative is giving a learned policy a direct node-provisioning lever on a payments cluster. The price is a weak, confounded gradient, since CI and batch generate node events the Commander had nothing to do with. What I could fix was the shape. Each provision event is now attributed across domains by their share of the pending pods that triggered it — fractional, noisy, blind to the deprovision half. A bad signal, but better than one cluster-wide scalar arriving ten minutes late with nothing in it to learn from.
In practice the penalty suppresses a failure mode I saw once the shaping terms were live: the Commander would over-allocate budget during a forecast spike, trigger node provisioning, then immediately reduce budget when the spike did not materialize at full predicted magnitude, triggering deprovisioning.
Both the thrash penalty and the proactivity bonus depend on temporal history. Thrash needs a 10-minute lookback, proactivity needs to know whether a predicted spike materialized. That breaks the Markov property. Including the rolling thrash count and the previous budget allocation in the observation repairs the thrash side, and I described that to myself as fixing the problem. It does not fix the proactivity side: at t+15 the reward depends on whether a spike was forecast and budget was raised at t, and the observation carries only the previous tick’s allocation, so that state is not recoverable. This system is a POMDP and calling it otherwise was wishful. Without the history that is there, the value function cannot predict its own reward, and training degrades in a way that does not show up as anything obviously wrong in the loss curve.
The Soldier’s Reward Function
Everything above is the Commander. The Soldiers have their own reward, and it is where I made the mistakes I am least proud of.
A Soldier turns a capacity share into replica counts across 150 to 500 applications, every ten seconds. Five terms:
R_soldier = (
v_slo * domain_slo_adherence # primary: this domain's SLOs
- v_bgt * budget_utilization_deviation # over- or under-spending the allocation
+ v_align * commander_directive_alignment # following the Commander's intent
- v_osc * replica_oscillation_penalty # up-down thrashing inside the domain
- v_cold * cold_start_penalty # pods not yet serving traffic
)
Coefficient priority: v_slo > v_align > v_bgt > v_osc ≈ v_cold.
Three of those are local. domain_slo_adherence is the same concave form as the Commander’s, applied to one domain. replica_oscillation_penalty is the Soldier-level analogue of thrash. cold_start_penalty counts pods in Pending or ContainerCreating as a fraction of total replicas, and it exists because without it the agent collects SLO credit for pods that are not serving traffic yet — JVM warm-up, connection pool establishment, readiness probes. A pod is “scaled” some time before it is useful, and a reward that cannot tell the difference will pay for the gap.
The other two couple the Soldier to the Commander, and both of them leaked.
The coupling term, and two ways I got it wrong
commander_directive_alignment scores how well the Soldier’s actual distribution of capacity matches the one the Commander intended. Both are vectors over the domain’s five to eight application groups, not over domains. actual is the Soldier’s own group-level softmax. intended is the Commander’s scalar budget for the domain, split across those groups in proportion to their current traffic share — so the Soldier is scored against a demand-weighted baseline rather than against anything the Commander says group by group.
My first version was plain cosine similarity, which is magnitude-invariant. A Soldier that matched the Commander’s proportions perfectly while spending half the allocated capacity scored a clean 1.0. The shape was right and the scale was free.
So I multiplied by a magnitude ratio, and shipped a version that penalized only under-provisioning. Over-spending sailed through. Nothing in the term stopped a Soldier from taking the full ten percent of headroom the budget cap allows and still collecting full alignment credit. That is the opposite failure, and the one I would have noticed later, because over-spending does not break an SLO. It shows up only in the cost term.
The version that shipped is symmetric: both directions cost the same.
Three corrections to that term took me longer than designing it did.
The epsilon belongs in the denominator. I had added it to both vectors. cos(a+ε, i+ε) shifts both toward the all-ones direction, so at low absolute resource levels — overnight troughs, the low-traffic domains — the cosine approaches 1 regardless of true alignment. Free alignment credit, in exactly the conditions where nobody is watching.
The magnitude factor has to be clamped at zero. Unclamped, it goes negative once the ratio exceeds 2.0, and because cosine is non-negative here, that inverts the gradient. A worse-aligned Soldier would have scored higher.
The ratio is over L1, not L2. Over L2 the factor conflates shape with scale. Intended (0.2, 0.2, 0.2, 0.2, 0.2) against actual (1, 0, 0, 0, 0) is identical total spend, but yields a ratio of 2.24, which the clamp then floors at zero — perfect total spend scored as no alignment at all, purely from concentration.
Those last two interact in a way I did not plan. Once the ratio is over L1 and the budget cap holds Soldiers within ten percent, the ratio cannot reach 2.0, so the clamp never fires. It is a guard against a formulation I no longer use, kept because I would rather the reward function not depend on a guardrail staying in place.
One conflict I have not resolved
budget_utilization_deviation is a quadratic penalty centered on 85% utilization. The magnitude factor inside commander_directive_alignment is maximized at 100%. Two terms in the same reward function with contradictory optima — and because v_align > v_bgt, the 85% target is never actually reached.
I know about it and I have not fixed it. One of the two should move. I have not decided which, because the honest answer is that I do not know whether 85% was a considered number or one I wrote down early and never went back to.
The order things are introduced in
Soldiers train first, alone, against a fixed budget. The Commander trains next against frozen Soldiers, and only in Stage 4 do both move at once. Terms arrive on the same kind of schedule, and that schedule matters more than it looks: a term that is not live yet is a behavior that is free.
Reward Hacking Episodes I Actually Encountered
All three of these were found in simulation, during Stage 3 and Stage 4 offline training. None of them reached a production cluster.
Episode 1: Conservative hoarding. The Commander learned to allocate almost all budget to P0 domains regardless of actual load, keeping P2/P3 domains barely provisioned. P0 domains maintained good SLOs easily, and cluster cost was technically “efficient.” The Commander’s reward was decent, but the resulting cluster was operationally useless — in the simulation, Internal Platform sat far enough below its capacity floor that deployment pipelines would have been unable to schedule.
This is the episode I flagged earlier, and it was not a surprise so much as a bill coming due. Two decisions I had already made guaranteed it. Priority weighting told the Commander that Internal Platform degradation counts for 0.3 of Payment degradation. The curriculum withheld w_flr until Stage 4, so for the whole of Stage 3 there was no penalty at all for driving a domain to its floor. The policy did exactly what those two choices instructed. Calling that reward hacking gives the agent too much credit.
The fix is partial, and I would rather say so than present it as closed. I moved from a flat floor to per-domain minimum budgets scaled to each domain’s viable footprint — which addresses the calibration of the floor and not the timing. w_flr still does not exist until Stage 4, so the whole of Stage 3 still trains a Commander for which driving a domain to its floor is free. I fixed the size of the guardrail and left the window during which there is no guardrail at all.
Two more things stay open, and I would rather list them than let the word “fix” do work it has not earned. The floor penalty is itself a max over domains, so even once it is live in Stage 4 it prices whichever domain is closest to its floor and nothing behind it — and Episode 1 starved both P2 and P3. And the priority weight of 0.3 that started the whole thing is exactly where it was. I named two causes, addressed neither of them directly, and improved a third thing that was also wrong. This mattered more than I expected. My first attempt was a uniform 5% floor, which sounds protective until you notice Internal Platform’s steady state is around 10% of the cluster — a 5% floor let the Commander cut it in half and remain fully compliant with its own guardrail. The same 5% could never bind on Payment, whose footprint is three times larger. A single number across domains with a threefold footprint range is not a floor, it is a decoration.
The utilization half of the fix belongs to the Soldiers, not here. budget_utilization_deviation is a Soldier reward term targeting 85% budget utilization, and it reaches the Commander indirectly through the soldier_budget_utilization[D] observation. I originally wrote it as a seventh Commander term, which was wrong on two counts: it contradicts the six-term function above, and a Commander-side utilization penalty fires hardest during a capacity incident, when allocated budget goes unused because pods are stuck Pending and nothing the Commander did caused it.
Episode 2: Forecast gaming. Soldiers scale domains down on their own when load falls. The Commander worked out that issuing a budget reduction just before that happened let it claim the “proactive scaling” bonus when the actual cause of good outcomes was the Soldier’s reactive behavior.
What I changed: tightened the attribution window for the forecast_proactivity_bonus — actions must precede the spike by more than five minutes, not merely at some point before the outcome — and added a counterfactual comparison against a baseline reactive policy. The baseline is a proportional-to-current-RPS allocator: it distributes budget in proportion to each domain’s current traffic share. The bonus only fires when the RL policy’s pre-positioned capacity produces measurably fewer SLO breaches than that baseline would have over the same window.
I am less confident in this fix than the other two. The counterfactual replays the baseline from the state the agent produced, so the agent controls the initial condition of its own comparison — leaving node provisioning saturated so a reactive ramp cannot land is within reach and is directly rewarded by the gate. And proportional-to-RPS is a weak opponent: no priority, no SLO awareness, no forecast. A gate that almost always passes is not a gate. The term is also simulator-dependent, so it exists in training and not in production, which is acceptable only because the deployed policy does not learn online.
Episode 3: Latency gaming. The Commander learned that keeping some domains slightly under-provisioned elevated their latency, which would then “improve” when budget was added, generating a large relative improvement signal. It was manufacturing credit for rescuing situations it had created.
I switched the SLO adherence component to an absolute threshold (are you within SLO?) rather than relative improvement (did you get better?).
That closes the channel in the SLO term. It does not close the pattern, and I claimed it did for longer than I should have. I(budget_delta[d] > 0) in the proactivity bonus is a delta reward — it pays for increases, not for being correctly positioned. A domain already sitting at the right allocation earns nothing further, and the only way to earn again is to first come down so there is room to go back up. That is the same manufactured-opportunity structure as Episode 3, in a different term, fighting the thrash penalty as it goes. What I actually did was remove relative-improvement rewards from the place I was looking.
A related vector I addressed late: SLO surfing. My initial SLO adherence score was binary (within SLO or not), which gave no gradient for maintaining headroom — the agent was indifferent between p99 at 50ms and p99 at 195ms when the SLO was 200ms. The fix was switching to a concave continuous formulation: sqrt(1 - clamp(ratio, 0, 1)) below SLO, linear penalty -(ratio - 1) above. The sqrt provides diminishing returns — at 30% of SLO the score is 0.84, at 50% it is 0.71, at 70% it is 0.55, at 90% it is 0.32, at 100% it crosses zero. The gradient is steepest near the SLO boundary and flattens as latency drops well below it, which is the right way round: the argument to the square root is 1 - ratio, so approaching the SLO means approaching zero, which is the steep end of the curve, not the flat one.
This rewards headroom without paying much for wasteful over-provisioning — the marginal gain from pushing latency from 70% down to 30% of SLO is only 0.29, against a cost term that rises the whole way. Under the per-pod cost metric that claim would have been false, since adding replicas was close to free; with absolute cluster cost it holds.
The property I like most is one I did not design. Below the SLO the function is concave, so by Jensen’s inequality noise costs more than smooth operation at the same mean — and sharply more near the boundary. For jitter confined below the threshold, a ±1% band costs about 0.0001 at 90% of SLO and about 0.0055 at 99%, roughly a fiftyfold amplification. The formulation rewards reducing latency variance, not just the average, exactly where variance is most dangerous.
That holds strictly below the SLO, and it is easy to overclaim. Once the jitter band straddles the threshold, most of the apparent variance penalty is the tail crossing into the linear branch — the breach penalty doing its job, not the curvature. Widen the band far enough and the sign flips, because the function is convex at the kink.
Two things I would fix. The derivative is unbounded as the ratio approaches 1, so the strongest policy gradient sits exactly where p99 measurement noise is worst — jitter that moves the score a couple of percent at half the SLO moves it more than 40% just inside the boundary. And the slope discontinuity runs the wrong way: near-vertical on the compliant side, slope 1 on the breached side, so the force pulling a breached domain back is weaker than the force that was holding it in. If crossing the SLO is meant to be categorically different, that belongs in the reward as a step, not a kink.
Behavioral Properties of the Trained Commander
A few notable behaviors from the trained policy. These are simulation measurements, taken across the Stage 4 evaluation scenarios — not production observations, for the reason given at the top.
Preemptive budget shifting. When the forecaster shows a 15-minute traffic increase for Merchant Services, the Commander begins raising that domain’s allocation six to eight ticks before the traffic arrives, in discrete steps rather than a smooth ramp — the dead-zone filter permits nothing else. The lead time is not a free parameter: the proactivity bonus only credits actions more than five minutes ahead of a spike, so anything faster than that earns the Commander nothing, and the term shapes the policy toward the window it pays for.
Uncertainty-driven conservatism. When forecast uncertainty is high, the Commander holds 8–12% of cluster capacity in reserve rather than its typical 3–5%. No reward term references forecast_uncertainty at all. The Commander is not instructed to be cautious under uncertainty; it is expected to discover that ignoring uncertainty leads to breaches, through a signal path with a fifteen-to-thirty-minute lag and GAE attenuating the credit by roughly sixty percent over that distance. The behavior showed up in evaluation. It is emergent rather than specified, which means it is not guaranteed to survive a retrain, and an explicit uncertainty term is the obvious thing to add if it ever stops appearing.
Cross-domain protection during cascade. When a domain starts degrading, the Commander pulls budget from lower-priority domains before their own load justifies giving it up. The cross-domain signals let it diagnose why a domain is degrading — but the exposure scalar alone cannot do this, since it sums over all of a domain’s dependencies. Localizing the culprit takes the exposure scalar together with the call-rate matrix and the per-domain degradation values, all three of which are in the observation. If Payment latency is climbing while its exposure is high and Fraud is the dependency actually breaching, the Commander learns to fund Fraud rather than Payment, where the capacity would be wasted.
The caveat on this one is a simulator caveat. The behavior was learned against a cascade model built from Istio-calibrated RPC dependencies, and the simulator does not model shared connection-pool saturation — which is among the most common real cascade mechanisms in a payments stack, and a different channel entirely from RPC latency propagation. I trust the shape of this behavior more than I trust its transfer.
Slow-to-scale-down. The Commander is asymmetric: it raises budget faster than it lowers it. I have described this as emerging naturally from the thrash penalty, and that is probably too tidy. w_thr sits in the bottom coefficient tier, below w_cost — and holding capacity longer than necessary is exactly what the cost term charges for, so a bottom-tier term is unlikely to be the whole explanation for a behavior that persistently opposes a higher-tier one. The more likely driver is SLO protection: scaling down early risks a breach, and breaches are the most expensive thing in the function. The honest version is that the asymmetry is overdetermined — thrash penalty, cost/SLO asymmetry, graceful-drain constraints, and the dead-zone all push the same direction, and I cannot cleanly attribute it to one of them.
The Commander produces a number per domain and a claim about how urgent it is. That is the whole output. Everything that makes it real — turning a capacity share into replica counts across hundreds of applications, every ten seconds, while the budget shifts underneath — belongs to the Soldiers.
Which leaves the question I have been avoiding for six posts. Every fix in this one was found by me noticing something. That is not a detection strategy, and the last post is about what happened when I finally built one, and everything it turned out I had already missed.