⬛ Architecture & Policy Analysis — For Discussion Purposes ⬛

Sovereign Digital Trade Infrastructure:
CUSMA Alignment, Cloud Architecture & the TPTN Design Case

An infrastructure design and policy analysis addressing cloud sovereignty, CUSMA trade-law risk, data classification, and applied architecture — using TPTN as the illustrative Canadian digital trade infrastructure model. TPTN is referenced here as a Canadian design-stage digital trade infrastructure model.

Audience: Government, regulatory, policy & advisory stakeholders Posture: Compatibility-first, standards-based Applied case: TPTN (design stage)

Prepared from an infrastructure design and policy implementation perspective for discussion purposes.

§ 01

Executive Explanation in Plain English

The Core Tension

Canada wants to build digital trade infrastructure that it controls — where sensitive trade records, encryption keys, audit logs, and governance decisions remain in Canadian hands. At the same time, Canada has signed CUSMA, Chapter 19 of which creates meaningful constraints on how governments can treat cross-border digital services and data flows.

The tension is not abstract. It arises whenever a Canadian government agency or quasi-public infrastructure operator must choose a cloud provider, decide where to store data, or impose a technical requirement on its vendors.

In the TPTN design approach, this tension is addressed not by avoiding foreign cloud providers, but by defining precisely which layers and data classes must remain under Canadian operational control — and building architecture around that boundary.

What the U.S. Side Is Worried About

The United States — whose major cloud providers (AWS, Microsoft Azure, Google Cloud) stand to lose revenue if Canada routes around them — is concerned that "sovereignty" requirements become a disguised form of market protectionism. From a U.S. trade-law perspective, the risk is:

Canada mandating that data be stored only with Canadian-headquartered companies
Canada prohibiting procurement of U.S. cloud services without technical justification
Canada imposing requirements so burdensome they effectively exclude U.S. providers from the market
Canada claiming "security" as a justification for what is, in substance, industrial policy favouring Canadian vendors

CUSMA Article 19.11 restricts data localization mandates that go beyond what is necessary for legitimate public policy objectives. Article 19.12 protects the free flow of cross-border data transfers. These are real constraints. Architectural decisions must be made with awareness of them.

What Canada Is Trying to Protect

Canada's concern is equally legitimate. The problem is not preference for domestic vendors — it is structural:

Foreign legal reach: Data stored in U.S.-provider infrastructure — even in a Canadian data centre — may be subject to compelled disclosure under instruments such as the U.S. CLOUD Act, which extends reach to data controlled by U.S. providers regardless of physical location. The specific application of this risk to any given architecture configuration is a legal question that warrants qualified counsel review; the architectural response is to ensure that no foreign provider controls the decryption capability.

Key control: If a U.S. provider manages encryption keys, that provider — and potentially its government — may have a path to the underlying data. "Data in Canada" is a weaker protection than it appears if the provider controls the decryption capability.

Operational sovereignty: If a critical trade infrastructure platform can be modified, throttled, or shut down by a foreign provider's decision or a foreign government order, Canada does not genuinely control its own trade infrastructure.

Audit integrity: If audit logs live inside the same foreign-controlled environment as transactions, those logs cannot function as genuinely independent evidentiary records.

Why the Answer Is Not "Ban U.S. Providers"

The distinction that matters throughout this document: the difference between restricting foreign providers by nationality — which is likely to create higher CUSMA challenge risk — and imposing neutral, objective control requirements that any provider must meet — which is a more defensible, procurement-safe, and standards-based approach. This distinction is the foundation of the design posture described here.

A blanket ban on U.S. cloud providers would likely create significant CUSMA challenge risk and would also be operationally counterproductive — these providers offer real capabilities that Canadian SMEs and infrastructure operators legitimately need.

The correct architecture does something more precise: it separates what a provider can host from what a provider can see or control. A Canadian operator can use AWS infrastructure to run application workloads — provided AWS never has access to plaintext sensitive data, never controls encryption keys, and never sits in the chain of custody for regulated trade records or cryptographic material.

This is not a workaround. It is architecturally sound, legally defensible in posture, and operationally coherent: any provider that satisfies Canada's neutral, objective security and control requirements may participate. No provider is excluded by nationality. But the requirements themselves are non-negotiable.

TPTN's design posture is compatibility-first. The architecture is designed to be interoperable with major cloud infrastructure and global trade systems — not to wall them off. The sovereignty position is defined by what TPTN controls, not by who TPTN excludes.

§ 02

High-Level Architecture Diagram

The diagram below shows the full system at a strategic level. Green zones represent Canadian-sovereign elements. Orange represents external provider infrastructure. Blue represents cross-border data flows and gateways. Purple represents encryption and key management controls.

Figure 1 — Strategic Architecture Overview (TPTN Design Model) FIG-01

