004 Corridor First Compliance Model
Source: docs/adr/004-corridor-first-compliance-model.md
# ADR-004: Corridor-First Compliance Model
**Status:** Accepted
**Date:** 2026-02-12
**Decision Makers:** RGL8R Engineering + Product
---
## Context
Phase 1 execution is intentionally narrow (`US->CA`, SHIP + TRADE), but several strategy documents and external messaging risk conflating:
- TRADE module with SIMA only
- destination-specific rules with universal compliance logic
- vertical expansion with corridor expansion
That framing is unsafe for long-term product direction. We need corridor-awareness as a first-class model while keeping current delivery priorities intact.
---
## Decision
Treat **corridor** as a core compliance dimension.
Corridor is defined as:
```text
corridor = origin_country -> destination_country
```
Rule applicability must support five scope levels and two orthogonal dimensions:
### Scope Levels (product/tariff rules)
1. `universal` — applies everywhere (physics, UN hazmat codes, HS first 6 digits)
2. `origin` — applies to exports from a specific origin (ITAR for US-origin, EAR for dual-use)
3. `destination` — applies to imports into a specific destination (SIMA for CA, Section 232 for US)
4. `corridor` — applies to a specific origin→destination pair (CUSMA for US→CA, Section 301 for CN→US)
### Orthogonal Dimensions
5. `party` — applies regardless of product or corridor (OFAC SDN, BIS Entity List, UN sanctions). A denied party BLOCK fires on any transaction involving that entity.
### Examples
| Level | Rule | Scope |
|-------|------|-------|
| Universal | Weight cannot exceed dims capacity | All shipments |
| Universal | UN hazmat classification | All products |
| Origin | ITAR screening (USML categories) | US-origin exports |
| Origin | EAR dual-use controls (CCL/ECCN) | US-origin exports |
| Destination | SIMA antidumping/countervailing | →CA imports |
| Destination | Section 232 steel/aluminum tariffs | →US imports |
| Corridor | CUSMA preferential treatment | US→CA |
| Corridor | Section 301 tariff lists | CN→US |
| Party | OFAC SDN list screening | Any transaction, any party role |
| Party | BIS Entity List screening | Any transaction involving listed entity |
---
## Key Distinctions
### ITAR vs EAR
| | ITAR | EAR |
|---|------|-----|
| Agency | State Department (DDTC) | Commerce Department (BIS) |
| Scope | Defense articles (USML) | Dual-use items (CCL/ECCN) |
| Default | Deny (license required) | Allow (license for restricted destinations/end-uses) |
| Trigger | US-origin product on USML | US-origin product with ECCN |
| Level | Origin | Origin |
### Section 232 vs Section 301
| | Section 232 | Section 301 |
|---|------------|-------------|
| Authority | Trade Expansion Act 1962 | Trade Act 1974 |
| Basis | National security | Unfair trade practices |
| Products | Steel, aluminum | Broad goods lists |
| Scope | Destination (→US, most origins) | Corridor (CN→US specifically) |
| Rate type | Ad valorem (25% steel, 10% aluminum) | Ad valorem (variable by list) |
### Denied Party Screening
Party screening is orthogonal to product/corridor rules. Every transaction must screen all parties (buyer, seller, consignee, end-user, freight forwarder, financial intermediary) against:
| List | Agency | Scope |
|------|--------|-------|
| SDN (Specially Designated Nationals) | OFAC | US persons, global reach |
| Entity List | BIS | Export restrictions |
| DPL (Denied Persons List) | BIS | Export privileges denied |
| UN Consolidated Sanctions | UN Security Council | Global |
A match on any list is a BLOCK regardless of product, corridor, or tariff status.
#### Applicability Metadata (Canonical Source)
The `scope_type` column on `app.rule_definitions` is the **canonical** applicability metadata.
No separate corridor metadata table is needed. The complete applicability is encoded as:
- `scope_type` — one of `UNIVERSAL`, `ORIGIN`, `DESTINATION`, `CORRIDOR` (Postgres enum)
- `scope_origin` — `TEXT[]`, country codes or `['*']` for wildcard
- `scope_destination` — `TEXT[]`, country codes or `['*']` for wildcard
For corridor-scoped rules, `scope_origin` and `scope_destination` should contain specific
country codes rather than wildcards — wildcards would make a corridor rule equivalent to
universal. This is a documented convention, validated by corridor isolation contract tests
(P7-E-A3) which verify correct scope matching/filtering. No runtime validation rejects
corridor rules with wildcard values, and no DB constraint enforces it.
## Non-Decision (Important)
This ADR does **not** require immediate code changes in Phase 1.
- No primitive signature changes are required now.
- No blocking schema migration is required before current P5/P6 work.
- This is a governance and architecture boundary decision first.
- ITAR, EAR, and denied party screening are Phase 2+ implementation items.
Implementation triggers:
- Before onboarding the first non-`US→CA` customer corridor, corridor-tagged rule metadata and tests become mandatory. Execution gate checklist: `docs/runbooks/corridor-rollout-trigger-checklist.md`.
- Before onboarding any customer with US export obligations, origin-level rules (ITAR/EAR) must be implemented.
- Before processing transactions for customers with US nexus, denied party screening should be activated (phased rollout acceptable; full coverage required before general availability).
---
## Consequences
### Positive
- Prevents Canada-specific assumptions from hard-coding into module boundaries.
- Gives a clean path from `US->CA` beachhead to additional corridors without rewriting core flows.
- Improves partner/investor messaging consistency ("Canada-first execution, corridor-agnostic architecture").
### Negative
- Adds design overhead before broad geographic expansion.
- Requires explicit rule tagging and test coverage before each new corridor launch.
---
## Generic Tariff Model
All tariff programs (SIMA, Section 232, Section 301, EU antidumping, etc.) share one schema:
```
program: string // SIMA, Section232, Section301, EUAntiDumping, ...
scope.type: enum // universal | origin | destination | corridor
scope.origin: string[] // country codes, or ["*"]
scope.destination: string[] // country codes, or ["*"]
scope.hs_codes: string[] // specific HS codes or chapter prefixes
conditions: object // material, intended use, product attributes
rate: object // ad_valorem | specific | mixed | variable
exemptions: object[] // exclusions, quotas, trade agreements, end-use
evidence_requirements: string[] // docs needed to prove compliance
```
New tariff program = new data row. No code deployment required.
## Rollout Plan
1. **Docs now:** Align execution/strategy docs with corridor-first language.
2. **Planning:** Track as `P7-D` (corridor model) and `P7-E` (export controls + denied party) in execution plan.
3. **Implementation gate:** Before first non-`US→CA` rollout, add corridor fields to rule applicability + tests.
4. **Validation:** Add negative tests proving wrong-corridor rules do not fire.
5. **Party screening gate:** Before GA, denied party screening must be active for customers with US nexus.
6. **Export controls gate:** Before onboarding customers with US export obligations, ITAR/EAR classification must be implemented.
---
## References
- `docs/EXECUTION_PLAN.md`
- `docs/operations/p7-e-a4-first-expansion-corridor-decision-memo.md`
- `docs/strategy/snapshots/self-extending-architecture-v1.md`
- `docs/strategy/snapshots/rgl8r-product-blueprint-v3.8.md`
- `docs/strategy/snapshots/rgl8r-vertical-expansion-plan-v1.md`
- `docs/architecture/cre-rule-hierarchy.md` (6-level rule hierarchy)
- ITAR: 22 CFR Parts 120-130 (USML)
- EAR: 15 CFR Parts 730-774 (CCL/ECCN)
- OFAC SDN: https://sanctionssearch.ofac.treas.gov/
- BIS Consolidated Screening List: https://www.trade.gov/consolidated-screening-list