Coalition Computation Across Sovereign Boundaries

Federation begins with a boundary

A coalition does not become interoperable by becoming one organization.

Each participant arrives with its own mission, systems, policy, data, security authorities, operating procedures, and responsibility to its nation or institution. The coalition still needs to act together. A logistics status, medical-capacity change, route closure, or targeting restriction may have consequences across several participants before any one participant can see the complete decision.

The central design problem is therefore not how to erase boundaries. It is how to coordinate through them without losing the meaning, revision, and authority of what crosses.

Traditional integration often stops at data exchange. System A publishes a message. System B maps its fields. System C displays a translated value. Connectivity is necessary, but the participants can still calculate different consequences from the same update because each keeps a private implementation of the governing rule.

This paper examines a stronger proposition: participants agree on the bounded logic that gives selected information operational meaning, execute that logic under local control, and exchange only the results each relationship is configured to receive. The public NATO and Defense Department record establishes the interoperability need. Grid enters only as an architecture to test against that need.

What the institutional direction establishes

NATO describes Federated Mission Networking as a governed framework of people, processes, and technology for establishing and operating mission networks. It is intended to support command and control and decision-making through improved information sharing while allowing NATO organizations, nations, and partners to contribute their own capabilities. Governance, standards, readiness, and mission-specific instantiation all matter; a network connection alone is not the framework.

The 2025 Data Strategy for the Alliance develops the same direction at the data layer. It describes movement from isolated repositories toward shared data spaces and federated meshes while Allies retain control of their data. That is a target state, not evidence that every required data product, label, control, or exchange path already exists.

The 2026 Alliance Digital Strategy calls for secure, resilient, interoperable digital capabilities, including standardized labels and metadata, federated identity and access, zero-trust approaches, and operation across cloud and tactical-edge environments. NATO's Digital Transformation Implementation Strategy 2.0 describes a federated digital backbone spanning NATO, national, security, cloud, and edge domains, with data sovereignty and structured interoperability built into the implementation direction.

These strategies preserve a crucial distinction. Federation enables collective action; it does not grant every participant unrestricted access to every fact. Classification, releasability, national caveats, identity, purpose, and mission authorization remain active constraints.

Interoperability must also be demonstrated, not inferred from a design document. NATO's CWIX 2026 account emphasizes testing data standards, interfaces, software, command-and-control systems, and operational procedures before interoperability failures reach a mission. Passing one schema check would be too narrow; people and procedures are part of the system under test.

The United States is pursuing related architectural patterns. The DoD Data Mesh Reference Architecture provides guidance for decentralized ownership, data as a product, common connection points, and reusable patterns. The CDAO Open DAGIR fact sheet describes government-owned, interoperable repositories and a multivendor ecosystem for data, analytics, and AI. Neither publication certifies a particular vendor or removes the need to evaluate contracts, interfaces, controls, and mission behavior.

Together, these sources support the direction: coalition systems must be federated, governed, interoperable, and testable while participants retain meaningful control. They do not establish that Grid conforms to any NATO or DoD framework.

Data exchange does not guarantee decision agreement

Suppose four organizations receive the same report that a corridor has closed. Each system may store an identical corridor identifier and closure time. Yet the four resulting plans can still diverge.

One participant treats the corridor as unavailable immediately. Another allows movements already inside the corridor to continue. A third applies the closure only to one cargo class. A fourth received the policy revision but still runs an earlier planning rule. Every organization can display the same source fact while calculating a different operational conclusion.

The missing interoperability object is the decision contract:

• Which fields and units define the exchanged fact?
• Which source, observation time, revision, and confidence travel with it?
• Which rule revision determines what depends on it?
• Which constraints are common, which are local, and which may not be disclosed?
• Which result may be shared, with whom, for what purpose, and for how long?
• Which human or external process may authorize an action?
• How is a correction delivered if the source or model later changes?

An interface can transport all of these claims, but it cannot decide them. They must be authored and governed.

The Grid proposition: shared logic, local execution, selected exchange

Grid proposes that a bounded coalition decision can be represented as a set of explicit models rather than as several hidden implementations joined only at their outputs.

Each participant can operate a local model containing its permitted facts, relationships, rules, constraints, and views. An agreed package can define the typed calculation or decision contract that participants need to execute consistently. A configured binding can publish a named, versioned result from one model to another without automatically publishing the entire local model or source dataset. When an accepted result changes, dependent logic can recalculate and preserve the source and model revisions used.

This is not a claim that every coalition should run one global model. Some rules are shared, some are national, some are mission-specific, and some cannot cross a boundary. The useful unit of federation may be very small: a capacity status calculated under an agreed definition, a route-feasibility result, an approved readiness claim, or a constraint that another model is permitted to consume.

Consider a fictional four-participant logistics case:

1. A host nation publishes a corridor status with identity, time, and revision.
2. A movement model evaluates the closure against agreed route semantics and publishes only a typed feasibility result.
3. A sustainment model consumes that result with local inventory and priority rules that never leave its environment.
4. A command view receives the represented alternatives and reasons that its policy permits it to see.
5. An authorized person records the external decision; configured participants receive the decision revision and acknowledgment request.

