1.1 No Network Coordinator

There is no network coordinator. No zone has authority over any other. There is no central network entity as a legal or technical object, only bilateral relationships between sovereign kernels. Each kernel is deployed and operated by its jurisdiction’s zone operator (the entity, typically a government agency or licensed private operator, authorized to run the jurisdiction’s compliance infrastructure). Each corridor is negotiated bilaterally between two zone operators. The network topology emerges from these bilateral decisions, not from any central planning function. If every corridor were severed, each kernel would continue operating independently for its jurisdiction: portability and multi-harbor composition would disappear; sovereignty and local compliance evaluation would remain. The network adds connectivity; each kernel is self-sufficient.

1.2 Scope and Limitations

This is a systems paper. It specifies an architecture, describes a construction, and isolates the formal obligations the construction incurs. It does not claim to solve the political problem of regulatory coordination; it reduces part of that problem to parameterization (choosing R, μ, and γ for each corridor), which remains a bilateral legal and political negotiation between jurisdictions. Where the paper discusses costs, latency, or failure rates, those quantities are corridor-formation priors or friction descriptors, not claims of production throughput.

1.3 Terminology

The following terms are used throughout and defined here on first use:

• Lex: The typed logic for encoding jurisdictional compliance rules presented in the companion paper Lex: A Logic for Jurisdictional Rules. Lex combines defeasible reasoning, temporal stratification, authority-relative interpretation via tribunal modals, and typed discretion holes. Lex rules are what the compliance tensor evaluates.

• Op: The typed workflow bytecode presented in the companion paper Op: A Typed Bytecode for Compliance-Carrying Operations. Op is the execution payload for multi-step operations. Lex rules lower into Op-visible obligations and checks; Op does not reinterpret Lex at runtime.

• Operation envelope: The target signed program submission consumed by the write path for multi-step activity. It carries an Op payload, the rule-pack and primitive-registry digests against which that payload was checked, the relevant Lex/rule receipts, gas and replay commitments, and the caller’s authorization evidence. This paper uses “operation” for the institutional action and “operation envelope” for the typed submission artifact that authorizes execution.

• Fiber: An individual compliance rule evaluation against a specific statute. A fiber is the atomic unit of compliance assessment, one rule applied to one entity in one jurisdiction, producing a verdict. Fibers compose into the compliance tensor.

• Pack: A versioned, content-addressed bundle of jurisdictional rules. Distinct pack kinds bundle different rule categories (lawpacks for static legislation and regulation, regpacks for dynamic supervisory state, licensepacks for licensing rules, corridorpacks for bilateral corridor parameters, and so on). Content addressing means any change to a pack produces a new digest, making version drift detectable and enabling rule-asof evaluation.

• Compliance tensor: A function from the finite domain set to the tensor-value type. Each domain coordinate carries a compliance grade on the three-chain NonCompliant < Pending < Compliant together with an applicability marker drawn from {Applicable, NotApplicable, Exempt}. Applicability is a separate axis, not an intermediate point on a compliance chain. The full tensor-value structure is defined in the compliance-tensor companion note. One compliance tensor per (entity, jurisdiction, evaluation-time) triple.

1.4 Paper Organization

Section 2 describes the kernel architecture. Section 3 specifies the write-path pipeline. Section 4 presents the compliance tensor and passport. Section 5 defines the corridor protocol, the corridor algebra, and the no-global-consensus claim under an explicit adversary model. Section 6 addresses multi-harbor composition with a worked example. Section 7 describes delegated automated operation on the compliance surface. Section 8 analyzes network topology and scaling. Section 9 discusses failure modes and security. Section 10 catalogs the formal verification obligations, distinguishing discharged from open. Section 11 states the open problems and scope. Section 12 positions the work against related systems. Section 13 discusses implications for jurisdictional competition. Section 14 describes the endgame.

2.1 Architecture

Each economic zone deploys a single kernel. The kernel is a proof-producing rule engine + runtime engine — a proof-producing rule layer (proofs primary, verdicts derived) over a runtime execution engine that carries out the institutional work of the jurisdiction continuously, at machine speed, against the proved rules — compliant-by-default, legal-by-default, end-to-end, AI-native, at the scale of an economy. It is the sole authority for all compliance-sensitive state within its jurisdiction. It is not an operating system in the systems-kernel sense (it does not manage hardware resources or schedule processes); it is a rule-and-runtime engine for institutional work. It earns the name “kernel” through a single structural argument: it is the N = 1 write-path enforcer. Every state-changing operation in the jurisdiction passes through it. There is no bypass, no alternative write path, no way to mutate compliance-sensitive state without the kernel’s involvement.

The kernel is a single process holding exclusive write credentials for the compliance-sensitive storage layer. Business-logic compute, entity formation, identity verification, treasury operations, cap-table management, governance workflows, document generation, and credential issuance run outside the kernel as stateless services. Those services read directly from the storage layer under read-only credentials and write exclusively through the kernel’s authenticated mutation interface. The credential distribution, not a documentation convention, enforces the N = 1 property.

2.2 The N = 1 Structural Property

The kernel’s authority derives from a conjunctive structural property: it is the only process that can mutate compliance-sensitive state. We state the property precisely.

System model. Fix a single zone. Let P denote the set of processes running within the zone’s operational perimeter and let kernel ∈ P denote the distinguished kernel process. Let Σ denote the set of compliance-sensitive storage tables. Let H : {0, 1}^* → {0, 1}²⁵⁶ denote the content-addressing hash function, assumed collision-resistant against an adversary running in time polynomial in the security parameter. Signature schemes are assumed EUF-CMA.

Definition (kernel-mediated mutation). A mutation m on Σ is kernel-mediated iff (K1) m’s write credential is held by the kernel process and by no other process; (K2) m passes through the distinguished mutation gate μ in the kernel’s control flow; (K3) m’s effect on Σ uses only INSERT (no UPDATE, no DELETE); (K4) m produces an event e linked into the per-entity hash chain by H.

Theorem 1 (N = 1 structural property). Assume the following trust assumptions hold:

• (T1) Credential isolation. The credential-provisioning system issues storage-layer write credentials exclusively to the kernel process.
• (T2) Firewall coverage. Every authorized write route in the kernel’s control-flow graph is dominated by the distinguished mutation gate μ.
• (T3) Schema-level DDL. The storage schema exposes no UPDATE or DELETE privilege on Σ to any credential reachable from any process in P.
• (T4) Hash-chain integrity. H is collision-resistant against the adversary.

Then every mutation of Σ observable by a corridor-participant verifier is kernel-mediated.

Proof sketch. Suppose, for contradiction, that some non-kernel-mediated mutation m of Σ is observable. By (K1) and (T1), no process other than kernel holds write credentials on Σ, so m must originate within kernel. By (T2) every authorized kernel write route is dominated by μ, so m satisfies (K2). By (T3) the schema admits only INSERT on Σ, so m satisfies (K3). If m produces an event e not linked into the per-entity hash chain, either e collides with an event already in the chain (contradicting (T4)) or e falls outside the chain, in which case any verifier holding the chain head detects m’s absence. Either way m is kernel-mediated, a contradiction. ◼

Theorem 1 is a conditional structural guarantee: each of (T1) through (T4) is a distinct trust assumption, and compromise of any one defeats the corresponding clause. (T1) fails under compromise of the credential-provisioning system; (T2) under compromise of the mutation-gate discipline; (T3) under schema-level ALTER compromise by a privileged operator; (T4) under a collision-finding attack on H. These assumptions delineate the boundary of the guarantee. The bar is weaker than full functional refinement against a formal model (seL4; Klein et al., 2009); Theorem 1 is a process-level invariant under a conjunction of operational assumptions, not a code-level invariant against arbitrary binary behaviour.

Mechanisms enforcing (T1) through (T4). Three complementary mechanisms carry the property:

1. Credential isolation. Only the kernel process holds storage-layer connection credentials with write privileges. Business-logic services hold read-only credentials.

2. Mutation firewall. Every state-changing handler in the kernel passes through a distinguished mutation gate that enforces audit journaling, sanctions fail-closed evaluation, and contract validation. A write handler that does not pass the gate is a defect of architecture, not a permitted variant.

3. Append-only event store. Every mutation produces a kernel event whose identifier is a content-addressed hash (SHA-256) of event type, payload, and prior-event identifier. Events are linked per-entity into a hash chain following Haber and Stornetta’s (1991) timestamping construction. The event store accepts only appends; UPDATE and DELETE are forbidden at the storage layer.

2.3 Compliance Evaluation

The kernel evaluates compliance across a fixed, finite taxonomy of regulatory domains, shared across the kernels that participate in the corridor network. The protocol uses the following twenty-three-domain taxonomy:

The taxonomy is pragmatic, not principled: it covers the regulatory surface area of institutional operations across the jurisdictions the protocol is designed to serve. The set is finite and fixed at composition time; extension follows a schema-evolution protocol (Section 8). Instrument-specific domains such as Sharia are evaluated per instrument rather than per venue. A conventional harbor reports NotApplicable on Sharia when the instrument lies outside Islamic-finance scope; an Islamic-finance instrument carries a substantive Sharia verdict; and the composition takes the meet on that per-instrument coordinate.

Each domain is evaluated through fibers, individual compliance rule evaluations against specific statutes. A fiber evaluates one Lex rule against one entity’s state and produces a verdict. Fibers compose into the compliance tensor, where each domain’s verdict is the meet of all fiber verdicts within that domain.

Each domain’s verdict carries two orthogonal axes. The compliance grade lives on the three-chain

NonCompliant < Pending < Compliant,

where lower means more restrictive and Pending represents incomplete evaluation. The applicability marker is drawn from {Applicable, NotApplicable, Exempt} and records whether the domain governs the entity in the jurisdiction at all: Applicable when the domain’s rules apply and a grade is substantive, NotApplicable when the domain does not govern the entity’s activity in that jurisdiction, and Exempt when the entity holds a signed policy artifact that removes the domain from scope. Applicability is a separate axis, not an intermediate point on the compliance chain.

Composition on the Applicable fragment, the sub-lattice where every coordinate is Applicable, is pointwise meet on the three-chain. The full tensor-value type, which carries the mixed-axis applicability information, is strictly richer. The compliance-tensor companion note proves a mixed-axis impossibility dichotomy: no total Heyting algebra structure exists on the full tensor-value type that preserves the applicability provenance required by the audit trail. The production composition is therefore MeetResult-valued: on coordinates where both inputs are Applicable, it returns the three-chain meet; on mixed-axis coordinates, it returns a structured outcome that preserves which jurisdiction contributed which applicability status. This scope is load-bearing for Sections 4.2, 6, and 7.

2.4 Lifecycle Typestates

State machines in the kernel are typestate-encoded: each lifecycle state is a distinct type, and only valid transitions are expressible. Invalid transitions are static errors, not runtime checks. This applies uniformly to the lifecycles of entities (formation through dissolution), licenses (application through grant and renewal), corridors (draft through active, with halted and suspended branches), harbor transitions (the phased corridor-crossing protocol), and watchers (bonding through slashing or unbonding). The typestate encoding makes lifecycle errors unreachable rather than detected.

2.5 Paired Issuance and Clearing

The kernel network is the authoritative issuance layer for programmable securities. A security originates inside a jurisdictional kernel, inherits a twenty-three-domain compliance tensor, and may then be admitted to a secondary clearing venue. In the paired architecture treated here, that secondary venue is Moxie.

The bridge interface is fixed by BRIDGE_PROTOCOL_VERSION = 1. It mirrors the twenty-three-domain ComplianceDomain vocabulary from the kernel into the clearing venue, carries bridge attestations under conjunctive verification by Ed25519 and ML-DSA-65, and transports a temperature classification derived from the authoritative tensor. Cold instruments remain issuance-only. Warm instruments admit constrained secondary handling. Hot instruments may clear on Moxie only when all twenty-three domains are Compliant or NotApplicable; for Sharia-constrained instruments, the Sharia coordinate is therefore load-bearing in graduation.

The asymmetry is deliberate. The kernel network remains authoritative for issuance, passport history, and compliance evaluation. Moxie is a secondary venue that inherits, rather than redefines, the compliance envelope. A clearing rule may further narrow admissibility on the venue; it cannot widen the authoritative envelope certified by the issuing kernel.

2.6 Protocol Accession and Layered Operation

A zone accedes to the protocol by a legally effective act plus operational integration. The legal form may be a statute, regulation, treaty, concession, or licensed-operator agreement, but the accession is not complete unless five facts become externally checkable: the competent authority designates the zone’s kernel as authoritative for compliance-sensitive state within the accession scope; the zone publishes the verification material by which passports and corridor receipts are to be checked; the zone accepts bilateral corridor commitments as binding evidence rules for inbound and outbound operations; the sovereign operator responsible for the kernel is named in the legal instrument or a referenced public registry; and the zone publishes the lifecycle and dispute procedures that govern suspension, halt, and retirement. Operational integration without that legal act is outsourcing. Legal proclamation without the verification surface is aspiration. Protocol accession requires both.

The deployed stack separates into three layers. The protocol layer fixes passports, corridor semantics, and fee-bearing transition types. The operating layer runs a zone’s kernel as a sovereign service, whether self-operated or delegated. The application layer hosts regulatory consoles, workflow engines, and sector-specific tools above the protocol. This separation matters because zones can share a protocol while differing in operators and application inventories.

The economic consequence is not a quadratic software network effect. New zones do not form all possible corridors. Each corridor is a sovereign negotiation with non-trivial legal cost, elapsed time, and failure probability. The realized growth regime is therefore sparse, and the network-value argument belongs to the Odlyzko-Tilly O(nlog n) family analysed in Section 8, not to Metcalfe n².

