Türkiye — Exceptional Acquisition of Turkish Citizenship Application Form (Vat-4)

Candidate selection

GOV-4839 ("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) and GOV-4832 authored VAT-6 (marriage-based acquisition), leaving VAT-1, VAT-2, VAT-4, VAT-5, VAT-7, VAT-8, VAT-10, and VAT-11 unscreened field-by-field. This cycle re-scanned the same NVI listing page fresh, fetched and field-counted all eight still-unauthored forms via pdfjs-dist's getAnnotations():

| Form | Widgets | Unique field names | |---|---|---| | VAT-1 | 87 | 79 | | VAT-2 | 72 | 68 | | VAT-4 | 96 | 92 | | VAT-5 | 97 | 93 | | VAT-7 | 51 | 50 | | VAT-8 | 94 | 90 | | VAT-10 | 62 | 61 | | VAT-11 | 108 | 100 |

VAT-4 — "Exceptional Acquisition of Turkish Citizenship" was selected as the strongest remaining candidate. This is the legal basis (Law No. 5901, Article 12) underlying Türkiye's widely known discretionary and citizenship-by-investment pathways (naturalization at the President's discretion for foreign nationals who make a qualifying real-estate or capital investment, provide notable service, or meet other Article-12 criteria) — of the eight remaining candidates it carries the highest real-world search volume and applicability for AI agents assisting foreign investors and their counsel, and is structurally close to the already-modelled Vat-3 (a genuine four-way marital-status/spouse requiredWhen gate, a 3-column minor-children table), letting this cycle reuse an already-proven pattern with high confidence rather than introducing a new structural family. VAT-11 has more raw widgets but is narrowly scoped to a specific bilateral pathway (TRNC citizens acquiring Turkish citizenship); VAT-5 (re-acquisition) and VAT-8 (acquisition by right of option) were runners-up but address narrower populations than the investment/discretionary pathway.

Reaching the live source

• Form Vat-4: https://www.nvi.gov.tr/kurumlar/nvi.gov.tr/mevzuat/nufusmevzuat/Formlar/Vatandaslik/Vat4_Istisnai_Olarak_Kazanma.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: 847001 bytes (matches the downloaded file exactly), sha256 ec84952a815bd114b381b77cc9de73e4db3a8962c21cb1b0d62a3ee3e3576acf, Last-Modified: Tue, 04 Aug 2020 08:33:32 GMT, no login/CAPTCHA gate. Retrieved 2026-07-25.
• Field structure extracted with pdfjs-dist's getAnnotations() (96 AcroForm widgets across 2 pages — all 96 on page 1, page 2 is the supporting-documents checklist with no form fields). Because several widgets in the minor-children table carry generic or miscopied alternativeText tooltips (e.g. Cinsiyet_3/Cinsiyet_4/Cinsiyet_5 and Din_3/Din_4/Din_5 all tooltip as "Eğitim Durumu", the same miscopy pattern already found on Vat-9's own children table), every field was independently resolved by extracting the raw text layer's item-level (x, y) positions via getTextContent() and matching each widget's rect to the printed row label directly above/beside it — a faster, equally rigorous alternative to node-canvas rendering for a form whose text layer is intact and unscrambled. This confirmed the children table's true row order top-to-bottom: Varsa Yabancı Kimlik No → Uyruğu → Yabancı Adı → Yabancı Soyadı → Türkçe Adı → Alacağı Soyadı (surname to be acquired — not "Türkçe Soyadı") → Anne Adı → Baba Adı → Doğum Yeri → Doğum Tarihi (Gün/Ay/Yıl) → Cinsiyeti → Dini, i.e. Vat-3's own 12-row children-table convention, not Vat-6's 11-row variant (Vat-6 has no Alacağı Soyadı row).
• Legal basis: Law No. 5901 on Turkish Citizenship (Türk Vatandaşlığı Kanunu), Article 12 — the form's own closing declaration cites this article by number ("5901 sayılı Türk Vatandaşlığı Kanununun 12'nci maddesine göre Türk vatandaşlığını istisnai olarak kazanmak istiyorum").

Findings / disclosed scoping calls

