A scheme family, not a scheme.

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.

Two shipping labels, blown out.

92 channel 92 / 93 / 94 — the IMpb application family
0559012345671234567 service · mailer · serial split per the pinned Pub 199 grammar when the vector set lands — the fields are not guessed here
0 check mod10 pass (Pub 199 §4.6)
1Z prefix the UPS family
12345E shipper account whose label this is
02 service consensus reading — structure by consensus parse
0527168 package serial
8 check best-effort (no public UPS algorithm) — not certified, so not green
IMpb    920559012345671234567 · check 0
sum     9×3 + 2×1 + 0×3 + 5×1 + 5×3 + 9×1 + 0×3 + 1×1 + 2×3 + 3×1 + 4×3 + 5×1 + 6×3 + 7×1 + 1×3 + 2×1 + 3×3 + 4×1 + 5×3 + 6×1 + 7×3 = 170
check   (10  170 mod 10) mod 10 = 0   → mod10 pass

1Z 12345E0205271688
check   best-effort (no public UPS algorithm) — no current official UPS
        document specifies the 1Z check character; the verdict says so in types

The row.

schemeusps-impb · ups-1z
grammarPer 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 digitIMpb: 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 formPer carrier row; identity is open, tracking status is per-caller.
symbologiesGS1-128 (IMpb) · Code 128 (1Z, FedEx ground) · 2D on newer labels
enrichmentidentity: open · status: per-caller, on the caller's own carrier authorizations
join ruleThe missing join is tracking → product identity: that repair is bridge — ranked GTIN candidates with evidence and a confidence floor, exit 1 below it.
pinned digestusps-impb sha256:0abc77368c2024331748c4f2f1a403c5694e9c5f000f4eece546fd41b28ac4b5
ups-1z sha256:50376812682d08d92a8544419fc250c43e321721eb7c9a5e2f64487e85e947b4
as data/schemes/tracking.json

In practice.

The verdict labels are the row's whole point: a pass is awarded only from a published rail, and a number whose rail is unpublished is not failed for it. If UPS publishes a 1Z specification, the row and the posts citing it revise together.

On the blog.

  • Tracking numbers are a scheme family too: 1Z, IMpb, and the SSCC nobody keeps

    Carrier tracking formats are proprietary grammars doing a logistic-unit identifier's job — and the parcel APIs that mint them are SKU-poor and GS1-blind. Product identity dies at the label, and the registry treats carrier formats as first-class scheme rows so the death is at least visible.

  • What did I just scan? Payload identification from the first three bytes

    A scanner hands you bytes, not meaning. The AIM symbology identifier, the FNC1 position, Code-39 framing, and URI shape classify any payload deterministically — worked here on ten raw payloads, the way resolve does it, from a pinned decision table rather than folklore.

  • The API economy is SKU-native: the GTIN gap, measured

    Across 37 verified commercial connector surfaces, GS1 identity lives only at the edges — the ERP top end, the regulated verticals, the standards rails — and is optional, unvalidated free text in the middle. Zero commercial APIs carry SSCC; two carry GLN. Product identity must be bridged into the transaction layer, never assumed.

Get an API key.

The local verbs run from npx barcoding.dev today with no key. A key opens the network half of the verb set.