From Common Operating Picture to Common Operating Model

The dashboard can be right while the decision is already wrong

Organizations have invested heavily in making information visible. Dashboards, maps, alerts, common operating pictures, data platforms, and business-intelligence tools can show many participants the same event quickly. That is valuable. It does not guarantee that those participants are calculating the same consequence.

Two teams can see the same delayed shipment, revised forecast, equipment fault, hospital diversion, policy change, or funding limit and still reach incompatible answers. One workbook may treat a missing value as zero. Another may retain yesterday’s value. A planning application may use the newest rule even though an older effective version governs the case. A briefing may combine an updated demand with a stale capacity snapshot. Every surface can look internally coherent while the organization has no single answer to a basic question: which sources, rules, assumptions, and authorities produced this conclusion?

A common operating picture synchronizes observation. A common operating model synchronizes the represented path from observation to decision without pretending that calculation and authority are the same thing.

How Grid Works is the shorter system guide. This paper goes deeper on the shared and federated operating-model architecture: source identity, governed logic, constraints, institutional authority, role-specific projections, and correction evidence across organizational boundaries.

The category is not a larger dashboard, a master spreadsheet, a universal data lake, or an autonomous decision-maker. It is decision infrastructure: a maintained computational object that connects source identity, relationships, rules, constraints, alternatives, role-specific views, authorization boundaries, and evidence. Different interfaces and organizations can participate without quietly becoming different implementations of the decision.

What public guidance establishes—and what it does not

Several mature bodies of guidance explain pieces of this problem, although none defines Grid or endorses this architecture.

The W3C PROV-O Recommendation provides a general way to represent entities, activities, agents, derivation, use, generation, and responsibility across systems. It demonstrates that provenance can be modeled as relationships rather than stored as an unstructured note. Provenance alone does not determine whether a source is accurate or a decision is authorized.

The NASA Systems Engineering Handbook distinguishes verification from validation, emphasizes bidirectional traceability among requirements and stakeholder expectations, and calls for recording assumptions, environments, outcomes, discrepancies, and corrective actions. Those practices support a testable operating model, but a business or mission decision still needs its own governing sources and acceptance authority.

NIST SP 800-53 Rev. 5 provides a flexible security and privacy control catalog covering access control, audit and accountability, configuration management, assessment, authorization, monitoring, system integrity, and other control families. NIST SP 800-207 describes zero trust as protecting resources rather than granting implicit trust because of network location or ownership. A shared model must inherit those concerns; the word “shared” is not permission to expose every fact to every participant.

The Defense Department’s public explanation of its Data Strategy names architecture, standards, governance, and talent and culture as essential capabilities, and describes data goals including visibility, accessibility, understandability, linkage, trustworthiness, interoperability, and security. Those are properties of usable data. They do not by themselves express the dependency logic, constraints, or human authority needed for a decision.

For federal management, the 2025 GAO Green Book and the separately issued 2026 OMB Circular A-123 have different institutional bases and should not be collapsed into one source. Each nevertheless places responsibility on management for an internal-control system and recognizes documentation, risk, monitoring, and corrective action as management concerns. A computation platform may help produce evidence; management still owns the control objectives, risk response, judgment, and assurance statement.

Together, these sources support a bounded conclusion: consequential systems need provenance, traceability, access boundaries, configuration control, verification, monitoring, correction, and accountable owners. They do not prove that a particular common operating model is correct, secure, suitable, authorized, or effective.

Six objects, not one answer field

A common operating model should keep at least six objects distinguishable.

Object	Minimum content	Question it must answer	What it must not imply
Source revision	Producer, identity, schema, observation and effective time, units, quality state, correction link, permitted purpose	Which accepted fact did the model use?	That the fact is true because it arrived successfully
Model revision	Rules, formulas, dependencies, constraints, assumptions, tests, owner, approval and effective interval	Which represented logic ran?	That the logic is lawful, doctrinally correct, or validated for every use
Evaluation state	Inputs, intermediate values, alternatives, warnings, infeasibility, uncertainty, and execution receipt	How did the result move?	That a feasible alternative is selected or authorized
Authority record	Role, delegation or policy basis, scope, reviewed revision, action, time, and exceptions	Who may decide what?	That system access equals decision authority
Projection	Audience, allowed fields, transformation, model and data revision, accessibility and release conditions	Which view of the shared state was produced?	That every audience may see the same information
Correction chain	Superseded object, reason, disposition, recomputation scope, downstream acknowledgments	What changed after release?	That correction permits erasing the earlier record

