Registry entry

Namibia Application for Visa (Form 3-1/0033)

The Namibian Ministry of Home Affairs, Immigration, Safety and Security (MHAISS), Department of Civic Affairs' "Application for Visa" (Form 3-1/0033), made under section 12 and 13 / Regulation 11 of the Immigration Control Act, 1993. Opens the Visa vertical for Namibia (GOV-4516, child of the recurring "GovSchema Standard Research" routine, following GOV-4513's re-discovery of the live source after this and the sibling BIPA CC1 Business Formation candidate both went stale since GOV-4488). Namibia's Taxes vertical is already published as na/namra/return-of-income-individuals@1.0.0; this schema is the second Namibia vertical. The source form's page 2 is explicitly split by its own printed instruction ("NOTE: COMPLETE ONLY PART A OR B") into two mutually exclusive branches — Part (A) Holiday/Business/Work/Transit Visa, and Part (b) Return Visa — modelled here via a required `visaCategory` discriminator field whose two enum values gate every Part-specific field's `requiredWhen`/`visibleWhen` (GSP-0013 §2), following this registry's established discriminator-field convention (e.g. the isBodyCorporate pattern in zm/pacra/company-incorporation and the applicationType/licenceDuration cross-tab in ug/mowt/driving-licence-application). The "FOR OFFICIAL USE ONLY" box on page 1 (Approved/Not Approved, Single/Multiple Entry, File No., Date of issue, Date of expiry, Remarks, official Signature/Date) is excluded from fields[] as officer-only, not applicant-supplied — see this document's own VERIFICATION.md for the full list of exclusions and disclosed scoping decisions. This schema does not submit the application itself; the live source is always authoritative. GovSchema is independent and is not affiliated with, endorsed by, or operated by the Government of the Republic of Namibia or its Ministry of Home Affairs, Immigration, Safety and Security.

Registry entry

na/mhaiss/visa-application

Jurisdiction
Namibia · national
Version
1.0.0
Verification
draft
Authority
Ministry of Home Affairs, Immigration, Safety and Security

Authoritative source Form 3-1/0033, "Application for Visa" (section 12 and 13 / Regulation 11)

Machine access

Schema document
registry/na/mhaiss/visa-application/1.0.0/schema.jsonapplication/schema+json
Verification record
registry/na/mhaiss/visa-application/1.0.0/VERIFICATION.mdtext/markdown
Registry catalog
registry/index.jsonone record per schema id

Field reference

90 fields across 12 steps, 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.

Applicant Particulars

  • surname string required

    Surname

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

    First Names

    length: 0–150classification: pii
  • maidenName string optional

    Applicable only if the applicant is or was a married woman, per the form's own printed qualifier.

    classification: pii

Eligibility Declarations (Items 4–10)

  • sex enum required

    Sex

    enum: MALE | FEMALEclassification: sensitive-pii
  • maritalStatus enum required

    Marital Status

    enum: NEVER_MARRIED | MARRIED | DIVORCED | WIDOW_WIDOWER
  • appliedForPermanentResidencePermit boolean required

    Have You at Any Time Applied for a Permit to Settle Permanently in Namibia?

  • everRestrictedOrRefusedEntry boolean required

    Have You Ever Been Restricted or Refused Entry into Namibia?

  • everDeportedOrOrderedToLeave boolean required

    Have You Ever Been Deported or Ordered to Leave Namibia?

  • everConvictedOfCrime boolean required

    Have You Ever Been Convicted of Any Crime in Any Country?

  • hasContagiousDiseaseOrMentalIllness boolean required

    Covers tuberculosis or any other contagious lung disease; trachoma or any other chronic eye infection; frambesia, yaws, scabies or any other contagious bacterial or other skin disease; syphilis or any other venereal disease; or leprosy or acquired immune deficiency syndrome virus (AIDS virus), or any mental illness or affliction, per the form's own printed list.

    classification: health

