Zimbabwe ITF 1 — Return of Employment Income by an Individual

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