How to Federate a Coalition or Multi-Cloud Without a Shared Controller

Nick Clark

What You Are Building

You are building a way for two or more independently governed systems to exchange and reconcile state without electing a master and without installing a shared control plane first. The systems might be allied nations' defense networks, two corporate environments after a merger, separate clouds under separate accounts, or municipal, state, and federal agencies coordinating a disaster response. Each already has its own authorities, its own clocks, its own naming, and its own policies. None of them will agree to hand governance to the others, and there is no pre-existing shared root of trust you can lean on.

The concrete goal: when these systems interconnect, observations produced independently on each side (including while they were fully disconnected) can be admitted, time-ordered, and merged into a coherent joint picture, with every crossing and every merge decision traceable back to who said what and under whose authority. Divergence is handled by an agreed policy rather than by a central referee, and intentional disconnection is a supported operating mode, not a fault. This guide describes the architecture disclosed as the Cross-Mesh Reconciliation inventive step in U.S. Provisional Application No. 64/049,409.

Why the Obvious Approaches Fall Short

The usual tools each assume something the coalition case denies you.

Database replication and federated database protocols assume the participants share a schema and a resolution authority. They move rows efficiently, but they expect the parties to have already agreed on structure and on who wins a conflict. In a coalition, the parties have deliberately different structures and no shared arbiter.

Cross-cloud identity federation (the SAML and OIDC family) is real and useful for logging a user from one domain into another. It authenticates principals across trust domains. But it establishes that a principal is who they claim to be; it does not reconcile divergent histories of what happened, nor does it carry the provenance of each downstream fact so a consumer can weigh it. It answers "who are you," not "how do I merge your view of the world with mine."

Blockchain-bridge architectures let assets cross between ledgers, but they presuppose a consensus protocol on each side and a bridge that itself becomes a coordination point. Consensus is exactly what independently governed parties refuse to submit to jointly.

Building a shared controller (a joint coordination service every party connects to) solves the merge but recreates the original problem: someone has to own it, host it, and be trusted to run it fairly, and it becomes a single point of failure and a single point of political friction. For air-gapped defense networks or sovereignty-constrained national systems, a persistent shared service is not merely unwanted; it is often disallowed.

The structural gap common to all of these: they require either authority unification, a shared clock or consensus authority, or a central service that spans the parties. The coalition and multi-cloud cases need federation that assumes none of those.

The Architecture

The disclosed approach starts from a different unit of exchange. Instead of moving bare rows or bare messages, every fact that crosses a boundary is a governed observation: a structured record that carries, per the spec, an authority credential, a device-identity attestation, a temporal reference (which may be a global time, a mesh-derived time, or a local clock), a payload, and a lineage field. The lineage field records provenance: the contributing-device identifier, references to any source observations it was derived from, the derivation function where applicable, and a cryptographic integrity attestation over those fields. Crucially, lineage fields compose: one observation's lineage links to the lineage of the observations it was built from, producing a cross-device, cross-authority provenance chain. This carried lineage is what makes controller-free reconciliation possible, because a receiver can evaluate a foreign fact on its own merits rather than trusting a central authority to have already vetted it.

On top of that unit, the Cross-Mesh Reconciliation mechanism (Section 27.13 of the disclosure) is composed of a specific set of parts. Read this as the architecture to build:

A cross-mesh discovery interface that admits governance-credentialed boundary agents, that is, agents that hold credentials to participate in more than one mesh. Boundary agents are the only things that cross; there is no shared bus.
A taxonomy translator that produces equivalence attestations between the two authority taxonomies. Rather than forcing both sides onto one naming and authority scheme, it emits attested statements that "authority X here is equivalent to authority Y there," so a foreign observation can be admitted under a mapped local authority.
A temporal reconciliation engine that reconciles the time-ordering of observations produced while the meshes were disconnected, using mesh-derived time rather than depending on either party's clock being canonical.
A lineage-preserving import mechanism that keeps the original mesh identity attached to imported observations, so an imported fact never loses the record of where it actually came from.
A cross-mesh conflict resolution evaluator that applies the conflict resolution of the shared-world-view chapter to reconcile competing observations.
A divergence-detection mechanism that identifies when the two histories have diverged enough that automatic synchronization is unsafe, and instead requires governance-policy-defined merging.
A partitioned-operation interface that supports intentionally disconnected meshes (air-gapped defense networks, isolated industrial networks, sovereignty-constrained national meshes) with selective admission through authorized gateway channels.
A cross-mesh-reconciliation-lineage recorder that records each reconciliation event.

