Authorized Here, Not Authorized There: Jurisdiction-Bound Execution Finality for Cross-Border and Sovereign Systems

Introduction

Vulnerability: Authorization Can Survive a Jurisdiction Change A system can authenticate a workload correctly, evaluate authorization correctly, establish an encrypted channel, verify a valid credential, and attest a healthy execution environment, yet still allow the resulting act to become effective under a jurisdictional or governance context that was not authorized for that act. The central failure is continuity. Authorization may be issued while the workload is in one region or sovereign context, but the actual effect can occur later after migration, failover, rerouting, destination change, remote administrative intervention, key-control change, or downstream processing.

Authorization survives a jurisdiction change t0 t1 t2 | | | | Candidate C authorized | workload / route / | protected | under context J17 | control context changes | effect K | | to J18 | |--------------------------|--------------------------| | v EFFECT under J18 If J18 is not permitted for C, a valid authorization at t0 MUST NOT silently survive to t2. This attack does not necessarily require token forgery, identity theft, broken encryption, or compromised attestation. The earlier authorization can remain authentic while the context that made the act permissible has changed.

Existing Mechanisms Already Address Important Parts OAuth Rich Authorization Requests can carry fine-grained authorization data . A deployment can define authorization-detail fields for region, sovereign domain, destination, data handling, or other jurisdiction-sensitive constraints. OAuth Resource Indicators identify the protected resource for which access is requested . JWT can carry signed application-specific claims such as issuer, audience, and private context claims . WIMSE addresses workload identity and security context in multi-system environments . RATS supplies a standardized architecture for Evidence, Verifiers, Attestation Results, Reference Values, and Relying Party decisions . SCITT supplies signed statements, transparency, registration, and verifiable receipts . Industrial platforms likewise already implement substantial sovereignty controls. Microsoft documents the EU Data Boundary and continuing-transfer cases . AWS documents the European Sovereign Cloud as an independent cloud environment designed for European sovereignty requirements . Google Cloud documents partner-operated Sovereign Controls including data-residency controls, external key management, and local supervision . These mechanisms are not treated as deficient. The ability to express region or jurisdiction constraints, attest a workload, constrain data residency, or operate a sovereign cloud is not the proposed novelty. If a deployment already enforces all required jurisdiction dimensions at the actual non-bypassable consequence boundary, it already satisfies the core property described here.

Why the Residual Gap Can Remain The residual gap appears when the enforcement boundary is narrower than the policy semantics. A signed claim such as "region=EU" can be authentic while the downstream processing path has moved. A workload identity can still name the correct workload while that workload runs in a disallowed control domain. A platform can be correctly attested while the destination, operator, remote-access context, or data-egress path violates the deployment's jurisdiction policy. Storage residency is also not automatically equivalent to complete processing sovereignty. Data can remain at rest in one region while being remotely accessed, processed, decrypted, transmitted, or disclosed through another operational context. Microsoft's own EU Data Boundary documentation distinguishes storage/processing commitments from documented continuing transfers and remote-access scenarios . This is an example of why a useful technical model must define the exact policy dimensions rather than reduce jurisdiction to one country code. RATS can provide trustworthy technical evidence, but an Attestation Result is not itself a legal determination. OAuth RAR can express jurisdiction-sensitive authorization detail, but expression does not prove that the current downstream effectuation environment still satisfies the detail. WIMSE can identify workloads across systems, but workload identity is not automatically operational or geographic jurisdiction. SCITT can prove that a statement was signed or registered, but that statement is not automatically a load-bearing effectuation rule.

What This Architecture Introduces The proposed contribution is deliberately narrow: jurisdictional authority is treated as an effectuation-time property of the exact Candidate Act. A Candidate Act remains non-effective until the Finality Sink establishes a current Jurisdiction Execution Context and verifies that the present effectuation environment satisfies the applicable machine-readable Jurisdiction Policy.

Define the jurisdiction-sensitive Candidate Act and Protected Consequence.
Define the deployment's authoritative Jurisdiction Policy instead of inferring law from geography.
Establish a current Jurisdiction Execution Context from trusted evidence sources.
Represent all policy dimensions that are actually load-bearing for the deployment.
Bind jurisdiction applicability to the exact act, destination, sink, and current policy/context generation.
Revalidate after migration, failover, routing, destination, operator, key-control, or equivalent context change.
Keep the act non-effective when jurisdiction context is unknown, stale, or disallowed.
Require every consequence-producing path to preserve equivalent jurisdiction enforcement.

Conventions and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Direct Question: What Threat Does This Architecture Solve? If Candidate Act C is authorized under jurisdiction or governance context J1, what prevents C from becoming effective after the execution context changes to J2? RequiredJurisdiction(C) = J_req CurrentContext(C, sink) = J_now NOT JurisdictionApplicable(J_req, J_now) ==> NOT Effective(K, C) The architecture does not decide whether J1 or J2 is legally correct. It enforces the authoritative machine-readable policy selected by the deployment.

Motivating Scenario: Authorized in J17, Effectuated in J18 Consider a sensitive AI inference result whose release is authorized only while the model, input data, decryption keys, and output release are governed by an approved sovereign processing context. The workload is initially scheduled in J17 and receives authorization. Before output release, an availability event activates failover to J18. Identity and workload credentials remain valid, and the replacement platform is healthy, but J18 is not within the policy permitted for that result.

Problem Space

Jurisdiction Is Not Merely Location A deployment's jurisdiction policy can include physical processing location, sovereign cloud membership, operator/control domain, key custody, remote-access policy, destination, trust state, and other dimensions. A country or region code alone is not a universal jurisdiction model.

Data Residency Is Not Complete Sovereignty

Storage residency does not prove complete effectuation context DATA STORED IN EU | +---------------+----------------+ | | | v v v processing remote admin destination outside EU outside policy outside policy A storage-location fact can be true while another load-bearing sovereignty dimension is false. The deployment must state which dimensions are required. A data-residency-only profile is valid if residency is the entire intended property, but it must not be described as a broader sovereignty guarantee.

Identity Is Not Jurisdiction A valid workload credential establishes workload identity under its profile. It does not automatically establish processing location, operator control, remote access, or destination. Those facts can be separately bound to the workload or resolved at the Finality Sink.

Attestation Is Not Legal Classification RATS and platform attestation establish technical claims and appraisal results. An application policy can interpret those technical claims as satisfying a jurisdiction profile, but the attestation protocol does not itself decide what law applies.

Audit Is Not Prevention Recording after the fact that processing occurred in a particular region can support compliance evidence, incident response, and accountability. It does not prevent an act from becoming effective under a disallowed context.

Threat Model and Assurance Scope

Adversary Capabilities The adversary MAY control or influence the requester, AI agent, application process, workflow engine, scheduler, ordinary operating system, service-mesh routing, unprotected region labels, an untrusted GeoIP or location service, queue producers, ordinary configuration caches, downstream service selection, user-controlled destinations, failover requests, or network routing outside protected enforcement. The adversary MAY replay old jurisdiction evidence, move a workload after authorization, redirect processing, alter destination, choose a global endpoint, activate a recovery path, exploit remote administration, suppress a policy update, or substitute context evidence from another workload, tenant, region, or generation.

Threat Severity and Applicability Severity is consequence-dependent. The issue deserves high attention for sovereign or public-sector cloud, regulated financial processing, health or sensitive personal data, national-security and defence data, AI model weights and confidential inference, cross-border AI agents, telecom/network control, critical infrastructure, government workloads, controlled technical data, cross-border payment or CBDC systems, and cryptographic key custody. The same architecture can be used for lower-risk applications, but a routine regional routing preference should not be mislabeled as a high-severity jurisdictional security requirement.

Baseline Jurisdiction-Finality Profile The requester, application, ordinary network, unprotected location metadata, and ordinary caches are untrusted. The authoritative Jurisdiction Policy source, required JEC evidence sources, cryptographic verification roots, and Finality Sink are trusted.

High-Assurance Jurisdiction-Finality Profile A higher-assurance profile MAY additionally distrust the host operating system, hypervisor where appropriate, orchestrator, scheduler, service mesh, ordinary cloud metadata cache, application-level region tags, or local configuration database. JEC inputs and finality enforcement must then be anchored in protection domains those components cannot rewrite or bypass. Potential substrates include attested confidential compute, HSMs, TEEs, DPUs or SmartNICs, protected network boundaries, protected storage or transaction services, and independently controlled policy authorities.

