Jordan — Visa Application to Enter the Hashemite Kingdom of Jordan

This file is the source-review record for this document version, per the manual-source-review-v1 practice.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-13
• maturity.level: structural-reference

This is GovSchema Standard Research cycle GOV-2746. This schema closes Jordan's Visa vertical (3 of 6), following GOV-2731 (Taxes, opened Jordan as the registry's 49th jurisdiction) and GOV-2739 (Passport, which also confirmed Business Formation, DMV, and National ID & Civic Documents as dead ends, and left this MFA Visa candidate open as well-sourced backlog after finding a competing 23-field embassy AcroForm only on third-party visa-expediting mirrors, not a first-party government host).

Source verification (independently re-derived, not copied from the task briefing)

• PDF source: https://www.mfa.gov.jo/documents/300419Jordan%20Visa%20Application%20.pdf — fetched independently this cycle via curl with a browser-like User-Agent/Accept header (a bare HEAD request against this host can 403; a plain GET succeeded cleanly):
  • HTTP 200, Content-Type: application/pdf, 419,769 bytes — matching the task briefing's expected size exactly.
  • sha256: 665961cc2d7746b6fdb8fa43e9c4153704f18fcb01e995c332223c37bfc7cc71 (computed via sha256sum on the freshly-downloaded file).
  • Last-Modified: Tue, 30 Apr 2019 06:41:00 GMT. Served via Cloudflare (server: cloudflare, a cf-ray header present, a benign __cf_bm cookie set) but with no JS-challenge/WAF block on this direct GET.
  • Domain mfa.gov.jo (Ministry of Foreign Affairs and Expatriates) is the correct, official first-party agency for Jordanian visa policy.

PDF structure, independently confirmed via pdfjs-dist

• 2 pages, a plain print-and-fill specimen. Two independent checks confirmed zero Widget-subtype annotations on either page: This is a genuine non-AcroForm specimen, consistent with both existing Jordan schemas (jo/istd/pit-return-employee, jo/cspd/passport-application).
  1. pdfjs-dist@4 (legacy ESM build): page.getAnnotations({intent: "display"}) returned 0 annotations on page 1, 1 non-Widget annotation on page 2 (a link/goto annotation, not a form field).
  2. pdfjs-dist@3 (legacy CJS build, used for the image render below): confirmed the same 0-Widget count on both pages independently.
• getTextContent() returned a full, clean, bilingual (English/Arabic) text layer on both pages. Every text item's (x, y) transform was grouped by rounded y-coordinate into rows and sorted by x to reconstruct the source's own line breaks and column layout — the full per-page, per-row transcript (with x-coordinates retained) was read in full before modeling any field.
• Page-image cross-check. pdfjs-dist@4's Node canvas-factory path threw TypeError: Image or Canvas expected when rendering this specimen's embedded photo-placeholder box and coat-of-arms image via a custom NodeCanvasFactory (a different failure mode from the blank-glyph gotcha noted in jo/cspd/passport-application's own record, but the same underlying category — a genuinely-imaged PDF needing special handling). Switching to pdfjs-dist@3's legacy CJS build (pdfjs-dist/legacy/build/pdf.js) with standardFontDataUrl pointed at its bundled standard_fonts/ directory rendered both pages cleanly via node-canvas, with no custom canvas factory needed. Both rendered pages were visually inspected and confirmed:
  1. Sex, Marital status, Type of Passport, and Number of Entries are all printed as genuine checkbox controls (☐), matching the task briefing's field list and justifying the enum typing used for these four fields (unlike this specimen's other Y/N-style questions in §6, which print no checkbox glyph at all — see below).
  2. A boxed, consular-only "For Official Use" sidebar runs the full height of page 1's right margin, containing a submitted-documents checklist (passport, residency card, invitation letter, official memo, medical report, Jordan Pass, bank statement, salary statement, employment/student/retirement proof, hotel booking, travel ticket, residence proof, spouse's passport, professional license), the receiving officer's name, the application receipt date, the amount paid, and the decision (grant single/double/multiple-entry visa, or refuse) with a notes line. This is genuinely staff/consular-only content and is excluded from fields[], consistent with this registry's established convention for office-use-only sections (e.g. jo/istd/pit-return-employee's "For Official Use" block, jo/cspd/passport-application's page-2 "For Department Use Only").
  3. §6's Y/N questions (6.1, 6.3, 6.5, 6.6, 6.7) print no checkbox glyph — only the question text followed on the next line(s) by "If yes, ..." detail-collection lines. This is disclosed as the basis for modeling each as a boolean field (the underlying answer is genuinely binary, and every question must be answered per the form's own "incomplete applications will not be processed" instruction) with an unrelated, optional detail companion field — rather than as free text.
  4. §5.6 (travel companions) and §6.8 (countries visited) are each printed as multiple blank ruled lines (3 lines and 2 lines respectively) rather than a numbered per-entry table — confirming these are single free-text fields, not bounded repeating groups like this registry's entrantN/childN precedent.
  5. §5.7 is a single shared blank box captioned with two alternative instructions — "Full address/telephone number of inviting person/ Organisation in Jordan" and, immediately below it, "*If tourist, Name of hotel, place of stay and telephone number" — confirming this is one field, not two.

