Türkiye — Marriage-Based Acquisition of Turkish Citizenship Application Form (Vat-6)

Candidate selection

GOV-4832 ("GovSchema Standard Research"). The GOV-4818 cycle opened Türkiye as the registry's 100th jurisdiction via Form Vat-3 (general acquisition of citizenship), confirming all five other verticals as dead ends and banking the remaining VAT-1/2/4-11 forms on nvi.gov.tr/vatandaslik-ile-ilgili-formlar as future National ID & Civic Documents companion-schema candidates. GOV-4825 subsequently authored VAT-9 (renunciation). This cycle re-scanned that same page fresh, fetched and field-counted all nine still-unauthored forms (VAT-1, VAT-2, VAT-4, VAT-5, VAT-6, VAT-7, VAT-8, VAT-10, VAT-11) via pdfjs-dist's getAnnotations(), and selected VAT-6 — "Acquisition of Turkish Citizenship Through Marriage" — as the strongest remaining candidate: a single-page, 86-widget AcroForm covering one of the most common real-world citizenship pathways (a foreign national married to a Turkish citizen), structurally distinct from both already-authored siblings (VAT-3's marital-status-gated spouse block vs. this form's always-present spouse section; VAT-9's renunciation direction vs. this form's acquisition direction).

Reaching the live source