Trusted Roots and Limits The base model assumes the selected jurisdiction policy is authoritative for the deployment and that at least one trusted evidence path exists for every required JEC dimension. Compromise of every policy/evidence authority, physical site falsification beyond the deployment's evidence model, or effectuation outside the declared consequence domain is outside the base prevention claim.

Design Goals and Non-Goals The design goal is to make jurisdiction-sensitive authority current, explicit, bounded, testable, and load-bearing at effectuation. This document does not determine which law applies, define regulatory compliance, replace legal analysis, define a universal country-code taxonomy, mandate GeoIP, create a new OAuth grant type, replace WIMSE workload identity, replace RATS, replace sovereign-cloud products, or mandate a new JEC token format. A profile MAY encode JEC in JWT, EAT, OAuth authorization details, WIMSE context, SCITT statements, protected local state, or another representation. The architecture requires the semantics, not a specific encoding.

Existing Mechanisms and the Proposed Delta

OAuth Rich Authorization Requests RFC 9396 defines `authorization_details` for fine-grained authorization . A deployment can define region, sovereign domain, resource, destination, or data-handling constraints within an authorization-details type. This document does not claim that expressing those constraints is new. The residual question is whether they remain current and mandatory at the actual consequence after downstream movement or context change.

OAuth Resource Indicators RFC 8707 allows an authorization request to identify the protected resource . Resource binding is valuable, but resource identity does not automatically establish the current processing region, operator/control domain, key control, or effect destination.

JWT and Application Claims JWT defines signed claims including issuer, subject, audience, and extensible application claims . A jurisdiction or region claim can therefore be carried using existing token machinery. The effectuation question is who vouches for the claim, what it means, how current it is, whether it applies to the present workload and sink, and whether the final effect technically depends on it.

WIMSE The WIMSE architecture addresses workload identity in multi-system environments . Workload identity is a strong input to JEC because JEC evidence must apply to a specific workload or trust domain. This document does not define a competing workload identity. It asks whether the identified workload's current effectuation context satisfies a separate deployment jurisdiction policy.

RATS RATS supplies technical Evidence and Attestation Results . Attestation can be a high-assurance JEC evidence source for platform, firmware, workload, configuration, or other profile-specific claims. The application still decides whether those technical claims satisfy J_req(C). This document does not turn RATS into a legal-jurisdiction oracle.

SCITT SCITT provides signed statements, transparency, and receipts . These can protect jurisdiction-policy manifests, sovereign-domain statements, configuration records, or evidence provenance. Registration or transparency does not by itself make a jurisdiction statement a load-bearing precondition of effectuation.

Cloud Sovereignty and Data-Boundary Controls Microsoft, AWS, and Google Cloud provide concrete controls and commitments addressing residency, sovereignty, operational control, or partner supervision . These are strong industrial precedents. The proposed model is not a replacement. A deployment using those controls may already satisfy the invariant if the policy dimensions required for C remain current and non-bypassable at the effectuation boundary.

Different JEC dimensions can require different evidence assurance Example policy: processing_region: require ATTESTED_PROTECTED_ASSERTION storage_region: require SIGNED_CONTROL_PLANE_ASSERTION operator_domain: require SIGNED_OPERATOR_ASSERTION destination: require exact observed endpoint + policy match remote_access: require protected session/control-state evidence No single "region=EU" label is sufficient for this profile.

Comparison Summary Existing mechanism and residual effectuation question

Mechanism	Strong existing property	Residual question only where not already enforced
OAuth RAR	Fine-grained authorization data	Does the jurisdiction constraint remain applicable at the actual effect?
Resource Indicators	Resource-specific authorization request	Is current jurisdiction/control context also required?
JWT	Signed/extensible claims	Who establishes jurisdiction, how current is it, and is it effectuation-bound?
WIMSE	Workload identity/security context	Does the current workload context satisfy sovereign policy at final effect?
RATS	Evidence and Attestation Results	Do the technical claims establish the required JEC dimensions for C?
SCITT	Signed statements/transparency/receipts	Is the statement a load-bearing rule or only evidence/audit?
Sovereign-cloud controls	Concrete residency/sovereignty controls	Does the deployment's exact consequence remain confined to all required dimensions?

What Is New in This Document The proposed contribution is the composition invariant, not the individual inputs. Jurisdiction-sensitive authority is evaluated again at the actual consequence boundary using the current effectuation context. Authorization under J17 != automatic authority under J18 For protected act C: Current JEC must satisfy J_req(C) immediately before or atomically with effectuation. If an existing OAuth, WIMSE, RATS, SCITT, sovereign-cloud, or proprietary architecture already provides that exact property for a deployment, the deployment already satisfies the core invariant.

Prevention and Mitigation Property

Prevention Profile Prevention of the governed jurisdiction-substitution class can be claimed only where the policy is authoritative, the exact Candidate Act is bound, the current JEC is established from trusted evidence, all load-bearing dimensions are checked, state/context changes cannot silently preserve stale authority, every effectuation path preserves equivalent enforcement, and successful verification is coupled to protected commit. authoritative J_req(C) + exact-act binding + trusted current JEC + all load-bearing jurisdiction dimensions + current policy/context generation + non-bypassable consequence path + protected verification-to-commit ordering = PREVENTION of the governed J1-to-J2 substitution class

Mitigation or Evidence Profile GeoIP, unsigned region labels, application deployment annotations, best-effort routing, post-hoc audit, stale region configuration, or incomplete consequence-path coverage can be useful controls but do not establish the same prevention invariant.

Unknown Jurisdiction Context A high-assurance profile SHOULD define an explicit JEC_UNKNOWN state. When a required JEC dimension cannot be established, a prevention profile MUST NOT silently interpret unknown as permitted. The Candidate Act should remain non-effective or enter a clearly identified lower-assurance policy.

Terminology Candidate Act: A proposed consequence-bearing operation that is prepared but has not yet been permitted to become externally effective. Protected Consequence: The first external, persistent, financial, physical, disclosure, administrative, or other effect governed by the deployment. Jurisdiction Policy: Machine-readable deployment policy defining the jurisdiction, sovereignty, data-boundary, control, destination, or related technical constraints required for a Candidate Act. It is not a legal opinion. Jurisdiction Execution Context (JEC): The current set of technical context facts used to evaluate Jurisdiction Policy at effectuation. Jurisdiction Context Evidence: Protected or authenticated evidence used to establish one or more JEC dimensions. Jurisdiction Generation: A protected epoch, version, digest, or equivalent identifier representing current jurisdiction policy and/or context state. Jurisdiction Applicability: The property that the current JEC satisfies the Jurisdiction Policy for the exact Candidate Act. Non-Effective State: A state in which the Candidate Act cannot yet produce the protected consequence. Finality Sink: The protected functional boundary where the Candidate Act first becomes externally effective and where final jurisdiction applicability is verified.

Jurisdiction Execution Context (JEC) JEC is intentionally multi-dimensional. A deployment selects only the dimensions required by its policy. X_now = ( workload_identity, compute_domain, processing_region, storage_region, destination_domain, operator_control_domain, key_control_domain, remote_access_context, sovereign_boundary, trust_state, policy_generation ) JEC is an architectural role and can be reconstructed from multiple sources rather than carried in a single token.

Typed Jurisdiction DimensionsA Jurisdiction Execution Context is not one country code. It is a typed set of dimensions, each with its own evidence source, assurance requirement, currentness rule, and policy semantics. A deployment selects only the dimensions that are load-bearing for a Candidate Act. JEC(C,t) = { workload_identity : W, compute_domain : CD, processing_region : PR, storage_region : SR, destination_domain : DD, operator_control_domain : OD, key_control_domain : KD, remote_access_context : RA, sovereign_boundary : SB, trust_state : TS, policy_generation : Gp, topology_generation : Gt } Each dimension d has: Value_d Evidence_d Assurance_d Freshness_d Authority_d Scope_d

