# Verification record — tj/andoz/simplified-tax-declaration@1.0.0

## Candidate selection

GOV-4490 ("GovSchema Standard Research", child of GOV-4488). The candidate was found and byte-hashed during the GOV-4424 scouting pass (2026-07-22), which banked Tajikistan's Taxes vertical as a "re-verify field count/structure directly from the PDF text layer (not yet attempted)" entry — this cycle performs that extraction from scratch rather than trusting the scouting note's own description.

## Reaching the live source

Independently re-fetched and re-hashed:

- `https://andoz.tj/docs/deklarasii_2022/Эъломия.pdf` (URL-encode the Cyrillic filename)
- HTTP 200, `Content-Type: application/pdf`, `Content-Length: 165,556` bytes — byte-for-byte matching the GOV-4424 banked record.
- sha256 `ccff9ae32e073213241da92b921bd24185ec99ac92d0cca3d95e36f41e3e6bd3`.
- `andoz.tj` serves an untrusted/self-signed TLS certificate — a plain `curl` fails with "unable to get local issuer certificate". Retrieved with `curl -k` (certificate verification skipped), a deliberate, disclosed exception to this registry's usual plain-fetch practice, not a sign of a compromised or unofficial source — the same domain publishes its own current tax-forms directory (`andoz.tj/docs/deklarasii_2022/`) from which this URL was found.
- No login/CAPTCHA/WAF gate beyond the certificate quirk.

## Extraction method

Extracted with `pdfjs-dist` (vendored at `/tmp/node_modules/pdfjs-dist`, CommonJS build at `build/pdf.js`). `getAnnotations()` confirmed zero `/Widget` annotations on the single page — a flat (non-AcroForm) specimen, matching this registry's prior Bolivia/Paraguay/Zimbabwe specimens rather than an interactive form. `getTextContent()` then read every text item's raw string and its `transform` x/y position, grouped into lines by rounded y-coordinate, to reconstruct the form's own item numbering (1-5, 001-007) and section layout.

