Registry entry

Tanzania — Visa Application Form (Embassy of the United Republic of Tanzania)

The United Republic of Tanzania's standard "Visa Application Form", a genuine fillable AcroForm PDF served directly by the Embassy of the United Republic of Tanzania in Washington, D.C. and used at Tanzanian diplomatic missions abroad to apply for a Travel (ordinary) or Transit visa. Opens Tanzania's Visa vertical (the country's fifth schema in this registry, following Business Formation via BRELA Form 14a, DMV via TRA Form MV10, National ID & Civic Documents via NIDA Form 2A, and Taxes via TRA ITX201.01-E; Tanzania now stands at 5 of 6 verticals). This is a whole-of-form schema: a fixed-layout, non-repeating, 2-page form covering the applicant's identity/passport particulars, the visa type/purpose/duration/number-of-entries requested, current residential and contact details, employment, travel-agent/tour-operator details, planned arrival/departure and in-country address, funding source, a bounded 3-row repeating group for minors travelling on the applicant's own passport, a transit-specific entry-permit question, and the applicant's dated declaration. It excludes the page 1 "FOR OFFICIAL USE ONLY" box (ERV No., Draft No., Date, Bank Name — none of which are fillable AcroForm fields, and the fillable "VISA NO." field inside the same box, which is consulate-assigned rather than applicant-supplied) and the page 2 "For official use only" table (Station, Type of visa issued, Visa sticker No, Processing Officer, Authorizing officer, Date), all staff-assigned intake/adjudication data the applicant never supplies; it also excludes two uncaptioned stray AcroForm text widgets disclosed in VERIFICATION.md (one carrying pdfjs-dist's literal placeholder alternative text "undefined") that correspond to no printed label anywhere on the form. The declaration's wet-ink `Signature` widget (a genuine PDF `/FT /Sig` field, not a text field) is modelled as a `documents[]` attestation entry rather than a scalar field, consistent with this registry's treatment of signature lines. This document describes the form only; it does not submit anything to the Government of Tanzania on an applicant's behalf, and does not imply endorsement by the United Republic of Tanzania, its Ministry of Home Affairs, its Immigration Department, or its Embassy in Washington, D.C. GovSchema is an independent, non-profit standards body.

Registry entry

tz/immigration/visa-application

Jurisdiction
Tanzania · national
Version
1.0.0
Verification
draft

Authoritative source "Visa Application Form" (Embassy of the United Republic of Tanzania, Washington, D.C.), 2-page fillable AcroForm PDF.

Machine access

Schema document
registry/tz/immigration/visa-application/1.0.0/schema.jsonapplication/schema+json
Registry catalog
registry/index.jsonone record per schema id

Field reference

67 fields, read from the published schema.json, with names, types, requiredness, and validation as the document states them. The live government form remains the authoritative source.

Fields

  • visaTypeTravel boolean optional

    One of two mutually-exclusive visa-type options (see exclusivityGroups). The underlying AcroForm widget's own tooltip ("Ordinary") is a copy-paste artifact from elsewhere in the form; the printed label is "Travel Visa".

  • visaTypeTransit boolean optional

    See visaTypeTravel for the mutual-exclusivity note. At the underlying PDF level this checkbox shares its AcroForm field name ("Transit") with the unrelated "Purpose of Visa: Transit" checkbox further down the page — a source field-naming defect disclosed in this document's verification notes and deliberately not reproduced; the two are modelled as independent fields (visaTypeTransit vs purposeOfVisaTransit).

  • surnameOrFamilyName string required

    Surname or Family Name

    length: 0–150classification: pii
  • firstNamesInFull string required

    The printed blank spans two lines (the AcroForm carries two widgets, tooltips "First Names in Full [1]"/"[2]", stacked with no intervening caption), modelled here as one field for the applicant's full given name(s).

    length: 0–300classification: pii
  • dateOfBirth date required

    Date of Birth

    classification: sensitive-pii
  • sex enum required

    A text blank with an explicit "(M/F)" instruction, not a checkbox pair; modelled as an enum of the two values the form itself instructs.

    enum: M | Fclassification: pii
  • placeOfBirth string required

    Place of Birth

    length: 0–150classification: pii
  • countryOfBirth string required

    Country of Birth

    length: 0–100classification: pii
  • presentNationality string required

    Present Nationality

    length: 0–100classification: pii
  • nationalityAtBirth string required

    Nationality at Birth

    length: 0–100classification: pii
  • purposeOfVisaLeisureHoliday boolean optional

    One of twelve mutually-exclusive purpose-of-visa options printed as a 4-row x 3-column checkbox grid (see exclusivityGroups).

  • purposeOfVisaBusiness boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note. The underlying AcroForm widget's own field name is "Others", a mismatch with the printed "Business" label disclosed in this document's verification notes; not reproduced as a misleading schema field name.

  • purposeOfVisaVarious boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note.

  • purposeOfVisaVisitingFriendsRelatives boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note.

  • purposeOfVisaStudy boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note.

  • purposeOfVisaDiplomatic boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note. At the underlying PDF level this checkbox shares its AcroForm field name ("Diplomatic") with the unrelated "Type of Passport: Diplomatic" checkbox further down the page — a source field-naming defect disclosed in this document's verification notes and deliberately not reproduced; the two are modelled as independent fields (purposeOfVisaDiplomatic vs typeOfPassportDiplomatic). Confirmed by 3x-scale render to be a genuine, independent, single-word category checkbox, not a mis-split half of a "Diplomatic Mission" label.

  • purposeOfVisaMission boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note. Confirmed by 3x-scale render to be a genuine, independent, single-word category checkbox in its own grid cell (row 3, column 1), not a continuation of "Diplomatic" (row 2, column 3).

  • purposeOfVisaTransit boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note. At the underlying PDF level this checkbox shares its AcroForm field name ("Transit") with the unrelated "Type of Visa Requested: Transit Visa" checkbox higher up the page — see visaTypeTransit.

  • purposeOfVisaOfficial boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note.

  • purposeOfVisaMeetingConference boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note.

  • purposeOfVisaHealthTreatment boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note.

  • purposeOfVisaSameDayVisitor boolean optional

    See purposeOfVisaLeisureHoliday for the mutual-exclusivity note.

  • requestedNumberOfEntriesSingle boolean optional

    One of two mutually-exclusive entry-count options (see exclusivityGroups).

  • requestedNumberOfEntriesMultiple boolean optional

    See requestedNumberOfEntriesSingle for the mutual-exclusivity note. The form's own footnote reads "(* not for transit visa)" — this option is not applicable when visaTypeTransit is selected.

  • requestedDurationOfStayDays integer required

    The form itself caps this at 90 days: "Requested duration of stay: ___ days (Max. 90)".

    range: 1–90
  • typeOfPassportOrdinary boolean optional

    One of four mutually-exclusive passport-type options (see exclusivityGroups).

  • typeOfPassportDiplomatic boolean optional

    See typeOfPassportOrdinary for the mutual-exclusivity note. At the underlying PDF level this checkbox shares its AcroForm field name ("Diplomatic") with the unrelated "Purpose of Visa: Diplomatic" checkbox higher up the page — see purposeOfVisaDiplomatic.

  • typeOfPassportService boolean optional

    See typeOfPassportOrdinary for the mutual-exclusivity note.

  • typeOfPassportOtherTravelDocument boolean optional

    See typeOfPassportOrdinary for the mutual-exclusivity note.

  • otherTravelDocumentSpecify string optional

    The blank line printed immediately beneath the Type of Passport checkbox row, positioned after "(Please specify)"; required only when typeOfPassportOtherTravelDocument is selected.

    length: 0–300
  • passportNumber string required

    Passport Number

    length: 0–30classification: sensitive-pii
  • passportDateIssued date required

    Date Issued

    classification: sensitive-pii
  • passportValidUntil date required

    Valid Until

    classification: sensitive-pii
  • passportIssuedAt string required

    Issued At

    length: 0–150
  • passportIssuingAuthority string required

    Issuing Authority

    length: 0–200
  • maritalStatusSingle boolean optional

    One of five mutually-exclusive marital-status options (see exclusivityGroups).

  • maritalStatusMarried boolean optional

    See maritalStatusSingle for the mutual-exclusivity note.

  • maritalStatusDivorced boolean optional

    See maritalStatusSingle for the mutual-exclusivity note.

  • maritalStatusWidowed boolean optional

    See maritalStatusSingle for the mutual-exclusivity note.

  • maritalStatusLegallySeparated boolean optional

    See maritalStatusSingle for the mutual-exclusivity note.

  • currentAddress string required

    The printed blank spans two lines (the AcroForm carries two widgets, tooltips "Current Address [1]"/"[2]", stacked with no intervening caption), modelled here as one field.

    length: 0–400classification: pii
  • postalCode string optional

    Not required: not every country's postal system applies to every applicant's current address.

    length: 0–20
  • city string required

    City

    length: 0–100classification: pii
  • telephoneNo string required

    Telephone No

    length: 0–30classification: pii
  • faxNo string optional

    Not required: a fax number is a legacy contact channel most applicants no longer have.

    length: 0–30classification: pii
  • emailAddress string required

    E-mail Address

    patternlength: 0–150classification: pii
  • professionOccupation string required

    Profession/Occupation

    length: 0–150
  • employerAddress string optional

    Not required: an unemployed, retired, or self-funded applicant has no employer to declare and the form provides no separate "none" option. The printed blank spans two lines; the AcroForm's second widget is internally named "ProfessionOccupation 2" (a copy-paste naming artifact from the field above it) but is positioned, per the rendered page, directly beneath Employer Address rather than beneath Profession/Occupation — modelled here as this field's continuation, not professionOccupation's.

    length: 0–400
  • nameOfTravelAgentTourOperator string optional

    Not required: only applicable to an applicant travelling through a travel agent or tour operator.

    length: 0–200
  • arrivalDatesInTanzania string required

    Modelled as free text, not a single calendar date, since the form's own label is plural ("Date(s)") and the printed blank is short enough only for a single trip's arrival date in practice, but the label itself does not foreclose a date range.

    length: 0–60
  • departureDatesFromTanzania string required

    See arrivalDatesInTanzania for the free-text-vs-date reasoning.

    length: 0–60
  • physicalAddressWhileInTanzania string required

    The form itself glosses this as "(Name of hotel(s), tour operator(s), person(s) or organization(s) visited)".

    length: 0–300classification: pii
  • fundingAvailableCash string optional

    Not required: only one of the three printed funding methods (cash, credit card, travelers cheques) need apply to any given applicant.

    length: 0–60
  • fundingAvailableOther string optional

    The form prints "Credit card" and "Travelers cheques" as plain words on the same line as "Cash $/___" with no dedicated blank or checkbox of their own (confirmed by 3x-scale render); the only remaining fillable space is a full-width blank line immediately below (the AcroForm's own internal name for this widget is "Credit card"), modelled here as covering both methods since the source provides no way to distinguish which of the two an amount belongs to.

    length: 0–300
  • minor1Name string optional

    "Minors Travelling in Applicant's Passport" prints a bounded 3-row table (3 sets of Name(s)/Sex/Year of birth widgets, confirmed by render), not an open-ended list; flattened here to minor1..minor3. Not required: an applicant with no minors on their own passport leaves the whole table blank.

    length: 0–200classification: pii
  • minor1Sex string optional

    Unlike the main applicant's "Sex (M/F)" field, this column carries no (M/F) instruction of its own; modelled as free text rather than an invented enum. Expected to be filled in whenever minor1Name is filled in, but not machine-gated with requiredWhen, since minor1Name is itself optional and absent (not empty-string) when unused.

    length: 0–20
  • minor1YearOfBirth integer optional

    Expected to be filled in whenever minor1Name is filled in; not machine-gated, for the same reason as minor1Sex.

    classification: sensitive-pii
  • minor2Name string optional

    Minor travelling in applicant's passport 2: Name(s)

    length: 0–200classification: pii
  • minor2Sex string optional

    Expected to be filled in whenever minor2Name is filled in; not machine-gated, for the same reason as minor1Sex.

    length: 0–20
  • minor2YearOfBirth integer optional

    Expected to be filled in whenever minor2Name is filled in; not machine-gated, for the same reason as minor1Sex.

    classification: sensitive-pii
  • minor3Name string optional

    Minor travelling in applicant's passport 3: Name(s)

    length: 0–200classification: pii
  • minor3Sex string optional

    Expected to be filled in whenever minor3Name is filled in; not machine-gated, for the same reason as minor1Sex.

    length: 0–20
  • minor3YearOfBirth integer optional

    Expected to be filled in whenever minor3Name is filled in; not machine-gated, for the same reason as minor1Sex.

    classification: sensitive-pii
  • hasEntryPermitForFinalDestination boolean optional

    The source prints this as two independent checkboxes ('No' and 'Yes') rather than a single field; collapsed into one boolean per this registry's established convention for a printed Yes/No checkbox pair mapping to one underlying question (see us/uscis/petition-alien-relative-i130 VERIFICATION.md for the same 'structural interpretation, not literal 1:1 transcription' precedent). The question's own text scopes it to transit applicants ('In case of Transit'), directly supporting the requiredWhen gate on visaTypeTransit.

  • finalDestinationEntryPermitValidUntil date optional

    Required only when hasEntryPermitForFinalDestination is true.

  • signingDate date required

    Date

  • signingPlace string required

    Place

    length: 0–100

Verification record

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-15

This is a GovSchema Standard Research cycle (GOV-3216), opening Tanzania's Visa vertical. Tanzania stood at 4 of 6 verticals entering this cycle (Business Formation via tz/brela, DMV via tz/tra Form MV10 (GOV-3214), National ID & Civic Documents via tz/nida, Taxes via tz/tra ITX201.01-E); it now stands at 5 of 6.

(Review-gate correction, GOV-3223: this branch was drafted before GOV-3214's DMV opening landed on main, so the paragraph above originally read "3 of 6 entering this cycle... it now stands at 4 of 6" and schema.json's description/verification.notes said the same; corrected here and there, plus in CATALOG.md, during rebase-before-merge rather than round-tripped back to the author, per this registry's established practice for this exact stale-branch pattern.)

Sources examined

Source 1 (primary source, Embassy of the United Republic of Tanzania, Washington D.C.)
  • Authority (printed on the form): "THE EMBASSY OF THE UNITED REPUBLIC OF TANZANIA", 22nd St. NW, Washington D.C 20037.
  • Document: "Visa Application Form"
  • URL (directly retrieved with a plain curl, no User-Agent/session/referrer needed): https://www.us.tzembassy.go.tz/uploads/forms/Visa_Application_Form_fillable.pdf
  • HTTP status / content type: 200 / application/pdf
  • File identity: sha256:daff7c35a97eb9a9e5fd14a21952bbc914b958cb6934c0d87271cbcc7ef57218, 1,521,186 bytes, Last-Modified: Tue, 09 Nov 2021 22:09:46 GMT, genuine %PDF-1.6 magic bytes.
  • Retrieved / reviewed: 2026-07-15
Source 2 (cross-check only, not the canonical source, Immigration Department scanned mirror)
  • Authority: Immigration Department (Idara ya Uhamiaji), Ministry of Home Affairs — immigration.go.tz's own <title> confirms "Immigration Department - Tanzania Immigration Department".
  • URL: https://www.immigration.go.tz/index.php/application-and-declaration-forms?download=16%3Avisa-application-form
  • HTTP status / content type: 200 / application/pdf
  • File identity: sha256:5e44563cce176d4a764426ed0ddb5959619c9f7388a4fe622e623805300be8e8, 572,504 bytes, genuine %PDF-1.3 magic bytes — a different, smaller, scanned/flattened edition of the same form (confirmed visually via a node-canvas render), used only to confirm every section modelled below is the Immigration Department's own current form design rather than an embassy-specific one-off. source.url in schema.json points at the embassy's genuinely fillable AcroForm edition, since a form-filling agent needs the fillable original, not the scanned copy.
  • Retrieved / reviewed: 2026-07-15

Structural verification (AcroForm re-derived from scratch)

pdfjs-dist 3.11.174 (installed standalone in a scratch directory for this task, not added as a repository dependency) was used three ways:

  1. page.getAnnotations() on both pages: 44 Widget annotations on page 1, 38 on page 2 — 82 widget annotations total.
  2. doc.getFieldObjects(): 80 distinct fully-qualified field names (two names — Diplomatic and Transit — are each shared by two separate widgets; see "Duplicate field names" below), confirming 82 real widgets plus 2 non-terminal parent-node placeholder entries pdfjs-dist reports at page: -1 for those two shared names (82 + 2 = 84 total field-object array entries, reconciling exactly against the 82 counted in step 1).
  3. page.getTextContent() (items sorted by transform x/y) on both pages, to read every printed label and cross-correlate it against each widget's rect.

Both pages were additionally rendered to PNG at 3x scale via node-canvas (page.render()), and specific regions were cropped and visually inspected to resolve every ambiguity below rather than guessing from text/rect coordinates alone.

Findings and scope decisions

  1. Two AcroForm field names are each shared by two visually/semantically distinct checkboxes — a source authoring defect, not reproduced. getFieldObjects() shows the literal field Diplomatic backs both the "Purpose of Visa" grid's "Diplomatic" checkbox (page 1, rect [440.9,276.2,453.6,288.2]) and the "Type of Passport" row's "Diplomatic" checkbox (rect [211.8,141.6,224.5,153.6]); the literal field Transit backs both the header "Type of Visa Requested: Transit Visa" checkbox (rect [396.3,462.9,409.0,474.9]) and the "Purpose of Visa" grid's "Transit" checkbox (rect [311.7,263.5,324.4,275.5]). In a real PDF viewer these pairs are the same field and tick together — almost certainly an authoring defect (copy-pasted checkbox groups without renaming the field), since a diplomatic-passport holder is not necessarily requesting a diplomatic-purpose visa, and a transit-visa applicant is not necessarily also selecting "Transit" as a purpose (the grid already lists "Transit" as one of twelve otherwise-independent purpose options). schema.json models all four checkboxes as four independent boolean fields (visaTypeTransit/purposeOfVisaTransit, purposeOfVisaDiplomatic/typeOfPassportDiplomatic), each disclosing the shared-name defect in its own description, rather than collapsing any pair to match the source's accidental linkage.
  2. Others internal field name backs the visually-printed "Business" checkbox. The "Purpose of Visa" grid's row-1/column-2 checkbox (rect [312.2,291.7,324.9,303.7]) sits immediately beside the printed word "Business" in the 3x render, but its own AcroForm field name is Others. Modelled as purposeOfVisaBusiness (matching the printed label a human sees), with the mismatch disclosed in its description rather than propagated as a misleading schema field name.
  3. Purpose-of-Visa grid re-derived and visually confirmed as a 4x3 checkbox grid, not a mis-split label. Read row-by-row off the 3x render: row 1 = Leisure, Holiday / Business / Various; row 2 = Visiting friends, relatives / Study / Diplomatic; row 3 = Mission / Transit / Official; row 4 = Meeting, Conference / Health Treatment / Same day visitor. Raw getTextContent() output initially looked like it might be a two-line wrap of "Diplomatic Mission" split awkwardly across rows 2 and 3 (the word "Diplomatic" appears on row 2's text line at x=466, and "Mission" appears on row 3's text line but at x=180 — a different column's x-coordinate). The render resolved this unambiguously: "Diplomatic", "Mission", and "Official" are three separate, independently-checkable single-word category checkboxes, each in its own grid cell with its own checkbox square to its left — not a continuation artifact. Modelled as three distinct fields (purposeOfVisaDiplomatic, purposeOfVisaMission, purposeOfVisaOfficial), each disclosing this specific verification step.
  4. Two uncaptioned stray text widgets excluded from fields[]. Both exclusions are consistent with the general pattern already visible in findings 1-2 above: this specific PDF was assembled with some sloppy copy-paste field authoring (shared names, copied tooltips, stray extra widgets), and this document models what the form visually asks an applicant, not every technically-present widget.
    • days Max 90 (rect [72,170.2,537.4,182.2], page 1): a full-width text widget on its own blank line directly beneath the labelled "Requested duration of stay: ___ days (Max. 90)" line. The 3x render confirms this second line carries no printed caption of its own — just a bare underline. Excluded as a stray/leftover fillable area rather than invented as a second, unlabelled question.
    • undefined_2 (rect [485.0,103.1,539.8,115.1], page 1): a small text widget at the tail end of the "Date Issued: ___ Valid Until: ___" line. Its own alternativeText as reported by pdfjs-dist is the literal string "undefined" — Adobe Acrobat's default placeholder when a widget author never gave it a real tooltip. No distinct printed caption exists at this position in the render. Excluded for the same reason as days Max 90.
  5. Three "continuation" widget pairs — two collapsed by inspection, one by position rather than by its own (misleading) internal name.
    • First Names in Full [1]/[2] (page 1) and Current Address [1]/[2] (page 2): each pair is vertically stacked with no intervening caption (confirmed by rect y-coordinates and the render), plainly one answer's overflow onto a second printed line. Each pair is modelled as one schema field (firstNamesInFull, currentAddress).
    • ProfessionOccupation 1/ProfessionOccupation 2 (page 2) is not a clean continuation pair despite the shared name prefix: the render shows ProfessionOccupation 1 (rect y 570.1-582.1) is the one and only line for "Profession/Occupation:", while ProfessionOccupation 2 (rect y 543.2-555.2) sits directly beneath Employer Address (rect y 556.7-568.7), not beneath ProfessionOccupation 1. It is Employer Address's own overflow line, mislabelled internally with a copy-pasted ProfessionOccupation prefix — the same class of naming sloppiness as finding 2. Modelled as part of employerAddress, keyed to its rendered position, not its internal name.
  6. Funding-source line has only one dedicated blank. "Budge [sic] available for your stay: Cash $/___ Credit card Travelers cheques" prints three funding methods, but the render confirms only "Cash $/___" has its own checkbox-free blank; "Credit card" and "Travelers cheques" print as plain words with no blank or checkbox of their own anywhere on that line. A separate full-width blank line immediately below (internal widget name Credit card, rect [72,422.4,537.4,434.4]) is the only remaining fillable space in this section. Modelled as fundingAvailableOther, documented as covering both of the two methods the source gives no dedicated field for.
  7. Minors table is scoped narrowly: "Minors Travelling in Applicant's Passport", not general accompanying persons. The heading directly above the repeating Name(s)/Sex/Year of birth grid reads "Minors Travelling in Applicants' Passport:" (page 2). The grid's row count — 3, matching the 3 sets of Names/Sex/Year of birth widgets (_2/_3 suffixed) — was confirmed by the render, not assumed from the heading text alone. Modelled as a bounded 3-slot repeating group (minor1..minor3), per this registry's established bounded-repeating-group convention (e.g. rw/dgie/visa-application's own 4-slot children table), not an invented unbounded array.
  8. Minor Sex fields modelled as free text, not an M/F enum. The main applicant's own Sex field carries an explicit "(M/F)" instruction ("Sex (M/F)"), justifying the enum: ["M","F"] modelling used elsewhere in this registry for instructed M/F text blanks (e.g. ph/dfa/passport-application). The minors table's Sex column carries no such instruction of its own — just the bare word "Sex" — so minorNSex is modelled as free text rather than assuming the same convention applies.
  9. No printed required-field marker exists anywhere on this form. A programmatic scan of every text item on both pages for the glyph found exactly one match: the "( not for transit visa)" footnote beside the "Multiple" entries checkbox, which qualifies that option's own applicability (a note, not a requiredness legend). No asterisk, legend, or other marker distinguishes a required blank from an optional one anywhere else on the form. Requiredness below is therefore asserted from context, following this registry's established practice for forms with no such marker (see uy/mrree/formulario-unificado-de-visas judgment call 4; do/mirex/visa-application scope decision 1): core identity/passport/current-location/contact/purpose/declaration fields are modelled required: true; fields the form itself frames as conditional (otherTravelDocumentSpecify, finalDestinationEntryPermitValidUntil) or supplementary/contingent on circumstances the form does not otherwise gate (postalCode, faxNo, employerAddress, nameOfTravelAgentTourOperator, fundingAvailableCash/fundingAvailableOther, the minor1..minor3 table) are modelled optional.
  10. The transit entry-permit question's printed "No"/"Yes" checkbox pair is collapsed to one boolean field, not modelled as two. "In case of Transit: Do you have an entry permit for the final country of destination? No [ ] Yes [ ]" (page 2) prints as two independent checkboxes (confirmed distinct AcroForm widgets, rects [463.8,327.6,476.5,339.6] for "No" and [499.1,327.6,511.8,339.6] for "Yes"), but the two together answer one underlying yes/no question. Modelled as a single field, hasEntryPermitForFinalDestination, requiredWhen visaTypeTransit is true (the question's own text scopes it to transit applicants), per this registry's established convention for a printed Yes/No checkbox pair mapping to one underlying question (structural interpretation, not literal 1:1 transcription of every checkbox widget — see us/uscis/petition-alien-relative-i130's own VERIFICATION.md for the same precedent). finalDestinationEntryPermit ValidUntil remains requiredWhen hasEntryPermitForFinalDestination is true.
  11. The declaration's Signature widget is a genuine PDF /FT /Sig field, not a text field — modelled as a documents[] attestation, not a scalar field. getAnnotations() reports fieldType: "Sig" for this widget (page 2, beside "I hereby declare that the information stated above is true and correct: Date: ___ Place: ___ Signature ___"), distinct from every other widget on the form (all "Tx" or "Btn"). Consistent with this registry's convention for signature lines (a value with no scalar representation), it is modelled as the declarationCertification documents[] entry (category: attestation) rather than a fields[] entry; signingDate and signingPlace (both genuine Tx text widgets) remain scalar fields.
  12. Office-use sections excluded in full. Page 1's "FOR OFFICIAL USE ONLY" box (ERV No., Draft No., Date, Bank Name — printed but carrying no AcroForm widgets at all, confirmed by getFieldObjects()) and its own fillable VISA NO widget (consulate-assigned, inside the same box) are excluded. Page 2's "For official use only" table (Station, Type of visa issued, Visa sticker No, Processing Officer, Authorizing officer, Date — all genuine Tx widgets, but printed inside a bordered table explicitly headed "For official use only" and containing only officer-facing columns) is excluded in full, consistent with this registry's standard office-use-section treatment.

Conformance

2 valid mock scenarios and 7 mutation-control fixtures are committed under conformance/tz/immigration/visa-application/1.0.0/:

  • valid-single-entry-travel-visa-leisure.json — a single-entry Travel visa, leisure/holiday purpose, ordinary passport, single applicant.
  • valid-transit-visa-with-minor-and-entry-permit.json — a Transit visa, transit purpose, one accompanying minor on the applicant's own passport, and an affirmative answer to the transit-specific entry-permit question (exercising both hasEntryPermitForFinalDestination's and finalDestinationEntryPermitValidUntil's requiredWhen).
  • mutation-control-missing-required-field.json — drops passportNumber.
  • mutation-control-invalid-date-format.jsondateOfBirth set to 12/04/1991 instead of ISO YYYY-MM-DD.
  • mutation-control-invalid-sex-enum.jsonsex set to "X".
  • mutation-control-invalid-email-pattern.jsonemailAddress set to "not-an-email".
  • mutation-control-missing-conditional-other-travel-document.json — sets typeOfPassportOtherTravelDocument: true without the required otherTravelDocumentSpecify.
  • mutation-control-missing-conditional-entry-permit.json — sets visaTypeTransit: true without the required hasEntryPermitForFinalDestination.
  • mutation-control-missing-declaration-attestation.json — drops the declarationCertification document entry.

An ephemeral, from-scratch conformance checker (/tmp/gov3216/check.mjs, deriving required/requiredWhen/enum/pattern/exclusivityGroups rules directly from this schema's own fields[]/documents[]; discarded after use, not committed to the repository) ran all 9 fixtures: both valid scenarios at 0 errors, all 7 mutation-control fixtures at exactly 1 error each.

Tooling

  • node tools/validate.mjs488/488 documents passed (full registry, including this one).
  • node tools/validate-ajv.mjs488/488 documents validated against the v0.3 meta-schema (ajv 2020-12, full registry).
  • node tools/verify-sources.mjs registry/tz/immigration/visa-application/1.0.0 — 4 URLs checked (this document's source.url, authority.url, and the two URLs cited above), 0 failures (1 transient WARN on immigration.go.tz, tolerated per the tool's own retry/backoff design; manually re-confirmed reachable with a direct curl, HTTP 200).
  • npm run build-index (in tools/govschema-client/) re-run to regenerate registry-index.json — 488 entries.

View the raw record (VERIFICATION.md)

Version history

  • 1.0.0 draft latest this page has verification record schema.json

Independent and non-affiliated

GovSchema is an independent, open-source project. This reference is not produced, reviewed, or endorsed by Immigration Department or any government. The authoritative source is always the live government form and its official instructions.