╔═══════════════════════════════════════════════════════════════════════════════════════╗
║                          CANADA SOVEREIGN BOUNDARY                                    ║
║  ┌──────────────────────────────────────────────────────────────────────────────────┐ ║
║  │                     CANADIAN SME EXPORTER LAYER                                  │ ║
║  │  [Agri-food]  [Manufacturing]  [Tech/Services]  [Forestry]  [Aerospace]         │ ║
║  │        │              │               │               │           │              │ ║
║  └────────┴──────────────┴───────────────┴───────────────┴───────────┘              ║
║                                    │                                                  ║
║              ──────────────────────▼──────────────────────                           ║
║  ┌──────────────────────────────────────────────────────────────────────────────────┐ ║
║  │           TPTN APPLICATION / WORKFLOW LAYER              [CA-RESIDENT]           │ ║
║  │  • Trade document creation     • FTA usability engine                            │ ║
║  │  • eCMR / eB/L workflow        • Compliance pre-check                            │ ║
║  │  • Permit & license mgmt       • Multi-party workflow orchestration              │ ║
║  └──────────────────────────────────────────────────────────────────────────────────┘ ║
║                        │                      │                                        ║
║          ──────────────▼──────────   ──────────▼──────────────────────────           ║
║  ┌──────────────────────────────┐  ┌──────────────────────────────────────────────┐ ║
║  │  AI / ORCHESTRATION LAYER    │  │    TRUST / AUDIT / RECORD LAYER [CA-ONLY]    │ ║
║  │  [CA-resident compute]       │  │                                              │ ║
║  │  • Anomaly detection         │  │  ┌────────────────────────────────────────┐  │ ║
║  │  • Document classification   │  │  │  PORTABLE TRUST RECORD (PTR) STORE     │  │ ║
║  │  • Routing intelligence      │  │  │  • Electronic Transferable Records     │  │ ║
║  │  • Human review / override   │  │  │  • Audit-ready evidentiary anchors     │  │ ║
║  │  (governed operational       │  │  │  • Immutable audit log stream          │  │ ║
║  │   support, not chatbot)      │  │  │  • Chain-of-custody records            │  │ ║
║  └──────────────────────────────┘  │  └────────────────────────────────────────┘  │ ║
║                                     └──────────────────────────────────────────────┘ ║
║                                                   │                                   ║
║          ┌────────────────────────────────────────▼──────────────────────────────┐  ║
║          │       CANADIAN KEY MANAGEMENT / HSM CONTROL LAYER [CA-ONLY]           │  ║
║          │                                                                        │  ║
║          │  ┌──────────────┐   ┌─────────────┐   ┌────────────────────────┐     │  ║
║          │  │ HSM CLUSTER  │   │  KEY VAULT  │   │  POLICY ENGINE / RBAC  │     │  ║
║          │  │ (CA-resident)│   │  (Canada)   │   │  (who gets keys, when) │     │  ║
║          │  └──────────────┘   └─────────────┘   └────────────────────────┘     │  ║
║          │                                                                        │  ║
║          │  ══ CANADIAN OPERATORS HOLD ALL ROOT KEYS ═══════════════════════════ │  ║
║          │  ══ FOREIGN PROVIDERS: ZERO ACCESS TO KEY MATERIAL ════════════════   │  ║
║          └────────────────────────────────────────────────────────────────────────┘  ║
║                                                                                       ║
║          ┌────────────────────────────────────────────────────────────────────────┐  ║
║          │        POLICY / GOVERNANCE / COMPLIANCE CONTROLS [CA-ONLY]             │  ║
║          │  • Data classification engine    • Access control policy store         │  ║
║          │  • PIPEDA / CPPA alignment       • Breach detection & response         │  ║
║          │  • FTA rules of origin engine    • Regulatory reporting interface      │  ║
║          └────────────────────────────────────────────────────────────────────────┘  ║
╚═══════════════════════════════════════════════════════════════════════════════════════╝
                               │                           │
               ════════════════▼════════════════  ═════════▼══════════════════
               ║  CROSS-BORDER DATA EXCHANGE    ║  ║  EXTERNAL CLOUD INFRA  ║
               ║       GATEWAY LAYER            ║  ║    PROVIDER LAYER      ║
               ╠════════════════════════════════╣  ╠════════════════════════╣
               ║  • Selective disclosure         ║  ║  AWS / Azure / GCP      ║
               ║  • Minimum necessary data      ║  ║                         ║
               ║  • Encrypted transit only      ║  ║  CAN HOST:              ║
               ║  • Protocol normalization      ║  ║  ✓ Encrypted app compute║
               ║  • Per-transmission audit log  ║  ║  ✓ Non-sensitive traffic║
               ╚════════════════════════════════╝  ║  ✓ UI/UX delivery       ║
                          │          │              ║  ✓ Encrypted blob store  ║
          ─────────────────┴──   ─────┴──────       ║                         ║
          │                         │               ║  CANNOT ACCESS:         ║
  ────────▼──────────  ─────────────▼──────────     ║  ✗ Encryption keys      ║
  │ FOREIGN GOV /   │  │ BANKS / LOGISTICS /   │    ║  ✗ Audit log plaintext  ║
  │ CUSTOMS /       │  │ BROKERS / INSURERS /  │    ║  ✗ PTR records          ║
  │ SINGLE WINDOW   │  │ ASEAN COUNTERPARTIES  │    ║  ✗ Trade intelligence   ║
  └─────────────────┘  └───────────────────────┘    ║  ✗ Root cryptographic   ║
                                                     ║    material            ║
                                                     ╚════════════════════════╝
  LEGEND:
  ╔══╗ = Canadian Sovereign Zone (CA operator-controlled; no foreign provider plaintext access)
  ╠══╣ = Cross-border gateway (CA-controlled; selective disclosure; all transmissions logged)
  ║  ║ = External provider zone (can host encrypted workloads; cannot see sensitive data plaintext)
  ──── = Data flow (always encrypted in transit)
  ═══  = Trust boundary

Applied to TPTN: In the TPTN design model, this diagram defines the trust boundary not as a national border, but as a cryptographic and operational boundary. The external cloud provider layer can host encrypted application workloads. It cannot access encryption keys, audit logs, portable trust records, or any data classified as Sensitive Trade Intelligence or above. The boundary is defined by control — not geography.

§ 03

Technical Layered Architecture

Figure 2 — Layer-by-Layer Technical Architecture (TPTN Design Model) FIG-02

Layer 10 ┌──────────────────────────────────────────────────────────────────────┐
MONITOR  │  MONITORING / AUDIT / COMPLIANCE LAYER                              │
& AUDIT  │  • Real-time SIEM (Security Information & Event Management)         │
[CA-ONLY]│  • Immutable audit log stream (append-only, CA-resident)            │
         │  • Compliance policy evaluation engine                              │
         │  • Breach detection, alerting, forensics                            │
         │  Residency: CANADA ONLY  |  Foreign provider: NO plaintext access   │
         └──────────────────────────────────────────────────────────────────────┘
                │
Layer 09 ┌──────────────────────────────────────────────────────────────────────┐
INFRA    │  INFRASTRUCTURE LAYER                                                │
         │  • Canadian-resident sovereign core (HSM, key mgmt, audit, PTR)    │
         │  • External cloud provider compute (encrypted app workloads only)   │
         │  • Network segmentation: sovereign VPC ↔ provider VPC (encrypted)  │
         │  • Canada-resident control plane (even if data plane uses cloud)    │
         │  Residency: SPLIT — sovereign core CA-only; app compute: external   │
         │  Foreign provider: CAN host encrypted blobs; CANNOT see plaintext   │
         └──────────────────────────────────────────────────────────────────────┘
                │
Layer 08 ┌──────────────────────────────────────────────────────────────────────┐
ENCRYPT  │  ENCRYPTION & KEY MANAGEMENT LAYER  [CROWN JEWEL — CA-ONLY]         │
& KMS    │                                                                      │
         │  ┌────────────────────────────────────────────────────────────────┐ │
         │  │  HSM Cluster (FIPS 140-2 Level 3 minimum)                      │ │
         │  │  • Root CA / root key material — never leaves HSM              │ │
         │  │  • Key derivation for per-record, per-document encryption       │ │
         │  │  • Customer-managed keys (CMK) — CA operator controls          │ │
         │  └────────────────────────────────────────────────────────────────┘ │
         │  ┌────────────────────────────────────────────────────────────────┐ │
         │  │  Key Vault (CA-resident)                                        │ │
         │  │  • Wrapping keys for application-layer encryption               │ │
         │  │  • Envelope encryption architecture                             │ │
         │  │  • Audit log: every key access event recorded                   │ │
         │  └────────────────────────────────────────────────────────────────┘ │
         │  Residency: CANADA ONLY  |  Foreign provider: ZERO key access       │
         └──────────────────────────────────────────────────────────────────────┘
                │ encrypts all sensitive data before any external storage
Layer 07 ┌──────────────────────────────────────────────────────────────────────┐
DATA     │  DATA CLASSIFICATION LAYER                                           │
CLASS    │  • Classifies data as it enters the system                          │
         │  • Routes Class 5–8 data to sovereign core only                    │
         │  • Routes Class 1–3 data to allow (encrypted) external hosting     │
         │  • Applies data handling policy per classification tag              │
         │  Residency: CA-resident policy engine; tags travel with data        │
         └──────────────────────────────────────────────────────────────────────┘
                │
Layer 06 ┌──────────────────────────────────────────────────────────────────────┐
API /    │  INTEGRATION / API GATEWAY LAYER                                    │
GATEWAY  │  • Cross-border data exchange gateway (CA-controlled)               │
         │  • Protocol normalization (UN/CEFACT, WCO Data Model, ASEAN DEFA)  │
         │  • Selective disclosure: minimum necessary data per request         │
         │  • mTLS / token-based authentication for all external connections   │
         │  • Per-transmission audit log (timestamp, recipient, data scope)    │
         │  Residency: CA-resident gateway; transit: encrypted only            │
         └──────────────────────────────────────────────────────────────────────┘
                │ ←────────────────────────────────────── │
                ▼                                          ▼
   [Foreign Gov / Customs]                     [Banks / Logistics / Brokers]
   [ASEAN Single Window]                       [Insurance / Trade Finance]
