Ecuador Visa Application (Formulario de Solicitud de Visa)

This file is the source-review record for this document version, per the manual-source-review-v1 practice. It documents the provenance of the published fields and states the current verification claim honestly.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-16

This is a GovSchema Standard Research cycle (GOV-3305), a general research-analyst brief covering DMV, Business Formation, Visa, Passport, Taxes, and National ID & Civic Documents across all jurisdictions.

Why this candidate

Every jurisdiction already in the registry (62 at the start of this cycle) had at least one prior cycle screen every one of its remaining open vertical gaps, and the large majority were re-confirmed dead ends this same cycle (Japan DMV/Passport, Uruguay Taxes/Passport/National ID, Pakistan Passport/Visa/National ID, Peru Passport/National ID, Chile Passport/Visa/National ID, Spain Passport/Visa, Sri Lanka Business Formation, North Macedonia/Slovakia/Netherlands/Poland Visa, Malaysia Taxes, Jordan DMV/Business Formation/National ID — see CATALOG.md's own accumulated screening notes). Rather than re-scout an already-exhausted gap, this cycle opened a brand-new 63rd jurisdiction: Ecuador, not previously modelled at all. A targeted web search for Ecuador's own government visa/immigration form found:

• SRI (tax authority) RUC registration forms (FORMULARIO RUC01A, a genuine PDF for business-registry inscription): the SRI web server itself did not respond to a direct connection attempt this cycle (curl: exit 28, connection timeout) — a candidate for a future cycle once connectivity is re-checked, not pursued here.
• Registro Civil identity-card issuance: the citizen-facing service page describes in-person/online-portal issuance with no downloadable static application form found.
• Cancillería (Ministry of Foreign Affairs and Human Mobility) visa application form — the strongest candidate found: a current (dated January 2025 in its own upload path), genuine 45-widget AcroForm PDF hosted directly by the Ministry, covering all four of its visa categories (temporary residence, permanent residence, temporary visitor, diplomatic) and five request types (application, certificate, renewal, transfer, cancellation) in one unified bilingual form. This document authors that candidate, opening Ecuador's Visa vertical (1 of 6).

Sources examined

Primary source

• Authority: Ministerio de Relaciones Exteriores y Movilidad Humana (Cancillería)
• Document: Formulario de Solicitud de Visa / Visa Application Form
• URL (directly retrieved, HTTP 200, application/pdf): https://www.cancilleria.gob.ec/wp-content/uploads/2025/01/formulario_solicitud_visa0165183001736872889-1.pdf
• File identity: sha256:79707ebe96b7e28893e66e0c0780f279da3facbfd855ef5231cc0ee38e33fbf0, 213,407 bytes.
• TLS caveat, disclosed rather than worked around silently: this exact URL's certificate chain is missing an intermediate certificate — both curl and Node's global fetch (the same client tools/verify-sources.mjs uses) fail standard TLS verification against it (unable to get local issuer certificate). This is a server-side misconfiguration on www.cancilleria.gob.ec, not evidence the document is stale, fabricated, or gated: the file was still retrieved successfully with certificate verification disabled (curl -k), confirmed a genuine, well-formed %PDF-1.6 file, and is byte-identical (same sha256, same 213,407 bytes) to an independently-fetched archive.org snapshot taken 2026-01-28 — itself found via the Wayback Machine's available API, not manually guessed. Because this repository's own source.url field must resolve over standard TLS for future automated re-verification, source.url points at that archive.org snapshot instead of the (currently TLS-misconfigured) Ministry URL directly; the Ministry URL above remains the authoritative origin and is unchanged in content from the archived copy.
• Extraction method: pdfjs-dist (legacy build) for both the AcroForm widget inventory (doc.getFieldObjects()) and the text layer (page.getTextContent(), position-sorted by item.transform[4]/[5] for x/y), plus a direct page render via pdfjs-dist + node-canvas at 2.2x scale to visually confirm widget-to-label correlation where the coordinate-only heuristic was ambiguous (see judgment call 1 below).
• Retrieved / reviewed: 2026-07-16

Alternative sources considered and not used

• SRI (Servicio de Rentas Internas) FORMULARIO RUC01A (business-registry inscription form) — a genuine PDF surfaced by search, but sri.gob.ec did not respond to a direct fetch attempt this cycle (curl exit 28, connection timeout over both HTTP and HTTPS). Left as an unscreened backlog candidate for Ecuador's Business Formation vertical for a future cycle, not a confirmed dead end.
• SRI individual income-tax declaration (Formulario 102/102A) — the SRI's own guidance describes filing exclusively through the authenticated "SRI en línea" web portal; no downloadable blank return form was found independent of that same connectivity issue, so this was not conclusively screened either way this cycle.
• Registro Civil identity-card request — the citizen-facing service page (registrocivil.gob.ec/emision-de-documentos-de-identidad/) describes first-issuance/renewal/duplicate handling via in-person appointment or an online citizen portal (servicios.registrocivil.gob.ec) requiring registration; no downloadable static application-form PDF was found in this cycle's search results. Not conclusively screened as a hard dead end (a future cycle with direct portal access could still find a genuine source), but not pursued further this cycle in favor of the stronger-sourced Cancillería visa form.

Field inventory (Phase 3)

The AcroForm carries 45 Widget annotations, all on page 1 (the form's only page): 29 Tx plain-text fields (named Texto1-Texto30, skipping Texto28) and 16 Btn checkbox fields (named Casilla de verificación1-16). None carry a self-documenting alternativeText tooltip. Because several rows share ambiguous coordinate proximity to more than one printed caption (especially the Estado Civil/Sexo checkbox grid, where five and two checkboxes respectively sit close to multiple adjacent labels), this document was correlated using both position-matching and a direct visual render, cross-checked against the rendered image before assignment.

| Field (schema name) | Label (source) | AcroForm widget | Example valid value | |---|---|---|---| | visaCategory | Residencia Temporal / Permanente / Visitante Temporal / Diplomático | Casilla de verificación1-4 | "RESIDENCIA_TEMPORAL" | | requestType | Solicitud / Certificado-Visa / Renovación / Transferencia / Cancelación | Casilla de verificación5-9 | "SOLICITUD" | | passportNumber | Número de Pasaporte | Texto1 | "AB1234567" | | passportCountryOfIssue | País Donde se Emitió Pasaporte | Texto2 | "Colombia" | | passportIssueDate | Fecha de Emisión | Texto3 | "2022-03-10" | | passportExpiryDate | Fecha de Expiración | Texto4 | "2032-03-10" | | apellidos | Apellidos | Texto13 | "Restrepo Gómez" | | nombres | Nombres | Texto14 | "Valentina" | | lugarNacimiento | Lugar de Nacimiento | Texto5 | "Medellín, Colombia" | | fechaNacimiento | Fecha de Nacimiento | Texto6 | "1995-06-21" | | nacionalidad | Nacionalidad | Texto7 | "Colombiana" | | ocupacion | Ocupación | Texto8 | "Ingeniera de software" | | estadoCivil | Estado Civil (Soltero/Casado/Viudo/Divorciado/Unión de Hecho) | Casilla de verificación10-14 | "SOLTERO" | | sexo | Sexo (Femenino/Masculino) | Casilla de verificación15-16 | "FEMENINO" | | direccionEcuador | Dirección Ecuador | Texto10 | "Av. Amazonas N34-120" | | ciudad | Ciudad | Texto11 | "Quito" | | provincia | Provincia | Texto12 | "Pichincha" | | correoElectronico | Correo Electrónico Principal | Texto15 | "valentina@example.com" | | telefonoMovil | Número Teléfono Móvil | Texto16 | "+593 99 123 4567" | | telefonoDomicilio | Número Teléfono Domicilio | Texto17 | "+593 7 234 5678" | | entidadAuspiciante | Entidad Auspiciante | Texto18 | "Tech Solutions Ecuador S.A." | | nombreResponsableEntidad | Nombre del Responsable en la Entidad Auspiciante | Texto19 | "Carlos Andrade" | | categoriaVisa | Categoría de Visa que Desea Aplicar | Texto20 | "Visa de Residencia Temporal por Relación Laboral" | | documentoEntregado1-9 | Documentos Entregados, items 1.- through 9.- | Texto29, Texto9, Texto21-27 (in that item order) | "Copia de pasaporte vigente" | | resumenPeticion | En Texto Resuma su Petición de Visa | Texto30 | "Solicito visa de residencia temporal..." |

Not modelled (excluded and disclosed, not silently dropped):

• The printed wet-ink signature line ("FECHA/Date" and "FIRMA/Signature", bottom of page) — no corresponding AcroForm widget exists at that position; a physical signature captured after printing, consistent with this registry's existing convention for consular/immigration forms (e.g. pe/cancilleria/solicitud-visa-dgc-005, uy/mrree/formulario-unificado-de-visas).
• The entire "Para Uso Oficial / For official use only" block (Arancel, Valor, Fecha de Autorización, Observaciones, and the responsible official's own name/signature line) — Ministry-staff-only case-processing fields, not applicant-facing, and no AcroForm widgets exist there either.

Access notes and judgment calls

1. Widget-to-label correlation required a direct page render, not just coordinate matching. A first pass matching each field's rect to the nearest text below it (mirroring this registry's usual "field box, then bilingual caption beneath it" heuristic) produced ambiguous or wrong results for two groups: (a) the passport-number row's four fields, whose own bilingual captions actually sit inside each field's rect near its bottom edge (an italic placeholder-style caption), not fully below it, so an over-wide matching window pulled in the next row's captions instead; and (b) the Estado Civil/Sexo checkbox grid, where five and two checkboxes respectively sit close to more than one adjacent label in a non-uniform 2-row grid. Both were resolved by rendering the page to a PNG at 2.2x scale via pdfjs-dist + node-canvas and visually reading the grid layout directly, then re-deriving each widget's assignment from the confirmed visual row/column position. This is disclosed because a coordinate-only heuristic, used alone, would have mis-assigned several fields.
2. visaCategory and requestType are each collapsed from independent checkbox widgets into a single enum field, per this registry's convention already established by pe/cancilleria/solicitud-visa-dgc-005's visaType/maritalStatus/sexo fields — the source implements no structural (e.g. radio-group) exclusivity of its own, but the printed options are mutually exclusive by their own meaning.
3. telefonoDomicilio, entidadAuspiciante, and nombreResponsableEntidad are required: false; every other mapped field defaults to required: true. The form prints no asterisk or other required/optional marker system anywhere. telefonoDomicilio is optional because a home landline is not universal once a mobile number is already captured. entidadAuspiciante/nombreResponsableEntidad are optional because a sponsoring organisation is only meaningful for residence/work-based applications, not every visaCategory value (e.g. a Visitante Temporal tourist), and the source provides no requiredWhen- style visibility instruction of its own to gate these fields on visaCategory explicitly — treating them as unconditionally required would over-constrain applicants who genuinely have none to name.
4. The nine documentoEntregadoN fields are modelled as free text, not a documents[] array. The source prints nine identically-blank numbered lines (1.- through 9.-) for the applicant to self-list whichever supporting materials are physically attached; it names no fixed document types of its own (unlike, e.g., pe/cancilleria/solicitud-visa-dgc-005's single named applicantPhoto requirement). A documents[] entry requires a fixed, non-empty label, which would misrepresent this source's actual blank-checklist structure; nine optional string fields instead preserve the source's own shape faithfully.
5. categoriaVisa is distinct from visaCategory. The source prints both: a checkbox grid naming the four broad application types (visaCategory), and a separate free-text line ("Categoría de Visa que Desea Aplicar") where the applicant names the specific visa sub-category/legal basis (e.g. a specific statutory clause) being requested under that broad type. Modelled as two separate fields rather than conflated into one.

Test run (Phase 4)

No live submission was attempted: Ecuador's visa process is consular/Ministry-counter (printed, signed by hand, and submitted with original supporting documents), not a portal accepting programmatic submissions, and submitting fabricated identity data against a foreign government's consular/immigration process is not a safe or reversible action — the same reasoning already documented for this registry's other consular/immigration schemas (e.g. pe/cancilleria/solicitud-visa-dgc-005, uy/mrree/formulario-unificado-de-visas, co/cancilleria/visa-application-individual).

Instead, two independent worked mock records were built from this document's own field inventory and checked with a purpose-written script (validate_instance.mjs, mirroring the approach used by those same three prior schemas): compiles schema.json's fields[] into a JSON Schema document checked with ajv (+ajv-formats for date).

``` $ node validate_instance.mjs registry/ec/cancilleria/formulario-solicitud-visa/1.0.0/schema.json \ conformance/ec/cancilleria/formulario-solicitud-visa/1.0.0/temporary-resident-first-time-applicant.json Static (required/type/pattern/enum) validation: PASS

OVERALL: PASS

$ node validate_instance.mjs registry/ec/cancilleria/formulario-solicitud-visa/1.0.0/schema.json \ conformance/ec/cancilleria/formulario-solicitud-visa/1.0.0/temporary-visitor-married-no-sponsor.json Static (required/type/pattern/enum) validation: PASS

OVERALL: PASS ```

Mutation controls — three negative fixtures, each targeting a distinct validation rule, built from the first valid fixture:

``` $ # mutation-control-missing-required-field.json: 'passportNumber' (required: true) removed Static (required/type/pattern/enum) validation: FAIL - (root) must have required property 'passportNumber' OVERALL: FAIL

$ # mutation-control-invalid-enum-value.json: 'estadoCivil' set to "EN_PAREJA" (not in the enum) Static (required/type/pattern/enum) validation: FAIL - /estadoCivil must be equal to one of the allowed values OVERALL: FAIL

$ # mutation-control-maxlength-violation.json: 'passportNumber' set to a 25-character string (maxLength: 20) Static (required/type/pattern/enum) validation: FAIL - /passportNumber must NOT have more than 20 characters OVERALL: FAIL ```

All five fixtures behaved exactly as expected. registry/validate.mjs and registry/validate-ajv.mjs (this registry's own zero-dependency structural validator and full meta-schema validator, respectively) both pass on schema.json itself.