2.7 Architectural Commitments and Proof Families

The paper treats the kernel through architectural commitments rather than repository facts. Five commitments are load-bearing: separation of authoritative mutation from observational and external-action lanes; explicit fee accounting for corridor and settlement transitions; separation between kernel operation and programmable applications; twin-state inversion between authoritative local state and portable attestations; and regulator interventions represented as explicit, signed ceremonies rather than hidden exceptions.

These commitments induce a family of proof obligations. The proof family includes authoritative-store integrity, emergency halt semantics, lattice orthogonality of compliance composition, leader transfer for background coordination, lifecycle morphism for jurisdiction creation and merger, trigger-system causality, key-rotation continuity, asset-lifecycle safety, and corridor accountability under intervention and partition. The paper uses these as formal abstractions. It does not ask the reader to infer conclusions from implementation inventories.

3.1 Principal Write Path: Full Compliance

Every state-changing operation passes through a fixed pipeline. The principal path (end-user-originated writes) enforces the full compliance evaluation:

At target, multi-step or delegated program-authored activity begins with an operation-envelope admission gate. The envelope carries the Op payload and the Lex/rule receipts that justify it. Admission checks the payload structurally and against the declared rule-pack, primitive-registry, capability, gas, replay, and sanctions/corridor context before the operation reaches business-logic delegation. Current public evidence is narrower: raw Op admission performs structural type/effect checks and runtime sanctions/tensor gates, while full signed-envelope admission remains an implementation obligation. The steps below describe the compliance pipeline once the submission artifact has been admitted.

Step 1: Authentication. The caller presents a credential. The kernel extracts a uniform caller identity with role, entity scope, and delegated-program attribution. The same identity structure applies uniformly to human operators, API consumers, and delegated programs.

Step 2: Sanctions fail-closed gate. Before any compliance evaluation, the kernel screens the entity and its counterparties against sanctions lists. A license, humanitarian carveout, sovereign exemption, or shared-authority recognition is encoded before this point as rule-scope or applicability evidence inside the Sanctions evaluator. If the applicable Sanctions coordinate still returns NonCompliant, the operation is rejected. This is a legal requirement under the International Emergency Economic Powers Act (50 U.S.C. 1705) and the equivalent statutes in each sovereign sanctions regime.

Step 3: Pre-flight compliance evaluation. The kernel builds a compliance tensor for the entity in the target jurisdiction, evaluating every applicable domain via pluggable evaluators. Each evaluator invokes fibers and aggregates their results. The tensor T(E, J) : 𝒟 → TensorValue maps each domain to a compliance grade plus an applicability marker. Required Applicable domains fail closed: NonCompliant blocks, and Pending blocks ordinary writes unless the operation is explicitly a staged lifecycle step whose rule permits evidence creation before final clearance.

Step 4: Business-logic delegation. The primitive operation (entity formation, share issuance, payment instruction) proceeds through the business-logic service layer, invoked via a typed client that is the sole authorized gateway between the kernel and the outside.

Step 5: Operational evidence storage. The fact that the operation succeeded is itself domain evidence. The kernel maps operation types to evidence domains: entity formation produces Corporate evidence, cap-table changes produce Securities and Corporate evidence, identity verification produces KYC, AML, and DataPrivacy evidence. The mapping is fail-closed: unverified evidence produces no domain credit.

Step 6: Post-flight re-evaluation. The kernel re-evaluates the compliance tensor, this time incorporating the operational evidence from Step 5. Domains that were Pending in pre-flight may now have substantive verdicts. The two-phase evaluation design separates the sanctions gate and baseline from the evidence the operation produced.

Step 7: Verifiable-credential issuance. The kernel issues a signed W3C Verifiable Credential attesting to the post-flight compliance evaluation. The credential captures the tensor state, the evaluation timestamp, the issuing zone’s decentralized identifier, and the tensor commitment digest. The credential is designed for interoperability with eIDAS cross-border trust services.

Step 8: Compliance passport update. The entity’s compliance passport, a hash-chained record of all compliance evaluations, is extended with the new evaluation. The passport records the previous digest (hash-chain link), the current domain verdicts, the tensor commitment, and the verifiable-credential digest. The passport update is itself signed by the zone.

Step 9: Mutation journaling. The mutation is recorded in the append-only event store. The journal entry is content-addressed, hash-chained per entity, and carries the full observation context produced by the compliance evaluation.

3.2 Reduced Path: Internal Service Writes

Business-logic services write through an internal interface that enforces a reduced pipeline: authentication, sanctions preflight under the same fail-closed verdict semantics as the principal path, the persistence write within a single storage transaction, and mutation journaling. Internal writes do not run the full tensor evaluation, verifiable-credential issuance, or passport update. The design decision is that compliance evaluation happens once, at the point where user intent enters the kernel (through the operation engine); internal writes persist already-evaluated results.

This reduced path creates a design obligation: every internal write must carry a durable reference to an operation whose intent was evaluated on the principal path, or to an explicitly enumerated evaluator exception whose compliance consequences are accepted by the rule pack. A write that neither originates from an evaluated operation nor passes full-tensor evaluation on its own terms is a defect of scope.

3.3 Generic Tabular Writes

For persistence-layer writes that require no domain-specific validation, the kernel provides a generic tabular-write interface over a static allowlist of table, field, type, and nullability constraints. Writes outside the allowlist are rejected. Compound atomicity is provided by wrapping the writes in a single transaction. Idempotency keys deduplicate resubmission. The interface reduces the marginal cost of a new write operation to a configuration change, not a code change, while preserving the invariant that all writes funnel through audited paths.

3.4 The Proof Bundle

Every principal write through the kernel produces a proof bundle. Reduced internal writes produce mutation receipts that cite the principal proof bundle or evaluator exception authorizing them.

1. Mutation journal entry. Content-addressed, hash-chained, append-only. Carries the operation type, resource identifiers, acting principal, timestamp, and compliance observation context.

2. Compliance observation context. Domain outcomes (per-domain verdicts from fiber evaluations), evaluation duration, evidence types, and the tensor commitment digest. This is the raw material for the intelligence corpus: every compliance evaluation contributes to the system’s understanding of jurisdictional requirements.

3. Verifiable credential. Signed attestation of the post-flight compliance tensor in the W3C Verifiable Credentials Data Model. The subject captures entity, jurisdiction, overall status, per-domain results, tensor commitment, and hash-chain link.

4. Compliance passport update. The entity’s hash-chained compliance history, extended with the new evaluation. The passport is a sequence of snapshots, each linked to its predecessor by a content-addressed digest.

This proof bundle is the fundamental unit of portable compliance. When an entity crosses a corridor to a new jurisdiction, it carries its passport, a verifiable, tamper-evident history of every compliance evaluation the issuing jurisdiction performed. When a programmable security is admitted to a secondary clearing venue, the bridge attestation is derived from the same bundle rather than from a parallel evidentiary surface.

4.1 Tensor Definition

A compliance tensor T(E, J) for entity E in jurisdiction J is a function from the domain set 𝒟 to the well-formed tensor-value type. Each per-domain value is a pair

T(E, J)(d) ∈ WF({NonCompliant, Pending, Compliant} × {Applicable, NotApplicable, Exempt}).

The well-formedness predicate requires a compliance grade exactly when the applicability marker is Applicable; NotApplicable and Exempt carry no hidden compliance grade.

The first component is the compliance grade on the three-chain NonCompliant < Pending < Compliant. The second component is the applicability marker, recording whether the domain governs the entity in the jurisdiction substantively (Applicable), does not govern the activity at all (NotApplicable), or has been removed from scope by a signed policy artifact (Exempt). Applicability is separate from the grade: an Exempt coordinate is not a maximally-compliant grade in disguise, and a NotApplicable coordinate is not a middling-compliant grade in disguise; both carry provenance the audit trail must preserve.

The tensor is parameterized by a jurisdiction configuration that specifies (i) the applicability marker per domain, usually a proper subset or the full set 𝒟, and (ii) for a synthetic zone composed from multiple jurisdictions, which source jurisdiction governs each domain. For a natural zone (single jurisdiction), every Applicable domain is governed by that jurisdiction. For a synthetic zone, different domains may inherit from different source jurisdictions, Corporate from one, Tax from another, Securities from a third, and the per-domain attribution is recorded in the configuration.

Each domain has a pluggable evaluator. The evaluator invokes fibers, individual Lex rule evaluations against specific statutes, and aggregates their verdicts via the fiber composition described in the companion Lex paper. The tensor supports both explicit state storage (pre-computed results loaded from evidence) and dynamic evaluation (evaluators invoked at tensor evaluation time). There is one evaluator per domain.

4.2 Lattice Structure

Per-domain compliance grade: a three-chain. On each domain coordinate, the compliance grade lives on the three-chain

NonCompliant < Pending < Compliant

where lower means more restrictive. Compliant is the top, NonCompliant is the bottom, and Pending (evaluation incomplete) sits strictly between them because incomplete evaluation must be treated as more restrictive than a substantive positive verdict. The three-chain is a finite distributive lattice and therefore a Heyting algebra in the per-domain factor.

Applicability axis: orthogonal to the grade. The applicability marker {Applicable, NotApplicable, Exempt} is a separate axis. NotApplicable and Exempt are not intermediate points on the compliance chain inserted between Pending and Compliant; they are distinct applicability states with distinct provenance obligations. A jurisdiction that reports NotApplicable is affirming the domain does not govern the entity’s activity at all; a jurisdiction that reports Exempt is affirming the entity holds a signed policy artifact that removes the domain from scope. Collapsing these into a single total chain would destroy the audit information that distinguishes “not governed” from “substantively governed and cleared.”

Applicable fragment: pointwise meet-semilattice. On the Applicable fragment ℒ^App = ∏_{d ∈ 𝒟}D_d, the sub-lattice where every coordinate is Applicable, composition is the pointwise meet on the three-chain factors. ℒ^App is a finite distributive lattice (a product of Heyting algebras is a Heyting algebra), so the pointwise residual is well-defined on this fragment. Associativity, commutativity, and idempotence of meet hold on ℒ^App, and the meet of two Applicable-fragment tensors produces the most restrictive constraint surface satisfying both jurisdictions simultaneously.

Full tensor-value type: impossibility of total Heyting structure. On the full tensor-value type, which carries the mixed-axis applicability information, no total Heyting algebra structure exists that preserves the applicability provenance. The compliance-tensor companion note states this impossibility result as a dichotomy: the positive characterization is that the MeetResult-valued operator is the information-preserving structured composition compatible with pointwise composition on the Applicable fragment. On coordinates where both inputs are Applicable, the operator returns the three-chain meet; on mixed-axis coordinates, it returns a structured outcome that names which jurisdiction contributed which applicability status. This scope is the canonical compliance algebra: per-domain Heyting structure, Applicable-fragment meet-semilattice with pointwise residual, and a MeetResult-valued composition on the full type.

Operational planning primitive. Because no total Heyting algebra exists on the full tensor-value type, the operational planning primitive for delegated planners is not a single residual operator over the full type. It is the scoped residual on fixed applicability slices (Section 6.3), together with a remediation operator built from the Applicable-fragment pointwise order plus source attribution for mixed-axis cases. Mixed-axis outcomes are handed to the rule layer that owns the applicability distinction rather than absorbed into a synthetic verdict.

The algebraic structure, associativity, commutativity, and idempotence of meet; the Galois connection for the pointwise residual on fixed applicability slices; and the mixed-axis impossibility dichotomy, are presented in the compliance-tensor companion note. The algebra is not an engineering convenience; it is the mathematical structure from which composition and selective disclosure are derived, and against which remediation state transitions are checked.

4.3 Tensor Commitments

A tensor evaluation produces a tensor commitment: a content-addressed digest of the canonical bytes of the evaluation result. This commitment binds the tensor state to a specific point in time and is included in verifiable credentials and passport entries. A Merkle inclusion proof verifies that a disclosed domain commitment belongs to the committed tensor. It does not, by itself, prove predicates about hidden domains; those privacy-preserving predicates require the zero-knowledge proof obligations stated in Section 11.

4.4 The Compliance Passport

The compliance passport is a hash-chained sequence of compliance evaluation snapshots. Each entry records:

• The entity the passport belongs to.
• The jurisdiction evaluated against.
• The aggregate compliance status.
• The per-domain compliance results.
• Summary statistics (passing and blocking counts).
• The tensor commitment digest.
• A hash-chain link to the previous passport state.
• The content-addressed digest of the current state.

The hash-chain link makes the passport tamper-evident: modifying any historical entry breaks the chain. This follows the Haber-Stornetta (1991) construction for linked timestamping, each entry is cryptographically bound to all previous entries. The passport is signed by the issuing zone’s signing key, making it independently verifiable by any party holding the zone’s public key.

The passport has a default validity period with domain-specific time-to-live for domains with shorter regulatory cycles (sanctions screening being the obvious example). The verifiable-credential format follows the W3C Verifiable Credentials Data Model and is designed for interoperability with eIDAS 2.0 cross-border trust services.

4.5 Passport Verification

A receiving jurisdiction verifies a foreign passport through the following procedure:

1. Signature verification. Verify the signature under the issuing zone’s verifying key. The receiving zone maintains a registry of known zone verifying keys indexed by key identifier and validity interval.
2. Hash-chain integrity. Verify that each entry’s link digest matches the preceding entry’s content digest.
3. Tensor commitment verification. Verify that the claimed per-domain results produce the claimed tensor commitment under the content-addressing hash (SHA-256).
4. Freshness. Verify that the passport has not expired under its issuance timestamp and validity interval.
5. Revocation. Verify that the issuing zone’s verifying key was not revoked at the passport’s issuance time, as recorded in the receiving zone’s key registry with revocation timestamps.
6. Pack-version compatibility. Verify that the passport’s declared pack versions are within the receiving zone’s corridor-parameter validity windows, ensuring that the μ mapping, grade-recognition maps, and R policy apply under the pack versions the passport was issued under.

Theorem 2 (passport verification soundness). Under EUF-CMA signatures and collision-resistant content-addressing: a passport π verified by steps (1) through (6) is either (a) cryptographically attributable to an issuing-zone key that was valid and non-revoked at the passport’s issuance time, under pack versions accepted by the receiving corridor’s validity window, or (b) rejected with a specific failure code.

Critically, verification does not require online trust in the issuing zone’s database or availability. The receiving zone verifies the cryptographic integrity of the passport and then applies its own (R, μ, γ) parameters to determine which domains to accept and which to re-evaluate locally. When a foreign evaluation is accepted, the trust is explicit: it rests on sovereign key provenance, corridor policy, accepted rule-pack versions, revocation checks, and any re-evaluation or audit policy the corridor requires. This is disclosed verification soundness: signed evaluation nodes, disclosed Merkle inclusions, non-revoked PCAuth or sovereign credentials, accepted pack windows, and replayable proof-bundle entries support the domains the receiver is allowed to inspect. It is not a privacy theorem over hidden domains. The passport provides evidence; the corridor parameters determine how that evidence is consumed.

5.1 Corridor Definition

A corridor is a bilateral relationship between two kernels. It is not a shared ledger, not a consensus mechanism, not a message bus. It is a parameterized channel through which typed compliance state flows. A corridor can exist only between zones that have completed protocol accession in the sense of Section 2.6.

A corridor is defined by the pair of participating zones (with their jurisdiction identifiers), a corridor type classifier based on zone metadata (cross-border, intra-federal, free-zone-to-host, or free-zone-to-free-zone), the destination-side re-evaluation domain set R, a domain-recognition map μ from source-domain names into destination-domain names, grade-recognition maps γ_d for the domains recognized by the corridor, and legal-instrument clauses that specify validity windows, evidence classes, and exceptions. Domains in R must be re-evaluated locally; domains outside R may consume foreign evidence only through the corridor’s declared recognition maps and grades.

5.2 The (R, μ, γ) Parameterization

The triple (R, μ, γ) is the fundamental parameterization of a corridor. It encodes the mutual recognition agreement between two jurisdictions in machine-executable form.

R: The re-evaluation set. When an entity’s compliance passport arrives at the receiving zone, R determines which domains the receiving zone will re-evaluate locally rather than accepting from the passport. A smaller R means more mutual recognition; a larger R means more local re-evaluation.

The default constraint for general-purpose corridors is that Sanctions is in R. A jurisdiction does not inherit a foreign sanctions evaluation as its own local clearance. A narrow subnetwork may encode Sanctions outside R only under a SharedSanctionsAuthority certificate: a signed legal artifact naming the common authority, the covered sanctions list or decision process, the bound jurisdictions, the validity window, the revocation procedure, and the corridor epochs to which the certificate applies. Characterizing those subnetworks and proving the certificate’s governance treatment is a separate lawpack and corridor-governance obligation; absent that proof, the safe corridor rule is local sanctions re-evaluation.

μ: The domain-recognition map. Different jurisdictions may use different names for equivalent regulatory categories. μ maps source-domain names into destination-domain names where the corridor instrument recognizes them as comparable. When μ is the identity function, both jurisdictions use the same domain taxonomy. When μ is non-trivial, the receiving zone maps foreign domain evaluations to local equivalents before deciding whether to accept them.

γ: The grade-recognition maps. A recognized domain name is not enough. The destination jurisdiction must also specify how source-side grades are consumed. A grade map γ_d sends accepted source grades for domain d to destination-side grades, review flags, or rejection codes. A grade map can be partial; an undefined input fails closed into local re-evaluation.

Recognition grades. The system supports four grades of per-domain recognition:

• Full, foreign evaluation accepted without local re-evaluation. Removes the domain from R.
• Partial, foreign evaluation accepted but flagged for local review. Removes from R but adds a review flag.
• Conditional, foreign evaluation accepted only if a specified condition is met (e.g., “FATF member state”, “bilateral treaty in force”). If the condition is not met, behaves as None.
• None, requires full local re-evaluation. Domain remains in R.

(R, φ) as reliance-envelope depth. We summarise (μ, γ) taken together as a single recognition-depth parameter φ when the focus is the depth at which the receiving jurisdiction admits the issuing jurisdiction’s evidence. The pair (R, φ) is the corridor’s typed handle on the reliance class a receiving party may attach to a contingent claim cleared under the corridor. Concretely: a claim issued by a multi-harboured entity in jurisdiction A and transferred under corridor C_AB to a holder in jurisdiction B inherits a reliance envelope whose depth is bounded by (R_AB, φ_AB). Shallow recognition (large R, downgrading φ) yields a thin envelope: the receiving jurisdiction accepts only a narrow slice of the issuing jurisdiction’s evidence, so the holder may rely on the cleared claim only for a narrow legal purpose with shallow recourse. Deep recognition (small R, identity-like φ) yields a thicker envelope: the receiving jurisdiction accepts a broader slice of the issuing jurisdiction’s evidence, so the holder may rely on the cleared claim for a broader purpose with deeper recourse. The corridor parameters are therefore typed inputs not only to admissibility but also to the depth of the reliance envelope under which a cleared claim may be relied upon by parties outside the issuance harbour. The clearing layer (companion paper Intelligent Assets) consumes (R, φ) as a typed input to the cleared claim’s reliance envelope; the protocol layer (this paper) is the source of those parameters.

5.2.1 Corridor Friction Profiles

Every active corridor carries a friction profile

F(C) = (Λ_C, ρ_C, δ_C, κ_C, χ_C)

where Λ_C is the latency distribution over completed corridor operations, ρ_C is long-run rejection rate, δ_C is long-run dispute rate, κ_C is the corridor’s per-operation cost schedule, and χ_C is its operational-capacity envelope. The summaries reported to operators are quantiles of Λ_C (in particular p50 and p99), together with windowed estimates of ρ_C and δ_C.

One convenient model treats each corridor operation as a Markov chain on

{Submitted, UnderReview, Accepted, Rejected, Disputed, Settled}.

Under ergodicity assumptions, ρ_C is the stationary mass on Rejected and δ_C is the stationary mass on Disputed. The architecture does not require this model to be exact; it uses the model to make routing and corridor comparison explicit. A routing weight can then be defined as

w(C) = α p99(Λ_C) + β ρ_C + γ δ_C + η κ_C,

with coefficients chosen by the routing policy. Corridor friction is therefore a formal quantity, not a verbal impression.

5.3 Corridor Asymmetry

Corridors are asymmetric. Zone A’s recognition of zone B’s AML evaluation does not imply zone B’s recognition of zone A’s AML evaluation. Each direction has its own (R, μ, γ). This mirrors the reality of international regulatory agreements: the EU’s recognition of a third country’s AML framework under the 4th Anti-Money Laundering Directive does not automatically mean that country recognizes the EU’s framework.

5.3.1 Corridor Algebra and Its Failure Modes

Corridor composition asks: given a corridor C_AB from zone A to zone B with parameters (R_AB, μ_AB, γ_AB) and a corridor C_BC with parameters (R_BC, μ_BC, γ_BC), what evidence obligations arise along the staged route A → B → C? The question is load-bearing for multi-hop portability and for route coherence: if an entity can route A → C directly or through B, the two routes must either produce compatible carried compliance state or a typed obstruction explaining why they do not.

Staged-route obligation. The staged route composes the recognition maps only where both partial maps are defined and only for domains whose grade-recognition maps compose without losing legally relevant evidence. On the source-side vocabulary of A, the set of domains that must be treated as requiring re-evaluation somewhere along the route contains μ_AB⁻¹(R_AB) ∪ (μ_BC ∘ μ_AB)⁻¹(R_BC), where each preimage is taken only on the domain where the corresponding partial map is defined. This expression is not a claim that an arbitrary bilateral corridor triple has an associative product. It is the footprint of a staged route under explicitly typed maps.

Route-coherence law. A direct corridor C_AC and a staged route A → B → C are route-coherent only if their domain maps, grade maps, re-evaluation masks, pack-version windows, and legal-instrument clauses agree after translating them into a common vocabulary. The normalized checker core is Qed-closed in op/formal/coq/CorridorMonotone.v: route_snapshot_eqb is sound and complete for equality of carried compliance cells, fresh-evaluation domains, and instrument clauses once both routes have been normalized, and the false-obstruction/decidability lemmas close the Boolean boundary at that snapshot layer. What remains open is the semantic lift from concrete corridor data (R, μ, γ), pack windows, grade maps, and instrument clauses to those normalized snapshots, plus completeness for every named obstruction class. The target theorem is normalize_route soundness and obstruction completeness for the finite surfaces the protocol compares. A general associativity theorem for all corridor instruments would require hypotheses stronger than this paper assumes. The architecture therefore treats failure of these equations as a structured RouteCoherenceObstruction, not as a hidden algebraic normalization.

Invertibility of composition, where available, is a separate and stronger property; it is required for round-trippability, not for ordinary one-way portability. The architecture does not assume groupoid structure.

Failure modes. Corridor composition has three principal failure modes. Each is a real obstruction the architecture must recognize.

1. Route-coherence failure. Let μ_AC denote the direct A → C domain-recognition map, and μ_BC ∘ μ_AB the staged recognition map through B where that composite is defined. Let R_AC denote the direct destination-side re-evaluation mask, and let the staged route carry the typed source-side footprint described above. If the maps, masks, grade maps, or instrument clauses disagree after comparison in a common vocabulary, the two routes produce different carried states. The consistency equation is structurally analogous to a cocycle law, but no sheaf-theoretic gluing theorem is claimed here. The disagreement is not a bug; it is a genuine inconsistency between the bilateral recognition agreements A → B, B → C, and A → C. Resolution requires that at least one of the three corridor agreements be renegotiated. The architecture surfaces the failure as a typed RouteCoherenceObstruction value naming (i) the domains on which the two routes disagree and (ii) the corridor agreements whose renegotiation would close the gap; it does not silently choose a winner.

2. Mutual-recognition asymmetry. If zone A accepts zone B’s AML evaluation but zone B does not accept zone A’s AML evaluation, the path A → B → A does not return an entity to the state it started in. The entity that crosses A → B under full AML recognition and crosses back under required AML re-evaluation finds its AML verdict downgraded in the return trip. This is not a pathology of the algebra; it reflects real asymmetry in international regulatory arrangements. The architecture preserves the asymmetry rather than smoothing it over. An entity planning a round trip must query both directions.

3. Pack-version skew. Corridor parameters (R, μ, γ) reference specific pack versions on either side. If one side updates its pack (say, tightens KYC rules in a new lawpack version), the corridor parameter may cease to be accurate for the new pack version. The protocol handles this conservatively: corridor parameters carry validity windows, and operations after the window’s expiry require re-verification. The alternative, allowing operations to proceed under stale parameters, would admit a class of attacks in which one side exploits the lag between a pack update and the corridor renegotiation to route operations under out-of-date recognition. The validity window forecloses this.

The three failure modes are distinct: cocycle failure is a disagreement between three bilateral agreements; mutual-recognition asymmetry is an intended feature of bilateral agreements; pack-version skew is a temporal drift between agreement and ground truth. Treating them uniformly would obscure the distinctions; treating them separately lets each class be diagnosed and resolved on its own terms.

5.3.2 The No-Global-Consensus Claim

This paper claims the corridor network achieves cross-border safety without global consensus. The claim is an architectural decomposition, not an impossibility-evasion result.

The corridor network factors cross-jurisdictional compliance state into two levels: (i) per-zone local state, governed by the zone’s own evaluation and event chain, and (ii) bilateral receipt chains, shared between exactly two zones. It has no global ledger on which all zones must agree. This avoids global consensus for ordinary corridor operations while leaving arbitrary multi-zone atomic commitment as a separate obligation. A transaction whose legal effect simultaneously depends on three or more zones must be decomposed into a saga of bilateral steps, or must carry a separate multi-party finality certificate with its own proof obligations. The load-bearing two-zone protocol is the bilateral signed commitment (BSC) specified in Section 5.4.

Fail-stop adversary. Under a fail-stop (crash-only, non-Byzantine) model for zone kernels, the BSC protocol is intended to achieve commit-safety: each kernel evaluates independently, signs its verdict, exchanges signatures, and transitions to a terminal only under the finality condition stated in ledger obligation O-2. If a participant crashes after that finality condition is met, the surviving participant determines the outcome from the certificate alone; no coordinator is required.