Many systems collapse these objects into a status such as approved, ready, or green. That shortcut makes the interface simple by moving ambiguity into the organization. A more honest model can return unresolved, stale, conflicted, infeasible, recommendation ready, or authorization required when the evidence supports those states.

Unknown is not zero. Received is not accepted. Calculated is not reviewed. Feasible is not authorized. Submitted is not acknowledged. A useful operating model preserves those distinctions even when a dashboard wants one color.

A synthetic port-recovery fixture

Consider Exercise Port Meridian, a fictional and non-operational continuity exercise. No organization, facility, system, customer, or real emergency is represented. The exercise asks whether three scheduled delivery groups can move through two handling sites inside a twelve-hour recovery window. The numbers exist only so another reviewer can reproduce the result.

The modeled demand is 180 pallet-equivalents: Group A requires 80 by hour 8, Group B requires 60 by hour 10, and Group C requires 40 by hour 12. Partial groups are not allowed. Site East initially reports 120 units of usable handling capacity during the window. Site West reports 90. Twenty units at West are reserved for a separately governed priority, leaving 90 - 20 = 70 units modeled as usable for this exercise. Initial usable capacity is therefore 120 + 70 = 190.

The baseline authored allocation sends Groups A and C to East (80 + 40 = 120) and Group B to West (60). It uses all East capacity, leaves ten units of West margin, and meets the represented windows. That is a feasible calculation, not permission to direct traffic, release reserved capacity, or change a real schedule.

At exercise hour 2, an accepted inspection revision reduces East usable capacity from 120 to 95. The dependency path is explicit:

East inspection revision → East usable capacity → group allocation → completion timing → plan feasibility

Revision	East usable	West usable	Authored allocation	Arithmetic	Represented state
S-17 baseline	120	70	A + C East; B West	120/120 East; 60/70 West	Feasible; authorization unresolved
S-18 correction	95	70	Same allocation	120 > 95 East	Infeasible; prior plan preserved
M-4.2 alternative	95	70	A East; B West; C deferred	80/95 East; 60/70 West	Feasible capacity, fails Group C window
M-4.3 alternative	95	90	A East; B + C West	80/95 East; 100 > 90 West	Infeasible even if reserve were released

The correction does not justify silently moving Group C, consuming West’s reserved capacity, splitting a group, or changing a required window. It invalidates the baseline’s feasibility conclusion and identifies the smallest affected dependency path. The rest of the source state remains unchanged.

Suppose a designated exercise authority supplies a separate revision that permits splitting Group C into two 20-unit increments and extends its window to hour 14. A new model evaluation can then test a declared alternative; the earlier infeasible result can be reconstructed only when its source and model revisions plus the relevant history were committed and retained. If the role lacks authority to change the requirement, the system should record the proposal and stop. The correct outcome is sometimes a refusal with a precise reason.

This compact fixture is useful because it makes four defects observable: stale source use, hidden reserve consumption, an unauthorized requirement change, and an overwritten prior result. A screenshot of the final allocation would reveal none of them.

One model can support many surfaces without creating many truths

Different roles should not receive identical screens. An operator may need current work, a planner may need alternatives and sensitivities, a source steward may need unresolved mappings, an executive may need material constraints, an auditor may need the complete revision chain, and an external participant may be entitled to only a selected releasable result.

Those surfaces can remain different while binding to the same source and model revisions. Each projection should declare its audience, permitted fields, transformations, timestamp, and receipt. A map and a table may present unlike shapes without calculating unlike answers. An API response and a briefing can be tested for semantic parity even when their layouts differ.

The opposite pattern is familiar: a dashboard formula, spreadsheet formula, service rule, briefing number, and AI-generated explanation each reimplement the decision. Reconciliation then becomes the architecture. A common operating model replaces those private implementations with governed projections from one represented state.

The One Program Rule, Many Public Surfaces paper applies this principle to staff, public, report, and API views. From a Spreadsheet to a Shared Model addresses the organizational transition from private copies. Neither implies that every legacy system should be replaced.

Federation without forced centralization

“Common” does not mean one database or one administrative domain. Separate models can run in different environments, retain local sources and decision rights, and exchange selected, governed results. The contract at each boundary should name the producer, consumer, schema, model and data revision, purpose, markings, release conditions, freshness, correction behavior, and acknowledgment semantics.