The architecture keeps unlike responsibilities distinct. The host nation remains authoritative for its source claim. The shared package defines only the logic the participants have agreed to share. Local models retain local facts and restrictions. The command authority decides under applicable policy. The exchange record preserves which revisions moved through the federation.

Shared Logic Across Coalition Boundaries visualizes this pattern. How Models Connect shows selected model-to-model exchange, and Local Compute and Selective Sharing focuses on the local execution boundary. These are authored explanations, not operational demonstrations.

What selective sharing does not solve

Publishing fewer fields can reduce unnecessary disclosure. It does not make a transfer authorized.

The deployment must still enforce classification, releasability, need to know, purpose, nationality, export-control, privacy, retention, and cross-domain rules. Identity and access services must authenticate the actor or service. Approved guards and interfaces must mediate transfers between security domains. Security and mission authorities must approve, authorize, or accredit the complete configuration as applicable. A model predicate stating that a result is releasable is useful only when it reflects an approved policy source and is backed by the controls that actually govern release.

A validated digital signature and trust chain can help a participant authenticate package origin; a digest checked against a separately trusted reference can verify content integrity. Neither proves that the author was authorized to define the rule, that the rule is correct, that a package is safe for a particular environment, or that another participant must accept it. Version agreement also does not remove national discretion. Two participants can execute the same calculation and remain authorized to make different decisions.

Local computation has similarly bounded value under disrupted, disconnected, intermittent, or limited communications. A validated local model may continue to evaluate locally available facts inside its approved scope. Grid does not provide the communications transport, guarantee indefinite offline operation, resolve every concurrent update after reconnection, or prove that a stale remote claim remains usable. Those conditions belong in the test plan.

No statement in this paper claims FMN compliance, NATO certification, Open DAGIR conformance, an authorization to operate, cross-domain approval, classified suitability, or deployment by any government or coalition organization.

Design the federation around explicit failure modes

A useful coalition evaluation should make failure visible instead of optimizing only for the successful exchange.

Test at least these cases:

• Two participants use different package or rule revisions.
• A source revision arrives without an accepted observation time or identity.
• A permitted result depends on a local fact that cannot be disclosed.
• A recipient is authorized for the result but not its underlying evidence.
• A national caveat changes after a result has already propagated.
• A connection fails before delivery, after delivery, or before acknowledgment.
• Two valid local decisions diverge even though the shared calculation matches.
• A correction must find every participant that consumed the earlier revision.
• An operator lacks the role, context, or time required for meaningful review.

The correct result is not always convergence. The system should sometimes refuse exchange, mark a result unresolved, retain a local conclusion, or require an authority to reconcile a difference. Interoperability that hides disagreement is more dangerous than a visible boundary.

A bounded interoperability evaluation

Begin with one recurring decision and two or three participating organizations in a controlled environment. Choose a narrow shared contract, a small set of declared local facts, one change that must cross a boundary, and one accountable decision. Establish the current manual or integrated baseline before introducing the model.

The evaluation packet should retain:

• Source identities, observation times, revisions, and labels
• Shared package, schema, rule, and binding revisions
• Local inputs that affected the result, including those represented only by permitted status
• Alternatives evaluated and reasons for accepted, rejected, or unresolved status
• Sender, recipient, authorization decision, delivery state, and acknowledgment
• Simulated interruption, recovery, duplicate, and correction events
• Human review, decision, accountable role, and external effect receipt where configured
• Security, releasability, and accreditation assumptions explicitly outside the product demonstration

Measure four different layers rather than collapsing them into one claim.

Semantic consistency: identical test cases producing the agreed shared result; unit, label, precision, and rule-version mismatches detected; rejected incompatible packages; and explanations that identify the rule used.

Exchange behavior: delivery and acknowledgment completeness, duplicate handling, stale-result detection, correction reach, disconnected queue behavior within the tested window, and visibility of partial failure.

Decision coordination: time from an accepted source change to revised conclusions, conflicting revisions across permitted views, reconciliation steps, and alternatives with an inspectable status and reason.

Authority and control: exchanges refused under the configured policy, decisions made by the role designated in the approved authority matrix, local information withheld as designed, and events that require external security or command authorization. The responsible organization must validate that the configured matrix reflects lawful and command authority.

A model demonstration can establish behavior only for the declared fixtures, interfaces, packages, and limits. A customer-controlled evaluation can test the system in the participant's environment under agreed acceptance criteria. Operational interoperability, security approval, and mission effect require the relevant authorities and independent evidence.

Share the smallest decision contract that creates collective value

Coalition architecture often oscillates between two unsatisfactory extremes: centralize everything or accept permanent fragmentation. Federation offers a third path, but only when the shared object has governed meaning.

The practical starting question is not, “How do we connect all our data?” It is, “Which conclusion must we calculate consistently, which facts and rules give it meaning, what may cross each boundary, and who remains authorized to decide?”

Use the From a Changed Fact to Coordinated Action journey to trace one revision through a decision, then use the decision evaluation worksheet to define the source, model, exchange, evidence, and authority boundaries for a controlled test.

Coalition computation should make collective action possible without making sovereignty, security, or responsibility disappear. Share the logic that must be common. Execute it where control belongs. Exchange only what the relationship permits. Keep every decision attributable to the authority that can actually make it.