# Verification record — zw/zimra/rev1-application-for-new-registration@1.0.0

## Candidate selection

GOV-4478 ("GovSchema Standard Research", child of GOV-4476), following GOV-4470's ITF 1 cycle which opened Zimbabwe as the registry's 87th jurisdiction under Taxes. This cycle authors Zimbabwe's Business Formation vertical (2/6) via ZIMRA's Form REV 1, "Application for New Registration Form" — the form used to register with ZIMRA for the first time and obtain a Business Partner (BP) number.

## Reaching the live source

Independently re-fetched and re-hashed:

- `https://www.zimra.co.zw/downloads/9-domestic-taxes?download=378:form-rev-1-application-for-new-registration-form`
- HTTP 200, `Content-Type: application/pdf`, `Content-Length: 479,772` bytes — byte-for-byte matching the delegating issue's own disclosed size.
- sha256 `f7a8a038e2b9227ef261f467ff7c7eb72e61eaef287c3996db0472afce8845dd`.
- No login, CAPTCHA, or WAF gate — a plain unauthenticated `curl` request with no session/cookie state reached it cleanly.
- 18 physical pages. Document-control footer stamps `DTF: 1 DOMESTIC TAXES ISSUE NO: 1 VERSION NO: 2 DATE OF ISSUE: 31/03/2020` on every page.

## Extraction method

Extracted with `pdfjs-dist` (vendored at `/tmp/node_modules/pdfjs-dist`, legacy CommonJS build). `getAnnotations()` confirmed zero `/Widget` annotations across all 18 pages — a flat (non-AcroForm) specimen, the same print-and-fill pattern as this registry's `zw/zimra/itf1-employment-income-return`. `getTextContent()` read every text item's raw string and its `transform` x/y position, grouped into lines by rounded y-coordinate, across all 18 pages.

The applicant-facing form's own body text (Parts I-XII, pages 1-7) extracted cleanly and unambiguously through the text layer alone, **except** Part [III].A "Revenue Heads" on page 2 — a four-column, 38-item tick grid whose text items interleave across columns when grouped purely by y-coordinate (each visual row spans four separate item/label/tick cells, and the raw item-by-item extraction order does not match reading order). This section was independently re-verified by rendering page 2 (and page 3, for the Special Income Tax Categories continuation) to a PNG via `pdfjs-dist` + `node-canvas` at 2.5x scale and reading the rendered grid directly — glyphs rendered cleanly on this specimen (unlike the ITF1 specimen's font-loading limitation), so the image itself, not just gridlines, was legible. All 38 revenue-head labels and item numbers, and all 10 special-category labels, were transcribed directly off the rendered image, cross-checked against the raw text layer's own (out-of-order) tokens to confirm no label was dropped or duplicated. Pages 1, 3, 4, 5, 6, and 7 were also rendered as a secondary check against the text-layer reconstruction of table/column structure (bounded-slot counts, tick-box layout, checkbox groupings).

## Document structure

Pages 1-7 carry the applicant-facing form:

- Page 1 — Part [I] Nature of Applicant; Part [II] Particulars of Applicant (items 1-10).
- Page 2 — Part [II] continued (items 11-14); Part [III].A Revenue Heads (38-item tick grid); Part [III].B Special Income Tax Categories (items 1-4).
- Page 3 — Part [III].B continued (items 5-10); Part [IV] Industry and Sector Details; Part [V].1 Branch/Division/Other Information; Part [V].2 Shareholder/Member/Partner counts; Part [V].3 Shareholder's Details for Private Companies (table header + start of rows).
- Page 4 — Part [V].4 Details of Directors; Part [VI] Bank Details; Part [VII].1 Particulars of Representative (start).
- Page 5 — Part [VII].1 continued; Part [VII].2 Spouse Bank Details; Part [VIII] Particulars of Tax Consultant/Tax Advisor; Part [IX] Information for VAT Registration (start).
- Page 6 — Part [IX] continued; Part [X] Information for PAYE Registration; Part [XI] Attachments.
- Page 7 (upper portion) — Part [XII] Declaration.

