Italy National Visa Application (D)

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-3032), opening Italy's Visa vertical (1 of 6). A prior scouting pass had flagged this form as a candidate but explicitly required a rigorous field-by-field reconciliation against the registry's existing EU-harmonized long-stay-visa siblings before authoring, "even if the answer here is not a duplicate" — per this registry's established precedent of overturning prior "duplicate"/dead-end findings only after an actual side-by-side content diff (see es/maec/solicitud-visado-nacional's own GOV-1861 reversal, and hr/mvep/zahtjev-za-dugotrajnu-vizu's own GOV-2902 reversal, both cited in the issue brief). This cycle performed that reconciliation from scratch (see below) and found this is not a duplicate — the form carries genuine, Italy-specific structural content none of the siblings carry, while omitting entire question categories (spouse, children, parents, criminal-conviction disclosure, notifiable disease) those siblings do carry. Authored as a new schema on that finding.

Sources examined

Source 1 (primary source, the form itself)

• Authority: Ministero degli Affari Esteri e della Cooperazione Internazionale (MAECI).
• Document: "National Visa Application (D)" / "Domanda di visto nazionale (D)", bilingual English/Italian.
• URL: https://www.esteri.it/mae/Servizi/Stranieri/Formulario_Visto_Nazionale_ING-ITA.pdf
• Fetched this cycle: curl -sL with a standard desktop browser User-Agent, unauthenticated, no login/CAPTCHA/WAF gate encountered.
• HTTP status: 200. Content-Type: application/pdf. Size: 283,335 bytes (independently confirmed via curl -D response headers and cross-checked with ls -la/wc -c).
• sha256 (independently computed this cycle with sha256sum, not trusted from the prior scouting pass that cited the same value): eba970bc7eebfde7ed96f61a428172017e31b8586e6dd5effafe35ec41aa4dee. This matches the prior scouting pass's claimed value exactly — both now independently agree, and this cycle did not simply repeat the claim without re-deriving it.
• Extraction method: pdfjs-dist@3.11.174, legacy/build/pdf.js (CommonJS require, this registry's established technique for this environment — no pdftotext/pdftoppm/pip available). doc.getFieldObjects() returned null and page.getAnnotations() returned zero Widget annotations on pages 1 and 2 (only 6 unrelated annotations — non-Widget — on page 3), confirming a static hand-fill/print template, not a fillable AcroForm PDF, the same class as hr/mvep/zahtjev-za-dugotrajnu-vizu. page.getTextContent() was used instead, reading every numbered item's printed text across all 3 pages, in full, independently of the prior scouting pass's own item list.
• What it confirms: the form's own 32 numbered items (1-32) and their exact bilingual labels, including the full 11-option purpose-of-journey checkbox grid (item 20), the two-sided travel-funding block (item 28), the "personal data of the family member who is an EU, EEA or CH citizen" block (item 29) and its own family-relationship taxonomy (item 30), the free-of-charge notice ("This application form is free" / "Modulo gratuito"), and page 3's closing declaration text citing Article 331 of the Code of Criminal Procedure and the Garante per la Protezione dei Dati Personali by name and address.
• Retrieved / reviewed: 2026-07-15.

Sources 2-5 (duplicate-detection comparison targets)

Each of the following was read in full (schema.json and VERIFICATION.md) this cycle before authoring:

• de/auswaertiges-amt/national-visa-application (Germany) — 81 fields across 16 labelled sections (identity, travel document, spouse, children, parents, previous stays in Germany, intended stay/accommodation type, permanent residence abroad, accompanying family, purpose of stay, references, profession, duration, means of subsistence/health insurance, criminal convictions, expulsion/refusal history, notifiable disease).
• bg/mvnr/zayavlenie-za-izdavane-na-natsionalna-viza-tip-d (Bulgaria) — spouse block, a 4-child repeating table (child1..child4, each with name/DOB-place/nationality/address), a guardian field, and a 3-entry previous-stays-in-Bulgaria repeating block.
• es/maec/solicitud-visado-nacional (Spain) — 60 fields, a 12-category residence-purpose taxonomy, and three purpose-conditional blocks (family-reunification sponsor, employer/company, educational establishment).
• hr/mvep/zahtjev-za-dugotrajnu-vizu (Croatia) — 50 fields, a two-step temporary-residence/visa construct (a pre-approval sub-block naming the approving police authority), an 11-category purpose-of-stay taxonomy (digital nomad, EEA long-term-resident stay, posted-worker employment), and a named family-reunification-sponsor sub-block.

fr/france-visas/schengen-visa-application's own travelCostsFundedBy/ applicantMeansOfSubsistence/sponsorMeansOfSubsistence fields were also read (not a long-stay-visa sibling, but the closest precedent in this registry for modelling the exact EU Annex-I-style two-sided funding block that reappears, in near-identical shape, as this form's own item 28 — see Judgment call 4 below).

