What You Are Building

You have two mesh networks that were built and operated separately. Each has its own governing authority, its own set of nodes, and its own record of what happened while the two were out of contact. A link opens between them, whether by design or by chance, and now you have to answer a hard question: what is true when both sides claim to know the state of the same thing, and neither side was wrong given what it could see?

This is the reconnect problem for independently governed meshes. It shows up after a merger joins two corporate deployments, when two disaster-response networks meet at a boundary, when an air-gapped network is deliberately bridged for a controlled exchange, or any time two meshes that answer to different owners have to interoperate without one swallowing the other.

The goal is to reconcile divergent observation histories on interconnection, preserve where each fact came from, and let each side keep its own authority. This guide describes the architecture for that, drawn entirely from the Cross-Mesh Reconciliation inventive step disclosed in U.S. Provisional Application No. 64/049,409. It is a design you implement yourself, not a package you download.

Why the Obvious Approaches Fall Short

The reflexive move is to pick one of the standard distributed-systems tools. Each is real and useful in its home domain, and each leaves a structural gap here.

Database replication and federated database protocols assume the participating stores share a schema and a coordinating owner. They synchronize rows; they do not carry the notion that observation A came from an authority you trust more than the authority behind observation B. When two owners disagree, replication has no principled basis to choose, so it falls back to timing or to a designated primary.

Last-writer-wins is the default tiebreak when replication has nothing else. It resolves conflicts by clock order alone. Across two independent meshes that were disconnected, the clocks were never guaranteed to agree, and "latest" is not the same as "most authoritative." A stale write from a trusted source can lose to a fresh write from an untrusted one.

A consensus protocol (the Paxos and Raft family) can give you a single agreed order, but it does so by electing one log that all participants defer to. That is exactly what you cannot impose here: neither mesh will subordinate its authority to the other's leader, and requiring a shared consensus group across both meshes reintroduces the single authority you were trying to avoid.

Blockchain bridges and cross-cloud identity federation move assets or identities across a boundary, but they do not preserve the originating authority signature and full provenance of each observation as a first-class property that the destination re-evaluates under its own policy.

The common gap: all of these either demand a shared authority or resolve conflicts by mechanism (timing, leader election) rather than by governance. The disclosed architecture treats disconnection as a normal operating mode and resolves conflicts by policy over carried provenance, with no single authority spanning both meshes.

The Architecture

The disclosed cross-mesh reconciliation mechanism (Section 27.13 of the filing) is built from a specific set of cooperating components. The design lets multiple independent governed-mesh deployments interoperate, reconcile divergent observation histories upon interconnection, and preserve lineage continuity across the boundary without requiring a prior shared authority or a consensus protocol. Every piece below traces to that disclosure.

Governance-credentialed boundary agents. Meshes do not fuse. Instead, a cross-mesh discovery interface admits boundary agents that hold credentials in more than one mesh. Reconciliation happens at these agents, at the seam, not by dissolving the seam. Each mesh keeps its own governing authority on its own side.

A taxonomy translator that produces equivalence attestations. The two meshes almost certainly rank authority differently. One mesh's "operational authority" is not automatically the same as the other's. Rather than force both onto one shared taxonomy, the architecture uses a taxonomy translator that emits equivalence attestations between the two authority taxonomies. An imported observation is admitted through a translated, attested mapping of its authority level, so cross-authority admission is mediated rather than unified.

A temporal reconciliation engine. Because the meshes were disconnected, their observations carry timestamps that need to be reconciled before you can order them. The design draws on the filing's mesh-derived time primitive, in which cooperating agents establish time bearings among themselves without depending on a single master clock or external time source, and each timestamp carries an uncertainty estimate. Time-ordering of observations produced during disconnection is reconciled through this mesh-derived time rather than through either party's clock authority.

A lineage-preserving import mechanism. This is the heart of the approach. When an observation crosses the boundary, its original mesh identity is preserved in the imported copy. The observation still carries its originating authority credential, its provenance, and its lineage field. The receiving mesh does not overwrite the source; it imports the fact along with the record of where it came from. That carried lineage is what makes principled arbitration possible on the other side.

A cross-mesh conflict resolution evaluator. When admitted observations conflict, the design applies the filing's conflict resolution from the shared environmental world view (Chapter 15). Notably, that mechanism combines admitted observations through evidentially-weighted aggregation rather than canonical selection or last-writer-wins. Weight reflects the contributing authority, staleness, modality reliability, and reputation. Conflict resolution can also produce a reconciled observation derived from the conflict set, and that reconciled observation is itself a governed observation carrying its own derivation lineage back to the inputs it came from.

A divergence-detection mechanism. Not every difference should be auto-merged. The architecture includes divergence detection that identifies when two histories have drifted far enough apart that governance-policy-defined merging rules must apply, rather than silent automatic synchronization. Small, compatible differences reconcile; large or sensitive divergences escalate to policy.

