Nepal — Department of Passports Machine Readable Passport (MRP) Offline Application Form

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-15

Why this schema and why now (GOV-3206, delegated from GOV-3204)

GOV-3204 ("GovSchema Standard Research") re-scanned CATALOG.md's disclosed backlog and found GOV-3078's own left-open finding: Nepal's Department of Passports "MRP Offline Application Form" — a genuine, currently-live, unauthenticated single-page AcroForm PDF found on the department's own Downloads page — was screened and confirmed strong, but left unauthored because every one of its 337 widgets uses a flat, semantically meaningless internal naming scheme (sur1..sur337) rather than one field per named datum, requiring widget-geometry and label-proximity reconstruction. This issue (GOV-3206) picks up that exact disclosed backlog item rather than re-scouting fresh candidates.

Source

• Downloads page: https://nepalpassport.gov.np/downloads (form labeled "MRP Offline Application Form").
• Direct PDF: https://verification1.nepalpassport.gov.np/uploads/g_Q6z_W_Hj_Ic_DQM_Oqn_Guq_G_Tz_Npa_ZXJYNC_meta_Zm9yb_T_It_NG_12_Mi0x_Ln_Bk_Zg_0cffb4c683.pdf
• Retrieved: 2026-07-15, HTTP 200, application/pdf, 2,827,163 bytes.
• sha256: 603d84d1e91be379ab9c438426392b71143073ece7f87cc0a750f76c5d4d411b — independently re-derived this cycle via a fresh curl fetch, matching the hash recorded in this issue's own brief exactly.
• Fetched directly with curl, no login/CAPTCHA/WAF gate encountered at any point.
• Genuine single-page AcroForm PDF (not scanned as a raster page format, but its visible content — labels, instructions, the Ministry crest, and box borders — is itself a background raster image with no text layer; see Extraction method below).

Currently-live status

Third-party sources report Nepal discontinued MRP (non-chip, machine-readable only) passport issuance in 2021 in favor of e-passports. This exact form, however, remains published today (2026-07-15) on the Department of Passports' own live, current Downloads page, alongside e-passport application materials — independently re-checked this cycle by fetching the Downloads page directly. It is modelled here as a currently-live offline/paper application pathway (plausibly for diplomatic missions or locations without e-passport enrollment capacity), not a defunct process. A future cycle with a corroborating primary DoP source (e.g. an official notice scoping or restricting this form's continued use) should revisit this characterization if one surfaces.

Extraction method: widget-geometry + label-proximity reconstruction

pdfjs-dist (legacy/build/pdf.js, pinned 3.11.174) confirms:

• 1 page, page size 595.275 × 841.89pt (A4).
• page.getTextContent() returns zero text items — every visible label, instruction, and the Ministry of Foreign Affairs crest are rendered as a single background raster image, not a text layer.
• page.getAnnotations() returns exactly 337 Widget annotations, all fieldType: "Tx" (plain text), field names sur1..sur337, matching GOV-3078's disclosed count exactly. 332 of the 337 have maxLen: 1 (single-character comb boxes); the remaining 5 have maxLen 8, 15, 15, 30, and 30 (non-comb, free-width boxes for Email/Phone/signature-date fields — corrected during review-gate re-derivation from an initial "8, 8, 15, 15, 30" miscount; the actual widgets are sur222/sur335 at maxLen: 30 (email/nextOfKinEmail), sur223/sur334 at maxLen: 15 (phoneNumber/nextOfKinPhoneNumber), and sur336 at maxLen: 8 (applicantSignatureDate)).

Because there is no text layer, the entire field list and every required-field asterisk were read visually, from a node-canvas 3×-scale render of the full page (page.render() against a NodeCanvasFactory), followed by a series of targeted higher-resolution crops of each form section (Date of Birth/Sex, Citizenship/Issue dates, Address, Next of Kin, the signature/thumb-impression block, and the office-use footer) to confirm every asterisk placement precisely.

Widgets were reconstructed into logical fields as follows:

1. Sorted all 337 field names with a natural sort on the pattern sur(\d+)([a-z]?) — not parseInt() on the numeric suffix alone, which silently collapses sur226 and sur226a into a false duplicate (both parse to 226) and, in the same pass, appears to "lose" sur337 (the true last item shifts down one position once the 226a insertion is accounted for). The AutoTab(this, event, "surN+1") keystroke action present on nearly every widget explicitly chains each box to the next in fill order, corroborating that natural-sort order is the form's own intended reading/fill sequence, not an artifact of file-internal object ordering.
2. Grouped the naturally-sorted widget list into rows/fields by clustering consecutive widgets whose rect y0 values are within ~3pt of each other (same visual row) and whose x0 is within ~8pt of the previous widget's x1 (horizontally contiguous, i.e. the same comb field, not a new one) — a purely geometric, reproducible grouping, not a visual guess. This produced exactly 30 widget-groups summing to all 337 widgets.
3. Matched each of the 30 groups against the rendered image's numbered field labels (1. Surname through 17. Email, plus the Applicant's Signature Date box) by comparing each group's y0/x0 (converted to pixel coordinates at the render's 3× scale) against the corresponding label's on-image position. Every group matched its expected label with no ambiguity; group sizes independently corroborate box counts printed on the page (e.g. the 14-box Ward-adjacent... actually District boxes at 15/18/14 characters line up with the visible box widths for each labeled field).
4. The 30 groups collapse to 29 modelled comb/text fields, because the "5. Date of Birth" row's two side-by-side 8-box groups (5A. A.D. and 5B. B.S., each Year(4)/Month(2)/Day(2)) are merged into one canonical dateOfBirth field — see Date/calendar modelling below.

Date/calendar modelling

This form prints dates in up to two calendars — Gregorian ("A.D.") and Bikram Sambat ("B.S.", the calendar in official use in Nepal) — and not every date box on the form has a parallel counterpart in the other calendar:

• Date of Birth (5A + 5B): both a required A.D. box and a required B.S. box are printed for the same date. Modelled as one canonical ISO dateOfBirth (type: date), following this registry's established parallel-calendar merge technique from th/mfa/passport-application-royal-thai-embassy-london (which merges Buddhist-Era/Gregorian year blanks the same way). A consuming agent completing the literal paper form is expected to derive both calendar representations from this one value.
• Citizenship/Permit Date of Issue (field 8): prints only a B.S. box (8 digits, Year/Month/Day), with no parallel A.D. box anywhere on the form for this date. Modelled as citizenshipOrPermitIssueDateBs, type: string (not type: date), since there is no Gregorian counterpart on the source to anchor a canonical ISO conversion, and asserting one would fabricate a value the source does not provide the means to derive.
• Old Passport Date of Issue (field 10A): prints only an A.D. box, with no B.S. counterpart. Modelled as oldPassportIssueDateAd, type: date, since this one genuinely is Gregorian.
• Applicant's Signature Date (sur336): an 8-digit box beside the signature line, printed with no calendar label of any kind — unlike every other date section on this form, which always labels A.D. or B.S. explicitly. Modelled as applicantSignatureDate, type: string, since the intended calendar cannot be determined from the source without fabricating an assumption.

Requiredness

Every required item on this form carries the source's own explicit printed * asterisk, confirmed field-by-field against the high-resolution render; non-asterisked items are modelled required: false. Two deliberate exceptions, both disclosed to avoid over- or under-claiming what the source states:

> Correction (review-gate re-derivation, GOV-3208): the original > field-by-field asterisk pass missed the printed on both 11D. > Town/Village (addressTownOrVillage) and 14F. Town/Village > (nextOfKinTownOrVillage) — confirmed present on a fresh, tightly-cropped > zoom of each label (visible as टोल/गाउँ , unlike their neighbouring > 11E/14G House No. boxes, which print no asterisk). Both fields are > corrected to required: true and their sourceRefs updated to include > the asterisk; valid-minimal-required-only.json and all four > mutation-control fixtures were updated to populate both fields so the > "exactly 1 error" invariant holds for the field each fixture actually > targets. All other required: false fields on this form (10, 10A, 10B, > 11E, 12, 13, 14G, 16, 17, photo) were independently re-checked against > the render this cycle and confirmed to genuinely carry no asterisk.

