Custom Engineering · Scenario Customization

Custom Search Support Systems

Search support is a system integration problem under time pressure: the output has to reach a search manager who is already making decisions.

6 of 10Method note

Overview

Coverage recording is the core function; everything else supports it.
Design for intermittent connectivity and for operation by people who are not the system's authors.
Match the output format to the incident command structure in use, or it will be retyped and lose fidelity.
Build in the privacy handling from the start; retrofit is usually too late.

Search support is a coverage and coordination problem

Aerial support for search — over land, in woodland, in mountains, over water — is not primarily a sensor problem. It is a coverage problem: how much ground can be searched with what confidence, in what time, and how that coverage is recorded so that nothing is searched twice and nothing is missed. The sensor matters, but coverage accounting is what determines whether a search is complete.

That frames the design priorities. Coverage per sortie and per hour, the confidence attached to that coverage, the ability to record what has been searched, and the ability to share that record between teams. A search that cannot say where it has looked cannot say where to look next, and teams end up re-searching ground that was already covered.

It also frames the realistic limit. Aerial search detects what is detectable from the air at the resolution and conditions available. Canopy, water surface state, terrain shadow and light all reduce what can be seen. Stating that limit honestly is more useful than implying a capability that conditions will not support.

Configuring for the terrain and the conditions

Woodland search is the hardest case and the most common. Canopy hides what is beneath it, and the useful countermeasures are seasonal — leaf-off acquisition sees more — and thermal, which can penetrate gaps and detect a warm body against cooler ground. Neither is reliable under all conditions, and both should be stated as improving the odds rather than as guaranteeing detection.

Mountain search adds wind, elevation and rapid weather change to the same problem, and it usually means a narrower operating window and a shorter sortie. Water search adds glare, surface state and the absence of anywhere to land. Each environment has its own configuration, and our woodland, mountain and water observation notes describe them respectively.

Night and low-light search changes the sensor set rather than the problem, with thermal taking the leading role and a lighting payload supporting confirmation. Our night thermal search note covers that configuration.

Recording coverage and coordinating teams

Coverage recording is the part that most search configurations under-invest in and later regret. Each sortie should produce a record of what area was covered, at what resolution, under what conditions and with what confidence — in a form that can be overlaid with other teams' coverage. Our search area coverage recording note describes the discipline.

Sharing that record between teams is what makes multi-team search efficient rather than redundant. Our multi-team search sharing note covers the coordination side, and it is usually the adaptation that delivers the largest practical improvement in a search programme.

The human confirmation step deserves explicit design. A candidate detection is a prompt for a person to look, not a conclusion. Our human confirmation workflow note covers how we structure that step, because it is where false positives are absorbed and where false negatives get a second chance.

Readiness, and the limits we state

Search is called on demand and in the worst conditions, which makes readiness the primary design target: configured, charged, exercised, and able to launch from a pre-agreed point without a long setup. Our emergency supply logistics note covers the same readiness discipline from the delivery side.

Readiness also means a written operating envelope and a clear authority to decline. The crew must be able to say that conditions are outside limits without that being treated as a service failure. Write it before the first real call rather than during one.

We state three limits explicitly in every search configuration. Canopy and cover reduce what is detectable. Conditions — light, wind, precipitation, surface state — set the real envelope. And automated detection flags candidates for human review; it does not conclude. These are not caveats to bury; they are what lets a search planner use the capability correctly.

Starting a search support engagement

The path is: identify the terrain types and their proportions; establish the coverage and confidence requirements; choose sensors per terrain; design the coverage recording and team sharing; build the readiness routine and the operating envelope; then exercise the whole chain before it is needed.

Exercise matters more here than in any other scenario. A search capability that is configured but never flown is not a capability, and the exercise is where the missing item — a battery, a cable, a form — surfaces while it is still cheap to fix.

Send your terrain types, typical conditions, crew and communications reality, and your existing search coordination process to our engineering team. We will propose a configuration and a readiness routine, and be explicit about what it can and cannot detect.