Iraq (IQ) — internal licensing notes

Source research, 2026-09-17 — verifying current state before any build

Starting state confirmed accurate: datasets/iq/datapackage.yml has data_available: false, and datasets/iq/README.md says outright "We don't have postal code data for Iraq yet." The one declared resource (postal-codes-iq-0, pointing at https://postal.datahub.io/iq/iq.csv) is a 158-byte header-only placeholder (modified: '2024-11-07') — this matches the task brief's "159-byte" figure closely enough to be the same file (byte-count-off-by-one is likely just a line-ending artifact). This pass is research/audit only — nothing built, nothing touched in R2, git, or datapackage.yml.

Headline finding: this is NOT a "no postal code system" country. Iraq has a real, structurally logical, UPU-documented 5-digit postal code system, still nominally active since 2004. This puts IQ in the same class as Turkmenistan (TM) and squarely NOT in the Bolivia/Curaçao/ Côte d'Ivoire/Libya/Zimbabwe/Syria group — the open question is digital accessibility of a bulk list, not existence of the system. Per the task's own instruction #4, this rules out defaulting to a GeoNames locality-only build.

1. Does a real postal-code system exist? — YES, confirmed via UPU

The Universal Postal Union's own country addressing profile for Iraq (https://www.upu.int/UPU/media/upu/PostalEntitiesFiles/addressingUnit/irqEn.pdf, dated 03/2005 — fetched and read directly as a PDF, not from a secondary aggregator) gives:

• Format: 5 digits, positioned below the locality name in the address block, bottom-left corner, left-aligned lines.
• Coding method is structural, not arbitrary — the document breaks down a worked example 6 1 0 0 2 (Al Asmaee, Al Basrah) as: region → province → delivery type → post office number (2 digits). This is the same "designed hierarchical scheme" shape as Turkmenistan's, not a flat arbitrary list.
• List of provinces given (18): Al Anbar, Al Basrah, Al Munthana, Al Najaf, Al Quadisiya, Al Sulaymaniah, Al Ta'amim (old name for Kirkuk), Arbil, Babil, Baghdad, Dahouk, Deyala, Karbala, Maysan, Mousl (Nainawa), Salah Al Deen, Thi Qar, Wasit.
• Contact listed is Coalition Provisional Authority (Steven J. Lucks, "Deputy Sr. Advisor – Post," Republican Palace, Baghdad) — the system was stood up in the CPA/2004 post-invasion period and the UPU document itself is a stale CPA-era snapshot (CPA had already dissolved by June 2004, yet the doc is dated 03/2005), but nothing about the coding scheme itself reads as defunct or superseded.

Cross-check against secondary sources (WebSearch, 2026-09-17): English Wikipedia "Postal codes in Iraq" independently confirms: system introduced 2004 ("restarted on May 24, 2004" per the Arabic-language sibling article), 5 digits, and gives the same governorate → 2-digit prefix mapping implied by the UPU worked example:

(18 governorates, 18 prefixes — table reconstructed from WebFetch summaries of the English Wikipedia page; not independently re-verified row-by-row against the article's raw wikitext in this pass.)

2. No separate Kurdistan-region postal authority — simpler than some other multi-authority cases in this catalogue

The task asked specifically whether the KRG's separate government creates the kind of structural complexity seen elsewhere in this project. Checked directly: it does not, for postal codes specifically.

• The three KRG governorates (Erbil IQ-AR/prefix 44, Duhok IQ-DA/ prefix 42, Sulaymaniyah IQ-SU/prefix 46) are listed as ordinary entries in the same national 18-province list in both the UPU document and the Wikipedia summary — there is no separate "Kurdistan Post" numbering scheme, no distinct prefix block reserved for the region as a whole, and no evidence of a competing KRG-issued postal code system.
• WebSearch for a distinct KRG postal authority found nothing — only community aggregator pages (postalcodes.com.ng, postcodebase.com) describing Erbil/Duhok/Sulaymaniyah codes as ordinary sub-ranges (44001–44099 etc.) within the national Iraq Post scheme. These are community mirrors, not independent confirmation of a second authority — treated as consistent with, not additional evidence for, the "one national scheme" conclusion.
• Iraqi Post ("Iraq Post" per Wikipedia) is organized under the Ministry of Communications nationally; no separate postal corporation for the Kurdistan Region was found.

Where the real complexity is instead: governorate count, not postal authority. See §5 below — this is a genuinely unresolved structural issue for any future build.

3. Network/access reality check for an official bulk source

• post.iq (current official Iraqi Post domain, confirmed via WebSearch — not the assumed iraqpost.gov.iq): live and resolves, fronted by Cloudflare. curl -I (plain, no UA) → HTTP/2 403. curl -I with a full browser User-Agent on / and on guessed paths (/en, /ar, /postal-code, /postcode, /zipcode) → 307 redirects then a bot-wall pattern consistent with a JS/Cloudflare challenge, not a dead site. This is the same signature the pipeline already treats as fetch_tier: stealth, not evidence of no data — a plain/static fetch was not pushed past 5 request variations per the Tunnel Vision Rule; a real build attempt should escalate to StealthyFetcher before concluding the site has nothing.
• moc.gov.iq (Ministry of Communications): same HTTP/2 403 Cloudflare signature.
• data.gov.iq (guessed open-data portal): does not resolve (curl DNS failure) — no Iraqi government open-data portal found by search either. Ruled out, not just untried.
• No official downloadable postal-code file (CSV/PDF/API) was located in this pass via WebSearch. This is the actual gap: the system exists, but no bulk machine-readable export from Iraq Post/MoC was found — distinct from Syria, where no system exists at all.

4. Best available structured source right now (semi-official, tier 4)

Arabic Wikipedia, "قائمة الرموز البريدية في العراق" (List of postal codes in Iraq) — fetched and summarized 2026-09-17:

• Organizes codes by governorate, all 18 governorates present, city/district-level entries under each, citing "Iraqi postal code databases" as its source (not itself primary, but structured and large).
• Per-governorate entry counts summarized by the fetch: Baghdad 91, Anbar 22, Diyala 19, Salah ad-Din 14, Kirkuk 16, Ninawa 25, Duhok 13, Erbil 22, Sulaymaniyah 23, Babylon 20, Wasit 11, Najaf 7, Karbala 4, Qadisiyyah 18, Basra 32, Maysan 12, Dhi Qar 16, Muthanna 8 — ≈373 entries total (arithmetic sum of the above; not independently recounted against raw wikitext, so treat as approximate pending an actual scrape).
• The companion article "الرموز البريدية في العراق" (singular — narrative page) states the system "restarted on May 24, 2004," aligned with the English-page and UPU-PDF dating.
• Community aggregators found as tier 5/6 cross-check candidates, not primary sources: irq.postcodebase.com, azpostcodes.com/irq, worldpostalcode.com/iraq, getpostalcodes.com/iraq, en.56ok.com/zipcode_IQ, postal-codes.net/iraq, oscarte.iq (blog post reposting a list). Spot-checked example overlap: postcodebase.com lists Erbil 44001, consistent with the UPU-derived prefix — these read as downstream mirrors of the same Wikipedia/Iraqi-source table, not independent corroboration.

Licence flag on the Wikipedia table — needs a human decision before use, do not default: Wikipedia text is CC BY-SA (share-alike). This project has an existing precedent for exactly this conflict — the ESP entry in the CLAUDE.md registry ruled out Wikipedia as an admin source for a resold derivative specifically because CC BY-SA share-alike would encumber it, and required a non-Wikipedia register instead (INE for Spain). The postal-codes R2/datahub channel is a paid, resold product, so the same reasoning applies here unless a human decides otherwise. Recommendation: do not build from the Wikipedia table as a licence-clean primary source without an explicit decision: compatible call recorded in a licence_status block — per the Provenance & Licence Gate, this must not default to "unresolved-but-shipped."

5. Structural problem for a future build: governorate count is contested (18 vs 19) — Halabja

This is the real "structural complexity" in Iraq, and it sits on the admin side, not the postal-authority side:

• ISO 3166-2:IQ (Wikipedia, re-fetched 2026-09-17): 19 rows total = 18 governorates + 1 region (IQ-KR, "Iqlīm Kūrdistān," added 2022-03-03 purely as a parent-subdivision wrapper over IQ-AR (Arbīl), IQ-SU (As Sulaymānīyah), IQ-DA (Dahūk)). Halabja is NOT a separate ISO code — it does not appear in the table at all.
• GeoNames' admin1CodesASCII.txt for IQ, by contrast, has 19 numeric admin1 buckets, IQ.01–IQ.19, where IQ.19 = Halabja (geonameid 12218240 — a conspicuously high/recent ID consistent with a late addition) as a bucket distinct from IQ.05 = Sulaymaniyah.
• Reality: Halabja was carved out of Sulaymaniyah governorate as Iraq's own administrative addition in 2014, i.e. after both the 2004/2005 postal-code system and well before the 2022 ISO newsletter — yet ISO still hasn't given it a code, while GeoNames has.
• Net effect for a future build: the UPU/2005 postal scheme's "18 provinces" list and the ISO 3166-2:IQ code table (18 governorates + 1 region wrapper) agree with each other (both pre/non-Halabja), but disagree with GeoNames' own admin1 gazetteer (19, Halabja split out) and with Iraq's current on-the-ground administrative reality (19 governorates are commonly cited in current press/geography sources). Whether Halabja addresses use a distinct postal prefix, fall under Sulaymaniyah's 46 prefix, or are simply unaddressed by the 2004 scheme was not resolved in this pass — it would need to be checked against whatever bulk source is eventually scraped (does a 46xxx-adjacent or genuinely new prefix appear for Halabja towns?). Flagging this now so a future build doesn't silently drop Halabja or silently misassign it under Sulaymaniyah without checking.

6. GeoNames fallback assessment (per the standing "fallback of last resort" rule — assessed, not recommended)

• Postal export: https://download.geonames.org/export/zip/IQ.zip → confirmed 404 (curl -I, 2026-09-17). No GeoNames postal-code product exists for Iraq — consistent with Iraq Post not having contributed data to GeoNames' postal partner program.
• Main gazetteer dump: https://download.geonames.org/export/dump/IQ.zip → confirmed 200 OK, Content-Length: 2,800,469 bytes, Content-Type: application/zip. Downloaded and inspected directly:
  • IQ.txt: 55,961 total rows.
  • Feature class breakdown: P (populated places) 23,824 · S (spot/facility) 14,603 · H (hydrographic) 8,425 · L (parks/area) 4,304 · T (mountain/hill) 3,893 · V (forest/heath) 435 · R (road/railroad) 262 · A (admin boundary) 203 · U (undersea) 12.
  • Admin1 (governorate) distribution among the 23,824 P rows: all 19 numeric buckets present (01–19, i.e. including Halabja), ranging 410–2,559 rows each, plus 1 stray row on 00 and 1 on 19 that would need the usual blank-vs-guessed handling if ever built.
• This confirms a locality-only GeoNames build is technically viable (same shape as the SY/LY/ZW/BO/ET/UG builds already in this catalogue) — but per the task's explicit instruction #4 and the "GeoNames is fallback, not default" standing rule, this should NOT be the recommendation here, because a real 5-digit postal system demonstrably exists and no attempt to actually reach it (stealth-tier fetch of post.iq, or a real scrape of the Wikipedia table) has yet been made. Recommending the GeoNames path now would repeat exactly the failure mode the standing rule exists to prevent.

Recommended next step (research conclusion, no build performed)

1. Do not default to a GeoNames locality-only build. A real postal system exists; defaulting past it would misrepresent Iraq the same way a "no postal code" country is handled, which it is not.
2. First real next step for a postal-scraper pass: attempt StealthyFetcher against post.iq (and moc.gov.iq) to determine whether either site has a public postcode lookup tool or a downloadable list behind the Cloudflare wall — this was not pushed past a plain curl check in this research-only pass, per scope.
3. In parallel, resolve the Wikipedia CC BY-SA question with a human before treating the ~373-entry Arabic Wikipedia table as usable — same share-alike conflict already ruled on for ESP's admin source. If ruled incompatible for the resold R2 channel, the table may still be usable as a cross-check reference, just not as the licensed source of record.
4. Flag the Halabja/governorate-count mismatch (18 vs 19) to whoever scopes the actual build — it needs its own resolution (does the 2004 postal scheme cover Halabja under Sulaymaniyah's 46 prefix, under a new prefix, or not at all?) before an admin mapping registry row can be written.
5. Record a licence_status block with decision: "unresolved" if/when a manifest is opened for IQ — per the Provenance & Licence Gate, this is the correct, expected state for an open research question, not a failure to fix now.

Files/state touched in this pass

Nothing under datasets/iq/ was modified except this notes file. datapackage.yml and README.md were read only, not edited. No R2, git, or datapackage.yml changes were made, per the task's explicit scope.