• Form Vat-6: https://www.nvi.gov.tr/kurumlar/nvi.gov.tr/mevzuat/nufusmevzuat/Formlar/Vatandaslik/Vat6_Evlenme.pdf — confirmed live directly from NVI's own current nvi.gov.tr/vatandaslik-ile-ilgili-formlar listing page (href scraped fresh this cycle), HTTP 200, Content-Type: application/pdf, Content-Length: 1340678 bytes (matches the downloaded file exactly), sha256 e62a7748c75bef9c6f4c07258147c0e05bf93d80e7f6d501692823bc8e50797c, Last-Modified: Tue, 04 Aug 2020 08:33:50 GMT, no login/CAPTCHA gate. Retrieved 2026-07-25.
• Field structure extracted with pdfjs-dist's getAnnotations() (86 AcroForm widgets on a single page, 85 unique field names — the Cinsiyet radio-button pair shares one field name across its two widgets). Every widget's rect was additionally rendered at scale 2.2 via node-canvas and visually cross-checked against the printed table headers, since the source reuses ambiguous numeric suffixes across distinct sections (e.g. Ad_1/Soyad_1 for the applicant's foreign name vs. Ad_11/Soyad_11 for the same applicant's Turkish-script name; Ad_3/Ad_33 for a child's foreign vs. Turkish-script given name) — every field was resolved to the label its rendered position sits directly beneath, not inferred from suffix pattern alone.
• Legal basis: Law No. 5901 on Turkish Citizenship (Türk Vatandaşlığı Kanunu), Article 16 — the form's own closing declaration cites this article by number ("5901 sayılı Türk Vatandaşlığı Kanununun 16'ncı maddesine göre evlenme yoluyla Türk vatandaşlığını kazanmak istiyorum").

Findings / disclosed scoping calls

1. Every one of the 86 widgets reconciles cleanly to 68 logical fields[] — the reduction is entirely accounted for by composite day/month/year boxes collapsing to a single date field (dateOfBirth, marriageDate, spouseDateOfBirth, child{1,2,3}DateOfBirth, declarationDate — 6 dates × 3 widgets each = 18 widgets → 6 fields), the applicant's own split area-code/subscriber phone boxes and split local-part/domain email boxes each collapsing to one field (4 widgets → 2 fields), and the Cinsiyet radio pair collapsing to one sex field (2 widgets → 1 field). Verified programmatically: 29 applicant-block widgets → 24 fields, 14 spouse-block widgets → 10 fields, 39 children-table widgets (13 × 3) → 33 fields, 3 declaration-date widgets → 1 field, plus the excluded 1-widget signature line — 86 widgets in, 68 fields[] + 1 excluded widget out.
2. A dedicated, always-required Turkish-citizen-spouse block (spouseIdentityNumber through spouseEducationLevel), unlike Vat-3's conditionally-requiredWhen-gated spouse fields — this form's very premise is marriage to a Turkish citizen, so the source carries no marital-status branching at all; the spouse section is unconditionally present on the form (TÜRK VATANDAŞI EŞE AİT BİLGİLER — "Information About the Turkish Citizen Spouse"). spouseIdentityNumber uses the genuine 11-digit T.C. Kimlik No pattern (^[1-9][0-9]{10}$), the same pattern Vat-9's identityNumber uses for its own already-a-citizen applicant.
3. submittedToOffice/submittedToOfficeType split, following Vat-9's precedent rather than Vat-3's single submittedToGovernorate — Vat-6's own salutation-line dropdown widget (Makam) offers the same two mutually exclusive destinations, VALİLİĞİNE (Governorship, domestic) and BAŞKONSOLOSLUĞUNA (Consulate General, abroad), reflecting that a foreign spouse may be filing from outside Türkiye.
4. useMaidenNameWithMarriedSurname/maidenName reuses Vat-3's exact pair (a boolean checkbox gating a requiredWhen-conditional maiden- surname text field) — Vat-6 poses the identical question ("Evlilik Soyadı ile birlikte Bekârlık Soyadı kullanılacak mı?") with the same single-checkbox-beside-a-text-box layout.
5. The 3-column minor-children table has 11 fields per child, one fewer than Vat-3's 12 — Vat-6's table provides only a single Türkçe Adı (Turkish-script given name) row and has no separate Alacağı Soyadı ("surname to be acquired") row that Vat-3's own children table carries; confirmed both from the visual render (the printed row labels stop at Türkçe Adı before Anne Adı) and from the annotation dump (no Soyad_33/Soyad_44/Soyad_55 widgets exist, only Ad_33/Ad_44/Ad_55). Modelled as the same bounded-slot child1/child2/child3 precedent (all fields optional, per the same reasoning as Vat-3 and Vat-9).
6. The Turkish spouse's own block has no Uyruğu (nationality) row — confirmed by both the visual render and the absence of a Uyruk_2 widget in the annotation dump, consistent with the spouse being a Turkish citizen by definition on this form.
7. hasPriorCriminalConviction/hasPendingProsecution reuse Vat-3's exact enum fields and labels verbatim — the same "Evet-Hayır" (Yes/No) question pair appears in the same position on this form.
8. phoneNumber and emailAddress each collapse a visually-split pair of input boxes into one field, matching Vat-3's and Vat-9's own precedent — the source prints a parenthetical area-code box before the phone number and splits the email box around a fixed, non-editable "@" glyph.
9. educationLevel, occupation, and religion are left optional for the applicant (no explicit required marker on the form for these three, matching Vat-3's and Vat-9's treatment of the identical fields), while the equivalent spouseOccupation/spouseEducationLevel are likewise left optional. All other applicant- and spouse-block fields are required: true, since the form itself provides no required/optional marker convention anywhere (same disclosed judgment call as both sibling schemas) and these particular fields are the ones Vat-3/Vat-9 already established as non-essential biographic detail.
10. Out of scope: the header's office-completed Kayıt Tarihi/ Kayıt No (registration date/number), the biometric-photograph box, and the closing Ad Soyad/İmza (printed name/signature) line — the same widget (Başvuran Ad) that both Vat-3 and Vat-9 exclude for their own equivalent line. declarationDate (the date accompanying the signature) is kept in scope as applicant-provided data, distinct from the signature mark itself.
11. This closes one of the nine remaining GOV-4818-banked VAT candidates. VAT-1, VAT-2, VAT-4, VAT-5, VAT-7, VAT-8, VAT-10, and VAT-11 remain open, unscreened backlog candidates on the same NVI page for a future companion-schema cycle. Türkiye remains 1 of 6 verticals open (National ID & Civic Documents) — this is a third schema within that already-open vertical, not a new vertical or jurisdiction.

Conformance

2 valid mock scenarios — valid-minimal-no-children-governorate (the 29 unconditionally-required fields only, no children, filed domestically with a Governorate, maiden name not used) and valid-consulate-general-with-three-children (filed with a Consulate General abroad, maiden name in use, every optional field populated, all 3 children columns fully filled) — plus 29 static-required-field mutation fixtures (one per required field), 1 requiredWhen mutation (maidenName omitted while useMaidenNameWithMarriedSurname is true), and 1 unknown-field-rejected fixture — 33 fixtures total, committed under conformance/tr/nvi/marriage-based-acquisition-of-turkish-citizenship-application/1.0.0/.

An ephemeral, from-scratch conformance checker (deriving required-field and requiredWhen rules directly from this schema's own fields[], discarded after use, not committed) ran all 33 fixtures: both valid scenarios at 0 missing-field errors, every mutation fixture raising exactly the one error it targets, and the unknown-field fixture's extra key correctly flagged — 33/33 passing. Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (668/668 documents, both individually and as part of the full registry run). registry-index.json regenerated via npm run build-index in tools/govschema-client/.