Dimension State and UNKNOWN Semantics DimensionState_d ∈ { KNOWN_ALLOWED, KNOWN_DENIED, UNKNOWN, STALE, CONFLICTING, UNAVAILABLE } For strict prevention: UNKNOWN OR STALE OR CONFLICTING OR UNAVAILABLE MUST NOT silently become ALLOW. A profile may define a lower-assurance fallback, but it must be explicit and must not be described as equivalent to the strict prevention profile.

Jurisdiction Evidence Source Model Source_d = ( issuer, evidence_type, protected_scope, freshness_model, assurance_class, rollback_protection, workload_binding, sink_binding_if_required ) TrustedFor(Source_d, dimension=d, policy=P) iff Source_d.issuer ∈ P.trusted_issuers[d] AND Source_d.assurance_class >= P.min_assurance[d] AND Source_d.scope covers P.required_scope[d]

Evidence-Assurance OrderingAssurance can be modeled as a partial order rather than a universal numeric scale. A policy can require one assurance class for processing region and a different class for key-control domain. Example partial order: APP_LABEL < AUTHENTICATED_METADATA < SIGNED_CONTROL_PLANE_ASSERTION < ATTESTED_PROTECTED_ASSERTION But: NETWORK_GEOLOCATION may be incomparable with SIGNED_OPERATOR_ASSERTION unless the deployment explicitly defines a relation. Requirement: EvidenceClass(E_d) ⪰ RequiredClass(P,d) This avoids implying that every evidence source can be ranked globally or that a weak source becomes strong merely because its value happens to be correct.

Multi-Source Corroboration Corroborated(d, E_set, P) := P.corroboration_rule[d]( { e ∈ E_set | TrustedFor(e.source, d, P) AND EvidenceFresh(e) AND EvidenceScopeValid(e) } ) Examples: ALL_OF(E_region_attestation, E_control_plane) ANY_OF(E_operator_A, E_operator_B) THRESHOLD(2 of {E1,E2,E3}) A profile can require corroboration where one source alone is insufficient. The rule must be protected policy rather than an application hint.

Multi-Dimensional Jurisdiction Policy

Data-Residency Profile ALLOW if: storage_region IN ApprovedStorageRegions

Processing-Sovereignty Profile ALLOW if: storage_region IN ApprovedStorageRegions AND processing_region IN ApprovedProcessingRegions

Operational-Sovereignty Profile ALLOW if: processing_region IN ApprovedProcessingRegions AND operator_control_domain IN ApprovedOperators AND key_control_domain IN ApprovedKeyDomains AND remote_access_context satisfies RemoteAccessPolicy

Strict Effectuation Profile ALLOW if: processing boundary allowed AND storage boundary allowed (when required) AND destination allowed AND operator/control domain allowed AND key-control domain allowed AND remote-access policy satisfied AND trust state acceptable AND jurisdiction generation current AND consequence path cannot bypass final enforcement

Formal Jurisdiction Policy J_req(C) = ( RequiredDimensions, AllowedValues, MinAssurance, FreshnessBounds, CorroborationRules, DestinationRules, ControlRules, KeyControlRules, RemoteAccessRules, TrustRules, TransitionRules, UnknownHandling, EmergencyProfile ) The policy can be act-specific. A low-sensitivity read can require only storage residency, while release of a high-value model or regulated dataset can additionally require processing, operator-control, key-control, destination, and remote-access predicates.

Jurisdiction Rule Composition JurisdictionPolicySatisfied(J_req, X_now) := FOR ALL d ∈ J_req.RequiredDimensions: DimensionSatisfied(d, J_req, X_now) DimensionSatisfied(d,P,X) := State_d(X) == KNOWN_ALLOWED AND ValueAllowed(P,d,X[d]) AND EvidenceAssuranceSufficient(P,d,X) AND EvidenceFreshEnough(P,d,X) AND CorroborationSatisfiedIfRequired(P,d,X)

Alternative and Conditional Sovereignty Rules Examples: ANY_OF processing regions: PR ∈ {EU-A, EU-B, EU-C} Conditional key rule: IF DataClass(C) == HIGHLY_SENSITIVE THEN KD ∈ ApprovedSovereignKMS Destination condition: IF Operation(C) == DISCLOSE THEN DD ∈ ApprovedRecipientDomains Emergency rule: IF EmergencyProfileActive THEN use separately labeled J_emergency with explicit weaker guarantees Conditional or emergency rules are valid only when machine-readable and explicit. A hidden operator override is an alternate policy path, not the same strict profile.

Jurisdiction-Context EquivalenceTwo contexts need not be byte-identical to be equivalent for a particular Candidate Act. Equivalence must be policy-defined and dimension-scoped. EquivalentFor(C, X1, X2, P) := FOR ALL d ∈ P.RequiredDimensions(C): EquivalentValue_d( X1[d], X2[d], P.equivalence_rule[d]) AND Assurance(X2[d]) >= RequiredAssurance(P,d) AND FreshnessValid(X2[d]) This permits, for example, migration between two approved sovereign regions while preventing a generic claim that all EU-labelled environments are automatically interchangeable.

Formal Mathematical Model Let C be the Candidate Act, K the Protected Consequence, S the Finality Sink, J_req(C) the required Jurisdiction Policy for C, X_now the current JEC, E_J the context evidence set, and g_J the current jurisdiction generation. ContextEvidenceValid(E_J, X_now, S, g_J) := EvidenceIntegrityValid(E_J) AND EvidenceIssuerTrusted(E_J) AND EvidenceFresh(E_J) AND EvidenceAppliesToWorkload(E_J, X_now.workload_identity) AND EvidenceAppliesToSink(E_J, S) AND EvidenceGenerationCurrent(E_J, g_J) JurisdictionApplicable(J_req, X_now, E_J) := ContextEvidenceValid(E_J, X_now, S, g_J) AND RequiredComputeDomainSatisfied(J_req, X_now) AND RequiredProcessingBoundarySatisfied(J_req, X_now) AND RequiredStorageBoundarySatisfiedIfAny(J_req, X_now) AND RequiredDestinationSatisfied(J_req, X_now) AND RequiredControlDomainSatisfied(J_req, X_now) AND RequiredKeyControlSatisfied(J_req, X_now) AND RequiredRemoteAccessRuleSatisfied(J_req, X_now) AND RequiredTrustStateSatisfied(J_req, X_now) The finality safety invariant is: Effective(K, C) ==> ExactActBindingValid(C) AND JurisdictionApplicable(J_req(C), X_now, E_J) AND JurisdictionGenerationCurrent(g_J) AND EffectuationPathAuthorized(C, S) For a strict prevention profile: NOT JurisdictionApplicable(J_req(C), X_now, E_J) ==> NOT Effective(K, C)

Bounded Prevention Argument Assume that the Jurisdiction Policy is authoritative for the deployment, every load-bearing JEC dimension is represented by trusted current evidence, the Finality Sink evaluates the exact Candidate Act immediately before protected commit, and every path to K preserves equivalent enforcement. Under those assumptions, an adversary cannot make K effective under a disallowed JEC without violating at least one explicit assumption: policy integrity, evidence integrity/currentness, exact-act binding, context continuity, or path non-bypassability. This is not proof of legal compliance. It is a technical prevention argument for the machine-readable policy selected by the deployment.

Formal Jurisdiction Evidence Predicate EvidenceValidForDimension(E_d, d, C, S, P, t) := IntegrityValid(E_d) AND IssuerTrustedForDimension(E_d.issuer, d, P) AND ScopeApplies(E_d, C, S) AND WorkloadBindingValidIfRequired(E_d,C) AND SinkBindingValidIfRequired(E_d,S) AND FreshnessValid(E_d,t,P.freshness[d]) AND GenerationCurrent(E_d) AND AssuranceClass(E_d) ⪰ P.min_assurance[d] AND NotSuperseded(E_d) AND ReplayRuleSatisfied(E_d)

Dimension Validity DimensionValid(d, C, X_now, E_set, P, t) := X_now[d] != UNKNOWN AND X_now[d] != STALE AND X_now[d] != CONFLICTING AND ValueAllowed(P,d,X_now[d]) AND EXISTS E_d ⊆ E_set: Corroborated(d,E_d,P) AND FOR EACH e ∈ E_d: EvidenceValidForDimension(e,d,C,S,P,t)