Layer 05 ┌──────────────────────────────────────────────────────────────────────┐
RECORDS  │  RECORDS / TRUST LAYER  [CA-ONLY]                                   │
& TRUST  │                                                                      │
         │  ┌───────────────────────────────────────────────────────────────┐  │
         │  │  Portable Trust Record (PTR) Store                             │  │
         │  │  • Electronic Transferable Records (per UNCITRAL MLETR)       │  │
         │  │  • eB/L, eCMR, electronic warehouse receipts                  │  │
         │  │  • Cryptographic hash anchors (integrity verification)        │  │
         │  │  • Chain-of-custody events (who, when, what action)           │  │
         │  └───────────────────────────────────────────────────────────────┘  │
         │  ┌───────────────────────────────────────────────────────────────┐  │
         │  │  Immutable Audit Log (append-only; CA-resident)                │  │
         │  │  • Every system action → log entry                             │  │
         │  │  • Log entries: cryptographically signed and chained           │  │
         │  │  • Log store: independent of application environment           │  │
         │  └───────────────────────────────────────────────────────────────┘  │
         │  Residency: CANADA ONLY  |  Foreign provider: NO plaintext access   │
         └──────────────────────────────────────────────────────────────────────┘
Layer 04 ┌──────────────────────────────────────────────────────────────────────┐
AI LAYER │  AI ASSISTANCE LAYER  [CA-resident compute; governed operation]     │
         │  • Document analysis & classification (not generative front-end)   │
         │  • Rules-of-origin eligibility flagging                            │
         │  • Anomaly / fraud detection in trade data streams                 │
         │  • All AI decisions: logged, human-reviewable, overridable         │
         │  Residency: CA-resident compute preferred; external cloud only if  │
         │  input data is pre-classified and confirmed non-sensitive           │
         └──────────────────────────────────────────────────────────────────────┘
Layer 03 ┌──────────────────────────────────────────────────────────────────────┐
WORKFLOW │  WORKFLOW / ORCHESTRATION LAYER                                      │
         │  • Multi-party trade workflow state machine                        │
         │  • FTA eligibility & compliance pre-check                          │
         │  • Permit, license, certificate of origin lifecycle                │
         │  Residency: CA-resident; external cloud may host if encrypted      │
         └──────────────────────────────────────────────────────────────────────┘
Layer 02 ┌──────────────────────────────────────────────────────────────────────┐
APP SVC  │  APPLICATION SERVICES LAYER                                          │
         │  • Exporter onboarding, identity verification                      │
         │  • Document management, template engine                            │
         │  • Notification services, partner communication                    │
         │  Residency: External cloud can host (encrypted; CMK applied)       │
         └──────────────────────────────────────────────────────────────────────┘
Layer 01 ┌──────────────────────────────────────────────────────────────────────┐
USER /   │  USER / CHANNEL LAYER                                                │
CHANNEL  │  • Web portal (Canadian SME exporters)                              │
         │  • API channel (freight forwarders, customs brokers)               │
         │  • Government portal interfaces                                     │
         │  Residency: Delivery via external CDN acceptable; auth CA-only     │
         └──────────────────────────────────────────────────────────────────────┘

  KEY:  [CA-ONLY] = Must reside in CA-controlled environment; no foreign provider plaintext access
        [SPLIT]   = Control plane CA-only; compute may use external cloud with encryption + CMK
        [EXT OK]  = Can be hosted by external provider if encrypted with CA-controlled keys

Layer	Purpose	Residency	Foreign Cloud Can Host?	Provider Plaintext Access?	Must Be CA-Controlled?
L10 — Monitor/Audit	Compliance, evidentiary integrity	Canada only	NO	NEVER	YES
L09 — Infrastructure	Compute, storage, network	Split (sovereign core + ext cloud)	PARTIAL	NO (encrypted only)	CONTROL PLANE YES
L08 — Encryption/KMS	Key custody, HSM	Canada only	NO	NEVER	YES — absolute
L07 — Data Classification	Tagging, routing policy	CA-resident engine	Policy engine: NO	NO	YES
L06 — API/Gateway	Cross-border exchange, selective disclosure	Canada controlled	Gateway: NO	NO	YES
L05 — Records/Trust	PTR, eTR, audit logs	Canada only	NO	NEVER	YES — absolute
L04 — AI Layer	Analysis, anomaly detection	CA compute preferred	Only with pre-classified non-sensitive data	CONDITIONAL	PREFERRED
L03 — Workflow	Trade workflow orchestration	CA resident	With CMK + encryption	NO	YES
L02 — App Services	Exporter-facing services	External cloud acceptable	YES (with CMK)	NO (encrypted)	PARTIAL
L01 — User/Channel	UI delivery, access	CDN/cloud acceptable	YES (delivery only)	Low-sens only	Auth must be CA-controlled

§ 04

Legal Logic — CUSMA Risk Analysis Table

Note on framing: The following table presents architecture and policy-risk analysis. Where a design approach is described as "more defensible" or "likely to present lower trade-law risk," this reflects architectural and procurement logic, not a legal opinion. CUSMA interpretation in specific cases requires qualified trade-law counsel. The table is intended to help infrastructure designers and policy advisors identify postures that are more or less likely to withstand scrutiny.

CUSMA Chapter 19 prohibits data localization mandates that lack a legitimate public policy objective and go beyond what is necessary to achieve it. It does not prohibit security-based, neutral, objective technical requirements that any provider — domestic or foreign — must meet. The architecture described here is designed so that every control can be justified on security, evidentiary integrity, or operational sovereignty grounds — not on provider nationality.

