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

1.1. 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.¶

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.¶

1.2. Existing Mechanisms Already Address Important Parts

OAuth Rich Authorization Requests can carry fine-grained authorization data [RFC9396]. 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 [RFC8707]. JWT can carry signed application-specific claims such as issuer, audience, and private context claims [RFC7519].¶

WIMSE addresses workload identity and security context in multi-system environments [WIMSE-ARCH]. RATS supplies a standardized architecture for Evidence, Verifiers, Attestation Results, Reference Values, and Relying Party decisions [RFC9334]. SCITT supplies signed statements, transparency, registration, and verifiable receipts [RFC9943].¶

Industrial platforms likewise already implement substantial sovereignty controls. Microsoft documents the EU Data Boundary and continuing-transfer cases [MS-EUDB] [MS-EUDB-TRANSFERS]. AWS documents the European Sovereign Cloud as an independent cloud environment designed for European sovereignty requirements [AWS-ESC]. Google Cloud documents partner-operated Sovereign Controls including data-residency controls, external key management, and local supervision [GOOGLE-SOV].¶

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.¶

1.3. 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 [MS-EUDB] [MS-EUDB-TRANSFERS]. 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.¶

1.4. 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.¶

5.1. 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.¶

5.2. Data Residency Is Not Complete Sovereignty

                 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.¶

5.3. 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.¶

5.4. 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.¶

5.5. 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.¶

6.1. 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.¶

6.2. 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.¶

6.3. 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.¶

6.4. 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.¶

6.5. 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.¶

8.1. OAuth Rich Authorization Requests

RFC 9396 defines `authorization_details` for fine-grained authorization [RFC9396]. 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.¶

8.2. OAuth Resource Indicators

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

8.3. JWT and Application Claims

JWT defines signed claims including issuer, subject, audience, and extensible application claims [RFC7519]. 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.¶

8.4. WIMSE

The WIMSE architecture addresses workload identity in multi-system environments [WIMSE-ARCH]. 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.¶

8.5. RATS

RATS supplies technical Evidence and Attestation Results [RFC9334]. 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.¶

8.6. SCITT

SCITT provides signed statements, transparency, and receipts [RFC9943]. 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.¶

8.7. Cloud Sovereignty and Data-Boundary Controls

Microsoft, AWS, and Google Cloud provide concrete controls and commitments addressing residency, sovereignty, operational control, or partner supervision [MS-EUDB] [AWS-ESC] [GOOGLE-SOV]. 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.¶

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.

8.8. Comparison Summary

8.9. 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.¶

9.1. 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

9.2. 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.¶

9.3. 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.¶

11.1. Typed Jurisdiction Dimensions

A 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

11.2. 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.¶

11.3. 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]

11.4. Evidence-Assurance Ordering

Assurance 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.¶

11.5. 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.¶

12.1. Data-Residency Profile

ALLOW if:
    storage_region IN ApprovedStorageRegions

12.2. Processing-Sovereignty Profile

ALLOW if:
    storage_region IN ApprovedStorageRegions
AND processing_region IN ApprovedProcessingRegions

12.3. 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

12.4. 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

12.5. 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.¶

12.6. 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)

12.7. 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.¶

12.8. Jurisdiction-Context Equivalence

Two 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.¶

13.1. 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.¶

13.2. 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)

13.3. 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)

13.4. Cross-Dimension Context Consistency

Individually 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)

13.5. 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)

13.6. 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.¶

13.7. 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.

13.8. 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.

13.9. 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

13.10. 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.

13.11. 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.

13.12. 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)

13.13. Expanded Bounded Prevention Proof