Independent re-extraction detail

`` numPages: 3 getFieldObjects: null page 1: annotations=0 widgets=0 page 2: annotations=0 widgets=0 page 3: annotations=6 widgets=0 ``

Zero Widget annotations confirms this is a static print/hand-fill template (the same class as hr/mvep/zahtjev-za-dugotrajnu-vizu), not a fillable AcroForm. getTextContent() produced clean, ordered per-page text with no image-only/scanned-page fallback needed.

Field-by-field reconciliation (mandatory per this cycle's brief)

| Item # (this form) | Label | de/auswaertiges-amt | bg/mvnr | es/maec | hr/mvep | Verdict | |---|---|---|---|---|---|---| | 1-3 | Surname, surname at birth, first names | Same fields (Section 1) | Same fields | Same fields (items 1-3) | Same fields (rubrike 1-3) | IDENTICAL (shared Schengen-harmonized identity boilerplate) | | 4-6 | Date/place/country of birth | Same | Same | Same (items 4-6) | Same (rubrike 4-6) | IDENTICAL (shared boilerplate) | | 7 | Current nationality + at-birth-if-different | Same | Same (+ "other nationality"/"previous nationalities" split into 2 extra fields) | Same (item 7) | Same (rubrika 7) | IDENTICAL (shared boilerplate) | | 8 | Gender | Same | Same | Same (item 8) | Same (rubrika 8) | IDENTICAL | | 9 | Marital status (6 values: single/married/separated/divorced/widowed/other) | 5-value list, no separate "Separated" | 7-value list (adds "registered partnership") | 7-value list (adds "registered union") | 7-value list (adds "life partnership") | SIMILAR-BUT-DIFFERENT (this form is the only sibling with no registered-partnership/civil-union category) | | 10 | Minors: guardian details | No counterpart (DE's Section 2/3 model spouse/children, not a guardian-for-minors field) | Present (guardianDetails) | Present (guardianDetails, item 10) | Present (parentalRightsOrLegalRepresentativeDetails, rubrika 10) | IDENTICAL concept, shared boilerplate | | — | Spouse block (full name/DOB/nationality/residence) | Present, 9 fields (Section 2) | Present, 7 fields | Absent | Absent | IT-SPECIFIC-NO-EQUIVALENT — this form has no spouse section at all | | — | Children block (repeating) | Present (childrenCount/childrenDetails) | Present, 4-slot repeating table (child1..child4) | Absent | Absent | IT-SPECIFIC-NO-EQUIVALENT — no children section at all | | — | Parents (father/mother) block | Present, unconditional (Section 4) | Absent | Absent | Absent | (DE-only content; not relevant to IT's own distinguishing content, listed for completeness) | | — | Previous stays in the destination country | Present, up to 5 (Section 5) | Present, 3-entry repeating block | Absent | Absent | IT-SPECIFIC-NO-EQUIVALENT — no previous-stays block | | 11 | Type of travel document (5 categories + other) | Same shape | Same shape | Same shape (item 12) | Same shape (rubrika 12) | IDENTICAL (shared boilerplate) | | 12-15 | Travel document number/issue/valid-until/issued-by | Same | Same | Same (items 13-16) | Same (rubrike 13-16) | IDENTICAL (shared boilerplate) | | 16 | Address + email + phone (combined box) | Split into currentAddressStreet/currentAddressPostcodePlace/email/phone/mobilePhone | Split similarly | Combined into one box (item 17), same as this form | Split (rubrika 17: address+email combined, phone separate) | SIMILAR-BUT-DIFFERENT (whether address/email are one combined box or split varies by sibling; this form matches ES's combined-box treatment) | | 17 | Residence in a third country + permit sub-block | No counterpart (Germany's own form is the entry document itself) | Present (residesInCountryOtherThanNationality + permit fields) | Present (item 18) | Present (rubrika 18) | IDENTICAL concept, shared boilerplate | | 18-19 | Current occupation + employer/institute details | Present (Sections 10-11, split across "references" and "profession") | Present (currentProfession/employerOrSchoolDetails) | Present (item 19, currentOccupation only — no employer field) | Present (rubrike 19-20) | SIMILAR-BUT-DIFFERENT (ES has no employer-details field at all; this form does) | | — | Accommodation type (single room/apartment/collective) | Present (Section 6) | Absent | Absent | Absent | (DE-only content, listed for completeness) | | — | Permanent residence maintained abroad | Present (Section 7) | Absent | Absent | Absent | (DE-only content) | | — | Family members accompanying | Present (Section 8) | Present (familyMembersTravelingTogether/familyMembersDetails) | Absent | Absent | (not this form's own content) | | 20 | Purpose of journey, 11 categories: family reunification, religious reasons, sport, mission, diplomatic, medical reasons, study, adoption, salaried employment, self-employment, other | 6 categories (Employment/Study/Au pair/Language course/Family reunion/Other) — no Adoption/Mission/Diplomatic/Religious-reasons/Sport | Different, residence/work-permit-oriented set (residence w/o work, employment types, seasonal work) | 12 categories (residence w/o work, family reunification, employment types, investor/entrepreneur, study, internship, research, residence recovery, accreditation, other) — no Adoption/Mission/Diplomatic/Religious-reasons/Sport | 11 categories (family reunification, employment, secondary education, posted-worker, studying, EEA-long-term-resident, research, digital nomad, humanitarian, other, life partnership) — no Adoption/Mission/Diplomatic/Religious-reasons/Sport | IT-SPECIFIC-NO-EQUIVALENT — no sibling's taxonomy contains Adoption, Mission, Diplomatic, Religious-reasons, or Sport as a purpose category; this form's taxonomy is oriented around consular-service categories rather than any sibling's residence/work-permit framing | | 21 | Destination in Italy | Present as intendedStayStreet/intendedStayPostcodePlace (Section 6) | Present (intendedPlaceOfStayInBulgaria) | Present (addressInSpain, item 23) | Present (intendedAccommodationAddressInCroatia, rubrika 30) | IDENTICAL concept, shared boilerplate | | 22 | Schengen State of first entry (if applicable) | Absent | Absent | Absent | Absent | IT-SPECIFIC-NO-EQUIVALENT — no sibling asks this | | 23 | Number of entries requested (1/2/multiple) | Absent (Germany's national visa does not ask this on the paper form) | Absent | Present (item 22, same 3-value shape) | Present (numberOfEntriesRequested, rubrika 24, 2-value: single/multiple) | SIMILAR-BUT-DIFFERENT (shared with ES specifically, not DE/BG/HR as a group) | | 24 | Number of days of intended stay (max. 365), numeric | Absent (DE instead asks intendedDurationFrom/intendedDurationTo as a date range) | Absent (BG instead asks plannedStayFrom/plannedStayTo) | Absent (ES has no explicit day-count/duration field at all) | Absent (HR has no explicit day-count field either) | IT-SPECIFIC-NO-EQUIVALENT — this form is the only sibling with an explicit numeric day-count cap rather than a date range | | 25 | Intended date of arrival in Schengen area | Present, similar (intendedDurationFrom) | Present (plannedArrivalDate) | Present (intendedDateOfArrival, item 21) | Present (intendedArrivalDate, rubrika 25) | IDENTICAL concept, shared boilerplate | | 26 | Family-reunification/employer-in-Italy contact block (name, address in Italy for other purposes, address/email, phone/fax) | No direct counterpart in this combined shape (DE's Section 10 "references" is generic and optional, not purpose-gated) | No direct counterpart in this combined shape | Present in a different shape: a full named-sponsor sub-block with the sponsor's own DOB/nationality/travel-document number (item 26) | Present in a different shape: a full named-sponsor sub-block with the sponsor's own DOB/nationality/permit-type (rubrika 28) | SIMILAR-BUT-DIFFERENT — this form's own item 26 is a lighter-weight contact block (name/address/phone/fax only, no sponsor DOB/nationality/document-number fields), materially thinner than ES's/HR's own sponsor sub-blocks | | 27 | Host company/organization block (name/address, phone/fax, contact person) | No direct counterpart (DE's Section 10 references are generic, not company-specific) | No direct counterpart | No direct counterpart (ES's item 27 employer block is purpose-gated on employment categories, not framed as "host company/organization" generally) | No direct counterpart (HR's rubrika 29 employer/school field is purpose-agnostic but a single combined line, not a 3-field company block) | SIMILAR-BUT-DIFFERENT — closest in spirit to ES's item 27 employer block, but framed generally as "host Company/Organization" rather than gated to employment-purpose values only | | 28 | Two-sided travel-funding block: who pays (applicant/sponsor/other) + a distinct means-of-support checklist for each side | No counterpart at all (DE's own Section 13 "means of subsistence" is a single free-text-style field, not this two-sided applicant-vs-sponsor structure) | No counterpart | No counterpart in this combined shape (ES has no "who pays" + means-of-support checklist structure at all) | No counterpart | IT-SPECIFIC-NO-EQUIVALENT among the D-visa siblings — but this exact structure (who-pays enum + per-side means-of-support checklist) is the EU Regulation 810/2009 Annex I harmonized funding block already modelled for the Schengen (Type C) short-stay visa in fr/france-visas/schengen-visa-application's own travelCostsFundedBy/applicantMeansOfSubsistence/sponsorMeansOfSubsistence fields — disclosed honestly as shared Schengen-Annex boilerplate re-used inside a national D-visa form, not evidence this whole document duplicates fr/france-visas (see "Why this is not a duplicate of fr/france-visas" below) | | 29-30 | Personal data of the family member who is an EU, EEA or CH citizen + family-relationship taxonomy (spouse/son-daughter/other descendant/dependent ascendant/other) | Absent | Absent | Absent | Absent | IT-SPECIFIC-NO-EQUIVALENT — no sibling long-stay-visa template already modelled in this registry carries an EU/EEA/CH-free-movement-family-member block at all | | — | Criminal-conviction disclosure (Germany/abroad, when/where/reason/nature) | Present (Section 14) | Absent | Absent | Absent | (DE-only content; IT's own closing declaration instead cites Article 331 c.p.p. as a consequence of false statements, not a disclosure question — see "Article 331 c.p.p. clause" below) | | — | Notifiable-disease disclosure | Present (Section 16) | Absent | Absent | Absent | (DE-only content) | | — | Expelled/deported/refused-entry history | Present (Section 15) | Absent | Absent | Absent | (DE-only content) | | 31 | Place and date of signing | Present | Present | Present (item 30) | (no distinct field; HR's own signature line is part of its declaration block) | IDENTICAL concept, shared boilerplate | | — | Article 331 c.p.p. criminal-referral clause (false statements → prosecution under Italian criminal procedure law) | Absent | Absent | Absent | Absent | IT-SPECIFIC-NO-EQUIVALENT — no sibling's declaration text cites a criminal-procedure-code referral by article number | | — | Garante per la Protezione dei Dati Personali citation (Italy's data-protection supervisory authority, named with address/phone) | Absent | Absent | Absent | Absent | IT-SPECIFIC-NO-EQUIVALENT — no sibling's data-protection notice names a specific national supervisory authority by name/address/phone in this way |

Conclusion: NOT a duplicate. This form omits, in its entirety, four structural blocks that Germany's and/or Bulgaria's forms both carry (spouse, children, previous-stays, accommodation-type), omits three disclosure categories Germany's form alone carries (criminal convictions, notifiable disease, expulsion history), and adds five items/blocks with no counterpart on any of the four already-modelled long-stay-visa siblings: the Schengen-first-entry-state field (item 22), the numeric 365-day cap (item 24), the two-sided applicant/sponsor funding-and-means-of-support block (item 28), the EU/EEA/CH family-member data-and-relationship block (items 29-30), and the closing declaration's Article 331 c.p.p. criminal-referral clause plus its Garante per la Protezione dei Dati Personali citation. This is a genuinely distinct national form sharing only the expected Schengen-harmonized opening identity/travel-document boilerplate (items 1-16) with its siblings — the same kind of shared convergence this registry already treats as expected, not evidence of duplication (see the ES and HR precedents cited above).

Why this is not a duplicate of fr/france-visas/schengen-visa-application

Item 28's own two-sided funding structure (who pays + a distinct means-of-support checklist per side) is, on its own, the same EU Regulation 810/2009 Annex I harmonized block already modelled for France's Schengen (Type C) short-stay visa. That overlap is disclosed honestly above rather than ignored. But fr/france-visas models an entirely different type of visa (Schengen short-stay, Type C) with an entirely different overall field set (no purpose-of-journey taxonomy resembling this form's own 11 categories, no travel-document/marital-status opening block in the same shape, no minors'-guardian field, no EU/EEA/CH family-member block at all — that specific block does not exist on the Schengen form either). One shared sub-block embedded inside two otherwise-unrelated forms is the same kind of ordinary convergence already documented for Sections 1-16's shared identity boilerplate across every sibling in this table; it is not evidence that this document, taken as a whole, is a duplicate of fr/france-visas or of any other document in this registry.

Field inventory (Phase 3)

All 53 fields[] entries and their exact source item number are recorded inline in schema.json's own sourceRef per field. Summary by step:

| Step | Fields | Source items | Notes | |---|---|---|---| | applicant_identity | 11 | 1-9 | Shared Schengen-harmonized opening identity block | | minors_and_travel_document | 7 | 10-15 | guardianDetails (item 10) left ungated — see Judgment call 1 | | contact_and_residence | 8 | 16-19 | applicantAddressAndEmail combines address+email into one field, matching the source's own single combined box | | journey_details | 7 | 20-25 | purposeOfJourney, Italy's own 11-category consular-service taxonomy; numberOfDaysOfIntendedStay is a numeric cap (max 365), unique among siblings | | family_reunification_or_employer_contact | 4 | 26 | Gated via requiredWhen purposeOfJourney in [...], split by the item's own two printed conditions (family-reunification/employer vs. adoption/religious/medical/sport/study/mission) — see Judgment call 2 | | host_company_or_organization | 3 | 27 | Left ungated — see Judgment call 3 | | travel_funding | 5 | 28 | Two-sided funding block, following fr/france-visas's own comma-separated-string means-of-subsistence precedent — see Judgment call 4 | | eu_eea_ch_family_member | 7 | 29-30 | Left ungated — see Judgment call 5 | | signature | 1 | 31 | Physical signature itself (item 32) not modelled, per this registry's standing convention |

Total: 53 fields, 8 documents[] entries, 1 crossFieldValidation rule (23 fields unconditionally required: true; 16 further fields conditionally required via requiredWhen).

Access notes and judgment calls

1. guardianDetails (item 10) is left required: false with no gating condition. The form's own instruction ("In case of minors...") makes this conditional on the applicant being a minor, but no separate "is the applicant a minor?" field or checkbox exists on the form to gate on — the same non-fabrication treatment es/maec and hr/mvep both already apply to their own equivalent fields.
2. Item 26's four sub-fields are split into two requiredWhen gates matching the item's own two printed conditions. The item's first line ("Surname and name of the person in Italy who applied for Family Reunification, or ... the Employer in Italy") is gated on purposeOfJourney being family-reunification or one of the two employment values; the item's second line ("For Adoption, Religious Reasons, Medical Reasons, Sport, Study, Mission, please specify the address in Italy") is gated on the complementary purpose values the source itself lists by name. The address/email and phone/fax sub-fields are gated the same way as the first line, since they are printed as a continuation of the family-reunification/employer contact, not the address-in-Italy line.
3. Item 27 (host Company/Organization) is left entirely ungated. The form prints no explicit boolean or purpose condition distinct from item 26's own conditions for this item, so it is left unconditionally optional rather than fabricating a gate — the same treatment hr/mvep applies to its own employerOrEducationalEstablishmentInCroatia field.
4. Item 28's means-of-support checklists are modelled as comma-separated strings (applicantMeansOfSupport/sponsorMeansOfSupport), not as individual boolean fields with an exclusivityGroups entry. This follows fr/france-visas/schengen-visa-application's own precedent for the identical EU Annex-I-style funding block ("multi-select-as-string treatment, pending GSP-0009"), since a real applicant could plausibly select more than one means of support simultaneously (e.g. both cash and a credit card) — unlike the form's other checkbox groups (maritalStatus, travelDocumentType, purposeOfJourney, numberOfEntriesRequested, familyRelationToEuEeaChCitizen), each of which is genuinely a single mutually-exclusive choice and is modelled as a single enum, following es/maec's and hr/mvep's own established convention for that widget class.
5. The entire EU/EEA/CH family-member block (items 29-30) is left unconditionally optional with no gating field. The form prints no separate "are you a family member of an EU/EEA/CH citizen?" boolean distinct from filling in items 29-30 themselves — the same non-fabrication principle applied throughout this document and its siblings.
6. travelCostsCoveredBy (item 28's own "who pays" question) is gated via requiredWhen purposeOfJourney in [religious-reasons, sport, medical-reasons, study, other] — the complementary set to the form's own printed exclusion list ("THIS INFORMATION IS NOT NECESSARY FOR THE FOLLOWING TYPES OF VISA: Family Reunification, Following Family Member, Salaried Employment, Self Employment, Mission, Diplomatic, Adoption"). This is a disclosed logical inversion of the source's own stated negative condition into the in-operator grammar this registry's Condition type supports (no notIn operator exists in spec v0.3) — not a fabricated condition, since it is derived directly from the source's own explicit text.
7. documents[] derives from the page-1 "Spazio riservato all'Amministrazione" (For Office use only) column's own "Documenti giustificativi" (supporting documents) checklist. Of its six checkbox items (travel document; means of subsistence; invitation; means of transport; travel health insurance; other), three map to universal, unconditional entries this cycle judged confidently required for every application (travelDocumentCopy, subsistenceMeansProof, travelHealthInsuranceProof), and two (invitationProof, meansOfTransportProof) map to entries this cycle could not confirm a universal trigger for and so modelled as optional — the checklist itself does not state which purposeOfJourney value(s) make each mandatory, the same disclosed-scope treatment es/maec applies to its own comparable checklist-derived entries.
8. No fee/payment document is modelled. The form's own header states "This application form is free" / "Modulo gratuito" — no payment category applies.
9. Two attestation documents, not one, are modelled — a shorter fee-non-refundability acknowledgement printed at the bottom of page 2 (immediately above the first signature line) and the longer page-3 declaration (data-protection notice, Article 331 c.p.p. criminal-referral clause, and Garante per la Protezione dei Dati Personali citation, above the second signature line). The form itself prints two separate signature blocks with two distinct attestation texts, so they are kept as two separate documents[] entries rather than merged into one.
10. The page-1 "Spazio riservato all'Amministrazione" (For Office use only) column is excluded from fields[] entirely (application date, application number, receiving mission/service provider, case handler, the visa decision, validity dates, entries/days granted) — the same class of exclusion this registry applies elsewhere to internal-marker or office-use-only widgets (e.g. es/maec's and hr/mvep's own excluded "reserved for administration" columns). The "Documenti giustificativi" checklist within this same column, however, genuinely describes the supporting-document types the mission expects, so it is separately captured in documents[] (see Judgment call 7).
11. No edition axis. This is a standing national-visa application form, not a dated annual filing, consistent with this registry's convention for non-time-versioned application forms.
12. process.language is it. The modelled edition is the bilingual Italian/English specimen at the URL cited above; both languages are reproduced in every field's own label, the same bilingual-label treatment hr/mvep and bg/mvnr both already use for their own bilingual/dual-script source forms.

Test run (Phase 4)

No live submission was attempted: this is a request form against a real national visa-issuing authority, and submitting fabricated identity data into a real government system is not a safe or reversible action.

Instead, two hand-authored mock instances were built from this document's own field inventory and independently checked with a disposable, from-scratch Node.js checker (not committed, per this registry's own established practice of not committing one-off verification scripts) that reads schema.json's own required/requiredWhen/validation.enum/ validation.pattern/validation.minimum/validation.maximum/ crossFieldValidation grammar and evaluates it against each mock record — the same technique already used by hr/mvep's own conformance run.

• study-visa-single-applicant — an unmarried applicant filing under purposeOfJourney: "study", not resident in a third country, single entry, no EU/EEA/CH family-member block populated, with the addressInItalyForOtherPurposes field (gated on the study/adoption/ religious/medical/sport/mission purpose set) and the full travelCostsCoveredBy: "applicant" funding block populated (since study is one of the purposes for which item 28 is necessary per the form's own exclusion list). PASS.
• family-reunification-with-eu-family-member — a married applicant currently resident in a third country (exercising the full item-17 residence-permit sub-block), filing under purposeOfJourney: "family-reunification" with the full item-26 contact block populated, the EU/EEA/CH family-member block populated (familyRelationToEuEeaChCitizen: "spouse"), and travelCostsCoveredBy correctly left absent (family reunification is one of the purposes the form's own text marks as not requiring item 28). PASS.

Six negative controls (each expected to fail exactly one rule):

1. Removing surname (unconditionally required) — correctly flagged as a missing required field.
2. Setting sex to an out-of-enum value ("nonbinary") — correctly flagged as a validation.enum violation.
3. Setting numberOfDaysOfIntendedStay to 400 (exceeding the form's own 365-day cap) — correctly flagged as a validation.maximum violation.
4. Swapping travelDocumentDateOfIssue/travelDocumentValidUntil so the document is valid before it was issued — correctly flagged as a crossFieldValidation violation.
5. Setting maritalStatus: "other" without supplying otherMaritalStatusDetails — correctly flagged as a missing conditionally-required field.
6. Setting purposeOfJourney: "study" (one of the purposes for which item 28 is necessary) without supplying travelCostsCoveredBy — correctly flagged as a missing conditionally-required field.

All six negative controls were correctly rejected; no defects were found in the schema itself.

Both registry validators were run against the finished document and pass clean:

``` $ node tools/validate.mjs registry/it/maeci/domanda-di-visto-nazionale-d/1.0.0/schema.json ok registry/it/maeci/domanda-di-visto-nazionale-d/1.0.0/schema.json

1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/it/maeci/domanda-di-visto-nazionale-d/1.0.0/schema.json ok registry/it/maeci/domanda-di-visto-nazionale-d/1.0.0/schema.json [v0.3]

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

What is NOT modelled (out of scope), and why

• The page-1 "Spazio riservato all'Amministrazione" (For Office use only) column — office-use-only, not applicant-facing (see Judgment call 10).
• The physical signature itself (item 32) — per this registry's standing convention.
• Any purpose-specific supplementary annex or documentary checklist a specific Italian embassy/consulate may request in addition to this base form for a given purpose or nationality.
• The English-only mirror edition of this same form, if one exists at a different URL — this v1.0.0 models the bilingual Italian/English specimen at the URL cited above.

Scope and jurisdiction notes

This document opens Italy's Visa vertical (1 of 6). it/agenzia-entrate and it/mit already cover Taxes and DMV respectively; this document opens a third IT authority segment, it/maeci.

Re-verification

Per the practice's cadence, nextReviewBy is set to 2027-01-15 (6 months). A future review should prioritize: (1) confirming the source PDF's sha256 is unchanged (a changed hash would require re-diffing the printed item text before assuming no field-level change); (2) upgrading status from draft to verified once a second independent reviewer cross-checks this record against the live source.