Byzantine adversary, bounded by signature unforgeability. Under a model in which a zone operator may behave arbitrarily (lie, fork, sign contradictory verdicts), but cryptographic signatures remain EUF-CMA-unforgeable, the pairwise protocol does not by itself establish commit-safety. A malicious zone can attempt to equivocate by issuing two conflicting signed verdicts under the same operation identifier and epoch. The architecture compensates with three mechanisms: (i) signed verdicts are non-repudiable and content-addressed, so equivocation is detectable when both conflicting verdicts surface; (ii) a watcher layer (Section 9) observes receipt chains across corridors and can surface conflicting verdicts through cross-checking; (iii) for high-value operations, zero-knowledge lock proofs (Section 9.6) bind the initiating zone’s verdict to a nonce, epoch, and resource commitment, so equivocation produces two verifiable proofs under the same (zone-did, nonce, epoch) with incompatible resource digests. The proof obligation is accountable disagreement (ledger obligation O-3): a safety violation should produce either a terminal-disagreement obstruction or a cryptographic certificate of blame. The defence is cryptographic accountability, not consensus.

Scope limit. The protocol leaves Byzantine fault tolerance in the classical sense outside its claim: damage can occur during the window before the second conflicting verdict surfaces. A zone operator in a strong Byzantine regime may temporarily route operations through a corrupted kernel until the equivocation is detected, at which point the corridor-demotion and slashing mechanisms activate. The defence is temporal: detect, attribute, punish. Reputation dynamics, corridor partners adjusting R and recognition grades in response to observed behaviour, are operational, with steady-state game-theoretic characterisation open (Section 11). The limit is explicit: the architecture removes the need for global consensus on entity compliance state while retaining local sovereignty. Trust in the zone operators remains necessary; it is a political property of the sovereign, not a computational property of the protocol.

5.4 Bilateral Signed Commitment

Cross-zone operations, harbor addition or lawful harbor retirement, cross-border settlement, and corridor-crossing trade require coordination between two sovereign kernels. We refer to the load-bearing proof target as the bilateral signed commitment (BSC). BSC is a target bilateral finality protocol rather than a closed claim of classical two-phase or three-phase atomic commitment: neither side is designated coordinator, and the safety theorem depends on the finality-certificate and recovery obligations below.

Protocol. Parties: zone kernels A and B. State: s ∈ {Init, Locked, Verified, Committed, Aborted}. Messages are signed envelopes ⟨m, σ_X⟩ under zone key k_X. An operation carries a unique identifier ω, a nonce n, and an epoch ϵ.

Init -> Locked -> Verified -> Committed
  |        |         |
  +--------+---------+-> Aborted

Phase 1: Lock. The initiating zone locks the relevant resources (entity state, account balances, compliance passport). The lock is attested with a signature under the zone’s verifying key. For high-value operations, the lock may additionally be accompanied by a zero-knowledge proof binding the initiating zone’s resource commitment, nonce, epoch, corridor identifier, and zone identifier; the accountability role of this proof is specified in Section 9.6.

Phase 2: Sign verdict. Each zone independently evaluates compliance for the cross-zone operation and signs a verdict v_X = sign_kX(ω, n, ϵ, tensor-state_X, d_X) containing: - the operation identifier ω and type; - the zone’s compliance tensor state; - the zone’s decision d_X ∈ {consent, reject}; - a signature over the verdict under the zone’s verifying key.

Verdicts are signed independently: neither zone sees the other’s verdict before signing, preventing one zone from conditioning its evaluation on the other’s.

Phase 3: Exchange and terminate. Each side transmits v_X to the other. The transition Locked → Verified requires, at each side, durable possession of both v_A and v_B together with valid signatures under both zones’ keys. This is the Verified-entry invariant: entering Verified means both signed verdicts are durable at that side. Terminal transition additionally requires the finality certificate specified in ledger obligation O-2, or an abort certificate accepted by the timeout rules, to enter the corridor receipt chain.

From Verified plus the required terminal evidence, each side computes the decision d = consent(v_A) ∧ consent(v_B) on the certificate’s verdict pair and transitions to Committed if d, else Aborted. Commit is final only when supported by the receipt-chain finality evidence. Abort is idempotent; commit fails closed on repeated calls.

The BSC orchestrator is a pure state machine with no I/O: the caller drives transitions through begin, lock, sign-verdict, exchange-verdicts, commit, abort, and timeout-check. Invalid transitions produce errors. The certificate core is mechanized in op/formal/coq/BSCInvariants.v: finality_certificate, abort_certificate, terminal_evidence, finality_commit_iff_both_accept, terminal_evidence_functional, and recovery_from_terminal_evidence_is_pure state and prove that accepted terminal evidence determines a unique terminal. The remaining object is an AcceptedTerminalEvidence receipt-chain witness tying that certificate to corridor id, (ω, ϵ), sequence or vector-clock position, endpoint signatures, key-epoch continuity, and inclusion proofs. The theorems below are the remaining protocol obligations under the stated assumptions (Section 10): binding the certificates to receipt-chain durability, payload instantiation, and partition recovery.

Ledger obligation O-2a (BSC commit-safety under fail-stop). Under a fail-stop (crash-only) adversary on either or both zones: if side X is in Committed then side X̄ is either in Committed (terminal agreement) or in a state from which only Committed is reachable on the terminal’s recovery schedule.

Proof target. Entry to Committed must be guarded by receipt-chain finality strong enough to prevent one side from committing while the other remains Locked and later times out. Durable local possession of both verdicts is insufficient by itself to prove that the peer has reached the same recovery schedule. The certificate-core proof establishes uniqueness of terminal recovery from accepted evidence; the remaining release-gate proof must show that the same evidence is durably available through the corridor receipt chain.

Ledger obligation O-2b (BSC partition-heal agreement). Suppose the finality certificate required by ledger obligation O-2a is durable at both sides. For any partition schedule P opening after that point, for any heal schedule that terminates, both sides reach the same terminal (Committed or Aborted) without further coordination.

Proof target. Verdicts are content-addressed and signed. The certificate-core theorem in BSCInvariants.v proves that the terminal is a pure function of accepted terminal evidence. The missing proof obligation is to show that the finality certificate enters both corridor receipt chains and is recovered after heal. Once that is shown, both sides compute the same decision d = consent(v_A) ∧ consent(v_B) on the same inputs; both transition to the same terminal. The partition-heal exchange is a receipt-chain integrity verification, not a state merge.

Remark on the precondition. If the partition opens during Locked, one side has signed its verdict but the other has not received the signature, the protocol is blocking until heal. This block is bounded: the Locked-state validity window triggers unilateral lock release at expiry. Liveness is bought by bounded locks, not by a coordinator-independent non-blocking property in the classical n-party sense.

Ledger obligation O-3 (BSC accountable safety under bounded-Byzantine). Assume the signature scheme is EUF-CMA and messages are content-addressed. If BSC reaches a state where side A is in Committed and side B is in Aborted (or vice versa), the protocol should either produce an accepted terminal-disagreement certificate naming the missing finality precondition, or produce an equivocation certificate naming the zone that signed conflicting artefacts.

Proof target. Terminal disagreement alone does not imply equivocation; it may also reflect an underspecified finality condition, malformed imported evidence, or a timeout race. An equivocation certificate is accepted only when it contains two conflicting signed verdicts or terminal artefacts under one zone’s key for the same (ω, ϵ) and incompatible resource commitment, with receipt-chain or watcher inclusion evidence. Slashing-enforceability is a separate mechanism requiring a bond custodian; we distinguish detection, attribution, slashing, corridor-demotion, and trust-level adjustment as distinct properties.

5.5 Foreign Operation Verification

When a zone completes an operation and sends a certificate to a partner zone, the receiving zone verifies the certificate. The verification:

1. Checks the signature against the origin zone’s known public key.
2. Translates the foreign compliance state into the local domain space using μ and the applicable grade-recognition maps γ.
3. Re-evaluates the Sanctions domain locally. A foreign sanctions verdict is evidence at most; it is never inherited as the local verdict. Legal carveouts are represented as Sanctions-rule scope or applicability evidence before evaluation, not as an override after a NonCompliant result.
4. Computes an aggregate verdict incorporating the translated foreign state and the local re-evaluations for domains in R.

For general-purpose corridors, local sanctions re-evaluation is the default non-recognition constraint in the corridor protocol. Every other domain’s treatment is configurable through (R, μ, γ). Sanctions is re-evaluated locally unless the corridor governance state carries an accepted SharedSanctionsAuthority certificate covering the domain, parties, validity window, legal basis, and revocation state.

5.6 Why This Is Not Federation

Classical federation systems (X-Road, GAIA-X, various health data exchanges) move data between organizations. Corridors differ in three specific ways:

1. Typed compliance tensors, not opaque data. Corridors carry compliance tensors, structured evaluations with defined domain semantics. X-Road carries data values (a name, an address, a KYC status). SWIFT carries payment instructions. A corridor message is not a data record; it is a compliance evaluation with algebraic structure.

2. Algebraic composition laws. Compliance tensors support pointwise meet and, on fixed applicability slices, a pointwise residual together with a remediation operator. These operations have provable algebraic properties within their stated scope. When two Applicable-fragment tensors are composed, the result is the unique most-restrictive constraint satisfying both. On mixed-axis coordinates, composition returns a structured outcome rather than pretending there is a single lattice value. Federation systems have no composition semantics; data received from a partner is consumed as-is or discarded.

3. Formally targeted composition. The tensor algebra, the Lex type system, and the BSC protocol have formal specifications with machine-checkable obligations. Some obligations have closed evidence; others, including full BSC mechanization beyond bounded/model evidence, remain proof targets. The claim is that the composition is targeted at proof, not that every bit is proved.

The plumbing is familiar (bilateral channels, signed messages, mutual authentication). The content is new: typed tensors that compose point-by-point, with proof targets.

5.7 No Transitive Trust

Multi-hop corridors do not inherit trust transitively. If zone A has a corridor with zone B, and zone B has a corridor with zone C, an operation traversing A -> B -> C is re-evaluated at every hop. Zone B does not relay zone A’s compliance evaluation to zone C; zone B performs its own evaluation (incorporating zone A’s passport via the A-B corridor parameters) and produces its own certificate, which zone C then verifies independently.

This is the correct behavior. Transitive trust in compliance would mean that zone A’s regulatory standards propagate to zone C through zone B even though zone C has no bilateral agreement with zone A. No sovereign regulator treats regulatory recognition that way.

Multi-hop composition evaluates transitive compliance across three-or-more-jurisdiction paths with per-domain evidence policies, re-evaluating sanctions at every hop unless every relevant hop is covered by a valid shared-authority certificate. When the three-jurisdiction cocycle fails (Section 5.3.1), the protocol reports the obstruction rather than silently selecting a path; the entity receives an explicit obstruction indicating which corridor agreements disagree on the relevant domain.

5.8 Graduated Trust

Corridors carry a trust level in a finite set L = {ℓ₀, ℓ₁, …, ℓ_k}, with per-level operational-limit policies π_ℓ (bounded per-operation value, per-window volume, in-flight count, and settlement-window length). A corridor begins at ℓ₀ with conservative policy π_ℓ0 and is promoted one level on observed-settlement thresholds or demoted on observed-failure thresholds. Specific numeric thresholds in π are deployment-configured and negotiated bilaterally between zone operators; the architecture provides the mechanism (a typed trust-level variable carried on the corridor, policy tables keyed by level, and monotonic promotion/demotion rules), not the numbers. The mechanism ensures that new corridors operate under conservative constraints until they demonstrate reliability, while established corridors benefit from higher throughput and shorter settlement windows.

5.9 Corridor Lifecycle

Corridors follow a typestate-encoded lifecycle: Draft -> PendingEndpointRatification -> PendingRouteNotice -> RatifiedPendingWindow -> Active, with Halted, Suspended, Revoked, SupersededDraining, Retired, and DisputedOverlay branches. A corridor in Draft cannot process operations. Endpoint ratification binds the sovereign authorities on both sides; route notice publishes the direct and staged routes whose coherence may be affected; the pending window gives counterparties time to halt before activation. A corridor in Halted state rejects all new operations while allowing in-flight operations to complete or time out. Suspended freezes all activity including in-flight operations. SupersededDraining keeps old receipts replayable while a new epoch accepts new operations. DisputedOverlay records an arbitration or watcher challenge without erasing the underlying state.

The governance state carried by the corridor is (corridor_id, direction, epoch, pack_digest, state, trust_level, validity_window, endpoint_authorities, standing_set, watcher_set, dispute_forum, bond_custodian, route_impact_set, proof_status, gov_log_head, sanctions_authority_scope). The signed events are Propose, EndpointRatify, RouteNotice, Activate, Tighten, Loosen, Halt, Suspend, Resume, Supersede, Drain, Retire, Dispute, Blame, Slash, SchemaEvolve, and SharedSanctionsAuthorityBind. Watchers attest and surface blame; they do not amend corridor law. Slashing requires an accepted blame certificate plus bond-custodian authority. Tightening recognition is prospective and destination-sovereign; loosening recognition requires endpoint ratification, route-impact notice, and proof-status checks. Binding a shared sanctions authority is a loosening event and therefore requires endpoint ratification plus validity-window and revocation checks. These rules are a state-machine specification, not a completed theorem: the open obligations are governance authorization soundness, audit reconstruction, sovereignty preservation, sanctions-recognition safety, route-coherence publication, effective-window safety, emergency-transition safety, watcher/slashing soundness, schema-evolution coverage, and proof-status honesty.

5.10 Jurisdiction Lifecycle Map

Jurisdictional change is part of the corridor model rather than an external administrative afterthought. Let 𝒥 be the directed graph whose nodes are jurisdictions at a legal epoch and whose edges are legally effective lifecycle events: creation, termination, merger, split, and scope amendment. Let 𝒦 be the transition system of kernel states and active corridor sets. The deployment relation assigns each jurisdictional event an explicit kernel-transition package:

L : 𝒥 → 𝒦.

