# Verification record — dk/skattestyrelsen/oplysningsskemaet@1.0.0

## Candidate selection

This session's brief (GOV-2253, "GovSchema Standard Research") re-confirmed
the four legacy-named National ID candidates (DE Steuer-ID, SG NRIC, NZ
RealMe, "remaining voter registration") are all already resolved, then
picked up Denmark's remaining vertical backlog. Denmark opened as the
registry's 33rd jurisdiction via `dk/um/application-for-danish-passport`
(GOV-2244, Passport, 1/6 verticals); CATALOG.md's own Known Gaps section
(item 4) had flagged genuine, fresh, unauthenticated AcroForm-PDF
candidates for Denmark's DMV and Taxes verticals as strong enough to
author, without naming a specific agency or form.

Both were screened fresh this cycle:

- **DMV**: Færdselsstyrelsen's driving-licence application, form P23
  (`https://cdn.fstyr.dk/faerdselsstyrelsen/Media/638554152455559004/Ansøgning%20om%20kørekort%20-%20(P23).pdf`,
  created June 2024) is a genuine, current, fillable AcroForm — but it
  resolves to 397 raw field names structured as a shared record card with
  18 repeated licence-category blocks (`proeve/kategori/paategningskode`),
  filled progressively over the licence's lifetime by driving schools,
  police, kommune, and examiners — only ~15 fields are actually
  applicant-entered, and the document is not fundamentally a citizen-facing
  intake form. Motorstyrelsen's vehicle-registration/re-registration flow
  (`motorregister.skat.dk`) is exclusively MitID/TastSelv-login-gated, no
  static-form fallback. Two further downloadable Motorstyrelsen forms
  (21.063 border-plate registration, 21.115 import-vehicle
  inspection/registration) are current but carry zero AcroForm fields —
  flat print specimens. **DMV was set aside as a poor candidate.**
- **Taxes**: Skattestyrelsen's form 04.003, "Oplysningsskemaet" (the
  personal income tax return issued to taxpayers exempt from the digital
  filing duty), is a genuine, current, fillable AcroForm with a
  field-by-field printed rubrik/felt-nr numbering scheme baked directly
  into the document's own text layer — no separate vejledning/guide
  document exists or is needed. **Taxes was picked.**

## Source

- **URL:** `https://skat.dk/media/ftiduwhm/04003_januar2026-t.pdf`
- Fetched fresh this session with a plain HTTP GET: **HTTP 200**,
  `461,975` bytes, confirmed a genuine PDF (`%PDF-1.7` header) containing
  an `/AcroForm` dictionary.
- **Edition:** January 2026, for indkomstår (tax year) 2025 — the form's
  own footer prints `04.003 Skattestyrelsen er en del af Skatteforvaltningen
  2026.01` on every page, and page 1 states the filing deadline as
  "Husk fristen den 1. juli 2026" (1 July 2026), consistent with a 2025
  tax-year return filed in 2026.
- No separate companion vejledning/guide document was needed or found:
  every input row on the form's own 4 pages is printed as
  `[label] [Rubrik #] [optional lock/redirect note] [Felt nr. #]`, giving
  a complete, self-documenting rubrik map directly in the specimen's own
  text content stream.

## Extraction technique

`pdfjs-dist` (`build/pdf.js`, loaded via `require()` from a cached
`/tmp/node_modules` install, same environment used by prior cycles) was
used for three independent passes, not one:

1. **`doc.getFieldObjects()`** — resolved **109 distinct field names**
   across the document's 4 pages (99 `Tx` text fields, ~10 `Btn`
   checkbox/radio widgets). Field names are entirely generic
   (`Text field #1` .. `#94`, `Knap_1` .. `Knap_10`, `Radioknap_1` ..
   `Radioknap_5`) — no self-documenting names, unlike some other
   jurisdictions' specimens in this registry.
2. **`page.getTextContent()` clustered into visual lines** — each text
   item's `transform[4]`/`transform[5]` (x/y) was used to group items into
   rows (items within 2.5pt of the same y treated as one printed line),
   then lines sorted top-to-bottom per page. This reconstructed the full
   rubrik/felt-nr table for all 4 pages independent of any AcroForm
   metadata.
