Türkiye — Reacquisition of Turkish Citizenship Application Form (Vat-5)

Candidate selection

GOV-4846 ("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 authored VAT-9 (renunciation), GOV-4832 authored VAT-6 (marriage-based acquisition), and GOV-4839 authored VAT-4 (exceptional/discretionary acquisition), leaving VAT-1, VAT-2, 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 (curl against the live page, href values scraped directly from the returned HTML) and re-fetched and field-counted all seven still-unauthored forms via pdfjs-dist's getAnnotations():

| Form | Widgets (AcroForm) | |---|---| | VAT-1 | 87 | | VAT-2 | 72 | | VAT-5 | 97 | | VAT-7 | 51 | | VAT-8 | 94 | | VAT-10 | 62 | | VAT-11 | 108 |

VAT-5 — "Reacquisition of Turkish Citizenship" was selected as the strongest remaining candidate. Of the seven remaining forms, reacquisition (Article 22) is the pathway with the highest real-world applicability for AI agents assisting the large Turkish diaspora: it is the route used by former Turkish citizens who renounced citizenship in order to naturalize elsewhere — historically very common for Turkish nationals in Germany and other EU states that long required renouncing an existing nationality to naturalize — and later seek to regain Turkish citizenship. VAT-11 (108 widgets) has more raw fields but addresses a narrow bilateral population (TRNC citizens); VAT-8 (acquisition by right of option, Article 8) and VAT-1 (post-majority birth-abroad declaration) are comparatively niche. VAT-5 is also structurally close to the already-modelled Vat-3/Vat-4 (a genuine four-way marital-status/spouse requiredWhen gate, a 3-column minor-children table with an Alacağı Soyadı row), letting this cycle reuse an already-proven pattern with high confidence.

Reaching the live source

• Form Vat-5: https://www.nvi.gov.tr/kurumlar/nvi.gov.tr/mevzuat/nufusmevzuat/Formlar/Vatandaslik/Vat5-FormYenidenTurkVatKaz.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: 1162702 bytes (matches the downloaded file exactly), sha256 2f0a1fc3f390059e9e0b4846bb67356544df74fc43d882b7f0af62509930b6c6, 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() (97 AcroForm widgets, all on a single page). Because a number of widgets carry generic or miscopied alternativeText tooltips — every Cinsiyet_3/Cinsiyet_4/Cinsiyet_5 and Din_3/Din_4/Din_5 widget in the minor-children table tooltips as "Eğitim Durumu", the same miscopy pattern already found on Vat-4's and Vat-9's own children tables — 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, rather than trusting alternativeText alone.
• A genuine field-naming quirk unique to this form's minor-children table, confirmed by the position match: the widget named TCKN_3 (and _4/_5) actually holds the foreign identity number (its own alternativeText reads "99 ile başlayan Yabancı Kimlik No yazınız...", and it sits directly under the printed "Varsa Yabancı Kimlik No (99… ile başlayan)" column header), while the widget named YKN_3 (and _4/_5) holds the T.C. identity number (alternativeText: "T.C. Kimlik No yazınız...", sitting under the "T.C. Kimlik No" header) — the exact opposite of what the field names themselves would suggest. This is unlike the applicant's own TCKN_1 widget, which correctly holds the applicant's own T.C. Kimlik No. Resolved entirely from the alternativeText + row-position match, not the field name.
• Legal basis: Law No. 5901 on Turkish Citizenship (Türk Vatandaşlığı Kanunu), Article 22 — the form's own closing declaration cites this article by number ("5901 sayılı Türk Vatandaşlığı Kanununa göre yeniden Türk vatandaşlığını kazanmak istiyorum").

Findings / disclosed scoping calls

1. All 97 widgets reconcile cleanly to 72 logical fields[] + 1 excluded widget. 97 total widgets − 1 excluded Başvuran Ad = 96 non-excluded widgets; 96 − 24 widgets-saved = 72. The folding: dateOfBirth (3→1, applicant), sex (2→1, radio pair), phoneNumber (2→1, area code + number), 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 own T.C. Kimlik No is required, not optional, unlike Vat-3/Vat-4 (whose foreign-national applicant has no pre-existing Turkish identity number). This reflects the form's own premise: an applicant reacquiring citizenship under Article 22 previously held one. Modelled as identityNumber with the same 11-digit T.C. Kimlik No pattern as the renunciation-side Vat-9's own identityNumber.
3. The applicant's foreign name fields (foreignFirstName/ foreignLastName, source Ad_0/Soyad_0) are optional, not required — the printed labels read "Varsa Yabancı Adı" / "Varsa Yabancı Soyadı" ("foreign name/surname, if any"), an explicit conditional phrasing not present on Vat-3/Vat-4's equivalent labels (plain "Yabancı Adı"/"Yabancı Soyadı"), confirmed via the text-layer position match. turkishFirstName/turkishLastName remain required, as on every sibling.
4. A genuine four-way maritalStatus with a requiredWhen-gated spouse block, reusing Vat-3's/Vat-4's exact pattern verbatim: 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.
5. 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..."), matching Vat-3's/Vat-4's identical spouseIdentityNumber treatment — modelled with a length-only validation (no pattern), since a reacquiring applicant's spouse need not be a Turkish citizen.
6. The 3-column minor-children table carries both a T.C. Kimlik No and a foreign (99…) identity number per child — child{N}IdentityNumber and child{N}ForeignIdentityNumber are both modelled, unlike the acquisition-side Vat-3/Vat-4 (whose children have never held Turkish citizenship and so carry only a foreign identity number). This is the direct structural consequence of the form's own reacquisition premise: a child here may have previously held a T.C. Kimlik No alongside the applicant before both lost citizenship. Neither child field is marked required on the source form (both are conditioned on a child actually being declared in that column), matching every sibling schema's treatment of its own optional per-child identity fields.
7. The children table carries the Alacağı Soyadı (surname to be acquired) row, matching Vat-3's/Vat-4's 15-field-per-child convention (not Vat-6's/Vat-9's simpler variant) — confirmed directly from the text-layer position match: Yabancı Adı → Yabancı Soyadı → Türkçe Adı → Alacağı Soyadı → Anne Adı → Baba Adı → Doğum Yeri → Doğum Tarihi (Gün/Ay/Yıl) → Cinsiyeti → Dini, printed top to bottom.
8. child{N}Sex is modelled as the same male/female enum used throughout every sibling schema, even though the underlying Cinsiyet_3/_4/_5 widgets are plain text fields (fieldType: Tx) rather than a radio-button pair like the applicant's own Cinsiyet widgets — the printed column header ("Cinsiyeti") and every sibling schema's own established convention both point to the same restricted value set, so the enum is kept for cross-schema consistency (disclosed here since it is a scoping choice, not a literal transcription of the widget's own field type).
9. No criminal-history question pair on this form — unlike Vat-4 (Article 12, exceptional acquisition), Vat-5's text layer and widget dump contain no "mahkûm"/"yargılama" (convicted/prosecution) language anywhere; not modelled, since the form itself does not ask for it.
10. phoneNumber and emailAddress each collapse a visually-split pair of input boxes into one field, matching every sibling schema's own precedent.
11. 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).
12. 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.
13. This closes one of the seven remaining GOV-4818-banked VAT candidates. VAT-1, VAT-2, 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 fifth schema within that already-open vertical, not a new vertical or jurisdiction.

Conformance

3 valid mock scenarios — valid-single-applicant-minimal (the 17 unconditionally-required fields only, maritalStatus: single, no spouse/children fields, filed with a Consulate General abroad), 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 17 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 — divorced and widowed each independently constructed from the married/widowed base scenarios), and 1 unknown-field-rejected fixture — 32 fixtures total, committed under conformance/tr/nvi/reacquisition-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 32 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 — 32/32 passing. Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (670/670 documents, both individually and as part of the full registry run). registry-index.json regenerated via npm run build-index in tools/govschema-client/.