Birth and Citizenship

  • birthDate date required

    Birth: Date

    classification: sensitive-pii
  • birthPlace string required

    Birth: Place

  • birthCountry string required

    Birth: Country

  • citizenship string required

    If citizenship was acquired by naturalization, the form's own printed instruction is to state the applicant's original citizenship in this same answer.

    classification: pii

Passport Details

  • passportNumber string required

    Passport: Number

    classification: sensitive-pii
  • passportPlaceOfIssue string required

    Passport: Place of Issue

  • passportDateOfIssue date required

    Passport: Date of Issue

  • passportDateOfExpiry date required

    Passport: Date of Expiry

  • passportValidForTravelToNamibia boolean required

    Is Passport Valid for Travel to Namibia?

Address and Residence

  • presentResidentialAddress string required

    Present Residential Address

    classification: pii
  • presentTelephoneCode string optional

    Present Residential Address: Telephone Code

  • presentTelephoneNumber string optional

    Present Residential Address: Telephone Number

    classification: pii
  • permanentResidenceAddress string required

    Address in the country of which the applicant is a permanent resident (may differ from the present residential address above).

    classification: pii
  • permanentResidenceTelephoneCode string optional

    Country of Permanent Residence: Telephone Code

  • permanentResidenceTelephoneNumber string optional

    Country of Permanent Residence: Telephone Number

    classification: pii
  • permanentResidencePeriod string required

    Period of Residence in Country of Permanent Residence

Occupation and Employment

  • occupation string required

    Occupation or Profession

  • representedOrganizationName string optional

    Firm, Company, University, etc. to Which Attached or Represented

  • employerNameAddress string optional

    Name and Address of Employer

    classification: pii
  • employerTelephoneCode string optional

    Employer: Telephone Code

  • employerTelephoneNumber string optional

    Employer: Telephone Number

  • natureOfBusiness string optional

    Nature of Business

  • studentUniversityAndCourse string optional

    Applicable only if the applicant is a student, per the form's own printed qualifier.

Accompanying Wife and Children

  • accompanyingFamilyMember1FirstNames string optional

    Item 19's printed table has exactly 3 rows (a)-(c); flattened here to accompanyingFamilyMember1..3, per this registry's bounded-repeating-group convention. Not required: an applicant travelling alone leaves all rows blank. The form's own N.B. notes separate applications must be completed for a spouse or children over 16, and for children travelling with their own passports.

    classification: pii
  • accompanyingFamilyMember1DateOfBirth date optional

    Accompanying Wife/Child 1: Date of Birth

  • accompanyingFamilyMember1PlaceOfBirth string optional

    Accompanying Wife/Child 1: Place of Birth

  • accompanyingFamilyMember2FirstNames string optional

    Accompanying Wife/Child 2: First Names

    classification: pii
  • accompanyingFamilyMember2DateOfBirth date optional

    Accompanying Wife/Child 2: Date of Birth

  • accompanyingFamilyMember2PlaceOfBirth string optional

    Accompanying Wife/Child 2: Place of Birth

  • accompanyingFamilyMember3FirstNames string optional

    Accompanying Wife/Child 3: First Names

    classification: pii
  • accompanyingFamilyMember3DateOfBirth date optional

    Accompanying Wife/Child 3: Date of Birth

  • accompanyingFamilyMember3PlaceOfBirth string optional

    Accompanying Wife/Child 3: Place of Birth

Funds and Travel Arrangements

  • fundsAvailableNAD number required

    Funds Available on Arrival (N$)

    range: 0–∞
  • hasOnwardReturnTicket boolean required

    Will You Be in Possession of an Onward/Return Ticket?

Visa Category

  • visaCategory enum required

    The form's page 2 is explicitly split into two mutually exclusive parts by its own printed instruction: "NOTE: COMPLETE ONLY PART A OR B". Selects which of the two parts below applies; only that part's fields are applicable.

    enum: HOLIDAY_BUSINESS_WORK_TRANSIT | RETURN_VISA

