Romania — Vehicle Registration / Transfer / Provisional-Deregistration Request (Cerere Operațiune Înmatriculări, Transcrieri, Radieri Provizorii)

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-2804, opening Romania's DMV vertical (2 of 6), following Taxes (ro/anaf/declaratie-unica-activitati-independente, GOV-2797, 50th jurisdiction).

Duplicate-concurrent-run check

Checked git branch -a | grep -i ro-dgpci, git branch -a | grep -i dgpci, and git log --all --oneline | grep -i "ro/dgpci" before starting — none found an existing ro/dgpci branch, commit, or PR, so no reconciliation was needed this cycle.

Source verification — independently re-fetched, not trusted from the task brief alone

• PDF source: https://db.prefectura.mai.gov.ro/wp-content/uploads/sites/43/2023/07/CERERE-OPERATIUNE-INMATRICULARI-TRANSCRIERI-RADIERI-PROVIZORII.pdf — re-fetched via curl -sL, independently of the task brief's own claimed byte size/hash:
  • HTTP 200, Content-Type: application/pdf, 201,447 bytes (matches the task brief's figure byte-for-byte).
  • sha256: 4669a2bd525ae3b3d3efe551c0ddea17e4e4e41bb51c13e52a3a8c8dc60ecc8e (computed via sha256sum on the independently re-fetched file).
  • File starts %PDF-1.7; object 1's dictionary contains /AcroForm 150 0 R /Pages 2 0 R ... — a genuine fillable PDF, confirmed independently (not just trusted from the brief's own byte-regex claim).
  • Last-Modified: Thu, 13 Jul 2023 11:47:03 GMT (per response headers), i.e. this specimen has been stable/unauthenticated at this URL for three years.

Agency-code decision: why dgpci, not db/prefectura/spcrpciv