Issue	What Creates Higher CUSMA Risk	More Procurement-Safe Approach	Why It Is More Defensible
Hard Data Localization Mandates	Requiring all data stored only in Canada with no performance-based or security justification — likely a less defensible posture under Art. 19.11	Mandate localization only for specific high-sensitivity classes (keys, audit logs, PTRs) with documented security rationale tied to evidentiary integrity and foreign legal exposure risk	CUSMA Art. 19.11 allows localization for legitimate public policy objectives. Targeted, justified localization of specific data classes is a more defensible position than blanket mandates
Procurement Requirements	Writing RFPs that specify "Canadian provider only" or require headquarters in Canada — generally a less defensible posture; more likely to be challenged as nationality-based discrimination	Write requirements in terms of capabilities: HSM residency, key custody, audit independence, compliance with CAN/DGSI 104 — any qualified provider may bid	Neutral capability requirements are a more procurement-safe and standards-based approach. Nationality-based requirements are generally a weaker legal position and more susceptible to challenge
Encryption Key Control	Allowing the infrastructure provider to manage encryption keys — creates higher risk that a foreign legal compulsion order could yield plaintext data regardless of geographic location	Require customer-managed keys (CMK) with HSM custody in Canada; key derivation must occur in CA-resident HSM; provider never has key access. Major providers support this via external key manager architectures	A genuine security control, not a nationality restriction. Any provider — AWS, Azure, GCP — can in principle satisfy this requirement if they support external key managers. The control applies to all providers equally
Data Residency	Treating "data centre in Canada" as equivalent to sovereignty — an architectural misunderstanding that may also be a weaker legal position if challenged	Distinguish residency from control. Require Canadian-controlled key management AND Canadian-resident evidentiary records AND Canadian-controlled audit logs — not just a data centre address	The more legally coherent question is who has the operational capability to produce the data — not where it physically sits. This framing is more likely to withstand legal and procurement scrutiny
Foreign Provider Access	Allowing providers admin access to environments containing sensitive trade records or cryptographic material — creates compulsion risk and operational sovereignty risk simultaneously	Zero-trust segmentation; break-glass access only with CA-operator co-authorization; all provider access events audited; no provider has standing access to sensitive environments	Security-neutral requirement applicable to all providers equally. Eliminates a class of legal compulsion exposure without constituting nationality discrimination
Cross-Border Data Transfer	Blocking all cross-border data flows or requiring government approval for routine trade data exchanges — likely to create higher CUSMA risk under Art. 19.12 and could impede lawful trade operations	Allow cross-border transfer of operational, non-sensitive trade data; classify and gate only genuinely sensitive classes; use selective disclosure at the API gateway for higher classes	CUSMA Art. 19.12 protects free data flows. Blocking operational trade data (customs declarations, shipping notices) would likely present higher challenge risk. Gating only high-sensitivity data is proportionate and more defensible
Government-Only Sensitive Workloads	Claiming all workloads are "government sensitive" to justify blanket restrictions — over-classification weakens the legal argument by making it appear the classifications are pretextual	Apply strict, documented classification: only actual government-interface data gets the highest protection tier; private-sector commercial data gets proportionate protection	Precise, documented classification is both better security practice and a more legally defensible position. The tighter the classification rationale, the harder it is to challenge as protectionist
Audit Logging	Storing audit logs in the same environment as the provider who controls the data plane — creates evidentiary integrity risk and compounds compulsion exposure	Require audit logs in an environment the infrastructure provider cannot modify or access; CA-resident, append-only, cryptographically signed	Audit log independence is an evidentiary integrity requirement consistent with ISO 27001, SOC 2, and legal chain-of-custody standards — not a nationality restriction
Portable Electronic Trade Records	Locking electronic trade records inside one vendor's proprietary format or control plane — creates vendor dependency that undermines both legal standing and operational sovereignty	Implement PTRs per UNCITRAL MLETR using open, portable formats; store record control in CA-resident system; allow transfer without losing legal standing	Standards-based portability is legally neutral, interoperability-promoting, and consistent with WTO TFA objectives. Proprietary lock-in is both a security risk and a sovereignty failure mode
Vendor Lock-In	Building architecture that can only function with one provider's proprietary services — undermines portability, resilience, and the ability to enforce procurement requirements	Use open standards for encryption, APIs, and record formats; require portability as a procurement condition; maintain ability to migrate providers	Provider portability is a legitimate security and resilience requirement applicable to all providers. It also protects against abuse of market position by any single provider, regardless of nationality
Discriminatory Provider Exclusion	Stating "we will not use AWS because it is American" — likely to create higher CUSMA challenge risk and is architecturally unnecessary if control requirements are properly designed	State instead: "We will use any provider that meets our published technical requirements for key custody, audit independence, and data isolation. Those requirements are open to all."	This is the core CUSMA defence. If a provider can satisfy the requirements, it cannot credibly claim discrimination. If it cannot, the issue is with its product — not Canada's nationality bias
Standards-Based vs Nationality Requirements	Requiring certification from a body that foreign providers cannot realistically access — may be treated as a de facto nationality restriction even if not expressly so	Reference internationally recognized standards (ISO 27001, FIPS 140-2, UN/CEFACT, WCO Data Model, CAN/DGSI 104) — any provider may comply regardless of nationality	International standards are provider-neutral by design. Even specifically Canadian standards are a more defensible basis for requirements when they apply equally to all providers and are grounded in legitimate public policy

§ 05

Data Classification Model

Every data element entering a sovereign digital trade platform must be classified at ingestion. Classification determines storage location, encryption requirements, cross-border transfer rules, and provider access permissions. In the TPTN design approach, the classification engine (Layer 07) is a Canadian-resident policy control — not a discretionary operational decision.

Class	Examples	Stays in Canada?	Can Transit Cross-Border?	Foreign Cloud Can Process?	Must Be Client-Side Encrypted?	Provider Can See Plaintext?
Class 1 Public / Low Sensitivity	Published tariff schedules, FTA text, public HS code lookups, general compliance guides	NOT REQUIRED	YES — freely	YES	NO	YES — acceptable
Class 2 Operational Business Data	Shipment tracking events, non-sensitive logistics data, port of loading/discharge, vessel schedules	NOT REQUIRED	YES — standard controls	YES	NO — transit encryption sufficient	LOW-RISK acceptable
Class 3 Regulated Commercial Data	Commercial invoices, packing lists, standard customs declarations, certificate of origin data, CFIA inspection results (non-sensitive)	PREFERRED	YES — to authorized recipients only	YES — with CMK encryption	APPLICATION-SIDE preferred	NO — encrypted storage required
Class 4 Sensitive Trade Intelligence	Buyer/supplier relationship data, pricing, trade route intelligence, competitive positioning, strategic shipment patterns	YES	RESTRICTED — minimum necessary only	NO — CA-resident compute only	YES — before external storage	NEVER
Class 5 Electronic Transferable Records / Title-Sensitive	Electronic bills of lading (eB/L), electronic CMRs, electronic warehouse receipts, promissory notes, letters of credit in digital form	YES — sovereign core only	Only via selective disclosure (hash + verification, not full record)	NO	YES — mandatory	NEVER
Class 6 Government-Shared / Regulated Interface Data	CBSA advance commercial information, controlled goods declarations, Export and Import Permits Act data, sanctions screening results	YES — sovereign core + CA gov systems	ONLY to authorized government recipients via encrypted channel	NO	YES — mandatory	NEVER
Class 7 Cryptographic Material / Root Secrets	HSM root keys, master key encryption keys (MEKs), signing certificates, private key material, CA root certificates	YES — HSM only, never leaves hardware	NEVER	NEVER	N/A — never stored externally	NEVER under any circumstances
Class 8 Audit / Evidentiary Records	System audit logs, access logs, chain-of-custody records, tamper evidence records, regulatory compliance trail	YES — append-only, CA-resident	NOT as a live replication feed	NO — must be independent of app environment	YES — cryptographically signed	NEVER

Design note on Class 5 — Electronic Transferable Records: Under UNCITRAL MLETR, an electronic transferable record must maintain "exclusive control" — meaning the system architecture must guarantee that only one party at a time can exercise control over the record. In the TPTN design approach, this is a structural requirement for the PTR store: it cannot replicate, duplicate, or allow simultaneous control by multiple parties without explicit transfer actions. This is not optional for any platform aspiring to MLETR-aligned standing.

§ 06

Step-by-Step Worked Export Scenario

Scenario: A Canadian agri-food exporter (wheat, processed grains) sells to a buyer in ASEAN (Thailand). The shipment moves from Winnipeg → Vancouver → Bangkok. The platform is a TPTN-style digital trade infrastructure operator. This scenario illustrates the intended data flow under the TPTN design approach — not a completed operational transaction.

Exporter Onboarding & Trade Document Creation

The exporter logs in via the web portal (Layer 01 — delivered via CDN; authentication via CA-controlled identity provider). The exporter initiates an export transaction: buyer identity, commodity (HS code), quantity, destination.

Data classification at ingestion: commercial invoice data → Class 3. Buyer/supplier relationship → Class 4. Trade route intelligence → Class 4. All classified before routing.

What AWS/Azure can see: the session request (encrypted in transit). Nothing else.

FTA Eligibility Pre-Check

The AI layer (CA-resident compute) runs an automated CPTPP rules-of-origin eligibility check. Class 3–4 data is processed in CA-resident compute. The AI output is a logged decision — timestamp, input hash, model version, result. The exporter sees the reasoning; a compliance officer can review and override.

What AWS/Azure can see: nothing. This computation is CA-resident.

