Eswatini — Application for Certification of Roadworthiness (Form ACR)

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