a guard nobody has tripped is a hypothesis

Several guards in this system exist only to refuse: a configuration whose fingerprint does not match the signed one, a start request that did not come from the schedule, a pinned specification older than the binary that would act on it. Each is easy to write and hard to trust from the outside, because a guard that never fires and a guard that cannot fire look identical in a passing test run.

So each is exercised in the failing direction. The pin tests were re-pointed at a deliberately wrong fingerprint and had to refuse. The deployment verification attempted a start outside its window and watched it decline. A configuration gate was re-checked after a pin change specifically to confirm that a partial or regressed file still stops the pass.

The most useful of these came from a surprise. Environment settings carried by the schedule are not inherited by work that the schedule launches, which was established by experiment rather than read from documentation. Rather than route the values some other way, the decision was to make a manual start impossible at the platform level, and then to verify the impossibility by attempting one.

The cost is that every guard now carries two tests rather than one, and the failure test is the more awkward of the two to write.

What it proves: the team distinguishes a control that is present from a control that works, and will build the uncomfortable test that tells the difference.