Denmark Application for Danish Passport

Why this version exists (GOV-2242, "GovSchema Standard Research")

1.0.0 (GOV-2244, merged as commit a85d509) modelled Section D's four always-collected string fields per consent-holder column (child's name, name, Civil Registration number, date-and-signature) as requiredWhen: { field: "applicantIsMinor", equals: true } for both the first- and second-parent columns equally — i.e. any minor applicant was modelled as needing both consent-holder columns filled in.

A concurrent, independent authoring pass on this same candidate (also GOV-2242-derived, racing 1.0.0's own authoring session — see [[gov2177-duplicate-concurrent-run-same-issue]]-style collision) built its own mock-conformance harness and found this incorrect: a minor applicant whose first parent/guardian holds sole legal custody (firstParentHasSoleCustody: true) has, by definition, only one legal consent-holder — there is no second parent/guardian whose name, CPR number, or signature the form could require. Modelling both columns as unconditionally required whenever applicantIsMinor is true would reject a genuinely valid, common submission.

This was checked against a source the 1.0.0 cycle did not consult: the Ministry of Foreign Affairs' own citizen-facing guidance page (a distinct um.dk subdomain, not the application PDF itself), https://um.dk/storbritannien/en/travel-and-residence/how-to-apply-for-a-danish-passport/passport-requirements/passports-for-children-under-18-years-old/, fetched fresh (HTTP 200, no login/CAPTCHA/WAF gate), which states verbatim:

> "According to Danish law, both parents must give their consent every > time they apply for a Danish passport for their child until he/she > reaches the age of 18." > > "If one parent has acquired sole custody/parental responsibility, > documentation to this effect must be presented together with the > passport application and only one consent must be given."

This confirms the sole-custody/joint-custody distinction the application PDF's own two parallel Section D columns structurally encode (each column asks "I hold [ ] sole [ ] joint legal custody of the child") is the correct gate, not applicantIsMinor alone. 1.0.0 remains published and immutable per VERSIONING.md §3 — it is not edited by this document, and its own claim (both columns always required for a minor) is a genuine, disclosed defect, not merely a documentation slip. 1.1.0 re-gates the second-parent column's four core fields (secondParentName, secondParentCivilRegistrationNumber, secondParentSectionChildName, secondParentDateAndSignature) on requiredWhen: { field: "firstParentHasJointCustody", equals: true } instead — the first parent's own custody-type selection is what the form's structure uses to signal whether a second consent-holder exists at all. The first-parent column's four core fields remain requiredWhen: { field: "applicantIsMinor", equals: true }, unchanged: whenever the applicant is a minor, at least one parent/guardian's consent is always required, per the same guidance page's first sentence quoted above.

This is a validation-loosening change (previously-required fields become conditionally optional; no previously-valid submission becomes invalid) — a MINOR bump per VERSIONING.md §1, not a MAJOR.

The out-of-scope "documentation to this effect must be presented" requirement (i.e. proof of sole custody, e.g. a court order) referenced in the guidance page above is not modelled as a documents[] entry in this version — the source PDF itself does not name or itemize such a document the way it does for lostPassportPoliceReport, and inventing an unbounded "proof of custody" document type without the form's own itemization would be a genuinely new scope decision, left for a future cycle to source properly rather than guessed here.

Everything below this point (candidate selection, source, extraction technique, widget accounting, checkbox/exclusivity modelling, documents[], verbatim-quote cross-check) is unchanged from 1.0.0 and reproduced here per this registry's convention of each version directory carrying its own complete, self-contained verification record.

Candidate selection

This session's brief (GOV-2244), delegated from the GOV-2242 "GovSchema Standard Research" cycle, was to author Denmark as GovSchema's 33rd jurisdiction, opening with its Passport vertical (1/6). GOV-2242 had scouted three new-jurisdiction candidates in parallel (Norway, Denmark, Belgium) and found Denmark the strongest: genuine, fresh, unauthenticated AcroForm PDFs across three verticals, with Passport judged the strongest single source to open with. This session re-verified that scouting from scratch — a fresh fetch, a fresh pdfjs-dist extraction independent of the scouting agent's own numbers, and a fresh field-by-field design pass — rather than assuming the prior cycle's figures still held.

Source

• Primary: https://um.dk/media/vd0fpauc/application_for-danish_passport_2026_03_web.pdf — the Ministry of Foreign Affairs of Denmark's (Udenrigsministeriet, UM) "Application for Danish passport" form, edition dated 03/2026 (printed at the foot of both pages: (03/2026)). Fetched with a plain HTTP GET using a realistic browser User-Agent: HTTP 200, content-type: application/pdf, exactly 122,515 bytes (SHA-256 87b7049de89a69cda5e512c91c8e74e038d6e217f5b93b81b8c0dffae48c8ac5), a genuine fillable AcroForm PDF, 2 pages. No login, CAPTCHA, or WAF gate of any kind — a direct, unauthenticated download from the Ministry's own um.dk media library.
• No separate form-number is printed anywhere on the document; it is referred to here by its own printed title, "Application for Danish passport."

The PDF was re-fetched a second time at the end of this session (see "Pre-PR re-verification" below); the byte length and SHA-256 were identical both times.

Extraction technique

The PDF's AcroForm layer was extracted with pdfjs-dist v3.11.174 (legacy/build/pdf.js, loaded via createRequire, per this registry's documented Node-environment requirement), calling page.getAnnotations({ intent: "display" }) on each page to enumerate every Widget annotation, doc.getFieldObjects() to group widgets by their true, distinct PDF field name, and page.getTextContent() (with each item's transform[4]/transform[5] x/y coordinates preserved) to reconstruct the surrounding printed prose and labels by position, in the same style used by this registry's at/bmeia/is/* cycles.

• 86 total AcroForm widgets — 42 on page 1, 44 on page 2.
• getFieldObjects() returns 86 distinct field-name keys — i.e. no two widgets in this document share a field name anywhere. Every Btn (checkbox) widget's own radioButton flag is false (checked across all 30 Btn widgets programmatically, not eyeballed). This document contains zero genuine PDF radio-button groups.
• Zero widgets carry a shared field name across the split Civil-Registration-number (CPR/personnummer) digit boxes — each of the 30 digit-box widgets (3 groups of 10, see "Split-digit merges" below) is its own distinct field name (pasansoeger personnr 1_2 .. 1_11, foraelder personnummer 2_2 .. 2_11, foraelder personnummer 3_2 .. 3_11), consistent with the split-box pattern already documented for other jurisdictions in this registry (e.g. Iceland's kennitala/kerfiskennitala forms).

Widget-to-field accounting (86 → 58, fully disclosed)

| Category | Widgets | Fields | Net | |---|---:|---:|---:| | Excluded (official-use-only) | 2 | 0 | −2 | | Split-digit CPR merges (3 groups × 10) | 30 | 3 | −27 | | All other widgets (1:1) | 54 | 54 | 0 | | Synthesized (no backing widget) | 0 | 1 | +1 | | Total | 86 | 58 | |

54 + 3 + 1 = 58, matching schema.json's own fields.length (checked mechanically: python3 -c "import json; print(len(json.load(open('schema.json'))['fields']))" → 58).

Excluded widgets (2)

Both are printed under the form's own header "For official use only" (top-right of page 1) and are explicitly the issuing authority's own fields, not applicant data:

• modtaget dato 2 ("Date received")
• hoejde 2 ("Height in cm")

Consistent with this registry's convention (see e.g. at/bmeia, de/bmi) of not modelling fields the source document itself marks as staff-only/office-computed.

Split-digit merges (3 groups, 30 widgets → 3 fields)

Each of the applicant and up to two parents/guardians has their 10-digit Danish CPR number (personnummer) split across ten separate single-digit text widgets on the source PDF, confirmed via each widget's own /TU alternate text (e.g. "Insert first digit of applicant's Civil registration number" through "...tenth digit..."). Per this registry's established split-digit/split-component box convention, each group of 10 merges into one field with a ^[0-9]{10}$ pattern:

• pasansoeger personnr 1_2 .. 1_11 → applicantCivilRegistrationNumber
• foraelder personnummer 2_2 .. 2_11 → firstParentCivilRegistrationNumber
• foraelder personnummer 3_2 .. 3_11 → secondParentCivilRegistrationNumber

Duplicate-value fields kept unmerged (disclosed, not a merge)

Section D's two parallel parent/guardian columns each carry their own Tx widget asking for the applying child's name (barn foraelder 2 / barn foraelder 3, both with the identical /TU alternate text "Insert name of child who is applying for a passport"). Unlike the CPR digit groups — which jointly encode ten fragments of one number — these two widgets are literal, independent duplicate write-in boxes, each on a different consent-holder's own signature block on the physical form, not a split encoding of a single value. They are modelled as two distinct fields, firstParentSectionChildName and secondParentSectionChildName, per this registry's convention of not merging genuinely duplicate write-in boxes purely because they happen to ask for the same underlying fact; see the corresponding field descriptions in schema.json.

Synthesized field (1, no backing widget)

Section D's own printed header reads: "D: Declaration of consent (This section shall be completed if the applicant is under 18 years of age)." The source form has no explicit age/minority checkbox anywhere (a Danish CPR number itself encodes date of birth, which likely explains why the form does not separately collect a date-of-birth field at all — there is none on this document). Without a real field to gate Section D's own requiredWhen visibility, a semantic-only field applicantIsMinor (type: boolean, required: true, no sourceRef widget) was added, disclosed here as not backed by any AcroForm widget — the same class of judgment call already used by this registry's is/thjodskra/passport-issuance-consent-minor (GOV-2226) cycle.

Non-grouped checkbox modelling (12 exclusivityGroups)

Every multi-option selector in this document is a set of independent, non-grouped PDF checkboxes (confirmed via getFieldObjects()/radioButton as above), modelled as independent optional boolean fields with a disclosed exclusivityGroups entry where real-world mutual exclusivity is evident — the same convention already established by us/uscis/employment-authorization-i765 and generalized across this registry's at/bmeia cycle:

| Group | Fields | |---|---| | application_type | firstPassportRequested, renewalRequested, provisionalRequested, extensionRequested, extraPassportRequested | | applicant_sex | applicantIsMale, applicantIsFemale | | danish_nationality_status | applicantHoldsDanishNationality, applicantDoesNotHoldDanishNationality | | other_nationality_status | applicantIsOrWasNationalOfAnotherCountry, applicantIsNotAndWasNeverNationalOfAnotherCountry | | previous_danish_passport_status | applicantPreviouslyHeldDanishPassport, applicantNeverHeldDanishPassport | | current_passport_reason | currentPassportExpiringOrExpired, currentPassportLost, currentPassportOtherReason | | first_parent_custody_type | firstParentHasSoleCustody, firstParentHasJointCustody | | first_parent_other_nationality_status | firstParentAcquiredOtherNationalityBefore2015, firstParentDidNotAcquireOtherNationalityBefore2015 | | first_parent_kinship_basis | firstParentKinshipBiological, firstParentKinshipAdoptive, firstParentKinshipOther | | second_parent_custody_type | secondParentHasSoleCustody, secondParentHasJointCustody | | second_parent_other_nationality_status | secondParentAcquiredOtherNationalityBefore2015, secondParentDidNotAcquireOtherNationalityBefore2015 | | second_parent_kinship_basis | secondParentKinshipBiological, secondParentKinshipAdoptive, secondParentKinshipOther |

Per this registry's established practice (see at/bmeia VERIFICATION.md), none of the individual boolean options within these groups carry their own requiredWhen — only the genuine conditional detail fields do (e.g. applicantOtherNationalityCountry gated on applicantIsOrWasNationalOfAnotherCountry, currentPassportOtherReasonDetails gated on currentPassportOtherReason, firstParentOtherNationalityCountry gated on firstParentAcquiredOtherNationalityBefore2015, firstParentKinshipOtherDetails gated on firstParentKinshipOther, and their secondParent mirrors). An earlier draft of this schema mistakenly applied requiredWhen: { field: "applicantIsMinor", equals: true } to every Section D boolean option (custody, nationality-acquisition, kinship-basis) — this was caught during authoring by a mock conformance test run, which showed the minor scenario failing with spurious missing-required errors on fields that are optional non-grouped checkboxes, not mandatory answers. The requiredWhen gate on applicantIsMinor was corrected to apply only to the genuine always-collected string fields per consent holder (child's name, name, Civil Registration number, date-and-signature) — not to the checkbox options themselves.

1.1.0 correction: as described in "Why this version exists" above, 1.0.0 still applied that applicantIsMinor-only gate to both consent-holder columns' four core string fields equally. 1.1.0 narrows the second-parent column's four core fields (secondParentName, secondParentCivilRegistrationNumber, secondParentSectionChildName, secondParentDateAndSignature) to requiredWhen: { field: "firstParentHasJointCustody", equals: true } — only required when the first parent's own custody selection indicates a second consent-holder exists at all. The first-parent column's four core fields are unchanged (requiredWhen: applicantIsMinor equals true).

documents[] (1 entry)

• lostPassportPoliceReport — requiredWhen: currentPassportLost == true, sourced from the form's own parenthetical: "Lost (a declaration of lost passport together with a police report must be enclosed)".

Verbatim-quote cross-check

Every phrase this record or schema.json places in single quotation marks was checked against this session's own pdfjs-dist getTextContent() dump of both pages (item strings preserved with x/y position, via a disposable script at /tmp/gov2244/text.js, not committed) — every quoted label, section heading, and instruction (including the Section C attestation text referencing "Section 163 of the Danish Criminal Code" and the Section D consent/custody sentences) matched the extracted text layer exactly, with no line-wrap or font-artifact discrepancies found.

Mock conformance test run

Three scenarios live under conformance/dk/um/application-for-danish-passport/1.1.0/ (the first two carried forward unchanged from 1.0.0; the third added in this version), checked against this schema's own required/requiredWhen/validation/ documents[]/exclusivityGroups grammar with a disposable checker script (same technique used across this registry's other cycles, extended here with explicit exclusivityGroups enforcement):

• application-packet-adult-renewal.json: an adult applicant renewing an existing Danish passport, a Danish national with no other nationality and no lost/stolen history. 20 fields collected, 38 correctly not-applicable, 0 errors; currentPassportNumber correctly required (previously held a passport); all Section D fields correctly not required (applicantIsMinor: false).
• application-packet-minor-both-parents-consent.json: a first passport for a minor applicant, filed with both parents completing Section D — the first parent has sole custody, is the biological parent, and did not acquire another nationality before 1 September 2015; the second parent has joint custody, did acquire another nationality before that date (triggering the conditional country field), and establishes kinship on an "other" basis (triggering the conditional details field). 34 fields collected, 24 correctly not-applicable, 0 errors. (Note: the first parent's sole selection alongside a second parent's joint selection in this fixture is internally inconsistent as a real-world custody arrangement — carried forward unchanged from 1.0.0 rather than rewritten, since the fixture still exercises the intended structural coverage, both columns populated, and this document does not cross-validate the two columns' custody-type answers against each other.)
• application-packet-minor-sole-custody-single-parent.json (new in 1.1.0): a first passport for a minor applicant whose first parent/guardian holds sole legal custody — no second parent/guardian data is supplied at all. 25 fields collected, 33 correctly not-applicable, 0 errors under 1.1.0. Re-run against the superseded 1.0.0 schema (same fixture, 1.0.0's own schema.json): 4 spurious missing-required errors (secondParentName, secondParentCivilRegistrationNumber, secondParentSectionChildName, secondParentDateAndSignature) — this is the defect this version fixes, reproduced directly rather than only asserted.
• Nine mutation/negative controls, each derived from a base scenario with exactly one defect introduced, run through the same checker script and each correctly raised at least one error:
  1. Removing the required applicantSurname → missing-required.
  2. Setting both applicantIsMale and applicantIsFemale to true → exclusivity-violation on the applicant_sex group.
  3. Setting applicantCivilRegistrationNumber to "12345" (violates pattern: ^[0-9]{10}$) → pattern-violation.
  4. Removing currentPassportNumber from the renewal scenario (where applicantPreviouslyHeldDanishPassport: true) → missing-required, confirming that requiredWhen gate fires.
  5. Setting currentPassportLost: true on the renewal scenario (which already has currentPassportExpiringOrExpired: true) → 2 errors: an exclusivity-violation on current_passport_reason and a missing-required-document on lostPassportPoliceReport, confirming both mechanisms fire independently and correctly on the same packet.
  6. Removing secondParentKinshipOtherDetails from the minor scenario (while secondParentKinshipOther: true remains) → missing-required, confirming that nested conditional gate fires.
  7. Setting applicantIsMinor: true on the adult-renewal scenario without filling any Section D fields → 4 missing-required errors (the first-parent column's four always-collected string fields: child's name, name, Civil Registration number, date-and-signature) — confirming the applicantIsMinor gate fires for exactly the first-parent column, no more, no fewer (under the superseded 1.0.0 gate this same mutation raised 8 errors, both columns; see "Why this version exists" above).
  8. Removing applicantDateAndSignature from the minor scenario → missing-required.
  9. Setting firstParentHasJointCustody: true on the new sole-custody fixture (in place of firstParentHasSoleCustody) without adding any second-parent data → 4 missing-required errors (the second-parent column's four core fields), confirming the 1.1.0 gate correctly does fire once joint custody is asserted, not just that it stays silent for sole custody.

The schema was also validated against the GovSchema v0.3 meta-schema with node tools/validate.mjs and node tools/validate-ajv.mjs (both pass, run from the repository root against this document specifically and against the full registry — 344/344 documents pass after this addition).

Pre-PR re-verification

Immediately before finalizing this record, the primary PDF was re-fetched live a second time in this same session: HTTP 200, application/pdf, 122,515 bytes, SHA-256-identical to the first fetch (87b7049de89a69cda5e512c91c8e74e038d6e217f5b93b81b8c0dffae48c8ac5).

Path to a verified claim (next step)

To advance from status: draft to status: verified, a future reviewer would: confirm with a Danish mission or um.dk's own citizen-facing guidance which supporting documents (photo, prior passport, birth certificate, etc.) this form's own instructions require per applicant scenario, since this form itself is silent on that beyond the lost passport / police report note modelled here; and check whether a Danish-language-only companion guidance page changes any of the conditional-document requirements disclosed above.

Scope and jurisdiction notes

Opens Denmark as GovSchema's 33rd jurisdiction, with its Passport vertical (1/6). DMV and Taxes were flagged by the GOV-2242 scouting cycle as genuine, fresh, unauthenticated AcroForm-PDF candidates for future cycles; Business Formation, Visa, and National ID remain unscreened backlog candidates for a future cycle.