A broker's order-placement path has a 200ms p99 budget that quietly degraded over eighteen months without any single change being responsible. What kind of control prevents this, and where must it run?

Why the alternatives do not stop drift

Quarterly review finds the drift after two months of it, by which point the cause is a hundred commits and nobody can attribute it. Code review cannot see a 4ms regression; no reviewer can hold a latency budget in their head across a diff. Production alerting is necessary but it is a detective control — it tells you the budget is already blown, in front of customers, and the fix is now an incident rather than a build failure.

Architectural characteristics do not degrade through a bad decision. They degrade through a long series of individually reasonable ones, which is exactly the failure mode that human review cannot catch.

What the fitness function looks like

A benchmark of the order path against a representative dataset, run on every build, asserting a hard number. It must:

• Fail the build, not warn. A warning is a metric nobody reads by week three.
• Measure the path, not the function. A microbenchmark of the matching logic misses the serialisation, the connection acquisition and the pool contention, which is where the milliseconds actually went.
• Run on stable infrastructure, or the noise exceeds the signal and the team learns to re-run it until it passes — which is worse than not having it.
• Have a named owner and a documented rationale, so that when it legitimately needs to change, it is changed deliberately rather than deleted at 2am.

The wider point

Anything you can state as an architectural characteristic — latency budget, dependency direction, bundle size, absence of a forbidden import, coverage of a critical module — can be asserted automatically. The ones that are not asserted are the ones that will drift, and in a trading system latency is not a quality of the product, it is the product.