Creation adds a new node with an accession act and an initial corridor set. Termination maps a jurisdiction to a tombstone state that preserves passport-verification history but accepts no new writes. Merger events induce endpoint-rewrite obligations on the corridor graph: predecessor corridors do not survive by implication, only by explicit continuation witnesses.

The continuation witness for an entity crossing the legal cut carries a dual-fiber pair (f⁻, f⁺): one fiber attesting the predecessor jurisdiction’s pre-cut compliance state and one attesting the successor jurisdiction’s continuation rule. Corridor continuation is sound only when the predecessor passport, successor passport, predecessor corridor, and successor corridor agree under the declared endpoint rewrite and evidence witnesses. A categorical formulation may be possible under stronger hypotheses; this paper only needs the typed lifecycle transition and its route-coherence check. The architecture therefore treats jurisdiction creation, termination, and merger as typed protocol events rather than as off-ledger exceptions.

6.1 The Composition Problem

A multi-harbor entity operates in jurisdictions J_1, J_2, …, J_k simultaneously. It has a compliance tensor in each jurisdiction: T_1, T_2, …, T_k. The entity must satisfy all jurisdictions simultaneously. What is its effective compliance constraint?

6.2 Pointwise Meet

The answer is the pointwise meet across all tensors:

T_effective = T_1 ^ T_2 ^ ... ^ T_k

where ∧ is the meet operation on the compliance-state lattice, applied independently to each domain. For each domain d:

T_effective(d) = meet(T_1(d), T_2(d), ..., T_k(d))

This produces the most restrictive state across all harbors. If any jurisdiction says the entity is NonCompliant on AML, the effective AML state is NonCompliant, regardless of what the other jurisdictions say. If one jurisdiction says Pending and another says Compliant, the effective state is Pending.

On the Applicable fragment, composition is computed by taking an iterator over (zone, tensor-slice) pairs and applying the pointwise meet, while tracking the source attribution per domain, recording which zone contributed each domain’s most restrictive state. On the full mixed-axis type, composition is the structured MeetResult reduction described above; it is not an arbitrary binary fold over a total lattice. The source attribution is required for the remediation operator (Section 6.3) to identify which harbor is the binding constraint for each domain.

6.3 Scoped Residual and Remediation

Two planning operators must be kept distinct.

First, on a fixed applicable fragment A ⊆ 𝒟, the pointwise residual

T_current⇒_AT_target

is the Heyting implication characterized by the adjunction

X ∧ T_current ≤ T_target  iff  X ≤ (T_current⇒_AT_target)

on every domain in A. This is a composition-theoretic operator. It is not a mechanism for improving the current tensor, because meet is restrictive.

Second, the operational planning primitive is the remediation operator

$$\mathrm{Rem}(T_{\text{current}}, T_{\text{target}}, \Gamma)(d) = \begin{cases} \varnothing & \text{if } T_{\text{current}}(d) \text{ already satisfies the target under context } \Gamma, \\ \{\text{fresh attestation / proof refresh / discretion fill for } d\} & \text{otherwise,} \end{cases}$$

where Γ contains validity windows, source attribution, propagation edges, and corridor re-evaluation masks. This operator answers the planning question directly: which domains must change state, by which authorized process, and at which harbor.

The source attribution from the composition tells the entity which harbor is the binding constraint for each domain. If the entity is NonCompliant on Securities because of jurisdiction J₂’s requirements, Rem(T_current, T_target) identifies J₂ as the harbor where Securities compliance must be addressed. This is the operator consumed by the delegated planning layer.

6.4 Conjunctive Consistency and Composition Obstructions

Zone composition requires that a composed (synthetic) zone’s compliance constraints be at least as restrictive as the natural jurisdictions it draws from. The property is necessary: a synthetic zone that lifted constraints from its component jurisdictions would be a back-door for regulatory arbitrage, the composition would be a way to reduce the surface rather than a way to live within it.

A composition obstruction is any domain on which the synthetic zone’s tensor would be less restrictive than a natural source jurisdiction’s tensor. The check walks the pair (synthetic zone, source jurisdiction) across every domain and reports every obstruction. An obstruction means the zone composition is invalid as specified: either the synthetic zone must tighten its tensor on the offending domain (adopting the source’s more restrictive state), or the source’s constraint must be demonstrably inapplicable (for example, the source jurisdiction does not govern the relevant activity in the synthetic zone’s scope). A synthetic zone that cannot be constructed without composition obstructions is not a permissible composition; the architecture refuses to assemble it rather than silently producing a degraded constraint surface.

The check is a conjunctive consistency check: a pessimistic lattice comparison detecting pointwise disagreement between the synthetic zone’s tensor and each source jurisdiction’s tensor. It is descent-style constraint propagation, not full Grothendieck descent. On the pure Applicable-fragment tensor, meet associativity means there is no independent triple-overlap obstruction. Route-coherence obligations live at the corridor-map and instrument-clause stratum (Section 5.3.1), where the direct corridor and the staged corridor may disagree even though each tensor composition step is a pairwise meet.

6.5 Worked Example

Consider an entity harbored in three jurisdictions, denoted J₁, J₂, J₃, and conducting a cross-border trade between J₁ and J₃. The entity must satisfy all three jurisdictions simultaneously.

Step 1: Per-harbor tensors. Each kernel evaluates the entity against its jurisdiction’s rules. Each coordinate is a pair (compliance grade, applicability):

T_1 (J_1):
  AML:         (Compliant, Applicable)     KYC:        (Compliant, Applicable)
  Sanctions:   (Compliant, Applicable)     Tax:        (Compliant, Applicable)
  Securities:  (Pending, Applicable)       Corporate:  (Compliant, Applicable)
  DataPrivacy: (Compliant, Applicable)     Banking:    (_, NotApplicable)
  Trade:       (Compliant, Applicable)

T_2 (J_2):
  AML:         (Compliant, Applicable)     KYC:        (Compliant, Applicable)
  Sanctions:   (Compliant, Applicable)     Tax:        (Compliant, Applicable)
  Securities:  (Compliant, Applicable)     Corporate:  (Compliant, Applicable)
  DataPrivacy: (Pending, Applicable)       Banking:    (Compliant, Applicable)
  Trade:       (_, NotApplicable)

T_3 (J_3):
  AML:         (Compliant, Applicable)     KYC:        (Compliant, Applicable)
  Sanctions:   (Compliant, Applicable)     Tax:        (_, Exempt)
  Securities:  (_, NotApplicable)          Corporate:  (Compliant, Applicable)
  DataPrivacy: (Compliant, Applicable)     Banking:    (_, NotApplicable)
  Trade:       (Pending, Applicable)

Applicability markers NotApplicable and Exempt carry the grade slot as “_” to make explicit that no substantive grade is reported on those coordinates.

Step 2: Applicable-fragment meet. On the coordinates where every harbor reports Applicable, composition is the three-chain pointwise meet:

Applicable-fragment meet on (AML, KYC, Sanctions, Corporate):
  AML:       Compliant
  KYC:       Compliant
  Sanctions: Compliant (each jurisdiction also evaluates independently per Section 5.5)
  Corporate: Compliant

On domains where at least one harbor is Applicable but at least one harbor is
not Applicable, the meet is MeetResult-valued; see Step 3.

Step 3: Mixed-axis outcomes via MeetResult. Where harbors disagree on applicability, the production meet is MeetResult-valued and preserves the provenance rather than collapsing into a single verdict:

• Tax. T₁ and T₂ report (Compliant, Applicable); T₃ reports (_, Exempt). Under the mixed-axis dichotomy, this is a mixed-axis coordinate: two Applicable verdicts plus one Exempt marker with signed-policy provenance. The production meet records the Applicable-fragment meet restricted to {J₁, J₂} (yielding Compliant) together with the mixed-axis flag that J₃ has exempted the entity from the Tax domain under a signed policy artifact. The operator does not output a synthetic Exempt or Compliant grade on the composed coordinate; it hands the applicability provenance to the rule layer.
• Securities. T₁ reports (Pending, Applicable); T₂ reports (Compliant, Applicable); T₃ reports (_, NotApplicable). Applicable-fragment meet on {J₁, J₂} is Pending, with binding harbor J₁. J₃’s NotApplicable is preserved as applicability provenance.
• DataPrivacy. All three harbors Applicable. Three-chain meet is Pending, with binding harbor J₂.
• Banking. T₁ reports NotApplicable; T₂ reports (Compliant, Applicable); T₃ reports NotApplicable. Applicable-fragment meet restricted to {J₂} yields Compliant with NotApplicable applicability provenance from {J₁, J₃}.
• Trade. T₁ reports (Compliant, Applicable); T₂ reports NotApplicable; T₃ reports (Pending, Applicable). Applicable-fragment meet on {J₁, J₃} is Pending, with binding harbor J₃ and NotApplicable applicability provenance from J₂.

Step 4: Applicability reduction for planning. A delegated planner reduces the mixed-axis outcome to a planning projection on a fixed applicability slice. For each domain, the planner fixes the applicability slice it is planning against, the set of harbors where the domain is Applicable for this planning cycle, and applies the pointwise residual and remediation operator on that slice. Coordinates with Exempt or NotApplicable markers are recorded in the plan as applicability conditions (for example, “J₃ Tax exemption must remain in force” as a standing assumption), not folded into the grade.

Step 5: Source attribution and remediation. The composition records the binding harbor per domain on the relevant applicability slice: - Securities: bound by J₁ on the Applicable slice {J₁, J₂}. - DataPrivacy: bound by J₂ on the Applicable slice {J₁, J₂, J₃}. - Trade: bound by J₃ on the Applicable slice {J₁, J₃}.

If the target is Compliant on every Applicable slice, the remediation operator identifies: - Securities: must achieve Compliant in J₁ (complete the pending securities registration). - DataPrivacy: must achieve Compliant in J₂ (complete the outstanding data-protection impact assessment). - Trade: must achieve Compliant in J₃ (complete the pending customs documentation).

A delegated planner managing this entity receives the remediation plan as a structured object plus the applicability provenance. The plan names the three actions, the relevant jurisdictions, and the applicability conditions (for example, the J₃ Tax exemption) that must be preserved for the plan to remain valid. Execution proceeds through the kernel write path in the respective harbors. After each action, the affected kernel re-evaluates its tensor, corridor intelligence propagates the change, and the composed tensor is recomputed.

Step 6: Corridor crossings. The cross-border trade between J₁ and J₃ requires a corridor crossing. The corridor has parameters R = {Sanctions, Trade, AML}, μ = identity, and grade maps that accept the shared taxonomy where legally recognized. J₁’s passport for the entity crosses the corridor. J₃ re-evaluates Sanctions (mandatory), Trade, and AML locally; accepts the remaining domains via mutual recognition only where the grade maps are defined. The BSC protocol coordinates the settlement.

6.6 Navigable Compliance Surfaces

The compliance tensor, remediation operator, and source attribution together define a constraint surface that delegated planners can navigate. Given an entity’s multi-harbor compliance state, a planner can:

1. Compute the effective constraint surface via pointwise meet.
2. Identify binding constraints per domain per harbor via source attribution.
3. Compute the improvement prescription via the remediation operator.
4. Prioritize remediation actions by domain severity and harbor importance.

The planning layer consists of a policy engine, an action scheduler, and a deficiency planner, supported by an intelligence layer that consumes the compliance observation corpus. Every compliance evaluation feeds the system’s understanding of jurisdictional requirements and can produce pack-update candidates with evidence and confidence estimates. Section 7 describes the operational loop.

7.1 Caller Authentication and Identity

A delegated program authenticates to the kernel through the same mechanism as any other caller: a credential that the kernel verifies, from which it extracts a uniform caller identity bearing a role, an entity scope, and delegated-program attribution. When the attribution field is set, every mutation journaled through the mutation firewall is tagged accordingly in the audit trail. This is not a different write path. It is the same write path with provenance. Sanctions fail-closed evaluation applies identically. The tensor evaluation applies identically. The proof bundle is produced identically. A delegated program has no more and no less authority than a human caller with the same role and scope. The distinction exists for audit attribution: regulators can query the event store for delegated-program mutations and review them separately.

7.2 The Operation Loop

A delegated planner managing an entity’s compliance operates in a closed loop:

Observe. The planner reads the entity’s current compliance tensor across all harbors where the entity operates. For a multi-harbor entity, this means reading T(E, J₁), T(E, J₂), …, T(E, J_k), one tensor per harbor. The planner also reads the entity’s compliance passport (the full hash-chained history) and any pending operations.

Compose. The planner computes the effective tensor via pointwise meet: T_eff = T₁ ∧ T₂ ∧ ⋯ ∧ T_k. This is a pure algebraic computation, with no external call and no side effect. The planner now has the most restrictive constraint surface the entity faces across all jurisdictions.

Compute remediation. Given T_eff and a target tensor T_target (typically all-Compliant, or a specific compliance posture the entity wishes to achieve), the planner computes the remediation operator. The resulting plan identifies, for each domain, whether improvement is needed and which harbor is the binding constraint via source attribution.

Select action. A deficiency planner converts the remediation plan into a prioritized sequence of typed remediation actions: submit a KYC document in harbor J₂, complete a securities registration in harbor J₁, file a tax return in harbor J₃. The selection is deterministic given the plan and the entity’s state.

Execute. The planner submits each action through the kernel write path by supplying an operation envelope or a front-end request that compiles into one. The admitted operation is then subject to the same write-path discipline (sanctions fail-closed evaluation, pre-flight tensor evaluation, business-logic delegation, evidence storage, post-flight re-evaluation, verifiable-credential issuance, passport update, mutation journaling where the deployment has those stages wired) as any other caller. The planner has no backdoor. It uses the same admission boundary a human operator would use.

