C2 systems

The shared-picture checklist

Here is the whole checklist first, because it is what a design review of a C2 system should walk through and because almost every line is cheap in the first schema and a migration in the second. It is numbered so a line can be cited: "we fail 2.2" is a ticket, where "the track model feels fragile" is a mood. The groups follow the data from the moment a report is created to the moment a person acts on it.

1. 1.Every report

   1. 1.1A report is immutable and has its own id, assigned where it was created. A correction is a new report that references the old one.
   2. 1.2It carries its provenance: the source, the sensor, the operator where there is one, and the version of any software that produced it.
   3. 1.3It carries two times — when it happened and when it arrived — plus which clock stamped it and how good that clock was.
   4. 1.4It says whether it is real, an exercise or a test, in a field that no display and no adapter can drop.

2. 2.Every track

   1. 2.1A track references its reports and never replaces them: merging adds a link, splitting removes one.
   2. 2.2A track number is never reused, so a question about a number always gets the same object.
   3. 2.3Position carries its uncertainty, and identity is a hypothesis with its alternatives rather than a label.
   4. 2.4Confidence says what it is based on, on a scale that everyone producing it means the same thing by.

3. 3.Every partition and every long run

   1. 3.1Nodes exchange an append-onlyappend-onlyrecords added, never changedA store or log in which new records are only ever added and existing ones are never changed or deleted in place; a correction is a new record pointing at the old one. It costs space and turns "the current value" into a query, and in return nothing that was once known can silently disappear.All terms log of reports, not a diff of tracks.
   2. 3.2On a conflict both versions are kept and correlation re-runs over the union; nothing is settled by comparing two clocks.
   3. 3.3Every sync is counted: reports exchanged, how many were new, how many conflicted, and how each conflict was resolved.
   4. 3.4A long uptime is a tested condition: time, counters and caches behave after a hundred hours as they do after one.

4. 4.Every interface with another system

   1. 4.1The message standard and its version are named in the requirement, not chosen by the team.
   2. 4.2Units, datum and time base — UTCUTCCoordinated Universal Time — the world’s reference timeThe time standard that clocks and logs are normally kept in, with no time zones and no daylight saving. It inserts leap seconds to stay close to the Earth’s rotation, which is why GPS time, which does not, now runs 18 seconds ahead of it.All terms or GPS time — travel in the data or are fixed by the contract, and the contract is tested rather than trusted.
   3. 4.3Anything a partner sends out of range is quarantined and flagged, never silently corrected.
   4. 4.4Every translation between schemas is logged, so a wrong value can be traced to the adapter that produced it.

5. 5.Every display element

   1. 5.1Age is visible without a click.
   2. 5.2Uncertainty is drawn as uncertainty — an area, a hollow marker — never as a precise symbol.
   3. 5.3Any element answers "why do you think that" in one interaction, with the reports and sources behind it.
   4. 5.4A stale feed or an isolated node is shown as stale or isolated; silence never looks like "nothing is happening".

6. 6.Every decision a person makes

   1. 6.1The person has enough time to decide, and the time actually available is measured rather than assumed.
   2. 6.2The person sees the evidence behind a recommendation — which source, how old, what it matched — not only a score.
   3. 6.3Refusing is as easy as accepting, a live action never shares a confirmation screen with a drill, and a cancellation is prepared in advance.
   4. 6.4When a person and an automated system can give conflicting instructions, which one wins is decided in advance and known to both.
   5. 6.5What was shown, what was chosen, by whom and when is recorded.

Correlation is the operation, and it is never certain

Three terms make the rest of this page readable, and they are worth separating because systems that blur them produce a picture nobody can reason about. A REPORT is what one source said at one moment: raw, attributable, never modified. An ENTITY is the real thing in the world that a report may or may not be about. A TRACK is the system’s current best belief about an entity, assembled from reports and always revisable. Reports are facts about sources; tracks are hypotheses about the world.

Correlation is the step that assigns a report to a track, and it is a judgement under uncertainty every single time. Two sensors reporting positions eighty metres apart may be seeing one object with a position error or two objects that happen to be close. The system has to pick, and both mistakes are expensive in different directions: merging two entities hides one of them, and splitting one entity produces a picture with a thing in it that does not exist. Neither error is recoverable if the reports were discarded after merging.