Assume: (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.¶

19.1. 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.¶

19.2. 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.¶

19.3. 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.¶

19.4. 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.¶

19.5. 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.¶

19.6. Architecture and Evidence Flow Diagrams

                       +-------------------------+
                       | Jurisdiction Policy     |
                       | Authority               |
                       +------------+------------+
                                    |
                                  J_req(C)
                                    |
                                    v
+-------------+        +-------------------------+
| Candidate C |------->| CURRENT JEC             |
+------+------+        | workload identity       |
       |               | processing/storage     |
       |               | destination            |
       |               | operator/control       |
       |               | key control            |
       |               | remote-access state    |
       |               | attested trust state   |
       |               +------------+------------+
       |                            |
       +----------------------------+
                    |
                    v
          +-------------------------+
          | FINALITY SINK           |
          | exact C                 |
          | current JEC             |
          | current generation      |
          | J_req(C) satisfied?     |
          | path authorized?        |
          +------------+------------+
                       |
                  pass | fail
             +---------+---------+
             |                   |
             v                   v
      PROTECTED COMMIT      NON-EFFECTIVE
             |
             v
           EFFECT K

                     +----------------------+
                     | Jurisdiction Policy  |
                     | Authority            |
                     +----------+-----------+
                                |
                              J_req(C)
                                |
                                v
+--------------+   +------------------------------+
| Candidate C  |-->| Required JEC dimensions      |
+--------------+   +---+----+----+----+-----------+
                       |    |    |    |
             +---------+    |    |    +----------+
             v              v    v               v
        Attestation      Region Operator     Key-Control
          Source           Source Source       Source
             \              |    |             /
              +-------------+----+------------+
                            |
                            v
                  +----------------------+
                  | JEC consistency +    |
                  | assurance/corrobor.  |
                  +----------+-----------+
                             |
                             v
                  +----------------------+
                  | Finality Sink        |
                  | exact act            |
                  | current vector       |
                  | path coverage        |
                  | protected commit     |
                  +----------+-----------+
                             |
                             v
                         EFFECT / DENY

20.1. 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

20.2. 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

20.3. 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

20.4. 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)

20.5. 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)
    }

20.6. 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

20.7. 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)

20.8. 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

20.9. 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)

20.10. 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

20.11. 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

20.12. 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.

20.13. 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

20.14. 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

20.15. 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

20.16. 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
    }

25.1. 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.¶

25.2. Stale Jurisdiction Evidence

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

25.3. 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.¶

25.4. Destination Substitution

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

25.5. 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.¶

25.6. 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.¶

25.7. 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.¶

25.8. 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.¶

27.1. 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.¶

27.2. 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.¶

27.3. 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.¶

27.4. Hybrid or Edge Deployment

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

33.1. 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.¶

33.2. 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.¶

33.3. 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.¶

33.4. 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.¶

34.1. Microsoft EU Data Boundary

Microsoft documents the EU Data Boundary and service-specific continuing transfers, including scenarios involving remote access and operational requirements [MS-EUDB] [MS-EUDB-TRANSFERS]. 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.¶

34.2. 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 [AWS-ESC].¶

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.¶

34.3. Google Cloud Sovereign Controls by Partners

Google documents partner-operated sovereignty controls including data residency, external key management, and local supervision [GOOGLE-SOV]. These map naturally to distinct JEC dimensions and illustrate why sovereignty can be multi-dimensional.¶

34.4. NVIDIA Attestation and Arm CCA

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

34.5. 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.¶

37.1. WIMSE

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

37.2. RATS

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

37.3. OAuth

OAuth is relevant where jurisdiction policy is part of delegated authorization or Rich Authorization Requests [RFC9396].¶

37.4. SCITT

SCITT is relevant to signed jurisdiction-policy/configuration statements and transparency [RFC9943].¶

37.5. DISPATCH

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

37.6. SAAG

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

37.7. 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.¶

40.1. False or Advisory Jurisdiction Label

Application labels and configuration annotations are not trusted evidence unless the profile explicitly designates their authority and protection.¶

40.2. 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.¶

40.3. Workload Migration

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

40.4. 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.¶

40.5. Remote Administration

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

40.6. Control-Plane/Data-Plane Mismatch

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

40.7. Storage Versus Processing Confusion

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

40.8. Key-Control Mismatch

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

40.9. Destination or Recipient Change

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

40.10. 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.¶

40.11. Cloud-Region Metadata Forgery

When the host is untrusted, ordinary instance metadata or environment variables cannot be assumed authoritative without protected provenance.¶

40.12. Compromised Scheduler or Orchestrator

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

40.13. 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.¶

40.14. 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.¶

40.15. 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.¶

40.16. 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.¶

40.17. Context-Evidence Replay

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

40.18. Cross-Tenant or Cross-Workload Reuse

JEC evidence should bind to workload/tenant where cross-context substitution could alter authorization.¶

40.19. 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.¶

40.20. 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.¶

40.21. 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.¶

40.22. Queue or Worker Relocation

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

40.23. 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.¶

40.24. 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.¶

40.25. 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.¶

40.26. 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.¶

40.27. Fail-Open on Unknown Context

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

40.28. 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.¶

40.29. 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.¶

40.30. Correlation

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

40.31. 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.¶

40.32. Topology Drift

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

40.33. Crash Consistency

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

40.34. Audit-Only Enforcement

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

40.35. 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.¶