Because box/tick-mark grids are drawn graphics, not text, the page was also rendered to a PNG via `pdfjs-dist` + `node-canvas` at 2.5x scale (requiring a `DOMMatrix` polyfill supplied from the `canvas` package's own export, needed for this pdfjs build's tiling-pattern fill path under Node — otherwise `getPattern()` throws `ReferenceError: DOMMatrix is not defined`) to visually confirm every digit-box grid width and tick-box count the text layer alone cannot express. This confirmed: item 1 (РМА) and item 2 (РЯМ) are each a 9-cell digit-box grid; item 4 prints exactly 4 separate tick boxes (Ибтидоӣ / Навбатӣ / Иловагӣ (Тасхеҳӣ) / Барҳамдиҳӣ); item 5 prints a 2-2-4 date-box grouping identical to the later `submissionDate`/office `Санаи қабул` groupings, plus a Ҳа/Не tick-box pair; each of items 001-007 is a 10-cell digit-box grid with no decimal-point cell; and the applicant's own name/signature section (head/director, then chief accountant) sits above a dotted horizontal divider, below which sits the tax inspector's own office-only acceptance block (accepting inspector's name/signature, "Санаи қабул" date grid, "Рамзи мақомоти андоз" code box, and "Қайд оид ба қабули эъломия" note line).

`tin`'s 9-digit format is independently corroborated by two sources beyond this cycle's own rendered-page count: andoz.tj's own publicly-listed "bezovtstvennie" (tax-debtor) tables show real РМА values as 9-digit numbers (e.g. `010026462`, `350004882`, `190002703`), and a third-party TIN-format reference (taxdo.com) states Tajikistan's Taxpayer Identification Number is a 9-digit number. Those same public debtor tables show a dash ("-") in their own РЯМ column for several listed entities — direct evidence that РЯМ is not universally populated, informing this schema's `unifiedIdentificationNumber` `required: false`.

## Document structure

A single physical page, four numbered sections: **1. Маълумот дар бораи андозсупоранда** (Information about the taxpayer) — items 1 (РМА/TIN), 2 (РЯМ/unified identification number), 3 (taxpayer's full name); **2. Намуди эъломия ва давраи ҳисоботии андоз** (Declaration type and tax reporting period) — item 4 (a 4-way tick-box declaration-type selector) and item 5 (reporting-period date plus a separate-subdivision Ҳа/Не tick-box pair); **3. Ҳисоби андоз** (Tax calculation) — items 001-007, each a 10-digit boxed amount; **4. Тасдиқи дурустӣ ва пуррагии маълумоти дар эъломияи мазкур зикргардида** (Confirmation of the accuracy and completeness of the information stated in this declaration) — the applicant's sworn-accuracy statement, the head/director's and chief accountant's printed names and signature lines, and the submission date, followed by a dotted divider and the tax inspector's own office-only acceptance block.

## Scope: computed fields excluded

- **Item 004** ("Маблағи андоз аз фарқияти даромад байни харочот, аз ҷумла (сатри 004.1+сатри 004.2)" — tax amount from the income/expense difference, **including (row 004.1+row 004.2)**) is excluded: its own printed text states it equals the sum of items 004.1 and 004.2, both of which are independently modelled.
- **Item 005** ("Ҳамагӣ маблағи ҳисобшавандаи андоз (сатри 003+сатри 004)" — total calculated tax amount **(row 003+row 004)**) is excluded on the same basis: it is explicitly the sum of items 003 and 004.
- This mirrors this registry's standing GSP-0013 §7 exclusion test applied identically in `bo/sin/formulario-200-iva` and `zw/zimra/itf1-employment-income-return`: a form line whose own printed text names an explicit same-form row-arithmetic combination is excluded, regardless of whether the source uses "=", "аз ҷумла" ("including"), or an equivalent construction.
- Items 001, 002, 003, 004.1, 004.2, 006, and 007 carry no such arithmetic reference to other same-form rows and are each included as directly-supplied figures, even though 003 and 004.1/004.2 are conceptually alternative tax-computation-method results — the form gives the taxpayer no other row from which to derive them.

## Scope: office-only fields excluded

- The **tax inspector's own acceptance block**, printed below a dotted divider line following the applicant's own signature section — "Насаб ном номи падари нозири эъломияро қабулнамуда" (surname/name/patronymic of the inspector accepting the declaration) with its own signature line, "Санаи қабул" (date of acceptance), "Рамзи мақомоти андоз" (tax authority code), and "Қайд оид ба қабули эъломия" (note on acceptance of the declaration) — is excluded in its entirety as tax-office-supplied data, not applicant-supplied, the same class of exclusion this registry draws around Bolivia's Sección D bank stamp (`bo/sin/formulario-200-iva`) and Zimbabwe's "For official use only" box (`zw/zimra/itf1-employment-income-return`).

## Disclosed findings and interpretation choices

1. **`declarationType` is modelled as a 4-value enum** (`initial`, `regular`, `amended`, `liquidation`), one per the form's own tick boxes: Ибтидоӣ (initial), Навбатӣ (regular/next-in-sequence periodic filing), Иловагӣ (Тасхеҳӣ) (additional/corrective — i.e. amended), and Барҳамдиҳӣ (liquidation). This mirrors this registry's Kyrgyzstan precedent (`kg/gns/unified-tax-declaration`'s `declarationType`, a 3-value primary/amended/liquidation enum) with one additional value for this form's own extra "regular" tick box.
2. **`tin` (item 1, "РМА") is modelled with a strict 9-digit pattern**, confirmed by both the rendered page's own 9-cell digit-box grid and the independent corroboration described above under Extraction method.
3. **`unifiedIdentificationNumber` (item 2, "РЯМ") is modelled `required: false`**, distinct from the required `tin`, on the direct evidence (described above) that andoz.tj's own public debtor tables leave this field unpopulated for several real taxpayers.
4. **`taxPeriod` (item 5, "Давраи андоз") is modelled as a single `date`**, per its own 2-2-4-digit boxed grouping (matching the DD.MM.YYYY grouping this same form's own `submissionDate` field uses), rather than as separate day/month/year fields.
5. **`isSeparateSubdivision` (item 5, "Воҳиди алоҳида", a Ҳа/Не — Yes/No — tick-box pair) is modelled `type: boolean`, `required: true`**, since the form prints it as an unconditional binary question sitting on the same numbered row as the always-applicable reporting period, with no visible gating text limiting it to a subset of filers.
6. **All Section 3 monetary items (001, 002, 003, 004.1, 004.2, 006, 007) are modelled `type: integer` with `validation.minimum: 0`.** The form gives no explicit currency-precision instruction, but every printed amount box is a plain 10-digit grid with no decimal-point cell visible in either the text layer or the rendered page image, and no item's own text admits a negative value.
7. **No field on this form carries a visible mandatory-field asterisk or equivalent marker anywhere in the extracted text or the rendered page.** Per this registry's own precedent for un-asterisked sources (e.g. `bo/sin/formulario-200-iva`, `zw/zimra/itf1-employment-income-return`), only the header identification fields (`tin`, `taxpayerFullName`), the declaration-type/reporting-period/separate-subdivision items, the total-income figure (item 001), the head/director's own printed name, and the submission date are modelled `required: true` — a declaration cannot be meaningfully filed or processed without them. Items 002/003/004.1/004.2/006/007 are each `required: false` since they are alternative-method or trade-specific line items the form's own layout does not universally require of every filer (mirroring `bo/sin/formulario-200-iva` Finding 5's identical reasoning for its own not-every-filer-has-every-line RUBRO items), and `accountantFullName` is `required: false` since a simplified-regime taxpayer (which may be an individual entrepreneur with no accounting staff) will not always have a chief accountant to name.
8. **The physical signature marks themselves are not separately modelled as data** — they are captured by the `declarationAttestation` document's own `required: true`, consistent with this registry's `bo/sin/formulario-200-iva` and `zw/zimra/itf1-employment-income-return` precedent for signature blocks; the accompanying printed names (`headFullName`, `accountantFullName`) and `submissionDate` are modelled as ordinary fields since they are typed/written data distinct from the signature act.

## Conformance

3 valid mock scenarios — `valid-initial-declaration-cash-method` (a first-time filer under the cash-method computation, with a populated goods-inventory balance); `valid-amended-declaration-income-expense-method` (a corrective/amended filing under the income-minus-expenses method, exercising both the goods-production and other-activity sub-items); and `valid-liquidation-declaration-separate-subdivision` (a liquidation filing for a separate subdivision, with no chief accountant named) — plus 6 mutation-control fixtures (one missing statically-required field from each of `tin`, `taxpayerFullName`, `declarationType`, `taxPeriod`, `totalIncomeForPeriod`, `submissionDate`) and one unknown-field-rejected fixture, committed under `conformance/tj/andoz/simplified-tax-declaration/1.0.0/`.

An ephemeral, from-scratch conformance checker (deriving required rules directly from this schema's own `fields[]`, discarded after use, not committed) ran all fixtures: all 3 valid scenarios at 0 errors, all 6 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. `registry-index.json` regenerated via `npm run build-index` in `tools/govschema-client/`.