Czech Republic Road Vehicle Registration Application (Žádost o zápis silničního vozidla do registru silničních vozidel)

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-08

This document was derived from a direct, unauthenticated fetch of the Ministerstvo dopravy's (MD, Ministry of Transport) own published PDF, whose AcroForm field layer was extracted programmatically and cross-checked against a rendered image of both pages. It remains draft, not verified, pending an independent second reviewer's field-by-field pass.

Why this document exists

GOV-1804 is GovSchema's recurring standards -research cycle. Its most recent prior run (GOV-1807) opened the Czech Republic as the registry's 26th jurisdiction with a single Business Formation schema (cz/mpo/jednotny-registracni-formular-fyzicka-osoba), leaving the Czech Republic's other five verticals (Passport, DMV, Taxes, Visa, National ID) as open, unscreened backlog. This cycle picks up DMV, following this registry's own established pattern of building out a newly-opened jurisdiction's remaining verticals before screening a further new jurisdiction (the same sequencing my/jpj → my/jim (Passport) → my/jim (Visa) used for Malaysia).

Source examined

• URL: https://md.gov.cz/getattachment/Dokumenty/Silnicni-doprava/Elektronicke-formulare-(1)/Elektronicke-formulare/Zadost-o-zapis-silnicniho-vozidla-do-registru-silnicnich-vozidel-(1).pdf.aspx?lang=cs-CZ
• Retrieved: 2026-07-08, HTTP 200, no login/CAPTCHA/WAF gate.
• Format: genuine %PDF-1.6, 683,153 bytes, linearized, 2 pages.
• Found via MD's own "Formuláře registru silničních vozidel" index page (md.gov.cz/Dokumenty/Silnicni-doprava/Elektronicke-formulare), which links this exact file as the current registration-application form.
• Candidates not pursued this cycle: MD's own site also links a companion "Přihláška k registraci vozidla" form on the third-party registr-vozidel.cz mirror and a "(4)"-suffixed near-duplicate PDF on md.gov.cz itself; both appeared in the same search results as the file used here but were not independently diffed against it — a possible further-vertical/edition-variant check for a future cycle, not pursued here since the "(1)"-suffixed file used is directly, currently linked from MD's own index and matches the same registr-vozidel process this document's title claims to cover.

Extraction method

1. Fetched the PDF directly (curl, no auth/cookies needed).
2. Extracted every AcroForm field two independent ways and cross-checked the counts: pdfjs-dist's per-page page.getAnnotations() (57 Widget annotations across 2 pages: 21 on p.1, 36 on p.2) and a separate pdf-lib form.getFields() pass (57 fields). The two techniques agree exactly, so — unlike GOV-1801's pt/mne PDF — this document's AcroForm field tree carries no orphaned/duplicate Widgets to reconcile.
3. Extracted each page's text content with pdfjs-dist's getTextContent(), re-sorted by descending y then ascending x (not linear read order) to recover the form's true multi-column reading order, and matched each field's widget rectangle against the nearest printed label by position.
4. Rendered both pages to PNG with pdfjs-dist + node-canvas at 2.5x scale and visually inspected the rendered image wherever the rect/label matching in step 3 left more than one plausible reading — see Judgment calls below for the specific cases this resolved.
5. Where a field's role was still ambiguous after steps 3–4, inspected the field's own raw PDF dictionary (Ff, MaxLen) via pdf-lib — this is what distinguished the two adjoining rodné-číslo comb boxes (see below).

Judgment calls

