Denmark Application for Permit to Drive a Foreign-Registered Motor Vehicle for Private Purposes in Denmark — Ansøgning om tilladelse til kørsel i Danmark med udenlandsk registreret køretøj (form 21.059)

Why this candidate (GOV-2355, "GovSchema Standard Research")

The task brief for this issue framed form 21.059 as closing Denmark's DMV vertical (its last open vertical, bringing Denmark to 6/6). By the time this authoring pass started, a concurrent cycle (GOV-2346) had already merged dk/fstyr/samtykkeerklaering-koerekort-under-18 (form P23T, the under-18 driving-licence consent declaration) and closed Denmark's DMV vertical to 6/6 — confirmed by fetching origin/main fresh (commit 90d18fa) and reading CATALOG.md's own Executive Summary before doing any extraction work here. Rather than discard the pre-scouted, independently-confirmed candidate (38 distinct AcroForm fields / 48 widgets, per this issue's own brief), this schema authors form 21.059 anyway as a second, genuinely distinct DMV sub-process for Denmark: it is not a duplicate of P23T (a narrow parent/guardian consent declaration for minor licence applicants) or of either DMV candidate P23/Motorstyrelsen-re-registration screened and rejected by the prior GOV-2253 cycle (P23 is a shared, multi-party 397-field record card; the Motorstyrelsen re-registration flow is MitID-gated with no static fallback) — 21.059 is a standalone, unauthenticated, citizen-facing intake form for an entirely different real-world process (a temporary permit letting a resident privately drive a foreign-registered vehicle on Danish roads). This is expanding Denmark's real-world DMV coverage, not re-closing a vertical count that is already closed.

Source fetch

• URL: https://motorst.dk/media/gbplxzah/21059_en_ns_t.pdf
• HTTP status: 200 (direct fetch from motorst.dk; no login/CAPTCHA/WAF gate encountered)
• Byte size: 1,222,437 bytes
• File header: %PDF-1.6
• SHA-256 of the fetched bytes: 3acae2e99c97c234f6326fc2ac83b3dd31a1ce9d01d49aee806d886624a26147 (recorded here for future re-verification cycles to diff against)
• Form edition marker printed in the PDF's own footer: 2018.07; form code 21.059 DA EN, matching the DA/EN bilingual filename itself.

Independent field extraction

Performed fresh with pdfjs-dist@3.11.174 (legacy/build/pdf.js), not trusted from this issue's own pre-authoring scouting numbers:

• pdf.numPages → 2
• pdf.getFieldObjects() → 38 distinct keys (field names)
• Per-page page.getAnnotations() → 33 Widget annotations on page 1 and 15 on page 2, 48 total — cross-checked against getFieldObjects()'s 38 keys; the gap (48 − 38 = 10) is accounted for entirely by 4 genuine PDF radio-button groups (radioButton: true, shared fieldName, distinct buttonValue per option, confirmed via getAnnotations()):
  • pg1-9 — 2 options (Ja/Yes, Nej/No) → previouslyAppliedForPermit
  • pg1-15 — 5 options (Hus/House, Lejlighed/Apartment, Værelse/Room, Ejet/Owned, Lejet/Rented) → typeOfResidenceInDenmark
  • pg1-18 — the same 5 options → natureOfDomicileInHomeCountry
  • pg1-20 — 2 options (Ja/Yes, Nej/No) → domicileMaintainedDuringStayInDenmark
  • Widget count check: 2+5+5+2 = 14 widgets across 4 fields; 48 − 14 = 34 single-widget fields; 34 + 4 = 38, matching getFieldObjects() exactly.