Cross-Dimension Context ConsistencyIndividually valid dimension claims can still describe inconsistent worlds. A processing region claim for workload W1 must not be combined with a key-control claim for W2 or a destination claim from another transaction. ContextConsistent(C, X_now, E_set) := SameWorkloadContext(E_set, C) AND SameTransactionOrActContext(E_set, C) AND SameTopologyGenerationWhereRequired(E_set) AND NoContradictoryDimensionClaims(E_set) AND CrossDimensionBindingsValid(E_set)

Expanded Jurisdiction Applicability JurisdictionApplicable(C,S,P,X_now,E_set,t) := ExactActBindingValid(C) AND PolicyApplies(P,C) AND ContextConsistent(C,X_now,E_set) AND FOR ALL d ∈ P.RequiredDimensions(C): DimensionValid(d,C,X_now,E_set,P,t) AND DestinationAndRecipientRulesSatisfied(P,C,X_now) AND ControlDomainRulesSatisfied(P,C,X_now) AND KeyControlRulesSatisfied(P,C,X_now) AND RemoteAccessRulesSatisfied(P,C,X_now) AND TrustRulesSatisfied(P,C,X_now) AND PolicyGenerationCurrent(P) AND TopologyGenerationCurrent(X_now) AND EffectuationPathAuthorized(C,S)

Policy and Context Generation Vector G_now = ( G_policy, G_workload, G_processing, G_storage, G_operator, G_key, G_remote_access, G_topology, G_trust ) GenerationVectorCurrent(G_eval,G_now,P,C) := FOR ALL dimension generations g_d that are load-bearing for P(C): g_eval[d] == g_now[d] OR AuthoritativeCompatibilityProof( g_eval[d], g_now[d], C, d) A single global generation is not required. A vector prevents unrelated state changes from forcing unnecessary invalidation while still binding every load-bearing dimension.

Context-Transition Applicability TransitionAffects(C, X_old, X_new, P) := EXISTS d ∈ P.RequiredDimensions(C): NOT EquivalentForDimension( C, X_old[d], X_new[d], P.equivalence_rule[d]) If TransitionAffects(...) = TRUE: prior jurisdiction approval MUST NOT automatically survive.

Migration and Failover Rule MigrationValid(C, X_old, X_new, P) := AuthorizedTransition(X_old, X_new, P) AND JurisdictionApplicable( C, S, P, X_new, Evidence_new, t_now) AND GenerationVectorCurrent( G_new_eval, G_new_now, P, C) Otherwise: Candidate remains NON-EFFECTIVE.

UNKNOWN and Partial-Evidence Semantics Strict profile: ∃ d ∈ RequiredDimensions(C) such that State_d ∈ {UNKNOWN, STALE, CONFLICTING, UNAVAILABLE} => NOT JurisdictionApplicable(...) Lower-assurance fallback is allowed only if: ExplicitFallbackProfileSelected AND FallbackProfileIsLabeledDistinctly AND RequiredSafety/Security PolicyAllowsFallback

Coupling to Consequence-Path Completeness JurisdictionPathSafe(C,K,D) := FOR ALL technically viable paths p capable of producing K: p crosses a jurisdiction-finality sink OR p enforces an equivalent jurisdiction invariant If EXISTS p bypassing the invariant: strict jurisdiction prevention fails.

Verification-to-Commit Serialization VerifyJEC(C, G17) | | success v ContextChange(G17 -> G18) | v CommitEff(C) If: VerifyJEC(C,G17) ≺_S Change(G17->G18) ≺_S CommitEff(C) then: CommitEff(C) MUST NOT proceed unless transition compatibility is authoritatively proven.

Strict Prevention Invariant Effective(K,C) => JurisdictionApplicable( C,S,J_req(C),X_now,E_set,t_now) AND ProtectedCommitAtFinalitySink(C,S) AND EffectuationPathAuthorized(C,S) Strict prevention: NOT JurisdictionApplicable(...) => NOT Effective(K,C)

Expanded Bounded Prevention ProofAssume: (1) J_req(C) completely identifies every load-bearing jurisdiction dimension for C; (2) every required dimension is established from sufficiently trusted, current evidence; (3) cross-dimension evidence is context-consistent; (4) every relevant migration/failover/context transition advances or validates the required generation vector; (5) the Finality Sink checks the exact Candidate Act and current JEC; (6) verification and protected commit are serialized against load-bearing context changes; and (7) every consequence-producing path crosses equivalent jurisdiction enforcement.Suppose K becomes effective while some required dimension is disallowed, stale, unknown, inconsistently bound, or below the required assurance. DimensionValid is then false, which makes JurisdictionApplicable false. The strict prevention invariant prohibits the effect, contradicting the assumed effect unless at least one premise — policy completeness, evidence trust/currentness, context consistency, transition handling, sink integrity, serialization, or path completeness — failed. The proof establishes only enforcement of the supplied machine-readable policy; it does not prove that the policy is legally correct.

Jurisdiction Generation and State Continuity A valid jurisdiction conclusion is a statement about current policy and current effectuation context. It MUST NOT silently survive a security-relevant context change.

Jurisdiction generation changes after migration or failover Generation J17: workload=W processing=EU-A operator=OP-A key-domain=K-A policy=JP17 | +---- C authorized Migration / failover / routing / operator / key change | v Generation J18: processing=EU-B or non-EU operator=OP-B key-domain=K-B policy=JP18 Result: Applicable(C, J17) does NOT imply Applicable(C, J18) A relevant context change should advance a protected generation, invalidate pending jurisdiction authority, or require an authoritative proof that the change is irrelevant to the policy dimensions required for C.

Multi-dimensional generation vector At evaluation time: G_eval = { policy: 17, processing: 44, operator: 8, key: 31, remote_access: 12, topology: 21 } Before commit: G_now = { policy: 17, processing: 45, <-- changed operator: 8, key: 31, remote_access: 12, topology: 22 <-- changed } Result: revalidate affected dimensions and path coverage rather than trusting the old aggregate approval.

Failover between equivalent and non-equivalent contexts J17: EU-A / Operator-A / KeyDomain-K1 | failover / \ v v J18a: EU-B / Operator-A / KeyDomain-K1 | approved by policy equivalence v REVALIDATE -> may remain eligible J18b: Global-X / Operator-B / KeyDomain-K9 | not equivalent for C v NON-EFFECTIVE / RE-AUTHORIZE

Exact-Act Binding Jurisdiction policy can depend on operation type, dataset, model, resource, purpose, destination, recipient, requested precision, or consequence class. The policy result MUST therefore be bound to the security-relevant Candidate Act rather than only to a session or workload.

Destination and Recipient Binding Processing context can be acceptable while the eventual destination is not. Where cross-border release or disclosure is jurisdiction-sensitive, the observed effect destination and recipient domain are load-bearing parts of JEC or of the Candidate Act.

Operator, Control-Plane, and Key-Control Binding Some sovereignty profiles require more than physical processing region. They can require a particular operator/control regime, cryptographic key-control domain, or remote-access rule. These are separate predicates and MUST NOT be inferred solely from a region label.

State Machine

Expanded multi-dimensional jurisdiction state machine +------------------+ | Candidate Act C | +--------+---------+ | v +------------------+ | Resolve J_req(C) | +--------+---------+ | v +---------------------------+ | Collect evidence per JEC | | dimension | +-------------+-------------+ | v +---------------------------+ | Verify assurance/freshness| | corroboration/consistency | +-------------+-------------+ | +-------+--------+ | | fail pass | | v v NON-EFFECTIVE JEC CURRENT/ALLOWED | v +--------------------+ | Path coverage + | | generation check | +---------+----------+ | +------+------+ | | fail pass | | v v NON-EFFECTIVE PROTECTED COMMIT | v EFFECTIVE

Solution Architecture

Resolve the Jurisdiction Policy The system determines J_req(C) from authoritative deployment policy. The policy can depend on act class, data category, workload, resource, destination, purpose, tenant, or other application context.

Establish Current JEC Required JEC dimensions are collected from trusted sources appropriate to the assurance profile. No single evidence source is assumed to be universally authoritative.

Bind JEC to Workload, Sink, and Generation Evidence SHOULD identify the workload, sink/effectuation domain, generation, and other scope necessary to prevent cross-context substitution.