1. The rodné-číslo/IČO row's three widgets are two logical values, not three. Section A's identity row visually renders as what looks like a single unbroken 10-cell comb grid immediately followed by a second comb grid (confirmed by rendering the page to an image), but the AcroForm layer actually defines three separate fields there: comb_3 (MaxLen: 6), an unlabelled field pdfjs reports as undefined (MaxLen: 4), and comb_5 (MaxLen: 8). 6 + 4 = 10 matches the Czech rodné číslo's own RRMMDD/XXXX format (6-digit birth-date prefix, up to 4-digit suffix) printed with no visible divider between the two boxes, which is why they render as one continuous grid; comb_5's separate 8-digit box is the IČO alternative the row's own printed footnote describes. This document therefore models the first two widgets as a single logical ownerPersonalIdNumber field (pattern ^[0-9]{8,10}$, permissive enough for both the 10-digit rodné-číslo case and the form's own fallback 8-digit DDMMRRRR date-of-birth case) and the third as the separate ownerIdentificationNumber. The same reasoning applies to Section B's mirror-image comb_6/undefined_2/comb_8 triple (operatorPersonalIdNumber / operatorIdentificationNumber).
2. Section B's operator-name field spans two form fields (fill_3, fill_6) for one logical value. Rendering the page showed no visible line or box under either the Section A or Section B name label at all (both are blank free-write areas) — but Section B's identical label text ("jméno, popřípadě jména a příjmení...") is followed by two separate blank field rows where Section A's copy of the same label has only one, evidently to leave room for a longer registered business name. Modelled as a single operatorName field, consistent with this registry's practice of modelling one printed value as one schema field even when the source form gives it extra visual room (e.g. this registry's own cz/mpo/jednotny-registracni-formular-fyzicka-osoba treats a two-line-wrapped label the same way).
3. comb_1 (top of p.1, "registrační značka (vyplní úřad)") is excluded — its own printed label states the issuing office, not the applicant, completes it. Its 7-character MaxLen matches the standard Czech registration-mark length, confirming it is a real plate-number box, just one the applicant never fills in.
4. RZ (p.1, plain "registrační značka" with no "(vyplní úřad)" qualifier) is modelled as an applicant field, existingRegistrationNumber. Positioned beside the rodné-číslo footnote and before the required -documents list, with an 8-character MaxLen, it reads as the vehicle's pre-existing Czech plate number for a re-registration (as opposed to a first-time registration) — distinct from the office-only comb_1 box.
5. Out of scope — every field structurally inside "G. Potvrzení o převzetí dokladů žadatelem (nabytí právní moci)" (p.2): the returned -document tabulation (plate/technical-certificate/registration -certificate numbers), "Jiné doklady", and both the applicant's and the "oprávněné úřední osoby" (authorized official's) signature/stamp lines. This section's own heading states it confirms the applicant receiving back processed documents once the registration has already acquired legal force — an office-completed post-approval receipt, not application-time applicant input, the same class of exclusion this registry documented for ca/esdc/social-insurance-number-application's "for office use only" sections.
6. Out of scope — the administrative-fee acknowledgment block (p.2, "Správní poplatek ... Kč podle položky ... byl uhrazen v hotovosti. Doklad č. ..." plus its adjoining "podpis oprávněné úřední osoby" line). Sitting between Section F and the G heading with no section letter of its own, its own printed text ("was paid in cash. Receipt No. ...", confirmed by the issuing official's own signature) describes a counter-side payment receipt completed by MD/municipal staff at submission time, not applicant-declared data — excluded on the same basis as judgment call 5.
7. The 10 vehicle-color checkboxes and the 4 vehicle-purpose checkboxes are each modelled as independent boolean fields joined by an exclusivityGroups entry, not collapsed into a single enum field. The AcroForm layer defines each checkbox as its own independently-named /Btn field (Check Box13–Check Box22 for color; vozidlo taxislužby/toggle_2/toggle_3/vozidlo obecného užití for purpose) rather than a single radio-button field with shared export values, so modelling each PDF widget as its own schema field is the more source-faithful choice; exclusivityGroups (GSP-0013 §5) then captures the real-world single-selection intent (a vehicle has one color, and at most one special-use declaration) without fabricating a constraint the source form's own field structure does not literally impose. This mirrors the existing cl/sii/aviso-venta-vehiculo precedent for a same-shaped checkbox group.
8. vehicleNotes collapses four identical blank lines into one multi-line field. The source form prints four consecutive dotted lines under "Poznámky (Zvláštní výbava a zařízení, povolené výjimky apod.)" with no sub-labels distinguishing them — one logical free-text value given four lines of writing room, modelled the same way as judgment call 2's operatorName.
9. The pre-Část-D "surrendering old plates/certificate" declaration (surrenderedPlateNumber, surrenderedPlateCount, surrenderedRegistrationCertificateSeries, surrenderedRegistrationCertificateNumber) carries no requiredWhen gate. The source form provides no boolean field signalling "this application surrenders a prior registration," so — consistent with this registry's established practice of never fabricating a synthetic toggle the source itself does not print (see cz/mpo/jednotny-registracni-formular-fyzicka-osoba's own judgment call 3) — these four fields are left plain optional.
10. documents[] required/optional split follows Část C's own printed conditions. Two of the nine listed attachments carry no stated condition in the source text (technicalFitnessDocument, thirdPartyLiabilityInsuranceDocument) and are modelled required: true; the remaining seven are each conditioned on a fact this schema's field set cannot reliably gate on (e.g. "unless the vehicle is new," "if identity is being verified") and are modelled required: false with the condition stated in each document's own label, the same convention this registry used for cz/mpo/jednotny-registracni-formular-fyzicka-osoba's own documents[] entries.
11. jurisdiction.level is national, not subnational, even though filing itself happens at the applicant's locally competent obecní úřad obce s rozšířenou působností — the form and the register it feeds are both nationally standardized and MD-published, the same classification this registry already applies to cz/mpo/jednotny-registracni-formular-fyzicka-osoba (filed with a local živnostenský úřad but modelled as national).

Test run (Phase 3)

No live submission was attempted: filing this application creates a real vehicle-registration record (and, where Část B/existing-plate fields are used, a real ownership/operator change) with a Czech municipal authority — fabricating applicant/vehicle records against a live government register is not a safe or reversible action, consistent with this registry's practice for every comparable registration-type schema.

Both meta-schema validators were run against the finished document and pass clean:

``` $ node tools/validate.mjs registry/cz/md/zadost-o-zapis-silnicniho-vozidla/1.0.0/schema.json ok registry/cz/md/zadost-o-zapis-silnicniho-vozidla/1.0.0/schema.json

1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/cz/md/zadost-o-zapis-silnicniho-vozidla/1.0.0/schema.json ok registry/cz/md/zadost-o-zapis-silnicniho-vozidla/1.0.0/schema.json [v0.3]

1/1 document(s) validated against the meta-schema (ajv 2020-12). ```

A hand-written structural self-check (field-name uniqueness, no required+requiredWhen conflicts, every exclusivityGroups field name resolving to a real boolean field, every documents[] id unique) was also run against the generated document before submission and reported zero issues.