Field derivation

The form's structure, reconstructed by row (bilingual, verified via getTextContent() positions and cross-checked against both page renders):

Page 1 — header (title "Visa Application to Enter the Hashemite Kingdom of Jordan"; an Applicant Photo placeholder box; an "Incomplete applications will not be processed..." instruction banner; the "For Official Use" sidebar, excluded — see above); §1 Personal Details (First name; Father's & grandfather's name; Family name; Current nationality; Mother's name; Sex; Date of Birth; Place of Birth; Marital status; Education; Name of spouse; Spouse's nationality); §2 Passport Details (Type Of Passport; Passport number; Date of issue; Date of expiry; Issuing authority); §3 Contact Details (Applicant's full address; Applicant's telephone number; Applicant's email address); §4 Employment (Current occupation; Name and full address of the employing Organisation; an asterisked "If Student..." companion line).

Page 2 — §5 Trip Information (Main purpose of visit; Number of Entries; Port of entry; Date of arrival; Date of departure; travel companion name(s); the combined inviting-person/hotel box); §6 Additional Information (other nationality + companion lines; Former Nationalities + companion lines; name-change + companion line; Date of first entry into country of residence; criminal conviction/trial + companion line; armed forces service + companion line; expulsion + companion line; countries visited in the last 10 years); the certification statement ("I hereby certify that the above information given is true and correct") and a combined "Name and Signature/ Date" declaration line.

Every printed applicant-facing field was mapped to one of this schema's 48 fields[] entries or its 1 documents[] entry. See the schema's own sourceRef on each field for the exact page/section/label it was read from.

Scoping and modeling judgment calls

• currentNationality, education, spouseNationality, typeOfPassportOtherSpecify modeled as free text: each is printed as a blank line with no options text, consistent with this registry's established precedent for unprinted-option fields (e.g. jo/istd/pit-return-employee's familyStatus).
• sex, maritalStatus, typeOfPassport, numberOfEntries modeled as enum: all four are printed as genuine checkbox controls with a fixed, closed option set — confirmed via the page-image render, not assumed from the text transcript alone.
• nameOfSpouse/spouseNationality modeled fully optional, no gate: the specimen prints no explicit yes/no gate ahead of this block (only married applicants would populate it) — disclosed here rather than inventing a requiredWhen gate the source doesn't have, matching the same judgment call jo/cspd/passport-application made for its own Husband/Wife Data block.
• studentSchoolNameAndAddress modeled optional, no gate: the specimen prints an asterisked companion line ("* If Student...") with no accompanying yes/no control.
• §6's boolean gate questions (hasOtherNationality, hasChangedName, hasCriminalConvictionOrTrial, hasServedInArmedForces, hasBeenExpelled) modeled as required boolean fields, each with optional, ungated "if yes" detail companion field(s): although these print no checkbox glyph (unlike sex/maritalStatus/typeOfPassport/ numberOfEntries), each is a plain-language yes/no question the form's own "incomplete applications will not be processed" instruction requires every applicant to answer, so each is modeled required: true. Per this task's explicit modeling guidance, the "if yes" companion detail fields (e.g. otherNationalityPassportName, criminalConvictionDetails) are modeled as plain optional fields with no requiredWhen coupling to the boolean, even though the source's own "If yes, provide details" phrasing could arguably support a requiredWhen gate (as this registry's gh/gra DT0103 precedent does for its own explicitly-gated sections) — disclosed here as a deliberate simplification, not an oversight.
• §6.2 "Former Nationalities" modeled with no accompanying boolean: unlike 6.1/6.3/6.5/6.6/6.7, this sub-section is printed as a plain heading ("Former Nationalities") rather than an explicit "Have you ...?"/"Do you...?" question, so no hasFormerNationality-style field was invented — only its two "if yes" companion fields (formerNationalityName, formerNationalityPassportNumber), both optional.
• travelCompanionNames and countriesVisitedLast10Years modeled as single free-text fields, not bounded repeating groups: confirmed via the page-image render that both are printed as multiple blank ruled lines (3 and 2 respectively), not a numbered per-entry table — unlike this registry's entrantN/childN precedent for genuinely tabular fixed-capacity sections.
• invitingPersonOrHotelDetails modeled as one required field covering two alternative instructions: the source prints "Full address/ telephone number of inviting person/Organisation in Jordan" and, on the line immediately below, "*If tourist, Name of hotel, place of stay and telephone number" sharing one blank writable box — confirmed via the page-image render rather than assumed from the text transcript alone (which could have been misread as two stacked fields).
• employerNameAndAddress scoped to the English caption only: the form's English label reads "Name and full address of the employing Organisation," while the adjacent Arabic column's own phrasing additionally mentions a telephone number; disclosed in the field's own description rather than silently expanding the English-language field's scope.
• declarantNameAndSignature/declarationDate split from one printed caption: the source's own closing line reads "Name and Signature/ Date" as a single caption; split into two typed fields (string + date) per this registry's established precedent for combined name-and-signature-plus-date declaration lines (e.g. jo/istd/pit-return-employee's taxpayerOrAgentNameAndSignature + taxpayerDeclarationDate).
• "For Official Use" sidebar excluded: consistent with this registry's established precedent for office/consular-use-only sections (see PDF structure section above).
• Classification: name pieces, address, phone, email, date/place of birth, spouse's name, travel-companion names, and the declarant's own name-and-signature are tagged pii; passport numbers (own, other- nationality, former-nationality) are tagged sensitive-pii, matching this registry's established precedent (e.g. jo/istd/pit-return-employee's nationalIdOrPassport); criminal-conviction/trial details and expulsion details are also tagged sensitive-pii given their legal/criminal nature, a judgment call made this cycle rather than a copied precedent. Plain enumerated/free-text demographic fields (sex, maritalStatus, currentNationality, spouseNationality) are left unclassified, consistent with jo/istd/pit-return-employee's own unclassified nationality/residency enum fields.

Conformance run

Two hand-authored valid fixtures under conformance/jo/mfa/visa-application/1.0.0/:

• valid-tourist-single-entry.json — a single, unmarried tourist applicant with a single-entry visa request, no other/former nationality, no name change, no criminal/military/expulsion history — exercising the schema's minimal required-field path (the hotel branch of invitingPersonOrHotelDetails).
• valid-business-multiple-entry-with-optional-blocks.json — a married business-trip applicant requesting multiple entries, exercising the optional spouse fields, an "Other" passport type with its "specify" companion, a travel companion, and all of §6's optional "if yes" companion blocks (other nationality, former nationality, name change, armed forces service).

Six mutation-control fixtures, each isolated to raise exactly one error:

• mutation-control-missing-passport-number.json — drops passportNumber (static required: true) from the tourist valid fixture.
• mutation-control-missing-date-of-birth.json — drops dateOfBirth (static required: true).
• mutation-control-missing-declaration-date.json — drops declarationDate (static required: true).
• mutation-control-invalid-enum-sex.json — sets sex to "other", not one of the enum's 2 values.
• mutation-control-invalid-enum-marital-status.json — sets maritalStatus to "engaged", not one of the enum's 4 values.
• mutation-control-invalid-type-has-other-nationality.json — sets hasOtherNationality to the string "no" instead of a JSON boolean.

All eight fixtures were checked with a from-scratch Node conformance checker (check-conformance.mjs, not committed — a disposable script, per this registry's own established practice) implementing this schema's own required/requiredWhen/type/validation.enum/validation.pattern grammar directly:

`` $ node check-conformance.mjs schema.json conformance/jo/mfa/visa-application/1.0.0 PASS mutation-control-invalid-enum-marital-status.json: expected 1 error(s), got 1 -> invalid enum value for maritalStatus: engaged PASS mutation-control-invalid-enum-sex.json: expected 1 error(s), got 1 -> invalid enum value for sex: other PASS mutation-control-invalid-type-has-other-nationality.json: expected 1 error(s), got 1 -> invalid type for hasOtherNationality: expected boolean, got string PASS mutation-control-missing-date-of-birth.json: expected 1 error(s), got 1 -> missing required field: dateOfBirth PASS mutation-control-missing-declaration-date.json: expected 1 error(s), got 1 -> missing required field: declarationDate PASS mutation-control-missing-passport-number.json: expected 1 error(s), got 1 -> missing required field: passportNumber PASS valid-business-multiple-entry-with-optional-blocks.json: expected 0 error(s), got 0 PASS valid-tourist-single-entry.json: expected 0 error(s), got 0 ``

All six negative controls raised exactly one error each, and neither valid scenario raised an unexpected error.

The registry's zero-dependency structural validator and its ajv-based meta-schema validator were both run against the schema document and pass:

``` $ node tools/validate.mjs registry/jo/mfa/visa-application/1.0.0/schema.json ok registry/jo/mfa/visa-application/1.0.0/schema.json

1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/jo/mfa/visa-application/1.0.0/schema.json ok registry/jo/mfa/visa-application/1.0.0/schema.json [v0.3]

1/1 document(s) validated against the meta-schema (ajv 2020-12). ```

tools/node_modules and tools/govschema-client/node_modules were both missing at the start of this cycle; both were restored via npm ci --include=dev run separately inside each directory (not npm install <pkg> --no-save, which has previously wiped ajv/ajv-formats devDependencies in this repo). The scratch pdfjs-dist/canvas installs used for PDF extraction and rendering were both done in isolated /tmp scratch directories, never inside tools/ or tools/govschema-client/.

tools/govschema-client/registry-index.json was regenerated via npm run build-index inside tools/govschema-client/ (412 → 413 entries).

Scope and jurisdiction notes

• Closes Jordan's Visa vertical (3 of 6). Business Formation, DMV, and National ID & Civic Documents were confirmed dead ends in the prior jo/cspd/passport-application (GOV-2739) cycle; combined with this schema and the existing Taxes/Passport schemas, all 6 of Jordan's verticals are now either built or confirmed dead ends — Jordan has reached its practical maximum coverage under this registry's current sourcing standards unless a dead-end vertical's underlying blocker (login-gated e-service, in-person/biometric-only process) changes.
• jurisdiction.level is national — MFA is Jordan's national foreign- affairs and visa-policy authority.
• process.type is application, matching this registry's established convention for visa forms (e.g. gr/mfa/application-for-schengen-visa, th/mfa/non-immigrant-visa-b-application-for-employment).
• process.language is en: although the specimen's own text layer is bilingual (English/Arabic), this schema's field labels/descriptions follow the English column throughout, consistent with this registry's existing Jordan schemas (both of which also declare en despite their own bilingual or Ministry-of-Finance-Arabic-adjacent source specimens).

Re-verification

Per the practice's cadence, nextReviewBy is set to 2027-01-13 (6 months). A future review should prioritize: (1) confirming whether the previously-scouted third-party-hosted 23-field embassy AcroForm ("Visa Application for US & EU countries") has since appeared on a first-party Jordanian government host, which could warrant a companion or successor schema; (2) re-attempting Jordan's Business Formation, DMV, and National ID & Civic Documents verticals if a bot-mitigation-workaround technique or a newly published paper form is found; (3) confirming whether an official Arabic-primary edition of this form differs in structure from the bilingual specimen used here.