Türkiye — Acquisition of Turkish Citizenship by TRNC Citizens Application Form (Vat-11)

Candidate selection

GOV-4853 ("GovSchema Standard Research"). Since GOV-4818 opened Türkiye as the registry's 100th jurisdiction via Form Vat-3 (general acquisition), five prior cycles (GOV-4825/Vat-9, GOV-4832/Vat-6, GOV-4839/Vat-4, GOV-4846/Vat-5) 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 six still- unauthored forms (VAT-1, VAT-2, VAT-7, VAT-8, VAT-10, VAT-11), and field-counted each via pdfjs-dist's getAnnotations():

| Form | Title | Pages | Widgets | |------|-------|-------|---------| | Vat-1 | 18 Yaşını Tamamladıktan Sonra Yurtdışından Doğuma İlişkin Başvuru/Beyan Formu | 2 | 87 | | Vat-2 | Doğum Yeri Esasına Göre Kazanma (jus soli) | 1 | 72 | | Vat-7 | Evlat Edinilme Yoluyla Kazanma (adoption) | 1 | 51 | | Vat-8 | Seçme Hakkı İle Kazanma (acquisition by right of option) | 1 | 94 | | Vat-10 | Seçme Hakkı İle Kaybetme (loss by right of option) | 1 | 62 | | Vat-11 | KKTC Vatandaşlarının Türk Vatandaşlığını Kazanma (acquisition by TRNC citizens) | 2 | 108 |