A partitioned-operation interface. Some meshes are meant to stay apart. The design explicitly supports intentionally-disconnected meshes, including air-gapped defense networks, isolated industrial networks, and sovereignty-constrained national meshes, with selective inter-mesh observation admission through authorized gateway channels. Disconnection is a persistent, first-class operating mode here, not a failure to recover from.

A cross-mesh-reconciliation-lineage recorder. Every reconciliation event is recorded in the governance chain lineage. What was imported, how its authority was translated, how time was reconciled, which conflicts were resolved and how, all of it becomes part of the provenance record.

The property that ties the components together, and that the filing calls out as distinguishing the approach: governance-credentialed boundary crossing preserves the originating mesh's authority signature and lineage, cross-authority admission is mediated by taxonomy translation rather than requiring unification, time is reconciled through mesh-derived time rather than either party's clock, divergence handling is governance-policy-defined, and no single governance authority or consensus protocol has to span both meshes.

How to Approach the Build

If you are implementing this yourself, here is a sensible order of work. The interface sketches below are illustrative only and faithful to the disclosure; they are not runnable code and there is no library behind them.

1. Make every observation carry its own provenance. Before you can reconcile anything, each fact in each mesh must arrive with its authority credential, a device or source identity, a spatial and temporal reference, and a lineage field. If your current messages are bare payloads, this is the prerequisite work. Reconciliation over provenance is impossible if the provenance was never recorded.

Observation {
  authority_credential   // who vouches for this, and at what level
  source_identity        // originating device / node
  spatial_reference
  temporal_reference     // with uncertainty
  payload
  lineage[]              // provenance, including source-observation refs
}

2. Stand up boundary agents, not a merge. Give each side a credentialed agent that participates in both meshes at the seam. Resist the urge to union the two node sets into one namespace. The whole point is that each mesh keeps its own authority; the boundary agent is where crossing is negotiated.

3. Build the taxonomy translation table and emit attestations. Enumerate each mesh's authority levels and define the equivalence mapping between them. When an observation crosses, attach an equivalence attestation so the receiving side admits it at a translated authority level. Where no equivalence exists, that is itself a decision point for policy, not a silent default.

4. Reconcile time before you order events. Decide how the two sides establish a common time frame for observations made during disconnection. The disclosed approach derives time cooperatively among mesh agents with per-timestamp uncertainty, so lean on mutual time bearings rather than trusting one side's wall clock as ground truth.

5. Import with lineage intact, then evaluate. On import, preserve the originating mesh identity. Only after the fact is imported with its provenance do you run the conflict resolution evaluator. Weigh conflicting observations by authority, staleness, modality reliability, and reputation, and where appropriate produce a reconciled observation that records its derivation from the conflict set.

onImport(obs):
  imported = preserveOriginIdentity(obs)     // do not overwrite source
  imported.authority = translate(obs.authority_credential)  // attested
  if conflictsWith(localState, imported):
     resolved = weightedResolve({localState, imported})   // not last-writer-wins
     record(resolved.lineage <- [localState, imported])

6. Set your divergence threshold and escalation policy. Define, in policy, how far two histories may drift before automatic merge is disallowed and a governance-defined merge path takes over. Decide what escalation means for your domain: a human sign-off, a higher-authority review, a hold.

7. Decide what stays partitioned. Configure the gateway channels that selectively admit observations for meshes that are meant to remain disconnected. Treat the air gap as a design feature with a controlled aperture, not a bug to be closed.

8. Record every reconciliation event in lineage. Emit a reconciliation record for each import, translation, time reconciliation, and conflict resolution, so the whole reconnect is auditable after the fact.

What This Does Not Give You

This is an architecture, not a drop-in library. There is no package to install, no SDK, and nothing here "just works" out of the box. You implement the boundary agents, the taxonomy translator, the temporal reconciliation, the conflict evaluator, and the lineage recorder yourself, against your own meshes and your own policies.

It is disclosed in a patent filing. It has not been presented here as a benchmarked, production-proven, or shipping product, and this guide states no performance numbers, guarantees, or throughput figures, because the disclosure does not.

The approach assumes you actually control the reconnect boundary and can deploy credentialed boundary agents on both sides, and that each mesh records provenance and authority on its observations. If your observations are bare and unauthenticated, you have upstream work before any of this applies. It also assumes the two authorities are willing to interoperate as peers; it deliberately does not give you a way to force one mesh under the other, because avoiding that is the entire design intent. And where a single shared authority is acceptable and available, a conventional consensus log may be a simpler fit than this architecture.

Disclosure Scope

The cross-mesh reconciliation approach described in this guide is disclosed in U.S. Provisional Application No. 64/049,409, as the Cross-Mesh Reconciliation inventive step (Section 27.13 of that filing). This guide is educational: it explains the architecture so a skilled developer can understand and build it. It is not a warranty, not an offer of software, and not a representation that any implementation, benchmark, or product exists. Every mechanism attributed here to the disclosed approach traces to that filing; nothing beyond it is claimed.