Trade Document Creation & Encryption

The workflow layer generates draft trade documents: commercial invoice, packing list, certificate of origin, and initiates an eB/L workflow. The CA-resident HSM derives a document-specific encryption key (DEK) for each document. Class 3 documents → encrypted with DEK, DEK wrapped with CMK. The eB/L (Class 5) → encrypted; stored in the PTR store — never leaves the sovereign core in plaintext.

Class 3 documents can now be stored in external cloud in encrypted form. The external cloud provider sees only ciphertext blobs.

eB/L: Class 5 — PTR store only Invoice: Class 3 — encrypted cloud storage acceptable

CBSA Advance Commercial Information (ACI) Filing

The platform generates an ACI submission for CBSA (Class 6 data). It moves via the API gateway using a dedicated, encrypted government interface channel. The gateway enforces selective disclosure: only minimum data elements required by CBSA regulation are transmitted; surplus fields are stripped. The gateway logs the transmission: timestamp + recipient + data scope + hash.

The eB/L is not transmitted — only a hash reference (for verification) is included. The original remains in the sovereign PTR store.

Logistics Integration

The freight forwarder receives booking reference, container number, vessel name (Class 2–3 data) through the API gateway. The carrier receives a hash reference to the eB/L — not the eB/L itself. The carrier can verify the eB/L exists and is valid via the platform's verification API, which returns cryptographic confirmation without exposing the document. Verifiable without visible.

Cross-border: booking ref, vessel data (Class 2) Stays CA: eB/L, pricing, supplier relationship (Class 4–5)

Trade Finance — Bank Verification

The Thai buyer's bank requests confirmation of the eB/L. The PTR store executes a controlled access event: the bank is authenticated; access is time-limited and scope-limited; the eB/L is decrypted only within the CA-resident trust layer; the viewing event is logged; the bank receives a secure, time-limited, scope-restricted view — not a copy of the document. Exclusive control remains with the exporter.

Access event logged in audit trail

ASEAN Single Window Filing — Thailand Customs

The API gateway generates an outbound submission to Thailand's National Single Window, formatted per ASEAN DEFA standards. The submission contains only Class 2–3 data: commodity description, HS code, declared value, weight, CO reference (hash, not full CO). The selective disclosure engine strips all Class 4+ data before transmission.

Thailand NSW receives: HS code, declared value, CO hash (Class 2–3)
Stays in CA: buyer/supplier relationship, pricing intelligence, eB/L plaintext (Class 4–5)

eB/L Formal Transfer — Title Passes to Buyer

The exporter formally transfers exclusive control of the eB/L to the Thai buyer within the PTR store. The old holder signs the transfer instruction with their private key (CA-resident key vault); the PTR store validates the signature, updates the exclusive control record; the transfer event is recorded in the immutable audit log with cryptographic proof. The Thai buyer is now the exclusive controller. The eB/L document never moved in plaintext.

Transfer event: immutable audit log with cryptographic proof

Audit Trail Completeness

At transaction close, the audit layer has a complete, cryptographically linked record: document creation, AI decision events, encryption/decryption events, government interface transmissions, third-party access events, chain-of-custody transfers. This audit trail is append-only, cryptographically chained, and stored in the CA-resident audit environment — to which no infrastructure provider has access. It constitutes an evidentiary-grade audit record suitable for regulatory review, dispute resolution, or legal proceedings.

§ 07

How This Applies to TPTN

The architecture described throughout this document is not abstract theory. It is the design posture that a Canadian digital trade infrastructure like TPTN must build toward in order to be credible with government and institutional stakeholders, viable in procurement contexts, and defensible on sovereignty grounds. This section maps the architecture directly to TPTN.

TPTN is not simply digitizing paperwork. It is intended to support trusted trade execution, auditability, interoperability, and — as it matures — electronic transferable record handling. Sovereignty for TPTN means not just where systems run, but who controls the trust architecture.

1. TPTN's Sovereign Core

In the TPTN design approach, the sovereign core encompasses the elements that must remain under Canadian operational control regardless of what external cloud infrastructure is used:

Trusted Records: Electronic trade records — including any future electronic transferable records — are to be held in TPTN's PTR store, which is designed as a CA-resident, MLETR-aligned record custody system. No external provider holds the record or controls access to it.
Audit Logs: All system audit logs are to be held in a CA-resident, append-only environment that is structurally independent of the application infrastructure provider. The logs are cryptographically signed and chained to preserve evidentiary integrity.
Key Custody: TPTN's design intent is that all encryption keys for sensitive data classes are held in Canadian-resident HSMs. Foreign infrastructure providers have zero access to key material. This is the core mechanism that eliminates meaningful plaintext exposure to foreign legal compulsion.
Policy and Access Governance: The decisions about who can access what, under what conditions, and with what logging — these governance decisions are made by TPTN's CA-resident policy engine. No external provider has the ability to modify access policy unilaterally.
Regulated Trade and Government-Interface Data: Data exchanged with Canadian government systems (CBSA, AAFC, TC, CFIA) is handled within the sovereign core and transmitted through the CA-controlled API gateway under strict classification and selective disclosure controls.

2. What TPTN Can Allow in External Cloud Infrastructure

Within a TPTN-style sovereign trade infrastructure model, the following can appropriately use external cloud infrastructure — subject to the encryption and key custody requirements described above:

Encrypted Application Workloads: Application compute (document management, workflow orchestration, notification services) may run in external cloud environments provided all sensitive data is encrypted client-side with CA-controlled keys before reaching the provider environment.
User Interface Delivery: Web portal delivery via CDN or cloud infrastructure is acceptable, provided authentication and session management are controlled by CA-resident identity infrastructure.
Selected Operational Services: Lower-sensitivity operational services (shipping data aggregation, notification routing, public data lookups) can be hosted in external cloud with appropriate encryption and access controls.
Low-Sensitivity and Tokenized Processing: Class 1–2 data and tokenized representations of higher-sensitivity data (where the token-to-identity mapping resides only in the CA sovereign core) can be processed in external environments.

3. What TPTN Should Avoid

The following represent design postures that TPTN should avoid — not because they are illegal, but because they undermine the sovereignty claims that make TPTN architecturally credible and government-relevant:

Plaintext storage of sensitive trade intelligence in foreign-controlled environments. Any Class 4+ data stored in plaintext in an external provider environment — regardless of geography — means the provider can be compelled to produce it. This collapses the sovereignty posture.
Provider-managed keys for crown-jewel data. If AWS KMS, Azure Key Vault (in provider-managed mode), or Google Cloud KMS holds the keys to TPTN's most sensitive records, the encryption is operational theatre. The provider's legal exposure becomes TPTN's exposure.
Commingling title-sensitive records with ordinary application data. Mixing Class 5 electronic trade records with Class 1–2 operational data in the same storage or compute environment creates unnecessary exposure surface and weakens the evidentiary independence of the record custody system.
Broad cross-border replication by default. Replicating sensitive trade data to external environments as a default operational behaviour — rather than as a deliberate, classified, audited disclosure event — is incompatible with TPTN's intended sovereignty posture.
Sovereignty claims based only on Canadian data-centre location. Asserting sovereignty because data is stored in an AWS Canada region, without CA-controlled key custody, CA-resident audit logs, and CA-controlled governance, is a claim that will not withstand serious government or regulatory scrutiny.

4. Why This Matters for TPTN Specifically

TPTN's value proposition to government and institutional stakeholders rests on a set of claims: that it provides audit-ready, standards-aligned, interoperable electronic trade workflows; that it reduces export friction while maintaining evidentiary integrity; that it can be trusted to handle data that includes government-interface records and potentially electronic transferable records.

