Automating the running estimate: keeping staff awareness live

Every staff section in a headquarters maintains a running estimate: a continuously updated assessment of the current situation and of how well the operation is tracking against the commander's intent. The intelligence officer estimates enemy strength and intent; the logistics officer estimates how many days of supply remain; the operations officer estimates combat power across the force. In doctrine these estimates are described as "running" – they are supposed to be current at all times. In practice they are usually anything but, because they are maintained by hand and update only when a staff officer finds time to refresh them. This article is about closing that gap with automation: pulling live data into combat power, sustainment, and risk views so the commander sees present-state truth instead of a snapshot that is already hours old.

What the running estimate is and why it decays

A running estimate is not a one-time product like an operation order. It is a living assessment that each warfighting function keeps current throughout an operation. Its structure is consistent across functions: the current friendly situation, the current enemy situation, civil considerations, the impact of all three on planned and potential operations, and the recommendations that follow. The commander uses the aggregate of these estimates to maintain situational understanding and to decide.

The doctrinal ideal is that the estimate reflects the situation right now. The operational reality is that a manually maintained estimate reflects the situation as of the last time someone updated it. A combat power chart refreshed at the morning synchronization meeting is already wrong by the time the commander reviews it before lunch, because casualties, ammunition expenditure, fuel burn, and vehicle deadlines all change continuously and asynchronously. The estimate decays the moment it is published, and the rate of decay is highest precisely when tempo is highest – which is when the commander most needs it to be right.

There is a second, quieter cost. Manual aggregation consumes staff hours. An assistant logistics officer who spends two hours each cycle collecting LOGSTAT reports, transcribing them into a master spreadsheet, and recomputing days of supply is two hours short on the analysis that actually informs a decision. Automation does not replace the staff officer's judgment; it removes the clerical work that stands between the officer and the judgment.

From manual charts to live data: the architecture

Automating a running estimate means building a pipeline that ingests authoritative reports, normalizes them into a shared state model, recomputes derived figures as inputs change, and presents the result with its provenance intact. The architecture mirrors the layered model used for a common operational picture, but the output is assessment rather than location.

The foundation is a state model defined per warfighting function. For the operations estimate, the model carries combat power by unit – typically expressed as a percentage of authorized strength in personnel and key equipment. For sustainment, it carries levels by class of supply, days of supply remaining, and the readiness state of critical systems. For protection, it carries risk indicators and the status of force-protection measures. Each field in the model names its authoritative source, its expected update cadence, and – for any derived figure – the formula that produces it. This model is the contract that every downstream stage depends on; getting it wrong propagates errors into every dashboard.

Above the model sit ingest adapters, one per source. A friendly force tracking feed delivers unit positions and status, usually as NFFI or CoT messages. Sustainment arrives as LOGSTAT reports or their national equivalents. Maintenance and deadline data, casualty reporting, and the intelligence estimate of enemy strength each have their own format and cadence. Each adapter's job is narrow and strict: translate the source format into the state model, validate it against plausibility ranges, and quarantine anything malformed rather than letting a corrupt report poison an aggregate. A single fat-fingered ammunition count that silently halves the reported basic load is worse than no report at all.

Computing combat power and sustainment continuously

Derived figures are the heart of the estimate. Percentage combat power, days of supply remaining, and the projected operational reach of a force are not reported directly – they are computed from the underlying reports. The design decision that matters most here is when to recompute.

A naive implementation recomputes on a fixed clock – every fifteen minutes, say. This guarantees the estimate is at least fifteen minutes stale at all times and wastes compute recomputing figures that have not changed. The better pattern is event-driven recomputation: when a LOGSTAT report changes a unit's fuel state, recompute that unit's days of supply and the rolled-up figure for its parent formation immediately, and leave every other figure untouched. Event-driven recomputation keeps latency near zero for the figures that changed and avoids needless work on the figures that did not.

Every output of the computation must carry its provenance. A combat power figure of 78% is meaningless to a commander without the answer to two questions: as of when, and from what. The system should stamp each derived figure with the timestamp and source identity of the reports it was computed from, so that provenance travels with the number all the way to the screen. This is the difference between an estimate the commander can interrogate and a number the commander must simply trust.

