Three Patterns, One Claim
The report has a problem. Not with the test results. With the headline above them.
Precision achieved.
Underneath are three drawings from a fictional series of repeated trials. In each drawing, a small cross marks the intended destination, and the dots mark where objects actually arrived. These are groups of outcomes, not three lucky shots.
In the first drawing, the dots sit so close together you could almost cover them with a fingertip. But the entire cluster is off to one side of the cross. In the second, the dots are scattered widely around the cross. Their average position looks about right, but individual results vary considerably. In the third, many dots gather close to the cross. A few are strikingly far away.
Someone has circled the third drawing and written, best precision. Someone else has underlined the first and written, most consistent. The report's author has left both comments in place.
Who is right?
You cannot settle the argument by choosing the picture that looks nicest. One pattern suggests consistency without correct location. Another suggests a good average with poor consistency. The last looks encouraging until you notice what its headline leaves out.
Beside the drawings are two other labels: guided and unguided. The report never tells you which label belongs to which pattern. That omission is deliberate. The shape of a group of results does not reveal the architecture that produced it.
The first question is not which picture wins. It is what the people reviewing this report think the word precision means. And before we can answer that, we need to understand what guidance can actually change.
Information, Timing, Authority
Imagine a small puck sliding across a perfectly ordinary tabletop. You give it a push, and then you let go. The puck continues according to its initial motion and the forces acting on it. You might know the table's slope. You might measure the surface carefully. You might choose the starting direction with remarkable accuracy. None of that means the puck can change its own path after you release it.
Now change just one thing. Imagine that the puck can receive information while moving and can make a limited correction. That is a different capability. It is not proof of a better result, but it changes what is possible.
Three questions reveal the difference. What information is available? When can the system act? And what can it actually change?
Start with information. In the first case, a person can make a sophisticated prediction before release. The puck itself receives nothing new. In the second case, the moving object might estimate its own position or receive an update. But an estimate is not automatically correct. An update is not automatically trustworthy.
Next, timing. Before release, you can change where and how you push. After release, the first puck has no way to respond. The second may have an opportunity, but only while its correction capability remains available. A late observation cannot undo every earlier consequence.
Finally, authority. Suppose the second puck can only make a small change. Knowing it has drifted does not mean it can erase the drift. Information tells a system something about its situation. Authority describes what it can physically do about it.
The analogy has limits. Real flight involves far more than a tabletop, and real systems may combine several kinds of information. But the three questions transfer: information, timing, authority.
Engineers also separate related jobs. Sensing provides observations. Navigation estimates a system's state. Guidance determines a desired change. Control produces a physical response. A system may combine these functions in different ways; they are not four interchangeable words.
This is why guided versus unguided is useful vocabulary but an incomplete comparison. One guided system might rely largely on information established before release, while another can incorporate updates later. Both may correct in flight, yet their information, opportunities and limits differ.
And notice something important about our first puck. Better measurements and a better initial push could improve its results. It would still be unguided. Improved preparation is not the same thing as in-flight correction.
So the word guided tells us that a kind of response is possible. It does not tell us how much information the system has, how late it can use that information, or how much it can change.
What the Kit Buys
That distinction makes a familiar proposal sound attractive. Take a system whose path is largely set at release, and add a guidance kit.
For our purposes, imagine only the capability, not the hardware. Before the change, the system has no means to make a deliberate in-flight correction. After the change, it may be able to use information and alter its course within limits. That is real engineering value. It creates an option that did not exist before.
But an option is not an outcome.
Think of a theatre spotlight. An operator can point it at a marked place on the stage. Now imagine giving the light a mechanism that can move it automatically when a performer changes position. The mechanism adds a valuable ability to respond. But if the information about the performer is wrong, the light can move precisely in the wrong direction. If it receives the information too late, it may respond after the moment has passed. And if the mechanism cannot turn far enough, knowing where to point does not make the movement possible.
A weapon is not a spotlight, and we are not describing a real guidance design. The useful distinction is between the ability to make a correction and the conditions needed for that correction to be useful.
A guidance kit also becomes part of a larger system. Information must mean what the receiving functions think it means. Interfaces must behave as expected. New functions must be verified. Maintenance, inspection, training, and support may change. A capability that works once in a demonstration is not automatically a capability that can be depended upon throughout its life.
Nor is every guidance kit the same. Some arrangements may use information fixed before release. Others may have ways to use later updates. Their available corrections and limitations differ. The label kit tells us almost nothing about those differences.
Return briefly to the report. Could a guidance kit explain why one drawing looks better than another? Possibly. But the dots alone cannot establish that explanation. A cluster is evidence about observed results. A guidance label is a claim about capability. We still need a way to describe the results themselves.
The Fifty-Percent Circle
Look at the first drawing again. The dots are tightly gathered, but away from the cross. The engineer who wrote most consistent was noticing something real. The outcomes repeat closely. The engineer who questioned the headline was noticing something real too. They are not close to the intended location.
In careful measurement language, precision often concerns how closely repeated measurements agree. Accuracy concerns closeness to a reference. In ordinary discussions of precision-guided weapons, the word precision is used more broadly. We should not pretend those usages always match.
Now imagine the reviewer draws a circle around the dots. How large a circle is needed to contain half the outcomes? That is the intuition behind a measure called circular error probable, usually shortened to C E P.
But there is a question hiding inside that simple description. Where do you put the center of the circle?
In one established Army engineering formulation, using a circular statistical model, the circle is centered on the true mean point of impact: the average location toward which the results tend. That center need not be the intended point. Other reporting conventions must be identified rather than silently assumed.
For the first drawing, a small circle around the cluster might describe its tight spread. It would not erase the distance between the cluster and the cross. A circle centered on the intended point would answer a different question. The two should not be mistaken for the same measurement.
Now the second drawing makes sense. Its average may be near the cross, yet the outcomes are scattered. Correct average location does not mean consistent individual results.
And the third? A circle containing half its outcomes could look impressive while telling us little about the more distant ones. Fifty percent is not everyone. It is not a promise about the next result. Nor can a finite sample establish the exact underlying distribution. The conditions, model, and reference point all matter.
This is the quiet trap in a single performance number. A statistic can be meaningful and still answer only one question. Without knowing how it was defined, what was measured, and under which conditions, we cannot safely make it answer several more.
The report's headline now looks different. We have learned enough to see that a tight group, a correctly located average, and a favorable fifty-percent figure are not interchangeable achievements.
Two Requirements, Two Answers
The review team has one more question. Suppose the system can be guided, and suppose we understand its measured performance. Should guidance always be added?
Imagine two fictional development reviews. They are not planning an engagement. They are deciding which engineering claims their organizations must be able to satisfy and sustain.
In the first room, the requirements board has a long list of obligations. The product must be available in substantial quantities. It must fit existing support arrangements. Manufacturing consistency matters. The organization has limited capacity to inspect, repair, and manage additional equipment. And every new interface creates something else that must be verified and maintained.
An engineer proposes adding a new correction capability. The board does not reject it because it dislikes technology. It asks a harder question: which requirement does that capability satisfy, and what new obligations arrive with it? If the baseline design already meets the stated performance requirement, adding functions may consume resources that the program needs elsewhere. Simplicity can be a genuine engineering advantage when it serves the requirement.
In the second room, the requirements are different. The board explicitly needs a capability to respond after release. Better initial estimates cannot substitute for that requirement. An unguided architecture, however carefully prepared, cannot claim an in-flight correction it does not possess.
Here, adding guidance is not decoration. It is central to the requirement. But the board still needs evidence: can the complete system use its information, make its permitted response, integrate with its surroundings, and remain supportable? A capability that exists on a diagram but cannot be reliably demonstrated is not a closed requirement.
Notice that neither board has declared a universal winner. The first has not proved guidance unnecessary everywhere. The second has not proved every guided design preferable everywhere. They have asked different questions and therefore require different evidence.
That is why guided and unguided approaches can coexist. Guidance changed what engineers could require of a system. It also brought new functions, dependencies, and lifecycle responsibilities. Meanwhile, scale, producibility, availability, support, and affordability did not stop mattering.
A feature can be superior along one dimension without making its architecture the best answer to every requirement. That is not a compromise in engineering rigor. It is what engineering rigor demands.
The Questions That Survive the Label
The fictional report is back on the table. Its headline has not changed. Neither have the dots. But the questions we can ask are different.
The first drawing is consistent and displaced. It raises the difference between a repeatable result and a correctly located one. The second has a plausible average but a wide spread. It reminds us that an average can hide variation. The third has many nearby results and a distant tail. It warns us that a fifty-percent measure does not describe the whole distribution.
Which drawing proves precision achieved? None, by itself. The answer depends on what the claim means, how the evidence was measured, and what requirement the result is meant to satisfy.
The guided label does not settle it either. We would still ask what information was available, when the system could act, and what it had the authority to change. A guidance kit might add correction capability. It would not automatically establish correct information, dependable integration, or a successful result.
And if someone asks which architecture should be chosen, we now know why the drawings are not enough. That decision belongs to a requirements argument, with evidence about capability and the obligations that come with it.
At the beginning, the report invited us to choose a winner from three pictures. Now it invites a better question: what exactly has been demonstrated, and what remains unproven?
That is the distinction worth carrying forward. A capability label tells you what may be possible. A statistic tells you something measured under particular conditions. A requirement tells you why either one matters. Good engineering never asks one of them to do the work of the others.