Trinidad and Tobago Application for Driving Permit(s)/Endorsement(s) (MOWT Form 4)

Candidate selection

GOV-4582 ("GovSchema Standard Research"). CATALOG.md's Known Gaps entry 0m banked this candidate since the GOV-4568 cycle, which opened Trinidad and Tobago as the registry's 91st jurisdiction and scouted four STRONG verticals on official .gov.tt domains (Passport, DMV, Business Formation, Taxes); Passport and Taxes were authored in the GOV-4568/GOV-4575 cycles. This cycle picks up DMV — the Ministry of Works and Transport's (MOWT) Form 4, "Application for Driving Permit(s)/Endorsement(s)" — leaving Business Formation (Companies Registry Form 1, plus a Form 6 sole-proprietor statement already confirmed image-only with no extractable text layer) as the sole remaining banked candidate.

Reaching the live source

Known Gaps entry 0m recorded the source URL with an elided path (mowt.gov.tt/MOWT/media/General/Documents/.../Application-for-Driving- Permits-Endorsement.pdf) and the note that mowt.gov.tt needs curl -k (a broken TLS certificate chain). The full path was not re-derivable from the live site's own navigation this cycle: mowt.gov.tt's Kentico-CMS- rendered HTML pages (e.g. /Services, /Divisions/Transport-Division/...) consistently returned HTTP 404 to a direct curl fetch — including with a realistic desktop User-Agent — while the static-file /MOWT/media/... path segment fetched cleanly, the same host-specific split this registry has seen before (bot-mitigated HTML shell, unmitigated document library). A web search recovered the exact live path, https://www.mowt.gov.tt/MOWT/media/General/Documents/New%20Transport%20 Division%20Forms%20-%20September%2016th%202020/Application-for-Driving- Permits-Endorsement.pdf, independently corroborated by three different result snippets (including one explicitly captioned "FORM 4 Government of the Republic of Trinidad and Tobago").

• Required curl -k (TLS certificate verification bypass) — a plain curl without it fails at the TLS handshake, matching the Known Gaps entry's own disclosed finding; a connectivity/certificate-chain characteristic of the host, not a login/CAPTCHA/WAF content gate.
• HTTP 200, Content-Type: application/pdf, 125,793 bytes — matches the byte count independently recorded when this candidate was first banked in GOV-4568, confirming the source has not changed since.
• sha256 of the retrieved bytes: 528de723f2b6cec474ffa9c26936f12cd270a7bc5a7650b8b7bdaf333f0dd5a2.
• PDF header %PDF-1.6 at byte 0, 2 pages, confirmed via pdfjs-dist's numPages.
• getFieldObjects()/getAnnotations() returned 72 named AcroForm fields across both pages (52 on page 1, 20 on page 2) — a genuine interactive form, unlike some other registry sources in this jurisdiction group.

Authority attribution

The document's own header prints "GOVERNMENT OF THE REPUBLIC OF TRINIDAD AND TOBAGO", cites "Motor Vehicles and Road Traffic Act, Chap. 48:50 Regulation 18", and is hosted under the Ministry of Works and Transport's own Transport Division document library. This schema attributes authority to the Ministry of Works and Transport (MOWT, mowt.gov.tt), the issuing ministry whose own domain hosts the form and whose Transport Division/ Licensing Authority processes driving-permit applications.

Extraction method

pdfjs-dist (vendored at /tmp/node_modules/pdfjs-dist) getTextContent() read every text item's raw string and transform x/y position on both pages, and getFieldObjects()/getAnnotations() enumerated every named AcroForm field with its rect. Field-to-label mapping was derived by cross-referencing each field's rect position against the nearest printed text at the same y-coordinate (e.g. the Classification1-Classification4 checkboxes at y=702.9 line up under "Motorcycle / Light Motor Vehicle / Heavy Motor Vehicle / Extra Heavy Motor Vehicle"; Classification5-7 at y=687.2 line up under "Omnibus / Tractor Wheel/Truck / Other" — 7 checkboxes for 7 printed options, not 8, since "Tractor Wheel/Truck" prints as one combined option rather than two). The document is plain English with clean, non-rasterized embedded fonts — the text layer extracted completely and unambiguously; no glyph-mapping or pixel-scan workaround was needed.

Document structure