Remain Non-Effective Successful policy calculation or JEC collection does not itself create the consequence. C remains non-effective until the Finality Sink performs the current check.

Verify and Commit at the Finality Sink The Finality Sink observes or reconstructs the exact effect, verifies the current JEC and generation, evaluates J_req(C), verifies the consequence path, and couples successful evaluation to protected commit.

Architecture and Evidence Flow Diagrams

Illustrative Pseudocode The following pseudocode is non-normative. It separates policy resolution, required-dimension selection, evidence acquisition, assurance checking, context consistency, multi-source corroboration, JEC assembly, transition handling, path coverage, multi-hop propagation, protected finalization, emergency-profile selection, and crash-safe recovery.

Resolve the Jurisdiction Policy function resolve_jurisdiction_policy(candidate): C = canonical_security_relevant_act(candidate) P = protected_policy_lookup( act_class=C.operation, data_class=C.data_class, resource=C.resource, tenant=C.tenant, destination=C.destination) if !verify_policy_integrity(P): reject("invalid jurisdiction policy") if P.generation != current_policy_generation(P.id): return RELOAD_POLICY if P.undefined_unknown_handling: reject("jurisdiction policy lacks UNKNOWN semantics") return P

Select Required JEC Dimensions function required_dimensions(candidate, policy): dims = set(policy.base_required_dimensions) for conditional in policy.conditional_rules: if conditional.predicate(candidate): dims.add_all(conditional.required_dimensions) return dims

Collect Evidence for Each Required Dimension function collect_dimension_evidence(candidate, sink, policy): E = {} for d in required_dimensions(candidate, policy): sources = policy.authoritative_sources[d] E[d] = [] for source in sources: evidence = fetch_or_observe_context_evidence( dimension=d, source=source, candidate=candidate, sink=sink) if evidence != NONE: E[d].append(evidence) return E

Verify One Dimension's Evidence function verify_dimension_evidence( dimension, candidate, sink, policy, evidence_list): valid = [] for e in evidence_list: if !verify_integrity(e): continue if !issuer_trusted_for_dimension( e.issuer, dimension, policy): continue if !scope_applies(e, candidate, sink): continue if !fresh_enough( e, policy.freshness_bound[dimension]): continue if !generation_current(e): continue if !assurance_satisfies( e.assurance_class, policy.min_assurance[dimension]): continue if evidence_superseded(e): continue valid.append(e) if !policy.corroboration_rule[dimension].satisfied_by(valid): return DimensionResult( state=UNKNOWN, reason="insufficient corroborated evidence") value = derive_dimension_value(valid) if contradictory_values(valid): return DimensionResult( state=CONFLICTING, reason="trusted sources disagree") if !policy.value_allowed(dimension, value): return DimensionResult( state=KNOWN_DENIED, value=value) return DimensionResult( state=KNOWN_ALLOWED, value=value, evidence=valid)

Assemble the Current JEC function assemble_current_jec(candidate, sink): policy = resolve_jurisdiction_policy(candidate) evidence = collect_dimension_evidence( candidate, sink, policy) X = {} for d in required_dimensions(candidate, policy): X[d] = verify_dimension_evidence( d, candidate, sink, policy, evidence[d]) X.policy_generation = current_policy_generation(policy.id) X.topology_generation = current_topology_generation() return { policy: policy, context: X, evidence: evidence, generation_vector: current_jurisdiction_generation_vector( candidate, policy) }

Verify Cross-Dimension Context Consistency function verify_context_consistency( candidate, jec_bundle): all_evidence = flatten(jec_bundle.evidence) if !same_workload_context(all_evidence, candidate): reject("mixed workload evidence") if !same_transaction_or_act_context( all_evidence, candidate): reject("mixed candidate/transaction context") if !compatible_topology_generations(all_evidence): reject_or_revalidate("context generation mismatch") if contradictory_cross_dimension_claims(all_evidence): reject("inconsistent jurisdiction context") return VALID

Evaluate the Multi-Dimensional Jurisdiction Policy function evaluate_jurisdiction(candidate, sink): bundle = assemble_current_jec(candidate, sink) verify_context_consistency(candidate, bundle) for d in required_dimensions( candidate, bundle.policy): state = bundle.context[d].state if state == KNOWN_DENIED: reject("jurisdiction dimension denied", d) if state in { UNKNOWN, STALE, CONFLICTING, UNAVAILABLE }: return handle_unknown_dimension( candidate, bundle.policy, dimension=d, state=state) if !destination_rules_satisfied( candidate, bundle.context, bundle.policy): reject("destination policy violation") if !control_domain_rules_satisfied( candidate, bundle.context, bundle.policy): reject("control-domain policy violation") if !key_control_rules_satisfied( candidate, bundle.context, bundle.policy): reject("key-control policy violation") if !remote_access_rules_satisfied( candidate, bundle.context, bundle.policy): reject("remote-access policy violation") if !trust_rules_satisfied( candidate, bundle.context, bundle.policy): reject("trust-state policy violation") return VALID(bundle)

Handle UNKNOWN and Explicit Fallback Profiles function handle_unknown_dimension( candidate, policy, dimension, state): if policy.strict_prevention: reject_or_remain_non_effective( "required JEC dimension unavailable", dimension, state) fallback = policy.explicit_fallback_profile if fallback == NONE: reject() if !fallback.permits( candidate, dimension, state): reject() mark_assurance_profile( candidate, profile=fallback.id, guarantee="lower than strict jurisdiction prevention") return FALLBACK_PROFILE_SELECTED

Handle Migration, Failover, and Context Transitions function on_jurisdiction_context_change(change): affected = dimensions_affected_by(change) for d in affected: advance_protected_generation(d) pending = pending_candidates_depending_on(affected) for candidate in pending: old = candidate.bound_jec_context new = observe_new_context(candidate) if transition_equivalent_for_candidate( candidate, old, new): mark_revalidation_required(candidate) else: mark_non_effective(candidate) require_reauthorization(candidate)

Validate Context Equivalence function transition_equivalent_for_candidate( candidate, old_ctx, new_ctx): P = resolve_jurisdiction_policy(candidate) for d in required_dimensions(candidate, P): if !P.equivalence_rule[d]( old_ctx[d], new_ctx[d]): return FALSE if new_ctx[d].assurance < P.min_assurance[d]: return FALSE if !fresh_enough( new_ctx[d], P.freshness_bound[d]): return FALSE return TRUE

Verify Jurisdiction Enforcement Across Effectuation Paths function verify_jurisdiction_path_coverage( consequence, path_inventory, jurisdiction_policy): for path in paths_capable_of( consequence, path_inventory): if path.crosses_jurisdiction_finality_sink( jurisdiction_policy): continue if path.enforces_equivalent_jurisdiction_invariant: continue return CoverageFailure( reason="jurisdiction-bypass path", witness=path) return COVERAGE_VALID

Preserve JEC References Across Multi-Hop Systems function forward_candidate( candidate, next_workload, verified_jec): envelope = { candidate: candidate, act_digest: H(canonical_security_relevant_act(candidate)), jurisdiction_policy_id: verified_jec.policy.id, policy_generation: verified_jec.policy.generation, generation_vector: verified_jec.generation_vector, scoped_evidence_references: create_scoped_jec_references( verified_jec.evidence) } return authenticated_forward(next_workload, envelope) # Downstream components MUST NOT assume that forwarded # JEC references remain current. The Finality Sink # re-establishes current applicability before effect.

Protected Jurisdiction Finalization function finalize(candidate): begin_protected_finality_section() sink = current_finality_sink() if !candidate_integrity_valid(candidate): reject("invalid candidate") if !exact_observed_effect_matches(candidate): reject("exact-act mismatch") result = evaluate_jurisdiction(candidate, sink) if result.status != VALID: remain_non_effective() return REJECTED bundle = result.bundle observed_vector = bundle.generation_vector if verify_jurisdiction_path_coverage( candidate.protected_consequence, current_effectuation_path_inventory(), bundle.policy) != COVERAGE_VALID: reject("jurisdiction path coverage incomplete") atomic { current_vector = current_jurisdiction_generation_vector( candidate, bundle.policy) assert generation_vector_matches_or_is_compatible( observed_vector, current_vector, candidate, bundle.policy) assert current_context_still_satisfies( candidate, bundle.policy, sink) assert exact_observed_effect_still_matches(candidate) consume_once_if_required( candidate.execution_authority) commit_protected_effect(candidate) } return EFFECT_COMMITTED