Observe again. After execution, the planner reads the updated tensor. The domain that was NonCompliant or Pending may now be Compliant. The effective tensor has changed. The remediation plan has changed. The loop repeats.

This loop is the fundamental unit of delegated automated compliance management. It is not a summary function. It is a typed proposal-and-admission loop through the kernel’s write path, followed by observation of the composed result.

7.3 Multi-Harbor Interaction Effects

When a delegated planner proposes an action in harbor J₁ and the kernel admits it, the effects can propagate to other harbors through two mechanisms:

Direct tensor change. The action in J₁ changes T(E, J₁). Since T_eff is the pointwise meet of all harbor tensors, the effective tensor changes. If J₁ was the binding constraint for some domain d (i.e., T(E, J₁)(d) was the most restrictive value), and the action improved that domain, then T_eff(d) improves, potentially changing the entity’s effective compliance state in every harbor.

Corridor intelligence propagation. The kernel in J₁ emits a compliance observation into its observation corpus. Anonymized zone-level intelligence digests are exchanged bilaterally with corridor partners. If J₂ has a corridor with J₁, J₂’s intelligence layer receives the updated observations. This can trigger re-evaluation of related fibers in J₂ because the observation is informative for J₂’s own evaluators; J₁’s evaluation does not bind J₂.

The corridor intelligence exchange is signed, replay-protected (monotonic sequence numbers per corridor), recipient-bound (preventing unintended forwarding), and supports multi-hop propagation with privacy-preserving aggregation (zone-level granularity, never entity-level). The sovereignty of each zone is preserved: intelligence digests are informative, not authoritative.

7.4 Scaling: N Planners, M Entities, K Harbors

Consider the computational complexity when N delegated planners manage M entities across K harbors, with domain set of fixed size D.

Tensor composition. For each entity, composing K harbor tensors is O(K ⋅ D). With M entities, total composition cost is O(M ⋅ K ⋅ D). This is a pure algebraic computation with no external I/O.

Remediation computation. Computing the remediation operator for one entity is O(D). For M entities: O(M ⋅ D).

Action execution. Each admitted action is one write through the kernel’s pipeline. The bottleneck is external I/O: sanctions screening (network call to sanctions lists), business-logic delegation, and storage-layer write. The kernel uses a set of background daemons with leader election and hash-based jitter to distribute work.

Cross-harbor propagation. An action in harbor J₁ triggers re-evaluation in at most K − 1 other harbors (one per corridor partner). Each re-evaluation is O(D) (tensor recomputation) plus the cost of any fiber re-evaluations triggered by the new evidence. The total propagation cost per action is O(K ⋅ F), where F is the average number of fibers re-evaluated per harbor per incoming intelligence digest.

Per-cycle cost. One operation-loop cycle for one entity across K harbors: O(K ⋅ D) for composition + O(D) for remediation + O(1) for action execution (apart from I/O) + O(K ⋅ F) for propagation. The dominant cost is fiber re-evaluation.

Concurrency. N planners operating simultaneously on different entities are embarrassingly parallel; they share no mutable state because each entity’s tensor is independent. N planners operating on the same entity are serialized by the kernel’s mutation firewall (optimistic concurrency on the storage layer, with conflict detection through hash-chain verification). The Lamport-clock ordering of events within the append-only event store ensures a total order on mutations per entity, regardless of how many planners attempt concurrent writes.

7.5 Simultaneous Planners at Scale

When many delegated planners operate simultaneously across the network, several structural properties arise:

Independent observation. Each planner observes its own entity’s tensor independently. Two planners managing two distinct entities in two distinct harbors do not interfere. They share no state except the corridor intelligence digests, which are read-only summaries with no coordination requirements.

Convergent remediation. Multiple planners working on entities in the same harbor independently discover the same binding constraints because Lex rules and fiber evaluations are deterministic. Their remediation actions follow similar patterns, generating a corpus of compliance observations that improves the intelligence layer for later evaluations. The compounding effect is indirect: admitted actions produce evidence that makes future evaluations more efficient.

No coordination protocol. Planners do not coordinate with each other. There is no planner-to-planner communication protocol, no shared planning state, no consensus mechanism. Each planner operates in its own loop, observing tensors and submitting actions through the kernel write path. The kernel provides the coordination through the mutation firewall (serializing writes to each entity), the compliance tensor (providing a consistent view), and the corridor protocol (propagating effects across harbors).

Graceful degradation. If a planner fails, its entity’s compliance state is unchanged: no in-progress mutation can be left half-applied because the mutation-firewall gate is atomic. Another authorized planner can continue from the current tensor state. The compliance passport provides the full history; the tensor provides the current state; the remediation plan provides the prescription. No planner-specific state needs recovery.

8.1 The Network Graph

Many kernels worldwide form a graph G = (V, E), where V is the set of zones (each running its own kernel) and E is the set of established corridors. The graph is:

• Not fully connected. Not every pair of zones has a corridor. Corridor establishment is a bilateral decision between two zone operators, involving negotiation of (R, μ, γ) parameters that encode a mutual recognition agreement.
• Disconnected components admitted. The graph may contain isolated zones with no corridors, or disconnected components.
• Directed. Corridors are asymmetric, each direction has its own (R, μ, γ). The graph is more precisely a directed graph where each undirected corridor edge represents two directed edges.
• Weighted. Corridors carry metadata: trust level, operational limits, compliance domain coverage, fee structure, and friction profile. Routing algorithms choose paths using weights derived from those quantities.

8.2 Scaling Properties

Adding a new zone: O(k) in protocol wiring, where k is the number of corridor partners the new zone wishes to establish. The kernel construction is common across zones; jurisdictional specificity enters through rule packs and operation schemas rather than through a new kernel design.

The binding constraint on network growth is not software. Each corridor requires bilateral negotiation of (R, μ, γ) between two sovereign regulators or their designated operators. As illustrative corridor-formation priors, not measured claims of this architecture, one may expect elapsed times and legal costs closer to bilateral regulatory instruments than to software deployments. The numbers in any deployment must be estimated from the actual treaty, MRA, tax-agreement, and supervisory-cooperation comparables for the participating jurisdictions. Activation is therefore a regulatory process with non-zero probability of failure, not a technical deployment problem.

Adding a new compliance domain: Adding a new top-level domain to the taxonomy requires every evaluator, every route, and every corridor parameter to address it. The cost of a new top-level domain is proportional to the number of places that case-split on domains, not to the number of zones or corridors. The schema-evolution protocol prescribed by the architecture is to add the new domain, extend every evaluator, renegotiate every corridor’s (R, μ, γ) to reflect the new domain’s treatment, and issue a new pack version carrying the extended taxonomy. Corridors operating under the old pack continue to function with the old taxonomy until their validity window forces renegotiation.

Adding a new harbor for an entity: One corridor crossing. The entity’s compliance passport travels to the new harbor, the corridor’s (R, μ, γ) parameters determine what is re-evaluated locally and how foreign evidence is consumed, and the entity begins accumulating compliance history in the new jurisdiction. The marginal cost of a new harbor is one corridor crossing, not a greenfield compliance engagement.

8.3 What Compounds Across Zones

The observation corpus. Every compliance evaluation, in every zone, contributes to a growing body of structured compliance observations. The corpus records operation type, jurisdiction, domain outcomes, evidence types, and evaluation duration. This corpus compounds because each zone’s evaluations are contextually informative for other zones operating under similar regulatory frameworks. A sanctions screening result in one jurisdiction informs the risk model for entities that also operate in another. A corporate-governance evaluation in one common-law free zone informs the template for similar evaluations in a peer common-law free zone.

Compliance passports. As entities accumulate compliance history across multiple zones, their passports become increasingly valuable, a well-attested entity with a long passport history is cheaper to evaluate than a new entity. The passport portability creates a genuine network effect: the more zones an entity has been evaluated in, the more evidence a new zone can draw from.

Operation definitions. The operation engine is driven by a declarative catalog of operation families keyed by jurisdiction. Each family lowers into the operation-envelope path before execution. Each new jurisdiction definition benefits from the pattern established by existing definitions. The declarative operation model means jurisdictional coverage is a data problem, not a code problem.

Corridor intelligence. Corridor partners exchange anonymized zone-level intelligence digests, aggregated compliance observations that inform partner zones without exposing individual entity data. This exchange is signed, replay-protected, recipient-bound, and supports multi-hop propagation with privacy-preserving aggregation (zone-level granularity, never entity-level).

8.4 What Does Not Compound

Sovereignty. Each kernel is sovereign. Zone A’s compliance evaluation does not constrain zone B’s evaluation. The network does not produce a “consensus compliance state”, each zone evaluates independently. This is a feature, not a limitation: regulatory sovereignty is the property being preserved, not an obstacle being overcome.

Trust. Trust does not compound transitively. A corridor between A and B, and a corridor between B and C, does not create implicit trust between A and C. Every hop re-evaluates. This is by design (Section 5.7).

Regulatory authority. The network does not aggregate regulatory authority. A zone’s regulator has authority over that zone’s kernel and no other. The network provides information flow: compliance passports and corridor intelligence. Authority flow remains sovereign-local.

8.5 Hub-and-Spoke Topology and Network Value

The corridor topology is not uniformly distributed. In any sparse bilateral network with heterogeneous negotiation capacity, some zones become hubs and others remain spokes. The corridor network is to jurisdictional compliance what BGP is to internet routing: a protocol for bilateral agreements between sovereign entities that produces a directed reachability graph without central coordination. Connected components emerge from adoption and negotiation capacity; they are not guaranteed by the protocol alone.

Network value therefore concentrates at hubs, but it does so under a sparse-growth law rather than a complete-graph law. A spoke that acquires a corridor to a hub gains access to the hub’s reachable corridor neighborhood without forming every bilateral edge itself. A hub that adds another spoke gains reachability value on the subset of paths made feasible by active corridors. If corridor formation remains negotiation-bounded, realized degree growth is sparse. Under sparse growth rules with average degree scaling like O(log n), the aggregate reachable-neighborhood value sits in the Odlyzko-Tilly (2005) O(nlog n) regime. Metcalfe n² would require dense realized edges absent from this model. This is a conditional economic model, not a theorem about every deployment.

Two properties of the architecture bound the implications of this concentration:

1. No transitive trust. A hub zone cannot “relay” compliance evaluations between spoke zones. Each corridor is bilateral. Hub status gives a zone more connections, not more authority.

2. Passport portability. An entity’s compliance passport is not tied to the hub zone. If a hub zone becomes unreliable or raises fees, entities can route through alternative paths (assuming corridors exist). The compliance history travels with the entity, not with the hub.

The concentration regime is not winner-take-all lock-in. Jurisdictional governance is differentiated and substitutable across regulatory cohorts; a superior later entrant can outcompete an inferior earlier hub because hubs provide connectivity, not custody of compliance state. The entity holds the compliance passport. The hub supplies reachability only.

9.1 Zone Failure

A zone goes offline. All operations within that zone halt. Operations in other zones are unaffected. Cross-zone operations involving the failed zone enter a timeout state and eventually abort per the BSC timeout protocol.

This is sovereign governance, not a technical failure. If a jurisdiction’s infrastructure goes down, operations in that jurisdiction stop, just as they would if a country’s banking system went offline. The network does not attempt to “work around” a failed zone by continuing operations on its behalf. That would violate the sovereignty property.

The BSC design target handles in-flight cross-zone operations through typed terminal evidence: if a zone fails to respond before finality, the operation remains bounded-blocking until the timeout rule produces an accepted abort certificate or the missing evidence arrives. Lock records are intended to ensure that resources are released on accepted abort. The recovery FSM is itself a proof obligation: a zone coming back online must resume from its last receipt-chain state and either terminate in agreement or return a typed obstruction.

9.1.1 Cross-Kernel State Reconciliation Under Partition

A partition of the corridor network, in which two kernels K_A and K_B cannot communicate for an interval [t₀, t₁] while both continue to accept local operations, raises a distinct question from single-kernel crash recovery. During the partition, each kernel writes to its own append-only event store. Neither store is corrupted; each is the correct record of what its own jurisdiction’s kernel observed and authorised. The reconciliation question is what happens to the corridor between them.

The architecture’s answer is structural: there is no cross-kernel shared state to reconcile. Each kernel is sovereign over its own event store, its own compliance passports for entities harboured in its jurisdiction, and its own fiber evaluations under its own packs. A partition does not produce divergent copies of the same state; it produces independent progress on independent states. What does require reconciliation is the set of in-flight corridor operations whose BSC protocol was interrupted at t₀.

Ledger obligation O-2c/O-3 (partition-heal invariant preservation). Let ω be a corridor operation in state s_X(ω) ∈ {Init, Locked, Verified, Committed, Aborted} at side X ∈ {A, B} at the moment a partition opens. After the partition heals, under the fail-stop or bounded-Byzantine adversary as specified, the recovery procedure must satisfy the following case analysis on s_A(ω) × s_B(ω):