None of those claims are credible if the underlying trust architecture is not genuinely sovereign. A platform that routes sensitive trade intelligence through foreign-controlled environments in plaintext, or that uses provider-managed keys for regulated records, cannot credibly present itself as digital trade infrastructure with government-grade integrity. The architecture described in this document is what makes the value proposition defensible.

For TPTN, this means that the sovereignty architecture is not a feature — it is the foundation. Everything else — the SME interface, the FTA usability engine, the interoperability protocols, the AI-assisted compliance tooling — rests on the integrity of the trust and control layer. If that layer is not genuinely Canadian-controlled, the rest of the platform's claims are weakened.

§ 08

What This Does Not Mean

The architecture described in this document is sometimes misread as a form of digital isolationism or anti-foreign-provider bias. To be precise about what this framework does and does not require:

This architecture is compatibility-first. It is designed to function with major global cloud infrastructure and to interoperate with global trade systems — not to exclude them.

This Architecture Does Not Require

Banning U.S. or foreign providers by nationality. AWS, Microsoft Azure, and Google Cloud can participate in this architecture. The question is where and under what conditions. The requirements are capability-based and apply to all providers equally.
Blocking lawful cross-border trade data exchange. The cross-border gateway is designed to enable interoperability with ASEAN Single Windows, foreign customs authorities, logistics partners, and trade finance institutions. The selective disclosure framework controls what is shared — it does not prohibit legitimate cross-border data flows.
Keeping every trade data element in Canada. Class 1–2 data (public tariff schedules, non-sensitive logistics data, tracking information) can and does move across borders freely. Only genuinely sensitive classes (4–8) are subject to strict residency and access controls.
Treating "Canadian region" as sovereign control. This document explicitly rejects that equivalence. A Canadian AWS region operated under AWS's standard terms does not constitute sovereign control. Sovereignty requires operational control, key custody, and audit independence — not a postal code.
Eliminating the need for legal review, procurement discipline, or standards validation. The architecture described here is a design posture. Implementing it in a procurement, regulatory, or government context requires qualified legal counsel, standards validation processes, and the appropriate procurement frameworks. This document does not substitute for any of those processes.

The Correct Framing

The architecture is a control posture, not an exclusion posture. It defines what must be Canadian-controlled — keys, audit logs, record custody, governance — and allows everything else to use the best available infrastructure, domestic or foreign, subject to meeting the control requirements.

Any government or institutional reader should understand this framework as: Canada asserting what it controls, not declaring what it excludes.

§ 09

Procurement-Safe Sovereignty Controls

The following table summarizes the key sovereignty controls in TPTN's design posture, framed explicitly as neutral, objective, standards-based requirements. A government reader should be able to confirm that none of these controls are nationality-based, and that each can be articulated in procurement language that any qualified provider — domestic or foreign — could in principle satisfy.

Control	TPTN Design Intent	Why It Is Neutral / Objective	Why It Matters
Canada-Resident Key Custody	All encryption keys for Class 4–8 data held in CA-resident HSMs (FIPS 140-2 Level 3 minimum); foreign providers have zero key access	Defined by technical capability and hardware certification standards (FIPS 140-2), not provider nationality. AWS, Azure, or GCP can each support this via external key manager architectures if they choose to do so	Eliminates the primary mechanism by which a foreign legal compulsion order could yield plaintext access to sensitive trade data, regardless of data location. This is the most important single control in the architecture
Independent Audit Logging	Audit logs stored in a CA-resident, append-only environment structurally independent of the application infrastructure provider; cryptographically signed and chained	Defined by evidentiary integrity requirements (consistency with ISO 27001, SOC 2, legal chain-of-custody standards) — applicable to any provider. No provider of any nationality is inherently preferred	Audit logs that a provider can modify or withhold are not reliable evidentiary records. Independent logging is a prerequisite for TPTN's audit-ready positioning and for any regulatory or dispute-resolution context
Classification-Based Routing	Data classified at ingestion by a CA-resident policy engine; Class 4–8 data routed to sovereign core; Class 1–3 data may use external cloud subject to encryption requirements	A security and data governance control based on data sensitivity, not provider identity. The same classification framework applies regardless of which cloud provider is used for each layer	Prevents inadvertent exposure of sensitive data to external providers; enables a principled distinction between what is legitimately in external infrastructure and what is not — which is also the CUSMA analytical framework
Selective Disclosure Gateway	CA-controlled API gateway enforces minimum-necessary-data filtering on all cross-border transmissions; every transmission is independently logged	A standards-based interoperability control (consistent with UN/CEFACT, WCO Data Model, ASEAN DEFA, WTO TFA Art. 10 formalities principles); not a restriction on who can receive data, but on how much data they receive	Enables lawful cross-border trade data exchange while maintaining data minimization discipline; protects against bulk replication of sensitive data to foreign jurisdictions; directly relevant to CUSMA Art. 19.12 proportionality
Portable Trusted Records	Electronic trade records implemented per UNCITRAL MLETR in open, portable formats; stored in CA-resident PTR store; transferable between parties without losing legal standing	Defined by international legal standards (UNCITRAL MLETR) and open technical formats — provider-neutral and jurisdiction-neutral in design; any provider capable of MLETR-compliant exclusive-control architecture may support this	MLETR compliance is the foundation of electronic trade document legal standing; portability prevents vendor lock-in from undermining the legal integrity of trade records; critical for TPTN's government-relevance claims
Provider Portability	Architecture must support migration from one infrastructure provider to another without data loss, record invalidity, or loss of governance continuity; open standards for all APIs and record formats	A resilience and procurement discipline requirement — not a preference for any specific provider. Any provider that uses open standards and does not impose lock-in satisfies this requirement, regardless of nationality	Prevents infrastructure dependence that would undermine Canada's operational sovereignty over its trade infrastructure; also a procurement governance best practice applicable to any government-adjacent infrastructure
Standards-Based Procurement Language	All procurement requirements for TPTN architecture reference international or Canadian standards (ISO 27001, FIPS 140-2, UN/CEFACT, WCO Data Model, CAN/DGSI 104) rather than provider-specific capabilities or nationality requirements	International standards are by design provider-neutral and jurisdiction-neutral; they can be met by domestic or foreign providers. CAN/DGSI 104 (AI governance) applies to any AI system deployed in this context, regardless of vendor origin	Standards-based procurement is the primary legal mechanism for imposing substantive sovereignty controls without creating CUSMA challenge exposure; it is also the normal practice for government-adjacent infrastructure procurement in Canada and internationally
No Provider Plaintext Access to Crown-Jewel Data	Class 5–8 data is never accessible in plaintext to any external infrastructure provider; all sensitive data encrypted client-side or application-side before reaching any external environment	Defined by what the provider can technically access — a capability and architecture requirement, not a nationality restriction. A U.S. provider that cannot access plaintext poses no greater legal exposure than a Canadian provider that cannot access plaintext	The single most operationally significant control. If this holds, the remainder of the architecture — data residency, vendor relationships, geographic location — becomes secondary. If this fails, no other control can fully compensate

§ 10

Architecture Patterns & Anti-Patterns

A. Recommended Patterns

✓ Recommended Pattern

Customer-Managed Keys (CMK)

Operator holds all encryption keys in CA-resident HSM. Provider infrastructure never has key access. Even if the provider is compelled to produce data, they can only produce ciphertext. This is the most operationally significant control in the architecture.

✓ Recommended Pattern

Split Control Plane / Data Plane

