Dubai Vehicle Registration Renewal (Renew Vehicle Ownership)

This file is the source-review record for this document version, per the manual-source-review-v1 practice. It documents the provenance of the published fields and flow and states the current verification claim honestly.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-06

The document was derived from direct visual reading of RTA's own screenshot-driven user manual, fetched directly from rta.ae with no login/CAPTCHA/WAF gate. It remains draft, not verified, pending an independent second reviewer's field-by-field pass — several fields in this document have no legible on-screen label anywhere in the source at any resolution tried (see "What was inferred" below), making this a weaker starting point than most manual-source-review-v1 documents in this registry, and it is flagged as such.

Why this document exists

This is a standing GovSchema Standard Research cycle (GOV-1512). CATALOG.md's own "Known Gaps" section (as of GOV-1474, 2026-07-06) named the UAE's DMV vertical as its strongest remaining open candidate: "RTA's 'Vehicle Renewal User Guide' is a strong, field-rich candidate but only confirmed via a third-party mirror, not the current rta.ae URL." This cycle re-searched for that guide and instead found a different, official, first-party PDF hosted directly on rta.ae itself — RTA's own April-2018 "Renew Vehicle Ownership User Manual" — resolving the exact provenance gap the prior cycle's note flagged. This opens the UAE's fourth vertical (DMV), alongside its existing Taxes, Visa, and National ID & Civic Documents schemas.

Source examined

• Document (id, version): ae/rta/vehicle-registration-renewal / 1.0.0
• Spec version: GovSchema 0.3.0
• Authority: Roads and Transport Authority (RTA), Dubai, United Arab Emirates
• Primary source URL: https://www.rta.ae/links/lic-services/links/Renew-Vehicle-Ownership.pdf ("Renew Vehicle Ownership User Manual", April 2018 — a 20-page PDF: 10 English pages followed by 10 mirrored Arabic pages of the same content)
• Also located, not used as primary source: a longer, more granular "Vehicle Renewal User Guide Roads & Transport Authority Version 1.0" (23 pages) hosted at professionallawyer.me/blog/wp-content/uploads/2021/01/Vehicle-Renewal.pdf — this is very likely the same document GOV-1474's own research cycle found (its catalog note describes "a 24-page, 68-screenshot 'Vehicle Renewal User Guide'"), still only reachable via this third-party mirror, not a live rta.ae URL, in this cycle's own search as well. The shorter, official, first-party rta.ae-hosted manual was used instead specifically because it resolves the exact provenance weakness the prior cycle flagged, even though it documents a narrower/older UI capture with fewer legible field labels — see "What was inferred" below for where this trade-off shows up.
• Located via: web search for RTA vehicle renewal service guide PDFs, cross-checked with curl -I against both candidate URLs before download.
• Retrieved / reviewed: 2026-07-06
• Reviewer: GovSchema Engineering (initial authoring source-review)

Access and extraction method

https://www.rta.ae/links/lic-services/links/Renew-Vehicle-Ownership.pdf returned HTTP 200 directly (confirmed via both curl -I and a full download, 1.9 MB, Last-Modified: Thu, 02 Aug 2018), no login gate, no CAPTCHA, no WAF block — a materially stronger provenance chain than the third-party-mirror-only finding of the prior AE DMV screening (GOV-1474).

The PDF carries a genuine (non-scanned) text layer, extracted via pdfjs-dist, but that text layer is narrative step captions only ("Click the Confirm button", "Enter your 'Delivery address' details") — the actual on-screen field labels are legible only inside the manual's embedded UI screenshots, which the text layer does not reproduce. Each of the 10 English pages was therefore rendered to a high-resolution PNG (pdfjs-dist + node-canvas, scale factor 2.5-6.0x depending on the region) and read visually, cropping to specific screenshot regions at up to 6x native PDF scale where the base render was still too small to read (the "Delivery Contact Information" block in particular — see below).