Page 1: Questions 1-14, the universal core application every transaction type completes (permit type/classification/use; applicant particulars; contact information; driving-permit history; endorsements, disqualification, fitness declaration, and signature). Page 2: Question 15 (a notarized statutory declaration, required only of "Duplicate" transaction applicants, per the form's own Instructions to Applicants item 2), followed by the Instructions to Applicants themselves and a "For Official Use" box.

Scope

This v1.0.0 schema models Questions 1-14 only — the portion the form's own Instructions to Applicants (item 1) states every applicant completes regardless of transaction type. Two things are excluded, both disclosed here rather than silently dropped:

1. Question 15 ("Declaration in Respect of Application for Duplicate Driver's Permit, Taxi Driver's Licence/Badge, Motor Vehicle Licence, Conductor's Permit") — a formal statutory declaration under the Statutory Declarations Act Chap. 7:04, sworn before a Commissioner of Affidavits, required only of "Duplicate" transaction applicants (a minority of the five transaction types). Structurally it repeats the same conceptual values (the permit/licence/badge type held, and its number) across three near-identical prose blocks — "I am the holder of ___ No ___", "The said ___ No ___ was lost or stolen...", "The said ___ No ___ was destroyed..." — with the applicant expected to complete only whichever of the lost/stolen or destroyed blocks applies, a distinction the specimen does not encode as a toggleable field. Combined with its requirement of in-person notarization (a step no agent-assisted remote filer can complete), this is out of scope for v1.0.0, on the same footing as this registry's standing practice of excluding sections that require a third-party official's in-person participation (e.g. the Uganda driving-licence schema's own excluded doctor's Medical Exam section, GOV-4335) — left as disclosed open backlog for a future cycle if a documented design for the repeated-value/either-or structure is worked out.
2. The companion Form 12 ("Form of Medical Certificate for an Applicant for a Permit to Drive Motor Vehicles") — a wholly separate document (its own file, its own form number) completed entirely by a Registered Medical Practitioner based on a clinical examination (blood pressure reading, Snellen's-test visual acuity, subjective fitness judgments), not by the applicant. No agent assisting a human applicant can supply this content on the applicant's behalf; excluded outright, the same reasoning already applied to doctor-completed medical-exam content elsewhere in this registry (GOV-4335).

Within Questions 1-14, two fields (applicationDate, signatureOfApplicant) are modelled from plain printed text ("Date:" / "Signature of Applicant") even though — unlike every other field in this schema — the specimen carries no distinct AcroForm annotation at that position; both are disclosed as a finding rather than silently included as if backed by a real interactive field.

Disclosed findings and interpretation choices

1. ttPermitNumber/ttPermitIssueDate/authorisedVehicleClass are gated requiredWhen an any condition over currentlyHoldsTtPermit OR previouslyHeldTtPermit, per the form's own printed instruction, "If 'yes' to (i) or (ii) state number and date of Issue below" (Question 9(iii)) — using GSP-0013's any condition composition, since this is a genuine two-field OR, not a single-field equality gate.
2. authorisedVehicleClass is modelled as a free-text string, not the vehicleClassification enum reused — the printed Instructions to Applicants define vehicleClassification's 7 categories specifically for a new application; an applicant's existing permit (Question 9(iv)) may print a different, older classification scheme the source does not itself enumerate.
3. sex, like this registry's other Trinidad and Tobago schemas, is modelled from two independent checkbox annotations (GenderM/ GenderF), not a single radio-button field — getFieldObjects() confirms each is its own standalone widget (matching the Transaction1-5/Classification1-7/Use1-3 pattern), not a shared-parent radio group; modelled as a mutually-exclusive enum per this registry's standing practice for this pattern.
4. endorsementParticulars is modelled required: false — the form's own Question 11 asks for particulars "of any endorsement(s) ... which you held or now hold", with no accompanying yes/no gate; left blank if the applicant has none to disclose, the same convention this registry applies to analogous open-text disclosure fields elsewhere.
5. disqualificationParticulars is requiredWhen previouslyDisqualified equals true, per the form's own printed "If 'yes' give particulars" directly beneath Question 12's yes/no gate.
6. Postal (Question 8) fields are all required: false, with no requiredWhen gate — the section's own header, "Contact Information if different from (7)", is conditional by its own wording but the specimen provides no boolean toggle field to key a requiredWhen condition on; modelled as ordinary optional fields with a description documenting the condition, following this registry's lv/vid-family precedent for a printed-but-unkeyable condition.
7. **Phone fields are split into three sub-fields (residentialPhoneAreaCode/Exchange/Number and the postal* equivalents)**, matching the three distinct AcroForm text-field widgets and rect widths printed under "Phone ( ) - " (area code ~3 digits, exchange ~3 digits, number ~4 digits — confirmed via each field's own rect width in getFieldObjects()), consistent with this registry's own precedent of one schema field per printed input box rather than a single concatenated phone-number field.
8. Excluded as official-use-only, not applicant-supplied data: page 2's "For Official Use" box.

Conformance

3 valid mock scenarios — valid-first-issue-motorcycle (a first-time motorcycle applicant with no prior permit history and no postal-address override); valid-renewal-with-prior-permit (a renewal applicant exercising the currentlyHoldsTtPermit-gated ttPermitNumber/ ttPermitIssueDate/authorisedVehicleClass trio, plus a postal address different from the residential address); and valid-provisional-with- disqualification-disclosed (a provisional applicant who discloses a past disqualification, exercising disqualificationParticulars's requiredWhen gate) — plus 12 mutation-control fixtures (one missing statically-required field from each of transactionType, vehicleClassification, useType, surname, firstName, sex, placeOfBirth, dateOfBirth, nationality, residentialAddressStreet, residentialAddressCity, currentlyHoldsTtPermit, previouslyHeldTtPermit, holdsPermitElsewhere, previouslyDisqualified, physicallyMentallyFit, declarantName, applicationDate, signatureOfApplicant — 19 fixtures, one per statically required field) and one unknown-field-rejected fixture, committed under conformance/tt/mowt/driving-permit-application/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 23 fixtures: all 3 valid scenarios at 0 errors, all 19 static-required mutation controls each raising exactly 1 error, the unknown-field fixture correctly rejected, and confirmed every requiredWhen field reference (including the two any-composed conditions) resolves to a real field name (0 dangling references). Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs, individually and as part of the full registry run.