The Gap
Coverage is not capability.
Most detection programs are built to answer two questions. Can we sense the threat? And have we covered enough ground? Both are real questions, and both can be answered with money. Buy the right instruments. Place enough of them. Pass the inspection.
A program can do all of that and still not have what its owners believe it has.
The two questions are about coverage: the presence of detection across an environment. Capability is something else. Capability is whether all that coverage produces the right decision, in time, when an alarm actually fires. Coverage is a map of where your instruments are. Capability is a plan for where a reading becomes a decision, and a decision becomes a response. The first can be purchased. The second has to be designed, and it almost never is.
This is the gap we work in, and it is wider than most organizations realize.
Where programs actually fail
The instrument is rarely the problem. Detection technology is mature, and most programs buy capable equipment. The failures happen in the spaces the equipment cannot cover for you.
They happen at the moment of decision. An alarm sounds, and someone has to determine what it means and what happens next, often in seconds, often without the authority to act, often with no script written in advance for a reading of that kind. The detector did its job. The program failed at the human moment the detector was built to serve.
They happen in the distance between the laboratory and the world. An instrument proven in controlled conditions meets temperature, humidity, contamination, and operating tempo that no one modeled, and quietly degrades while still appearing to work. The assurances a program was built on were true somewhere. They do not always remain true where the program actually lives.
And they happen in the gap between what a program was designed for and what it will actually face. A program built against a clean specification, or borrowed whole from a respected peer, can be correct on paper and incapable on the ground, because the threat, the environment, and the operators in front of it are not the ones the design assumed.
None of these are detection failures. They are architecture failures. And they share a single cause: the program designed the coverage and never designed the capability.
Why it stays hidden
Coverage is visible. You can see the instruments, count them, show them to an inspector, and put them on a capabilities list. Capability is invisible until it is tested, and most programs are tested for whether their instruments detect, not for whether their organization decides, holds up in the real environment, or fits the program to its actual ground.
So the gap stays hidden, and an organization carries a belief about its own readiness that the first real event will correct. The cost of that belief is not theoretical. It is the difference between a program that was bought and a program that works.
How we close it
The Threshold™ framework exists to close this gap deliberately, across the full lifecycle of a program: assessing where capability actually stands, designing where detection belongs, fielding it, preparing the operators who run it, and proving that it works under the conditions it exists to meet.
Most engagements begin with an assessment: a clear-eyed read of whether a program delivers capability or only coverage. It is the least expensive way to find out, and often the most revealing.
Inside the Threshold framework