# Verification record — zw/zimra/itf1-employment-income-return@1.0.0

## Candidate selection

GOV-4470 ("GovSchema Standard Research", child of GOV-4468). Zimbabwe's ZIMRA ITF 1 was banked as a pre-scouted STRONG backup candidate during the prior GOV-4458 cycle (which instead authored Bolivia's Formulario 200 IVA). This cycle independently re-verified the candidate fresh rather than trusting the delegating issue's own paraphrase — the issue's own description mis-scoped two sections (see Disclosed findings, below).

## Reaching the live source

Independently re-fetched and re-hashed:

- `https://www.zimra.co.zw/downloads/category/9-domestic-taxes?download=385%3Aitf-1-return-of-employment-income-by-an-individual`
- HTTP 200, `Content-Type: application/pdf`, `Content-Length: 425,835` bytes — byte-for-byte matching the delegating issue's own disclosed size.
- sha256 `a75fb0ae96c51ca7dbde0ec13cc8093666e458e46313430cfa8c5d8e7b78fcca`.
- No login, CAPTCHA, or WAF gate — a plain unauthenticated `curl` request with no session/cookie state reached it cleanly.
- 7 physical pages. Document-control footer stamps `DTF: 84 DOMESTIC TAXES ISSUE NO: 1 VERSION NO: 1 DATE OF ISSUE: 26/10/2015` on every page — a long-standing edition, still the current live download.

## Extraction method

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

