# Verification record — jm/pica/passport-application@1.0.0 ## Candidate selection GOV-4367 ("GovSchema Standard Research", 2026-07-22). Consumes the single most attractive of Jamaica's four disclosed-STRONG banked-backlog verticals left open by the GOV-4360 cycle (see CATALOG.md's Known Gaps entry 0f) — PICA's own genuine AcroForm passport application, flagged in that cycle's own scouting notes as "the richest and cleanest source of all six Jamaican verticals scouted, a true fillable AcroForm rather than a flat/scanned specimen". Opens Jamaica's Passport vertical (2 of 6); Business Formation is already open via `jm/orc/business-name-registration-individual`, and DMV/Visa/Taxes remain open, STRONG banked backlog for future cycles (National ID is a confirmed dead end per the GOV-4360 cycle's own screening). ## Reaching the live source Independently re-fetched and re-hashed rather than trusted from the prior cycle's own banked report alone: - `https://www.pica.gov.jm/sites/default/files/Forms/Jamaica-Passport-Application-Compressed.pdf` (linked from the live, unauthenticated `/passport/application-forms` page). - HTTP 200, `Content-Type: application/pdf`, 776,064 bytes (byte-for-byte match with the GOV-4360 cycle's own reported ~776KB size). - sha256 `aa259402cb3e6231a4661e6d6e567645c9cafb3e87741231c5b530e8c5c44e40`. ## Extraction method Confirmed mechanically via `pdfjs-dist`'s (vendored at `/tmp/node_modules/pdfjs-dist`) `getAnnotations()` API across all 6 pages: 172 `/Widget` annotations resolving to exactly 152 unique AcroForm field names (an exact match with the GOV-4360 cycle's own reported field count), concentrated on pages 1-4 (57, 26, 36, and 53 widgets respectively); pages 5-6 carry zero widgets and are the printed guideline pages, not fillable form content. Text extracted via `getTextContent()`, grouped by row (y-coordinate, tolerance 2pt) and column (x-coordinate), to recover every printed section heading, field label, and radio/checkbox option caption, cross-referenced against each widget's own `rect` to resolve column and section membership. A `pdfjs-dist` + `node-canvas` (vendored at `/tmp/node_modules/canvas`) render-to-PNG attempt at 2.5x scale for all 4 form pages confirmed the overall box/line/radio-button grid layout (comb-style text boxes, circular radio buttons grouped in rows) but could not render the form's own embedded glyphs (a `getPathGenerator`/"Requesting object that isn't resolved yet" font-resolution failure) — the same disclosed sandboxed PDF-render tooling gap this registry's `eg/mfa/civil-status-record-request` and other schemas have already hit; text-layer extraction was unaffected and is this schema's primary evidentiary basis. ## Document structure The PDF's 6 pages: pages 1-4 are the fillable AcroForm (Sections A-K); pages 5-6 are printed "Guidelines for Jamaican Passport Application" (no widgets), the source for this schema's own `documents[]` entries. Models 110 `fields[]` across 12 steps (Eligibility Gates; Section A Personal Data; Section B Marriage Details; Section C Consent for Minor; Section D Particulars of Most Recent Passport; Section E Declaration of Applicant; Section F First Emergency Contact; Section F Second Emergency Contact; Section G Official Certification; Section H Religious Headgear; Section I Born Outside Jamaica; Section J Supplementary Information) plus 6 `documents[]` entries. ## Disclosed source-fidelity findings 1. **Three unprinted boolean eligibility gates model conditions the form's own section headers state in prose but never back with a printed checkbox** — `applicantIsMinor` (Section C's own header: "Applicable to persons under 18 years of age"), `wearsHeadgearForReligiousReasons` (Section H's own header), and `applicantBornOutsideJamaica` (Section I's own header: "TO BE COMPLETED BY APPLICANTS BORN OUTSIDE OF JAMAICA"). This is the same unprinted-condition convention this registry's Botswana (`bw/dic/passport-application` Finding 3), Zambia, Ethiopia, Malta, and Cyprus passport schemas already use for their own section-applicability gates, since GSP-0013's `Condition` grammar has no derivation operator (e.g. age-from-date-of-birth, or country-of-birth-vs-Jamaica) that could compute any of these three directly from an already-answered field. 2. **Sections B (Marriage Details) and D (Most Recent Passport) are gated on already-answered enum fields rather than a further unprinted boolean**, since the form's own printed structure makes both conditions directly derivable: Section B's own header ("TO BE COMPLETED IF APPLICANT IS OR HAS BEEN MARRIED") is modelled `requiredWhen maritalStatus in [MARRIED, DIVORCED, WIDOWED]` (GSP-0013's `in` operator), and Section D's own header ("required whether the passport is expired or current, damaged, lost or otherwise unavailable") is modelled `requiredWhen priorPassportDeclaration in [SURRENDERED, LOST_OR_UNAVAILABLE]` (i.e. not `NEVER_HELD`) against Section E's own three-way declaration. A `LOST_OR_UNAVAILABLE`-only subset of Section D's own fields (`mostRecentPassportLossDate`, `passportIssuedInNameSurname`, `passportIssuedInNameFirstName`, `placeOfPassportLoss`, `circumstancesOfPassportLoss`) is further narrowed off the `SURRENDERED` branch, since their own printed captions ("Name in which stolen, lost or unavailable passport was issued"; "BRIEF STATEMENT OF CIRCUMSTANCES WHERE PASSPORT HAS BEEN DAMAGED") apply only to a lost/damaged passport, not a simply-surrendered one. 3. **Section E's own "Declaration" AcroForm field is a genuine radio-button group (mutually exclusive) across all three printed declaration paragraphs**, even though each paragraph is presented as its own free-standing sentence rather than an explicit "tick one" instruction. The three paragraphs are logically mutually exclusive in substance (never held one; held one now surrendered; held one now lost/unavailable), so the radio-button implementation is semantically consistent with the printed content — modelled as a required 3-value enum (`priorPassportDeclaration`), ordered top-to-bottom by each option's own y-position on the page (the underlying AcroForm's own shared `/V` entry does not distinguish per-widget export values, so position, not field-reported value, is this schema's basis for enum ordering throughout). 4. **`placeOfBirth` is modelled as a single field backed by three separate AcroForm text widgets** (`Applicant_Place_of_Birth`, `Applicant_Place_of_Birth2`, `Applicant_Place_of_Birth1`, in that on-page order). The first two widgets are an unambiguous two-line box directly beneath one label ("Place of Birth: (Town, City and Parish)") — the same multi-line-box-under-one-label pattern this schema also uses for `profession`, `permanentAddress`, `mailingAddress`, `permanentTown`, `mailingTown`, `placeOfMarriage`, `marriageCountry`, both emergency contacts' own address/town pairs, and `placeOfPassportLoss` (in each case, two or three same-width AcroForm widgets stacked directly beneath a single printed label with no distinguishing sub-caption, collapsed here into one logical, generously-sized field rather than modelled as separate implementation-level line1/line2 fields). The third widget, however, sits beneath a **second, standalone "Place of Birth" label reprinted further down the page** (with no parenthetical this time), positioned immediately beside where the "Mother's First Name" column begins — after the intervening Date of Birth/Sex/Height row breaks the visual continuity. It is not certain from the source alone whether this third widget is a continuation line of the same answer (consistent with its internal AcroForm name and identical `alternativeText`, both shared with the first two widgets) or a distinct, mislabelled field the form's original designer intended to caption differently. This schema takes the conservative reading — a third line of the same `placeOfBirth` answer — given the shared internal name and alternative text, but discloses the ambiguity here rather than silently resolving it. 5. **`circumstancesOfPassportLoss` collapses three separate ruled-line AcroForm widgets** (`Circumstances_of_passport_loss1/2/3`) under one "BRIEF STATEMENT OF CIRCUMSTANCES WHERE PASSPORT HAS BEEN DAMAGED" heading into a single, generously-sized free-text field, per the same collapsing convention as Finding 4. 6. **`consentGiverNameInDeclaration` and `consentGiverRelationshipInDeclaration` are printed restatements of `consentGiverSurname`/`consentGiverFirstName`/`relationToMinor` already captured earlier in the same Section C**, embedded in the section's own narrative consent sentence ("I (name)... the (Relationship)..."). Similarly, `applicantFullNameForCertification` in Section G restates the applicant's own `surname`/`firstName` already captured in Section A, embedded in the certifying official's own narrative sentence ("hereby certify that I have known [Full Name of Applicant]... as stated on application"). All three are modelled as their own distinct fields, since each is backed by its own separate AcroForm widget and GSP-0013 has no field-equality assertion this schema could use to express "must match a value already given" instead. 7. **No signature line anywhere on this form is backed by an AcroForm widget** — not the applicant's own Section E signature, not the parent/legal guardian's Section C signature, and not the certifying official's Section G signature; each is a plain underlined blank. This is a genuine departure from this registry's non-AcroForm passport schemas (e.g. `bw/dic/passport-application`, `zm/dnrpc/passport-application`), which model "signature" as a plain string field for lack of any better-typed alternative on a flat specimen — here, since every other data point on this same form is backed by a real, distinguishing AcroForm widget and these three specifically are not, this schema excludes all three from `fields[]` and instead models a single `signedApplicationForm` document, since wet-ink signature capture is out of scope for a machine-readable field. The parent/legal guardian's Section C consent **date** is likewise excluded (no backing widget), unlike the applicant's own Section E declaration date (`Declaration_Date`, modelled as `declarationDate`) and the certifying official's own Section G certification date (`Date_of_Certification`, modelled as `certificationDate`), both of which do have real AcroForm widgets. 8. **Section J ("SUPPLEMENTARY INFORMATION") prints 18 ruled lines but the underlying AcroForm exposes only 16 unique field names** — two pairs of adjacent lines share one field name apiece (`Supplimentry_Information4` appears on two separate ruled lines, as does `Supplimentry_Information17`), while a would-be `Supplimentry_Information5` is never used at all. This is a genuine duplicate-widget naming defect in the source AcroForm (filling one of a duplicated pair auto-fills its sibling line, since they are literally the same underlying field), not a schema limitation. Modelled as 16 independent, renumbered optional free-text fields (`supplementaryInformationLine1`-`supplementaryInformationLine16`), each `sourceRef`-annotated with its own actual AcroForm field name for traceability. The source PDF's own internal field name for `specialVisibleFeatures` (`Apecial visible Feature`) contains its own typo, corrected here to a clean camelCase name; the printed label itself ("Special Visible Features") is spelled correctly. 9. **Section G's own "Address of Certifying Official" column is split across five separate stacked AcroForm text widgets** (Building/ Apartment Number and Name — explicitly "(if applicable)" per its own printed caption, hence the sole optional field in this block; Street Number and Street Name; Town; City; Parish/State), while the adjacent "Country" column carries three (Country, Postal/Zip Code, Telephone). This is a genuinely different split from the applicant's own Section A permanent/mailing address blocks (each a simple Address/Town/Country/ Zip/State column set) — Section G's own five-way Town/City/Parish/ State breakdown has no analogue elsewhere on this form and is modelled field-for-field as the source AcroForm actually structures it, not assumed identical to Section A's own convention. 10. **Section F's two emergency-contact blocks ("FIRST CONTACT PERSON"/ "SECOND CONTACT PERSON") are printed as visually identical blocks with no annotation distinguishing one as optional.** This schema models the first contact's own fields as required and the second contact's own fields as entirely optional, a disclosed judgment call (the same convention this registry's Botswana/Zambia passport schemas apply to their own next-of-kin/emergency-contact sections) rather than assuming a second contact is universally mandatory. 11. **`residentialPhoneNumber`/`businessPhoneNumber` and `permanentAddress`/`mailingAddress` (with their own Town/Country/Zip/ State companions) are each modelled as independently optional, with no selector or validation rule requiring at least one of the pair.** The form itself prints "Mailing Address (If different from permanent address)", confirming the mailing block is conditional in substance on the applicant actually having a different mailing address, while `permanentAddress` itself carries no such qualifier and is modelled required. The two phone-number columns (Residential/Business) carry no qualifier distinguishing either as mandatory; both are modelled optional, the same disclose-rather-than-fabricate treatment `bw/dic/passport-application` Finding 2 applies to an analogous unconditioned either/or pair. 12. **`maidenSurname`, `previousName`, `middleName`, `specialVisibleFeatures`, `permanentZipCode`/`mailingZipCode`, `permanentState`/`mailingState`, and `certifyingOfficialZipCode` are modelled optional** since not every applicant has a maiden surname, a prior name, a middle name, a distinguishing mark, or a postal code/state on their address (Jamaican addresses commonly carry a Parish rather than a postal code or state) — the source prints no optionality marker for any of these, the same disclosed judgment-call convention `bw/dic/passport-application` Finding 5/7 applies to its own comparable fields. 13. **`previousPassportOrTravelDocumentNumber` (Section E's own "other than Passport or Travel Document No. ___, which is submitted herewith") is modelled bare-optional, not gated on `priorPassportDeclaration`.** The sentence structure implies this blank is only completed if such an exception document exists, which is not guaranteed even within the `SURRENDERED` declaration branch — the same disclosed no-printed-signal treatment `bw/dic/passport-application` Finding 9 applies to its own analogous ungated optional field. 14. **Section K ("FOR OFFICIAL USE ONLY") and the "RECEPTION TEAM" block are excluded in full**, including the eleven-row "DOCUMENTS SUBMITTED" table (document number and issue date per document type — Birth Certificate, Adoption Certificate, Marriage Certificate, Naturalization Certificate, Registration Certificate, Certification of Citizenship, Divorce Certificate, Driver's Licence, Tax Registration Number, Electoral Identification, Other) and the Outpost Staff/ Passport Office reception sign-off fields — all completed by PICA staff recording which documents were physically produced and processed, not applicant-supplied data. This mirrors `bw/dic/passport-application` Finding 10's own exclusion of its source form's "For Official Use Only" page. 15. **Radio-button and checkbox-grid option orderings (`maritalStatus`, `eyeColour`, `sex`, `relationToMinor`) were resolved by cross-referencing each radio widget's own `rect` x-position against the nearest printed option caption's own x-position**, not by the AcroForm's own reported `fieldValue` (which returns the field's shared `/V` entry, identical and uninformative across every sibling widget in a group, e.g. every `Eye Colour` widget reporting `null` and every `Declaration` widget reporting the same string). `eyeColour` in particular is an 11-value enum (Dark Brown, Brown, Grey, Grey Blue, Blue, Hazel, Chestnut, Black, Red, Burgundy, Mixed) confirmed by an 11-widget-to-11-caption exact positional match across four printed rows. ## Conformance 3 valid mock scenarios (a first-time adult applicant declaring `NEVER_HELD` with no marriage, minor-consent, headgear, or foreign-birth branches triggered; a married adult renewing after a lost passport, triggering Section B, the `LOST_OR_UNAVAILABLE` subset of Section D, and a police-report document; and a minor applicant born outside Jamaica with a legal guardian's consent and a religious-headgear declaration, triggering Sections C, H, and I together) plus 17 mutation-control fixtures (a missing statically-required field for `surname`, `firstName`, `maritalStatus`, `eyeColour`, `dateOfBirth`, `sex`, `mothersFirstName`, `mothersMaidenName`, `permanentAddress`, `permanentTown`, `permanentCountry`, `priorPassportDeclaration`, `declarationDate`, and `emergencyFirstContactSurname` [14 fixtures]; a missing `requiredWhen`-true field (`consentGiverSurname`) while its gate is active; an invalid enum value (`eyeColour`); and an unknown top-level field) are committed under `conformance/jm/pica/passport-application/1.0.0/`. An ephemeral, from-scratch conformance checker (deriving required/ requiredWhen rules directly from this schema's own `fields[]`, discarded after use, not committed) ran all 20 fixtures: all 3 valid scenarios at 0 errors, all 17 mutation controls each raising exactly 1 error, and confirmed every `requiredWhen` field reference resolves (0 dangling references). Validated clean with `node tools/validate.mjs` and `node tools/validate-ajv.mjs`, individually and as part of the full registry run. `registry-index.json` regenerated via `npm run build-index` in `tools/govschema-client/`.