What was confirmed directly (from the source's embedded screenshots)

• Step 1 vehicle/fee display: Model information (plate number, model details, vehicle category, expiry), Insurance information (company, number, type, valid-until), Vehicle test information (test center, date, result), Mortgage Information (name, reference, date), and a Fee Summary (Total Service Fees Due, Total Fines Due, Total amount due excluding delivery) — all confirmed present, all read-only/system-displayed (see "What was deliberately NOT modelled").
• The exact "Optional extras" wording: "Would you like to change your plate number?" / "Would you like to change your plate design?", each with its own registration-fee-cost consequence (an unspecified add-on amount for plate number; an explicit "400 AED" for plate design) — both directly legible.
• The exact "Select plate style — Front / Back" structure: Front offers 3 radio-selectable thumbnails (confirmed via a 6x-scale crop spanning the full row), the third one captioned "(Luxury plate size)"; Back offers 2 — confirmed by locating the screenshot's own right-hand border and finding no further option beyond it.
• The exact "Choose delivery method" three-way split (Courier Delivery to your door — 20 AED/package, 7-10 days; Collection from RTA office — no fee, ~7 days; Collection from kiosk — no fee, 7-10 days depending on kiosk), each fee/timing figure read directly off the Step 9 screenshot.
• The exact "Delivery Address" field labels and mandatory markers for the courier path: "Contact Name*", "Emirate:*", "Area:*", "Address Line 1*", "Address Line 2*", all under the source's own "Fields marked with (*) are mandatory" caption — confirmed at 6x scale (page07_crop_courier.png equivalent render). Both address lines carry an asterisk in this source, unlike most renewal schemas elsewhere in this registry where a second address line is optional.
• No date-selection control on the kiosk path: Step 12's screenshot ("Collection from kiosk") shows a kiosk-location pick list, a map, and "Delivery Contact Information" only — no delivery/collection date field, unlike Steps 10 (courier) and 11 (RTA office), which both show one. This is corroborated by Step 9's own kiosk info tile text, "7-10 days depending on kiosk" (a range, not a chosen date).
• A single payment channel: Step 13's Confirm screen shows only one radio option, "E-Payment" — there is no genuine payment-method choice to model (see "What was deliberately NOT modelled").
• The Interim Vehicle Registration Notice and payment receipt (Steps 14-16) are RTA-generated outputs following successful payment, confirmed via their own screenshots, not applicant-input data.

What was inferred (not independently confirmed) and why

1. mobileNumber, landlineNumber, poBoxNumber, email, confirmEmail — no legible field labels. The "Delivery Contact Information" block (Steps 10, 11, and 12 all show the identical block) displays only pre-filled sample values with no visible placeholder/label text at any render resolution tried, up to 6x native PDF scale — this is a genuine limitation of the source screenshot's own resolution, not a rendering artifact (re-confirmed by cropping progressively tighter regions and observing the blur does not resolve into legible text). The five fields modelled are inferred from the shape of the three numeric sample values (0509558138 — a 10-digit UAE mobile number, 05 prefix; 026565656 — a 9-digit landline number with a 02 [Dubai] area code; 5454 — a short standalone numeric value, inferred as a P.O. Box number given UAE addresses' common reliance on P.O. Box delivery) and the two adjacent, identically-formatted email-shaped values (inferred as an email/confirm-email retype pair). This inference is corroborated, independently, by a WebSearch result summarizing this same manual's content during this cycle's own research, which paraphrased the block as "email address (typed and re-entered)" — but that paraphrase is itself a third-party summary, not a second independent visual read, so it is corroborating rather than dispositive. **This is the weakest-sourced part of this document; a reviewer with a native-resolution or live capture of this screen should confirm or correct these five field names and which of required: true (mobileNumber, email, confirmEmail) vs. required: false (landlineNumber, poBoxNumber) is actually enforced by the live wizard — the source's own "Fields marked with () are mandatory" caption is not legible next to this specific block, unlike the Delivery Address block directly above it.*
2. plateStyleFront / plateStyleBack enum values. The three (Front) and two (Back) style thumbnails have no adjacent text captions in the source — each is a plate-graphic image only. Values (bordered_standard, bilingual_stacked, luxury_size) are this document's own descriptive naming of what is visually shown (a black-bordered single-line style; an unbordered, two-language stacked style; a physically larger plate for the Front-only third option), not verbatim source labels. A reviewer with a live render of this screen (where hovering/selecting a thumbnail may reveal a tooltip or caption) should confirm or rename these values.
3. emirate enum (7 values). The dropdown's own rendered option list is not visible in the source screenshot (only the placeholder text "Emirate:*"). The 7 values used are the United Arab Emirates' complete, externally stable, definitionally closed set of emirates (Abu Dhabi, Dubai, Sharjah, Ajman, Umm Al Quwain, Ras Al Khaimah, Fujairah) — this is treated differently from an assumed application-specific catalog (like area, collectionOfficeLocation, or kioskLocation below, all left as open strings) because the value set itself is a fixed external fact, not something RTA could plausibly define more narrowly or broadly.
4. area, collectionOfficeLocation, kioskLocation modelled as open strings. Each is a dependent/dynamic pick list (area-per-emirate; the RTA office directory; the kiosk directory) shown in the source with only one example value each ("Area:*" placeholder only; "Delivery Center - Diera Licensing"; "kiosk Deira Customer Service Center") — consistent with this registry's existing practice of not inventing an unsourced full option list (e.g. ph/comelec/overseas-voter-registration's registeredCityMunicipality, several mx/semovi/alta-vehiculo-foraneo dropdowns).
5. plateNumber modelled as an identifying field. The applicant selects an existing vehicle from their authenticated "My Vehicles" list rather than typing a plate number into a text box — modelled the same way sg/lta/road-tax-renewal's vehicleRegistrationNumber is: as the identifying value for which vehicle this transaction applies to, even though the live UI captures it via selection rather than free text entry.
6. No repeating/array field type (GSP-0009) needed. Not applicable — no repeating structure was found in the field inventory (a single vehicle, single delivery/collection detail block per transaction).

What was deliberately NOT modelled (and why)