Select an Emergency or Break-Glass Profile function select_emergency_profile(candidate, reason): P = resolve_jurisdiction_policy(candidate) E = P.emergency_profile if E == NONE: reject("no emergency cross-boundary policy") if !authorized_emergency_condition(reason): reject("emergency condition not authorized") if !required_break_glass_approvals(E): reject("break-glass approvals missing") record_distinct_assurance_profile( candidate, profile=E.id, reason=reason) return E

Crash-Safe Recovery function recover(candidate_id): state = protected_commit_state(candidate_id) if state == EFFECTIVE: return DO_NOT_REPLAY if state == COMMITTING: outcome = resolve_atomic_commit(candidate_id) if outcome == EFFECT_COMMITTED: return DO_NOT_REPLAY return REVALIDATE_CURRENT_JEC_AND_PATHS if state == PENDING: return REVALIDATE_CURRENT_JEC_AND_PATHS return FAIL_CLOSED

Generate a Reviewable Jurisdiction Failure Explanation function explain_jurisdiction_failure(result): return { failed_dimensions: result.denied_or_unknown_dimensions, evidence_failures: result.invalid_or_stale_evidence, assurance_failures: result.below_required_assurance, conflicting_sources: result.conflicting_sources, generation_changes: result.changed_generations, path_witness: result.jurisdiction_bypass_path_if_any, policy_id: result.policy.id }

Multi-Hop and WIMSE Composition WIMSE can identify workloads and carry security context through multi-system chains. Jurisdiction-bound finality can use that identity to bind JEC evidence to the correct workload while leaving WIMSE credential semantics unchanged.

Jurisdiction context across a multi-hop workload chain Workload A (J17) | | workload identity + transaction/security context v Workload B (J17) | | queue / async boundary v Worker C (J18 after failover) | v +-------------------------+ | FINALITY SINK | | identify Worker C | | establish CURRENT JEC | | compare to J_req(C) | +------------+------------+ | v allow / reject The final sink does not assume that a context label forwarded by Workload A remains true after the chain moves.

Workload identity can remain stable while jurisdiction context changes WIMSE workload identity: workload://tenant/service-A | | remains stable v +---------------+ | Workload W | +-------+-------+ | +--------+---------+ | | v v Region J17 Region J18 Operator A Operator B KeyDomain K1 KeyDomain K2 Stable workload identity does not imply stable sovereign context.

RATS-Based Jurisdiction Context RATS can provide high-assurance technical evidence for selected JEC dimensions, such as platform identity, workload state, security configuration, or profile-defined claims. Attestation Results may therefore be one input to JEC.

Attestation as a JEC input, not a legal conclusion Attester | Evidence v Verifier | Attestation Result: platform / workload / profile-defined claims | v +-----------------------+ | Jurisdiction Policy | | interprets technical | | claims for J_req(C) | +-----------+-----------+ | v FINALITY SINK RATS supplies technical trust evidence. Application policy decides whether that evidence satisfies J_req(C).

RATS evidence can cover only the dimensions it actually attests Attestation Result may establish: platform identity software measurement TEE / Realm state profile-defined region claim But policy may also require: operator control domain key-control domain destination remote-access state Therefore: trusted platform evidence + separate authoritative context evidence = complete JEC only if all required dimensions are covered.

SCITT-Based Policy and Configuration Evidence SCITT can protect signed jurisdiction-policy manifests, configuration claims, sovereign- domain statements, or receipts proving registration of those statements. This can improve provenance and accountability for JEC inputs. A SCITT Receipt does not by itself establish that the currently observed effectuation context satisfies the signed policy; the Finality Sink still evaluates current applicability.

Alternate-Path Resistance Jurisdiction enforcement at one API or gateway is insufficient when another route can produce the same consequence. A prevention profile therefore composes directly with consequence-path completeness.

Jurisdiction enforcement bypass through an alternate path Normal EU-controlled path: C --> JEC check --> Finality Sink --> K | | protected Alternate path: admin / DR / replication / global API | +-----------------------> K If the alternate path can produce K without equivalent JEC enforcement, the deployment cannot claim consequence-wide jurisdiction prevention.

Jurisdiction-safe normal path with unsafe cross-border bypass Normal path: C -> EU workload -> JEC check -> Finality Sink -> K ^ | jurisdiction enforced Alternate path: C -> recovery queue -> global worker -------------> K If the global worker can produce K without equivalent JEC enforcement, the deployment cannot claim consequence-wide jurisdiction prevention.

Attack Analysis

Forged or Advisory Region Label An application supplies "region=EU" from an untrusted configuration field. A high-assurance profile rejects it unless the policy explicitly allows that source.

Stale Jurisdiction Evidence A valid J17 statement is replayed after migration to J18. Generation/freshness checking rejects or revalidates the evidence.

Disaster-Recovery Failover The primary sovereign region is unavailable and the platform fails over to a global region. Availability does not silently override a prevention profile unless policy explicitly defines such a lower-assurance fallback.

Destination Substitution Processing remains in an allowed region, but the output destination changes to a disallowed recipient/domain. Destination binding fails.

Remote Administration Outside Policy Data and workload remain in the allowed region while a remote control path that policy forbids becomes active. An operational-sovereignty profile treats remote-access context as load-bearing.

Key-Control Change Workload location is unchanged but key custody moves to a disallowed control domain. Where key control is part of J_req(C), jurisdiction applicability fails.

Cross-Region Queue or Worker Authorization occurs in J17, but an asynchronous worker in J18 performs the actual consequence. The worker/final sink establishes current JEC rather than inheriting the producer's region assumption.

Alternate Path Around Jurisdiction Enforcement A protected regional API is bypassed through an administrative, recovery, replication, or direct-storage path. Prevention fails unless the alternate path enforces an equivalent invariant.

High-Assurance Enforcement

Protected JEC assembly from independent evidence sources +--------------------+ | Policy Authority | +---------+----------+ | v +-------------------+ | Protected AFB/JFS | +----+----+----+----+ | | | +----------+ | +-----------+ v v v Attestation Sovereign/Region Key-Control Verifier Authority Authority \ | / \ | / +-------------+--------------+ | v CURRENT JEC | v effect / reject

Deployment Patterns

Single Sovereign Region A bounded deployment can make one region or sovereign environment the only path to the consequence. JEC primarily verifies that no migration or bypass has changed that fact.

Multi-Region with Policy-Constrained Failover Several regions can be permitted under the same policy. Failover is allowed only among contexts satisfying J_req(C), and generation changes trigger revalidation.

Sovereign plus Global Cloud A deployment can use both sovereign and global environments while marking only selected Candidate Acts as jurisdiction-restricted. Unrestricted acts can take lower-cost paths; restricted acts require JEC finality.

Hybrid or Edge Deployment Edge sites can provide local context evidence while a central policy authority defines approved sovereign groups or control domains.

Performance and Availability Jurisdiction-policy resolution, topology appraisal, and attestation can occur on a cold path, while the hot path verifies protected generations, scoped evidence, destination, and current local JEC. Synchronous remote attestation or legal-policy service calls on every operation are not required by this architecture. Protected cached evidence, local generation state, pre-authorized region sets, or mirrored policy roots can reduce latency when their freshness and rollback semantics are explicit. Fail-closed jurisdiction enforcement creates availability tradeoffs during region outage. A deployment MAY define emergency or lower-assurance failover policy, but it MUST NOT label a fail-open global fallback as equivalent to the strict prevention profile.

Relationship to OAuth OAuth RAR can carry fine-grained jurisdiction-sensitive authorization details and Resource Indicators can identify the intended protected resource . This document does not require new OAuth semantics. The deployment question is whether the effectuation boundary re-establishes that those constraints still apply after the workload and downstream processing path have evolved.

Relationship to WIMSE WIMSE is directly relevant to identifying workloads and preserving security context across multi-system environments . A jurisdiction profile could use WIMSE identities as one dimension of JEC without defining a competing credential format. A useful community question is whether JEC belongs as a WIMSE security-context profile or should remain application-specific policy.

