Tajikistan — Ариза оид ба додани шиносномаи шаҳрванди Ҷумҳурии Тоҷикистон (Application for Issuance of the Internal Passport of a Citizen of the Republic of Tajikistan)

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/.