3. **`page.getAnnotations()` widget rects cross-referenced against the
   clustered lines** — for every `Tx` widget, its own rect's y-range
   (`rect[1]` to `rect[3]`) was checked against which clustered line(s)
   fall inside that exact vertical span, rather than assuming the
   field-name numbering (`#1, #2, #3...`) matches visual reading order.
   This distrust was deliberate: the raw field-name sequence is
   demonstrably **not** a reliable position proxy on this specimen — e.g.
   `Text field #93` and `#94` are interleaved out of numeric order between
   `#28`/`#29` and `Knap_3`/`#32` respectively, yet sit in the visually
   correct row on the page. A purely name-ordered mapping would have
   silently mis-attributed several rows.

## The "locked/redirected rows have no widget" finding (disclosed, not assumed)

Walking every `Tx` widget's rect against the clustered lines on pages 1-2
turned up an exact, exhaustive 1:1 correspondence: **every rubrik row
printed with a "Felt låst" (locked) or "Anvend blanket 04.071/04.072" (use
companion form) annotation has literally no AcroForm widget anywhere on
this specimen.** This was checked exhaustively, not sampled:

- **Page 1 body:** 20 rubrik rows total (11, 12, 14, 15, 16, 17, 18, 19,
  347, 251, 20, 784, 785, 786, 21, 23, 24, 27, 437, 29); 9 carry a
  lock/redirect annotation (11, 12, 14, 16, 17, 18, 347, 21, 23); the
  remaining 11 (15, 19, 251, 20, 784, 785, 786, 24, 27, 437, 29) have no
  annotation and map 1:1, in rect order, onto the page's 11 body widgets
  (`Text field #4` through `#14`).
- **Page 2 body:** 22 rubrik/amount rows (32, 33, 34, 35, 36, 37, 346, 39,
  40, 41, 42, 43, 44, 50, 51, 52, 53, 54, 55, 447, 448, 56, 449, 57, 58, 59,
  460, 461, 466, 961) plus 2 checkbox rows (166, 167); 12 of the amount
  rows carry a lock/redirect annotation (34, 41, 42, 43, 44, 50, 52, 55,
  447, 448, 56, 466); the remaining 18 amount rows (32, 33, 35, 36, 37,
  346, 39, 40, 51, 53, 54, 449, 57, 58, 59, 460, 461, 961) plus the 2
  checkbox rows map 1:1, in rect order, onto the page's 18 body text
  widgets (`Text field #15`, `#15-2`, `#16`-`#21`, `#22`-`#30`, `#93`) and
  2 button widgets (`Knap_1`, `Knap_2`).
- **Zero widgets were left unaccounted for and zero un-annotated rows were
  left unmatched** on either page.

This means the exclusion of locked/redirected rubrikker from this
schema is a hard structural fact about the specimen, not an editorial
scope choice: Skattestyrelsen's own paper form gives the taxpayer no box
to write in for a line it already has from third-party reporting (employer,
bank, pension provider) or that it routes to a dedicated companion form
(04.071 for certain interest/maintenance items, 04.072 for certain
wage/pension/dividend items).

## Header-block widget mapping

Three widgets on page 1 cover the header area (Navn og adresse,
Personnummer, Ægtefællens personnummer, plus purely-informational
Skattekommune/Skatteprocenter/Kommune/Kirke/Personfradrag/Indregnet
restskat figures), disambiguated by rect geometry rather than assumed:

- `Text field #1`: rect `x 56.7–307.4, y 669.9–745.5`, `multiLine: true` —
  a wide box on the page's left column spanning ~76pt vertically, matching
  the free-text "Navn og adresse" block.
- `Text field #2`: rect `x 449.4–575.4, y 766.6–779.8` — a narrow
  single-line box in the right column at the "Personnummer" row height.
- `Text field #3`: rect `x 449.4–575.4, y 740.4–753.6` — an identically
  narrow single-line box directly below, at the "Ægtefællens personnummer"
  row height.

No other widget exists in the header region — Skattekommune, Skatteprocenter,
Kommune, Kirke, Personfradrag, and "Indregnet restskat 2023" are pure
Skattestyrelsen-supplied reference figures printed for the specific
addressee and are not modelled.

## Scope decision: pages 1-2 only (employee/pensioner filer)