Relationship to RATS RATS provides a natural evidence architecture when jurisdiction policy depends on trusted platform/workload/configuration state . This draft does not add legal meaning to attestation claims; it treats them as technical inputs to application policy.

Relationship to SCITT SCITT can protect jurisdiction policy, signed configuration, evidence provenance, and transparency records . It is complementary to effectuation-time evaluation and need not be on every hot path.

Industrial Relevance and Sovereign-Cloud Alignment

Government and Sovereign Cloud Public-sector and sovereignty-sensitive workloads often distinguish ordinary cloud availability from permitted sovereign operating contexts. JEC provides a way to express the effectuation-time technical invariant without assuming one vendor model.

AI and Confidential Inference Model weights, prompts, retrieval data, KV caches, and generated outputs can have different jurisdiction policies. A final output-release sink can verify the current workload, region, destination, and trust context rather than assuming that inference started in the correct location.

Financial, Payment, and CBDC Systems Cross-border transactions may have technical policy constraints on processing, settlement, key custody, or destination. The architecture can enforce such machine-readable policies without deciding regulatory jurisdiction.

Telecom and Critical Infrastructure Distributed control functions, network-management operations, and critical commands can require sovereign processing or operator-control boundaries. The Finality Sink can evaluate those requirements at the actual control-effect boundary.

Complementary Industrial Alignment

Microsoft EU Data Boundary Microsoft documents the EU Data Boundary and service-specific continuing transfers, including scenarios involving remote access and operational requirements . This is relevant because it demonstrates that data-boundary semantics are richer than a simple storage-region flag. The reference is complementary only. This document does not claim that Microsoft's controls lack execution-time enforcement or that any Microsoft service is non-compliant.

AWS European Sovereign Cloud AWS announced general availability of the European Sovereign Cloud in January 2026 and describes European sovereignty requirements including data residency, operational control, and governance independence . The architecture can treat a sovereign-cloud identity, control plane, region, and related protected metadata as JEC inputs where a deployment chooses to do so. No deficiency is asserted.

Google Cloud Sovereign Controls by Partners Google documents partner-operated sovereignty controls including data residency, external key management, and local supervision . These map naturally to distinct JEC dimensions and illustrate why sovereignty can be multi-dimensional.

NVIDIA Attestation and Arm CCA NVIDIA documents GPU/NVSwitch attestation, and Arm CCA provides isolated Realms and attestation capabilities . These mechanisms can provide trusted compute-state inputs or host protected enforcement. Neither is described as a legal-jurisdiction oracle.

Non-Endorsement and Non-Criticism Named companies and products are included only as documented technical alignment or integration examples. This document does not assert vulnerability, deficiency, non-conformance, affiliation, endorsement, or a requirement that any named product adopt this architecture.

Required Classes of Test Vectors A concrete profile or implementation SHOULD test at least:

C authorized and effected under the same permitted current JEC: succeed;
C authorized under J17, then processing moves to disallowed J18: reject/revalidate;
processing moves from one allowed region to another allowed region under same policy: succeed after required generation handling;
stale J17 context evidence replayed after migration: reject;
untrusted application region label presented as authoritative evidence: reject;
storage in permitted region but processing outside permitted region where processing is load-bearing: reject;
processing permitted but destination disallowed: reject;
processing permitted but operator/control domain disallowed: reject;
processing permitted but key-control domain disallowed: reject;
remote administrative state changes to a prohibited mode: reject/revalidate;
attestation valid but missing a required jurisdiction dimension: JEC_UNKNOWN or reject;
failover into explicitly permitted lower-assurance emergency profile: label and enforce that profile;
global fail-open fallback under strict prevention profile: test failure;
queue producer in allowed region, worker in disallowed region: reject at final worker/sink;
alternate admin/DR/direct-storage path bypasses JEC check: prevention profile fails;
SCITT receipt valid but current context does not satisfy signed policy: reject;
policy generation rolls back: reject;
context evidence from another tenant/workload reused: reject;
audit record created only after cross-border effect: classify as audit, not prevention.

Implementations SHOULD also test mixed-assurance and inconsistent-context cases: correct processing-region value from an under-assured source; valid region evidence for workload W1 combined with key-control evidence for W2; two trusted sources that disagree; migration between two policy-equivalent regions; migration to a non-equivalent operator/key domain; remote-access state change after verification; topology change that introduces a cross-border bypass; emergency profile activation; and crash recovery after JEC verification but before protected commit.

Questions to the IETF Community Criticism, corrections, counterexamples, operational experience, prior art, and evidence that existing standards already provide the full property are explicitly invited. Recommendations to narrow, merge, or stop the work are useful outcomes.

Is jurisdiction-bound execution finality a useful separate abstraction, or is it fully expressible using existing authorization and attestation patterns?
Can OAuth RAR already express all useful jurisdiction constraints, making the remaining problem purely deployment-specific?
Should jurisdiction context be represented as authorization metadata, WIMSE security context, attestation claims, or application policy?
Which jurisdiction-relevant facts can be established technically without making legal conclusions?
Is physical processing location sufficient for any useful profile, or must operational-control, key-control, destination, and remote-access dimensions also be represented?
How should deployments distinguish data residency, processing sovereignty, and operational sovereignty?
What evidence source can authoritatively establish processing region when the host operating system is in the adversary model?
Can RATS Attestation Results carry enough trusted location/control-domain evidence for a high-assurance jurisdiction profile?
Which events should advance jurisdiction generation: migration, failover, DR activation, region change, operator change, key-control change, destination change, or remote-access change?
How should jurisdiction context remain valid across WIMSE multi-hop and asynchronous chains?
Can jurisdiction context safely be portable, or should the final sink re-establish it locally?
Is sink/audience binding necessary to prevent cross-region or cross-tenant reuse of otherwise valid evidence?
How should remote administrative access be represented when it is part of sovereignty policy?
How should emergency or break-glass cross-border operations be represented without silently weakening the normal profile?
Is GeoIP ever sufficient beyond a low-assurance advisory profile?
What is the proper relationship between SCITT transparency evidence and effectuation-time jurisdiction enforcement?
Which sovereign-cloud or industrial control systems already provide the full proposed invariant in concrete deployments?
Would a standard JEC token improve interoperability, or should the work remain architecture/BCP only?
What privacy risks arise from exposing exact region, sovereign domain, operator, key-control, or jurisdiction claims?
What counterexample would show that this architecture is unnecessary or incorrectly scoped?
Which venue is best for further discussion: WIMSE, RATS, OAuth, SCITT, DISPATCH, SAAG, or another group?

Potential IETF Discussion Venues

WIMSE WIMSE is highly relevant because it addresses workload identity in multi-system environments and could provide identity/security-context inputs to JEC .

RATS RATS is relevant where jurisdiction assurance depends on trusted platform, workload, or configuration evidence .

OAuth OAuth is relevant where jurisdiction policy is part of delegated authorization or Rich Authorization Requests .

SCITT SCITT is relevant to signed jurisdiction-policy/configuration statements and transparency .

DISPATCH DISPATCH can be useful if the work spans ART/security/cloud architecture without a clear single Working Group owner.

SAAG SAAG is useful for broad Security Area review and criticism. It is not a Working Group that adopts documents.

No Presumed Home This document does not claim that any named group should adopt the work. Overlap review and falsification of the residual gap should come before routing.

Relationship to Other Execution-Finality Internet-Drafts The execution-finality family addresses different failure surfaces. This document isolates jurisdiction continuity at effectuation.

The protocol-layer draft defines the broad Candidate Act, Non-Effective State, protected validation, Execution Handle, and Finality Sink architecture.
The agentic draft applies execution finality to high-risk AI tool dispatch.
The hardware-enforced draft focuses on hardware-rooted finality for agentic and industrial systems.
The RATS/attestation-bound draft connects trusted workload state to exact consequential authority.
The state/policy-continuity draft asks whether the earlier decision basis remains applicable.
The finality-bound-revocation draft asks whether withdrawn authority survives to commit.
The consequence-path-completeness draft asks whether the consequence can bypass enforcement.
The third-party-decision-binding draft asks whether a required external authority actually issued the applicable decision.
The purpose-execution-finality draft addresses purpose/capability laundering and cross-domain reuse.
The AI-interoperability draft applies bounded finality to third-party AI/device interoperability.

