# Tracking numbers — a scheme family, not a scheme

> The tracking registry rows: USPS IMpb with its published Pub 199 MOD10 rail, UPS 1Z as consensus parse with a typed best-effort label, FedEx as parse-and-say-so.

- page: https://barcoding.dev/schemes/tracking/
- machine row: https://barcoding.dev/schemes/tracking.json
- scheme (dotted registry name): usps-impb · ups-1z

## Reference
- grammar: Per carrier. USPS IMpb: GS1-128 with AI 420 (ZIP) + the 9x IMpb structure, fully published. UPS 1Z: 1Z + shipper id + service + package id — structure by consensus parse. FedEx: format families parsed and labeled as such.
- check: IMpb: USPS Pub 199 §4.6 MOD10, worked example public — mod10 pass/fail. UPS 1Z: no current official public specification of the check character — typed best-effort (no public UPS algorithm), never a fabricated pass. FedEx: parse-and-say-so.
- canonical: Per carrier row; identity is open, tracking status is per-caller.
- barcode types: GS1-128 (IMpb) · Code 128 (1Z, FedEx ground) · 2D on newer labels
- enrichment: identity: open · status: per-caller, on the caller's own carrier authorizations
- join: The missing join is tracking → product identity: that repair is bridge — ranked GTIN candidates with evidence and a confidence floor, exit 1 below it.

## Registry rows (engine artifacts, digest-stated)
### usps-impb
- grammar: `^(420\d{5,11})?9[234]\d{20,24}$`
- check: impb-mod10 → "mod10 pass (Pub 199 §4.6)" (USPS Pub 199 §4.6 MOD10)
- canonical: the tracking digit string without the (420) routing prefix
- segments: channel application identifier · service type code · mailer ID · serial · check
- generate: gs1-128
- hand-off: identity is local and free; status is the carrier's to tell — here is their door
- digest: sha256:0abc77368c2024331748c4f2f1a403c5694e9c5f000f4eece546fd41b28ac4b5

### ups-1z
- grammar: `^1Z[A-Z0-9]{16}$`
- check: ups-best-effort → "best-effort (no public UPS algorithm)" (no current official UPS document specifies the 1Z check character (P0-21 posture watch))
- canonical: 1Z + 16 characters, upper-case
- segments: 1Z · shipper account · service code · package serial · check
- generate: refuses (CONFORMANCE)
- hand-off: identity is local and free; status is the carrier's to tell — here is their door
- digest: sha256:50376812682d08d92a8544419fc250c43e321721eb7c9a5e2f64487e85e947b4

## Resolution stance
barcoding.dev detects, parses, verifies, enriches and generates — the codec and the data layer. Resolution — an identifier answered with identity and its linkset of live doors — is ONE capability family-wide, served by the family's identity layer, id.org.ai; vertical estates project the same one capability (vehicles: auto.dev). This registry row is the data that resolution consumes.

## Posts
- https://barcoding.dev/blog/tracking-numbers-scheme-family/
- https://barcoding.dev/blog/what-did-i-just-scan/
- https://barcoding.dev/blog/the-gtin-gap-measured/