This schema models pages 1-2 in full (Personlig indkomst, Kapitalindkomst,
Fradrag i kapitalindkomst, Ligningsmæssige fradrag, and the
ejendomsværdiskat confirmation checkboxes) and deliberately excludes pages
3-4 (Virksomheds ophør, Virksomhedsbeløb, Øvrige virksomhedsoplysninger,
Kapitalafkastordning, Virksomhedsordning, Særlig kapitalafkastberegning,
and Virksomhedsoplysninger/regnskab/revisor disclosure) — the
self-employment/sole-proprietorship accounting sections. These pages are
confirmed present and well-populated with their own fillable widgets (not
screened field-by-field this cycle) and are left as an open backlog
candidate for a future companion schema, the same treatment this registry
already gives the Czech Republic's own base-return-plus-Přílohy sequence
(`cz/mf/priznani-k-dani-z-prijmu-fyzickych-osob` plus Přílohy č. 1-4). Page
1's own printed text reinforces that this form's own designers already
route business income elsewhere: "Resultat af udenlandsk virksomhed skal
angives på blanket 04.011."

Money amounts are modelled as `type: "number"` representing whole Danish
kroner (DKK), the convention this registry already uses for other
jurisdictions whose forms print unlabelled currency-unit boxes (e.g.
`cz/mf/*`, `pt/at/declaracao-rendimentos-irs-modelo-3`). The three
form-printed deduction caps (`travelExpensesDeduction` ≤ DKK 32,800,
`tradesmenDeduction` ≤ DKK 8,600, `serviceDeduction` ≤ DKK 17,500) are
encoded as `validation.maximum`, taken directly from the amounts printed
in each row's own label text ("- højst 32.800 kr.", "- højst 8.600 kr.",
"– højst 17.500 kr.").

## Field-by-field source mapping

All 34 fields cite their exact `Rubrik <N> / Felt nr. <N>` pair (or, for
the 3 header fields, the specific page-1 header box) directly in
`sourceRef` — see `schema.json`. Every citation was read from the
clustered-line text extracted directly from the live PDF this session, not
copied from any secondary source.

## Mock conformance test run

Two scenarios were built under
`conformance/dk/skattestyrelsen/oplysningsskemaet/1.0.0/` and checked
against this schema's `required`/`validation` grammar with a disposable
checker script (`/tmp/gov2253/check_conformance.mjs`, not committed — same
technique used across this registry's other v1.0.0 cycles):

- **`application-packet-minimal-required-only.json`**: only the two
  required identity fields filled (name/address, CPR). **2 fields
  collected, 32 correctly not-applicable, 0 errors.**
- **`application-packet-full-employee-filer.json`**: a salaried employee
  with a spouse, minor personal/capital income, several itemized
  deductions at or under their printed caps, and both ejendomsværdiskat
  checkboxes set. **13 fields collected, 21 correctly not-applicable, 0
  errors.**
- **Four mutation/negative controls**, each derived from a base scenario
  with exactly one defect introduced, each correctly raised the expected
  error:
  1. Removing the required `applicantCivilRegistrationNumber` →
     `missing-required`.
  2. Setting `applicantCivilRegistrationNumber` to `"12345"` (violates
     `pattern: ^[0-9]{10}$`) → `pattern-violation`.
  3. Setting `tradesmenDeduction` to `15000` (exceeds the printed DKK 8,600
     cap) → `maximum-violation`.
  4. Setting `serviceDeduction` to `20000` (exceeds the printed DKK 17,500
     cap) → `maximum-violation`.

The schema was also validated against the GovSchema v0.3 meta-schema with
`node tools/validate-ajv.mjs` (passes standalone) and `node
tools/validate.mjs` (passes against the full registry, 346/346 documents
after this addition, 3/3 mapping.json companions).

## Scope and jurisdiction notes

This document models Denmark's Taxes vertical (2/6 for Denmark; DMV,
Business Formation, Visa, and National ID & Civic Documents remain open,
unscreened-or-screened-and-set-aside backlog candidates — see CATALOG.md's
Known Gaps section). It does not submit the return on the taxpayer's
behalf; the live source (skat.dk / TastSelv) is always authoritative.
GovSchema is independent and is not affiliated with, endorsed by, or
operated by the Kingdom of Denmark or Skattestyrelsen.