The Green Status
The review chair turns to the last page of the exercise report. Six boxes. Six green lights. Across the top, in large letters: End-to-end demonstration complete.
This is a fictional systems-engineering exercise. There is no real weapon, no real engagement, and no operational mission. The teams have built a simulation to test whether information, decisions, and results can move through a connected process. Every team has brought evidence that its own part worked.
The chair asks one question. “What exactly have we demonstrated?”
The first engineer says the observation system passed. Another says the record was maintained. The decision interface accepted an approval. The action simulator executed its command. The final screen shows a green assessment indicator. Nobody seems uncertain about the result.
But the chair is not asking whether the individual screens are green. She is asking whether the evidence behind those screens supports the sentence above them.
A junior reviewer begins to answer, then stops. The records all look complete. They even have matching fields. But the more carefully she reads them, the less certain she is that they describe one continuous, justified process.
For now, we will leave her question unanswered. It is the question this episode is designed to solve.
The familiar phrase is kill chain. The word chain suggests links, but it can also mislead us into imagining a row of boxes, each one lighting up when its job is done. Our fictional report looks exactly like that.
To understand why its conclusion may be premature, we need to follow the case that supposedly passed through those boxes.
Six Verbs, One Process
The exercise begins with an unfamiliar symbol appearing in a simulated observation feed. The team notices it and creates a record. That is the first idea: find. Something potentially relevant has been detected. Finding is not the same as knowing everything about it.
The next function must establish what the record can reliably say about the simulated object, including where it was described as being and how certain that description is. That is fix. It is not simply placing a tidy symbol on a display. It is developing information that another function can responsibly use.
A new simulated observation arrives. Does it concern the same object? Has anything changed? What can be carried forward from the earlier record, and what must be reconsidered? Maintaining and updating that understanding is track. In a real process, finding, fixing, and tracking can overlap. New information can challenge what seemed settled.
Now the exercise reaches a different kind of boundary. Information alone does not decide what should happen. The target function concerns the broader process of considering a possible action in relation to the available evidence, the purpose, and applicable constraints. The word can sound like choosing a point on a map, but the decision process is wider than that. Technical analysis and human judgment have different responsibilities. Nor does completing a targeting function, by itself, grant permission to act.
If an appropriate action is authorised, engage is the execution stage. In our exercise, the action is only a simulated command. The simulator can demonstrate that a command was received and performed. It cannot, merely by performing it, prove what result followed.
That leaves assess. The final function examines what happened and what evidence supports a conclusion about the intended outcome. Assessment may lead to further questions rather than a neat green light. It can send the process back to reconsider earlier information.
Find. Fix. Track. Target. Engage. Assess. Six verbs, and six different kinds of claim. The first three develop and maintain an understanding. The fourth concerns the consideration of action and its constraints. The fifth concerns execution. The sixth concerns evidence about the result.
These are useful conceptual distinctions, not a universal mechanical sequence. Different doctrinal contexts describe the work differently. For this episode, the six verbs are a map of responsibilities, not instructions for conducting an operation.
Now imagine that every function passes its own test. The find function can create a record. Fix can populate its required fields. Track can update an entry. Target can register a reviewed case. Engage can execute a simulation. Assess can display a status. Does that establish the complete chain?
Only if the claims mean the same thing at the boundaries. The junior reviewer has found the first place where they may not.
The Missing Meaning
She places two records side by side. The first came from the find function. The second is the record that the tracking team says it maintained. Both are valid inside their own software. Both have the expected fields. The interface test confirms that the message was delivered without corruption.
But the first record is marked as an uncertain identification. The second presents a definite label. The transfer included the label, not the qualification. Somewhere between one function and the next, uncertainty stopped travelling with the claim.
The tracking engineer objects, reasonably, that his software did exactly what the interface specification required. The receiving field was a name. A name was received. The test passed.
The chair asks what the receiving team thought that name meant.
There is the first break. A successful data transfer is not necessarily a successful transfer of meaning. The sending system knew that the identification was provisional. The receiving system treated it as established. No bit had to be damaged for the overall conclusion to become unreliable.
The junior reviewer finds another detail. The updated record carries a different case identifier. It might be the same simulated object, or it might be a new case opened by the later team. The tools do not establish which. Both teams can truthfully say they processed their assigned records. Neither can yet demonstrate that the records belong to the same continuing story.
This is what an engineering interface must address. Not merely whether two systems are connected, but what one is promising when it sends information, what the other is entitled to infer, and how the responsibility for the claim crosses the boundary.
Notice what she has not concluded. She has not declared the original observation wrong, or the tracking tool defective. She has found that the end-to-end claim depends on a relationship neither local test established.
The next finding is more subtle. Even if the two teams had agreed perfectly about the record's meaning, they still needed to agree about its time.
The Information That Aged
The reviewer reads the timestamp aloud. It looks recent. Then the observation engineer points out that it records when the message entered the receiving system, not when the underlying observation was made.
The two times describe different events. An observation can be accurate when it is made and insufficient to describe what is true later. Nothing about that requires a faulty sensor.
Suppose a building's maintenance display reports that a door was closed at noon. The report remains an accurate statement about noon even after someone opens the door. If the display shows the old status without its time, a reader may mistake a historical fact for a present condition. That is not a failure of the original observation. It is a failure to preserve what the observation can support.
Back in the exercise, the junior reviewer asks a question nobody included in the local acceptance tests: which moment does the decision record actually describe? The observation time, the receipt time, and the review time are all recorded somewhere, but the final display treats them as though they are interchangeable.
Worse, a later simulated observation raises doubt about the earlier description. The tracking tool has retained both entries. Its local test is green. Yet the review workflow contains no demonstrated path for bringing that contradiction back to the people relying on the earlier claim.
This is where a neat linear diagram becomes misleading. Find, fix, and track are not doors that close permanently once passed. New information may require a fresh look at what was found, what was established, or whether a case still means what the organisation thinks it means. Assessment, too, can raise questions about an earlier assumption.
Time matters because information has a history. Provenance matters because a timestamp without an identified event is ambiguous. Uncertainty matters because a confident-looking display can conceal the limitations of its source.
She does not ask the teams to make their simulated process faster. Speed would not repair a missing observation time, nor explain why a contradictory record was ignored. Faster movement of misunderstood information could simply move the misunderstanding faster.
The case has now reached the decision side of the exercise. The software says an approval exists. The review team must ask a harder question: approval of what, by whom, and on what basis?
The Approval That Was Not Enough
The decision team's representative opens the approval record. It is genuine within the simulation. An authorised reviewer entered it during the exercise. The interface transmitted the word approved, and the action simulator accepted the message.
So the decision team passed its test. The message was not forged. The simulator did not ignore the field. And yet the chair asks the team to read the case description attached to the approval.
It refers to the earlier version of the record, before the uncertain identification was promoted into a definite label and before the later observation raised a contradiction. The exercise has demonstrated that an approval existed. It has not demonstrated that the approval applied to the case as it was understood at the moment of the simulated action.
The difference is easy to miss when approval appears as a single green symbol. An approval record has meaning and scope. It belongs to a particular decision, under particular assumptions and constraints. The fact that a computer can read the word approved does not establish that every later use of that word is justified.
This is also why we should be careful with the word target. Within the broader targeting process, developing information about a possible action, evaluating its suitability, and exercising authority are related but distinct responsibilities. A technical recommendation is not automatically a command decision. A system capable of executing a command is not, for that reason, authorised to execute it.
The point is conceptual, not procedural. We are not describing who should approve an actual engagement or how to conduct one. We are identifying a system boundary that includes human responsibility and organisational judgment.
One green light remains unchallenged: assess. The report says the exercise was completed successfully. This is the moment when the review team discovers what the last green light actually measures.
The Last Green Light
The assessment engineer explains that the final status was generated when the action simulator reported that its command had executed. The chair asks whether the assessment function examined any evidence of the simulated result.
No. It recorded the execution event and displayed complete.
The chair writes four statements on the board. A command was issued. A command was executed. An effect was observed. The intended outcome was supported by evidence.
The first two statements have supporting records in the exercise. The third has not been demonstrated. The fourth has not been assessed. Those are not four ways of saying the same thing.
An action can be executed without producing an intended effect. An event can be observed without establishing what caused it. An effect can occur without establishing that the broader intended outcome was achieved. Assess exists because those differences matter.
The engineer who built the assessment screen says the software behaved exactly as specified. That may be true. Its specification told it to copy an execution status into a field labelled complete. The local test proved that copying worked. It did not prove that the label meant what the report's readers believed it meant.
The review chair returns to the sentence at the top: End-to-end demonstration complete. She does not replace it with End-to-end demonstration failed. The evidence does not justify that conclusion either. Instead, she marks the overall claim unresolved. The system has demonstrated several local functions. It has not demonstrated the continuity of meaning, time, authority, and evidence across them.
The junior reviewer can now explain the whole case. Find produced a provisional observation. Fix developed information about it. Track updated a record but did not demonstrate the continuity and qualifications on which the later claim depended. Target brought the information into a decision-oriented process, but the approval record's scope was not established for the revised case. Engage executed a simulated command. Assess reported that execution, not an independently supported outcome.
Six verbs. Six useful distinctions. But the real engineering object is the connected system that must make them work together. It includes software and devices, certainly. It also includes the definitions behind their data, the history of observations, the scope of decisions, the people accountable for them, and the evidence needed to close a claim.
A chain does not become trustworthy when every box turns green. It becomes trustworthy when the evidence survives the journey between them.