• Init at either side. No lock was taken; no resources are reserved. The partition has no effect on ω. The initiator eventually times out and retries or abandons. Both sides agree trivially.
• Locked at X, any state at X̄. One side holds a lock; the other may or may not have received the lock notification. The lock carries a bounded validity window Δ_L. At expiry, the locking side releases unilaterally unless a valid finality certificate has already formed. On heal, the side that lost connectivity reconciles via the event-store exchange; its local lock, if held, times out on Δ_L. This is a bounded-block regime, not classical non-blocking recovery.
• Verified at both sides with a shared finality certificate. Both sides hold the certificate required by ledger obligation O-2a. On heal, both sides deterministically compute the same terminal from the same durable certificate, with no further coordination.
• Verified at X, Locked at X̄. This is not automatically safe. If X̄ can still receive the missing verdicts and form the same finality certificate before its lock expires, the operation advances to the shared-finality case. If X̄’s lock window expired during partition, the result is a terminal-disagreement obstruction unless the trace also contains an equivocation certificate. The protocol must surface this obstruction; it must not infer Byzantine blame from the crossed state alone.
• Committed or Aborted at either side. Terminal states are compared by their signed terminal artefacts. Agreement is accepted only when both terminals are supported by the same finality certificate or by compatible timeout evidence. Otherwise the heal procedure returns a typed terminal-disagreement obstruction.

Proof target. Each case must be discharged against the BSC transition relation, the lock-expiry rule, the finality-certificate definition, and the accepted terminal-evidence verifier. The crossed-state case is the reason the certificate is load-bearing.

The reconciliation procedure on partition heal is therefore a metadata exchange, not a state merge: each side publishes the head of its corridor-operation receipt chain, the other verifies the receipt chain’s integrity against the hash-chain invariants, and each side advances its view of the partner’s terminal state for partition-time operations. No cross-kernel write conflict is merged because no cross-kernel writes are attempted. Accepted recoveries must terminate in agreement; rejected recoveries must return a typed obstruction naming the missing finality, timeout, or equivocation evidence.

The one class of operation that is not auto-reconcilable is Byzantine equivocation: a malicious zone operator who, during the partition, issues conflicting signed verdicts to two partition halves. The bounded-Byzantine defence (Section 5.3.2) applies only under explicit observer assumptions: the conflicting signed artifacts must be published or otherwise imported into both sides’ evidence surface; the watcher threshold must not be captured; and any slashing mechanism requires a bond custodian and an accepted verifier. The partition temporally separates evidence gathering from attribution; non-repudiable signatures make attribution possible once the evidence is visible.

In sum, “no global consensus” in the partition setting is the architectural fact that the system has no cross-kernel shared ledger to coordinate over. It has bilateral receipt chains whose content-addressed structure makes independent reconciliation sufficient for ordinary corridor operations. The BSC proof obligation is to formalise partition healing precisely enough that any accepted partition-healing sequence terminates in agreement, and every rejected sequence returns a typed obstruction with the evidence needed for governance.

9.2 Split-Brain Recovery After Kernel Restart

When a kernel restarts after a crash, it must recover to a consistent state. The append-only event store is the recovery mechanism: the kernel replays the event log from the last known-good state. Because the event log is append-only (no UPDATE, no DELETE), the event store is its own write-ahead log. The recovery procedure:

1. Read the last committed event for each entity (the hash-chain head).
2. Verify hash-chain integrity from the head backward to the last checkpoint.
3. Resume the background daemons, each acquiring leader-election locks before processing. Leader election prevents split-brain: if a previous instance is still holding locks (stale connection), the new instance blocks until the lock timeout before acquiring leadership.
4. In-flight BSC operations are recovered via the BSC state machine’s recovery FSM. Operations in the Locked state that timed out during the crash are aborted. Operations in the Verified state require the finality certificate specified by the BSC proof obligations. Operations in ambiguous states are resolved by the timeout protocol or returned as typed terminal-disagreement obstructions. Full public proof-assistant mechanization of this FSM is a release gate, not a claim made here.

The critical invariant: no mutation is lost (append-only guarantees), and no mutation is applied twice (content-addressed event IDs with hash-chain linking make duplicates detectable).

9.3 Cascade Failure When Hub Zone Goes Down

When a hub zone (one with many corridor connections) goes offline, the cascade effects are bounded:

Direct impact: All corridors involving the hub zone enter a degraded state. In-flight BSC operations involving the hub zone time out and abort. Entities whose only path to certain jurisdictions runs through the hub lose multi-harbor connectivity to those jurisdictions.

Bounded blast radius: Operations entirely within non-hub zones are unaffected. Corridors between non-hub zones are unaffected. The hub zone’s failure does not propagate, it creates a connectivity gap, not a data corruption event.

No authority loss: Entities previously evaluated by the hub zone retain their compliance passports. The passports are self-contained (hash-chained, signed) and do not require the issuing zone to be online for verification. A receiving zone can verify a passport from a crashed hub zone using the hub’s public key (which is cached in the receiving zone’s key registry).

Recovery: When the hub zone comes back online, its corridors re-activate through the graduated trust mechanism. Corridors that were already active return to their prior trust tier because the bilateral relationship and settlement history are preserved in both zones’ databases.

This is an availability attack on the hub zone’s connectivity, not a safety violation. No compliance evaluations are falsified. No passports are corrupted. Operations are blocked, not corrupted.

9.4 The Watcher Layer

Corridor receipt chains are observed by an external watcher layer. A watcher is an independent party that subscribes to one or more corridors and produces signed attestations over receipt chain heads. The role is separated from the kernel deliberately: watchers do not write compliance state; they observe and attest.

Watcher protocol. A corridor C = (Z_A, Z_B, τ, R, μ, γ) admits a finite set W(C) of watchers, each with a registered signing key. A watcher w ∈ W(C) produces attestations of the form α_w = sign_kw(corridor-id, h_head, t, epoch), where h_head is the content-addressed digest of the corridor’s receipt chain head as observed by w, t is the watcher’s local timestamp, and epoch is the corridor epoch. Each watcher posts a bond at registration time, slashable on proven equivocation under the verifier specified in ledger obligation O-3.

Detection threshold. A fork is declared when the union of watchers’ attestations over a single (corridor, epoch) pair contains two distinct digests h₁ ≠ h₂ each backed by at least θ attestations from distinct watchers, where θ is a corridor parameter bounded below by ⌈|W(C)|/3⌉ + 1 to defend against minority collusion. When two disjoint θ-witnessed views exist, the bilateral evidence suffices to invoke the slashing mechanism on the equivocating zone if it satisfies the verifier specified in ledger obligation O-3.

Three-level ordering for tiebreak. When attestations agree on the digest but disagree on sequence, fork detection uses three-level ordering: timestamp (primary, with a 5-minute maximum clock skew tolerance); watcher-attestation count (secondary); lexicographic digest (tertiary, deterministic tiebreak). This is an ordering tiebreaker rule rather than a fork resolution rule.

Watcher collusion. If a strict majority of watchers in W(C) collude with a malicious zone operator, fork detection at threshold θ fails. The mitigation is structural diversity: watchers are operated by independent parties with misaligned incentives, such as the zone’s regulator, the corridor partner, and independent auditors. The bonding mechanism creates an economic disincentive proportional to the bond size, but it does not prevent collusion in adversarial models stronger than EUF-CMA. This residual risk is a fundamental limitation of observer-based detection schemes and is named here rather than absorbed into the protocol’s safety claim.

9.5 Corridor Denial-of-Service

An attacker who can flood a corridor’s communication channel can block all cross-zone operations without compromising safety. The corridor’s BSC operations time out and abort. No false compliance evaluations are created. No passports are corrupted. The attack is on availability, not integrity.

Properties preserved under DoS: Sanctions fail-closed evaluation remains enforced (each zone evaluates independently). Hash-chain integrity remains intact (no events are lost or modified). Compliance passports remain valid and verifiable. Local operations within each zone continue unaffected.

Properties degraded under DoS: Cross-zone operations are blocked. Corridor intelligence digest exchange is interrupted. Entities cannot cross corridors or establish new multi-harbor positions.

Mitigation: Rate limiting on corridor endpoints, conservative limits on newly activated corridors, and corridor suspension that preserves in-flight operations while blocking new ones.

9.6 Malicious Zone Operator

A zone operator who controls the kernel could issue false compliance evaluations, marking a sanctioned entity as Compliant, for example. The architecture provides graduated defenses:

Graduated trust. New corridors start at the lowest trust tier with conservative limits. A malicious zone cannot immediately route high-value operations.

Passport verification. The receiving zone cryptographically verifies the passport’s integrity but applies its own (R, μ, γ) to determine what to accept. With a sufficiently large R (re-evaluating many domains locally), the receiving zone is largely immune to false evaluations.

Sanctions local re-evaluation. In general-purpose corridors, sanctions are re-evaluated locally (Section 5.5). A malicious zone cannot route sanctioned entities through such corridors merely by falsifying its own sanctions status; shared-authority subnetworks require their own explicit premises.

ZK lock proofs. For high-value corridor operations, the lock phase may be accompanied by a knowledge-sound zero-knowledge proof binding the initiating zone’s resource commitment, nonce, epoch, corridor identifier, and zone identifier. The paper uses only the abstract property that two incompatible proofs over the same (zone-id, nonce, epoch) can be turned into accountable evidence of equivocation. It does not require a commitment to a particular proving system.

Non-equivocation property. Nonce uniqueness per (zone-did, ϵ) is enforced at the credential layer: the credential-provisioning system issues each zone a fresh nonce space per epoch and refuses to countersign a lock proof whose nonce has already been consumed. Under this discipline, a zone that issues two lock proofs (π₁, π₂) sharing (z, n, ϵ) but carrying different resource digests r₁ ≠ r₂ has signed incompatible commitments under its own key.

Open proposition schema (equivocation extraction). Assume a specified lock-proof relation with public inputs (z, n, ϵ, ω, r), knowledge soundness for that relation, EUF-CMA signatures, nonce-credential uniqueness, and an accepted blame verifier. The intended theorem is: given two verifying lock proofs π₁, π₂ sharing (z, n, ϵ, ω) but carrying incompatible resource commitments, the verifier either extracts conflicting signed artifacts under the key bound to z or returns a typed malformed-witness obstruction. This remains open until the circuit relation, witness format, nonce credential discipline, and blame-verifier rules are fixed and proved.

Trust revocation. A corridor can be demoted or suspended. Three consecutive failures trigger automatic demotion. A zone operator or regulator can manually suspend a corridor, halting all cross-zone operations while allowing in-flight operations to complete.

9.7 Corridor Compromise

If a corridor’s communication channel is compromised (man-in-the-middle), the attacker could intercept or modify compliance state in transit.

Hybrid signatures. Corridor and bridge communications use conjunctive verification under Ed25519 and ML-DSA-65. The verification succeeds only if both components verify, so an adversary must break both the classical and post-quantum components to forge the envelope. This is the signature surface assumed by BRIDGE_PROTOCOL_VERSION = 1 in Section 2.5.

Key rotation with dual-key window. Zone keys rotate through a key-rotation interface. During rotation, both the old and new keys are valid for a specified window, ensuring that in-flight corridor operations signed with the old key remain verifiable. The zone maintains a registry of all currently-valid verifying keys, indexed by key identifier and validity interval.

Content addressing. All corridor messages are content-addressed: the message identifier is the content-addressed digest of the message’s canonical bytes. Modification of any field changes the digest, making tampering detectable.

9.8 Receipt Chain Integrity

Corridor operations produce receipt chains, append-only sequences of receipts backed by a Merkle Mountain Range (MMR; Todd, 2012; Bünz et al., 2020) for efficient inclusion proofs. The receipt chain enforces:

• Hash-chain continuity. Each receipt’s predecessor root equals the previous receipt’s final state root.
• Content addressing. Each receipt’s next-state root is the SHA-256 digest of the canonical byte encoding of the payload.
• MMR commitment. The chain’s aggregate root is the MMR commitment over all next-state roots.

Fork detection uses signed watcher attestations with timestamp bounds, a 5-minute maximum clock skew tolerance, and three-level ordering: timestamp (primary), watcher attestation count (secondary), lexicographic digest tiebreaker (tertiary). This ordering triages competing observations; it is not a legal resolution rule for protocol forks or equivocation.

9.9 PII Protection

The architecture specifies field-level encryption at rest for personally identifiable information, with authenticated encryption (e.g., AES-256-GCM) applied below the storage-layer interface. Log-level PII scrubbing in the request-handling middleware redacts sensitive fields (email, phone, national-identity numbers) before log emission. Outbound HTTP clients disable redirect policies to prevent server-side-request-forgery attacks. These are defense-in-depth measures above the cryptographic guarantees of the proof bundle itself.

10.1 What Is Targeted for Proof

The architecture names a set of formal obligations, some of which are discharged and some of which remain open. Honesty about the distinction is itself a contribution: compliance infrastructure whose formal targets are unclear cannot be audited, and compliance infrastructure whose claims exceed its proofs is a failure mode worth foreclosing.

State-machine properties (TLA+). The mutation-firewall invariants, the BSC corridor-commit protocol, leader transfer for background coordination, lifecycle morphism, trigger-system causality, key-rotation continuity, and emergency halt semantics are targeted for TLA+ specification and bounded model checking. Until the public .tla artifacts and run parameters are cited, this paper treats those checks as specification obligations and scaffolding evidence, not as closed confirmation of safety or liveness.

Lattice algebra. The compliance-tensor lattice properties, associativity, commutativity, and idempotence of meet; pointwise-meet correctness; and the Galois connection for the pointwise residual on fixed applicability slices are proof targets. The public proof-assistant evidence is partial; papers must cite the closed lemmas they rely on rather than treating the whole algebra as mechanically discharged.