(A) Holiday / Business / Work / Transit Visa

  • intendedArrivalDateAndPort string optional

    Printed as a single combined blank (date and port together), not two separate fields.

  • purposeOfVisit string optional

    Purpose of Visit

  • businessNatureDetail string optional

    Applicable only if the purpose of visit is for business, per the form's own printed qualifier.

  • durationOfIntendedVisit string optional

    Number of days, weeks, or months, per the form's own printed instruction.

  • placesToBeVisitedInNamibia string optional

    Full addresses, including telephone numbers, per the form's own printed instruction. Printed as a multi-line answer block, modelled here as a single field.

  • medicalDoctorHospitalClinicName string optional

    Applicable only if the purpose of visit is medical treatment, per the form's own printed qualifier.

  • medicalExpensesPayer string optional

    Medical Treatment: Who Will Pay Expenses and Fees

  • medicalFundsAvailable number optional

    Medical Treatment: Funds Available if Applicant Liable

    range: 0–∞
  • proposedResidentialAddressInNamibia string optional

    Proposed Residential Address in Namibia

    classification: pii
  • proposedResidentialTelNo string optional

    Proposed Residential Address in Namibia: Telephone Number

  • relativeInNamibia1Name string optional

    Item 6's printed table has exactly 2 rows (a)-(b); flattened here to relativeInNamibia1/2, per this registry's bounded-repeating-group convention.

    classification: pii
  • relativeInNamibia1AddressAndPhone string optional

    Relative in Namibia 1: Address and Telephone Number

  • relativeInNamibia1Relationship string optional

    Relative in Namibia 1: Relationship

  • relativeInNamibia2Name string optional

    Relative in Namibia 2: Name

    classification: pii
  • relativeInNamibia2AddressAndPhone string optional

    Relative in Namibia 2: Address and Telephone Number

  • relativeInNamibia2Relationship string optional

    Relative in Namibia 2: Relationship

  • dateOfLastVisitToNamibia date optional

    Date of Last Visit to Namibia, if Any

  • professionalContributionDetails string optional

    Applicable only if the applicant does contribute, per the form's own "if so" qualifier.

  • destinationAfterLeavingNamibia string optional

    Destination After Leaving Namibia

  • modeOfTravelToDestination string optional

    Mode of Travel to Destination

  • intendedDayAndPortOfDeparture string optional

    Intended Day and Port of Departure

  • destinationEntryAssuredDetails string optional

    E.g. whether the applicant holds a visa or a permit for permanent or temporary residence at the onward destination; proof is required to be submitted, per the form's own printed instruction. Printed as a single open answer line, not a Yes/No checkbox.

  • reasonsForTravellingThroughNamibia string optional

    Applicable to a transit visa; left optional since this Part also covers Holiday/Business/Work purposes for which this question does not apply.

(b) Return Visa

  • permitKindAndNumber string optional

    Kind of Permit and Number

  • returnVisaDateOfDeparture date optional

    Date of Departure

  • returnVisaExpectedDateOfReturn date optional

    Expected Date of Return

  • residenceInNamibia1DateOfFirstEntry date optional

    Item 2's printed table has exactly 3 blank rows; flattened here to residenceInNamibia1..3, per this registry's bounded-repeating-group convention.

  • residenceInNamibia1PortOfEntry string optional

    Residence in Namibia 1: Port of Entry

  • residenceInNamibia1PeriodFrom date optional

    Residence in Namibia 1: Period From

  • residenceInNamibia1PeriodTo date optional

    Residence in Namibia 1: Period To

  • residenceInNamibia2DateOfFirstEntry date optional

    Residence in Namibia 2: Date of First Entry

  • residenceInNamibia2PortOfEntry string optional

    Residence in Namibia 2: Port of Entry

  • residenceInNamibia2PeriodFrom date optional

    Residence in Namibia 2: Period From

  • residenceInNamibia2PeriodTo date optional

    Residence in Namibia 2: Period To

  • residenceInNamibia3DateOfFirstEntry date optional

    Residence in Namibia 3: Date of First Entry

  • residenceInNamibia3PortOfEntry string optional

    Residence in Namibia 3: Port of Entry

  • residenceInNamibia3PeriodFrom date optional

    Residence in Namibia 3: Period From

  • residenceInNamibia3PeriodTo date optional

    Residence in Namibia 3: Period To

  • countryToBeTraveledTo1 string optional

    Item 3's printed line has exactly 4 blanks (a)-(d); flattened here to countryToBeTraveledTo1..4, per this registry's bounded-repeating-group convention.

  • countryToBeTraveledTo2 string optional

    Country to Be Traveled To 2

  • countryToBeTraveledTo3 string optional

    Country to Be Traveled To 3

  • countryToBeTraveledTo4 string optional

    Country to Be Traveled To 4

  • purposeOfJourney string optional

    Explain fully, per the form's own printed instruction.

