Bangladesh National ID Card / Preserved Data Correction Application, Form-1 (Election Commission, National Identity Registration Wing)

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-2688. It opens Bangladesh's National ID & Civic Documents vertical, the last of Bangladesh's 6 verticals to open, using the National Identity Registration Wing's (NIDW, operating under the Bangladesh Election Commission) "Form-1" ("Application for Correction of Error(s) in the National ID Card or Preserved Data"). A sibling issue/PR (GOV-2687) authors Bangladesh's Business Formation vertical in parallel this cycle — see "Bangladesh's overall vertical status" below for how the two combine.

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

• Forms index: https://nidw.gov.bd/downloadForm.php — independently re-fetched this cycle via a Chrome-like-User-Agent curl (no TLS bypass needed for this host): HTTP 200, Content-Type: text/html; charset=UTF-8, 32,211 bytes. The page's own <title> reads ".: Bangladesh Election Commission :." and its form list carries the exact link text "1. Print Mistake Correction Form1.pdf." pointing at download/NIDForms/print_mistake_correction_form1.pdf.
• NIDW homepage: https://nidw.gov.bd/ — independently fetched, HTTP 200; its own prose refers to "NID Wing" as the operational unit handling NID issuance/correction, confirming authority.name ("National Identity Registration Wing (NIDW), Bangladesh Election Commission").
• PDF source: https://nidw.gov.bd/download/NIDForms/print_mistake_correction_form1.pdf — fetched independently this cycle via the same curl invocation:
  • HTTP 200, Content-Type: application/pdf, 146,866 bytes — matching the task briefing's own cited size exactly, independently re-derived.
  • sha256: a80ee2b64d89d5a540eeac21bbe2fff0c69b28e4df1da5bdec475e8a78ef593d (computed via sha256sum on the freshly-downloaded file).
  • The response's own Last-Modified header reads Wed, 07 Mar 2018 04:32:02 GMT, captured here to anchor a future re-verification diff.

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

• 2 pages.
• getFieldObjects() returned null, and both pages' getAnnotations() returned an empty array — this is a genuine static print-and-fill specimen with zero AcroForm/Widget annotations, unlike this registry's bd/dip schemas (e-passport, visa) or bd/brta's AcroForm-bearing DMV form.
• getTextContent() returned a text layer across both pages, position-sorted into rows by y-coordinate to reproduce the form's own reading order.

Bengali text-extraction encoding issue — investigated and fixed, not given up on

pdfjs-dist's raw getTextContent() output, read literally, is not directly legible Bengali — it is not mojibake in the "wrong codepage" sense, but a glyph-ordering artifact: the extraction follows the underlying content stream's glyph paint order, which for this PDF's embedded font is visual order, not Unicode logical order. Bengali has three dependent vowel signs that are pre-base in rendering but post-base in logical/Unicode storage — ি (U+09BF, vowel sign I), ে (U+09C7, vowel sign E), ৈ (U+09C8, vowel sign AI). Because they are painted before the consonant they modify, the raw extraction also emits them before that consonant, e.g. the very common word "পরিচয়" ("identity") was extracted as "পিরচয়" (the vowel sign ি and the consonant র swapped).

This was investigated, not written off as unreadable:

1. Confirmed the pattern was systematic (the same three vowel signs, the same swap direction) rather than random noise, by observing it recur identically across dozens of words.
2. Wrote a small, disposable Node post-processing script (not committed, per this registry's own established practice for one-off extraction tooling) applying one regex: for each pre-base vowel sign (ি/ে/ৈ) immediately followed by a virama-joined consonant cluster, move the vowel sign to after that cluster.
3. Re-ran the fix across the full extracted text of both pages. The result is substantially and legibly correct Bengali: recognizable, correctly-ordered government-form vocabulary throughout (জাতীয় পরিচয়পত্র "National ID card", সংশোধন "correction", আবেদনকারী "applicant", অভিভাবক "guardian", ঠিকানা "address", স্বাক্ষর "signature", মোবাইল নম্বর "mobile number", ইমেইল "e-mail", রক্তের গ্রুপ "blood group", জন্ম তারিখ "date of birth", etc.). Every field in this schema, the correction table's 9 subject rows, and all 6 of the page-2 instructions were read from this corrected text.

A residual, disclosed limitation: dropped conjunct ligatures

A handful of complex Bengali conjunct ligatures used by this PDF's embedded legacy font (e.g. ক্ষ "ksha", ত্র "tra") have no ToUnicode entry at all and extract as a blank space rather than a reordering-recoverable character — these are glyph-mapping gaps, not an ordering problem the regex above can fix.

An attempt was made to independently cross-check these specific gaps by rendering each page to a bitmap via pdfjs-dist's canvas API (node-canvas, page.render() at 3x scale). This did not work: the PDF's embedded TrueType font uses non-standard/malformed glyph hinting programs — pdfjs-dist logs a repeated "TT: CALL empty stack (or invalid entry)" warning for essentially every glyph on both pages while rendering — and the resulting bitmap paints no visible glyph outlines at all. This failure is itself informative: it corroborates that this document embeds a legacy, non-standard Bengali font whose both its ToUnicode CMap and its glyph program are unreliable, consistent with the reordering bug above, rather than being two unrelated defects.

Lacking a working visual cross-check, every ligature-dropped gap was resolved instead from the fixed, verbatim-repeated legal phrase it sits inside. The form's own title phrase — "জাতীয় পরিচয়পত্র বা সংরক্ষিত তথ্য-উপাত্ত" ("the National ID card or preserved data") — recurs identically at the top of page 1, in item ১, in item ৩'s table header, and in page-2 instructions ১/২/৪, always with the exact same single dropped syllable in the exact same word ("সংরক্ষিত" → "সংরি ত"). Recognizing the same, common, unambiguous administrative term recurring identically across five independent locations in the same document is treated here as a disclosed judgment call, not an independently re-derived fact of the same weight as the mechanical reordering fix above.

Form structure and scoping decisions

In scope (30 fields[] + 4 documents[] entries)

• Application type (applicationType): a printed "জরুরী/সাধারণ" (Urgent/Regular) checkbox pair, appearing on both the main application and its tear-off receipt, corroborated by page-2 instruction 4's own differential processing time (7 working days urgent vs. 30 regular). Modeled as enum, required: true.
• Item ১ (identity of the NID card holder / applicant): Name, National ID Number — applicantName, applicantNidNumber, both required: true.
• Item ২ (legal guardian, applicable when the NID holder is a minor or court-declared incompetent): Name, National ID Number — guardianName, guardianNidNumber. The source's own item ২ heading and page-2 instruction 2 make this block conditionally mandatory, but — the same disclosed judgment call this registry's bd/dip e-passport schema already made for its own guardian block — the form provides no dedicated boolean field (e.g. an "is the card holder a minor?" checkbox) to gate a requiredWhen condition against. Rather than inventing one, both fields are modeled as unconditionally optional.
• Item ৩ (the correction table, 9 printed subject rows, each with a current-value and a requested-new-value column): Name (Bengali), Name (English), Father's Name, Mother's Name, Spouse's Name, Date of Birth, Address, Blood Group, Other — modeled as 18 flat fields (correction<Subject>Current/correction<Subject>New), all optional. The table's own instruction ("অপ্রয়োজনীয় অংশ কর্তন করিয়া দিন" — cross out the unneeded rows) confirms an applicant fills in only the row(s) relevant to their specific correction request, so no row can be marked unconditionally required; this registry's v0.3 field model is flat (no nested/array fields, per spec §6.1), so the table's rows are expressed this way rather than as a repeating group. Blood Group is kept string, not enum: this is a blank fill-in on a static, non-AcroForm specimen with no embedded or printed option list to model a closed set from — inventing an 8-value (A+/A-/etc.) enum without direct source evidence would violate this registry's "never invent an enum without a source-provided option list" convention.
• Other row (item ৩'s ninth, catch-all row): correctionOtherFieldName (which field), correctionOtherCurrentValue, correctionOtherNewValue.
• Signature block (bottom of page 1, two columns — Applicant's signature/thumbprint, Legal Guardian's signature/thumbprint if applicable): each column separately prints Name/Address/Mobile Number/E-mail alongside the signature line. The Name in this block is the same underlying fact already captured as applicantName/guardianName above and is not re-modeled as a duplicate field (disclosed consolidation decision, to avoid two fields asserting the same data point under different names). Address and Mobile Number are new facts not captured elsewhere on the form and are modeled required: true for the applicant column (no asterisk convention exists on this static form, but these are the applicant's own basic contact particulars with no "if applicable" qualifier printed near them, unlike E-mail, whose own label reads "ই-মেইল (যদি থাকে)" — "E-mail, if any" — explicitly optional). guardianAddress/guardianMobileNumber/guardianEmail mirror the same three facts for the guardian column, unconditionally optional for the same reason as guardianName above.

Out of scope, disclosed

• Serial Number and Application Date (top of page 1): both sit directly beneath a printed "(অফিস কর্তৃক পূরণীয়)" ("to be filled by the office") heading — office-entered, not applicant-entered, data.
• The tear-off acknowledgement-receipt section ("অংশ-ক (ফরম-১)" — "Part-A (Form-1)"): a duplicate summary restating the applicant's/guardian's Name and National ID Number, the Application Date, plus office-only fields (the responsible officer's signature/seal, and the next-contact/NID-issuance date, both filled in when the office later hands the receipt back — see page-2 instruction 4). Excluded as a receipt slip that duplicates already-captured applicant data plus office-only content, consistent with this registry's convention of not double-modeling a restated receipt (see bd/dip/e-passport-application-form's own exclusion of its Online Registration ID/Payment Reference items on the same reasoning).
• No payment/fee requirement is modeled. Page-2 instruction 5 states explicitly: "অত্র আবেদনের জন্য আবেদনকারীকে কোনো ফি/চার্জ প্রদান করিতে হইবে না" ("The applicant shall not have to pay any fee/charge for this application") — a genuine, source-confirmed negative finding, not an omission.

Documents (documents[])

• applicantNidPhotocopy (identity-document, required: true) — page-2 instruction 3 unconditionally requires a photocopy of the NID holder's own National ID Card.
• guardianNidPhotocopy (identity-document, required: false) — page-2 instruction 2 makes this mandatory specifically when the card holder is a minor/court-declared incompetent, but — for the same reason as guardianName above — no boolean gate field exists, so this is modeled unconditionally optional and the conditional requirement is disclosed in the entry's own handling text rather than fabricated as a machine-checked gate.
• correctionSupportingDocument (supporting-evidence, required: false) — the correction table's own fourth column ("মন্তব্য/দলিলাদি" — Remarks/Documents) implies supporting proof accompanies specific corrections (e.g. a birth certificate for a date-of-birth correction), but the form itself provides no discrete, itemized per-row document checklist the way bd/dip/e-passport -application-form's attachment list does. Modeled as one generic optional entry rather than fabricating a per-row requirement the source does not spell out.
• applicantSignatureAttestation (attestation, required: true) — the signature/thumbprint of the applicant, or of the legal guardian if the card holder is a minor/court-declared incompetent. No verbatim declaration sentence ("I hereby declare...") is printed near the signature line on this form (unlike, e.g., bd/dip/e-passport-application-form's own Declaration block), so no statement text is cited.

Language

process.language is bn (Bengali): the form's text is Bengali throughout; only the parenthetical "(NID)" abbreviation survives as Latin-script text anywhere on the form. This distinguishes it from bd/dip's fully bilingual (Bengali-primary/English-secondary) passport and visa specimens.

Bangladesh's overall vertical status

At the time this cycle authored this schema, Bangladesh had 4 of 6 verticals published (Taxes, DMV, Passport, Visa) plus this cycle's National ID & Civic Documents (5th), with Business Formation being authored in parallel via a sibling issue/PR (GOV-2687, registry/bd/roc/). Whether Bangladesh reaches 6 of 6 depends on whether that sibling PR has landed on main by the time this PR is reviewed — see this PR's own description and CATALOG.md's Executive Summary entry for the count current as of this PR's opening.

Conformance run

Two hand-authored valid fixtures under conformance/bd/nidw/nid-correction-application-form-1/1.0.0/:

• valid-adult-name-correction.json — an adult applicant (no guardian), a regular (non-urgent) application, correcting only their Bengali-script name (row (ক)).
• valid-minor-with-guardian-dob-blood-group-correction.json — a minor applicant with a legal guardian, an urgent application, correcting both Date of Birth (row (চ)) and Blood Group (row (জ)), with full guardian contact particulars and all 4 documents[] entries provided.

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,pattern,maxLength} grammar plus documents[].required directly against spec/v0.3/SPEC.md's rules:

`` $ node check_conformance.mjs schema.json \ valid-adult-name-correction.json \ valid-minor-with-guardian-dob-blood-group-correction.json valid-adult-name-correction.json: 0 error(s) valid-minor-with-guardian-dob-blood-group-correction.json: 0 error(s) ``

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

• mutation-control-missing-applicant-name.json — drops applicantName (a static required: true field) from the adult valid fixture.
• mutation-control-missing-applicant-address.json — drops applicantAddress.
• mutation-control-missing-applicant-mobile-number.json — drops applicantMobileNumber.
• mutation-control-invalid-enum-application-type.json — sets applicationType to "walk-in", not one of the enum's 2 values.
• mutation-control-missing-required-document-nid-photocopy.json — removes the applicantNidPhotocopy entry from documents[], isolating the required-document check.
• mutation-control-invalid-email-pattern.json — starts from the guardian valid fixture (which populates applicantEmail) and sets it to "not-an-email", violating its regex pattern.

`` $ node check_conformance.mjs schema.json \ mutation-control-missing-applicant-name.json \ mutation-control-missing-applicant-address.json \ mutation-control-missing-applicant-mobile-number.json \ mutation-control-invalid-enum-application-type.json \ mutation-control-missing-required-document-nid-photocopy.json \ mutation-control-invalid-email-pattern.json mutation-control-missing-applicant-name.json: 1 error(s) - applicantName: required but missing mutation-control-missing-applicant-address.json: 1 error(s) - applicantAddress: required but missing mutation-control-missing-applicant-mobile-number.json: 1 error(s) - applicantMobileNumber: required but missing mutation-control-invalid-enum-application-type.json: 1 error(s) - applicationType: value "walk-in" not in enum ["urgent","regular"] mutation-control-missing-required-document-nid-photocopy.json: 1 error(s) - documents.applicantNidPhotocopy: required document not provided mutation-control-invalid-email-pattern.json: 1 error(s) - applicantEmail: value "not-an-email" does not match pattern ^[^@\s]+@[^@\s]+\.[^@\s]+$ ``

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/nidw/nid-correction-application-form-1/1.0.0/schema.json ok registry/bd/nidw/nid-correction-application-form-1/1.0.0/schema.json 1/1 document(s) passed.

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

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

Scope and jurisdiction notes

• Opens Bangladesh's National ID & Civic Documents vertical, its last remaining open vertical.
• jurisdiction.level is national — NIDW/the Bangladesh Election Commission is Bangladesh's national identity-registration authority.
• process.type is amendment — this form corrects/amends already-registered NID data, rather than an original application.
• Companion candidate for a future cycle: NIDW's Form-6 ("Lost/Duplicate NID Reissue"), located at https://nidw.gov.bd/download/NIDForms/lost_duplicate_form6.pdf (908,653 bytes per this cycle's scouting; not independently re-verified in this cycle since it is out of this v1.0.0's scope) and mirrored at https://services.nidw.gov.bd/resources/forms/New_Lost_Form.pdf. This would model the lost/damaged-card reissue process rather than a data-correction process, and NIDW's own downloadForm.php index also lists a Form-14 ("ID Card Correction Form") not investigated this cycle.
• The live online submission portal (services.nidw.gov.bd) requires login to actually file — only the downloadable specimen PDF is unauthenticated — consistent with this registry's existing precedent (BRTA, DIP) that a genuine print-and-fill specimen is sufficient basis for a schema even when live online submission itself sits behind a portal login.

Re-verification

Per the practice's cadence, nextReviewBy is set to 2027-01-13 (6 months). A future review should prioritize: (1) confirming the PDF has not been silently replaced with a revised edition (this cycle captured its Last-Modified: Wed, 07 Mar 2018 04:32:02 GMT header to anchor a future diff); (2) whether NIDW's Form-6 (lost/duplicate reissue) or Form-14 (a second, differently-named correction form also listed on the same index) warrant a companion schema; (3) whether a future cycle can find a working image-rendering path for this PDF's malformed embedded font, to independently re-confirm the small number of conjunct-ligature-dropped words resolved this cycle by textual-repetition inference rather than direct visual read.