# Verification record — sz/rtd/certification-of-roadworthiness-application@1.0.0

GOV-4804 ("GovSchema Standard Research"). This cycle re-scanned `CATALOG.md` fresh: Eswatini has 3 of 6 verticals open (National ID & Civic Documents via GOV-4783; Taxes via GOV-4790; DMV via GOV-4797), with Business Formation and Visa confirmed dead ends and Passport confirmed dead end as of the GOV-4797 cycle. That same cycle authored `sz/rtd/motor-vehicle-initial-registration-application@1.0.0` (Form MVR1-MIB) from a bundled `.docx` and explicitly banked the same document's other form, ACR ("Application for Certification of Roadworthiness"), as a future DMV-vertical companion-schema candidate rather than modelling it. This is the strongest banked candidate available this cycle: the source document is already downloaded, already independently verified (byte-identical, sha256-confirmed), and already extracted with a clean, unscrambled native XML text layer — no new sourcing or extraction-method risk, only a fresh field-by-field read of the ACR-specific section.

## Reaching the live source

Re-fetched: `https://www.gov.sz/images/Works/forms/RTD%20-%20MVR1%20and%20ACR%20FORMS.docx`, HTTP 200, `Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document`, `Content-Length: 48931`, `Last-Modified: Thu, 25 Sep 2025 20:01:36 GMT`, sha256 `c2ce9f0496d346ad29eee067253bc698c0125cde82b3c0c775d8579cb1bce265` — byte-for-byte identical to the record in `sz/rtd/motor-vehicle-initial-registration-application@1.0.0`'s own VERIFICATION.md, confirming the source has not changed since that cycle. No login/CAPTCHA/WAF gate; a static asset off gov.sz's own "Works Forms" page (Ministry of Public Works and Transport section, under `/index.php/policies-regulations`).

## Extraction method

Same method as the MVR1-MIB companion schema: the `.docx` is a genuine Office Open XML zip (confirmed via Python's `zipfile` module), and `word/document.xml` was parsed with Python's stdlib `xml.etree.ElementTree`, walking every `w:p` (paragraph) and `w:tbl` (table) element in document order and reading each table row's cell text via the `w:t` text runs. This is a native, unscrambled OOXML text layer — no rendering or glyph-position recovery needed. This cycle re-ran the walk over the full document and focused on the ACR-specific section, which begins at the "ACR" heading/"APPLICATION FOR CERTIFICATION OF ROADWORTHYNESS" title (the source's own spelling) and runs to the end of the file, including a shared "Motor Vehicle Descriptions" glossary table at the very end.

## Document structure (ACR only)

- **Identification of Applicant (Person presenting the motor vehicle)**: type of identification (Traffic register no / Swazi ID / Foreign ID), identification number, country of issue (if foreign ID), surname, initials and first names (not more than 3).
- **Details of Application**: class of vehicle (bus / Goods vehicle (Excluding trailer) / Motor cycle / other); licence number and vehicle register number (if available), or a "Not allocated" checkbox; preferred language.
- **Declaration by Owner (if available)**: a single inline attestation row — "I the applicant [blank] (a) declare that all the particulars furnished by me in this form are true and correct; and (b) realise that a false declaration is punishable with a fine or one year imprisonment or both." Unlike MVR1-MIB's own two declarations, this section prints no separate role checkbox and no separate Place/Date blanks — just the one inline attestation-and-signature line.
- **FOR OFFICE USE ONLY** (two panels, both entirely excluded, RTD-staff/examiner-completed): the first covers vehicle classification/VIN, make, series name, manufacturer's model derivative, vehicle category (a lettered A–U checklist cross-referencing the trailing "Motor Vehicle Descriptions" glossary table), drive configuration, vehicle description, engine number, net power/engine capacity, fuel type, tare/gross mass, transmission, main colour, steering wheel position, odometer reading, passenger capacity, gross combination mass, axle/wheel counts, overall dimensions, wheelbase/track, gearbox/differential numbers, date of application, and the examining/data-capturing officials' name-signature-date blocks, plus the serial number and re-test number of the roadworthiness test sheet; the second is a short "Certificate of Roadworthiness" panel covering the fee and receipt number for certification.
- **Motor Vehicle Descriptions** (trailing glossary table): a reference table of vehicle-type names (e.g. "Sedan (closed top)", "Bendi bus/Bus-train", "Pick up/bakkie") grouped by the vehicle-category letters used in the office-use panel above — purely an RTD staff classification aid, not an applicant-facing field.

## Disclosed findings and interpretation choices