That boundary is both computational and organizational. A technically valid message may still be prohibited by policy, classification, privacy, contract, sovereignty, or purpose limitation. A locally authorized result may remain only an input to another participant’s decision. An acknowledgment can prove receipt without proving agreement or effect.

Zero-trust principles are relevant because network location should not substitute for resource-level authorization. Provenance is relevant because a received result needs a trace to its producing activity and responsible agent. Neither principle eliminates the need for domain-specific accreditation, data rights, release authority, cross-domain controls, retention rules, or operational approval.

The companion paper Coalition Computation Across Sovereign Boundaries examines the stricter defense case. The same architectural discipline also applies to suppliers, regulators, research collaborators, banks, hospitals, and public agencies.

AI needs a durable object to contribute to

AI can help translate expert intent, draft rules, map data, propose formulas, generate views, explain a dependency path, and create test cases. Without a common operating model, it can also create many plausible implementations that disagree on defaults, precision, missingness, exceptions, or authority.

The control is not a generic “human in the loop” label. An AI contribution should land in a named object with a review state: proposed mapping, proposed rule revision, generated explanation, suggested alternative, or test case. The reviewer needs the source context, model version, change set, test results, uncertainty, and authority boundary. Accepting a draft may promote a model revision; it must not silently authorize the external decision the model supports.

The Authority Contract for AI-Assisted Decisions defines that boundary in detail. Grid Developers’ documentation describes relevant implementation primitives including reactive models, typed values, and named dependencies, explanation, saved history, and validation, and multiple surfaces bound to one model. Documentation makes those primitives inspectable; it does not prove performance or suitability in a customer environment.

Failure modes that should be seeded, not hoped away

A bounded evaluation should deliberately introduce failure rather than demonstrate only a happy path:

• a corrected source arrives with an older observation time but a newer transmission time;
• two feeds use the same label with different units or definitions;
• a model revision is approved but not yet effective;
• an unknown value is coerced to zero or allowed to retain a stale value;
• a dependency changes but one surface keeps a cached conclusion;
• an optimization proposes an option outside the declared alternative set;
• a technically authorized account attempts an action outside the person’s decision delegation;
• a disconnected participant returns with a conflicting source or model revision;
• a projection exposes a field the receiving role may not see;
• a correction changes the current result but destroys the earlier release receipt.

Expected responses should be declared before execution: reject, quarantine, mark stale, preserve both revisions, request review, recalculate a bounded subgraph, or stop for authority. A refusal is a successful test when the model lacks evidence or permission.

A credible evaluation starts with one recurring decision

Do not begin by connecting an enterprise. Choose one recurring, consequential decision with a manageable source set and a known current workflow. Build a reference fixture using synthetic or appropriately controlled historical facts. Freeze expected results, failure states, roles, and acceptance thresholds before evaluating Grid.

Test area	Evidence to retain	Minimum acceptance question
Source fidelity	Source identities, revisions, times, units, mapping tests, missing and correction states	Did every calculation use the intended accepted fact?
Model fidelity	Rules, dependencies, constraints, versions, approval state, tests, intermediate values	Can an independent reviewer reproduce the represented result?
Change propagation	Changed source, invalidated nodes, recalculated nodes, unaffected nodes, timings	Did the change move every dependent conclusion and no unrelated conclusion?
Alternatives and constraints	Declared option set, feasibility results, binding constraints, sensitivity and uncertainty	Did the model avoid inventing a choice or hiding infeasibility?
Authority	Role matrix, attempted actions, decisions, delegations, denials, overrides	Did every unauthorized state transition fail closed?
Surface parity	Projection contracts, field-level comparisons, accessibility and disclosure tests	Did different views preserve the same semantic state without leaking data?
Replay and correction	Execution receipts, releases, acknowledgments, corrections, superseding links	Can the team reconstruct what was known, calculated, shown, and decided then?

Compare the model with the actual baseline: reconciliation cycles, rekeys, formula copies, stale conclusions, conflicting releases, time to reproduce a decision, unexplained exceptions, and unauthorized attempts. Do not convert a faster demonstration into a promised operational outcome. A passed synthetic fixture supports only the tested proposition. Customer-controlled and independently validated claims require their own environments, operators, methods, acceptance criteria, and evidence.

The category shift is precise. A common operating picture helps people see together. A common operating model helps them calculate, challenge, decide, and correct from an inspectable shared structure—while leaving truth, policy, judgment, authority, security, and real-world action with the institutions responsible for them.