• photo (the "35mm X 45mm Borderless Colour Photo" gluing box) has no backing AcroForm widget and — notably, given this form's otherwise consistent asterisk convention — no printed asterisk either. Modelled required: false rather than assuming a photo is mandatory (which it almost certainly is, in practice, for any passport application) because the source's own consistent required/optional marking convention does not apply one here.
• The two boxes captioned "Thumb Impression/औंठाको छाप" (Right Thumb/ दायाँ, Left Thumb/बायाँ) sit under a single printed asterisk covering both, but are excluded from fields[] entirely — see Biometric/signature exclusions below.

Biometric/signature exclusions

Consistent with this registry's established treatment of biometric and wet-ink capture on print-and-fill government forms (do/mirex/passport- application's exclusion of its "FIRMA Y HUELLA" signature-and-fingerprint block; mx/sre/passport-application; il/mot/medical-examination-driving- license-renewal), this schema excludes:

• The applicant's handwritten signature mark itself (labelled "Applicant's Signature/निवेदकको सही *"). No backing widget exists for the mark; only its accompanying Date (sur336, applicantSignatureDate) is modelled, since that date is itself a distinct, separately-boxed data value.
• Both Right Thumb and Left Thumb impression boxes — physical biometric capture performed on the paper form, not digitally modelable data. Neither has a backing AcroForm widget.
• The "Verifying Officer" name/signature/designation/date block — department-staff attestation, not applicant-supplied data, and (like the above) not backed by any widget.

Out of scope: "FOR OFFICE USE ONLY" section

The form's lower section — Application Source & Name (DOP/District/Mission checkboxes plus a name comb grid), Application Type (Regular/Emergency/New/ Lost/Renewal), Document Type (Ordinary/Diplomatic/Official/Travel Document), Validity (Years/Months), Revenue Receipt No., and a processing Date grid — was checked against the complete 337-widget inventory and confirmed to have zero backing AcroForm widgets of its own: every one of the 337 widgets maps to the numbered applicant-facing fields 1–17 or the Applicant's Signature Date, none to this section. It is static, non-fillable artwork completed by hand by department staff after submission, consistent with this registry's convention for excluding office-only processing blocks (e.g. do/jce/cedulacion-movil-especial's internal-processing block).

Conformance

An ephemeral, from-scratch conformance checker (deriving required/enum/ maxLength rules directly from this schema's own fields[], discarded after use, not committed) ran the following fixtures in conformance/np/dop/mrp-offline-application-form/1.0.0/:

• valid-full-application.json (all required fields, plus several optional fields, populated) — 0 errors.
• valid-minimal-required-only.json (only required fields populated, optional fields omitted) — 0 errors.
• mutation-control-missing-required-field.json (drops surname) — exactly 1 error.
• mutation-control-missing-required-field-nextofkin.json (drops nextOfKinFullName) — exactly 1 error.
• mutation-control-invalid-enum-sex.json (sets sex to X, not in the enum) — exactly 1 error.
• mutation-control-maxlength-exceeded-surname.json (surname exceeds the form's 22-character comb-box allowance) — exactly 1 error.
• mutation-control-invalid-date-format.json (dateOfBirth set to a non-ISO string) — exactly 1 error.

This schema has no requiredWhen rules (a straightforward biographic/ contact form with no conditional branches) and no required documents[] entries, so no fixtures target those.

Structural validation

• node tools/validate.mjs registry/np/dop/mrp-offline-application-form/1.0.0/schema.json — ok.
• node tools/validate-ajv.mjs registry/np/dop/mrp-offline-application-form/1.0.0/schema.json (ajv 2020-12 against spec/v0.3) — ok.
• Full-registry re-run after adding this document: node tools/validate.mjs and node tools/validate-ajv.mjs — see PR for exact counts.
• npm run build-index re-run in tools/govschema-client/ to regenerate registry-index.json with this document included.

Maturity

structural-reference: every field traces to a specific box visually confirmed on a high-resolution render of the genuine, currently-served official form, and widget-geometry grouping was independently cross-checked against visible box counts, but no live filing at a Department of Passports office was attempted. GovSchema is an independent, non-profit standards body and is not affiliated with, endorsed by, or operated by the Government of Nepal or the Department of Passports.