Because this specimen's body-text glyphs did not render through `pdfjs-dist`'s canvas backend even after supplying `standardFontDataUrl`/`cMapUrl` (a font-loading limitation of this particular PDF's embedded Times/Helvetica subsets, not a text-layer defect — the text layer itself extracted cleanly), table/row structure was confirmed by rendering each page to a PNG via `pdfjs-dist` + `node-canvas` at 2.5x scale and visually counting the printed table gridlines (which render even where glyph paths do not), cross-referenced against the text layer's own x/y line groupings. This combination independently confirmed: the Employment section's employer/position/period columns sit above one unruled writing block (no fixed row count — modelled as free text, not a bounded table); the P.A.Y.E.-deducted section prints exactly one row of two side-by-side Serial No./Amount column pairs (bounded to 2 slots); the Disabled Person's Credit table prints exactly 3 ruled rows; and both the Bank/Savings Accounts and Rent Paid tables print exactly 4 ruled rows each.

## Document structure

Pages 1-6 carry the applicant-facing form; page 7 (and the tail of page 6) is a purely informational, three-column directory of ZIMRA Regional Tax Office and border-post addresses, correctly excluded per the delegating issue's own scoping instruction. The form's own numbered sections: header/identity (T.I.N., date of birth, name, addresses); Employment; Details of earnings; Deductions claimed; §2-4 Other income; §5 P.A.Y.E. deducted; §6 Credits claimed (A. Medical expenses, B. Medical aid contributions, C. Blind person's credit, D. Disabled person's credit); §7 Details of bank or savings accounts; §8 Rent paid; §9 Other information; §10 Remarks; §11 Declaration; §12 Regional Tax Offices (excluded, office directory).

## Scope: office-only / computed fields excluded

- **The page-1 "For official use only" box** (Taxpayers Identity Number, "Issued by", "To…" address lines) is excluded in its entirety as ZIMRA's own pre-issuance office box, not applicant-supplied — the same class of exclusion this registry draws around Bolivia's FOLIO/NÚMERO DE ORDEN (`bo/sin/formulario-200-iva`) and Paraguay's own office-assigned tracking numbers. This is distinct from the applicant's own later T.I.N./Date of birth entry (page 1, below the instructions), which is included.
- **Every printed "Office use only" annotation column** running down the right edge of the Earnings, Credits Claimed, Bank Accounts, and Rent Paid tables is excluded as ZIMRA staff annotation space, not applicant data.
- **Total from employment, Total deductions claimed, Net earnings, Total income, and Total medical expenses** are each excluded as same-form computed sums (arithmetic combinations of other same-form lines, with explicit "=" arithmetic marks printed beside several of them), per this registry's standing GSP-0013 §7 exclusion for calculated/derived fields.
- **Section 12 (Regional Tax Offices) and the closing portion of page 6** are excluded as a third-party office directory, not applicant data, consistent with the delegating issue's own scoping instruction to exclude page 7.

## Disclosed findings

1. **The delegating issue's own paraphrase omitted two genuine sections, both caught by this cycle's independent re-extraction rather than trusting the issue text at face value.** (a) Page 1 prints "Spouse's address" and "Name and address of spouse's employer" as two further header fields (continuing onto page 2), absent from the issue's own header-field list — included here as `spouseAddress`/`spouseEmployerNameAddress`, both optional since the form prints no separate marital-status indicator to gate them on. (b) Section 6 prints a "C. Blind person's credit" subsection ("Claim relates to … Self … Spouse") between the issue's listed (A) and (B) items and its (D) Disabled person's credit — included here as `blindPersonCreditClaimRelatesTo`.
2. **The Employment section's employer/position/period-of-employment columns are modelled as free-text fields, not a bounded row-repeating table**, since the source prints one unruled writing block beneath the three column headers rather than the ruled sub-rows this registry's bounded-slot precedent (e.g. `zm/pacra/company-incorporation`'s director1/director2) requires before slotting. GSP-0009 (composite & repeating values / arrays) remains an unaccepted spec proposal, so an unbounded list has no structural representation available regardless; this is the same "flatten when the composite is unruled free text" posture this registry's Remarks/Other-earnings/Benefits fields already take elsewhere on this same form.
3. **P.A.Y.E.-deducted, Disabled Person's Credit, Bank/Savings Accounts, and Rent Paid are each modelled as bounded numbered slots** (2, 3, 4, and 4 respectively), matching the exact number of ruled rows each table prints — confirmed via the rendered-page gridline count, not merely inferred from column headers — mirroring this registry's `zm/pacra/company-incorporation` bounded-slot precedent. Unlike that Zambian precedent, this form prints no companion "how many" count field, so slots beyond the first carry no `requiredWhen` gate of their own; only the first Rent Paid slot (and `boardType`) is gated `requiredWhen ownHome equals false`, mirroring the source's own explicit "If 'NO' give the following details" instruction.
4. **"Other earnings (specify)" and "Benefits (please specify type of benefits and state amount)" are each split into a description field plus an amount field**, even though the source prints one combined blank line per item, for cleaner machine-readable amounts; both halves carry an identical `sourceRef` pointing at the same printed blank.
5. **`title` is modelled `type: string`, not `enum`**, since the source prints "Mr., Mrs., etc." as illustrative examples, not a closed option list — the same reasoning this registry's `zm/pacra/company-incorporation` applies to its own ungated `Gender` field.
6. **All monetary fields are modelled `type: integer` with `validation.minimum: 0`.** The source gives no explicit currency-precision instruction (unlike Bolivia's "EN BOLIVIANOS SIN CENTAVOS"), but every printed amount blank is a plain `$` figure with no decimal ruling visible in either the text layer or the rendered page images, and no line'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 pages.** Per this registry's own precedent for un-asterisked sources (e.g. Bolivia's Formulario 200, Zambia's ITF 46_1), only the header identity block (tax year, T.I.N., date of birth, surname, first names, residential address), the Employment section's employer name(s)/address(es) field (a return cannot report employment income without at least one employer), and the closing declaration's signature date are modelled `required: true`, on the basis that a return cannot be meaningfully filed or processed without them; every other field is `required: false`, gated `requiredWhen` where the source's own branching text (first-return Yes/No; own-home Yes/No) makes the conditional relationship explicit.
8. **The physical signature mark itself is not separately modelled as data** — it is captured by the `declarationAttestation` document's own `required: true`, consistent with this registry's `bo/sin/formulario-200-iva` precedent for signature blocks; the accompanying `signatureDate` is modelled as an ordinary required field since it is typed/written data distinct from the signature act.

## Conformance

3 valid mock scenarios — `valid-single-employer-paye-return` (a straightforward single-employer filing with salary income, PAYE already deducted, and a medical-aid credit); `valid-multiple-employers-and-rent-paid` (an employee who changed employers mid-year, exercising two P.A.Y.E. certificate slots and two Rent Paid landlord slots on a rented home); and `valid-first-return-with-disability-credits` (a first-time Zimbabwe filer exercising the first-return explanation branch, all three Disabled Person's Credit slots, and multiple bank accounts) — plus 8 mutation-control fixtures (one missing statically-required field from each of `taxYear`, `tin`, `dateOfBirth`, `surname`, `firstNames`, `residentialAddress`, `employersNamesAddresses`, `signatureDate` — one per required field) and one unknown-field-rejected fixture, committed under `conformance/zw/zimra/itf1-employment-income-return/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 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/`.