The control plane (governance decisions, key operations, access policy) runs in the CA-sovereign environment. The data plane (encrypted compute, storage) may use external cloud. The provider cannot influence governance decisions even if they host the workload.

✓ Recommended Pattern

Sovereign Key Custody

Root key material never leaves the CA-resident HSM. All derived keys are wrapped before leaving the HSM. Access requires multi-party authorization. Any key access event is logged in the independent audit environment.

✓ Recommended Pattern

Selective Disclosure

At every cross-border transmission, the API gateway applies minimum-necessary-data filtering. Recipients receive only what they need for their specific authorized function. Each transmission is independently authorized, scoped, and logged.

✓ Recommended Pattern

Data Minimization at Ingestion

Data is classified and stripped of unnecessary elements at the point it enters the system. Fields not needed for the current workflow are not collected. This limits exposure surface before encryption is even applied.

✓ Recommended Pattern

Tokenization / Pseudonymization

Sensitive identifiers are replaced with opaque tokens in external systems. The token-to-identity mapping lives only in the CA-sovereign core. External systems work with tokens, not real identities or sensitive values.

✓ Recommended Pattern

Portable Trusted Records (PTR Architecture)

Electronic trade records stored in open, MLETR-compliant formats. Chain-of-custody in CA-resident PTR store. Records can be transferred between parties without vendor dependency. Verifiability is cryptographic, not platform-specific.

✓ Recommended Pattern

Zero-Trust Access

No user, system, or provider is implicitly trusted. Every access request is authenticated, authorized against current policy, and logged. This applies equally to internal users, authorized partners, and external infrastructure providers.

✓ Recommended Pattern

Canada-Resident Audit Logging

Audit logs stored in an environment entirely separate from application infrastructure and inaccessible to any infrastructure provider. Append-only, cryptographically chained, signed. The log store cannot be modified by any external party.

✓ Recommended Pattern

Envelope Encryption Architecture

Each record encrypted with a unique DEK. The DEK wrapped with a KEK held in the HSM. Compromising one document does not compromise any other. Key rotation is operationally feasible without re-encrypting all data.

✓ Recommended Pattern

Provider-Neutral Technical Standards

Procurement requirements reference international standards (FIPS 140-2, ISO 27001, UN/CEFACT, WCO Data Model) rather than vendor-specific certifications. Any provider that meets the standards may participate. This is the core procurement-safe CUSMA defence.

✓ Recommended Pattern

Policy-Based Routing

Data routing decisions are made by a CA-controlled policy engine based on classification tags. Changes to routing policy require authorized operator action. No external provider can unilaterally alter data flow behaviour.

B. Dangerous Anti-Patterns

✗ Anti-Pattern

Storing Sensitive Records in Plaintext in a Foreign Hyperscaler

Technical risk: The provider can read, copy, or be compelled to produce the data.
Legal risk: Under instruments such as the U.S. CLOUD Act, U.S. authorities may be able to compel a U.S. cloud provider to produce data regardless of where it is stored. "Stored in Canada" is not a complete defence if the provider controls access. The specific application of this risk to any given configuration requires legal counsel review.
Strategic risk: Any credibility claim of sovereignty collapses immediately once it becomes known that title-sensitive records or trade intelligence sit in plaintext on a foreign-controlled environment.

✗ Anti-Pattern

Provider-Managed Keys Controlling Crown-Jewel Data

Technical risk: Provider-managed keys mean the provider has the decryption capability — their HSM, their root of trust, their access policies.
Legal risk: The legal exposure analysis is the same as plaintext storage — if the provider can decrypt, they may be compellable to produce decrypted data.
Strategic risk: Sovereignty architecture built on provider-managed keys is sovereignty architecture in name only and will not withstand scrutiny from informed government or institutional stakeholders.

✗ Anti-Pattern

Centralizing All Logs with the Infrastructure Vendor

Technical risk: If the vendor controls the logs, the vendor can modify, delete, or withhold them. A self-serving audit record is not an audit record.
Legal risk: Logs in a foreign provider environment are subject to the same legal exposure as any other data. A log that can be compelled, modified, or withheld by a foreign-controlled party is not a reliable legal instrument.
Strategic risk: In any regulatory investigation or dispute, audit log independence is the first thing that will be challenged. Vendor-held logs fail this test.

✗ Anti-Pattern

Commingling Title-Sensitive Records with Ordinary Application Data

Technical risk: Co-location creates lateral movement opportunities; a vulnerability in the low-sensitivity layer becomes a path to the high-sensitivity layer.
Legal risk: Regulatory requirements for Class 5–8 data require demonstrable isolation. Mixed environments make it difficult to prove that sensitive records were protected to the required standard.
Strategic risk: Any serious security audit or government review will flag mixed environments as an immediate concern. Segmentation is not optional for infrastructure with sovereignty claims.

✗ Anti-Pattern

Broad Cross-Border Replication by Default

Technical risk: Default replication means sensitive data is permanently present in foreign legal environments regardless of operational need.
Legal risk: PIPEDA and the proposed CPPA require purpose limitation and proportionality in cross-border transfers. Blanket replication is likely to present compliance problems.
Strategic risk: Once data is replicated to a foreign environment, it is extremely difficult to recall. The sovereignty posture becomes permanently compromised for that data.

✗ Anti-Pattern

Locking Portable Records Inside One Vendor Stack

Technical risk: Vendor lock-in for electronic trade records means record portability and legal continuity are at risk if the vendor relationship changes.
Legal risk: UNCITRAL MLETR compliance requires the system controlling an electronic transferable record to be reliable and interoperable. Proprietary lock-in undermines both.
Strategic risk: A sovereign infrastructure that can only be operated by one commercial vendor is dependent — not sovereign. This is the exact condition sovereignty architecture is designed to prevent.

✗ Anti-Pattern

Using Nationality Bans Instead of Objective Control Requirements

Technical risk: Nationality bans do not address the underlying technical problem. A Canadian provider with poor key management is less secure than a U.S. provider with strong key isolation capabilities.
Legal risk: Excluding providers by nationality is generally a weaker legal posture under CUSMA — it is the design choice most likely to create a successful trade challenge.
Strategic risk: It transforms a defensible security architecture into an indefensible trade policy position, and discredits the entire sovereignty rationale in the process.

∑

One-Page Summary

The core challenge: Canada wants to build digital trade infrastructure that it genuinely controls. CUSMA Chapter 19 restricts data localization mandates but does not prohibit neutral, objective security and control requirements applied equally to all providers. The design posture described in this document — and intended for TPTN — is built on that distinction.

Applied to TPTN, the architecture answer is sovereignty-by-design, not crude isolationism. This means separating what a provider can host from what a provider can see or control. Foreign cloud providers can host encrypted application workloads. They cannot hold encryption keys, access sensitive records in plaintext, control audit logs, or manage electronic transferable records.

Five non-negotiable design principles for TPTN:

Canadian key custody: All encryption keys for sensitive data (Class 4–8) held in CA-resident HSMs. Foreign providers have zero key access. This is the primary mechanism by which meaningful foreign legal exposure is eliminated at the data layer.
Canadian audit independence: Audit logs stored in a CA-resident environment entirely separate from and inaccessible to application infrastructure providers.
Canadian sovereign core for Class 4–8 data: Trade intelligence, electronic transferable records, cryptographic material, government-interface data, and audit records do not leave CA-controlled environments in plaintext.
Standards-based, not nationality-based requirements: Every control references an international or Canadian standard. Any provider that satisfies the requirements may participate. No provider is excluded by nationality.
Selective disclosure at every cross-border boundary: The API gateway enforces minimum-necessary-data principles on every outbound transmission. No bulk replication. Every cross-border data flow is logged.

