Türkiye — Acquisition of Turkish Citizenship by Place of Birth Application Form (Vat-2)

Candidate selection

GOV-4875 ("GovSchema Standard Research"). Nine prior cycles (GOV-4818/ Vat-3, GOV-4825/Vat-9, GOV-4832/Vat-6, GOV-4839/Vat-4, GOV-4846/Vat-5, GOV-4853/Vat-11, GOV-4860/Vat-8, GOV-4868/Vat-1) each authored the strongest remaining banked VAT companion candidate on NVI's vatandaslik-ile-ilgili-formlar page. This cycle re-scanned that same listing page fresh, re-fetched all three still-unauthored forms (VAT-2, VAT-7, VAT-10), and field-counted each via pdfjs-dist's getAnnotations():

| Form | Title | Pages | Widgets | |------|-------|-------|---------| | Vat-2 | Doğum Yeri Esasına Göre Kazanma (acquisition by place of birth) | 1 | 72 | | Vat-10 | Seçme Hakkı İle Kaybetme (loss by right of option) | 1 | 62 | | Vat-7 | Evlat Edinilme Yoluyla Kazanma (acquisition by adoption) | 1 | 51 |

Vat-2 was selected as the strongest remaining candidate: the largest widget count of the three, a genuinely distinct legal basis (acquisition through place of birth on Turkish soil — not adoption, and not a loss form like Vat-10, which runs the opposite direction to every other VAT companion authored to date), and a structure closely mirroring the already-authored Vat-1 (descent) schema's two-full-parent-block pattern, letting this cycle reuse that precedent directly while still capturing a form-specific finding of its own (see Finding 3 below).

Reaching the live source

• Form Vat-2: https://www.nvi.gov.tr/kurumlar/nvi.gov.tr/mevzuat/nufusmevzuat/Formlar/Vatandaslik/Vat2-FormDogumYeriEsasinaGoreTurkVatKaz.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, 708,415 bytes, sha256 879955ad8ca02d19114bcd3846a34f077d76043c5d52b7f900c8b36630a4a591. Retrieved 2026-07-25.
• Field structure extracted with pdfjs-dist's getAnnotations() (72 AcroForm widgets, single page) and cross-checked against the extracted text layer (getTextContent(), with explicit x/y transform coordinates pulled per text run) to resolve every widget's rect position to the label it sits directly beneath.

Findings / disclosed scoping calls

