When a government organization considers persistent sensing infrastructure that a contractor owns, operates, and sustains, one question tends to arrive before any technical question: if the company is running the sensor, who is actually in charge of what it sees?
It is a fair question and it deserves a precise answer rather than a reassuring one. The answer is that operating infrastructure and holding authority are two different things, and a well-structured program keeps them visibly apart. Where programs get into trouble is not usually that someone intended to transfer authority. It is that nobody wrote down where the line was, so the line moved.
Why the question is being asked more often
Three things have converged. Sensing has moved from something you bring to a location toward something that stays there. Autonomous and uncrewed systems have made continuous coverage affordable in places where keeping a crew would not be. And the commercial sector has become a realistic supplier of the infrastructure that hosts both.
Each of those is individually familiar. Together they produce an arrangement that is less familiar: a commercial entity maintaining a continuous presence, hosting government-relevant sensing, in an environment where decisions may need to be made quickly. The authority question is the natural response to that arrangement, and it should be.
Operating is not deciding
The useful distinction is between the physical and logistical work of keeping a capability available, and the decisions made using what that capability produces.
An infrastructure operator launches, recovers, hosts, powers, maintains, repairs, and sustains. The operator keeps the platform on station, keeps the payloads working, keeps the links up, and keeps the whole arrangement available over a program's life. That is a demanding set of responsibilities and it is entirely about availability.
None of it is a decision about what the mission is, what a contact means, whether to respond, or what response is authorized. Those are different questions, they are answered by different people, and they sit with the government.
The authorities that do not move
It helps to enumerate these rather than gesture at them, because the enumeration is what makes the boundary auditable:
- Command authority. Who directs the mission and to whom the mission answers.
- Mission authority. What the mission is, what it prioritizes, and when it changes.
- Intelligence authority. How collected information is assessed, classified, and used.
- Response authorization. Whether action is taken on what has been observed.
- Engagement authority. Who may be engaged, under what conditions.
- Weapons-release authority, where weapons are in question at all.
Hemisphere Aerospace Defense structures programs so that every one of these stays with government personnel. The company does not replace military services, government mission owners, or prime contractors, and it does not hold government authority.
Why it has to be designed in, not asserted
A boundary that exists only in a statement of work drifts. A boundary that is reflected in how the system is built tends to hold, because crossing it requires someone to actively change something rather than simply keep working.
In practice that means the architecture itself should make the distinction legible. Who can task a sensor, and who can only keep it running. Where the awareness picture is assembled, and who sees it. What the operator can observe about the mission as a byproduct of maintaining the equipment, and what they deliberately cannot. How reach-back to government decision-makers is structured so that it is the normal path rather than an exception.
These are design decisions with real engineering consequences. They are considerably cheaper to make at the start of a program than to retrofit after an architecture has settled.
Questions worth asking a vendor
If you are evaluating contractor-operated persistent sensing, these tend to separate a considered answer from a confident one:
- Which specific authorities does your model leave with us, named individually rather than described in general terms?
- What can your personnel see about the mission as a consequence of maintaining the infrastructure, and what have you deliberately designed them not to see?
- If we withdrew tasking authority from you entirely, would the program still work as proposed?
- Where does the awareness picture get assembled, and who controls that location?
- What happens, procedurally, when something is detected and no government decision-maker is immediately reachable?
- How does your architecture make the authority boundary observable to us rather than a matter of trust?
The last one matters most. A boundary you can verify is a different thing from a boundary you have been promised.
How this shapes our programs
Preserving authority is one of the principles Hemisphere Aerospace Defense scopes programs against, alongside starting from the operational problem and advancing on evidence. It is not a compliance posture bolted on at the end. It changes what gets built.
In the Paul Revere Program, which is persistent maritime awareness infrastructure built around the AYDLL platform and currently in program development, the infrastructure exists to carry sensing, support autonomous systems operations, host modular mission capability, and connect to government reach-back command. The infrastructure is the product. The decisions remain the government's.
That is a narrower claim than the market usually makes. We think it is the one that survives contact with a program office.
If you are structuring a program where this boundary matters, we are glad to talk through how we approach it.
Discuss a program