Papua New Guinea Application for Entry Permit

Candidate selection

GOV-5819 ("GovSchema Standard Research"). GOV-5812's own prior cycle screened Papua New Guinea's Visa vertical (alongside the other four verticals it screened) and banked two live, unauthenticated, genuinely rich AcroForm candidates without authoring either:

1. "Application to Extend Entry Permit" (the ICA's own form) — ica.gov.pg/uploads/media/post_file_2430587-visa-extension-form-new-savable.pdf — HTTP 200, 123,043 bytes, confirmed 62 widgets across 2 pages. This is a follow-on/renewal action for someone already in-country, not a first-entry application.
2. "Application for entry permit" (first-entry visa application) — mirrored at png.or.jp/wp-content/uploads/2016/01/Application_for_entry_permit_form_new_savable.pdf — HTTP 200, 180,934 bytes, confirmed 102 widgets across 4 pages, itself watermarked "Downloaded from www.immigration.gov.pg" (the direct immigration.gov.pg path for this exact filename currently 404s; png.or.jp is the only currently-live host found for this specific PDF). A genuine first-entry visa application, and the richer of the two (102 vs. 62 widgets).

This cycle authored the richer, first-entry candidate (#2), opening Papua New Guinea's Visa vertical outright. The visa-extension form (#1) remains unauthored backlog for a future cycle, as a distinct renewal/extension action rather than a first-entry application.

Reaching the live source

Independently re-fetched https://png.or.jp/wp-content/uploads/2016/01/Application_for_entry_permit_form_new_savable.pdf directly via plain curl, twice, to confirm reproducibility:

• HTTP 200, 180,934 bytes, both times.
• sha256 669fe6cf6878c7c11aac04459056cc6782da0396de4ce73dfcc17bc18da5076d, both times, byte-identical (cmp confirmed).
• No login, CAPTCHA, or WAF/JS-challenge gate — served directly (content-type: application/pdf) with a permissive response.
• Last-Modified: Sun, 11 Sep 2016 15:00:00 GMT — a long-standing, stable specimen, not a recent upload.
• Independently confirmed the direct immigration.gov.pg path for this exact filename currently 404s (immigration.gov.pg/wp-content/uploads/... and www.immigration.gov.pg/... both return HTTP 404), corroborating that png.or.jp is the only currently-live host for this specific PDF, even though the PDF itself is watermarked "Downloaded from www.immigration.gov.pg" and so explicitly attributes its own source authority.

Confirmed via pdfjs-dist to be a genuine native (searchable-text) PDF, not a scanned image: a clean text-layer extraction across all 4 pages recovered every printed label with no glyph-mapping or OCR workaround needed.

Authority naming

This specimen's own page-1 letterhead reads "PNG Immigration & Citizenship Service Authority", and Instruction 3 addresses the completed form to "The Chief Migration Officer, Immigration and Citizenship Service Authority, PO Box 1790, BOROKO, NCD, Papua New Guinea" — a slightly different printed name ("...Service Authority") than the name printed on pg/ica/passport-application's own specimen ("Immigration and Citizenship Authority", no "Service"). A live web search corroborates both names refer to the same body: ica.gov.pg's current branding is "Immigration and Citizenship Authority"/ICA, while "Immigration and Citizenship Service Authority"/ICSA appears in older/alternate third-party usage for the identical institution (e.g. a ZoomInfo entry titled "The PNG Immigration & Citizenship Service Authority" and a CB Insights entry titled "Papua New Guinea Immigration and Citizenship Authority" both describe the same body). This schema therefore reuses the existing registry/pg/ica/ authority directory and the existing pg/ica/passport-application authority block verbatim (name "Immigration and Citizenship Authority", abbreviation "ICA", url ica.gov.pg) rather than opening a new, spurious authority directory for what is the same institution under an older printed name.

ica.gov.pg itself returned HTTP 403 to both a direct curl and a WebFetch attempt during this cycle's verification (consistent with GOV-5812's own passport cycle, which reached the same domain successfully for its own PDF asset but not this HTML front-end), so the current-name corroboration above relies on third-party search results, not a direct fetch of ica.gov.pg's own text — disclosed as a residual sourcing gap, not a live-fetch confirmation.

Extraction method

Extracted with pdfjs-dist (vendored install at /tmp/mn-passport/extract/node_modules/pdfjs-dist, CommonJS legacy build): a full getAnnotations() pass per page enumerated every AcroForm Widget (102 total across 4 pages — page 1: 33; page 2: 40; page 3: 29; page 4: 0, a pure general-information/notes page), recording each widget's internal field name, PDF field type (Tx/Btn/Ch), rect (bounding box) position, and (for Btn widgets) checkBox/radioButton/pushButton flags; then a getTextContent() pass per page, sorted by descending y then ascending x, to recover reading order.

Several ambiguous regions were re-extracted with a narrower y-band and raw per-glyph x/y coordinates (rather than trusting the joined-line text alone) to positively cross-check every widget's rect against its printed label before naming the field:

• The page-1 TRAVEL ARRANGEMENTS column layout: the joined-line text briefly appeared to read "Arrival in PNG / Departure to PNG / Name of Vessel/Flight" left-to-right, but a raw per-glyph re-extraction of that row (y=60–115) showed Name_of_VesselFlight's own widget rect sits leftmost (x=24–196), Departure_to_PNG's own Port/Date widgets sit in the middle column (x=234–395, directly beneath the "Departure to PNG"/"Port:"/"Date:" labels printed at x=214), and Arrival_in_PNG's own Port/Date widgets sit rightmost (x=432–564, beneath labels at x=413) — confirmed by rect-to-label proximity, not the initially-misleading line-joined text order.
• Page 2's two-column employment-document-checklist vs. stay-funding-source-checklist split: a rect/text cross-check confirmed the left column (x=26–44) backs the four employment-purpose document checkboxes and the right column (x=377–395) backs the four stay-funding-source checkboxes.
• The page-3 DECLARATION paragraph: a raw per-glyph re-extraction (y=250–300) confirmed the text-layer's own reading order is internally consistent here (not a sort-order artifact, unlike the travel-arrangements row above) — see scoping decision 11 below.

canvas was not available in this environment (checked /tmp/node_modules and every node_modules tree reachable from the working directory; only pdfjs-dist itself was found, no canvas), so no page was rendered to a PNG. Every field mapping in this schema was instead confirmed via the rect-position/text-position cross-check method described above, consistent with this registry's own established practice of only invoking canvas-rendering when rect-position inference alone leaves genuine ambiguity — no such residual ambiguity was found here.

Structure and scoping decisions

No printed required/optional signal of any kind exists anywhere on this specimen (no asterisk, no "(required)"/"(optional)" caption, confirmed by a full page-by-page text-layer read) — the same constraint pg/ica/passport-application and cd/maeci/visa-application faced. This schema follows the same policy those two adopted: required only the fields necessary to identify the applicant and the substance of the application, and bare-optional for travel logistics, secondary address/phone detail, and the emergency-contact block, with every genuinely conditional block gated by requiredWhen wherever the form's own layout or prose states a real conditional relationship.

Disclosed scoping decisions:

1. This specimen carries two genuine image-insertion pushbutton widgets — a real contrast with pg/ica/passport-application, which carries none. Page 3's "Photograph" box and "Signature of Applicant/Parents/Guardian:" line are each backed by a real AcroForm Btn widget (Insert_photograph_here, Insert_signature_image_here) with pushButton:true and isTooltipOnly:true — Acrobat/LiveCycle "click to insert an image" pushbuttons, not checkboxes or text fields. Both are modelled as fields[] of type file (applicantPhotograph, applicantOrGuardianSignatureImage), both required, since a genuine widget backs each — consistent with this registry's convention of only modelling signature capture (and, by the same logic, photograph capture) where the source itself provides a fillable widget. Unlike bz/doi/passport-application's submitterSignature (a text-type Tx widget on a printed "Signature" line) or tt/imd's applicantSpecimenSignature, this specimen's signature widget is an image-insertion pushbutton, modelled as type file rather than type string for that reason.
2. Instruction 1 states "Where the application is in respect of a child under 16 years of age, both parents must sign the application", but only one signature widget exists on the entire specimen (the single Insert_signature_image_here pushbutton behind the shared "Signature of Applicant/Parents/Guardian:" line). This is a genuine content gap in the source specimen itself, not an omission of this schema's own: there is no second signature widget, and no separate parent/guardian name text field anywhere on the form, to model a two-parent-signature scenario distinctly. Disclosed rather than invented; applicantOrGuardianSignatureImage models the one widget that exists.
3. Three directly-supplied boolean gates without a backing widget of their own — hasChangedNameOrAlias, hasOtherPassport, and hasOrganisationalSponsor: All three mirror this registry's own hasSponsor (cd/maeci/visa-application) / hasHostInMalta (mt/identita/long-stay-visa-application) / applicantUnder17 (pg/ica/passport-application) convention for a real conditional relationship stated in prose or layout without its own checkbox.
   • hasChangedNameOrAlias and hasOtherPassport split a single combined page-2 prose sentence ("If you have ever change your name, are known by an alias, or own another passport, please provide details:") that precedes two visually distinct subsections (PREVIOUS NAMES/ALIAS DETAILS: and OTHER PASSPORTS:). Since the two subsections are printed and headed separately, this schema models two independent gates rather than one combined one, so a same-name-never-changed applicant who nonetheless holds another passport is not forced to also complete the previous-name/alias block, and vice versa.
   • hasOrganisationalSponsor models the ORGANISATIONAL SPONSOR heading's own genuinely conditional nature (most applicants — e.g. tourists funding their own stay — will have no organisational sponsor at all) even though the form prints no explicit "do you have a sponsor?" yes/no question of its own for this block.
4. Within the hasOrganisationalSponsor branch, only organisationalSponsorName, sponsorStreetAddress, and sponsorCountry are gated requiredWhen true; sponsorAgentName, sponsorSuburbTown, sponsorStateProvince, sponsorPostcode, sponsorBusinessTelephone, and sponsorFax remain bare-optional even within a true branch, consistent with this registry's policy of not over-requiring secondary contact detail absent its own printed signal.
5. applicationType collapses 7 independent AcroForm checkboxes into one enum (Application_Type_-_Visitor/Working_Resident/Business/ Entertainer/Student/Special_Exemption/Dependent, each its own Btn widget with exportValue "Yes", not a single radio-button field), consistent with this registry's established convention for this checkbox-group pattern. The form's own instruction reads "TICK THE PURPOSE AND CIRCLE A DESCRIPTION OF YOUR VISIT TO PNG": beneath/around each of the 7 category checkboxes sits a list of finer-grained descriptive labels (e.g. under Working Resident: "Short-term Employment", "Employment", "Consultant/Specialist"; under Special Exemption: "Film maker", "Comedian", "Musician", "Melanesian Spearhead", "Foreign Official", "Diplomat", etc.) meant to be hand-circled, not ticked — none of these finer descriptions carries its own AcroForm widget anywhere on the specimen, so none is modelled as a separate field; only the 7 category-level checkboxes, which do carry widgets, are modelled.
6. The page-2 employment-purpose document checklist (4 checkboxes) is inferred to gate on applicationType == WORKING_RESIDENT. The form's own page-2 heading reads "For entry for the purpose of employment: Please attach copies of the following documents" opposite "For all other types of entry: How will you be funding your Stay in PNG?" — real conditional prose — but neither heading cross-references the page-1 application-type checkbox labels by name. Of the 7 application-type categories, only Working Resident's own page-1 descriptive labels ("Short-term Employment", "Employment", "Consultant/Specialist") describe genuine paid employment; this schema therefore infers applicationType == WORKING_RESIDENT as the gating condition for sponsorEmploymentLetterAttached/workPermitApprovalAttached/ medicalCertificateAttached/policeClearanceAttached (and the four matching documents[] entries), disclosed as an inference rather than a literal cross-reference printed on the form.
7. The four "how will you be funding your Stay in PNG" checkboxes (fundedBySalary/fundedByCompanySponsor/fundedByOwnFunds/ fundedByFamily) are left entirely ungated (bare-optional, no requiredWhen), even though they are the page-2 counterpart to the employment-document checklist above. Unlike that checklist (four items that read as a single unconditional list once employment purpose is established), these four are independent, mutually non-exclusive checkboxes with no "tick one" or "at least one" instruction of their own, and the requiredWhen grammar available to this spec only expresses single-field conditions, not "at least one of these four fields must be true" — encoding a mandatory-selection constraint here would overreach what the form itself states. Disclosed rather than invented.
8. previousSex and previousMaritalStatus are genuine Ch (combo-box) dropdown widgets, each with a blank first option (exportValue " ") followed by the real choices (F/M for sex; Married/Never married/ Divorced/Widowed/De-facto for marital status) — the blank option is not modelled as a valid enum value, and both enums are normalised to the same MALE/FEMALE and MARRIED/DE_FACTO/WIDOWED/DIVORCED/ NEVER_MARRIED vocabulary already established by this schema's own top-level sex/maritalStatus fields (themselves collapsed from independent Btn checkboxes on page 1), for cross-field consistency, rather than preserving the dropdown's own raw single-letter/differently -ordered export values verbatim.
9. Two separate, non-combined address blocks exist for the applicant (RESIDENTIAL, page 3, and a second "PNG:" in-country stay address, page 3), each backed by its own full set of independent AcroForm widgets — modelled as two fully separate groups of fields (residential*/ pngStay*) rather than combined into one address field each, since the source itself prints two visually and semantically distinct address sections with different sub-label sets (Suburb/Town vs. Town/Village; State/Province vs. Province; the PNG block additionally has its own separate "Postal Address" box with no residential-block equivalent).
10. The page-1 TRAVEL ARRANGEMENTS row was disambiguated by rect position, not by the joined-line text's own left-to-right order — see the Extraction method section above for the full detail.
11. The page-3 DECLARATION statement's own printed wording reads "...the information provided on the form is true and correct at I have disclosed all information that may be relevant..." — quoted verbatim (sic) in the applicantDeclaration document's statement field. A raw per-glyph re-extraction of this exact paragraph confirmed the text-layer's own reading order is internally consistent (not a sort-order artifact of overlapping text runs, unlike the travel-arrangements row above) — "at I have" therefore appears to be the source PDF's own genuine wording (most likely originally intended as "and that I have"), not an extraction defect, though this cannot be independently confirmed without a canvas-rendered image (unavailable in this environment).
12. Instruction 3's own address ("The completed form and the applicant's passport should be sent to: The Chief Migration Officer... PO Box 1790, BOROKO, NCD, Papua New Guinea") establishes that the applicant's physical passport itself, not merely passport particulars, must accompany the submitted form — modelled as the applicantPassport documents[] entry (category identity-document, required), distinct from the passportNumber/passportExpiryDate/passportIssueDate/ passportIssuingPlace/passportIssuingAuthority fields[] entries that model the printed particulars.
13. No application fee of any kind is printed anywhere on this specimen (unlike pg/ica/passport-application's own K100 fee), confirmed by a full page-by-page text-layer read for "fee"/ currency-amount mentions — the only currency figure on the entire specimen ("K300.00 a month", page 4) is general proof-of-funds guidance for tourists/visitors, not a payable application fee — so no documents[] payment entry is modelled.

Structure

Models 89 fields[] across 12 steps, 6 documents[] entries, and 1 crossFieldValidation rule. 3 of the 89 fields — hasChangedNameOrAlias/hasOtherPassport/hasOrganisationalSponsor — are directly-supplied gates without a backing widget; the other 86 collapse this specimen's 102 total AcroForm widgets, since 16 widgets across 8 checkbox-group/pair collapses — applicationType [7→1], sex [2→1], maritalStatus [5→1], agreeToEmailContact [2→1], visitedPNGBefore [2→1], hasCriminalConviction [2→1], hasBeenDeportedOrRefusedEntry [2→1], hasMedicalConditionOrMentalHealthHistory [2→1] — each collapse into one enum/boolean field. The 6 documents[] entries are the applicant's own physical passport; four employment-purpose supporting documents gated on applicationType == WORKING_RESIDENT; and the Declaration attestation. The 1 crossFieldValidation rule (passportExpiryNotBeforeIssue) checks the passport's own expiry date is not before its issue date, mirroring pg/ica/passport-application's own travelDocumentExpiryNotBeforeIssue and bz/doi/passport-application's reportDateNotBeforeDateOfLoss.

Conformance

2 valid mock scenarios — valid-visitor-minimal-no-conditional-history (a minimal Visitor applicant exercising the false/absent branch of every one of this schema's 8 conditional gates) and valid-working-resident-full-conditional-history (a Working Resident applicant exercising the true branch of all 8 conditional gates simultaneously, including the full organisational-sponsor, previous-name/ alias, other-passport, prior-visit, criminal-conviction, deportation, and medical-history blocks) — plus 18 mutation-control fixtures (7 missing-required fixtures spanning an enum, two strings, a date, and three booleans across different steps; 8 missing-requiredWhen fixtures, one per conditional branch; an invalid-enum-value fixture against applicationType; an unknown-field-rejected fixture; and a crossFieldValidation-violation fixture with passportExpiryDate set before passportIssueDate) — are committed under conformance/pg/ica/entry-permit-application/1.0.0/.

An ephemeral, from-scratch conformance checker (deriving required/ requiredWhen/crossFieldValidation rules directly from this schema's own fields[], discarded after use, not committed) ran all 20 fixtures: both valid scenarios at 0 errors, all 18 mutation controls each raising exactly 1 error. Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs, individually and as part of the full registry run (706/706 documents pass both validators with this file included).

Outcome

Opens Papua New Guinea's Visa vertical (3 of 6 verticals now open, alongside Business Formation via pg/ipa/business-name-registration and Passport via pg/ica/passport-application). DMV and Taxes remain confirmed dead ends per GOV-5812's own screening; National ID has two live but flat (zero-widget) candidates, weaker than a genuine AcroForm, still banked as backlog; the ICA's own "Application to Extend Entry Permit" (62 widgets) remains unauthored backlog for a future cycle, as a distinct renewal/ extension action rather than a first-entry application.