Declaration

  • declarationDate date required

    Date

  • applicantSignature string required

    The form's own printed note states only the signature of the applicant will be accepted.

    classification: pii

Verification record

Candidate selection

GOV-4516 ("GovSchema Standard Research"), delegated by GOV-4513 after that cycle re-scanned Namibia's two remaining backlog candidates (BIPA CC1 Business Formation, this MHAISS Visa form) and found both had gone stale since GOV-4488's original scouting pass. Namibia's Taxes vertical is already published as na/namra/return-of-income-individuals@1.0.0 (GOV-4491); this schema is the second Namibia vertical (Visa). A sibling cycle (GOV-4515) authors Namibia's Business Formation form (BIPA CC1) independently in a separate worktree/PR.

Reaching the live source

Fetched the friendly direct-download URL GOV-4513 re-resolved (the shorter view_file/{id} URL form is known from prior scouting to falsely report "document could not be found" for this exact form):

https://mha.gov.na/documents/292728/582288/Visas+Application.pdf/c6d9c9b7-49ba-b0e6-fb40-2b3213544664?t=1741771353038&download=true

  • Plain unauthenticated curl request, no session/cookie state, no CAPTCHA/WAF challenge.
  • HTTP 200, Content-Type: application/pdf, 82,771 bytes — an exact byte-for-byte match with the size GOV-4513 flagged before delegating.
  • PDF header %PDF-1.7\r\n at byte 0.
  • sha256 of the retrieved bytes: a48c2cf18ca0ca3b3398a677ea874f3c6720cf1100f603cb5a849af1b4a787d2.
  • 2 pages, confirmed via pdfjs-dist's numPages, matching the delegating issue's own page count.
  • getAnnotations() returned zero /Widget annotations on both pages — a flat, print-and-fill specimen, not an interactive AcroForm PDF.

Extraction method

pdfjs-dist (vendored at /tmp/node_modules/pdfjs-dist, installed fresh this cycle) getTextContent() read every text item's raw string and transform x/y position on both pages, grouped into printed rows by rounded y-coordinate (±2pt) and sorted by x-coordinate to reconstruct column order. The document is plain English with clean, non-rasterized embedded fonts — text extracted cleanly with no glyph-mapping/encoding failure of the kind this registry has hit on some non-English gov PDFs.

