# Verification record — tj/vkd/internal-passport-application@1.0.0

## Candidate selection

GOV-4506 ("GovSchema Standard Research"). The candidate was found and byte-hashed during the GOV-4424 scouting pass (2026-07-22), which banked Tajikistan's National ID vertical as a "ready-to-author 3-of-6 new-jurisdiction candidate for a future cycle" entry (Known Gaps 0i, later re-confirmed live and un-authored by GOV-4488/GOV-4490/GOV-4499, Known Gaps 0k) — its field structure was never text-extracted at that time. This cycle performs that extraction from scratch rather than trusting the scouting note's own description.

## Reaching the live source

Independently re-fetched: `https://passportvkd.tj/wp-content/uploads/2019/11/Zamimaho.docx`, HTTP 200, `Content-Length: 608,357` bytes — byte-for-byte matching the GOV-4424 banked record. sha256 `c3f4c20ad42452eda4148a6bb46d3b88322d65fcc94880afa25fdb3c3566beb1`. Genuine Office Open XML (`.docx`, a real ZIP/`[Content_Types].xml` container, not a renamed binary `.doc`). No login/CAPTCHA/WAF gate; a plain `curl` (no `-k` needed, unlike sibling `andoz.tj`) succeeds.

## Extraction method

`passportvkd.tj`'s own "Zamimaho" (Appendices) document is a single large docx bundling roughly 35 numbered appendix forms end-to-end (Shakli 1 through Shakli 35+, covering the passport service's entire form library — residence registration, military-obligation deregistration, correction requests, and more), not solely the internal-passport application. `word/document.xml` was extracted directly via Python's standard-library `zipfile` module (no `unzip`/`pip` available in this environment) and each `<w:p>...</w:p>` paragraph's `<w:t>` runs concatenated in document order (with a corrected regex distinguishing literal `<w:t>` from `<w:tab .../>`, whose tag name is a substring-prefix match risk that first produced a garbled extraction with raw XML leaking into the transcribed text) to reconstruct plain text with paragraph breaks preserved.

The scope boundary was located by searching for the form's own `Шакли N` page headers: Shakli 1 begins at the document's second paragraph and Shakli 2 begins 113 paragraphs later, cleanly bounding this schema's own scope to Shakli 1 plus its own numbered continuation sheet Shakli 1/1 (which sits between Shakli 1's own closing office block and Shakli 2's own heading, and is explicitly captioned as belonging to the same application, "Ариза барои гирифтани шиноснома" — "Application for obtaining the passport").

Confirmed via inspection (searching for `<w:sdt>`, `<w:tbl>`, and checkbox/content-control markup within this span) that the form carries zero tables, content controls, or checkbox form-fields — a plain fill-in-the-blank template using underscore rules for every answer, consistent with this registry's prior Bolivia/Zimbabwe/Tajikistan-Taxes non-AcroForm specimens; two `<w:drawing>` elements in this span correspond to the form's own photo-placement boxes ("РАСМ" / "Ҷои сурат"), not data-bearing content.

## Document structure

