Zimbabwe e-Visa Application (Ordinary Single-Entry)

Candidate selection

GOV-4481 (child of GOV-4476, "GovSchema Standard Research"). Opens Zimbabwe's Visa vertical (3 of 6), following the zw/zimra Taxes (GOV-4470) and Business Formation (GOV-4478) schemas.

Reaching the live source

The issue delegating this work disclosed that evisa.gov.zw's field schema is not behind login: the entire compiled Angular client ships on a plain unauthenticated GET before any auth. Independently re-fetched fresh rather than trusting the delegating issue's own disclosed hash: https://www.evisa.gov.zw/app/main.baa2096ea7e0d09e.js, HTTP 200, Content-Type JavaScript, 7,376,521 bytes — byte-for-byte matching the delegating issue's own disclosed size, confirming the specimen is unchanged. https://www.evisa.gov.zw/app/index.html#/start returns HTTP 200, 50,568 bytes, and redirects an unauthenticated visitor to #/sign-in (confirmed via a real Playwright/Chromium session, realistic desktop UA, LD_LIBRARY_PATH/FONTCONFIG_FILE sandboxed-launch fix applied per this registry's own established recipe). The sign-in screen's own "No account yet?" link reaches a sign-up form requiring e-mail verification to proceed — not completable without a real inbox, and not attempted, since GovSchema does not create accounts on government portals it documents. This confirms, first-hand, the delegating issue's own caution that live-browser rendering of the actual multi-step wizard is not the reliable path for this specimen (the issue additionally reported a prior SIGABRT crash on an unrelated MRZ/passport-scanner WASM asset); all field-level modelling below is instead drawn from static re-extraction of the compiled bundle's own source code, which is authoritative for what the client actually submits regardless of account access.

Extraction method

The bundle is minified but not obfuscated: every Angular reactive-form field configuration survives as a literal JavaScript object (e.g. {name:e.Wd.PURPOSE_OF_VISIT,type:"select",validators:[n.kI.required],...}), and the field-name enum (Wd) and section-name enum (mP) both survive as literal U.SOME_KEY="someValue" assignment chains. Located and bracket-matched (respecting string/escape state) four distinct product field-configuration objects, each keyed by section name ([e.mP.PERSONAL_DETAILS], etc.); the one beginning with PERSONAL_DETAILS+EMERGENCY_CONTACT+TRAVEL_INFORMATION+DOCUMENT sections and containing passport issue/expiry dates, arrival/departure dates, and funds-available fields is the one modelled here as the ordinary zwevisa product — distinguished from a second, adjacent configuration (personal details + travel information with vehicle/mode-of-travel numbers, an existing-entry-reference field, and a residence-permit-number field, but no advance passport-issue/expiry or arrival/departure dates) that is far more plausibly the physical border-crossing zweentry form, and from a third (attestant/extension-reason fields) that is plainly one of the zwevisaextc/zwevisaextab extension forms. Cross-referenced every field's translation key (form.*, 241 keys confirmed, matching the delegating issue's own disclosed count) against the bundle's own embedded, per-language translation object literals (no separate assets/i18n/*.json file exists; translations are inlined directly in main.js) to recover human-readable labels, taking the first English-language occurrence per key after confirming several samples resolved to genuine English text rather than a stray cross-reference.

The applicant's document-type (passportType) and nationality are set on a separate, shared "passport-type" screen (component class confirmed by name) reused across every product, not part of the four-section field-configuration object; its selectable document types are a subset of a shared PassportType enum (ordinary, diplomatic, marine, service, laissez-passer, identity-card, resident-permit, refugee, permanent-resident-permit) which are exposed to the applicant, only 5 of which (ordinary, diplomatic, service, refugee, marine) carry a confirmed English translation anywhere in the bundle — the remaining 4 (identity-card, resident-permit, permanent-resident-permit, laissez-passer) have no translation and no other reference in the bundle, and are excluded here as unconfirmed for this product rather than fabricated. Similarly, the applicant's planned port of entry (plannedEntry) is set on a dedicated "travel-name" screen whose own component code fetches its selectable options at runtime from a separate live API call (this.api.schema("zweentry"), reading properties.ProvisionnalEntryPort.enum) rather than embedding them statically in this bundle; that live endpoint was not called (it plausibly requires the same account session as the wizard itself, and calling an unfamiliar authenticated-looking endpoint speculatively was judged out of scope for a static bundle re-extraction), so plannedEntry is modelled as an open string rather than a fabricated closed enum.

Disclosed findings

