Bangladesh Motor Vehicle Registration Application (BRTA "Form of Application for the Registration of Motor Vehicle")

This file is the source-review record for this document version, per the manual-source-review-v1 practice.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-13
• maturity.level: structural-reference

This is GovSchema Standard Research cycle GOV-2644. It opens Bangladesh's DMV vertical (2 of 6), using the Bangladesh Road Transport Authority's (BRTA) "Form of Application for the Registration of Motor Vehicle". Bangladesh currently has only its Taxes vertical published (bd/nbr/individual-income-tax-return-form-it-11ga).

Source verification (independently re-derived, not copied from the task briefing)

• Form page: https://brta.gov.bd/pages/forms/6922d9b3933eb65569dff7ec — independently re-fetched this cycle, HTTP 200.
• PDF source: https://objectstorage.ap-dcc-gazipur-1.oraclecloud15.com/n/axvjbnqprylg/b/V2Ministry/o/office-brta/2024/12/d4bc1c3b395d434f87240284abeb807a.pdf — fetched independently this cycle via curl -sk -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36" (the host's TLS chain fails default certificate verification, consistent with the task briefing's note):
  • HTTP 200, Content-Type: application/pdf, 71911 bytes.
  • sha256: 96d0e10bcb05988ec2cb31419656121440b5602353493c33e91b38d412721223 (computed via sha256sum on the freshly-downloaded file).
  • All three figures were independently re-derived this cycle and match the prior scouting pass's reported figures exactly.
• Parsed with pdfjs-dist@6 (legacy build), installed in a scratch directory (not a repo dependency):
  • getFieldObjects() returned null — no AcroForm widgets, a plain print-and-fill document, not a fillable form. This matches the prior scouting note's characterization and also matches this cycle's independent screening of the driving-licence variant on the same BRTA forms page, which was confirmed a dead end (garbled/generic AcroForm field names, no legible text layer) and not re-attempted here — only this vehicle-registration form was in scope.
  • getTextContent() returned a full, clean English text layer across all 3 pages, 4801 characters total — matching the prior pass's reported ~4,801 exactly.
  • Every field below was extracted directly from this text layer.
  • Additionally rendered all 3 pages to PNG at 3x scale via pdfjs-dist + @napi-rs/canvas and visually inspected the images, specifically to check for printed checkbox/option lists next to the five items the prior scouting pass flagged as possible enums (Sex, Owner type, Vehicle or trailer, Class of vehicle, Fuel used). None of the five had any printed checkbox, radio mark, or enumerated option list anywhere on the rendered page — each is simply a label followed by a blank colon-terminated line, confirmed visually as well as textually.

Deviation from the task briefing, disclosed

Given this task's own instruction to identify enum values directly from the form's own text layer, and finding no printed option list for any of the five candidate fields, this schema models ownerType, ownerSex, classOfVehicle, and fuelUsed as free-text string, not enum — deviating from the prior scouting pass's suggestion that these might be enums. This is consistent with this registry's own established th/dlt/vehicle-registration-application precedent (its vehicleType, engineType, and vehicleUseCategory are likewise modeled as free-text because "the source prints each as a blank line with no enumerated options to choose from"). The sole exception is vehicleOrTrailer, modeled as a 2-value enum (vehicle / trailer) — not because a checkbox exists, but because the printed label itself names exactly two mutually exclusive options ("Vehicle or trailer").

Full field-numbering cross-check (own extraction vs. prior scouting note)

Own extraction (pdfjs-dist getTextContent(), cross-checked against the rendered page images) confirms the prior pass's numbering almost exactly:

• Section II (owner information), items 1-13: Name of owner, Date of birth, Father/Husband, Nationality, Sex, Guardian's name, Owner's Address (one only), Phone No., PO/Bank, Joint owner, Owner type, Hire, Hire purchase.
• Section III (owner information / vehicle specification), items 14-31: Vehicle or trailer, Class of vehicle (14a), Prev. Regn. No. (15), Maker's name (15a), Type of body, Maker's Country, Color (cabin/body), Year of manufacture, Number of cylinders, Chassis number, Engine number, Fuel used, Horse power, RPM, Cubic capacity, Seats (incl. driver), No. of Standee, Wheel base, Unladen weight (kg), Maximum laden/train weight (kg).
• Section IV (additional information for transport vehicle), items 32-38: item 32 is printed verbatim as "No. of types :" (not "No. of tyres" — see the disclosed numberOfTyres field description for why this is almost certainly a source-side wording quirk for tyre count, given its position immediately before "Tyres size" and "No. of axle"), Tyres size, No. of axle, Maximum axle weight (kg) broken into a) Front axle (1)(2), b) Central axle (1)(2)(3), c) Rear axle (1)(2)(3), Dimensions (mm): a) Overall length b) Overall width c) Overall height, Overhangs (%): a) Front b) Rear c) Other, and a vehicle-dimension-drawing attachment line.
• Section V (page 2), items 39-41: Hire purchase/hypothecation information (Name, Date, Address), Insurance information (Policy no., Type of policy, Insurer's name & address, Date of expiry — printed with a duplicated "b)" label for both "Type of policy" and "Date of expiry", disclosed on the insurancePolicyExpiryDate field), Joint owner information (two columns, "a)"/"b)", each with Name and Father/Husband).
• Section VI (page 2), items 42-46: Declaration by owner, Registered dealer's certificate, certificate by the Inspector of Motor Vehicles, Registration Status, Fees and Tax Accounts — see scoping decision below.
• Page 3, "Owner's Particulars/Specimen Signature": a 13-item duplicate identity/vehicle-ID card (Name, Father/Husband, Address, Sex, Phone No., Nationality, Date of Birth, Guardian's Name, Chassis No., Engine No., Year of Mfg., Prev. Regn. No., P.O./Bank), a "3 Copies Photograph" + "Stamp Size Color Pic" box, and 4 specimen-signature boxes.

This confirms the prior scouting pass's field list essentially verbatim; the only correction is the exact printed wording of item 32 ("No. of types", not "No. of tyres") and the discovery that items 39-41 are genuinely applicant-supplied particulars (not office-only), which are modeled as in-scope fields below.

Scoping decision

In scope (63 fields[] + 3 documents[] entries)

All of Section II (owner information, items 1-13), Section III (vehicle identification and technical specification, items 14-31), Section IV (transport-vehicle-specific technical detail, items 32-38, modeled as optional given no dedicated boolean gates whether a vehicle is a "transport vehicle"), and Section V (hire-purchase/hypothecation, insurance, and joint-owner particulars, items 39-41) — all owner-supplied content. Item 38's drawing-attachment line is modeled as a documents[] entry (vehicleDimensionDrawing) plus two companion fields carrying the approver name and date. Item 42 (Declaration by owner) is modeled as a documents[] attestation entry (ownerDeclarationAttestation), mirroring this jurisdiction's own bd/nbr/individual-income-tax-return-form-it-11ga precedent for modeling a sworn owner declaration as an attestation document rather than a plain field. Page 3's 3-copies-photograph requirement is retained as a documents[] entry (ownerPhotograph).

Bounded repeating structures, modeled as flat numbered-suffix fields (per this registry's own established child1/child2-style convention, e.g. ng/firs/fct-irs-personal-income-tax-return-form-a), not unbounded arrays:

• Axle weights (item 35): frontAxleWeightKg1/2 (source prints 2 blanks), centralAxleWeightKg1/2/3 (3 blanks), rearAxleWeightKg1/ 2/3 (3 blanks) — 8 fields total, each bound exactly to the source's own printed (1) (2) (3) markers, not an invented cap.
• Joint owner (item 41): jointOwner1Name/jointOwner1FatherOrHusbandName (requiredWhen jointOwner == true) and jointOwner2Name/ jointOwner2FatherOrHusbandName (unconditionally optional, since the source's single jointOwner boolean does not further distinguish whether a second joint owner is mandatory given a first) — matching the source's own two-column "a)"/"b)" layout exactly.

Out of scope, disclosed

• Section-1's office-only intake box (Regn No., Issue No., Diary No., Customer ID, District, Vehicle ID, Veh. Description, Call non date, Refusal date/Code/Refused by, P.O./Bank, Index, Remarks, Index No.) — completed by the BRTA office at intake, not the applicant, per the source's own "To be filled in by the office" heading immediately above it.
• Section VI, items 43-46 — Registered dealer's certificate (signed by the selling dealer, not the applicant), certificate by the Inspector of Motor Vehicles (office-generated after in-person inspection), Registration Status (the registering authority's own adjudication), and Fees and Tax Accounts (a payment-receipt line completed at the counter). None of these four is applicant-supplied input.
• Page 3's duplicate identity/vehicle-ID data and specimen-signature/stamp boxes — every one of its 13 numbered items (Name, Father/Husband, Address, Sex, Phone No., Nationality, Date of Birth, Guardian's Name, Chassis No., Engine No., Year of Mfg., Prev. Regn. No., P.O./Bank) duplicates a field already modeled in Section II/III above; the 4 specimen-signature boxes and the "Stamp Size Color Pic" box are wet-ink/ physical-artifact placeholders with no fillable data content. Only the page's "3 Copies Photograph" requirement is retained, as the ownerPhotograph document entry, since it is a genuine supporting-artifact requirement not captured anywhere else on the form.
• No signature-only lines modeled as fields. "Signature of owner" (item 42(a), 43, 46) and "Signature of dealing assistant"/"Counter signature by the registering authority" (item 46) are wet-ink lines with no adjacent fillable date sub-line of their own (each date is already captured separately, e.g. hirePurchaseAgreementDate, or belongs to an excluded office-only block) — consistent with this registry's established convention (th/dlt/vehicle-registration-application's own precedent) of not inventing a field for a bare signature line.
• Section IV (items 32-38) has no dedicated "is this a transport vehicle?" boolean gate on the form itself, so all of Section IV's fields are modeled as optional rather than encoding a fabricated requiredWhen condition against a field the source does not provide.
• Insurance particulars (item 40) have no dedicated boolean gate either, unlike hirePurchase and jointOwner (items 13 and 10, each printed as their own labeled line), so insurancePolicyNumber/insurancePolicyType/ insurerNameAndAddress/insurancePolicyExpiryDate are left optional.
• ownerType, ownerSex, classOfVehicle, fuelUsed modeled as free-text string, not enum — see "Deviation from the task briefing" above.
• numberOfTyres's label is the source's own verbatim "No. of types" wording, not silently corrected to "tyres" — see the field's own description and the field-numbering cross-check above.

Conformance run

Two hand-authored valid fixtures under conformance/bd/brta/motor-vehicle-registration-application/1.0.0/:

• valid-private-individual-owner.json — a private individual owner registering a new sedan-class vehicle, no hire purchase, no joint owner, no transport-vehicle-specific data populated (Section IV left absent, all optional).
• valid-company-hire-purchase-owner.json — a company/organization owner with hirePurchase: true (exercising the Section V hire-purchase requiredWhen fields), jointOwner: true (exercising both joint-owner requiredWhen fields plus the optional second joint-owner slot), and a fully populated Section IV transport-vehicle technical block (tyres, all 8 axle-weight fields, dimensions, overhangs, and the vehicleDimensionDrawing document with its two companion fields).

Both were checked with a from-scratch Node conformance checker (check_conformance.mjs, not committed — a disposable script, per this registry's own established practice) validating required/requiredWhen/type/validation.{enum,minimum,maximum,pattern, minLength,maxLength} directly against spec/v0.3/SPEC.md's own rules:

`` $ node check_conformance.mjs schema.json \ valid-private-individual-owner.json \ valid-company-hire-purchase-owner.json valid-private-individual-owner.json: 0 error(s) valid-company-hire-purchase-owner.json: 0 error(s) ``

Five mutation-control fixtures, each isolated to raise exactly one error:

• mutation-control-missing-owner-name.json — drops ownerName (a static required: true field) from the private-individual valid fixture.
• mutation-control-missing-chassis-number.json — drops chassisNumber.
• mutation-control-invalid-enum-vehicle-or-trailer.json — sets vehicleOrTrailer to "motorcycle", not one of the enum's 2 values.
• mutation-control-invalid-type-year-of-manufacture.json — sets yearOfManufacture to the string "twenty twenty-five" instead of an integer.
• mutation-control-missing-hire-purchase-financier-name.json — starts from the company/hire-purchase valid fixture and drops only hirePurchaseFinancierName, isolating the requiredWhen violation (since hirePurchase is still true in that fixture).

`` $ node check_conformance.mjs schema.json \ mutation-control-missing-owner-name.json \ mutation-control-missing-chassis-number.json \ mutation-control-invalid-enum-vehicle-or-trailer.json \ mutation-control-invalid-type-year-of-manufacture.json \ mutation-control-missing-hire-purchase-financier-name.json mutation-control-missing-owner-name.json: 1 error(s) - ownerName: required but missing mutation-control-missing-chassis-number.json: 1 error(s) - chassisNumber: required but missing mutation-control-invalid-enum-vehicle-or-trailer.json: 1 error(s) - vehicleOrTrailer: value "motorcycle" not in enum ["vehicle","trailer"] mutation-control-invalid-type-year-of-manufacture.json: 1 error(s) - yearOfManufacture: expected type integer, got "twenty twenty-five" mutation-control-missing-hire-purchase-financier-name.json: 1 error(s) - hirePurchaseFinancierName: required but missing ``

All five negative controls raised exactly one error each, and neither valid scenario raised an unexpected error.

Both registry validators were run against the schema document and pass:

``` $ node tools/validate.mjs registry/bd/brta/motor-vehicle-registration-application/1.0.0/schema.json ok registry/bd/brta/motor-vehicle-registration-application/1.0.0/schema.json 1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/bd/brta/motor-vehicle-registration-application/1.0.0/schema.json ok registry/bd/brta/motor-vehicle-registration-application/1.0.0/schema.json [v0.3] 1/1 document(s) validated against the meta-schema (ajv 2020-12). ```

(tools/node_modules did not have ajv present in this worktree at the start of this cycle; ran npm ci --include=dev inside tools/ first, per this registry's own known NODE_ENV=production gotcha.)

tools/govschema-client/registry-index.json was regenerated via npm run build-index inside tools/govschema-client/.

Scope and jurisdiction notes

• Opens Bangladesh's DMV vertical (2 of 6); Taxes is already published. National ID, Passport, Business Formation, and Visa remain screened/backlog per prior cycles.
• jurisdiction.level is national — BRTA is Bangladesh's national road transport authority.
• process.type is registration; process.language is en — the source PDF's own text layer is entirely in English (unlike bd/nbr/individual-income-tax-return-form-it-11ga, whose 2023 edition is also English; Bangladesh's official-language forms typically have separate Bengali editions this schema does not address).
• The driving-licence variant on the same BRTA forms page was screened and confirmed a dead end this cycle (garbled/generic AcroForm field names, no legible text layer) and is not re-attempted here; only the vehicle registration form was in scope for GOV-2644.
• Companion candidates for a future cycle: Bangladesh's remaining National ID, Passport, Business Formation, and Visa verticals, still screened/backlog; and, if a future cycle wants to model government-generated certificate/inspection content, the Section VI dealer/inspector certificates excluded here (an open scope question, not resolved in this cycle, mirroring similar unresolved questions raised in th/dbd/boj-1 and th/dlt/vehicle-registration-application's own VERIFICATION.md files).

Re-verification

Per the practice's cadence, nextReviewBy is set to 2027-01-13 (6 months). A future review should prioritize: (1) confirming the object-storage-hosted PDF has not been silently replaced with a revised edition (no Last-Modified header was captured this cycle to anchor a future diff, since the header set returned by this object-storage host does not include one); (2) re-attempting the BRTA forms page directly, in case a fillable/AcroForm edition is published in the future; (3) whether a future cycle wants to model Section VI's dealer/inspector certificates as separate government-generated-content schemas.