1. 72 widgets reconcile to 49 logical fields[]. 8 composite day/month/year groups collapse to 1 date field each (dateOfBirth, marriageDate, divorceDate, spouseDeathDate, spouseDateOfBirth, fatherDateOfBirth, motherDateOfBirth, declarationDate — 8 groups × 3 widgets = 24 widgets → 8 fields), the Cinsiyet radio pair collapses to 1 sex field (2 → 1), the Secim_3 4-way radio group collapses to 1 maritalStatus field (4 → 1), the split phone (Alan kodu + Telefon) and split email (Eposta + Eposta_2) boxes each collapse to 1 field (4 widgets → 2 fields), and the closing Başvuran Ad (printed name/signature) widget is excluded entirely (1 widget out). Reconciliation: 72 − 16 (date collapses) − 1 (sex radio) − 3 (marital-status radio) − 1 (phone) − 1 (email) − 1 (signature, excluded) = 49.
2. Two full parent-information blocks, matching the Vat-1 precedent: "BABASINA AİT BİLGİLER" (father's information) and "ANNESİNE AİT BİLGİLER" (mother's information), each carrying identity number, nationality, given name, surname, the parent's own mother's/father's name (modelled as paternalGrandmotherName/paternalGrandfatherName and maternalGrandmotherName/maternalGrandfatherName, to avoid colliding with the applicant's own top-level motherName/ fatherName fields), place of birth, and date of birth. Both parent blocks are modelled fully optional, not requiredWhen- gated — the source form provides no boolean/enum toggle indicating which parent's status is load-bearing, and (unlike Vat-1's "anne ve/veya baba" framing) this form's Article 8 place-of-birth basis does not even require either parent to be a Turkish citizen — the same disclosed "no structured control to gate an at-least-one-of-N requirement on" pattern used on Vat-1 and elsewhere in this registry.
3. Genuine source-document finding: each parent block's closing Yerleşim Yeri Adresi (residential address) widget carries the wrong internal field name/alternativeText. The extracted text layer confirms both parent blocks end with a printed "Yerleşim Yeri Adresi" label (two side-by-side columns, x≈42/x≈304, y≈79–100) directly above the education/occupation row. The corresponding AcroForm widgets at that same rect (fill_30 at x:[101,297] y:[79,100], fill_31 at x:[363,566] y:[79,100]) both carry alternativeText: "Eğitim Durumu" (education level) — evidently copy-pasted from the applicant's own fill_27/fill_28 education-level fields higher on the page, rather than updated for this position. Position (cross-checked against the text layer's own transform coordinates), not the widget's own internal name/ alternativeText, was used to model these two widgets as fatherResidenceAddress/motherResidenceAddress — both disclosed in the schema's own field description, following this registry's established practice of naming source-document field-labeling bugs rather than propagating them (cf. the TCKN/YKN swap on Vat-5, the TCKN_1 mismatch on Vat-8). These two address fields do not appear on Vat-1, whose equivalent parent blocks end one row earlier (at date of birth) with no address capture at all — a genuine structural difference between the two forms, not a modelling inconsistency.
4. No foreign-script/Turkish-script name split for the applicant — like Vat-1/8/9/11 and unlike Vat-3/4/5/6, Vat-2's own applicant block provides only a single Ad_1/Soyad_1 pair (confirmed by both the annotation dump and the rendered text, "Adı ... Soyadı" with no "Yabancı"/"Türkçe" qualifier). Modelled as plain firstName/ lastName.
5. No maiden-name question, no criminal-conviction/pending-prosecution questions, and no page-2 "Gerekli Diğer Bilgiler" declaration block — Vat-2 is a single page (unlike the two-page Vat-1), and its text layer confirms none of these three question groups appear anywhere on it.
6. Spouse block is the smaller 8-field pattern (no Mesleği/ Eğitim Durumu columns), matching the Vat-1/Vat-8 precedent; spouseIdentityNumber's own alternativeText ("T.C. Kimlik No/Yabancı Kimlik No yazınız...") confirms it accepts either a T.C. Kimlik No or a foreign identity number, since the applicant's spouse need not be a Turkish citizen — modelled with only minLength/maxLength, no strict digit pattern, matching the Vat-1/Vat-8 identical finding.
7. educationLevel, occupation, and religion are left optional for the applicant (no explicit required marker on the form for these three), matching every prior VAT companion schema's treatment of the identical fields.
8. Out of scope: the closing Başvuran Ad (printed name/signature) widget and the biometric-photograph box, consistent with every prior VAT companion schema's exclusion of its own equivalent closing artifacts.
9. This closes one of the three remaining GOV-4868-banked VAT candidates. VAT-7 and VAT-10 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 ninth schema within that already-open vertical, not a new vertical or jurisdiction.

Conformance

3 valid mock scenarios — valid-married-father-based-consulate (married applicant, filed with a Consulate General abroad, spouse block and both parent blocks, including their residence-address fields, fully populated), valid-single-domestic-no-spouse (single applicant, filed domestically with a Governorate, no spouse block, both parent blocks populated), and valid-widowed-mother-only-parent-block (widowed applicant with a deceased spouse, only the mother's parent-information block populated, father's block left entirely blank to exercise the "fully optional, either/neither parent block" judgment call) — plus 17 static-required-field mutation fixtures, 6 requiredWhen mutation fixtures (4 gated on marital status ∈ {married, divorced, widowed}, 1 gated on divorced via a locally-derived divorced variant, 1 gated on widowed), and 1 unknown-field-rejected fixture — 27 fixtures total, committed under conformance/tr/nvi/acquisition-of-turkish-citizenship-by-place-of-birth-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 27 fixtures: all 3 valid scenarios at 0 missing-field/pattern errors, every mutation fixture raising exactly the one error it targets, and the unknown-field fixture's extra key correctly flagged — 27/27 passing. Every foreignIdentityNumber value across all fixtures was asserted programmatically to match the schema's own ^99[0-9]{9}$ pattern (11 characters total) before being written to disk, per the standing guard against the 11-vs-12-digit fixture bug found during GOV-4862's review of a prior VAT sibling. Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (674/674 documents, both individually and as part of the full registry run). registry-index.json regenerated via npm run build-index in tools/govschema-client/.