1. The "Application reference" field (BatchId/travelName, called out in the delegating issue's own field list) is excluded from fields[] entirely. Its own component code (found and read in full) shows it is not applicant-supplied: this.form.controls.travelName.patchValue(this.cart.currentApplication.travelName||this.cart.getUniqueReference(this.existingTravelNames)) immediately followed by this.form.controls.travelName.disable() — the client itself generates a unique reference and disables the control before the applicant ever sees it. It carries a Validators.required only because the system always supplies a value, not because a human must type one; modelled here the same way this registry excludes other system/office-assigned identifiers (e.g. ZIMRA's own pre-issuance office box).
2. lastName, firstName, and otherName are modelled required: false, matching the source's own configuration exactly, despite this being surprising for a visa applicant's own name. The extracted field objects for these three carry only a name-shape pattern validator (^[A-Za-z\s\-]+$) and no Validators.required — confirmed by direct, repeated reading of the raw configuration text, not a parsing artifact. The most plausible explanation (not itself confirmed, disclosed as inference only) is that these fields are ordinarily auto-populated from the passport-scan upload's OCR/MRZ pipeline earlier in the same product family, making a client-side required check redundant in the reference implementation; this schema models the confirmed validator set as-is rather than adding a required flag the source does not carry.
3. No field in the Supporting Documents section carries a Validators.required (or any validators array at all) in the extracted configuration, unlike every other section, where required fields are explicit. All 14 modelled documents[] entries are therefore required: false, disclosing this as a genuine, confirmed absence rather than an assumption; the government's own officer-review workflow (found separately in the same bundle) manually inspects and can reject an application short on supporting evidence, rather than the client blocking submission.
4. Five generic "Extra document" upload slots (ExtraDocument1–ExtraDocument5) and one further upload field explicitly marked hidden: true in its own source configuration (PreviousVisa) are excluded from documents[]. The five extra slots carry no semantic label distinguishing one from another (each only progressively reveals the next via ifFormControlHasValue chaining) and the sixth is explicitly hidden from the applicant by the source's own flag; none represents a distinct, nameable document requirement.
5. gender, maritalStatus, fundsAvailableCurrency, passportType, and modeOfTravel enum values are modelled using the exact lower-case (and, for passportType, hyphenated) string literals the compiled client itself submits (e.g. "male", "married", "USD", "ordinary", "flight"), rather than this registry's more common upper-cased convention for enums inferred from a printed paper form — because these values were read directly from the live client's own JavaScript enum definitions, not inferred from rendered text, source fidelity is best served by preserving the exact wire values.
6. purposeOfVisit's 9-value enum (business_visa, holiday_visa, conferencing_visa, transit_visa, student_visa, sports_visa, arts_visa, live_here, other_visa) includes live_here ("Long-term Resident"), an option that reads oddly for an advance single-entry tourist/business e-visa product. Modelled as-is because it is the confirmed, complete set of values referenced by this exact product's own field-configuration object (durationOfStayDays's own requiredWhen explicitly exempts this value), not a value borrowed from a different product.
7. durationOfStayDays is requiredWhen the applicant's purpose is anything other than live_here ({"not":{"field":"purposeOfVisit","equals":"live_here"}}), matching the source's own ifFormControlHasNotValue condition exactly.
8. The source's own relative-date rules that require date arithmetic beyond simple field-to-field comparison (e.g. a passport must remain valid at least 6 months beyond the arrival date; the applicant must be at least old enough that their passport's issue date follows their birth date) are disclosed in the relevant fields' own description, not encoded as crossFieldValidation, since GSP-0013's fieldCompare grammar supports only direct value comparison between two fields, not comparison against another field plus a duration offset. The two relationships that do map cleanly to direct comparison (dateOfIssue on/after dateOfBirth; departureDate on/after arrivalDate) are modelled as crossFieldValidation rules.

Conformance

3 valid mock scenarios — valid-holiday-single-applicant (an unmarried holiday visitor travelling by air, no spouse/companions/prior convictions); valid-business-visa-with-spouse-and-convictions-disclosed (a married business applicant travelling with their spouse, declaring a disclosed prior conviction in Zimbabwe, funds in EUR); and valid-long-term-resident-by-road (a live_here applicant entering by car, exercising carNumber and the durationOfStayDays exemption) — plus mutation-control fixtures (one missing-required-field fixture for each statically required field, an invalid-enum fixture, and an unknown-field-rejected fixture), committed under conformance/zw/immigration/evisa-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 fixtures: all 3 valid scenarios at 0 errors, all 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/.