Line 2.2 is the same rule applied to names. A track number is how people talk about an object, over a radio or across a room, and a number that can be reassigned, or that changes when two tracks merge, turns a question about one object into an answer about another. Give each track an identity that never moves, and if tracks merge, keep the old numbers as aliases that resolve to the surviving track rather than freeing them for reuse.

Two times and a clock on every record

Retrofitting any of these is a migration across every consumer of the data, so they belong in the first schema rather than the second version. All four look like details, and all four decide whether the picture can be trusted — which is why they are lines 1.2 and 1.3.

• Event time and receipt time

  When it happened and when you learned about it are different numbers, and the gap can be minutes. A report that is forty seconds old is not a report about now, and a display that cannot show the difference will present stale information as current.

• Confidence, as a value

  Every report and every track carries how sure it is and on what basis. Rounding uncertainty away at the edge of the system is the most common way a picture becomes confidently wrong.

• Provenance

  Which source, which sensor, which operator, which version of which classifier. This is what makes a disagreement investigable rather than a matter of opinion.

• Clock discipline

  Nodes that cannot reach a time source drift. Record the clock source and its quality with the timestamp, or ordering across nodes becomes a guess dressed as a fact.

The clock deserves more than a card, because the way a clock goes wrong is slow. A small error per hour is invisible in a one-hour test and decisive in the hundredth hour, and for anything that moves, an error in time is an error in position. The most studied case in software engineering is exactly this, and the diagram below is drawn from the investigators’ own table.

That is line 3.4, and it generalises well beyond clocks. Counters that wrap, caches that grow, sequence numbers that exhaust a field, floating-point accumulators that lose precision — each of them passes every test that restarts the system first. If the system will run for days in the field, one test has to run for days too, and the uptime at which each component was last verified belongs in the release notes.

Confidence deserves one extra note because it is where good intentions fail — line 2.4. A number between zero and one is only meaningful if everyone producing it means the same thing by it, and they do not: a sensor’s 0.9 is a calibrated probability, a classifier’s 0.9 is a softmaxsoftmaxscores squashed into 0–1The function a classifier’s last layer usually applies to turn raw scores into numbers between zero and one that add up to one. They look like probabilities but are not calibrated ones, so a softmax of 0.9 does not mean the model is right nine times in ten.All terms output that means very little, and a person’s 0.9 is a shrug rendered as a number. Either agree what the scale means and calibrate against it, or carry the raw evidence and let the consumer decide. What does not work is averaging three incompatible 0.9s into a 0.9 that describes nothing.

When two nodes lose contact

This is where the absent network stops being abstract. Two nodes are disconnected for an hour, both keep receiving reports, both update their tracks, and both are correct about what they saw. When the link returns they disagree — not because either is broken, but because they saw different things. The general distributed-systems material on this lives elsewhere on the site; what is specific here is that the correct resolution is almost never to pick a winner.

One practical consequence, which is line 3.1: because reconciliation happens over reports rather than over tracks, the sync protocol exchanges an append-only log of immutable facts, not a diff of mutable state. That is a considerably simpler thing to make correct, it is idempotentidempotentsafe to repeatAn operation that has the same effect whether it runs once or five times. It is what makes a retry safe — and since any network call may be retried without you knowing, the alternative is charging a card twice.All terms by construction, and it survives being interrupted halfway — which matters when the contact window is measured in seconds.

Interoperability is a requirement, not a preference

A product team chooses its formats. A C2 team mostly does not. Requirements arrive as documents written by someone who will never meet you, and one sentence in them usually decides the architecture: the system shall exchange data with these systems, in this message standard, at this version. Those partners are often older than yours and cannot be changed, so the standard is a constraint you inherit rather than a design you get to improve — which is line 4.1, and the reason a lot of the skill here is reading a specification closely.

The person in the loop, and the screen they decide through

Everything above exists so that a person can make a decision, and "human in the loop" is used loosely enough to mean nothing. As an engineering requirement it is specific. A person is IN the loop when nothing consequential happens until they act. A person is ON the loop when the system acts unless they stop it inside a window. And a person is in NEITHER when they are told after the action. The third is the common arrangement, and it usually arrives by accident rather than by decision.