Aggregation and roll-up

Combat power and sustainment figures aggregate up the task organization: squads into platoons, platoons into companies, companies into the battalion total. Automating this roll-up is straightforward in principle and treacherous in detail. Attachments and detachments change the org tree during an operation, and a roll-up that uses a stale task organization will sum the wrong units. The state model must therefore treat task organization itself as a live input, not a static configuration, so that combat power follows units as they are cross-attached. When a company is attached to a different battalion, its combat power must roll up under the gaining unit from the moment the attachment is effective.

Keeping the estimate trustworthy: staleness, confidence, and override

The most dangerous failure mode of an automated estimate is not that it is wrong – it is that it looks confident while being wrong. A clean dashboard with a crisp 78% invites more trust than a hand-drawn chart with visible erasures, even when the hand-drawn chart is more current. Engineering for trust means engineering for honest uncertainty.

Staleness handling is the first requirement. Every input has an expected cadence; any report older than a configurable multiple of that cadence is flagged as stale and surfaced visually – greyed, badged, or annotated – rather than being used silently. A days-of-supply figure computed from a fuel report that is eighteen hours old in a high-tempo fight should shout its age, not hide it. The corollary is that a derived figure inherits the staleness of its oldest input: a roll-up is only as fresh as its least-fresh contributor.

Confidence is the second. Where the underlying reporting is partial – for example, when only two of three subordinate units have reported – the aggregate should carry an explicit confidence or coverage indicator rather than presenting a partial sum as if it were complete. This connects the running estimate to the broader discipline of AI decision support, where surfacing the basis and uncertainty of a recommendation is what makes it usable rather than merely impressive.

Override handling is the third. A staff officer will sometimes know something the feeds do not – a unit reported by radio that has not yet filed a structured report, or a known-bad sensor that should be disregarded. The system must let the officer override an automated value, must record who made the change and why, and must never let a subsequent automated update silently erase that override. Overrides should expire or prompt for reconfirmation rather than persisting invisibly forever, so that a manual correction from yesterday does not quietly distort today's picture.

Surfacing the estimate: live views for the commander and staff

The final stage turns the computed state into views people actually use. The running estimate is not one screen but several role-filtered ones: a combat power view for the operations officer and commander, a sustainment view for logistics, a risk and protection view, and a rolled-up command summary. Each is a read-only projection of the same authoritative state, which guarantees that the logistics view and the command summary can never disagree about the same unit's fuel state. This single-source-of-truth discipline is the same one that governs sound C2 dashboard architecture: displays are consumers, never editors, of the state store.

Live views should push changes as they happen rather than waiting for a refresh, and they should draw the eye to what changed. A dashboard that redraws every figure on every update trains the commander to ignore it; one that highlights the deltas – the company whose combat power just dropped below 70%, the supply class that just crossed a decision threshold – directs attention to the few facts that demand it. The objective is not to show everything that is current, but to show what just became true and what it means for the plan.

Decision thresholds deserve explicit treatment. Commanders set criteria – combat power below a percentage, days of supply below a number – that trigger a decision. An automated estimate can monitor these thresholds continuously and alert when one is crossed, turning the estimate from a thing the staff reads into a thing that tells the staff when to act. Care is required: threshold alerts that fire on a single stale or quarantined report erode trust quickly, so an alert should fire on the same provenance-aware, staleness-aware figures the dashboards show, not on raw inputs.

How automation fits the wider C2 picture

The running estimate does not stand alone. It draws on the same feeds as the common operational picture and the wider multi-domain operations dashboard, and it feeds the recommendations that decision-support tools generate. The map answers where forces and threats are; the estimate answers how capable those forces still are and what that means for the mission. When both are built as views over one authoritative state store, the commander never has to reconcile a map that shows a unit forward with an estimate that shows it combat-ineffective – the two are computed from the same reports and agree by construction.

That coherence is the real prize of automation. Keeping a running estimate live is not primarily about saving staff hours, though it does. It is about ensuring that when the commander turns from the map to the assessment, both are telling the same, current truth – so the decision rests on the situation as it is now, not as it was at the last sync.