• Every non-radio widget's own alternativeText directly names its section and label bilingually (e.g. "Oplysninger om den, som skal anvende køretøjet i Danmark/Information about the user of the vehicle in Denmark: Navn/Full name"), so no separate getTextContent() label correlation was needed for those. The 4 radio groups' own option widgets carry no alternativeText (empty string on every Btn widget), so their meaning was recovered by extracting each page's getTextContent() with y-coordinates and matching each radio group's own printed section heading directly above it (e.g. pg1-9's heading, printed at y=529.9/520.9, reads "Er der tidligere søgt om tilladelse?/Former applications for permit").
• Field type breakdown: 34 Tx (text) widgets forming 34 single-widget fields, 1 Sig (digital-signature) widget, and 4 Btn radio groups (14 widgets) forming 4 enum fields — 38 distinct fields total, 37 modelled as schema fields[] entries (the Sig widget is deliberately excluded; see below).

Raw field list (internal PDF field name → this schema's field name):

| PDF field name | Page | Type | Schema field | |---|---|---|---| | pg1-1 | 1 | Tx | fullName | | pg1-2 | 1 | Tx | nationality | | pg1-3 | 1 | Tx | personalIdentityNumberOrDateOfBirth | | pg1-4 | 1 | Tx | dateOfEntryIntoDenmark | | pg1-5 | 1 | Tx | dateOfDepartureFromDenmark | | (pg1-6 absent — no widget of this name exists on the specimen; form's own numbering simply skips it) | — | — | — | | pg1-7 | 1 | Tx | occupationOrPurposeOfStay | | pg1-8 | 1 | Tx | previousResidenceDurationInDenmark | | pg1-9 | 1 | Btn (radio, 2 opt) | previouslyAppliedForPermit | | pg1-10 | 1 | Tx | previousApplicationReferenceNumber | | pg1-11 | 1 | Tx | addressInDenmark | | pg1-12 | 1 | Tx | postalCodeAndCityInDenmark | | pg1-13 | 1 | Tx | telephone | | pg1-14 | 1 | Tx | email | | pg1-15 | 1 | Btn (radio, 5 opt) | typeOfResidenceInDenmark | | pg1-16 | 1 | Tx | leaseDurationInDenmark | | pg1-17 | 1 | Tx | addressInHomeCountry | | pg1-18 | 1 | Btn (radio, 5 opt) | natureOfDomicileInHomeCountry | | pg1-19 | 1 | Tx | leaseDurationInHomeCountry | | pg1-20 | 1 | Btn (radio, 2 opt) | domicileMaintainedDuringStayInDenmark | | pg1-21 | 1 | Tx | spouseOrCohabitantNameAndAddress | | pg1-22 | 1 | Tx | childrenNameAndDateOfBirth | | pg1-23 | 1 | Tx | expectedDaysOffInDenmark | | pg1-24 | 1 | Tx | expectedDaysOffInHomeCountry | | pg2-1 | 2 | Tx | vehicleRegistrationNumber | | pg2-2 | 2 | Tx | vehicleRegistrationCountry | | pg2-3 | 2 | Tx | vehicleMake | | pg2-4 | 2 | Tx | vehicleType | | pg2-5 | 2 | Tx | vehicleIdentificationNumber | | pg2-6 | 2 | Tx | vehicleOwnerNameAndAddress | | pg2-7 | 2 | Tx | currentMileage | | pg2-8 | 2 | Tx | expectedMileageInHomeCountry | | pg2-9 | 2 | Tx | expectedMileageInDenmark | | pg2-10 | 2 | Tx | purposeOfUseInHomeCountry | | pg2-11 | 2 | Tx | purposeOfUseInDenmark | | pg2-12 | 2 | Tx | frequencyOfUse | | pg2-13 | 2 | Tx | supplementaryInformation | | (pg2-14, pg2-15 absent — no widgets of these names exist on the specimen) | — | — | — | | pg2-16 | 2 | Tx | signatureDate | | pg2-17 | 2 | Sig | (not modelled — see below) |

38 distinct PDF fields → 37 schema fields[] entries (1 field, the Sig widget, deliberately excluded), a fully accounted-for mapping with no unexplained merging, splitting, or exclusion.

Disclosed judgment calls

1. personalIdentityNumberOrDateOfBirth (pg1-3) is a plain string, not this registry's usual ^[0-9]{10}$ personnummer pattern. The widget's own bilingual label reads "Dansk personnummer eller fødselsdato og -år/Danish civil registration number or date and year of birth" — the form itself offers an explicit non-personnummer alternative for applicants (typically foreign residents, the entire population this form targets) who do not yet hold a Danish personnummer. Constraining to the 10-digit pattern would reject a legitimate value the source form itself invites.
2. previousApplicationReferenceNumber (pg1-10) is requiredWhen previouslyAppliedForPermit equals "Ja/Yes". The field's own label ("Evt. journalnummer/Reference number, if any") and its physical placement directly beside the "Former applications for permit" yes/no radio group tie its relevance to a "yes" answer there, not to unconditional optionality with no linkage.
3. The 38th distinct field, pg2-17 (the form's own genuine Sig AcroForm field type), is deliberately not modelled as schema data. This is the only widget on the entire form typed Sig rather than Tx/Btn — a true interactive digital-signature field, not a text box. Consistent with this registry's existing precedent of not modelling ink/e-signature acts as schema data (dk/siri/work-permit-application models only signatureDate/ signaturePlace, never the signature act itself; the sourcing note in dk/um/application-for-danish-passport@1.1.0 states signature blocks are "not modelled as hand-drawn/image signature fields"). Its accompanying date widget, pg2-16, is modelled as signatureDate.
4. typeOfResidenceInDenmark / natureOfDomicileInHomeCountry each combine two logically distinct concepts (dwelling type: House/ Apartment/Room, and tenure: Owned/Rented) into a single 5-option enum. This mirrors the widget structure exactly: both are single PDF radio groups (one fieldName each, mutually exclusive by construction), not two independent groups — modelled as the source form actually constrains input, not split into what might seem like a cleaner two-axis model the form itself does not offer.
5. postalCodeAndCityInDenmark (pg1-12) combines postal code and city into one field, matching the single combined widget ("Postnummer og by/Postal code and city") rather than this registry's more common split-postal-code convention used elsewhere, because this specimen genuinely has only one widget here.

documents[]

Three document/attachment requirements, each directly quoting the form's own printed instructions rather than inferred:

1. vehicleRegistrationCertificateCopy (required: true) — "Kopi af køretøjets registreringsattest vedlægges/Enclose copy of the vehicle registration certificate", printed on both the page-1 header and again near the top of page 2.
2. processingFeeReceipt (required: true) — "(Det koster 400 kr. at få behandlet ansøgningen, vedlæg kvittering for indbetaling)/(The price for applying for a permit is DKK 400, enclose receipt for payment)", the page-1 subtitle.
3. employmentOrStudyDocumentation (required: false, no requiredWhen) — "Dokumentation for ansættelses-/studieforholdet herunder varighed bedes vedlagt/Documentation of nature and duration of employment/study must be enclosed", the pg1-7 (occupationOrPurposeOfStay) field's own parenthetical. Textually this only applies when the applicant's stated purpose of stay is employment or study, but occupationOrPurposeOfStay is free text, not a boolean/enum GovSchema's requiredWhen condition grammar can gate on precisely — gating on an exact-string match (e.g. equals: "employment") would be unreliable rather than a genuine reflection of the source form's own conditionality (per this registry's own documented notEquals-against-free-text pitfall). Modelled as unconditionally optional and disclosed here rather than guessed at.

Conformance verification

A one-off checker script (not committed — ad hoc per this registry's convention, mirroring prior cycles, e.g. dk/fstyr and dk/skattestyrelsen) was written to evaluate every fixture in conformance/dk/motorstyrelsen/ tilladelse-til-koersel-med-udenlandsk-registreret-koeretoej/1.0.0/ against this schema's fields[] (required/requiredWhen/validation.enum/ pattern/minLength/maxLength/minimum) and documents[] (required/requiredWhen) rules. Results:

| Fixture | Errors | Expected | |---|---|---| | application-packet-foreign-worker-fixed-term.json | 0 | 0 | | application-packet-returning-student.json | 0 | 0 | | mutation-control-missing-static-required.json | 1 (fullName missing) | 1 | | mutation-control-requiredwhen-violation.json | 1 (previousApplicationReferenceNumber requiredWhen violated) | 1 | | mutation-control-enum-violation.json | 1 (typeOfResidenceInDenmark invalid enum value) | 1 | | mutation-control-missing-required-document.json | 1 (processingFeeReceipt document missing) | 1 |

All 6 fixtures produced exactly the expected error count. The two valid scenarios (a foreign worker on a fixed-term Danish work assignment driving their own home-country-registered car; a returning exchange student who previously held this same permit) exercise both branches of the previouslyAppliedForPermit/previousApplicationReferenceNumber gating logic, and each mutation control isolates exactly one rule type (required, requiredWhen, enum, documents[].required) by construction — every mutation fixture is otherwise a fully valid, complete submission with exactly one deliberate defect introduced, so no fixture can pass by accidentally satisfying an unrelated rule. documents[] requiredness was explicitly exercised (not left an untested blind spot, per this registry's own documented documents[]-coverage pitfall).

Registry validation

• node tools/validate.mjs → ok, 359/359 documents pass (full registry, including this schema)
• node tools/validate-ajv.mjs → ok, 359/359 validate against the v0.3 meta-schema (full registry, including this schema)