Vat-11 was selected as the strongest remaining candidate: the largest widget count of the six, a genuinely distinct legal basis (Article 42 of Law No. 5901, a dedicated pathway for citizens of the Turkish Republic of Northern Cyprus reflecting Türkiye's unique bilateral relationship with the TRNC — not marriage, not investment/exceptional acquisition, not reacquisition, not renunciation), and a second page of open-ended declarations (dual/other-state citizenship, statelessness, foreign residence history, Turkish-citizen relatives) that none of the five already-authored VAT companion schemas carry.

Reaching the live source

• Form Vat-11: https://www.nvi.gov.tr/kurumlar/nvi.gov.tr/mevzuat/nufusmevzuat/Formlar/Vatandaslik/Vat11-FormKKTCVatTurkVatKaz.pdf — confirmed live directly from NVI's own current nvi.gov.tr/vatandaslik-ile-ilgili-formlar listing page (fetched fresh this cycle), HTTP 200, Content-Type: application/pdf, Content-Length: 1170672 bytes (matches the downloaded file exactly), sha256 8f6402d03fd29c8f50089d7ef4ee911978454b8cee4158e1458aad7b3986e9c0, Last-Modified: Tue, 04 Aug 2020 08:33:58 GMT, no login/CAPTCHA gate. Retrieved 2026-07-25.
• Field structure extracted with pdfjs-dist's getAnnotations() (108 AcroForm widgets across 2 pages) and cross-checked against each page's extracted text layer (getTextContent()) to resolve every widget's rect position to the label it sits directly beneath.
• Legal basis: Law No. 5901 on Turkish Citizenship (Türk Vatandaşlığı Kanunu), Article 42 — the form's own closing declaration cites this article by number ("K.K.T.C. vatandaşı olup 5901 sayılı Türk Vatandaşlığı Kanununun 42'nci maddesine göre Türk vatandaşlığını kazanmak istiyorum," i.e. "Being a TRNC citizen, I wish to acquire Turkish citizenship under Article 42 of Law No. 5901"). Note: the form's own page-1 section header directly above the applicant block reads "ANNE VE/VEYA BABAYA BAĞLI OLARAK TÜRK VATANDAŞLIĞINI KAZANMAK İSTEYEN KİŞİYE AİT BİLGİLER" ("Information about the person seeking to acquire Turkish citizenship dependent on mother and/or father") — likely reused template boilerplate from a different VAT form, since it contradicts the form's own title and closing declaration (both citing the TRNC-citizen/Article-42 basis, with no mother/father-descent question anywhere on the form). Not modelled as a field; noted here as a disclosed source-document inconsistency, not a GovSchema authoring error.

Findings / disclosed scoping calls

1. 108 widgets reconcile to 74 logical fields[]. Page 1 (92 widgets): 13 composite day/month/year groups collapse to 1 date field each (dateOfBirth, marriageDate, divorceDate, spouseDeathDate, spouseDateOfBirth, child{1,2,3}DateOfBirth, declarationDate — 9 groups × 3 widgets = 27 widgets → 9 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) — 92 widgets → 67 fields. Page 2 (16 widgets): 7 free-text declaration widgets (fill_1, fill_2_2, fill_3_2, fill_4, fill_5, fill_6, fill_7_2) map 1:1 to 7 fields; the remaining 9 widgets (Beyan Ad ×2, Beyan Unvan, B_Gün ×2, B_Ay ×2, B_Yıl ×2 — the receiving-official's and re-declarant's signature blocks) are excluded entirely, per finding 6 below. 67 + 7 = 74 fields[] total.
2. Genuine field-name collision found and disclosed: the source PDF's Beyan Ad, B_Gün, B_Ay, and B_Yıl field names are each reused verbatim across two different widgets on page 2 — one under the left-column "Beyan Alan Yetkilinin" (the receiving official's name/ date) heading, the other under the right-column "Beyan Verenin" (the declarant's own name/date) heading, at the same y-coordinate but different x-coordinates. Per standard PDF AcroForm semantics, widgets sharing a fully-qualified field name mirror the same value — meaning in the live, fillable PDF, typing into either the official's or the declarant's name/date box silently overwrites the other. This is very likely an authoring oversight in NVI's own source PDF (the two roles are logically distinct people), not an intentional shared-value design. Neither block is modelled as a schema field (see finding 6); flagged here as a genuine, disclosed source-document quirk in the spirit of prior cycles' TCKN/YKN field-naming findings (e.g. GOV-4846).
3. No foreign-script/Turkish-script name split for the applicant — unlike Vat-3/4/5/6 (each of which splits the applicant into foreignFirstName/foreignLastName plus turkishFirstName/ turkishLastName), Vat-11'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 anywhere in that row). Modelled as plain firstName/lastName.
4. Spouse block carries no nationality/citizenship qualifier — Vat-11's own section header reads "EŞE AİT BİLGİLER" ("Information About the Spouse"), not Vat-6's "TÜRK VATANDAŞI EŞE AİT BİLGİLER" ("Information About the Turkish-Citizen Spouse"). Consistent with this, the section does carry its own Uyruk_2 (nationality) widget — the mirror image of Vat-6's finding that its Turkish-citizen-only spouse block has no nationality row. spouseIdentityNumber is therefore modelled as a generic identity-number string (no strict T.C.-Kimlik-No digit pattern), matching Vat-3's precedent for a spouse of unconstrained nationality, not Vat-6's 11-digit-pattern precedent.
5. Children carry only a foreign identity number, no T.C. Kimlik No — the minor-children table's YKN_3/YKN_4/YKN_5 widgets sit directly beneath "Varsa Yabancı Kimlik No (99… ile başlayan)" with no parallel TCKN_3/TCKN_4/TCKN_5 widgets anywhere in the annotation dump — confirmed both fields are absent, unlike Vat-5's reacquisition-applicant children (who may hold both, since a reacquiring parent's children could have previously held Turkish citizenship). Consistent with Vat-11's premise: a TRNC-citizen applicant's children would not have previously held Turkish citizenship.
6. Each child's Cinsiyeti (sex) is a free-text widget (fieldType: "Tx"), not a radio-button pair — confirmed directly from the annotation dump (Cinsiyet_3/Cinsiyet_4/Cinsiyet_5 all report "Tx"), unlike the applicant's own Cinsiyet (a genuine "Btn" radio pair). Modelled child{1,2,3}Sex as type: "string" rather than the enum used for the applicant's own sex, to preserve fidelity to the actual widget control type; the description documents the expected "Erkek"/"Kadın" values.
7. Out of scope: the closing Ad Soyad/İmza (printed name/ signature) widget (Başvuran Ad), the biometric-photograph box, and the entire page-2 "Beyan Alan Yetkilinin"/"Beyan Verenin" signature block (9 widgets: officialdom's name/title/date plus the duplicate- named declarant name/date widgets discussed in finding 2) — all receiving-authority- or signature-only artifacts, consistent with every prior VAT companion schema's exclusion of its own equivalent closing line.
8. Page-2 "Gerekli Diğer Bilgiler" (Other Required Information) block is unique to this schema among the registry's VAT companions — none of Vat-3/4/5/6/9 carry a second page of open-ended declarations. Three of its seven fields (otherNationalityDeclaration, residenceSinceDate, nameUsedInResidenceCountry) are always-applicable and modelled required: true; the remaining four (foreignCitizenshipAcquisitionInfo, statelessLegalConductDeclaration, turkishCitizenSiblingsDeclaration, turkeyRelativesDeclaration) are each conditional on a fact pattern the form does not capture via a separate structured control (whether the applicant holds another citizenship, is stateless, has Turkish-citizen siblings, or has relatives in Türkiye) — the source provides no boolean/enum toggle to requiredWhen-gate against, so these four are left required: false with a description disclosing their true conditional applicability, the same disclosed-judgment-call pattern used for genuinely conditional fields lacking a gating control elsewhere in the registry. foreignCitizenshipAcquisitionInfo is modelled type: "string" rather than date, since its own widget is a single free-text blank with no day/month/year split (unlike this schema's other date fields) and may legitimately contain "by birth" or "not applicable" rather than a calendar date.
9. 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.
10. This closes one of the six remaining GOV-4818-banked VAT candidates. VAT-1, VAT-2, VAT-7, VAT-8, 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 sixth schema within that already-open vertical, not a new vertical or jurisdiction.

Conformance

3 valid mock scenarios — valid-single-applicant-minimal (single applicant, no spouse, no children, filed domestically with a Governorate), valid-married-applicant-with-spouse-consulate (filed with a Consulate General abroad, spouse block fully populated, every optional applicant/page-2 field populated, no children), and valid-widowed-applicant-with-three-children (widowed applicant with a deceased spouse, all 3 children columns fully filled) — plus 20 static-required-field mutation fixtures, 11 requiredWhen mutation fixtures (9 gated on marital status ∈ {married, divorced, widowed} via the married scenario, 1 gated on divorced via a locally-derived divorced variant, 1 gated on widowed via the widowed scenario), and 1 unknown-field-rejected fixture — 35 fixtures total, committed under conformance/tr/nvi/acquisition-of-turkish-citizenship-by-trnc-citizens-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 35 fixtures: all 3 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 — 35/35 passing. Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (671/671 documents, both individually and as part of the full registry run). registry-index.json regenerated via npm run build-index in tools/govschema-client/.