Finland Guardian's Consent for a Minor's Passport, Identity Card, Firearms Permit, or Explosives Precursor Licence — Huoltajan suostumus (Poliisi-Muut-07)

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

Finland stood at 5 of 6 verticals (Business Formation, DMV, Taxes, National ID, Visa published; Passport open and unscreened as Finland's sole remaining vertical). Poliisi's own primary adult passport/identity-card application process (poliisi.fi) was re-confirmed this cycle as online-application-plus- mandatory-in-person-biometric — no downloadable blank application form exists for the main flow. This is the same dead-end pattern this registry has already confirmed for the Czech Republic, Norway, Estonia, Poland, and Sweden's own passport verticals: a government identity document issued only via an in-person, biometric appointment has no citizen-facing static form to model.

There is, however, a genuine, standalone, citizen-facing companion PDF: Poliisi-Muut-07, "Huoltajan suostumus" (Guardian's consent) — the form a minor's guardian(s) use to consent to the minor being granted a passport, identity card, firearms permit, or explosives precursor licence. This is directly analogous to two existing precedents in this registry: se/polisen/medgivande-pass-nationellt-id-kort-minderarig (GOV-2363, PM 531.2), which closed Sweden's Passport vertical the same way, and dk/fstyr/samtykkeerklaering-koerekort-under-18 (GOV-2346, P23T), a narrow guardian-consent companion form that closed Denmark's DMV vertical.

Three other candidates were screened and set aside this cycle before settling on this one — see "Candidates considered and not picked" below.

Source fetch

• Finnish original: https://poliisi.fi/documents/25235045/39994070/Muut+07+fi+-+Huoltajan+suostumus.pdf/759ee9b1-52b5-705b-32ef-055b11b39907?version=1.2&t=1648720607186 (form Poliisi-Muut-07, Finnish edition, revision dated 24.3.2022) — fetched fresh this cycle: HTTP 200, 743,734 bytes, genuine %PDF-1.7 header, no login/CAPTCHA/WAF gate. SHA-256: b693daeb6877300c43ca0a019522c77aef9ae704c7872013b61927bb6f88f31c.
• English bilingual sibling: https://poliisi.fi/documents/25235045/45904321/Muut+07+en+-+Guardians+consent.pdf/79c29be7-5bf0-de1c-dff9-7c0e68543d07?version=1.1&t=1648721040515 (revision dated 28.3.2022) — fetched fresh this cycle: HTTP 200, 789,231 bytes, genuine %PDF-1.7 header. SHA-256: 22110a298416f58dd4b74a2f423f5669bc7586504181d06c50bb87c0013a3fbe. Used only to cross-check field meaning against a readable English rendering, not as the schema's primary source — modelled from the Finnish original, per this registry's preference for the native-language authoritative document.
• Fetch gotcha, disclosed rather than silently worked around: a bare curl request with no User-Agent header, and a URL variant with a duplicated .pdf path segment (a plausible URL shape this registry's own prior scouting pass had used), each returned an HTML "Tila" (Status) error page from poliisi.fi's Liferay-based CMS rather than the PDF. Re-fetching poliisi.fi's own live forms index (poliisi.fi/lomakkeet, poliisi.fi/en/forms) surfaced the current, correct download URLs (above) which succeeded immediately with a realistic desktop browser User-Agent string — not a bot-mitigation/WAF gate, just a stale/malformed URL from an earlier scouting pass.
• Discovery path: poliisi.fi/lomakkeet (Finnish forms index) and poliisi.fi/en/forms (English forms index), both fetched live this cycle, list "Huoltajan suostumus" / "Guardian's consent" under the "Muut" (Other) forms category.

Independent field extraction

Performed fresh with pdfjs-dist@3.11.174 (legacy/build/pdf.js, a throwaway /tmp scratch install, not added to this repo's tracked package.json), on both the Finnish original and the English sibling independently:

• pdf.numPages → 1 (both editions)
• doc.getFieldObjects() → 20 keys; per-page page.getAnnotations() → 20 annotations, all subtype === 'Widget', confirmed on both editions.
• Of the 20 Widget annotations, 4 are non-data UI controls: Tyhjenna1 (a "Tyhjennä lomake" / clear-form button near the top of the page), Tallenna (Save), Tulosta (Print), and Tyhjenna2 (a second, separate "Tyhjennä lomake" clear-form button near the bottom of the page) — confirmed via each widget's own fieldType: "Btn" with no checkBox/ radioButton flag and a null fieldValue, distinct from the real checkbox Btn widgets below. 16 applicant-facing data fields remain, not 17 as an earlier scouting pass (which had informally counted "17 real data fields (+3 UI buttons)") had estimated — that count missed that the form carries two separate clear-form buttons (one top, one bottom), not one; this cycle's own precise widget-subtype count of 4 non-data buttons (not 3) supersedes the earlier estimate.

Checkbox pairs are independent Btn widgets, not PDF radio groups

Every one of the 8 licence/document-type checkboxes (Passikylla/PassiEi, HKkylla/HKei, AAkyllä/AAei, LAkyllä/LAei, and their English equivalents PassportYes/PassportNo, etc.) is confirmed via radioButton: false on every widget to be an independent checkbox, not a member of a genuine PDF radio-button parent field — unlike, for example, fi/dvv/registration-of-foreigner's exclusive-choice groups, which are genuine radio-button parents. Each checkbox's own on-state exportValue is the literal string "Kyllä" ("Yes") regardless of whether it is itself the Yes or No checkbox for its row — e.g. PassiEi ("Passport, No") still carries exportValue: "Kyllä". The semantic Yes/No meaning of each widget is therefore only recoverable from (a) its own alternativeText tooltip (e.g. "Passi, Kyllä" vs "Passi, Ei") and (b) the page's own printed column headers, both independently cross-checked via page.getTextContent() coordinate extraction on both editions:

• Finnish: "Kyllä" printed at x≈183, "Ei" at x≈261, for every one of the four rows (Passi/Henkilökortti/Ampuma-aselupa/Lähtöainelupa).
• English: "Yes" printed at x≈230, "No" at x≈308, for every one of the four rows (Passport/Identity Card/Firearms permit/Explosives Precursor Licence).

This is a real, independently-derived finding (the raw exportValue string alone would mislead a naive reader into thinking every checkbox represents "Yes"), not assumed from the task brief. Each row is modelled as two independent boolean fields (<type>ConsentYes/<type>ConsentNo) plus an exclusivityGroups entry (at most one true), following this registry's own established convention for a printed Yes/No (or multi-option) checkbox-row pattern (se/polisen's travel_document_type group; dk/um/application-for-danish-passport's application_type group) rather than collapsing to a single unconstrained boolean or a single enum field.

Section headers confirmed via text-layer extraction

getTextContent() on both editions confirms the form's own section structure: "Huoltajan suostumus"/"Guardian's consent" (title), "Alaikäisen tiedot"/"Information on minor", "Luvat"/"Licenses" with instruction text "Suostun siihen, että alaikäiselle lapselleni voidaan myöntää seuraavat luvat:"/"My consent for permitting following licenses:", and "Huoltajien allekirjoitukset"/"Signatures of guardians". The footer instruction "Täytä lomake huolellisesti. Puutteelliset tiedot hidastavat asian käsittelyä."/"Carefully fill the form. Incomplete information may slow down the process." is a general completeness admonition, not a specific document-attachment requirement — corroborating the documents[] decision below.

Two guardian blocks: stacked, not side-by-side; single combined signature line

Unlike Sweden's PM 531.2 (whose two guardian-consent blocks and witness blocks are laid out side by side, left/right column), this Finnish form's two "Huoltajien allekirjoitukset"/"Signatures of guardians" blocks are laid out one above the other (confirmed via getAnnotations() widget rect y-coordinates: Nimi_2/Henkilötunnus_2 at y≈399–417 and Nimi_3/Henkilötunnus_3 at y≈314–331, both left-aligned at the same x-position). "first"/"second" in this schema's own field names (firstGuardian*/secondGuardian*) is therefore a document-modelling convention corresponding to top/bottom position, not a label the source itself prints — disclosed explicitly, following the same disclosure pattern this registry's se/polisen sibling already established for its own left/right convention.

Each guardian block carries exactly one combined "Päiväys, paikka ja allekirjoitus"/"Date, place and signature" Tx widget (confirmed via getAnnotations(): a single full-width rect per block, e.g. [57.14, 358.12, 555.89, 375.69] for the first guardian) — not three separate date/place/printed-name fields as Sweden's PM 531.2 sibling prints. This schema models it as one combined string field (firstGuardianDatePlaceSignature/secondGuardianDatePlaceSignature) rather than synthetically splitting a field the source itself does not split.

Second guardian: no synthetic gating field (same judgment call as the Swedish precedent, independently re-confirmed for this form)

Neither language edition of this form prints any sole-vs-joint-custody selector field, nor any prose explaining when a second guardian's consent is required — confirmed by reading the full getTextContent() output of both editions in full (reproduced above; there is no additional prose beyond what is quoted). This is notably more silent than Sweden's PM 531.2, which at least carries explanatory prose ("Vid gemensam vårdnad ska intyget undertecknas av båda vårdnadshavarna") even though it too lacks a selector field to key a requiredWhen condition on.

Per this registry's "spec precision over cleverness" and source-fidelity principles, no synthetic gating field is invented. secondGuardianName/secondGuardianPersonalIdentityCode/ secondGuardianDatePlaceSignature are each modelled as plainly required: false, with no requiredWhen, each field's own description disclosing that a second guardian's consent may be required in practice (e.g. under joint custody) but that neither edition of this form provides any fillable indicator or explanatory text this schema could condition a requiredWhen rule on.

henkilötunnus fields: maxLength only, reusing existing in-jurisdiction precedent

minorPersonalIdentityCode/firstGuardianPersonalIdentityCode/ secondGuardianPersonalIdentityCode use maxLength: 20 with no strict pattern, deliberately reusing this registry's own existing fi/vero/50a-earned-income-and-deductions and fi/migri/residence-permit-employed-person precedent for the Finnish henkilötunnus field (both of which also use maxLength: 20 with no pattern) — a conservative, already-established convention for this jurisdiction, not a new invention this cycle. (This form's own widgets carry no format hint or input mask beyond a plain single-line text box, for either the minor's or the guardians' henkilötunnus fields — confirmed via getAnnotations() rect dimensions and the absence of any maxLen attribute on the field objects.)

Revision-date discrepancy between the two editions (disclosed, not resolved)

The Finnish edition's own footer reads "Poliisi-Muut-07 24.3.2022"; the English edition's own footer reads "Poliisi-Muut-07 28.3.2022" — a real, 4-day discrepancy between the two editions' own printed revision-date stamps, confirmed independently via getTextContent() on both PDFs (not a transcription error in this document). This has no bearing on field content: both editions carry the identical 20 Widget annotations (16 data fields + 4 buttons) in the identical layout, cross-checked field-by-field above. Disclosed here rather than silently reconciled or ignored.

documents[]

This schema has no documents[] array — neither language edition's printed text references any supporting-document/attachment requirement anywhere (the footer's completeness admonition, quoted above, is general, not document-specific), matching the se/polisen/medgivande-pass- nationellt-id-kort-minderarig and dk/fstyr/samtykkeerklaering-koerekort- under-18 precedent of 0 documents for this class of narrow consent-appendix form.

Conformance verification

A one-off checker script (check_conformance.mjs, not committed — ad hoc per this registry's convention) was written to evaluate every fixture in conformance/fi/poliisi/huoltajan-suostumus/1.0.0/ against this schema's fields[] (required/validation.maxLength/validation.minLength) and exclusivityGroups rules (no documents[] rules to evaluate, per above). Results:

| Fixture | Errors | Expected | |---|---|---| | single-guardian-passport-and-id-card.json | 0 | 0 | | two-guardians-all-four-licences.json | 0 | 0 | | mutation-control-missing-static-required.json | 1 (firstGuardianDatePlaceSignature missing) | 1 | | mutation-control-henkilotunnus-maxlength-violation.json | 1 (minorPersonalIdentityCode exceeds maxLength) | 1 | | mutation-control-exclusivity-group-violation.json | 1 (passport_consent both true) | 1 |

All 5 fixtures produced exactly the expected error count. The two valid scenarios cover both the minimal shape (a single guardian consenting to two of the four licence types) and the fully populated shape (two guardians, all four licence types, including exercising the "No" side of one exclusivity pair); the three mutation controls each isolate exactly one rule type (plain required, validation.maxLength, exclusivityGroups) by construction — each 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.

Registry validation

• node tools/validate.mjs registry/fi/poliisi/huoltajan-suostumus/1.0.0/schema.json → ok, 1/1 passed
• node tools/validate-ajv.mjs registry/fi/poliisi/huoltajan-suostumus/1.0.0/schema.json → ok against the v0.3 meta-schema, 1/1 validated
• node tools/verify-sources.mjs registry/fi/poliisi/huoltajan-suostumus/1.0.0 → "1 directory, 3 URLs checked, 0 warning(s), 0 allowlisted, all clear"

Candidates considered and not picked

Three other jurisdictions' open, unscreened verticals were scouted in parallel this cycle before settling on this Finnish candidate:

• Spain (ES) Passport: the main adult flow (policia.es) is confirmed in-person/biometric-only, same dead-end pattern. A companion form does exist — https://www.dnielectronico.es/PDFs/autorizacion_menores_pasaporte.pdf ("Autorización de pasaporte para menores"), a real, unauthenticated, fetchable 2-page PDF with a genuine text layer but zero AcroForm widgets — but its enumerable field set (minor's name; two legal representatives, each with name/DNI-NIE-passport-number/place; an "observaciones" free-text block) is narrower and less self-documenting than the Finnish AcroForm candidate ultimately picked. A viable backlog candidate for a future cycle if Spain's Passport vertical is revisited.
• Argentina (AR) National ID: RENAPER's DNI process is confirmed fully in-person/biometric, with only an internal, office-use "Formulario Único de toma de trámite" (not citizen-fillable) found. The only genuinely open PDF found in this vertical, padron.gov.ar/cne_reclamos/reclamos/formulario_reclamo.pdf (an electoral-roll correction form, not a DNI application), is a weaker fit for the National ID vertical than a direct identity-document application — set aside as a weak candidate, not picked.
• Chile (CL) Passport, Visa, National ID: all three of Chile's remaining open verticals were re-confirmed as dead ends this cycle — Passport and National ID (Registro Civil) are in-person biometric-capture workflows with no application PDF ever published; Visa's former email/paper fallback form (extranjeria.gob.cl) has been discontinued in favor of a strictly ClaveÚnica-login-gated online portal (serviciomigraciones.cl), which itself states applicants must not submit through any other channel.

Scope and jurisdiction notes

This closes Finland's Passport vertical, the sole vertical that remained open for Finland. Finland now stands at 6 of 6 verticals (Business Formation, DMV, Taxes, National ID, Visa, Passport) — no vertical remains open for Finland.