1. Login and vehicle selection from the "My Vehicles" dashboard (Steps 1-4). A pre-existing authenticated RTA account session, not renewal-transaction data — consistent with how this registry excludes the login/account step elsewhere (e.g. ae/icp/emirates-id-replacement's Smart App login).
2. Vehicle insurance / technical inspection / mortgage-redemption status (the "Insurance information", "Vehicle test information", and "Mortgage Information" blocks on the Step 7 screenshot). These are read-only, system-displayed from RTA's own vehicle record and checked automatically before the "Vehicle Renewal" button is even shown to the applicant — the manual's own "Why Can't I Proceed with the Service?" section confirms this ("If you have no valid Insurance Details for the selected vehicle" / "no valid Test Details") is a gate the system enforces, not a declaration the applicant makes in this transaction. This differs from sg/lta/road-tax-renewal's modelling of equivalent prerequisites as applicant-declared eligibility booleans — that document was authored from a guidance page with no UI capture available, so declaration was the only modellable proxy; here, an actual screen capture shows these values are system-supplied, not applicant-entered, so no corresponding fields are modelled.
3. The broader vehicle-ownership eligibility statement ("UAE nationals, or GCC nationals, or Residency in UAE") from the "Requirements to Renew Vehicle Ownership" page. This describes who may hold an RTA account and register a vehicle in Dubai at all — an account-level precondition, not a field collected during this specific renewal transaction.
4. The plate-selection sub-flow behind changePlateNumber. Choosing to "save your selection plate" cross-references a separate RTA service ("Buy Plate"/"Request Plate", visible as menu items on the Licensing Services dashboard in Step 4's screenshot) for reserving/purchasing a specific plate combination before this renewal transaction. This document models only the boolean opt-in and its fee consequence, not that separate plate-selection service's own field-by-field flow.
5. paymentMethod. The Step 13 Confirm/Pay screen shows exactly one radio option, "E-Payment" — with no second value to distinguish, modelling it as a field would add no information; the fee itself is captured as the renewalFeePayment document instead.
6. RTA-generated output documents: the payment receipt (Step 14, "Your payment has been submitted", showing a Request Reference Number) and the Interim Vehicle Registration Notice (Step 16, a two-tab "Registration Card Replacement" / "Interim License" printable document). Both are system-generated confirmations produced after a successful transaction, not applicant-submitted input — consistent with how this registry excludes generated receipts/certificates elsewhere (e.g. mx/sre/passport-application excludes the consular office's internal processing checklist).

Path to a verified claim (next step)

1. Obtain a live or higher-resolution capture of the "Delivery Contact Information" block (Steps 10-12) to confirm or correct the five inferred field names/requiredness in item 1 above — this is the single highest-value next step for this document.
2. Confirm or rename the plateStyleFront/plateStyleBack enum values (item 2) against a live render, ideally one where hovering/selecting each thumbnail reveals a caption.
3. Confirm the emirate field's dropdown against a live render (item 3), even though the 7-value set itself is not expected to change.
4. Cross-check this document against the longer, more granular "Vehicle Renewal User Guide Version 1.0" (23 pages) found at professionallawyer.me this cycle — if a future cycle locates that guide's own first-party rta.ae URL, re-verify this document against it, since it very likely resolves several of the "not legible" gaps above.
5. Confirm RTA has not since revised this service's screen flow (the primary source is dated April 2018).

Mock test run (phase 4)

A throwaway Node script (not committed) built three mock scenarios against this document's fields/steps, one per deliveryMethod branch, and checked every populated field against its type/validation constraint and every requiredWhen-gated field's effective requiredness given each mock's own answers:

• Courier scenario: deliveryMethod: courier_to_door, changePlateDesign: true — correctly required deliveryDate, contactName, emirate, area, addressLine1, addressLine2, plateStyleFront, plateStyleBack; left collectionOfficeLocation, collectionDate, kioskLocation not required.
• RTA office scenario: deliveryMethod: rta_office_collection, changePlateDesign: false — correctly required collectionOfficeLocation, collectionDate; correctly left plateStyleFront/plateStyleBack not required (changePlateDesign false); correctly left the courier-only address fields not required.
• Kiosk scenario: deliveryMethod: kiosk_collection — correctly required kioskLocation only, no date field, matching the source's own missing date-selection control for this path.

All three scenarios reached the terminal pay step with mobileNumber, email, and confirmEmail (unconditionally required) present and matching their pattern constraints. Result: PASS, 19 fields modelled across 5 flow steps, 1 document modelled. This is a data-shape dry run only — it does not constitute execution of the live system: the live wizard requires an authenticated RTA account and a real Dubai-registered vehicle to reach any of these screens, which this cycle deliberately did not attempt to obtain or use, consistent with this registry's practice of not exercising real citizen accounts or holding real government resources (the same posture applied to scarce appointment slots in ph/dfa/passport-application, GOV-1497). See conformance/ae/rta/vehicle-registration-renewal/1.0.0/ for the committed mock application packet (the courier scenario).

Re-verification

Per the practice's Cadence, nextReviewBy is set to 2027-01-06 (~6 months). Re-check the source, and confirm no structural change to the live wizard or this manual's field set, on or before that date and on any source.url change.