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
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- Verification record
registry/tz/immigration/visa-application/1.0.0/VERIFICATION.mdtext/markdown- 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
-
visaTypeTravelboolean optionalOne 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".
-
visaTypeTransitboolean optionalSee 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).
-
surnameOrFamilyNamestring requiredSurname or Family Name
length: 0–150classification: pii -
firstNamesInFullstring requiredThe 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 -
dateOfBirthdate requiredDate of Birth
classification: sensitive-pii -
sexenum requiredA 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 -
placeOfBirthstring requiredPlace of Birth
length: 0–150classification: pii -
countryOfBirthstring requiredCountry of Birth
length: 0–100classification: pii -
presentNationalitystring requiredPresent Nationality
length: 0–100classification: pii -
nationalityAtBirthstring requiredNationality at Birth
length: 0–100classification: pii -
purposeOfVisaLeisureHolidayboolean optionalOne of twelve mutually-exclusive purpose-of-visa options printed as a 4-row x 3-column checkbox grid (see exclusivityGroups).
-
purposeOfVisaBusinessboolean optionalSee 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.
-
purposeOfVisaVariousboolean optionalSee purposeOfVisaLeisureHoliday for the mutual-exclusivity note.
-
purposeOfVisaVisitingFriendsRelativesboolean optionalSee purposeOfVisaLeisureHoliday for the mutual-exclusivity note.
-
purposeOfVisaStudyboolean optionalSee purposeOfVisaLeisureHoliday for the mutual-exclusivity note.
-
purposeOfVisaDiplomaticboolean optionalSee 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.
-
purposeOfVisaMissionboolean optionalSee 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).
-
purposeOfVisaTransitboolean optionalSee 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.
-
purposeOfVisaOfficialboolean optionalSee purposeOfVisaLeisureHoliday for the mutual-exclusivity note.
-
purposeOfVisaMeetingConferenceboolean optionalSee purposeOfVisaLeisureHoliday for the mutual-exclusivity note.
-
purposeOfVisaHealthTreatmentboolean optionalSee purposeOfVisaLeisureHoliday for the mutual-exclusivity note.
-
purposeOfVisaSameDayVisitorboolean optionalSee purposeOfVisaLeisureHoliday for the mutual-exclusivity note.
-
requestedNumberOfEntriesSingleboolean optionalOne of two mutually-exclusive entry-count options (see exclusivityGroups).
-
requestedNumberOfEntriesMultipleboolean optionalSee 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.
-
requestedDurationOfStayDaysinteger requiredThe form itself caps this at 90 days: "Requested duration of stay: ___ days (Max. 90)".
range: 1–90 -
typeOfPassportOrdinaryboolean optionalOne of four mutually-exclusive passport-type options (see exclusivityGroups).
-
typeOfPassportDiplomaticboolean optionalSee 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.
-
typeOfPassportServiceboolean optionalSee typeOfPassportOrdinary for the mutual-exclusivity note.
-
typeOfPassportOtherTravelDocumentboolean optionalSee typeOfPassportOrdinary for the mutual-exclusivity note.
-
otherTravelDocumentSpecifystring optionalThe blank line printed immediately beneath the Type of Passport checkbox row, positioned after "(Please specify)"; required only when typeOfPassportOtherTravelDocument is selected.
length: 0–300 -
passportNumberstring requiredPassport Number
length: 0–30classification: sensitive-pii -
passportDateIssueddate requiredDate Issued
classification: sensitive-pii -
passportValidUntildate requiredValid Until
classification: sensitive-pii -
passportIssuedAtstring requiredIssued At
length: 0–150 -
passportIssuingAuthoritystring requiredIssuing Authority
length: 0–200 -
maritalStatusSingleboolean optionalOne of five mutually-exclusive marital-status options (see exclusivityGroups).
-
maritalStatusMarriedboolean optionalSee maritalStatusSingle for the mutual-exclusivity note.
-
maritalStatusDivorcedboolean optionalSee maritalStatusSingle for the mutual-exclusivity note.
-
maritalStatusWidowedboolean optionalSee maritalStatusSingle for the mutual-exclusivity note.
-
maritalStatusLegallySeparatedboolean optionalSee maritalStatusSingle for the mutual-exclusivity note.
-
currentAddressstring requiredThe 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 -
postalCodestring optionalNot required: not every country's postal system applies to every applicant's current address.
length: 0–20 -
citystring requiredCity
length: 0–100classification: pii -
telephoneNostring requiredTelephone No
length: 0–30classification: pii -
faxNostring optionalNot required: a fax number is a legacy contact channel most applicants no longer have.
length: 0–30classification: pii -
emailAddressstring requiredE-mail Address
patternlength: 0–150classification: pii -
professionOccupationstring requiredProfession/Occupation
length: 0–150 -
employerAddressstring optionalNot 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 -
nameOfTravelAgentTourOperatorstring optionalNot required: only applicable to an applicant travelling through a travel agent or tour operator.
length: 0–200 -
arrivalDatesInTanzaniastring requiredModelled 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 -
departureDatesFromTanzaniastring requiredSee arrivalDatesInTanzania for the free-text-vs-date reasoning.
length: 0–60 -
physicalAddressWhileInTanzaniastring requiredThe form itself glosses this as "(Name of hotel(s), tour operator(s), person(s) or organization(s) visited)".
length: 0–300classification: pii -
fundingAvailableCashstring optionalNot required: only one of the three printed funding methods (cash, credit card, travelers cheques) need apply to any given applicant.
length: 0–60 -
fundingAvailableOtherstring optionalThe 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 -
minor1Namestring 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 -
minor1Sexstring optionalUnlike 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 -
minor1YearOfBirthinteger optionalExpected to be filled in whenever minor1Name is filled in; not machine-gated, for the same reason as minor1Sex.
classification: sensitive-pii -
minor2Namestring optionalMinor travelling in applicant's passport 2: Name(s)
length: 0–200classification: pii -
minor2Sexstring optionalExpected to be filled in whenever minor2Name is filled in; not machine-gated, for the same reason as minor1Sex.
length: 0–20 -
minor2YearOfBirthinteger optionalExpected to be filled in whenever minor2Name is filled in; not machine-gated, for the same reason as minor1Sex.
classification: sensitive-pii -
minor3Namestring optionalMinor travelling in applicant's passport 3: Name(s)
length: 0–200classification: pii -
minor3Sexstring optionalExpected to be filled in whenever minor3Name is filled in; not machine-gated, for the same reason as minor1Sex.
length: 0–20 -
minor3YearOfBirthinteger optionalExpected to be filled in whenever minor3Name is filled in; not machine-gated, for the same reason as minor1Sex.
classification: sensitive-pii -
hasEntryPermitForFinalDestinationboolean optionalThe 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.
-
finalDestinationEntryPermitValidUntildate optionalRequired only when hasEntryPermitForFinalDestination is true.
-
signingDatedate requiredDate
-
signingPlacestring requiredPlace
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:draftverification.method:manual-source-review-v1verification.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.6magic 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.3magic 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.urlinschema.jsonpoints 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:
page.getAnnotations()on both pages: 44 Widget annotations on page 1, 38 on page 2 — 82 widget annotations total.doc.getFieldObjects(): 80 distinct fully-qualified field names (two names —DiplomaticandTransit— 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 atpage: -1for those two shared names (82 + 2 = 84 total field-object array entries, reconciling exactly against the 82 counted in step 1).page.getTextContent()(items sorted by transform x/y) on both pages, to read every printed label and cross-correlate it against each widget'srect.
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
- Two AcroForm field names are each shared by two visually/semantically distinct checkboxes — a source authoring defect, not reproduced.
getFieldObjects()shows the literal fieldDiplomaticbacks 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 fieldTransitbacks 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.jsonmodels all four checkboxes as four independent boolean fields (visaTypeTransit/purposeOfVisaTransit,purposeOfVisaDiplomatic/typeOfPassportDiplomatic), each disclosing the shared-name defect in its owndescription, rather than collapsing any pair to match the source's accidental linkage. Othersinternal 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 isOthers. Modelled aspurposeOfVisaBusiness(matching the printed label a human sees), with the mismatch disclosed in itsdescriptionrather than propagated as a misleading schema field name.- 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. - 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 ownalternativeTextas 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 asdays Max 90.
- 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) andCurrent 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 showsProfessionOccupation 1(rect y570.1-582.1) is the one and only line for "Profession/Occupation:", whileProfessionOccupation 2(rect y543.2-555.2) sits directly beneathEmployer Address(rect y556.7-568.7), not beneathProfessionOccupation 1. It isEmployer Address's own overflow line, mislabelled internally with a copy-pastedProfessionOccupationprefix — the same class of naming sloppiness as finding 2. Modelled as part ofemployerAddress, keyed to its rendered position, not its internal name.
- 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 asfundingAvailableOther, documented as covering both of the two methods the source gives no dedicated field for. - 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 birthwidgets (_2/_3suffixed) — 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. - Minor
Sexfields modelled as free text, not an M/F enum. The main applicant's ownSexfield carries an explicit "(M/F)" instruction ("Sex (M/F)"), justifying theenum: ["M","F"]modelling used elsewhere in this registry for instructed M/F text blanks (e.g.ph/dfa/passport-application). The minors table'sSexcolumn carries no such instruction of its own — just the bare word "Sex" — sominorNSexis modelled as free text rather than assuming the same convention applies. - 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 (seeuy/mrree/formulario-unificado-de-visasjudgment call 4;do/mirex/visa-applicationscope decision 1): core identity/passport/current-location/contact/purpose/declaration fields are modelledrequired: 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, theminor1..minor3table) are modelled optional. - 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,requiredWhenvisaTypeTransitistrue(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 — seeus/uscis/petition-alien-relative-i130's own VERIFICATION.md for the same precedent).finalDestinationEntryPermit ValidUntilremainsrequiredWhenhasEntryPermitForFinalDestinationistrue. - The declaration's
Signaturewidget is a genuine PDF/FT /Sigfield, not a text field — modelled as adocuments[]attestation, not a scalar field.getAnnotations()reportsfieldType: "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 thedeclarationCertificationdocuments[]entry (category: attestation) rather than afields[]entry;signingDateandsigningPlace(both genuineTxtext widgets) remain scalar fields. - 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 fillableVISA NOwidget (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 genuineTxwidgets, 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 bothhasEntryPermitForFinalDestination's andfinalDestinationEntryPermitValidUntil'srequiredWhen).mutation-control-missing-required-field.json— dropspassportNumber.mutation-control-invalid-date-format.json—dateOfBirthset to12/04/1991instead of ISOYYYY-MM-DD.mutation-control-invalid-sex-enum.json—sexset to"X".mutation-control-invalid-email-pattern.json—emailAddressset to"not-an-email".mutation-control-missing-conditional-other-travel-document.json— setstypeOfPassportOtherTravelDocument: truewithout the requiredotherTravelDocumentSpecify.mutation-control-missing-conditional-entry-permit.json— setsvisaTypeTransit: truewithout the requiredhasEntryPermitForFinalDestination.mutation-control-missing-declaration-attestation.json— drops thedeclarationCertificationdocument 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.mjs—488/488documents passed (full registry, including this one).node tools/validate-ajv.mjs—488/488documents 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'ssource.url,authority.url, and the two URLs cited above), 0 failures (1 transient WARN onimmigration.go.tz, tolerated per the tool's own retry/backoff design; manually re-confirmed reachable with a directcurl, HTTP 200).npm run build-index(intools/govschema-client/) re-run to regenerateregistry-index.json— 488 entries.
View the raw record (VERIFICATION.md)
Version history
-
1.0.0draftlatestthis pagehas verification recordschema.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.