# Verification record — bz/doi/passport-application@1.0.0 ## Candidate selection GOV-5805 ("GovSchema Standard Research"). A prior cycle (GOV-5791, 2026-07-31) scouted 18 new-jurisdiction candidates in parallel and banked Belize as one of 16 countries with at least one reachable, unauthenticated candidate document ("Belize ePassport"), without authoring any of the 16 (Papua New Guinea's Form A-17 was judged the strongest single candidate that cycle, and the Democratic Republic of the Congo's Visa AcroForm the strongest of the remainder in the following cycle, GOV-5798). This cycle re-scouted Belize specifically and confirmed its Department of Immigration hosts a genuine, unauthenticated, recently-updated (V2, revised July 3, 2025) AcroForm passport-application PDF directly on its own official domain — the strongest of the remaining banked candidates checked this cycle (Suriname's individual income tax return requires portal pre-registration since 2025-01-01 per the tax authority's own site; Malawi's MRA taxpayer-registration form is a KYC data-collection sheet rather than a fillable AcroForm; Guyana's own Ministry of Foreign Affairs states no downloadable form exists for in-country applications). Opens Belize as the registry's 103rd jurisdiction, via the Passport vertical (1 of 6). ## Reaching the live source Target: `https://immigration.gov.bz/wp-content/uploads/2025/08/Belize-ePP-PP-Application-form_LETTER_v2_Jun_03-2025.pdf` ("Application for Passport", V2 Revised July 3, 2025, Department of Immigration). - Re-fetched directly: HTTP 200, `Content-Type: application/pdf`, **510,208 bytes**, `Last-Modified: Fri, 29 Aug 2025 14:21:47 GMT`. - sha256 of the retrieved bytes: `afb776dbf18c4a80a189d881f18be66cc2785b1653b7296406c4f57bf6d00c94`. - No login, CAPTCHA, or WAF gate on the asset itself, nor on the hosting page `https://immigration.gov.bz/passport/passport-forms/` or `https://immigration.gov.bz/passport/passport-adult-application/`. - The Department's own site root (`https://immigration.gov.bz`, "Belize — Official Immigration Website", operated under the Ministry of Immigration, Governance & Labour per its own page-footer text) is used as `authority.url` (the passport-specific landing page, `https://immigration.gov.bz/passport/`, specifically). - A companion child/minor-applicant form (`passportForm-Children-version-1A.pdf`, "version 1A", last touched 2020) and an older, superseded adult form (`passportForm-Adults-version-1.pdf`, "version 1", also 2020) are hosted on the same domain; this schema targets the newer, unified V2 (July 2025) form, which the site's own "Passport Adult Application" landing page links first and which supersedes both by scope (New/Renewal/Replacement/ Lost-or-Stolen in one form) and recency. - Confirmed mechanically via `pdfjs-dist`: the document is a genuine AcroForm (not a flat/print-and-fill specimen) with 3 pages, 40 form-field annotations on page 1, 57 on page 2, and 2 on page 3 (99 total raw widgets — `Btn` radio groups and `Tx` text fields), each carrying an internal PDF field name independently extracted via `page.getAnnotations()`. ## Extraction method `pdfjs-dist` (`getAnnotations()` for the 99 raw form-field widgets; `getTextContent()`, read per page and cross-referenced by (x, y) coordinates against each widget's own `rect`, for the surrounding printed labels/instructions/section headers) — no glyph-index or `canvas` rendering workaround was needed; the embedded fonts decode cleanly to readable English text (two harmless `pdfjs-dist` warnings, "TT: invalid function id"/"TT: undefined function", relate to unused embedded TrueType hinting instructions and do not affect text or field extraction). Each raw widget was matched to its printed label and section (1–8, following the form's own numbering) by this rect-to-label cross-reference; the form places each field's box a small, consistent vertical offset below (rarely, as in the signature/date lines, above) its own printed label, confirmed as a consistent pattern across all three pages before being relied on to disambiguate ambiguous internal field names (see below). ## Field modelling and disclosed findings Models 72 `fields[]` across 8 steps mirroring the form's own layout (an unnumbered "APPLICATION DETAILS" box, followed by its own numbered Sections 1–8), 1 `documents[]` entry, and 1 `crossFieldValidation` rule. Disclosed findings, all confirmed directly against the raw annotation/text extraction rather than assumed: 1. **No printed required/optional signal anywhere on the form.** Like `cd/maeci/visa-application`, this specimen marks no field as mandatory or optional with any printed asterisk or symbol. Every field's required/optional status here is a disclosed domain judgment call: core identity, citizenship-basis, and application-routing questions are modelled required; supplementary contact detail (international phone, email), the current address block, and free-text comments fields are modelled optional. 2. **The "APPLICATION DETAILS" box is printed "(for office use only)" but its own fields require applicant-only information the office could not supply unprompted** — who is submitting, why, and which document/ processing-time/priority tier is being requested (all of which the form's own fee table, printed immediately above the box, prices differently). Modelled as applicant-facing fields regardless of the header's wording, consistent with the fact that these are genuine fillable `Btn`/`Tx` AcroForm widgets on the same specimen — the "(for office use only)" caption is treated as informational/administrative framing, not an exclusion signal, and disclosed as such rather than silently reinterpreted. 3. **`email` is internally named `PERMANENT ADDRESS`** on the raw AcroForm despite sitting directly under the printed "Email:" label and directly above the actual Permanent/Current Address block — a source-side field-naming artifact (the widget was very likely auto-named after the heading immediately following it during the form's original design), not a schema modelling choice. Disambiguated by rect position (y≈672–687, matching the "Email:" label's own y≈677, distinct from the Permanent Address block's own first row at y≈642–656). 4. **Three further internal PDF field names are generic, non-semantic placeholders (`Text8`, `Text9`, `Text10`, `Text11`, `Text12`)** rather than reused/mismatched real labels: `Text8`/`Text9` are height-in-feet/ height-in-inches (Section 1); `Text10`/`Text11`/`Text12` are the spouse's date of birth/nationality/place of birth (Section 4). All five disambiguated by rect position against their own row's printed label, not by internal name. 5. **`childDateOfBirth` and `guardianPlaceOfBirth` (Section 6) carry internal names that concatenate two adjacent rows' printed text** (`Date of Birth DDMMYYYYSingle Married Divorced Widower` and `Single Married Divorced WidowerPlace of Birth` respectively) — the same naming-artifact pattern already seen in Section 2's `email` field, here affecting two fields at once because Section 6 stacks three short label rows (Relationship to Child + Date of Birth; Marital Status; Place of Birth + Nationality) in quick succession. Disambiguated by rect position against each field's own row. 6. **No checkbox field exists for the "Same as permanent address" note** next to the Current Address header (Section 2) — confirmed by enumerating every `Btn` widget on page 2 and finding none positioned near that note's own coordinates. The five Current Address fields (`currentAddressStreetVillage`/`PoBox`/`City`/`DistrictState`/`Country`) remain independently optional text fields, each described as leavable blank when identical to the Permanent Address, per the source's own printed instruction — not modelled as a boolean gate, since the source provides no corresponding control to formally flag it. 7. **Section 7's own five declaration items (A–E, "check all that apply") have no selectable checkbox widgets at all** — confirmed by finding only 2 raw widgets on page 3 total, neither positioned near items A–E's own text. Applicants must hand-mark these on a printed/scanned copy; this registry cannot model a control that does not exist on the live AcroForm. The single free-text widget associated with that paragraph block (capturing whichever of item D's or item E's own blanks — a previously-issued-but-not-surrendered passport's number/place/date of issue, or an unavailable-for-presentation passport's equivalent) is modelled as `lostOrStolenDeclarationDetails`, disclosing that this schema cannot determine from the AcroForm alone which of D or E the applicant intends. 8. **`certificationDate`** (the date accompanying the applicant's general "I certify that the above particulars are correct..." declaration) is modelled required, since it applies to every application, even though the source's own layout places it directly beneath Section 5 (Lost or Stolen Passport) rather than in a numbered section of its own — a form-layout quirk, disclosed rather than silently re-sectioned into a step that doesn't match the source's own visual order. 9. **`submitterIdType`/`submitterIdNumber`** (Section 6, "SUBMITTER" column) are gated `requiredWhen submittedBy in [PARENT_LEGAL_GUARDIAN, AUTHORIZED_PERSON]` rather than tied only to the Parent/Legal Guardian path, since the "SUBMITTER" column heading applies to whoever other than the applicant is submitting — a disclosed scope judgment call, not directly printed as a rule on the form itself. 10. **One signature field is modelled; the rest, plus the photo box, are not.** The specimen's own "SIGNATURE BOX," the general "I certify..." declaration's signature line, and the Section 6 guardian-consent signature line's own accompanying date, plus the "PHOTO BOX (for office use only)," carry no corresponding data-entry widgets beyond the dates already modelled alongside them — consistent with this registry's convention of not modelling physical signature/photo capture as data fields where the source provides no fillable widget for it. **Section 6's own SUBMITTER-row signature line is the one exception**: a genuine `Tx` widget (raw id `169R`) sits directly beneath the printed "Signature" label there, at the same row as the "SUBMITTER" column heading over `submitterIdType`/`submitterIdNumber` — confirmed by rect position (widget rect y≈91–106, immediately below the "Signature" label's own y≈113 and the blank signature rule at y≈127, and gated identically to `submitterIdType`/`submitterIdNumber`'s own `requiredWhen submittedBy in [PARENT_LEGAL_GUARDIAN, AUTHORIZED_PERSON]`). Modelled as `submitterSignature`, per this registry's convention of modelling a signature only where the source itself supplies a fillable widget (see e.g. `tt/imd/passport-application-first-adult`'s own `applicantSpecimenSignature` exception). The widget's own raw tooltip (`Signature_ID No.:`) splices this column's "Signature" label onto the neighboring column's "ID No.:" label — the same internal-field-naming artifact already disclosed at findings 3–5 above, not a compound field. 11. **`statutoryDeclarationOfLossOrTheft`** is modelled as the schema's sole `documents[]` entry, `requiredWhen replacementReason in [LOST, STOLEN]`, per Section 7 Item E's own text ("Unavailable for presentation... I have attached a Statutory Declaration attesting to its loss, destruction or being stolen"). No other attachment checklist appears anywhere on the specimen (unlike, e.g., `cd/maeci/ visa-application`'s own Section A checklist); the citizenship certificate referenced in Section 3 is captured by its own number/ place/date-of-issue text fields rather than as a separate attachment, since the form itself asks only for those details, not for an uploaded copy. ## Conformance testing 3 valid mock scenarios (a single, first-time ePassport applicant applying in person; a married applicant replacing a lost temporary passport, with a spouse and a police report on file; a divorced applicant renewing their ePassport through an authorized person) plus 12 mutation-control fixtures (a missing statically-required field; a missing `ePassportType` while `documentType` is `EPASSPORT`; a missing `replacementReason` while `applicationReason` is `REPLACEMENT`; a missing `titleOther` while `title` is `OTHER`; a missing `spouseSurname` while `maritalStatus` is `MARRIED`; a missing `dateOfLoss` while `replacementReason` is `LOST`; a missing `relationshipToChild` while `submittedBy` is `PARENT_LEGAL_GUARDIAN`; a missing `submitterIdType` while `submittedBy` is `AUTHORIZED_PERSON`; a missing `submitterSignature` while `submittedBy` is `AUTHORIZED_PERSON`; an invalid `gender` enum value; an unknown top-level field; and a `crossFieldValidation` violation with `reportDate` before `dateOfLoss`), committed under `conformance/bz/doi/passport-application/1.0.0/`. An ephemeral, from-scratch conformance checker (deriving required/ requiredWhen rules, enum validation, and the crossFieldValidation rule directly from this schema's own `fields[]`/`crossFieldValidation[]`, discarded after use, not committed) ran all 15: all 3 valid scenarios at 0 errors, all 12 mutation controls each raising exactly 1 error, confirmed every `requiredWhen` field reference resolves (0 dangling references), and separately confirmed the sole `documents[].requiredWhen` gate (`statutoryDeclarationOfLossOrTheft`) evaluates `true` only for the lost-passport scenario and `false` for the other two. Validated clean with `node tools/validate.mjs` and `node tools/validate-ajv.mjs`, individually and as part of the full 704-document registry run. Registry index rebuilt via `npm run build-index` in `tools/govschema-client/`.