1. All 96 widgets reconcile cleanly to 71 logical fields[] + 1 excluded widget. 95 non-excluded widgets − 24 widgets folded into composite fields = 71 fields[]. The folding is entirely accounted for: dateOfBirth (3→1, applicant), sex (2→1, radio pair), phoneNumber (2→1), emailAddress (2→1), maritalStatus (4→1, 4-way radio), marriageDate (3→1), divorceDate (3→1), spouseDeathDate (3→1), spouseDateOfBirth (3→1), child{1,2,3}DateOfBirth (3→1 each, ×3), declarationDate (3→1) — 24 widgets saved across these 13 composites. The single excluded widget is Başvuran Ad (the closing printed-name/signature line), matching every sibling schema's own convention.
2. The applicant's foreign/Turkish-script name split (Ad_0/Soyad_0 → foreignFirstName/foreignLastName, Ad_1/Soyad_1 → turkishFirstName/turkishLastName) was confirmed via the text-layer position match: the printed labels read, top to bottom, "Yabancı Adı / Yabancı Soyadı" directly above "Türkçe Adı / Türkçe Soyadı", aligning exactly with the Ad_0/Soyad_0 row sitting above the Ad_1/Soyad_1 row — the same reuse-of-ambiguous-suffix pattern already documented on Vat-6.
3. A genuine four-way maritalStatus with a requiredWhen-gated spouse block, reusing Vat-3's exact pattern verbatim rather than Vat-6's/Vat-9's single-scenario (always-a-spouse / never-a-spouse) treatment: single/married/divorced/widowed (source: Secim_3, a 4-value radio group, per the form's own footnote a/b/c). Evlenme Tarihi (marriage date) is required whenever married, divorced, or widowed; Boşanma Tarihi (divorce date) only when divorced; Vefat Eden Eşin Ölüm Tarihi (spouse's death date) only when widowed. The entire 8-field Eşe Ait Bilgiler (spouse information) block is likewise requiredWhen gated on maritalStatus being one of the three non-single values.
4. No maiden-name question on this form — unlike Vat-3/Vat-6/Vat-9, Vat-4's applicant-information block has no "Bekârlık Soyadı" (maiden surname) field or corresponding checkbox anywhere in the text layer or widget dump; not modelled, since the form itself does not ask for it.
5. No occupation/education fields in the spouse block — the Eşe Ait Bilgiler section on this form has exactly 8 rows: Kimlik No, Uyruğu, Adı, Soyadı, Anne Adı, Baba adı, Doğum Yeri, Doğum Tarihi; there is no Mesleği/Eğitim Durumu row for the spouse, unlike Vat-3's spouse block (which does carry spouseOccupation/spouseEducationLevel). Confirmed by the absence of any corresponding widget or text label between the spouse block's Doğum Tarihi row and the minor-children table header.
6. spouseIdentityNumber accepts either a T.C. Kimlik No or a foreign Yabancı Kimlik No (widget tooltip: "T.C. Kimlik No/Yabancı Kimlik No yazınız..."), unlike Vat-6 (whose spouse is always a Turkish citizen by the form's own premise) — modelled with a length-only validation (minLength/maxLength, no pattern), matching Vat-3's identical spouseIdentityNumber treatment for the same reason (an Article-12 exceptional-acquisition applicant's spouse need not be a Turkish citizen).
7. The 3-column minor-children table has 12 fields per child, matching Vat-3's own convention (not Vat-6's 11-field variant), since this form's table does carry the Alacağı Soyadı (surname to be acquired) row — confirmed directly from the text-layer position match described above.
8. 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.
9. phoneNumber and emailAddress each collapse a visually-split pair of input boxes into one field, matching every sibling schema's own precedent.
10. religion, educationLevel, and occupation are left optional for the applicant (no explicit required marker on the form for these three, matching every sibling schema's treatment of the identical fields).
11. Out of scope: the header's office-completed intake fields, the biometric-photograph box, and the closing Ad Soyad/İmza (printed name/signature) line — the same Başvuran Ad widget every sibling schema excludes for its own equivalent line. declarationDate (the date accompanying the signature) is kept in scope as applicant-provided data, distinct from the signature mark itself.
12. Disclosure: this schema models only the government's own published intake-form fields. It does not itself define, evaluate, or guarantee eligibility for any citizenship-by-investment or discretionary-acquisition pathway under Article 12 — those criteria are set by separate regulation and administrative decision, outside this form's own scope.
13. This closes one of the eight remaining GOV-4818-banked VAT candidates. VAT-1, VAT-2, 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 fourth schema within that already-open vertical, not a new vertical or jurisdiction.

Conformance

3 valid mock scenarios — valid-single-applicant-minimal (the 21 unconditionally-required fields only, maritalStatus: single, no spouse/children fields), valid-married-applicant-with-spouse-consulate (filed with a Consulate General abroad, maritalStatus: married, full spouse block, no children), and valid-widowed-applicant-with-three-children (filed domestically, maritalStatus: widowed with both marriageDate and spouseDeathDate populated, full spouse block, all 3 children columns fully filled) — plus 21 static-required-field mutation fixtures (one per unconditionally required field), 11 requiredWhen mutation fixtures (marriageDate, divorceDate, spouseDeathDate, and all 8 requiredWhen-gated spouse-block fields, each covering its own triggering maritalStatus value), and 1 unknown-field-rejected fixture — 36 fixtures total, committed under conformance/tr/nvi/exceptional-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 36 fixtures: every valid scenario at 0 missing-field errors, every mutation fixture raising exactly the one error it targets (including the divorced/widowed branches, each independently exercised), and the unknown-field fixture's extra key correctly flagged — 36/36 passing. Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (669/669 documents, both individually and as part of the full registry run). registry-index.json regenerated via npm run build-index in tools/govschema-client/.