State continuity: Is the authorization basis still applicable? Revocation finality: Has authority been withdrawn? Consequence-path completeness: Can the effect avoid enforcement? Third-party decision binding: Did the required external authority issue the applicable decision? Jurisdiction-bound finality: Is the exact act becoming effective under the CURRENT authorized jurisdiction / sovereignty / control context? Related documents include , , , , , , , , , and .

Public Implementations and Companion Engineering Material Public execution-finality repositories provide architectural and implementation background . They are not represented here as complete implementations of the multi-dimensional JEC profile. The architecture repository discusses jurisdiction as one possible finality predicate, and the hardened challenge-bound implementation demonstrates exact-effect, epoch, policy, revocation, and sink binding. A future jurisdiction-specific implementation should not be claimed until trusted JEC evidence, migration/failover behavior, policy generations, and cross-context test vectors are actually implemented.

Security Considerations A jurisdiction prevention claim is only as strong as the Jurisdiction Policy, the evidence used to construct JEC, the currentness model, and the non-bypassability of the Finality Sink.

False or Advisory Jurisdiction Label Application labels and configuration annotations are not trusted evidence unless the profile explicitly designates their authority and protection.

Stale Region Evidence Authentic old region evidence must not survive migration, failover, or other context change when the evidence no longer describes the current effectuation environment.

Workload Migration Live migration or rescheduling can change processing, control, or key domains without changing workload identity. Security-relevant migration must trigger revalidation.

Failover and Disaster Recovery DR routes are part of the jurisdiction threat surface. Strict profiles must pre-authorize their context or remain non-effective when failover leaves the permitted domain.

Remote Administration Physical data location can remain unchanged while a remote administration path violates an operational-sovereignty policy.

Control-Plane/Data-Plane Mismatch A permitted data-plane region does not guarantee that management/control operations satisfy the same sovereignty rule.

Storage Versus Processing Confusion A storage-residency proof MUST NOT be interpreted as a processing or disclosure proof unless the policy defines that equivalence.

Key-Control Mismatch Where sovereign key custody is load-bearing, key-control changes must be part of JEC and jurisdiction generation.

Destination or Recipient Change Processing can be permitted while final disclosure is not. Destination-sensitive acts require exact destination binding.

GeoIP Spoofing and Inaccuracy GeoIP is generally an inference from network data, not cryptographic proof of processing jurisdiction. It can be used only at an assurance level consistent with that limitation.

Cloud-Region Metadata Forgery When the host is untrusted, ordinary instance metadata or environment variables cannot be assumed authoritative without protected provenance.

Compromised Scheduler or Orchestrator A scheduler can move a workload after authorization. High-assurance profiles must detect or make such moves generation-relevant.

Compromised Host Host-controlled JEC inputs are insufficient when the host is in the adversary model. Independent or attested sources are required for load-bearing dimensions.

Compromised Jurisdiction Evidence Source A trusted evidence source can lie if compromised. High-assurance deployments can use independent sources, threshold rules, protected policy, or narrower trust scopes.

Valid Attestation but Insufficient Semantics A valid Attestation Result proves only the claims it actually carries and appraises. It must not be stretched into jurisdiction facts absent from the evidence/profile.

Jurisdiction-Policy Rollback An attacker may restore an earlier permissive policy. Protected generations, signed policy roots, or monotonic state are required where rollback is in the threat model.

Context-Evidence Replay Evidence from a prior region, tenant, workload, or generation must not be reusable outside its applicability semantics.

Cross-Tenant or Cross-Workload Reuse JEC evidence should bind to workload/tenant where cross-context substitution could alter authorization.

Multi-Hop Context Loss Downstream workloads must not assume jurisdiction context remained unchanged merely because an upstream component sent a valid identity or context reference.

Alternate Effectuation Path Admin, DR, replication, storage, device, or global API paths can bypass otherwise correct JEC enforcement. Consequence-path completeness is required for a prevention claim.

Replication and Direct Storage Paths Replication promotion or direct storage mutation can create effects outside the normal application route and must be modeled where jurisdiction-sensitive.

Queue or Worker Relocation Asynchronous systems can authorize in one context and execute in another. The final worker/sink must establish current JEC.

Service-Mesh or Routing Change Routing changes can alter processing context without changing application-level endpoints. Load-bearing route changes must advance or invalidate jurisdiction state.

Emergency and Break-Glass Paths Emergency cross-border operation can be modeled as a separate explicit profile with stronger human/technical controls. It must not be an undocumented bypass.

Jurisdiction-Policy Authority Compromise If the authoritative policy source is compromised, it can redefine permitted context. Separation of duties, signed policy, threshold approval, or governance controls may be appropriate.

Legal or Policy Misconfiguration The mechanism enforces the supplied policy. An incorrect legal interpretation encoded into policy can be enforced perfectly and still be legally wrong.

Fail-Open on Unknown Context Unknown JEC MUST NOT silently become permitted for a strict prevention profile. Lower-assurance fallback must be explicit.

Denial of Service Attackers can disrupt attestation, context sources, region metadata, or policy services to force JEC_UNKNOWN. Availability engineering must not silently weaken the strict invariant.

Jurisdiction and Location Privacy Exact processing region, operator, key-control domain, or site identity can be sensitive. Evidence should disclose only the minimum needed for policy evaluation.

Correlation Stable JEC identifiers can allow cross-service or cross-border correlation. Scoped identifiers or local verification can reduce this risk.

Physical-Site Falsification Physical location cannot be cryptographically inferred without an evidence architecture that actually supports that claim. Profiles must state how physical-site evidence is established.

Topology Drift New services, networks, routes, regions, or failover configurations can alter effectuation context. Jurisdiction generations must track security-relevant drift.

Crash Consistency A crash between JEC verification and protected commit must not allow replay under stale context. Transactional or idempotent recovery may be required.

Audit-Only Enforcement Logging a prohibited cross-border effect after completion does not satisfy the prevention invariant.

Technical Enforcement Is Not Legal Advice The document specifies enforcement of machine-readable policy. It does not establish that a policy is legally sufficient, identify the applicable regulator, or determine the legal meaning of "jurisdiction", "sovereignty", "residency", or related terms in a particular legal system.

Privacy Considerations JEC can expose sensitive information about physical/processing region, operator, sovereign control, key custody, infrastructure topology, remote-access status, and destination. Profiles SHOULD disclose only the predicates needed to make the final decision. Techniques such as policy-class membership claims, scoped digests, local protected verification, selective disclosure, pairwise identifiers, and short-lived evidence can reduce unnecessary location and topology exposure.

Criticism, Corrections, and Review Invited This document is intentionally presented for adversarial review. Reviewers are invited to identify legal/technical boundary mistakes, existing standards or products that already provide the full invariant, jurisdiction dimensions that are technically unmeasurable, profiles that are too broad, weak evidence assumptions, bypass paths, privacy costs, terminology conflicts, and reasons that the work should be narrowed, merged, or stopped. Particularly useful feedback is a concrete deployment in which existing OAuth, WIMSE, RATS, SCITT, sovereign-cloud, workload-identity, or proprietary controls already guarantee that the exact Candidate Act cannot become effective outside the current authorized jurisdiction/governance context. Such evidence should reduce the scope of this proposal, not be ignored.

IANA Considerations This document has no IANA actions.

Conclusion Identity, authorization, attestation, residency, and sovereign-cloud controls solve indispensable parts of cross-border security. The narrow question addressed here is whether the jurisdiction-sensitive assumptions that made a Candidate Act permissible are still true at the moment the act becomes externally effective. AUTHORIZED HERE != AUTHORIZED EVERYWHERE Valid under J17 != Automatically valid under J18 For strict jurisdiction finality: Current JEC satisfies J_req(C) OR Candidate remains non-effective. Existing systems that already provide that relationship already satisfy the core invariant. The purpose of this draft is to make the relationship explicit, testable, composable with existing standards, and open to correction by the community. A useful implementation should be able to explain not merely that "jurisdiction failed" but which required dimension failed, which source established or failed to establish it, whether the failure was value, assurance, freshness, corroboration, cross-context consistency, generation drift, migration equivalence, or path coverage, and which protected policy generation governed the decision.