Panama Tourist Visa Application

Candidate selection

GOV-4293 ("GovSchema Standard Research", 2026-07-22). The GOV-4271 cycle (2026-07-22, opening Zambia as the registry's 77th jurisdiction) screened Panama and Albania in parallel as candidate new-jurisdiction openings and banked Panama's Visa candidate — Migración Panamá's tourist-visa PDF — as pre-scouted, disclosed backlog: the strongest of Panama's six verticals (DMV, Business Formation, Passport, Taxes, and National ID each route exclusively into a login-gated online portal with no static application-form document; only Visa had an unauthenticated, unGated PDF). Zambia won that cycle on a stronger three-candidate showing across all six verticals, so Panama was left open. This cycle re-screens the banked candidate fresh and authors it, opening Panama as the registry's 78th jurisdiction via its Visa vertical (1 of 6).

Reaching the live source

Fetched https://migracion.gob.pa/wp-content/uploads/10-Formulario_visa_de_turista.pdf directly with a plain unauthenticated curl request (no session/cookie state, no CAPTCHA/WAF challenge):

• HTTP 200, 313,700 bytes.
• sha256 a5c4a233bfa243ccf77b17d767ab83eae044d199dd154023b393519916574fdc.
• PDF header %PDF-1.7 at byte 0 — a genuine native (searchable-text) PDF, not a scanned image.
• Independently re-confirmed as still the banked GOV-4271 URL, unchanged since that cycle's scouting pass.

Extraction method

Extracted with pdfjs-dist (vendored from an existing session scratch install at /tmp/node_modules), reading each page's text content directly — extraction was clean and complete across all 3 pages with no glyph-mapping workaround needed. A supplementary render-to-PNG pass via pdfjs-dist + node-canvas was attempted to visually cross-check the page 2/3 layout, but this particular PDF's embedded Times-family fonts triggered getPathGenerator/"object isn't resolved yet" glyph-rendering errors in this session's node-canvas build, leaving the rendered images mostly blank of text (checkbox glyphs did render, confirming their positions). This is a rendering-pipeline limitation, not a text-extraction one: pdfjs-dist's getTextContent() API (used for the actual field inventory below) reads the underlying character stream directly and does not depend on the glyph rasterizer, and returned complete, coherent bilingual text for all three pages. Field positions (transform x/y) were additionally read directly from the text-content API to disambiguate side-by-side columns (e.g. item 2's two adjacent "Usual name" / "Legal name" boxes) without needing the image render.

Document structure

A bilingual Spanish/English, three-page, single form: "Solicitud de Visa de Turista / Requesting a Visa as a Tourist," 32 numbered items (numbering genuinely skips from 20 to 22 in the source itself — confirmed by direct inspection of each text item's y-position, which shows a single ordinary paragraph-gap between items 20 and 22, not a truncated or misread item 21; this schema does not model a field numbered 21, since none exists), plus an unnumbered closing certification paragraph, signature block, and a final section reserved for applications filed from within Panama specifically (requiring an attorney's name, signature, Cédula, and idoneidad/professional- registration number) — out of scope, per below.

Page 1's own printed instructions read (bilingually): "Do not leave blank spaces. In cases the interrogation does not apply to you, write 'Not Applied' (N/A)." Per this registry's established precedent for forms carrying this exact instruction (see et/mor/individual-tin-registration, GOV-4246), this drives required: true for the great majority of fields — "N/A" is itself a valid literal value satisfying a required: true string field, so requiredness here reflects "must answer something," not "must supply real data." requiredWhen is reserved for the handful of fields the form itself gates on a narrower, more specific printed condition than the blanket instruction (marital status driving spouse/partner details; Yes/No-gated visa-history and residency follow-up fields; the purpose-of-travel enum driving its own conditional free-text lines).

Fields modelled

50 fields[] across 10 steps (Applicant's identity; Travel document; Marital status and family; Residence and contact; Occupation; Contacts and accommodation in Panama; Journey details; Panama visa history; Future intentions and other residency; Declaration) plus 1 documents[] entry.

Disclosed source-fidelity findings

1. Item 2 ("Nombre usual / Usual name" and "Nombre Legal / Legal name") is modelled as two separate fields (usualName, legalName) whose relationship to item 1's already-captured full name is not further explained by the source. The two labels appear as adjacent, clearly distinct printed boxes at the same y-position (confirmed via direct x/y text-position inspection: "Nombre usual" at x≈73, "Nombre Legal" at x≈294, both at y≈484), so they are modelled as the form's own genuine structure rather than merged into one field — but the form gives no further guidance on when a usual name would differ from the legal name already given in item 1. Flagged as an open interpretive question for a future re-verification pass with clearer official guidance, if any becomes available; not a blocking ambiguity since both are ordinary optional-content string fields under the page-1 fill-all/N/A instruction.
2. Item 14 ("Declare if having any relatives or friends in Panama") is modelled as two independent, ungated optional fields (relative1NameRelationAddress, relative2NameRelationAddress), each combining name/relation/address-and-phone into one field per the source's own printed row structure (two identical blank rows, no further sub-division). Unlike most of this form, item 14's own "Declare if..." framing is a conditional invitation, not a blanket fill-all instruction, so these two fields are left required: false with no fabricated boolean gate, per this registry's established precedent for ungated conditional fields with no printed antecedent checkbox (e.g. es/maec/solicitud-visado-nacional's guardianDetails).
3. Items 23 and 24 (prior stay in Panama; denied/revoked visa or residence) are each modelled as a single free-text field (previousStayInPanamaDetails, deniedOrRevokedVisaOrResidenceDetails) rather than a boolean-plus-detail pair, because — unlike item 22, which prints an explicit Sí/No checkbox pair (confirmed via the rendered-page checkbox glyphs at the expected position) — no separate Yes/No control was found printed for items 23 or 24 in either the text extraction or the checkbox-position scan; each is a single blank the applicant fills directly (with "N/A" when inapplicable, per the page-1 instruction). Item 24's own blank is confirmed to continue onto page 3 under its own "Tipo de visa, permiso y fecha / Type of visa, permission and date" sub-heading, modelled as the same single field per the source's own layout rather than split across a page boundary.
4. The form's own final section — reserved for applications presented from within Panama, requiring an attorney's name, signature, Cédula (personal identification number), and idoneidad (professional registration number) — is excluded from this schema, as is the receiving official's own signature line. Both are administration-facing or in-country-specific submission-channel content, not part of the general applicant-facing form this schema models, consistent with this registry's standing precedent for excluding "reserved to the administration" sections (e.g. es/maec/solicitud-visado-nacional's own "PARTE RESERVADA A LA ADMINISTRACIÓN" exclusion).
5. All physical-signature fields are excluded, per this registry's standing convention. The applicant's own certification is instead modelled as a boolean acknowledgement (certificationAcknowledged) of the form's printed certification paragraph, plus its accompanying declarationDate; the "name of the person who filled the form" (item 32) models only the name, not the accompanying signature.

Conformance

3 valid mock scenarios — valid-single-tourist (an unmarried applicant travelling alone for tourism, no conditional branches triggered); valid-married-family-visit-prior-visa-and-residency (a married applicant visiting a relative in Panama, previously authorized a Panama tourist visa, and resident of a country other than their nationality — exercising the maritalStatus-gated spouse fields, the purposeOfTravel-gated family-visit detail field, the hasBeenAuthorizedPanamaVisaBefore-gated prior-visa-type field, and the isResidentOfCountryOtherThanNationality-gated residency- country field and its companion document); and valid-transit-filled-by-agent (an applicant in transit to a third country, form filled out by a travel agent on their behalf — exercising the purposeOfTravel-gated transit-destination field and the formFilledByAnotherPerson-gated filler-name field) — plus 10 mutation-control fixtures (three missing-required fixtures — touristLastName, maritalStatus, certificationAcknowledged; five missing-required fixtures exercising requiredWhen-gated fields correctly triggered in their scenario — spouseOrPartnerName, previousVisaTypeDetails, residencyCountryIfDifferent, transitDestination, personWhoFilledFormName; an invalid-enum fixture for maritalStatus; and an unknown-field-rejected fixture) are committed under conformance/pa/migracion/tourist-visa-application/1.0.0/. An ephemeral, from-scratch conformance checker (deriving required/requiredWhen/enum rules directly from this schema's own fields[], discarded after use, not committed) ran all 13: both valid scenarios' non-triggered fixture at 0 errors, the two conditional-scenario valid fixtures each at 0 errors with every gated field correctly satisfied, and all 10 mutation controls each raising exactly 1 error of the expected kind. Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs, individually and as part of the full registry run (595/595 documents, including this one).