Type-system soundness (Coq). The Lex type system is mechanized in Coq. The mechanization establishes decidability of admissibility, typing rules for the admissible core, and the standard binding substitution lemmas needed by the current De Bruijn development. What the mechanization leaves open: preservation for the full admissible fragment, unconditional progress beyond the named premises, confluence through par_diamond_spec, shift-compatibility for step_match_ctor_fire through conv_eq_shift_compat_spec, and strong normalization beyond the flat affine fragment. These are acknowledged as the primary open metatheoretic obligations; the architecture does not claim these are proved.

Bilateral signed commitment. The BSC protocol’s commit-safety obligation (ledger O-2a), partition-heal terminal-agreement obligation (ledger O-2b), accountable-disagreement obligation under bounded Byzantine behavior (ledger O-3), and recovery finite-state-machine obligation are proof targets. Current evidence is the state-machine specification, the payload-abstract session theorem, the BSC kappa invariants, and the certificate-core terminal-evidence determinism lemmas. Durable receipt-chain agreement, concrete payload instantiation, recovery FSM correctness, and Byzantine certificate extraction remain release gates. The accountable-disagreement proof depends on the non-repudiability of signed verdicts (EUF-CMA), collision-resistant content addressing, and watcher/receipt-chain inclusion assumptions.

Cryptographic soundness. Merkle inclusion-proof soundness and completeness under collision-resistant hashing are standard proof obligations; this paper does not claim a closed mechanization unless a cited public lemma is named.

10.2 What Is Explicitly Not Proved

The paper is explicit about limits that neither the current proof set nor any plausible extension of it can remove:

Evaluator fidelity. The domain evaluators implement jurisdictional compliance rules in Lex. The rules are type-checked and the type system’s soundness is partially mechanized, but whether a specific AML evaluator correctly encodes a given jurisdiction’s statutory requirements is a question of fidelity between Lex code and law, validated by jurisdiction experts, not by a proof assistant.

Operational equivalence. Relating the abstract specification to a concrete implementation is conformance checking, not full functional equivalence: it verifies that an implementation follows the specification’s state machine, not that every line of implementation code is correct.

Cryptographic hardness. The system relies on standard cryptographic assumptions: the hardness of discrete logarithm on a named elliptic curve, collision resistance of the content-addressing hash, authenticated encryption of the field-encryption primitive, and, for ZK lock proofs, knowledge-of-exponent on a pairing-friendly curve. These assumptions are cited, not proved.

Byzantine adversary for zone operators. As discussed in Section 5.3.2, the protocol is specified to be safety-preserving under fail-stop assumptions and accountability-preserving under bounded Byzantine assumptions where signatures are unforgeable. These are proof targets, not classical Byzantine fault tolerance. The defense against a Byzantine zone operator is reputation and cryptographic accountability, not consensus.

10.3 The Formal-Gate Discipline

The architecture commits to treating formal proofs as CI artifacts. Gates for model-checking, refinement conformance, dynamic trace witnessing, operation-kernel legality, callback-contract validation, passport hash-chain integrity, and proof-count regression should run on every commit. A release attestation digest-binds the gate reports. If any gate fails, the release is rejected.

This is an architectural commitment, not a guarantee that every gate is currently green. Formal proof mechanization is a moving target; the open obligations in Section 10.1 reflect current gaps, and precise accounting is required. The gate discipline ensures that new gaps are visible (a new admitted theorem in Coq raises a regression alarm) rather than silently accumulating.

12.1 Blockchain Systems

Bitcoin [Nakamoto 2008] introduced decentralized consensus through proof of work. The key insight is that mutually distrusting parties can agree on a transaction ordering without a central authority. The sovereign jurisdiction network does not solve this problem because it does not need to: within a jurisdiction, the kernel is the trusted authority (trusted by that jurisdiction’s regulator). Between jurisdictions, the corridor protocol provides bilateral agreement without global consensus.

Ethereum [Buterin 2014; Wood 2014] extends the blockchain model with a Turing-complete smart contract platform. The Ethereum yellow paper specifies a global state machine where every node executes every transaction. This global execution model is antithetical to jurisdictional sovereignty: a compliance evaluation under one jurisdiction’s law should not be executed or validated by validators whose mandate arises under another jurisdiction’s law. The sovereign jurisdiction network inverts this: execution is local, verification is bilateral, and there is no global state.

Cosmos IBC [Kwon and Buchman 2016] provides an inter-blockchain communication protocol that relays opaque packets between sovereign chains. The closest analogy to corridors. The distinction is that IBC packets carry application-specific data with no composition semantics, while corridors carry typed compliance tensors with defined meet, pointwise residual, and Merkle-verification structure. The receiving zone composes the data with its own compliance state using well-defined lattice operations.

12.2 Federation Systems

X-Road [Estonian Information System Authority] is the data exchange layer underlying Estonia’s digital government. X-Road enables secure data exchange between organizations, a citizen’s identity data flows from the population registry to a bank. X-Road exchanges data; corridors compose compliance constraints. The distinction is algebraic: X-Road moves values (a name, an address, a KYC status), while corridors move typed tensors that participate in lattice operations. X-Road’s “information system can query another information system” is necessary and insufficient for portable compliance. The compliance state must be composable as well as transferable.

SWIFT [Society for Worldwide Interbank Financial Telecommunication] provides the messaging infrastructure for international financial transactions. SWIFT messages carry payment instructions between banks. SWIFT is a messaging standard; the kernel network is a compliance evaluation architecture. They are complementary, not competing.

eIDAS [European Parliament Regulation (EU) No 910/2014] establishes a framework for electronic identification and trust services across EU member states, enabling cross-border credential portability. The kernel passport can interoperate with trust-service frameworks of that kind. The key distinction is that eIDAS operates within a pre-existing legal harmonization, while the sovereign jurisdiction network operates between jurisdictions with no pre-existing harmonization; the (R, μ, γ) parameterization encodes whatever degree of mutual recognition the bilateral parties negotiate, from full to zero.

12.3 Routing Systems

BGP [Rekhter, Li, and Hares 2006] is the inter-domain routing protocol of the internet. Each autonomous system (AS) makes independent routing decisions; BGP propagates reachability information between ASes. The corridor network is to jurisdictional compliance what BGP is to internet routing: a protocol for bilateral agreements between sovereign entities that produces a directed reachability graph without central coordination. Each node (zone) is sovereign, connections are bilateral, and the topology emerges from bilateral agreements rather than central planning. The distinction: BGP propagates reachability (is this prefix reachable?), while corridors propagate compliance state (what is this entity’s compliance status, and how does it compose with the receiving zone’s evaluation?). BGP’s path selection is based on AS-path length and policy; corridor routing is based on compliance tensor compatibility (Jaccard similarity over domain coverage) and cost (Dijkstra-weighted).

12.4 CBDC Cross-Border Systems

mBridge [BIS Innovation Hub, 2022] and Project Dunbar [BIS, Reserve Bank of Australia, Bank Negara Malaysia, Monetary Authority of Singapore, South African Reserve Bank, 2022] explore multi-CBDC cross-border payment platforms. These projects address the settlement layer, how central bank digital currencies move between jurisdictions. The sovereign jurisdiction network addresses the compliance layer, how compliance state is evaluated, composed, and verified across jurisdictions. The two are complementary: mBridge and Dunbar provide payment rails, while the kernel network provides the compliance proofs that authorize movement on those rails.

12.5 Verified Systems

seL4 [Klein et al. 2009] is the first formally verified general-purpose operating system microkernel. seL4 proves functional correctness: the C implementation refines the abstract Haskell specification, which refines the Isabelle/HOL formal model. The sovereign jurisdiction network’s formal verification ambition is narrower: the obligations named in Section 10 target specific architectural properties (tensor algebra, type-system soundness, protocol safety) rather than full functional correctness of the implementation. seL4 sets a standard to which this work asymptotes in the specific subsystems it covers; the comparison is orientational, not equal.

12.6 Regulatory Frameworks

Basel Accords [Basel Committee on Banking Supervision] establish international standards for banking regulation. Basel III’s capital adequacy, stress testing, and leverage ratio requirements are the kind of compliance rules that the kernel’s Banking and Clearing domain evaluators encode. The Basel framework operates through “national implementation”, each country implements Basel requirements in its own regulatory framework. The sovereign jurisdiction network mirrors this: each kernel encodes its jurisdiction’s implementation of international standards, and corridors parameterize how one jurisdiction’s implementation relates to another’s.

EU Passporting [European Parliament Directive 2014/65/EU] allows financial firms authorized in one EU member state to operate in other member states without additional authorization. EU passporting is the real-world precedent for the corridor concept. The distinction: EU passporting is a legal arrangement backed by a common regulatory framework (the single market); corridors are a technical protocol backed by pointwise composition semantics. Corridors can encode EU-style full mutual recognition (R = {Sanctions}, $= $ identity, grade maps accepting the shared vocabulary) or much more conservative arrangements (large R, non-trivial μ, partial grade maps). The system is parametric over the degree of mutual recognition.

12.7 Timestamping and Ordering

Haber and Stornetta [1991] introduced hash-chain timestamping: linking documents into a chain where each document’s hash includes its predecessor’s hash, creating a tamper-evident sequence. The kernel’s append-only event store and compliance passport both use this construction. Each kernel event’s identifier is the content-addressed digest of event type, payload, and prior-event identifier, directly implementing the Haber-Stornetta chain. The compliance passport extends this to compliance evaluations: each passport entry is hash-linked to its predecessor, creating a verifiable compliance history.

Lamport clocks [Lamport 1978] establish a partial ordering on events in distributed systems without requiring synchronized physical clocks. The kernel event store provides a total order within each entity’s event chain (hash-chain linking) and a partial order across entities (no cross-entity ordering is required or claimed). For cross-zone operations, the BSC protocol is specified to establish agreement on the commit point without requiring global clock synchronization. Its safety properties are proof targets under the configured timeout and clock-skew assumptions.

13.1 The Structural Argument

When the cost of moving compliance state between jurisdictions falls materially, jurisdictions may face greater competitive pressure on regulatory quality. Tiebout (1956) argued that mobile consumers “vote with their feet” among local governments, and competition between jurisdictions leads to efficient provision of local public goods under strong assumptions. The Tiebout model makes three assumptions that do not hold in practice: perfect mobility (moving is costless), perfect information (consumers know what each jurisdiction offers), and no externalities (one jurisdiction’s policies do not affect others).

The sovereign jurisdiction network addresses two of these three limitations directly:

Information through passports. Tiebout assumed perfect information about jurisdictional quality. In practice, comparing regulatory frameworks requires expensive human analysis. The compliance passport provides a machine-verifiable record of a jurisdiction’s signed and attested compliance evaluations. An entity considering a new harbor can inspect the compliance passports of entities already operating there. The shared domain-indexed tensor provides a standard representation that makes cross-jurisdictional comparison tractable. This reduces the information asymmetry that shields low-quality jurisdictions from competitive pressure.

Mobility through corridors. Tiebout assumed costless mobility. In practice, the compliance switching cost, re-evaluation from scratch in the new jurisdiction, is a major barrier to jurisdictional mobility. Corridors reduce this cost to the re-evaluation of domains in R, plus measured corridor friction and any corridor-formation bottleneck that remains. The compliance passport travels with the entity; the history is not abandoned at the border.

Externalities remain. Tiebout assumed no externalities. The sovereign jurisdiction network does not address the externality problem by itself: jurisdictions that compete on regulatory laxity (“races to the bottom”) can impose costs on other jurisdictions through regulatory arbitrage. The architecture makes regulatory arbitrage more visible (compliance passports reveal the evaluating jurisdiction’s standards) and faster (corridors enable rapid movement), but it does not prevent a jurisdiction from setting low standards. The cross-harbor meet prevents laxity from relaxing an in-scope stricter constraint on cross-harbor operations; it does not bind purely local operations or eliminate externalities. Whether increased mobility leads to laxity-seeking, quality-seeking, pooling, or segmented equilibria is a parameter-regime question that depends on entity preferences, local-operation shares, floor strength, inspection intensity, non-computational switching costs, and corridor governance.

13.2 The Competition Mechanism

When an entity can carry its compliance passport from jurisdiction J₁ to jurisdiction J₂ and have its evaluation history cryptographically verified and composed point-by-point, the compliance component of switching cost drops to the cost of re-evaluating the domains in R together with the corridor’s friction profile. For corridors with small R and low friction, this cost can be materially smaller than a full restart, but it is not zero.

Jurisdictions that impose unnecessarily high compliance burdens face a sharper exit signal from entities able and willing to use corridors. Jurisdictions that produce high-quality compliance evaluations may attract entities when partner zones respect those evaluations, corridor friction is low enough, passport signals are informative enough, inspection is strong enough to deter local-only arbitrage, and non-computational preferences do not dominate. The architecture creates a measurable competitive channel; the equilibrium effect remains the game-theoretic obligation named in Section 11. The theorem target is a finite two-stage game over corridor formation and entity mobility, with mixed-equilibrium existence, exit-signal monotonicity, meet-floor, visibility, and parameter-regime classification proved under stated assumptions rather than inferred from the architecture.

13.3 What This Does Not Solve

The mechanism requires jurisdictions to deploy kernels and establish corridors. It does not compel them to do so. A jurisdiction that refuses to participate faces no competitive pressure from the network; its entities cannot benefit from portable compliance. The system creates incentives for participation without mandating it.

The system also leaves regulatory capture, corruption, and incompetence within a jurisdiction as political risks. A corrupt regulator controlling a kernel can issue false compliance evaluations. The graduated trust model and local sanctions re-evaluation provide defense in depth (Section 9.6); they are mitigations. The system makes the consequences of bad regulation more visible through entity exit without preventing bad regulation from occurring.