Group 6 of the checklist is what turns the phrase into properties you can test. A person needs enough time to decide, measured rather than assumed — a two-second confirmation is not oversight, it is a rubber stamp with extra latency. They need the evidence behind the recommendation, not only its score. Refusing has to be as easy as accepting and must not look like a mistake; if "no" is harder than "yes", the loop is decorative. When the person and the automation can disagree, which one wins has to be settled in advance. And the decision has to be recorded — what was shown, what was chosen, when, and by whom — or a bad outcome cannot be reviewed.

The display is therefore not a presentation layer over the real system. It is the last stage of it, and the place where careful data modelling is most easily thrown away: a track carrying age, confidence and provenance, rendered as an icon identical to every other track, has lost all three at the last step. Group 5 of the checklist is the minimum.

• Age visible without being asked for (5.1). A track built on a report four minutes old should not look like one updated two seconds ago.
• Uncertainty drawn as uncertainty (5.2). A precise symbol is a claim, and drawing one over a guess is a lie the interface tells on the system’s behalf.
• Every element answers "why do you think that" in one interaction (5.3), showing the reports behind it and their sources.
• Degraded modes have a design, not a blank panel (5.4) — silence reads identically to "nothing is happening".
• An interruption the person cannot act on trains them to ignore the ones they can — the same alerting rule as everywhere else on this site.

Seven failures, and the line that covers each

Each of these has a public investigation, and several cost lives. They are here for what they teach about building a shared picture, not as a verdict on the people involved: in almost every one, the investigators found the cause in a field, a screen or a procedure that the system’s designers had made or left out.

Where it degrades

The honest limit of everything on this page is that a shared picture can only correlate what was reported. The sensor that was never there, the source that was jammed, the object that looked like background — these are absent without a trace, and a complete-looking picture invites the belief that the absence of a track is the absence of an object. The interface can show that a feed has gone stale; it cannot show a feed that never existed. The only defence is to draw coverage as well as tracks, so that "we see nothing here" and "we cannot see here" never look the same.

• A picture that looks complete because gaps in coverage are drawn as empty map rather than as unknown.
• A two-second confirmation dialog counted as "human in the loop".
• A reconciliation dashboard that is green because a long partition produced zero conflicts.
• Confidence averaged across sources that mean different things by the number.
• An exercise flag that exists in the database and is dropped by the adapter to a partner system.
• An interface specification that exists as a document and is never run as a test.
• A system tested for an hour and deployed for a month.
• Every conflict escalated to a person, so that none of them is read.
• A display that renders every track identically, deleting age, confidence and provenance at the last possible step.

When to use it

Related pages

• DeftechComputer visionComputer vision is the practice of turning camera images into detections a machine or a person can act on, and the model is rarely the hard part of it. What makes it hard here is that it runs on a device with a power budget and no network, on images unlike the ones it was trained on, feeding a decision where the two kinds of error are paid for by different people. The page opens with twelve field failures, the cause behind each and the check that catches it, then covers the budget on the device, the data problem, the threshold as a policy, what has to be recorded, and seven documented failures.
• DeftechData platformsA data platform is the stack that collects, stores and moves an organisation’s records, and one built for a reliable network sends first and stores as a side effect. Invert that assumption and the architecture inverts with it: the node writes locally and always, and sending becomes an opportunistic background activity that may not happen today. The page opens with twelve ways a disconnected platform loses or corrupts data, each with the design that prevents it, then covers the priority queue, the receiving side that expects to be interrupted, what every record carries, evidence as a deliverable, twenty years of formats, and seven documented cases.
• DeftechDrone softwareDrone software is the flight code on an uncrewed aircraft and the ground software commanding it, built to stay safe when the link, position or battery fails. An uncrewed aircraft is a distributed system in which one node falls out of the sky if it misses a deadline, and that one fact decides which code runs where, what may block and what may crash. The page opens with the twenty-five-line flight-readiness checklist, then covers the stack as a hierarchy of deadlines, the failsafe ladder as the real specification, the return decision as an energy calculation, autonomy as a list of decisions, simulation as the test environment, and seven documented accidents.