The arbitration that replaces a controller is policy-defined. The disclosure describes a governance-policy-defined arbitration mechanism used where multiple proposed actions are concurrently present: it selects a single outcome through governance-policy-defined priority, authority weighting, composite-admissibility comparison, or any governance-policy-defined arbitration function, and records each arbitration event in the lineage field. Applied at a mesh boundary, this is the pattern you use to decide which of two divergent observations prevails, without a central referee: each side agrees in advance on the arbitration function, and the decision is evaluated locally over the carried lineage and recorded.

What ties it together, per the spec's own statement of distinction: governance-credentialed boundary crossing preserves the originating mesh's authority signature and lineage; admission is mediated by taxonomy translation rather than taxonomy unification; ordering uses mesh-derived time rather than one party's clock; divergence is handled by policy and intentional disconnection is a persistent mode rather than a failure; and no single governance authority or consensus protocol is required to span the reconciling meshes. That last point is the whole promise: federation without global governance consolidation.

How to Approach the Build

You are implementing this yourself. A workable order:

Define your unit of exchange first. Before any federation, make every fact inside a single mesh a governed observation with an authority credential, a device-identity attestation, a temporal reference, a payload, and a composing lineage field. Federation only works if the thing that crosses the boundary already carries its own provenance and authority.
Stand up boundary agents, not a bus. Identify which agents hold credentials in both meshes and make them the only crossing points. An illustrative interface sketch, faithful to the disclosed parts (illustrative pseudocode, not shipping code):
```
interface BoundaryAgent {
  // credentials proving participation in each mesh it bridges
  credentials: MeshCredential[]
  admit(obs: GovernedObservation, from: MeshId): AdmissionResult
}
```
Build the taxonomy translator as attestations, not rewrites. When a foreign observation arrives, do not rename it into your scheme. Produce and attach an equivalence attestation mapping its authority to a local authority, and admit it under the mapped authority with its original identity intact.
Reconcile time explicitly. Do not assume either clock is canonical. Feed disconnected-period observations through a temporal reconciliation step that orders them using mesh-derived time before you attempt any merge.
Import with lineage preserved. On admission, keep the originating mesh identity and the full lineage chain on the observation. Never flatten a foreign fact into a local-looking one.
Detect divergence before merging. Run divergence detection over the two histories. If divergence is below threshold, apply the conflict resolution evaluator. If it is above threshold, stop automatic synchronization and route to your governance-policy-defined merge path.
Encode arbitration as policy both sides pre-agree. Implement the arbitration function (priority, authority weighting, composite-admissibility comparison, or your own governance-policy-defined function) and evaluate it locally over the carried lineage. Record every arbitration decision.
Treat disconnection as a mode. Build the partitioned-operation interface so meshes can run fully disconnected and later admit selected observations through authorized gateway channels. Design for this from the start rather than bolting it on.
Record every reconciliation event. Wire the cross-mesh-reconciliation-lineage recorder so each crossing, translation, ordering decision, and merge is itself lineage, auditable after the fact for legal, regulatory, or commercial review.

What This Does Not Give You

This is an architecture, not a drop-in library. There is no package to install and nothing here "just works" out of the box; you implement the boundary agents, the taxonomy translator, the temporal reconciliation engine, the divergence detector, and the arbitration policy yourself, against your own systems. The disclosure describes the mechanism and its parts with enough structure to build from, but it is a patent filing, not a benchmarked or production-proven product. This guide reports no performance numbers, throughput, or convergence guarantees, because the filed disclosure states none, and neither should you.

The approach also does not decide policy for you. Whether authority X is truly equivalent to authority Y, what the divergence threshold should be, and which arbitration function is fair are governance decisions the parties must make; the architecture carries and enforces those decisions but does not originate them. And it does not eliminate trust: boundary agents must genuinely hold valid credentials in each mesh, and a compromised boundary agent or a bad equivalence attestation is a real risk you must manage. Finally, if your parties are actually willing to share one authority, one clock, and one controller, you do not need this; a shared control plane is simpler. This architecture earns its complexity only when no party will cede governance.

Disclosure Scope

The cross-mesh reconciliation approach described in this guide is disclosed in U.S. Provisional Application No. 64/049,409, where it appears as the Cross-Mesh Reconciliation inventive step (Section 27.13, "Cross-Mesh Reconciliation and Disconnected-Mesh Synchronization"). This guide is educational. It explains an architectural approach a developer can study and build themselves; it is not a shipping product, not a warranty of fitness or performance, and not an offer of software. Every mechanism described here is drawn from that filing, and claims about how the approach works are limited to what the filing states.