# Verification record — tr/nvi/general-acquisition-of-turkish-citizenship-application@1.0.0

## Candidate selection

GOV-4818 ("GovSchema Standard Research"). Türkiye (TR) was entirely absent
from the registry (99 jurisdictions before this cycle). A prior cycle had
briefly screened Türkiye's `evisa.gov.tr` for the Visa vertical only
(found to redirect to a commercial third-party domain) and left every
other vertical unscreened. This cycle screened all six verticals fresh:

1. **Passport** — `nvi.gov.tr`'s ordinary-passport process is entirely
   biometric/in-person via e-Devlet appointment booking
   (`randevu.nvi.gov.tr`); the only downloadable "Pasaport Talep
   Formları" on that domain are for **service/diplomatic passports**
   (government officials only), not applicant-facing. **Dead end.**
2. **DMV** — `egm.gov.tr/trafik-tescil-hakkinda` states vehicle
   registration forms (EK-1, M1) are obtained in person from Şoförler
   Odası (Drivers' Chambers), not published online; driver-license exam
   applications route through a login-gated MEB e-Sınav portal. **Dead
   end for a downloadable field-by-field form.**
3. **Business Formation** — MERSIS (`mersis.gtb.gov.tr`), Türkiye's
   central trade-registry system, requires a MERSIS account or
   e-Devlet/e-imza login before any field is shown — a genuine login
   gate hiding the field structure. The Ministry of Trade's published
   "esas sözleşme örneği" (model articles-of-association templates) are
   legal boilerplate contracts, not application forms. **Dead end.**
4. **Taxes** — GİB's own "Hazır Formlar" (Ready Forms) library at
   `dijital.gib.gov.tr/Formlar`, checked live, returned "Seçilen
   kategoriye ait kayıt bulunmamaktadır" (no records) for every category;
   all filing paths (e-Beyanname, İnteraktif/İnternet Vergi Dairesi,
   Hazır Beyan Sistemi) require T.C. Kimlik No + e-Devlet login. **Dead
   end** — Türkiye's tax administration is fully digitized with no
   paper-form fallback.
5. **Visa** — `evisa.gov.tr` re-screened live with a real Playwright
   browser (not just an HTTP fetch): it does redirect, inconsistently, to
   `dtvgroup.com.tr` ("DTV Consultancy... a subsidiary of the Foundation
   for Strengthening the Foreign Affairs Organization" — a real
   MFA-affiliated intermediary, correcting the prior cycle's "unrelated
   commercial domain" characterization). The application wizard itself
   (`evisa.gov.tr/en/apply/`) reaches a real step-1 screen (visa type,
   nationality, travel-document type, destination) but gates the actual
   personal-data page behind a reCAPTCHA before the field structure can
   be observed. **Dead end for schema extraction** (different reason
   than previously recorded, same outcome).
6. **National ID & Civic Documents** — `nvi.gov.tr/vatandaslik-ile-ilgili-formlar`
   publishes 11 live, unauthenticated, directly downloadable AcroForm
   PDFs (VAT-1 through VAT-11) covering Turkish-citizenship acquisition
   and loss, issued by the Ministry of Interior's own Nüfus ve
   Vatandaşlık İşleri Genel Müdürlüğü (NVI). **VAT-3** ("Genel Olarak
   Türk Vatandaşlığının Kazanılması Başvuru Formu" — General Acquisition
   of Turkish Citizenship Application Form) is the broadest of the
   series and was confirmed via `pdfjs-dist` to carry 100 genuine
   AcroForm fields (not a scanned image). **Authored as this v1.0.0** —
   opens Türkiye as the registry's 100th jurisdiction.

## Reaching the live source

- **Form Vat-3**:
  `https://www.nvi.gov.tr/kurumlar/nvi.gov.tr/mevzuat/nufusmevzuat/Formlar/Vatandaslik/Vat3_Genel_Kazanma.pdf`
  — HTTP 200, `Content-Type: application/pdf`, `Content-Length: 870243`
  bytes (matches the downloaded file exactly), sha256
  `e94cafefbbf09d9ec13c3b0849e8b227b2758ee959472824d9ce58f00d4f4533`,
  `Last-Modified: Tue, 04 Aug 2020 08:33:31 GMT`, no login/CAPTCHA gate,
  linked directly from NVI's own current "Vatandaşlık ile İlgili Formlar"
  listing page. Retrieved 2026-07-25.
- Field structure extracted with `pdfjs-dist`'s `getAnnotations()` (100
  AcroForm widgets on a single page) and cross-checked against the text
  layer (`getTextContent()`) for label wording. Because the form packs a
  dense two-column layout (applicant block, marital-status block, spouse
  block, and a 3-column minor-children table all on one page), the page
  was additionally rendered at scale 2.2 via `node-canvas` and visually
  inspected in cropped sections to confirm which printed label each
  AcroForm field name corresponds to — several field names on this form
  are not self-describing (e.g. `Soy` for the "Soyu" column, `Ad_33`/
  `Soyad_33` for "Türkçe Adı"/"Alacağı Soyadı" within the children table,
  as distinct from `Ad_3`/`Soyad_3` for "Yabancı Adı"/"Yabancı Soyadı" in
  the same column) and were only resolved correctly by matching each
  field's rendered `rect` y-coordinate against the row it visually sits
  in, not by name alone.
- Legal basis: Law No. 5901 on Turkish Citizenship (Türk Vatandaşlığı
  Kanunu), Article 11 — the form's own closing declaration cites this
  article by number ("5901 sayılı Türk Vatandaşlığı Kanununun 11'inci
  maddesi uyarınca Türk vatandaşlığını genel hükümlere göre kazanmak
  istiyorum").

## Findings / disclosed scoping calls

1. **`jurisdiction.level` is `"national"`** — NVI is Türkiye's central,
   state-level civil-registry authority; this form is filed with a
   provincial Governorate (Valilik) acting on NVI's behalf, not a
   subnational body with its own separate legal basis.
2. **`descentOrLineage` (source label "Soyu") is modelled as optional and
   described conservatively** — the form prints this as a bare column
   header inside the place-of-birth block with no further gloss or
   footnote defining it. Rather than guess at a semantic meaning (e.g.
   ethnic descent relevant to Türkiye's separate soydaş/descent-based
   citizenship pathway), this schema states the ambiguity explicitly in
   the field's own `description` and leaves it non-mandatory.
3. **`phoneNumber` and `emailAddress` each collapse a visually-split
   pair of input boxes into one field** — the source prints a
   parenthetical area-code box before the phone number and splits the
   email box around a fixed, non-editable "@" glyph. Both splits are
   typographic, not two independent pieces of data (unlike, say, a
   day/month/year triple), so each is modelled as a single semantic
   field, noted in its own `description`.
4. **`maritalStatus` is modelled as a 4-way enum** derived from four
   independently-named "Evet" checkbox widgets (Bekar/Evli/Boşanmış/Dul)
   that are visually a single-select group despite not sharing one
   PDF field name.
5. **`hasPriorCriminalConviction` and `hasPendingProsecution` are
   modelled as a 2-value enum (`yes`/`no`)**, not free text, even though
   their underlying AcroForm widgets are plain text boxes — the form's
   own printed instruction constrains the answer to "(Evet-Hayır)".
6. **`marriageDate` is `requiredWhen maritalStatus` is `married`,
   `divorced`, or `widowed`; `divorceDate` only when `divorced`;
   `spouseDeathDate` only when `widowed`; every `spouse*` field only
   when not `single`** — this is a direct transcription of the form's
   own printed footnote (a/b/c) stating exactly which combination of
   dates and spouse particulars must accompany each marital-status
   answer.
7. **`maidenName` is `requiredWhen useMaidenNameWithMarriedSurname` is
   `true`** — the form only provides a maiden-surname box conditioned on
   answering "yes" to the adjoining checkbox question.
8. **The 3-column minor-children table is modelled as bounded-slot
   `child1`/`child2`/`child3` fields (12 fields per child), all
   optional** — consistent with this registry's established
   bounded-slot precedent (e.g. `us/uscis/naturalization-n400`'s
   `child1Name`/`child2Name`/`child3Name`). The form provides exactly 3
   columns and states no further overflow procedure, so no more than 3
   slots are modelled.
9. **Out of scope**: the header's `Kayıt Tarihi`/`Kayıt No` (registration
   date/number, completed by the receiving authority upon intake, not
   the applicant), the biometric-photograph box, and the closing
   signature/printed-name line (`Ad Soyad`/`İmza`) — consistent with
   every prior flat-PDF schema in this registry. `declarationDate` (the
   date accompanying the signature) is kept in scope as applicant-
   provided data, distinct from the signature mark itself.
10. **DMV, Business Formation, Taxes, Visa, and Passport are all
    confirmed dead ends for Türkiye this cycle** (see "Candidate
    selection" above) — National ID & Civic Documents is Türkiye's only
    open vertical going into future cycles' backlog, via the remaining
    VAT-1/2/4-11 citizenship-related forms on the same NVI page (not
    screened field-by-field this cycle beyond confirming they exist as
    live AcroForm PDFs).

## Conformance

4 valid mock scenarios — `valid-single-applicant-minimal` (maritalStatus
= single, exercising only the 21 unconditionally-required fields),
`valid-married-applicant-with-spouse` (maritalStatus = married,
exercising `marriageDate` plus all 10 spouse fields), `valid-widowed-applicant-with-three-children`
(maritalStatus = widowed, exercising `marriageDate` + `spouseDeathDate` +
all 10 spouse fields + all 3 children columns fully filled), and
`valid-married-applicant-using-maiden-name` (exercises `maidenName`) —
plus 21 static-`required`-field mutation fixtures (one per
unconditionally-required field) and 14 `requiredWhen` mutation fixtures
(one per conditionally-required field: `maidenName`, `marriageDate`,
`divorceDate`, `spouseDeathDate`, and all 10 spouse fields, each built
from the appropriate positive scenario above), and 1
unknown-field-rejected fixture — 40 fixtures total, committed under
`conformance/tr/nvi/general-acquisition-of-turkish-citizenship-application/1.0.0/`.

An ephemeral, from-scratch conformance checker (deriving required/
`requiredWhen` rules directly from this schema's own `fields[]`,
discarded after use, not committed) ran all 40 fixtures plus the 10
scripted scenarios used during authoring: every valid scenario at 0
missing-field errors, every mutation fixture raising exactly the one
error it targets, and the unknown-field fixture's extra key correctly
ignored by requiredness logic (schema-level rejection of unknown fields
is an implementer's own JSON Schema `additionalProperties` concern, out
of this document's scope). Validated clean with `node tools/validate.mjs`
and `node tools/validate-ajv.mjs`, individually and as part of the full
registry run. `registry-index.json` regenerated via `npm run build-index`
in `tools/govschema-client/`.