1. **`identificationType`'s enum values reuse `sz/rtd/motor-vehicle-initial-registration-application@1.0.0`'s own `representativeIdentificationType` values** (`traffic_registration_number`, `swazi_id`, `foreign_id`), since both fields identify an individual person for the same RTD process family and this ACR section itself prints the option cleanly as three distinct choices ("Traffic register no / Swazi ID / Foreign ID") — the same three concepts that document's own VERIFICATION.md used this ACR text to disambiguate a column-merge rendering artefact on MVR1-MIB's own middle option.
2. **No separate `role`/`place`/`date` fields are modelled for the Declaration by Owner**, unlike MVR1-MIB's two declarations. The source itself prints only a single inline row ("I the applicant [blank] (a) declare … (b) realise …") with no separate proxy/representative role checkbox and no separate Place/Date blanks following it — consistent with the applicant here being a single natural person, not an organisation with a proxy/representative structure. Modelled as a single `documents[]` "attestation" category entry (statement text drawn directly from the source's own declaration prose), per this registry's established convention of using `documents[]` whenever a genuine attestation statement accompanies a signature line, rather than a bare, unaccompanied signature blank (cf. `sz/ebc/special-voting-application`'s own disclosed choice of the opposite convention for its own bare signature line, and `sz/rtd/motor-vehicle-initial-registration-application`'s own use of this same `documents[]` convention for its two declarations).
3. **`licenceNumber`, `vehicleRegisterNumber`, and `licenceNotAllocated` are each modelled as independently optional, not gated by a `requiredWhen`.** The source prints "Licence number and vehicle register[,] Number (if available)" immediately followed by a "Not allocated" checkbox and the word "Or", read as the applicant choosing directly between supplying a number or ticking the box — the same either/or pattern as `sz/rtd/motor-vehicle-initial-registration-application@1.0.0`'s own disclosed choice for its `noOdometer`/`odometerReadingKm` pair, and for the same reason: no declared boolean field exists in the source for this schema to safely condition a `requiredWhen` gate on.
4. **`vehicleClass`'s "Goods vehicle (Excluding trailer)" option is modelled as `goods_vehicle_excluding_trailer`**, preserving the source's own explicit trailer exclusion in the enum value itself rather than truncating it to a generic "goods_vehicle", since the source's separate office-use "Vehicle category" checklist (excluded from this schema) distinguishes trailers as their own category and this applicant-facing field's own parenthetical is the only place that distinction is disclosed to the applicant.
5. **The entire "FOR OFFICE USE ONLY" panel(s) and the trailing "Motor Vehicle Descriptions" glossary table are excluded**, per this registry's standing convention of modelling only the applicant-facing portion of a mixed applicant/agency form — here doubly so, since roadworthiness classification, testing, and certification are inherently post-submission, examiner-performed steps, not data the applicant supplies when filing the application.
6. **`initialsAndFirstNames` and `surname` are capped at `maxLength: 100`**, matching this registry's general free-text-name convention rather than the source's own blank-cell count (which varies by table-column width and is not a meaningful character limit).

## Conformance

A mock test run was completed with valid example data before authoring the conformance fixtures below, exercising the full applicant-facing flow: a Swazi-ID-identified applicant (Thabo Dlamini, ID 8501015800087) presenting a "bus" for roadworthiness certification with an already-allocated licence number (SD 4521 BB) and vehicle register number (available), preferred language English, and the Declaration by Owner attestation accepted — every field validates against its own `validation` block (enum membership, `maxLength` bounds) with no rejections. A second scenario exercises the `requiredWhen` gate with a foreign-ID-identified applicant (South African passport holder, country of issue "South Africa") and the "Not allocated" licence path (no `licenceNumber`/`vehicleRegisterNumber` supplied).

10 mock scenarios exercised via an ephemeral, from-scratch conformance checker (deriving required/requiredWhen rules directly from this schema's own `fields[]`, discarded after use, not committed): 2 positive scenarios (the Swazi-ID/bus/allocated-licence scenario and the foreign-ID/not-allocated-licence scenario above), 1 negative control (`countryOfIssue` omitted while `identificationType` is `foreign_id`, confirming the `requiredWhen` gate fires), 1 unknown-field-rejected fixture, and all 6 unconditionally `required: true` fields/documents (`identificationType`, `identificationNumber`, `surname`, `initialsAndFirstNames`, `vehicleClass`, plus the `declarationByApplicant` document) individually mutated to absent against the first positive scenario, each confirmed to raise exactly 1 error. All 10 passed. Validated clean with `node tools/validate.mjs` and `node tools/validate-ajv.mjs`, individually (1/1) and as part of the full registry run (664/664). `registry-index.json` regenerated via `npm run build-index` in `tools/govschema-client/`.