Paraguay MRE Formulario de Visa Titular — Diplomatic, Official, and Courtesy Visa Application

Candidate selection

GOV-4451 ("GovSchema Standard Research"). The GOV-4424 cycle scouted Paraguay as a brand-new jurisdiction and found it the strongest of three candidates (4 of 6 verticals STRONG — Taxes, Business Formation, DMV, Visa; see CATALOG.md's Known Gaps entry 0i). Taxes, Business Formation, and DMV were authored first (GOV-4427, GOV-4435, GOV-4443); this issue authors Visa, the fourth and last of the scouting cycle's STRONG candidates, closing Paraguay's disclosed backlog entirely — Passport and National ID (cédula) remain confirmed dead ends per the scouting cycle's own findings.

Reaching the live source

The scouting cycle's own note already gave the exact document URL and byte count; both were independently re-verified rather than trusted at face value:

• https://www.mre.gov.py/wp-content/uploads/documentacion-dgp/Formulario_de_Visa_Titular_2021..docx
• HTTP 200, Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, 57,591 bytes — matching the banked figure exactly.
• No login, CAPTCHA, or WAF gate — a plain unauthenticated curl request with a desktop User-Agent reached it cleanly.
• sha256 1a85502c1a56c457fdb030b56af3c3198426f54d9f99ed5496298bac8b66a115.

A sibling "Dependiente" (dependent/family-member) form was referenced by the scouting cycle's own note as forming a ".docx pair" with this Titular form, but its exact URL slug could not be independently re-derived this cycle (the obvious Formulario_de_Visa_Dependiente_2021..docx guess 404s) — it is left as unverified, open backlog rather than guessed at, and this schema is scoped to the Titular form only.

Extraction method

This is a native Office Open XML .docx, unlike this registry's usual scanned/AcroForm PDF Paraguayan specimens. Extracted with Python's standard-library zipfile module (no pip/third-party dependency needed) to unzip the archive, then xml.etree.ElementTree to parse word/document.xml and walk its w:body/w:tbl/w:tr/w:tc/w:p/ w:r/w:t element tree in document order, recovering every printed label together with its table position.

An explicit grep of the raw XML confirmed zero w:sdt content controls, zero legacy w:ffData form fields, and zero w:checkBox elements anywhere in the document — this specimen carries no structured form-field widgets of any kind. The only non-text constructs are decorative mc:AlternateContent/w:pict VML checkbox-box shapes preceding a handful of printed option labels (Nueva Expedición/ Renovación; No/Sí) — rendered boxes meant to be marked by hand, not machine-readable fields. These were used only to identify which printed labels are mutually-exclusive checkbox options versus plain blank-line fields; every other field is a blank table cell meant to be typed into directly, the same "flat, form-tool-generated document with no structured fields" pattern this registry's other Paraguayan specimens (py/suace/business-formalization-individual, py/mda/driving-licence-declaration) already establish, just via a .docx container instead of a PDF.

Document structure

A single page: a photo-attachment placeholder ("FOTO 5X5 FONDO BLANCO Pegar Aquí") and header identifying the Ministerio de Relaciones Exteriores's Dirección General de Protocolo; a request-date line and "Misión Diplomática/Org. Int." field; a two-way Nueva Expedición/ Renovación checkbox pair; a "DATOS DEL TITULAR" block (name, place and date of birth, nationality, a Sí/No permanent-residency question with a conditional Cédula de Identidad number, marital status, sex, home address/city, passport type-and-number, passport country, passport validity Desde/Hasta, date of entry into the country, point of entry); a "DATOS LABORALES" block (rank/grade, function performed, approximate length of stay, name of predecessor if applicable, work address/city, work phone, email); a signature block (Firma del Titular, Sello de la Misión, Jefe de Misión Firma y Aclaración); a "Uso exclusivo de la Dirección General de Protocolo" office-processing block (Procesado por / V°B° Jefe de Asuntos Protocolares / Autorizado); and a "NÚMERO DE VISA / TIPO DE VISA / VISA VALIDA HASTA" block recording the visa the government ultimately issues.

Scope: excluded blocks

• The photo-attachment placeholder — a physical photograph, not a data field.
• The signature/seal block ("Firma del Titular", "Sello de la Misión", "Jefe de Misión Firma y Aclaración") — physical signatures and a physical seal, with no corresponding blank data cell.
• "Uso exclusivo de la Dirección General de Protocolo" — internal government sign-off (Procesado por / V°B° Jefe de Asuntos Protocolares, Inmunidades y Privilegios / Autorizado), not applicant input. The same class of exclusion this registry's py/suace/business-formalization-individual (Finding 8) and py/dnit/individual-income-tax-return (Finding 5) already draw around their own "for official use" blocks.
• The "NÚMERO DE VISA / TIPO DE VISA / VISA VALIDA HASTA" block — the visa the government issues as output of the process, not applicant input.
• The closing "Los formularios presentados revisten carácter de declaración jurada" line — a printed legal notice, not a field.

Disclosed findings and interpretation choices

1. This form is scoped to diplomatic/official/courtesy visas specifically, per its own printed title ("VISA DIPLOMÁTICA – OFICIAL – DE CORTESÍA") — it is not Paraguay's general tourist/ business visa, which the GOV-4424 scouting cycle separately confirmed is a distinct login-gated online system excluded from consideration. This form is filed by an accrediting diplomatic mission or international organization on behalf of the Titular (visa beneficiary), not filed directly by an ordinary traveler.
2. sexo is modelled as an enum (masculino/femenino), not free text, even though the source prints a plain blank cell with no option list — following this registry's established convention for the identical situation on py/mda/driving-licence-declaration's own sexo field (itself following do/mirex/passport-application's precedent).
3. estadoCivil (marital status) is modelled as free-text string, not enum, since the source prints only a plain blank cell with no checkbox group — following uy/mrree/formulario-unificado-de-visas's own explicit precedent for the same distinction (a blank line is free text; a printed checkbox grid would be an enum, and this form has no such grid for marital status).
4. tieneResidenciaPermanente is modelled as boolean, not enum, since the source's "¿Posee residencia permanente en el Paraguay?" question is a plain two-way Sí/No choice, consistent with this registry's convention of using boolean for two-way Sí/No questions (as opposed to enum for the form's own tramiteType, a genuinely different Nueva Expedición/Renovación choice, not a yes/no question).
5. tipoNumeroPasaporte combines passport type and number into one field, since the source prints exactly one blank cell under the single label "Tipo y N° de Pasaporte" with no separate boxes — unlike py/suace/business-formalization-individual's own three-document-type row, this source gives the combined label only one cell, so no split is invented.
6. nombreAntecesor (name of predecessor) is modelled as optional (required: false) with no requiredWhen gate, per the source's own footnote instruction "Indicar en el caso de que corresponda a un nuevo cargo" (indicate only if this corresponds to a new posting) — a genuinely conditional-on-circumstance field with no other form field it could be gated against.
7. requestDate (the top-of-form "Fecha:" line) is modelled as a required applicant-facing field, distinct from the separate office-processing block's own internal sign-off dates — it sits in the form's main body immediately after the header, before the office-only block begins, consistent with this being the date the submitting mission completes the form.
8. No field in this source carries an asterisk or other explicit required-field marker (unlike py/suace/business-formalization-individual, which marks required fields with *). Requiredness here is inferred from the form's own structural purpose: every identity, passport, and employment field a diplomatic mission would need to supply to support a visa request is modelled as required, except the two fields the source itself marks conditional in wording (cedulaIdentidadNumero, gated on tieneResidenciaPermanente) or by footnote (nombreAntecesor).

Conformance

3 valid mock scenarios:

• valid-nueva-expedicion-sin-residencia — a new diplomatic-visa request for a Titular with no Paraguayan permanent residency.
• valid-renovacion-con-residencia-permanente — a renewal for a Titular who holds Paraguayan permanent residency, exercising the conditional cedulaIdentidadNumero.
• valid-nueva-expedicion-con-antecesor — a new courtesy-visa request exercising the optional nombreAntecesor field for a new posting.

8 mutation-control fixtures (one missing statically-required field each from requestDate, misionDiplomatica, tramiteType, nombres, fechaNacimiento, tieneResidenciaPermanente, sexo, correoElectronico) and one unknown-field-rejected fixture, all committed under conformance/py/mre/visa-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 12 fixtures: all 3 valid scenarios at 0 errors, all 8 mutation controls each raising exactly 1 error, and the unknown-field fixture correctly rejected.

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/.