Verification tools

The Canadian traffic path test matrix describes what each observation proves. These tools gather configuration and traffic evidence for the staged demonstration; a network location or response code alone does not establish country classification.

Tool	Evidence and boundary
verify-canadian-public-re.py	Allocation binding, RE/CE selectors, origin-pool reference, serving RE headers and exact origin response
verify-country-receipts.py	A private receipt joining observed egress to XC source/classification and policy denial for plain and spoofed-header variants
verify-azure-routing.sh	Internal routes, BGP session inventory and internal application paths
verify-azure-failover.sh	Owned node withdrawal, surviving traffic and restored sessions; see failover exercise
lifecycle.py --mode verify	The staged deployment’s combined checks and refresh-enabled zero-change readiness

The existing verifier uses repeated samples as an automation gate. Its sample count is a property of that implementation, not a guarantee of availability or geography. A classified Canadian request must match the origin control body. A negative receipt needs a matching policy-denial event, since an unrelated HTTP error proves no country-policy decision. Supplied forwarding headers must leave the actual-source result unchanged.

Supplied commands

These commands read protected deployment state or private receipts. CANADA_PRIVATE names the deployment’s protected evidence directory; deployment guide describes its inputs.

python3 scripts/verify-canadian-public-re.py --terraform-dir terraform \
  --evidence-dir "$CANADA_PRIVATE/public-receipts" --samples 120
python3 scripts/verify-country-receipts.py "$CANADA_PRIVATE/country-receipt.json"
python3 scripts/lifecycle.py --mode verify \
  --tfvars "$CANADA_PRIVATE/canada.tfvars" \
  --backend-config "$CANADA_PRIVATE/backend.hcl" \
  --private-root "$CANADA_PRIVATE/verify-receipts"

The country receipt is assembled from actual XC events and observed egress; the validator checks their consistency. Raw addresses, credentials, state and events remain in protected storage. A sanitized receipt can identify the tested source commit, artifact identities, observations and outcome without publishing those inputs.

The documentation receipt binds documentation checks to their candidate. It is separate from live infrastructure acceptance. A zero-change plan establishes state/configuration convergence for the observed deployment; it does not replace DNS, traffic, policy or origin evidence.