Bangladesh e-Passport Application Form (New/Re-Issue) (Department of Immigration and Passports)

This file is the source-review record for this document version, per the manual-source-review-v1 practice.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-13
• maturity.level: structural-reference

This is GovSchema Standard Research cycle GOV-2666. It opens Bangladesh's Passport vertical (3 of 6), using the Department of Immigration and Passports' (DIP) "e-Passport Application Form (New/Re-Issue)". Bangladesh previously had two published verticals (Taxes — bd/nbr/individual-income-tax-return-form-it-11ga; DMV — bd/brta/motor-vehicle-registration-application).

Reverses a prior dead-end verdict

GOV-2591's cycle screened Bangladesh's Passport vertical and characterized it as weak/dead-end (Bangladesh's e-passport process is primarily an online portal — epassport.gov.bd — with no fillable PDF specimen located at the time). This cycle found the Ministry of Foreign Affairs' (MOFA) own forms portal (mofa.gov.bd/pages/forms/*) hosts a genuine, unauthenticated, interactive AcroForm PDF distributed specifically for offline/embassy submission of this same process — the same class of reversal already recorded for Bangladesh's DMV vertical (GOV-2644's BRTA finding).

Source verification (independently re-derived, not copied from the task briefing)

• Landing page: https://mofa.gov.bd/pages/forms/69959494fcf25ca2d1011a0e — independently re-fetched this cycle via curl -sk -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36" (TLS certificate verification fails on this host by default, consistent with the task briefing's note and the same pattern already seen for BRTA/RJSC/ECS elsewhere in this registry): HTTP 200, Content-Type: text/html; charset=utf-8, 72,484 bytes.
• PDF source: https://objectstorage.ap-dcc-gazipur-1.oraclecloud15.com/n/axvjbnqprylg/b/V2Ministry/o/office-mofa/2026/1/a04a6c52-75cf-4edb-820c-0f4dd0f9ecfe.pdf — fetched independently this cycle via the same insecure-TLS curl invocation (this object-storage host also fails default certificate verification):
  • HTTP 200, Content-Type: application/pdf, 4,114,743 bytes.
  • sha256: 477e229ac2869691f6bd2a09be01af0d7ebb22cdae0e4591db7687e6ac7dd862 (computed via sha256sum on the freshly-downloaded file).
  • All three figures were independently re-derived this cycle and match the task briefing's own cited figures exactly.
  • The response's own last-modified header reads Wed, 18 Feb 2026 10:29:40 GMT, captured here to anchor a future re-verification diff.
• The form's own footer text confirms the issuing agency: "Government of the People's Republic of Bangladesh, Department of Immigration and Passports, www.dip.gov.bd" — MOFA is merely the offline-distribution host, not the issuing agency, hence registry/bd/dip/, not registry/bd/mofa/.

PDF structure, independently confirmed via pdfjs-dist@4 (legacy build)

• 3 pages, matching the task briefing.
• getFieldObjects() returned 111 distinct field names across the document's AcroForm Widget annotations (the task briefing's own count of 114 widgets is also consistent: a handful of field names — e.g. Road_block_info — repeat across multiple widget rectangles, since they are decorative per-section "ⓘ" info-icon push buttons appearing next to more than one field, not distinct data-bearing fields; getFieldObjects() groups these under one name).
• getTextContent() returned a full, clean, bilingual (Bengali primary, English secondary) text layer across all 3 pages. Every printed item number (1-87), label, and required-field asterisk was read directly from this text layer, position-sorted into rows, and cross-checked against the task briefing's own transcription — it matches field-for-field, including every asterisk placement.

A significant data-quality finding: AcroForm field names do not track printed item numbers

Independently correlating every Widget annotation's page/rect coordinates against the position-sorted text layer (grouping widgets into rows by rounded y-coordinate, then left-to-right by x, which reproduces the form's own reading order and therefore its own item numbering) revealed that the PDF's internal AcroForm field names — mostly plain numeric strings — do not reliably correspond to the form's own printed item numbers. For example, in the (out-of-scope) Previous-Passport/Re-Issue row:

• Printed item 9 ("Previous Passport No.") is internal field name "9" — matches.
• Printed item 10 ("Date of Issue") is internal field name "11".
• Printed item 11 ("Date of Expiry") is internal field name "12".
• Printed item 12 ("Reason for Re-Issue") is internal field name "10".

Similar scrambles recur in the (out-of-scope) "Additional Information for Official and Diplomatic Passport" block (items 32-37) and, more importantly, within the in-scope Permanent/Present Address blocks (e.g. printed item 38 "District" is internal field name "37"; printed item 44 "Country" is internal field name "42"). Given this, every field in this schema was identified by its on-page position and printed label, never by trusting the internal PDF field name — the field's own name in this schema.json is a GovSchema-authored camelCase key, not copied from the AcroForm.

Two auxiliary widgets were also excluded on this basis: an internal field named "0" (a tiny widget at the very bottom of page 1, value "0.90", evidently an internal PDF/form-version marker) and an internal field named "88" positioned between printed items 3 and 4 with no printed label of its own and a default value of "N/A" — excluded as a non-conforming artifact widget, alongside items 1-3 (see below).

Combobox option-list check

Corrected 2026-07-13 per GOV-2672 (review gate GOV-2668 requested changes on PR #438). The original claim below was false and is struck through for the record; see "GOV-2672 correction" immediately after it for what actually holds.

~~getFieldObjects() exposes each combobox's embedded /Opt option array (via its options member). All 33 combobox-typed fields in this document returned options: null — no embedded option list on any of them — so, per this registry's own established convention (bd/brta, th/dlt), none is modeled as enum purely on the basis of being rendered as a dropdown.~~

GOV-2672 correction

The .options member checked above does not exist on pdfjs-dist's getFieldObjects() result — it always reads undefined (loosely null), regardless of whether the combobox has an option list. The correct property is .items (an array of {exportValue, displayValue}), confirmed by re-reading pdfjs-dist@4's own FieldObject type. Independent re-extraction against the same freshly re-downloaded, hash-verified PDF (see "Source verification" above — unchanged, same sha256) using .items found 24 of this form's combobox-typed fields do carry a genuine embedded option list, not the near-blanket "options: null" the v1.0.0 draft reported.

Every one of these 24 comboboxes is also flagged editable: true in its field object (an "editable combo box": the AcroForm widget lets the user type a value outside the printed list, not just pick one) — checked directly against the PDF's own field flags, not inferred. This matters for the enum-vs-free-text call below: editable: true alone does not disqualify a field from enum (passportType/gender, discussed next, are themselves editable combos, corroborated instead by independent form text), but it does mean "this combobox has a dropdown" is not, by itself, evidence the value space is closed — the form's authors may have made a list editable specifically because it is not exhaustive.

Fields converted from free-text string to enum this correction, each backed by either an explicit "OTHER(S)" catch-all in the source's own list or a functionally exhaustive world country/nationality/calling-code list (this registry already accepts large genuine-source enums at this scale — see ph/comelec/overseas-voter-registration's and nl/denhaag/voter-registration-abroad's 247-value country enums):

• numberOfPages (2: 48 PAGES/64 PAGES), durationOfPassport (2: 5 YEARS/10 YEARS), typeOfDelivery (3: REGULAR/EXPRESS/SUPER EXPRESS) — the three smallest, most clearly closed sets.
• religion (8 values + OTHERS), typeOfCitizenship (6, incl. OTHER), maritalStatus (5), emergencyContactRelationship (26 + OTHERS).
• profession/fatherProfession/motherProfession/guardianProfession/ spouseProfession (61 values + OTHERS, one shared list).
• countryOfBirth/countryOfOtherCitizenship/presentCountry/ emergencyContactCountry (244 values, one shared world-country list).
• fatherNationality/motherNationality/guardianNationality/ spouseNationality (236 values, one shared world-nationality list).
• contactCountryCode/emergencyContactCountryCode (226 distinct calling codes after de-duplication — the source list repeats a code once per country that shares it, e.g. "1" for every NANP country; de-duplicated before use as an enum, order otherwise preserved).
• passportOfficeOrMission (154 values after de-duplication: DIP's own passport offices plus Bangladesh's diplomatic missions — the authoritative, DIP-controlled set of places this application can be filed).

Fields where .items returned a genuine list but the field is deliberately kept free-text (disclosed in each field's own description):

• districtOfBirth, permanentDistrict, presentDistrict, emergencyContactDistrict — all four share one 64-value list of Bangladesh's own administrative districts only, with no catch-all, and the source's own dependent-field JavaScript (attached to permanentDistrict and presentDistrict's underlying widgets) keys the adjacent Post Office/Police Station comboboxes off this same district list — clear evidence the list is meant to be exhaustive for a Bangladesh address. But this schema already discloses (and a committed conformance fixture already exercises) present/emergency-contact addresses abroad (presentCountry/emergencyContactCountry are not Bangladesh-restricted), and countryOfBirth is a full 244-country list, so an applicant can legitimately be born abroad or reside abroad while this district combobox's option list offers no matching (or "other") value. Enum-ing these four would make a real, already-disclosed scenario inexpressible, so — unlike every other corrected field above — they remain string.
• Permanent/Present/Emergency-Contact Police Station and Post Office fields — re-checked and confirmed genuinely blank (.items returns a single empty-string entry); the v1.0.0 draft's finding for these specifically was correct, just for the wrong reason (it read .options, which is also blank/absent here, coincidentally reaching the right conclusion).

passportType and gender were already correctly modeled as enum pre-correction, from independent textual corroboration rather than the (broken) combobox check, and are unchanged:

• passportType — modeled as a 3-value enum (ordinary/official/ diplomatic) because two independent pieces of the form's own text corroborate a closed 3-way set: the combobox's own default value is "ORDINARY", and the form's own "Additional Information for Official and Diplomatic Passport" section heading (items 32-37) independently names the other two categories. Its combobox's .items now also directly confirm the same 3-value set (ORDINARY/OFFICIAL/DIPLOMATIC).
• gender — modeled as a 3-value enum (female/male/other) because its own printed Bengali parenthetical translation literally lists the three options ("নারী/ পুরুষ / অন্যান্য" — "Female/Male/Other"), the same class of exception this registry already uses for bd/brta's vehicleOrTrailer field. .items confirms the same 3-value set (MALE/FEMALE/OTHER).

Split-widget fields

Three printed items are genuinely two adjacent AcroForm widgets, not one, and are modeled as two fields each:

• Item 30 ("Contact No.") — a country-code combobox (default "880", Bangladesh's own calling code) plus a free-text number field → contactCountryCode + contactNumber.
• Item 76 ("Contact No.", Emergency Contact) — the same pattern → emergencyContactCountryCode + emergencyContactNumber.
• Item 87 ("Paid Amount") — a free-text amount field (paidAmount) plus an adjacent combobox. The v1.0.0 draft excluded this companion combobox as "unclear" (a blank-default widget with no distinguishing printed sub-label). Corrected 2026-07-13 per GOV-2672: the same .items re-extraction that fixed the combobox option-list check (above) found this companion combobox in fact carries a genuine 2-value list (BDT/USD), so it is no longer excluded — it is now modeled as paidAmountCurrency, an enum field. The unlabeled "88" widget is unrelated (not a combobox) and remains excluded on its own basis.

Scoping decision

In scope (72 fields[] + 5 documents[] entries — 71 + paidAmountCurrency, added per the GOV-2672 correction above)

This v1.0.0 scopes to the first-time (new) applicant pathway of this combined New/Re-Issue form:

• Passport request (items 4-8): Passport Office/Bangladesh Mission, Passport Type, Number of Pages, Duration of Passport, Type of Delivery. Items 1-3 (Online Registration ID/Payment Reference/Payment Amount) are excluded: their own embedded default field values read "OFFLINE APPLICATION", "N/A", "N/A" respectively, directly confirming (from the PDF's own data, not inference) that these are online-system auto-fill fields inapplicable to this offline specimen — not data the applicant themselves enters.
• Personal Information (items 13-31): Full Name, Given Name, Surname, Date of Birth, Country/District/Place of Birth, Gender, Religion, National ID No., Birth Registration No., Type of Citizenship, Dual Citizenship Status, Country of Other Citizenship, Foreign Passport No., Marital Status, Profession, Contact No. (2 fields), E-mail.
• Permanent Address (items 38-43) and Present Address (items 44-50) — 6 and 7 fields respectively.
• Parental Information (items 51-58): Father's/Mother's Name, Nationality, National ID No., Profession.
• Guardian Information (items 59-62): modeled, but unconditionally optional. The source's own item 59 label reads "Guardian's Name – if applicable (as per NID/BRC)", and the page-3 declaration's signature line reads "Signature of Applicant/Guardian (if Applicant is minor)" — together implying this block is meant for a minor applicant — but the form provides no dedicated age/minor boolean field anywhere to gate a requiredWhen condition against, so a fabricated gate is not invented; all four guardian fields are left optional, consistent with this registry's convention of not inventing conditions the source does not itself provide.
• Spouse Information (items 63-66): all four fields, none printed with an asterisk (applicable only if married).
• Emergency Contact (items 67-77): Name, Relationship, Country, District, Police Station, Post Office, Postal Code, City/Village/House, Road/Block/Sector, Contact No. (2 fields), E-mail.
• Bank Payment Information (items 84-87): Bank Name, Payment Reference No., Payment Date, Paid Amount. Deviation from the task briefing's own suggested scoping: the task flagged this block as possibly a system/office-generated payment receipt rather than applicant-entered data. Independent inspection found no "for office use"/"to be filled in by the office" heading anywhere near these four items (unlike bd/brta/motor-vehicle-registration-application's own genuinely office-only Section-1 intake box, which is headed that way) — these are ordinary fillable AcroForm widgets, consistent with Bangladesh's common practice of paying a government fee via a manually-completed bank challan and then citing that receipt's own bank name/reference/date/amount on the application itself. They are therefore modeled as applicant-supplied fields, all optional (none carry a printed asterisk).
• List of Attachments (4 of the printed checklist's 10 checkboxes): Photocopy of National ID, Photocopy of Birth Registration Certificate, Photocopy of Marriage Certificate, Other — modeled as documents[] entries, all required: false. The form's own instruction header ("Please fill up the application form page 1 to 3 as per National ID/Birth Registration Certificate") implies at least one of National ID or Birth Registration Certificate is expected from every applicant; this is disclosed in each document entry's handling text rather than machine-encoded, consistent with this registry's established convention for source-disclosed-but-ungated "at least one of" business rules (e.g. rw/dgie/passport-application-first-adult's phone-or-email precedent).
• Declaration (page 3): modeled as a documents[] attestation entry (declarationAttestation, required: true) carrying the declaration's verbatim statement text, plus a companion declarationDate field. This last is a disclosed judgment call: a genuine AcroForm text widget (internal name "200") was found in the page-3 declaration/signature area, but its rect sits roughly 70-90pt below the printed "Date ___ Signature ___" line rather than directly beneath either blank. It is nonetheless the only unclaimed fillable widget anywhere in that region of page 3, so it is modeled here as the date accompanying the applicant's/guardian's signature, left optional (no printed asterisk is visible for it either way).

Out of scope, disclosed

• Items 1-3 (Online Registration ID, Online Payment Reference, Online Payment Amount) — confirmed online-system auto-fill fields via their own embedded default values ("OFFLINE APPLICATION"/"N/A"/"N/A"), not applicant-entered data on this offline specimen.
• Items 9-12 (Previous Passport No., Date of Issue, Date of Expiry, Reason for Re-Issue) — re-issue-only; the form's own page-1 note states re-issue-without-change applicants need only fill items 1-37, implying these are populated when the applicant already holds — and is re-issuing — a passport, which cannot apply to a first-time applicant.
• Items 32-37 ("Additional Information for Official and Diplomatic Passport": GO/NOC/Others, Issuing Authority, Reference No., Date, Date of Retirement, Passport Application for) — a narrower official/diplomatic sub-pathway, out of scope for this general first-time-applicant v1.0.0. A future companion schema could model this sub-pathway, mirroring this registry's own established companion-schema pattern (e.g. the CH-ZH Hilfsblatt series, the GR AADE Ε2/Ε3 forms).
• Items 78-79 ("Pre-Police Clearance Information if applicable") — the source itself flags this as conditional but discloses no gating field, and it is plausibly tied to specific occupational/re-issue scenarios; left out of scope per the task's own suggestion, disclosed here as an open question for a future cycle rather than resolved.
• Items 80-83 ("Information for Lost/Stolen Passports") — by definition a re-issue-only scenario (a first-time applicant has never held, and therefore cannot have lost or had stolen, a passport).
• 6 of the 10 List-of-Attachments checkboxes: Photocopy of Previous Passport (re-issue-only), NOC and GO (tied to the official/diplomatic sub-pathway, items 32-33), Retirement Document (tied to item 36, Date of Retirement, itself official-passport-only), Pre-Police Clearance Certificate and G.D. (tied to the excluded items 78-83 above).
• The companion combobox behind item 87 ("Paid Amount") — see "Split-widget fields" above.
• Decorative "ⓘ" info-icon push-button widgets (Perm_addr_info, Curr_addr_info, Guardian_info, District_info, Road_block_info ×4, Lost_info) — confirmed via pdfjs-dist's own "Push buttons without action dictionaries are not supported" warning: these are non-interactive decorative icons with no associated action, not data-bearing fields.
• The page-1 barcode/QR annotation (Barcode) — confirmed via pdfjs-dist's own "Barcodes are not supported" warning: an image-bearing annotation, not applicant input.

Language

process.language is set to bn (Bengali): the form's own title block leads with the Bengali title ("ই-পাসেপাটর্ আেবদন ফরম") before the English translation, and the issuing government's own official language is Bengali, distinguishing this schema from bd/nbr and bd/brta (both genuinely English-only text layers). Every field label on this form is bilingual (English first, Bengali parenthetical, on most rows) — this is disclosed as a judgment call, since the form is functionally usable in either language.

Conformance run

Re-run 2026-07-13 per GOV-2672. Converting 24 fields from free-text string to enum (see "GOV-2672 correction" above) invalidated several fixture values that were free-form prose standing in for what are now closed sets (e.g. maritalStatus: "Unmarried" — not a member of the corrected 5-value enum; countryOfBirth: "Bangladesh" — the corrected enum's actual member is the source's own verbatim casing, "BANGLADESH"). All 8 fixtures were updated to use real enum member values (verbatim source casing, e.g. "ENGINEER", "BANGLADESHI", "SINGLE") wherever a field they populate was converted; fields kept free-text (the four district fields, Police Station/Post Office, City/Village/House, etc.) are untouched. The valid-married-dual-citizen-applicant-with-guardian.json fixture also gained a paidAmountCurrency: "BDT" entry alongside its existing paidAmount, to exercise the new field.

Two hand-authored valid fixtures under conformance/bd/dip/e-passport-application-form/1.0.0/:

• valid-single-first-time-applicant.json — an unmarried, single- citizenship applicant applying for an ordinary passport at a domestic passport office; no guardian/spouse/bank-payment data populated (all optional, left absent).
• valid-married-dual-citizen-applicant-with-guardian.json — a married, dual-citizen applicant applying for a diplomatic passport at an overseas mission, exercising dualCitizenshipStatus: true's requiredWhen gate on countryOfOtherCitizenship/foreignPassportNo, plus a fully populated spouse block, guardian block, bank payment block, and declarationDate.

Both were checked with a from-scratch Node conformance checker (check_conformance.mjs, not committed — a disposable script, per this registry's own established practice) implementing this schema's own required/requiredWhen/type/validation.{enum,minimum,maximum,pattern, minLength,maxLength} grammar directly against spec/v0.3/SPEC.md's rules:

`` $ node check_conformance.mjs schema.json \ valid-single-first-time-applicant.json \ valid-married-dual-citizen-applicant-with-guardian.json valid-single-first-time-applicant.json: 0 error(s) valid-married-dual-citizen-applicant-with-guardian.json: 0 error(s) ``

Six mutation-control fixtures, each isolated to raise exactly one error:

• mutation-control-missing-full-name.json — drops fullName (a static required: true field) from the single-applicant valid fixture.
• mutation-control-missing-permanent-district.json — drops permanentDistrict.
• mutation-control-invalid-enum-gender.json — sets gender to "unknown", not one of the enum's 3 values.
• mutation-control-invalid-enum-passport-type.json — sets passportType to "tourist", not one of the enum's 3 values.
• mutation-control-invalid-email-pattern.json — sets email to "not-an-email", violating its regex pattern.
• mutation-control-missing-conditional-foreign-passport-no.json — starts from the dual-citizen valid fixture and drops only foreignPassportNo, isolating the requiredWhen violation (since dualCitizenshipStatus is still true and countryOfOtherCitizenship is still present in that fixture).

`` $ node check_conformance.mjs schema.json \ mutation-control-missing-full-name.json \ mutation-control-missing-permanent-district.json \ mutation-control-invalid-enum-gender.json \ mutation-control-invalid-enum-passport-type.json \ mutation-control-invalid-email-pattern.json \ mutation-control-missing-conditional-foreign-passport-no.json mutation-control-missing-full-name.json: 1 error(s) - fullName: required but missing mutation-control-missing-permanent-district.json: 1 error(s) - permanentDistrict: required but missing mutation-control-invalid-enum-gender.json: 1 error(s) - gender: value "unknown" not in enum ["female","male","other"] mutation-control-invalid-enum-passport-type.json: 1 error(s) - passportType: value "tourist" not in enum ["ordinary","official","diplomatic"] mutation-control-invalid-email-pattern.json: 1 error(s) - email: value "not-an-email" does not match pattern ^[^@\s]+@[^@\s]+\.[^@\s]+$ mutation-control-missing-conditional-foreign-passport-no.json: 1 error(s) - foreignPassportNo: required but missing ``

All six negative controls raised exactly one error each, and neither valid scenario raised an unexpected error.

Both registry validators were run against the schema document and pass:

``` $ node tools/validate.mjs registry/bd/dip/e-passport-application-form/1.0.0/schema.json ok registry/bd/dip/e-passport-application-form/1.0.0/schema.json 1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/bd/dip/e-passport-application-form/1.0.0/schema.json ok registry/bd/dip/e-passport-application-form/1.0.0/schema.json [v0.3] 1/1 document(s) validated against the meta-schema (ajv 2020-12). ```

(tools/node_modules did not have ajv/ajv-formats present in this worktree at the start of this cycle; ran npm ci --include=dev inside tools/ first, per this registry's own known NODE_ENV=production gotcha.)

tools/govschema-client/registry-index.json was regenerated via npm run build-index inside tools/govschema-client/.

Scope and jurisdiction notes

• Opens Bangladesh's Passport vertical (3 of 6); Taxes and DMV are already published. Business Formation, Visa, and National ID remain open backlog per prior cycles' screening.
• jurisdiction.level is national — DIP is Bangladesh's national passport and immigration authority.
• process.type is application; see "Language" above for the process.language: bn judgment call.
• Companion candidates for a future cycle: (1) the official/diplomatic sub-pathway (items 32-37) excluded here, as its own companion schema, mirroring this registry's CH-ZH Hilfsblatt / GR AADE Ε2-Ε3 companion- schedule precedent; (2) the re-issue pathway (items 9-12, 78-83), which would need this same form modeled from the opposite (holder-already-has- a-passport) angle; (3) Bangladesh's remaining Business Formation, Visa, and National ID verticals.

Re-verification

Per the practice's cadence, nextReviewBy is set to 2027-01-13 (6 months). A future review should prioritize: (1) confirming the object-storage-hosted PDF has not been silently replaced with a revised edition (this cycle captured its last-modified: Wed, 18 Feb 2026 10:29:40 GMT header to anchor a future diff, unlike the BRTA cycle's PDF host, which returned no such header); (2) re-attempting DIP's own site (dip.gov.bd)/the online e-passport portal (epassport.gov.bd) directly, in case a more authoritative first-party specimen becomes reachable in the future; (3) whether a future cycle wants to model the official/diplomatic sub-pathway or the re-issue pathway as separate companion schemas.