Both pages were additionally rendered to PNG via pdfjs-dist + node-canvas at 2.5x scale and visually inspected in full, to independently confirm every checkbox pair (Sex; Marital Status; each Yes/No question), grid/table row count, and the page-2 Part A/B layout that the text layer alone could not fully disambiguate — in particular:

  • Item 19's accompanying-wife-and-children table has exactly 3 rows (a)-(c), not more (initial scouting notes described this only as "a table," with no row count).
  • Part A, Item 6's relatives-in-Namibia table has exactly 2 rows (a)-(b).
  • Part B, Item 2's residence-particulars table has exactly 3 rows.
  • Part B, Item 3's countries-to-be-travelled line has exactly 4 blanks (a)-(d).
  • Item 13 (Citizenship) prints only one blank followed by a parenthetical instruction ("If acquired by naturalization, state original citizenship") — not a second blank for a separate "original citizenship" field. Confirmed visually; modelled as a single citizenship field with the instruction folded into its description, not a second field (an initial reading of the raw text-layer row, before the row was visually cross-checked, would have suggested two answers).
  • The "FOR OFFICIAL USE ONLY" box (Approved/Not Approved, Single/Multiple Entry, File No., Date of issue, Date of expiry, Remarks, Signature, Date) sits at the same page-1 y-coordinates as several applicant question rows (items 6-9), which the text-layer row-grouping briefly merged into a single logical row (e.g. item 8's question line and the office box's own "Date:" label extracted at the same y-coordinate). Visually confirmed via the rendered page image that this is a separate officer-only box, not an applicant-supplied date attached to item 8 — excluded from fields[] entirely, consistent with this registry's standing treatment of officer/office-only boxes.
  • Item 10's Yes/No checkboxes and every other page-1 Yes/No pair render as two clearly bounded, symmetric boxes (both options boxed) — no printed checkbox asymmetry of the kind disclosed in some other registry visa schemas (e.g. bw/dic/visa-application's Sex field).

Document structure

Page 1 — header (Republic of Namibia, Ministry of Home Affairs, Department of Civic Affairs, Immigration Control Act 1993, Form 3-1/0033), a "FOR OFFICIAL USE ONLY" box (excluded, officer-only), Items 1-3 (name particulars), Items 4-10 (checkbox/Yes-No eligibility declarations, with Item 10 the long tropical/communicable-disease and mental-illness question), Item 11 (an instruction to attach full particulars if items 6-9 were answered affirmatively — modelled as a conditional documents[] entry, not a field), Items 12-14 (birth, citizenship, passport), Items 15-16 (present address and country-of-permanent-residence address, each with phone sub-fields), Items 17-18 (occupation/employer), Item 19 (a 3-row accompanying-wife-and-children table), Item 20 (funds available, onward/return ticket).

Page 2 — headed "NOTE: COMPLETE ONLY PART A OR B", then:

  • (A) Holiday/Business/Work/Transit Visa — Items 1-10: arrival date/port, purpose of visit (with a business-nature sub-line), duration, places to be visited, medical-treatment sub-fields (doctor/hospital, payer, funds if liable), proposed residential address in Namibia, relatives-in-Namibia table (2 rows), date of last visit, professional- contribution question, destination-after-Namibia details (destination, mode of travel, departure day/port, whether entry is assured), and reasons for travelling through Namibia (the transit-specific question).
  • (b) Return Visa — an "IMPORTANT" instruction block (produce passport/travel document; submit proof of residence rights if not endorsed in passport — both modelled as conditional documents[] entries), then Items 1-4: kind of permit and number, departure/expected- return dates, a 3-row residence-in-Namibia particulars table, a 4-slot countries-to-be-travelled line, and purpose of journey.
  • A single Declaration (date + signature) at the very bottom of page 2, applicable regardless of which Part was completed.

Scope: the Part A/B discriminator

The source's own page-2 instruction — "NOTE: COMPLETE ONLY PART A OR B" — is a genuine mutually-exclusive choice between two differently-shaped blocks of fields, not two independently-optional sections. Modelled via a single required visaCategory enum field (HOLIDAY_BUSINESS_WORK_TRANSIT / RETURN_VISA), whose value gates every Part-specific field's visibleWhen (GSP-0013 §2), with requiredWhen additionally applied, using the identical condition, to the fields that are mandatory within whichever Part is selected (e.g. purposeOfVisit/durationOfIntendedVisit in Part A; permitKindAndNumber/purposeOfJourney in Part B). This follows this registry's established discriminator-field convention (e.g. zm/pacra/company-incorporation's isBodyCorporate boolean gating natural- person vs. body-corporate fields; ug/mowt/driving-licence-application's applicationType/licenceDuration in-operator cross-tab) rather than GSP-0013's boolean-only exclusivityGroups mechanism, which is scoped to pairs of boolean fields and does not fit a two-sided, many-fields-per-side choice like this one. exclusivityGroups was considered and rejected for this reason.