Page 7's lower portion (from "INDUSTRY CLASSIFICATION TABLE" onward) and all of pages 8-18 are a purely informational, ISIC-derived lookup reference: 21 industry sections lettered A-U (page 7), followed by ~11 pages of specific numeric activity/product codes grouped under each industry (pages 8-18). This table is referenced by Part [IV]'s own "Industry Name"/"Principal Key Activity" entries (the form's own NOTES instruct the applicant to "Use the Industry Classification table at the end of the form") but is not itself applicant-supplied data, and is excluded from `fields[]` on the same basis this registry excludes reference/lookup directories elsewhere (e.g. `zw/zimra/itf1-employment-income-return`'s regional tax office directory, `zm/pacra/company-incorporation`'s analogous classification appendices).

## Scope: office-only / computed fields excluded

- **The Industry Classification Table (page 7 lower portion through page 18)** — excluded in its entirety as a third-party reference lookup, not applicant data (see Document structure, above). Two fields (`industrySectionCode`, `principalActivityCode`) capture the applicant's own transcription of the relevant code *from* this table, consistent with how other registry schemas model a lookup-derived code field without duplicating the lookup table itself.
- **No "for office use only" box or BP-number-issuance box appears on this form** — unlike ITF1, REV 1 does not print any office-only annotation column or pre-issuance box; the entire applicant-facing portion (Parts I-XII) is applicant-supplied data (aside from Business Partner Number fields *already assigned to* a director/representative/tax consultant who is an existing taxpayer, which are included as ordinary optional string fields since they are applicant-supplied information about an existing registration, not this form's own office-assigned output).
- **No same-form computed/derived totals appear on this form** — REV 1 is a registration/particulars form, not a return; it contains no arithmetic-combination lines to exclude under GSP-0013 §7.

## Disclosed findings

1. **Part [III].A "Revenue Heads" is modelled as 38 independent boolean fields** (plus 10 further booleans for Part [III].B "Special Income Tax Categories"), rather than a single enum, since the form's own instruction — "Tick against **required** revenue heads" (plural) — and its own four-column grid of 38 separately-boxed tick items make clear that a business may need to register for more than one tax head simultaneously (e.g. Income Tax **and** VAT **and** PAYE). This registry's spec (v0.3) has no array/multi-select field type (`fieldType` enum is `string, number, integer, boolean, date, enum, file, object` — GSP-0009 composite/repeating values remains an unaccepted proposal), so per-item booleans is the only structurally available representation, consistent with precedent elsewhere in this registry for large independently-tickable checklists (e.g. `za/sars/corporate-income-tax-return-itr14-medium-large-business`'s 125 boolean fields).
2. **Part [I].2 "Type of Business" is modelled as a single-select `enum`, not booleans**, despite being printed as 17 separately-boxed tick items (numbered 3-19, continuing the section's own item numbering from "1. Nature of Applicant"/"2. Type of Business"), because these 17 categories describe mutually exclusive entity types (a business cannot simultaneously be a "Private Company" and a "Trust"), unlike the Revenue Heads grid where multiple selections are the form's own explicit intent. This mirrors this registry's own `zw/zimra/itf1-employment-income-return` precedent of modelling a tick grid as `enum` when the underlying options are mutually exclusive (e.g. that schema's `boardType`).
3. **Part [IV] "Industry and Sector Details" row 1's own printed "CODE" table cell renders as a solid black rectangle** in the rendered page-3 image, rather than as an ordinary blank writing box (row 2's "CODE" cell renders normally). This is disclosed rather than silently reconciled; `industrySectionCode` is modelled as an ordinary optional string field on the reasonable assumption that this is a rendering/print artifact in the source PDF rather than an intentional suppression of the field, but a future review of a re-issued edition of this form should re-check this cell.
4. **Part [V].3 "Shareholder's Details for Private Companies" and Part [V].4 "Details of Directors" are modelled with different cardinalities.** The Shareholder's Details table prints 3 ruled rows (confirmed via the rendered page 3/4 image) and is modelled as 3 bounded numbered slots (`shareholder1`-`shareholder3`, 5 fields each), mirroring this registry's `zm/pacra/company-incorporation` bounded-slot precedent. Section 4 ("Details of Directors"), by contrast, prints only a single set of fields beneath the instruction "attach schedule of all directors and their details as below" — modelled here as a single record (the Managing Director), with the form's own instruction directing any additional directors to an attached schedule (see `directorsIdentityAddressProofCopy` in `documents[]`) rather than further form rows.
5. **Part [VI] "Bank Details" (3 slots, 8 fields each) and Part [VII].2 "Spouse Bank Details" (3 slots, 6 fields each) share the same 3-bank-column layout but differ in which fields the source prints** — the company's own Bank Details table additionally prints "Mobile Bank/Wallet Provider" and "Cell Number for Mobile Bank/Wallet Account" columns that the Spouse Bank Details table (page 5) does not repeat. Modelled with two independent field sets (`bank1..3*` vs `spouseBank1..3*`) rather than a shared shape, matching what each table actually prints.
6. **Part [IX] "Information for VAT Registration" and Part [X] "Information for PAYE Registration" are conceptually tied to the `valueAddedTax`/`payeTax` revenue-head booleans in Part [III].A, but are deliberately left ungated (`required: false`, no `requiredWhen`)** rather than conditionally required on those booleans. Two reasons: (a) this form carries no visible mandatory-field marker anywhere in the extracted text or rendered pages (no asterisks), consistent with this registry's own precedent for un-asterisked ZIMRA sources (`zw/zimra/itf1-employment-income-return` disclosed finding #7); and (b) several of these figures (e.g. zero motor vehicles, zero exempt turnover) are legitimately absent rather than merely unfilled, so a strict `requiredWhen` gate risks rejecting a genuinely complete, valid submission. Each field's own `description` notes the section's conceptual tie to its corresponding revenue head.
7. **Part [XI] "Attachments" is modelled as 11 conditional `documents[]` entries** (plus the Part [XII] declaration attestation), gated using the source's own three-way "for whom required" split (Registered Company / Individual / Other Organizations): company-specific documents (Certificate of Incorporation, Memorandum and Articles of Association, 2-directors' identity/address proof, CR14/CR6, the Public Officer's own identity documents) are gated `requiredWhen typeOfBusiness in ["Private Company", "Public Company"]`; `nationalIdentityCopy` is gated `requiredWhen natureOfApplicant equals "Individual"`; `partnershipDeedCopy` is gated `requiredWhen typeOfBusiness equals "Partnership"`; `constitutionCopy` is gated `requiredWhen typeOfBusiness in [...]` over the remaining non-company, non-individual categories; `publicOfficerAppointmentLetter` (printed under both the Registered Company and Other Organizations categories, but not Individual) is gated `requiredWhen natureOfApplicant notEquals "Individual"`; and `currentBankStatementCopy` / `publicOfficerRepresentativeProofOfResidence`, which print under all three categories, are modelled `required: true` unconditionally. This registry's `condition` schema (§ GSP spec v0.3) supports only a single field with one operator per condition (`field`/`equals`/`notEquals`/`in`/comparison — `maxProperties: 2`), so no compound (AND-of-two-fields) gate was available; each document's gate was chosen from the single most specific supporting field.
8. **`nationalProvince` is modelled `type: string`, not `enum`**, since the form prints "National Province" as a plain blank with no list of Zimbabwe's own provinces visible anywhere on the form or in the extracted text — consistent with this registry's convention of not inventing an enum the source itself does not print.
9. **No field on this form carries a visible mandatory-field asterisk or equivalent marker.** Per this registry's own precedent for un-asterisked sources, only the fields necessary to process a registration at all are modelled `required: true`: `natureOfApplicant`, `typeOfBusiness`, `registeredName`, `dateOfIncorporationOrBirth`, `registrationNumber`, `physicalAddress`, `industryNameDescription`, `principalActivityDescription` (the Part [IV] table's own column header names this information "REQUIRED"), `declarantFullName`, `designation`, and `signatureDate`. Every other field is `required: false`, gated `requiredWhen` only where the source's own single-field branching is unambiguous (`otherBusinessTypeSpecify`).
10. **The physical signature mark itself is not separately modelled as data** — captured by the `declarationAttestation` document's own `required: true`, consistent with this registry's `zw/zimra/itf1-employment-income-return` and `bo/sin/formulario-200-iva` precedent for signature blocks; the accompanying `designation`/`signatureDate` fields are modelled as ordinary required fields since they are typed/written data distinct from the signature act.

## Conformance

3 valid mock scenarios — `valid-private-company-full-registration` (a private company registering for Income Tax, VAT, and PAYE simultaneously, exercising the shareholder/director/bank bounded slots, VAT turnover/asset figures, and PAYE headcounts); `valid-individual-sole-trader-registration` (an individual sole trader registering for Presumptive Tax – Informal Trade only, exercising the representative/spouse-bank-details fields and the false/absent path of the VAT/PAYE sections); and `valid-organisation-trust-registration` (a Trust registering for Stamp Duty and the Pension Fund special category, exercising the tax-consultant particulars) — plus 11 mutation-control fixtures (one missing statically-required field from each of `natureOfApplicant`, `typeOfBusiness`, `registeredName`, `dateOfIncorporationOrBirth`, `registrationNumber`, `physicalAddress`, `industryNameDescription`, `principalActivityDescription`, `declarantFullName`, `designation`, `signatureDate` — one per required field) and one unknown-field-rejected fixture, committed under `conformance/zw/zimra/rev1-application-for-new-registration/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 11 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 617-document registry run. `registry-index.json` regenerated via `npm run build-index` in `tools/govschema-client/`.