The procurement-safe CUSMA defence posture: TPTN's architecture imposes neutral, objective, proportionate technical requirements justified by legitimate public policy objectives — evidentiary integrity, protection from foreign legal compulsion, operational sovereignty over national trade infrastructure. These requirements apply equally to all providers. They are not nationality restrictions. They are security and governance controls consistent with standards applied by the EU, Singapore, Australia, and the UK to their own sovereign digital infrastructure.

What this architecture is not: It is not a ban on foreign providers, a restriction on lawful cross-border trade data flows, or a claim that every trade data element must remain in Canada. AWS, Microsoft Azure, and Google Cloud can participate in TPTN architecture — in the layers where their participation is appropriate and meets the control requirements. The architecture defines what Canada controls, not who Canada excludes.

✓

10-Point Sovereignty Evaluation Checklist

Use this checklist to evaluate whether a proposed architecture is genuinely sovereign-by-design or presenting a sovereignty claim that will not withstand serious scrutiny.

01
Key Custody: Are all encryption keys for sensitive data (Class 4–8) held in a Canada-resident HSM that the infrastructure provider cannot access? "We use provider-managed keys" or "our keys are in Azure Key Vault managed by Microsoft" means the sovereignty claim at this layer is not substantiated.
02
Audit Log Independence: Are audit logs stored in an environment entirely separate from the application infrastructure provider and inaccessible to that provider? Audit logs in the same AWS account as the application are not independent evidentiary records.
03
Electronic Transferable Record Control: Do electronic trade records maintain MLETR-compliant exclusive control within a CA-resident PTR store? Can exclusive control be transferred without the document leaving the sovereign core in plaintext?
04
Data Classification Enforcement: Is there an operational classification system at ingestion that routes sensitive data classes to sovereign environments and enforces that routing by policy engine — not by human discipline alone?
05
Control Plane vs Data Plane Separation: Is the CA-resident control plane (governance, access policy, key operations) genuinely separate from the data plane, such that the external provider could be replaced without losing governance continuity?
06
Cross-Border Selective Disclosure: Does every cross-border data transmission go through a CA-controlled API gateway enforcing minimum-necessary-data filtering? Is every transmission independently logged with recipient, scope, and timestamp?
07
Provider Portability: Can the architecture migrate from one infrastructure provider to another without re-encrypting sensitive data, breaking record portability, or losing audit continuity? Vendor lock-in is a sovereignty failure mode.
08
Standards-Based Requirements: Are all security and control requirements expressed in terms of international or Canadian standards — not vendor-specific capabilities or nationality restrictions? Could any competent provider — domestic or foreign — in principle satisfy the requirements?
09
Foreign Legal Exposure Analysis: Has the architecture been reviewed for the risk that any provider in the stack has access — direct or key-based — to sensitive data that could be subject to foreign legal compulsion? Has that exposure been addressed by the key custody architecture? Determining the precise scope of this risk in any specific configuration is a matter for qualified legal counsel.
10
Operational Sovereignty Test: If the primary infrastructure provider terminated its contract tomorrow, could the platform continue operating with another provider without data loss, record invalidity, or loss of governance control? If the answer is no, the platform is dependent — not sovereign.

Glossary

CUSMA Digital Trade Risk

The risk that a digital infrastructure design choice — particularly around data localization, procurement requirements, or provider restrictions — may create a higher likelihood of challenge under Chapter 19 of the Canada-United States-Mexico Agreement, which restricts data localization mandates (Art. 19.11) and protects cross-border data flows (Art. 19.12). The analysis here is architectural and policy-risk in nature; specific CUSMA obligations in any procurement or regulatory context should be assessed with qualified trade-law counsel. The risk is generally higher when requirements are based on provider nationality rather than neutral, objective technical criteria.

Data Residency

The physical or logical location where data is stored — typically defined by which country's data centre contains the data. Data residency is not the same as sovereign control. Data stored in a Canadian AWS region is resident in Canada but may still be accessible to a foreign government if the provider controls the encryption keys. Residency is a necessary but not sufficient condition for the sovereignty posture described in this document.

Sovereign Control

The ability of a Canadian operator to make and enforce decisions about who can access, modify, or compel production of data and systems — independent of the infrastructure provider's legal exposure to foreign governments. True sovereign control requires: (1) Canadian key custody, (2) Canadian audit log independence, (3) Canadian-controlled governance of access policy, and (4) the ability to operate without dependence on any single foreign provider. Data residency alone does not constitute sovereign control.

Customer-Managed Keys (CMK)

An encryption architecture in which the customer — not the cloud provider — generates, holds, and controls the encryption keys used to protect data. The provider's infrastructure stores encrypted data but never has access to the key material needed to decrypt it. Major cloud providers support CMK through mechanisms like AWS External Key Store (XKS), Azure Customer-Managed Keys, and Google Cloud CMEK. Under a proper CMK architecture, a legal order compelling the provider to produce data yields only ciphertext, not plaintext.

HSM (Hardware Security Module)

A dedicated, tamper-resistant hardware device designed to securely generate, store, and perform operations with cryptographic keys. Root key material generated in an HSM is designed never to leave the hardware boundary in plaintext. HSMs are certified to FIPS 140-2 or FIPS 140-3 standards (Level 2 or Level 3 for high-security applications). In the TPTN design approach, a Canada-resident HSM cluster operated by Canadian personnel under Canadian governance is the foundation of the key custody architecture.

Zero Trust

A security architecture principle that assumes no user, system, or network segment should be implicitly trusted — including those inside the organization's own perimeter. Every access request must be explicitly authenticated, authorized against current policy, and logged. Zero trust prevents lateral movement and is essential for protecting a multi-layer platform where different zones have different sensitivity levels and different provider access profiles.

Selective Disclosure

A design pattern in which a system shares only the minimum information necessary for a specific, authorized purpose. In a digital trade context, selective disclosure means a customs authority receives only the fields it legally requires for clearance — not the full commercial transaction record. Applied at the API gateway, selective disclosure is both a data minimization control and a proportionality mechanism relevant to CUSMA Art. 19.12 analysis.

Portable Trusted Record (PTR)

An electronic trade record — such as an electronic Bill of Lading or electronic CMR — that maintains legal standing equivalent to its paper counterpart, can be transferred between parties without losing validity, is not dependent on a single vendor's platform for its enforceability, and maintains an immutable chain of custody. PTRs in the TPTN design approach are aligned with UNCITRAL MLETR, which defines the conditions under which an electronic record can function as an electronic transferable record with full legal standing. The architecture must guarantee exclusive control at all times.

Plaintext Exposure

The condition in which sensitive data is accessible to a party — such as an infrastructure provider — in its unencrypted, human-readable or machine-processable form. Plaintext exposure is the primary sovereignty failure mode: if a foreign infrastructure provider has plaintext access to sensitive trade records, the sovereignty architecture has not achieved its objectives regardless of data geography. Eliminating plaintext exposure for sensitive data classes is the first design objective of the architecture described in this document.

Interoperability Gateway

In this architecture, the API/integration gateway (Layer 06) that manages all data exchange between the sovereign core and external systems — foreign governments, logistics partners, banks, ASEAN counterparties. The gateway enforces protocol normalization (translating between UN/CEFACT, ASEAN DEFA, and other standards formats), selective disclosure, encrypted transit, authentication, and per-transmission audit logging. It is the controlled chokepoint through which all cross-border data flows, enabling both lawful interoperability and the sovereignty control posture described throughout this document.