**Shakli 1** (two sides of one physical sheet): a front side with 20 numbered items — items 1-14 (applicant's own current and prior name components, sex, date/place of birth, blood group and Rh factor, marital status, spouse's name, and TIN), items 15-16 (the prior document the passport issuance is based on, and any additional supporting identity documents, each a single compound blank), item 17 (payment receipt or fee-exemption document reference), item 18 (applicant's own signature), and items 19-20 (the receiving clerk's own office-only acceptance code/signature block) — followed by a reverse side ("тарафи дигари варақа") with items 21-34 — items 21-22 (father's and mother's full names), items 23-25 (three consecutively numbered blanks captioned with the identical residence-address label), item 26 (a unified national identification number), item 27 (an office-only service-notes line), items 28-31 (the applicant's own previous passport's number, validity period, issuing authority, and issue date, for replacement/renewal filers), and items 32-34 (the applicant's own second signature acknowledging responsibility for false information, followed by two further office-only employee/head signature blocks).

**Shakli 1/1** ("ба Дастурамал" — appendix to the instruction, the application's own continuation sheet): a system-assigned application sequence number ("Рақами ариза", printed as a 12-digit placeholder, `000000000001`) and an unexplained "Афзалият" (priority/preference) marker; a "Маълумотҳои шахсӣ" (personal data) block restating the applicant's name, nationality, national number, TIN, date of birth, sex, blood group, marital status, place of birth, address/phone, and spouse — all already captured on Shakli 1 itself; a "Мавҷудияти изи ангуштҳо" (fingerprint availability) section with left-hand/right-hand indicators; an eight-question "Саволнома" (Questionnaire) of Yes/No (Ҳа/Не) eligibility questions; and a "Пардохт" (Payment) block (payment date, receipt number, discount type/percentage, amount) closed by a final applicant signature line.

## Scope: excluded content

- **Shakli 1/1's own restatement of the applicant's personal data** (name, nationality, national number, TIN, date of birth, sex, blood group, marital status, place of birth, address, spouse) is excluded in its entirety: every one of these facts is already modelled once from Shakli 1 itself (items 1-14, 26), and the continuation sheet's own layout and heading ("Маълумотҳои шахсӣ") read as a system-populated summary printed from the same underlying record, not a second independent data-collection point.
- **`Рақами ариза` (application sequence number) and `Афзалият`** are excluded: the printed `000000000001` placeholder is plainly a system-assigned sequence counter, not applicant-supplied data, and `Афзалият` ("priority"/"preference") carries no explanatory text anywhere in this document — this Zamimaho bundle contains only the appendix forms themselves, not the instruction ("Дастурамал") document each appendix is captioned as belonging to, so this field's meaning cannot be confirmed from the available source and is disclosed as excluded rather than guessed.
- **The fingerprint-availability indicators** (left hand/right hand) are excluded as an office-completed confirmation that biometric capture occurred during in-person enrollment, not applicant-supplied data — the same class of exclusion this registry draws around other office-only confirmation marks (e.g. `tj/andoz/simplified-tax-declaration`'s tax-inspector acceptance block).
- **The Payment block** (payment date, receipt number, discount type/percentage, amount) is excluded as office/cashier-supplied transaction data, mirroring this registry's standard treatment of payment-processing blocks; the applicant-facing obligation to present a receipt or fee-exemption document is instead captured as the `paymentReceiptOrFeeExemptionDocument` document requirement (Shakli 1, item 17).
- **Items 19-20, 27, and 33-34** (the receiving clerk's acceptance code/signature/date, the service-notes line, and the processing employee's and department head's own signature blocks) are excluded as office-only, the same class of exclusion as this registry's `tj/andoz/simplified-tax-declaration` tax-inspector block.
- **The applicant's own signature marks themselves** (Shakli 1 items 18 and 32) are not separately modelled as data — captured instead by the `signedApplicationDeclaration` document's own `required: true`, consistent with this registry's established signature-block convention (e.g. `tj/andoz/simplified-tax-declaration`, `bo/sin/formulario-200-iva`).

## Disclosed findings and interpretation choices

1. **Items 23, 24, and 25 print the identical residence-address caption three times in a row** ("суроғаи ҷойи зист ва ё суроғаи ҷойи будубош: вилоят, ноҳия, нуқтаи аҳолинишин, кӯча, хона, бино, ҳуҷра" — "address of residence or address of actual stay: region, district, locality, street, house, building, room"), each with its own full-width blank line and its own item number, with no distinguishing text anywhere in the source explaining why three numbered blanks share one caption. Rather than invent a semantic distinction the form itself does not state (e.g. guessing these are three different addresses), this schema models them as three sequential bounded slots — `residentialAddressLine1` (required, since a residence address cannot be entirely absent), `residentialAddressLine2` and `residentialAddressLine3` (both optional continuation lines) — the same bounded-slot treatment this registry has applied to other forms with repeated, undifferentiated numbered blanks.
2. **`sex` (item 4, "ҷинс") is modelled as a free-text `string`, not an `enum`**, because — unlike `maritalStatus` (item 12), whose blank is captioned with its own two printed options ("оиладор/муҷаррад") — this item's blank carries no printed option list at all, only the bare category label. Modelling it as a string avoids asserting a closed value set the source itself does not print.
3. **`maritalStatus` (item 12) is modelled as a 2-value enum** (`married`, `single`), mapped from the form's own printed "оиладор/муҷаррад" (married/unmarried) option pair directly beneath the blank.
4. **`spouseFullName` (item 13) is modelled `requiredWhen` `maritalStatus` equals `married`, static `required: false`**, since a single applicant has no spouse to name and the form provides no other gating mechanism for this field.
5. **Items 15 and 16 ("шиноснома дода шудааст дар асоси" and "Ҳуҷҷатҳои иловагӣ") are each modelled as a single compound `string` field**, not decomposed into separate document-name/series/number/date/authority fields, because each is printed as exactly one continuous underscore blank beneath a caption listing several sub-facts to write into that one line — unlike the later previous-passport block (items 28-31), where each of those same sub-facts (number, validity period, issuing authority, issue date) gets its own separately numbered blank and is modelled as a separate field accordingly.
6. **`nationalIdNumber` (item 26, "рақами ягонаи миллии") is modelled `required: true`**, as Tajikistan's own unified national identification number, a distinct concept from both `tin` (item 14, the tax identifier) and the passport's own future serial number (not yet assigned at application time, hence not itself a field on this form).
7. **Items 28-31 (the applicant's own previous passport details) are all modelled `required: false`**, since a first-time applicant (per the very process this unified form covers) has no previous passport to report; the form gives no separate first-time/renewal/replacement selector field distinguishing these cases, so requiredness cannot be conditioned on an applicant-supplied value and is instead left optional across the board, consistent with this registry's treatment of renewal-only blocks on other first-time/renewal/replacement combined forms (e.g. `zw/rg/passport-application`'s own lost/stolen-particulars section).
8. **The eight Саволнома (Questionnaire) items are each modelled as a `boolean` field, `required: true`.** Two pairs read as near-duplicates of each other at first glance (`q1SecretInfoAuthorizationFormsOneAndTwo` and `q7PriorSecretInfoAuthorization`) but are grammatically distinct in the source — q1 uses the present-perfect "дароварда шудааст" ("has been formalized", i.e. a currently-standing authorization) while q7 uses the past-perfect "дароварда шуда буд" ("had been formalized", i.e. an authorization that existed at some past point, phrasing consistent with asking about a since-lapsed or revoked clearance) — both are modelled as distinct fields rather than collapsed into one, since the form itself prints them as two separate questions.
9. **No field on this form carries a visible mandatory-field asterisk or equivalent marker** anywhere in the extracted text. Per this registry's own precedent for un-asterisked sources (e.g. `tj/andoz/simplified-tax-declaration`, `bo/sin/formulario-200-iva`), fields are modelled `required: true` only where the form's own layout and this application's basic purpose make the fact essential to processing any application at all (the applicant's own current name, sex, date/place of birth, marital status, parents' names, current residence, national ID number, the passport-issuance-basis document, and all eight questionnaire answers), and `required: false` elsewhere (prior names, blood group, TIN, additional documents, previous-passport particulars, and the two address continuation lines).

## Conformance

3 valid mock scenarios — `valid-first-time-single-applicant` (a never-married first-time applicant with no previous passport and no prior-name history), `valid-renewal-married-applicant-with-spouse` (a married renewal applicant reporting a previous passport and a spouse), and `valid-name-change-divorced-applicant` (a divorced applicant reporting a prior (maiden) name and additional supporting documents) — plus 8 mutation-control fixtures (one missing statically-required field from each of `surname`, `givenName`, `sex`, `dateOfBirth`, `maritalStatus`, `fatherFullName`, `residentialAddressLine1`, and `q8OtherCitizenship`) and one unknown-field-rejected fixture, committed under `conformance/tj/vkd/internal-passport-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 fixtures: all 3 valid scenarios at 0 errors, all 8 mutation controls each raising exactly 1 error, and the unknown-field fixture correctly rejected. Validated clean with `node tools/validate.mjs` and `node tools/validate-ajv.mjs`, individually and as part of the full registry run (623/623 documents). `registry-index.json` regenerated via `npm run build-index` in `tools/govschema-client/`.