The hosting domain, db.prefectura.mai.gov.ro, belongs to the Instituția Prefectului Județul Dâmbovița (the Dâmbovița County Prefecture; "db" is Dâmbovița's own county abbreviation — confirmed via the page's own <title>Instituția Prefectului – JUDEȚUL DÂMBOVIȚA</title>). The form itself is listed on that site under "Formulare tipizate gestionate la nivelul SPCRPCIV Dâmbovița" (standardized forms managed at the level of SPCRPCIV Dâmbovița — the Serviciul Public Comunitar Regim Permise de Conducere și Înmatriculare a Vehiculelor, the county-level operational unit that actually processes these requests, administered under the Prefecture). However, this is the same nationally-uniform, identically-formatted request form used by every county's SPCRPCIV — it is a DGPCI-designed "formular tipizat," not a Dâmbovița-specific document, and the same site's own form list separately references "CERERE RESTITUIRE TAXE DIRECȚIA GENERALA PERMISE DE CONDUCERE ȘI ÎNMATRICULĂRI" (a fee-refund request form addressed to DGPCI by name), confirming DGPCI's role as the national design/policy authority behind this whole family of forms. Per this registry's established convention of attributing a nationally-uniform form to its national issuing authority even when a county/local operational unit hosts or administers it (e.g. rs/mup: a single national Ministry-published Rulebook annex, administered locally by police stations; co/runt's own precedent for a nationally uniform, locally-administered form), the chosen agency code is dgpci (Direcția Generală Permise de Conducere și Înmatriculări, dgpci.mai.gov.ro), the task brief's own stated national policy owner — not db/prefectura (the specific county mirror that happened to host this copy) and not spcrpciv (the operational unit named on the county page, but itself a dgpci-subordinate unit with no independent public web presence of its own; dgpci.mai.gov.ro's own <title> confirms "Direcția Generală Permise de Conducere și Înmatriculări" as the umbrella authority).

PDF structure, independently confirmed via pdfjs-dist

• 1 page. Confirmed via pdfjs-dist@3 (legacy build): page.getAnnotations({intent: "display"}) returned 34 Widget-subtype annotations, all on this single page.
• 25 text (Tx) widgets + 9 checkbox (Btn/checkBox) widgets = 34 total, matching the document's own field count exactly (see field-count reconciliation below).
• All 34 widgets sit in "Caseta B" (the applicant-completed half of the page, per the page's own printed heading "Rubricile din caseta B se completează de către solicitant" — the fields in box B are completed by the applicant). "Caseta A" (per the page's own printed heading "Rubricile din caseta A se completează de către autoritatea de înmatriculare" — completed by the registration authority) carries zero Widget annotations of its own on this specimen — confirmed directly from the annotation list, not inferred from layout alone. Caseta A's own printed columns are: (1) the registration number assigned by the authority, (2) the rank/name/signature of the officer who performed the operation, (3) the date the operation was performed, and (4) observations — all authority-completed, not applicant-submitted content, and excluded from this schema for that reason, consistent with this registry's established convention for the same class of content (rs/mup's excluded deciding-authority items, rs/mfa's excluded consular column).
• Extracted the full x/y-positioned text layer for the page and cross-checked every widget's own rect (x/y) against the text layer's own line order, since the 9 checkbox widgets are named non-sequentially by the PDF's own internal numbering (Check Box0, Check Box1, Check Box3, Check Box2, Check Box4, Check Box5, Check Box6, Check Box7, Check Box8 — note Box3 printed before Box2). Re-deriving the true top-to-bottom order from each widget's own rect[1] (y-coordinate) against the text layer's own top-to-bottom line order gives, unambiguously: Check Box0 = "înmatricularea", Check Box1 = "înmatricularea temporară", Check Box3 = "transcrierea transmiterii dreptului de proprietate", Check Box2 = "eliberarea unui duplicat al certificatului de înmatriculare", Check Box4 = "eliberarea unui nou certificat ca urmare a modificării datelor înscrise", Check Box5 = "radierea", Check Box6 = "autorizarea provizorie pentru o perioadă de ... zile" (with the adjacent Nr zile text-widget positioned directly beneath it), Check Box7 = "duplicat placă nr. înmatriculare/placă suplimentară ... buc" (with the adjacent Nr buc text-widget positioned directly beneath it), Check Box8 = "păstrarea combinației numărului de înmatriculare". All nine are independent Btn/checkBox widgets ("radioButton": false, "checkBox": true on every one) — not a single radio-button field — so nothing in the PDF's own AcroForm structure enforces mutual exclusivity; this schema adds that constraint itself via exclusivityGroups, matching the form's own single "solicit:" (I request:) sentence, which reads naturally as a one-of-nine selection even though the widgets are technically independent (the same modeling choice as this registry's rs/apr precedent for its own exclusivity-constrained boolean pair).
• The multi-purpose scope disclosed in the task brief ("registration OR transfer OR provisional deregistration") undercounts the actual form: the form's own checkbox list has nine operation types, not three — the title's three named operation families ("Înmatriculări, Transcrieri, Radieri Provizorii") are the three headline categories, but the form itself also lets an applicant request a duplicate certificate, a new certificate after a data change, a duplicate/supplementary plate, or retention of the existing plate combination, none of which are literally "registration," "transfer," or "(provisional) deregistration." This schema models the full nine-way choice as found, not narrowed to the title's three-word summary.
• The Data1 widget's own alternativeText metadata is "dd.mm.yyyy", confirming the vehicle-acquisition-date field's source format independently of the surrounding text layer.
• The "Semnătura ( ştampilă )" (signature/stamp) text printed beside the declaration date carries no fillable widget of its own on this specimen (only the adjacent Data text widget does) — confirmed directly from the 34-widget annotation list, which contains no widget positioned at or near the signature line's own coordinates. Not modeled as a field, consistent with this registry's practice of only modeling fields an agent can actually populate.
• The printed "NOTĂ DE INFORMARE" (GDPR data-protection notice) is prose text the applicant is asked to acknowledge ("Am luat cunoştinţă de conţinutul Notei de Informare" — printed directly above the Data/ signature line, itself not a separate widget) — not a fillable field, and not modeled.

Scope: what is modeled as fields[], and what is excluded

Included (all 34 of the form's own Widget annotations, one modeled field per widget):

• Applicant identity/address/contact block (name-or-company, CNP/CUI, locality, street, street number, block/staircase/floor/apartment, sector/county, e-mail, phone). E-mail and phone are modeled required: false per the form's own printed footnote explicitly stating both are optional ("Am luat cunoștință că adresa e-mail și numărul de telefon sunt opționale"); block/staircase/floor/apartment are left optional since they apply only to a block-of-flats address, matching this registry's standard treatment of the same class of sub-address component (e.g. rs/mup's optional secondary address fields).
• The nine mutually-exclusive operation-type checkboxes (exclusivityGroups entry operationTypeSelection), plus the two operation-specific blanks they gate via requiredWhen (provisionalAuthorizationDays, duplicatePlateQuantity).
• The vehicle-description block (brand, type, VIN, year of manufacture, existing registration number if any) and its acquisition detail (acquisition date, mode, and the party acquired from) — the last three are left optional since the form prints no explicit yes/no gate ahead of them and they are not equally relevant to every one of the nine operation types (e.g. a duplicate-certificate or duplicate-plate request does not inherently involve a new acquisition), consistent with this registry's practice of not inventing a synthetic gate where the source itself prints none.
• The optional "point 2" secondary-user block (name/CNP-CUI of a person other than the owner recorded as entitled to use the vehicle), left optional per the same no-explicit-gate reasoning — the source's own instruction text ("Se completează doar în cazul...") states the condition in prose but the form provides no separate checkbox/field to gate on, so no synthetic gating field was invented (per this registry's explicit guidance against fabricating a requiredWhen keyed to a non-existent field).
• The declaration date (declarationDate).

Excluded, with reasons (see "PDF structure" above for the independently-confirmed zero-widget basis):

• Caseta A in its entirety (authority-assigned registration number, processing officer's rank/name/signature, date of processing, observations) — office-only content, zero widgets of its own.
• The signature/stamp line beside Data — no widget of its own.
• The GDPR "NOTĂ DE INFORMARE" prose — not a fillable field.

documents[] — deliberately omitted, disclosed rather than fabricated

This form itself prints no attachment checklist (unlike this registry's rs/mup precedent, where the governing Rulebook's own Article 5 legally itemized a numbered list of mandatory attachments). A canonical, currently maintained document-requirements list does exist on DGPCI's own site (dgpci.mai.gov.ro/documents-and-forms/inmatriculari), but that site is an Angular single-page application: a plain curl fetch (with a standard user agent, and separately with a Googlebot user agent) returns only the empty <cbn-root></cbn-root> app shell with no server-rendered content, and the one available Wayback Machine snapshot (web.archive.org/web/20260218004949/...) is the same empty shell (Wayback's own crawler does not execute the page's JavaScript either). A WebSearch query surfaced a plausible-looking checklist (contract vânzare-cumpărare, talon, CIV, viză fiscală, RAR Auto Pass, RCA, CAF, act de identitate, dovadă domiciliu) via a third-party aggregator site (dosar-auto.ro), not DGPCI directly, and was not used as a documents[] source: this registry's practice requires each documents[] entry to trace to a directly verified first-party source, and an unverified secondary aggregator's summary does not meet that bar (this is the same category of risk as this registry's documented general caution against trusting a WebSearch/WebFetch AI summary without direct re-verification). Disclosed as a known gap: a future review with either direct browser-rendered access to dgpci.mai.gov.ro/documents-and-forms/inmatriculari or a first-party PDF/DOC checklist should add a documents[] array grounded in that verified source.

Field-count reconciliation

The source PDF's own AcroForm exposes 34 Widget annotations, all on Caseta B (Caseta A has zero). This schema models 34 fields[] — a 1:1 mapping from widget to field, with none merged, split, or left unmodeled. This same figure (34) is used consistently in this file, in the schema's own top-level description, and in the PR description, to avoid the field-count drift this registry has previously caught in review (see GOV-2801's own memory of a description/prose count mismatch).

Conformance fixtures

Two valid scenarios (0 errors each), under conformance/ro/dgpci/cerere-operatiune-inmatriculari-transcrieri-radieri-provizorii/1.0.0/:

• valid-registration-owner-only.json — a natural-person applicant requesting plain registration (operationRegistration: true, every other operation boolean explicitly false), full vehicle/acquisition detail, no secondary user, minimal address (no block/staircase/floor/apartment, since the address is a house, not a flat).
• valid-provisional-authorization-with-secondary-user.json — a legal-entity applicant (a CUI, a full block/staircase/floor/apartment address, optional e-mail/phone both provided) requesting provisional authorization (operationProvisionalAuthorization: true, provisionalAuthorizationDays: 30), an existing registration number (no fresh acquisition data), and a populated secondary-user block.

Six mutation controls, each raising exactly one error:

`` $ node check.mjs schema.json mutation-control-missing-required-field.json ["vehicleBrand: required but missing"] $ node check.mjs schema.json mutation-control-invalid-date-format.json ["declarationDate: expected type date, got string (\"13.07.2026\")"] $ node check.mjs schema.json mutation-control-invalid-type-year-of-manufacture.json ["vehicleYearOfManufacture: expected type integer, got string (\"2024\")"] $ node check.mjs schema.json mutation-control-value-below-minimum.json ["vehicleYearOfManufacture: 1850 below minimum 1900"] $ node check.mjs schema.json mutation-control-missing-conditional-provisional-days.json ["provisionalAuthorizationDays: required but missing"] $ node check.mjs schema.json mutation-control-exclusivity-group-violation.json ["exclusivityGroup operationTypeSelection: more than one field set (operationRegistration, operationDeregistration)"] ``

check.mjs is a scratch, from-scratch conformance checker (built in /tmp/pdfscratch/, never committed) that walks fields[], required/requiredWhen (evaluating the shared Condition grammar: all/ any/not/equals/notEquals/in/truthy), type (including the date YYYY-MM-DD format), validation (enum/minimum/maximum/ minLength/maxLength/pattern), exclusivityGroups (at most one true-valued member per group), documents[] (none present in this schema), and an unknown-field check. All eight fixtures (two valid, six mutation controls) were run against it; both valid fixtures returned [] and every mutation control returned an array of exactly one error string, matching the transcript above exactly.

The registry's zero-dependency structural validator and its ajv-based meta-schema validator were both run against the full registry (including this new schema) and pass:

``` $ node tools/validate.mjs 421/421 document(s) passed. 3/3 mapping.json companion(s) passed.

$ node tools/validate-ajv.mjs 421/421 document(s) validated against the meta-schema (ajv 2020-12). 3/3 mapping.json companion(s) validated. ```

(Registry count was 420/420 before this schema; 421/421 after, consistent with adding exactly one new schema and no others.)

The scratch pdfjs-dist/canvas install used for PDF extraction was done in an isolated /tmp/pdfscratch/ scratch directory, never inside tools/ or tools/govschema-client/. Running node tools/validate-ajv.mjs itself required a one-time npm ci --include=dev inside tools/ (its ajv/ ajv-formats devDependencies were not yet installed in this worktree) — this is tools/'s own package.json-declared dependency set, not a scratch install, and is the documented workaround for this registry's own "local NODE_ENV=production makes npm ci skip ajv" gotcha.

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

Scope and jurisdiction notes

• Opens Romania's DMV vertical (2 of 6). Passport, Business Formation, Visa, and National ID & Civic Documents remain open, unscreened backlog candidates for Romania — not screened this cycle.
• jurisdiction.level is national — this is a DGPCI-designed, nationally uniform request form used identically by every county's SPCRPCIV, even though the operational processing happens at county level and this particular copy is mirrored on one county Prefecture's own document host.
• process.type is registration, matching rs/mup's own convention for the equivalent multi-purpose DMV-vertical form type (a single form spanning registration, transfer, and deregistration operations).
• process.language is ro, since the source is monolingual Romanian.

Re-verification

Per the practice's cadence, nextReviewBy is set to 2027-01-13 (6 months). A future review should prioritize: (1) obtaining direct browser-rendered (or otherwise first-party) access to dgpci.mai.gov.ro/documents-and-forms/inmatriculari to add a verified documents[] array; (2) screening Romania's remaining four verticals (Passport, Business Formation, Visa, National ID & Civic Documents) for a ready-to-author candidate.