Not every Part-specific field is requiredWhen-gated: fields that are only conditionally applicable within their own Part (e.g. Part A's medical- treatment sub-fields, only relevant if the visit's purpose is medical treatment; Part A's relatives-in-Namibia table and Part B's residence/ countries tables, all bounded-repeating and optional even at row 1) are visibleWhen-gated on visaCategory only, left required: false bare — consistent with this registry's standing convention of not fabricating an unprinted conditional tie between an optional free-text/enum field and a second field it has no explicit checkbox link to.

Scope: fields excluded

  • The page-1 "FOR OFFICIAL USE ONLY" box in its entirety (Approved/Not Approved, Single/Multiple Entry, File No., Date of issue, Date of expiry, Remarks, Signature, Date) — officer-only, not applicant-supplied.
  • Item 11's "attach full particulars" instruction is not itself a field; modelled as a conditional documents[] entry (requiredWhen an any of the four items 6-9 booleans equalling true).
  • Part B's "IMPORTANT" produce-passport / submit-proof-of-residence-rights instructions are modelled as two conditional documents[] entries (identity-document and supporting-evidence respectively), not fields.

Scope: judgment calls on requiredness

This source has no asterisk/mandatory marking convention of its own (like several other registry sources), so requiredness was assigned by engineering judgment: core identity/eligibility/passport/present-address/ occupation/funds/declaration fields are required: true; secondary contact details (telephone numbers), employer/business sub-fields, the accompanying- family table, and every bounded-repeating-table row are required: false. Two disclosed judgment calls worth flagging explicitly:

  1. permanentResidenceAddress/permanentResidencePeriod (Item 16) modelled required, on the reasoning that every applicant has some country of permanent residence to state (which may be identical to or different from the present residential address in Item 15) — unlike the Item 15 present-address phone sub-fields, which are secondary contact details left optional.
  2. destinationEntryAssuredDetails (Part A, Item 9(d)) modelled as a free-text string, not a boolean. The source prints this as a single open answer line with no Yes/No checkbox pair (unlike every other yes/no question on this form, which prints two boxed options) — confirmed visually via the rendered page-2 image. Its associated "(proof to be submitted)" instruction is modelled as a plain-optional documents[] entry rather than requiredWhen-gated against this field, per this registry's documented notEquals-against-an-absent-optional- field bug class.

Conformance

2 valid mock scenarios (a Part A Holiday/Business/Work/Transit applicant; a Part B Return Visa applicant) plus 1 mutation-control fixture (Part A selected with its own purposeOfVisit omitted) were run through an ephemeral, from-scratch condition evaluator (deriving visibleWhen/ requiredWhen/required resolution directly from this schema's own fields[]/documents[], discarded after use, not committed): both valid scenarios resolved with zero missing required fields, and the mutation control correctly flagged exactly the one omitted field (purposeOfVisit) as missing. The fullParticularsOfAffirmativeReply document's any-condition and the passportOrTravelDocument/ proofOfResidenceRightsInNamibia documents' visaCategory-gated requiredWhen were each independently evaluated true/false against the expected inputs.

Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (ajv 2020-12 against spec/v0.3/govschema.schema.json). registry-index.json regenerated via npm run build-index in tools/govschema-client/.

Models 90 fields[] across 12 steps, plus 5 documents[] entries (2 unconditional-within-their-Part, 3 conditionally gated).

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 Ministry of Home Affairs, Immigration, Safety and Security or any government. The authoritative source is always the live government form and its official instructions.