Slovenia — Consular Personal ID Card Application (DKP)

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-14
• maturity.level: structural-reference

This is GovSchema Standard Research cycle GOV-2928 (parent GOV-2925, "GovSchema Standard Research"). This schema advances Slovenia's National ID & Civic Documents vertical via MZEZ's consular-channel personal-ID-card application, the sibling deliverable to the same cycle's consular passport application (si/mzez/vloga-za-pridobitev-potnega-lista, GOV-2927) — same MZEZ diplomatic-mission (DKP) application family, scoped to the ID-card (osebna izkaznica) pathway instead.

Source verification (independently re-fetched and re-derived this cycle)

• Fetched file: https://www.gov.si/assets/ministrstva/MZEZ/Dokumenti/konzularne-zadeve/oddelek-za-varstvo-interesov-slovencev/IO-obrazec-vloge.pdf — re-fetched fresh this cycle, not reused from any cached copy.
  • HTTP 200, Content-Type: application/pdf, 116,487 bytes.
  • sha256: 94d121358473a27684b87de61418ff8646590bdcfaf629e91dbff94687046a85 (computed directly against this cycle's own freshly-fetched bytes) — matches the issue brief's own claim exactly.
• Extracted with pdfjs-dist (getFieldObjects() and page.getAnnotations() per page). Confirmed 1 page and 31 real /Widget fields, exactly matching the issue's own claim. All 31 are text (Tx) fields; no checkboxes/radio groups/choice fields exist on this form. getFieldObjects()'s own field-name count (31) matched the widget count exactly, so no non-terminal-node reconciliation was needed.
• Every one of the 31 fields extracts with a generic AcroForm field name (undefined, undefined_2, ... undefined_31), confirming the issue brief's own caveat. Coordinate-correlation (below) was required to assign every field's real identity.
• Also independently rendered page 1 to a PNG image via pdfjs-dist + node-canvas (scale 3.0) and visually cross-checked the printed layout against the coordinate-correlation reasoning below, including several close-cropped zooms of specific regions to confirm exact caption text (see "TIP OI" discovery below).
• Cross-checked the Bern-embassy mirror the issue cites (gov.si/assets/predstavnistva/bern/dokumenti/Obrazec_vloge_OI.pdf, sha256 8552be8c... per the issue) only by relying on the issue's own claim of 0 widgets (a flattened scan) — not re-fetched independently this cycle, as it is out of scope (the MZEZ-hosted 31-widget version is the canonical source).

Coordinate-correlation method

Every field's rect (page.getAnnotations()) was compared against the page's own text layer (page.getTextContent()), using the same ~5.6–6.4pt vertical-offset pattern established by the passport sibling schema's own VERIFICATION.md: a single-line field's rect bottom (y0) sits just above its own printed caption immediately below it (e.g. field 36R's y0=566.16, caption "REGISTRSKA ŠTEVILKA" at y=560.4, offset 5.76 — reproduced across every single-line personal-data field). For multi-line blocks, a caption sits between an above-line and one or more below-lines (e.g. "STALNO PREBIVALIŠČE" at y=463.2, with field 43R directly above at y1=469.08 and fields 44R/45R continuing below at y1=463.32/y1=444 respectively — a 3-line address block). The rendered page image visually confirmed every correlation, including a discovery not apparent from the text layer alone (below).

The "TIP OI" / "DRŽAVLJANSTVO" discovery

The rendered PNG showed two printed captions with their own underlines — "TIP OI" (beside "VRSTA OSEBNE IZKAZNICE") and "DRŽAVLJANSTVO" (beside "SPOL") — that do not appear anywhere in getTextContent()'s output (confirmed by an exhaustive dump of every text item on the page; neither string appears). Cross-checked against getAnnotations(): no widget rect exists at either caption's position. This means these two blanks are printed guidance lines with no backing AcroForm field at all — not missed by extraction, genuinely absent from the form's fillable structure. Both are excluded from this schema's fields[] (there is nothing to model); see this schema's own field list, which has no idCardTypeCode or citizenship entry. This is a genuine structural difference from the passport sibling specimen, whose own equivalent row does carry a real DRZAVLJANSTVO widget (self-describing AcroForm field name, confirmed via the passport sibling's own widget dump) — different specimens, not a missed field on this one.

Cross-reference against the passport sibling specimen

The passport sibling schema's own source PDF (a different, 27-widget specimen from the same MZEZ family, with self-describing AcroForm field names rather than this specimen's fully generic ones) was used as a cross-check for several otherwise-ambiguous captions on this specimen, since the two forms share near-identical administrative-tracking rows:

• The passport specimen's widget at the position equivalent to this specimen's field 46R carries the self-describing name SERIJSKA ŠTEVILKA — confirming 46R's own coordinate-correlated caption reading ("Serijska številka").
• The passport specimen's widget at the position equivalent to this specimen's field 48R carries the self-describing name FUNKCIJA DRZAVA (function/country, double space in the raw field name). This specimen's own text layer shows only "FUNKCIJA" (no "DRZAVA") at the equivalent position — a genuine per-specimen difference, not an extraction gap (confirmed by an exhaustive text-layer dump finding no "DRZAVA"/"DRŽAVA" string anywhere on the page).
• The passport specimen's own signature-instruction box ("Podpišite se znotraj označenega mesta") and photo-instruction area ("Prilepi fotografijo") have zero corresponding widgets (per that schema's own VERIFICATION.md, judgment call 5). On this specimen, the signature box does have a real widget (field 35R, the large box at the top of the form) — confirmed independently via this cycle's own getAnnotations() dump, not merely inferred from the passport's absence. The photo area ("Prilepi fotografijo") has no widget on this specimen either, matching the passport sibling.
• A close crop of the office-signoff row confirmed this specimen's field 58R caption reads "PODPIS URADNE OSEBE, ki je prejela OI" (signature of the official who received the ID card) — explicitly including "URADNE" (official). This differs from the passport sibling's own equivalent field, captioned "PODPIS OSEBE ki je prejela potno listino" (signature of the person who received the passport, without "uradne"), which that schema models as the applicant/recipient's own signature. Given the explicit "URADNE OSEBE" wording confirmed by direct visual inspection of this specimen, field 58R is modelled here as cardReceivingOfficialSignature (an office-only field, distinct in kind from the passport sibling's recipientSignature), not copied blindly from the sibling's naming.

Field inventory

All 27 fields[] entries and their exact source-form section/label reference are listed inline in schema.json's own sourceRef per field. Every one of the 31 AcroForm widgets is accounted for by exactly one fields[] entry, with three fields each spanning multiple widgets (permanentResidence: 3 widgets; legalRepresentativeResidence: 3 widgets) and the remaining 25 fields each mapping 1:1 to a single widget:

| Source field (by rect position) | Modelled as | Notes | |---|---|---| | 34R (top box, above "Naziv DKP") | dkpName | Caption below the box | | 35R (top-right bordered signature box) | applicantSignature | Caption above the box ("Podpišite se znotraj označenega mesta") | | 36R | registrationNumber | Caption below the box ("REGISTRSKA ŠTEVILKA") | | 37R | idCardType | Caption below the box ("VRSTA OSEBNE IZKAZNICE") | | 38R | emsoOrBirthDateAndSex | Caption below the box | | 39R | sex | Caption below the box ("SPOL") | | 40R | surname | Caption below the box ("PRIIMEK") | | 41R | givenName | Caption below the box ("IME") | | 42R | placeOfBirth | Caption below the box ("ROJSTNI KRAJ") | | 43R/44R/45R | permanentResidence | Caption between line 1 (above) and lines 2–3 (below) | | 46R | officialSerialNumber | Caption below the box ("SERIJSKA ŠTEVILKA"); cross-confirmed against passport sibling | | 48R | officialFunction | Caption below the box ("FUNKCIJA"); cross-confirmed against passport sibling | | 47R | applicationDate | Caption below the box ("DATUM VLOGE") | | 49R | validityDate | Caption below the box ("DATUM VELJAVNOSTI") | | 50R | legalRepresentativeName | Heading below the box ("PRIIMEK IN IME ter podpis zakonitega zastopnika") | | 51R | legalRepresentativeSignature | Same heading, second line | | 52R/53R/54R | legalRepresentativeResidence | Heading between line 1 (above) and lines 2–3 (below) | | 55R | receivingOfficialSignature | Caption below the box | | 56R | deliveryMannerAndDate | Caption below the box | | 57R | deliveringOfficialSignature | Caption below the box | | 58R | cardReceivingOfficialSignature | Caption below the box; see cross-reference discussion above | | 59R | receiptRegistrationNumber | Receipt-stub section | | 60R | receiptEmsoOrBirthDateAndSex | Receipt-stub section | | 61R | receiptSurname | Receipt-stub section | | 62R | receiptGivenName | Receipt-stub section | | 63R | receiptApplicationDate | Receipt-stub section | | 64R | receiptOfficialSignature | Receipt-stub section |

Judgment calls

1. Every widget-backed field is modelled, including office-only ones, marked required: false rather than omitted. registrationNumber, idCardType, officialSerialNumber, officialFunction, applicationDate, validityDate, both officials' signature fields, the delivery-manner field, and the entire six-field receipt stub are all completed by DKP staff during/after processing, not by the applicant at submission time. This mirrors the passport sibling schema's own established convention (its judgment call 3) for the same reasoning: model faithfully, mark optional, describe who completes each one.
2. idCardType and officialFunction/officialSerialNumber classified as office-completed based on 13. člen ZOIzk-1's own explicit content ordering. The Zakon o osebni izkaznici (ZOIzk-1) prescribes this document's content in a fixed order: issuer mark/name, registration number, serial number, ID-card type — all four listed together, ahead of the applicant's own personal-data fields (EMŠO, surname, given name, permanent residence). This registry reads that grouping as the law's own confirmation that these four are issuer/administrative content, not applicant declarations, and models them accordingly.
3. sex modelled as required: true, distinct from emsoOrBirthDateAndSex. Unlike the passport sibling specimen (which has no separate sex widget), this specimen prints "SPOL" as its own field beside the EMŠO/birth-date field. Since a personal ID card always records sex regardless of whether EMŠO is known, this is modelled as unconditionally required, not gated to the EMŠO-absent case implied by the neighbouring caption's own parenthetical.
4. Legal-representative block modelled as unconditionally optional. Consistent with this registry's established convention for this pattern (see bg/mvr/zayavlenie-za-izdavane-na-pasport's guardian block and the passport sibling's own identical treatment): the form prints no explicit boolean gate tying the legal-representative fields to a specific applicant condition (e.g. minor status), so no invented requiredWhen condition is added.
5. Multi-line address blocks modelled as a single field each. permanentResidence and legalRepresentativeResidence each span three printed lines but are modelled as one string field apiece, per this registry's established convention (e.g. bg/mvr's own address field) — chosen deliberately over the passport sibling's own lower-confidence, internally-inconsistent line-splitting for its analogous fields (that schema's own judgment call 1 self-discloses this as a lower-confidence mapping).
6. Signature fields modelled as type: string. Every "PODPIS ..." field is a plain AcroForm text widget (not a documents[] image attachment), so each is modelled as a string field standing in for a physical signature — this registry's established convention for paper-form signature blocks.
7. applicantPhoto modelled as a documents[] entry despite no corresponding AcroForm widget. "Prilepi fotografijo" (paste photo) is printed guidance with no fillable field of any kind (confirmed: no widget exists in the relevant page region), describing a physical, in-person completion step. This registry's documents[] category exists precisely to record such required non-field attachments (e.g. bg/mvr's own applicantPhoto/signatureSpecimen entries), so one is included here — a deliberate departure from the passport sibling schema's own choice to omit any documents[] entry for its equivalent instruction.
8. TIP OI and DRŽAVLJANSTVO captions excluded entirely, not modelled with required: false. Unlike the office-only widget fields above, these two captions have no backing AcroForm widget at all on this specimen (confirmed via getAnnotations()) — there is nothing to model, per this registry's "don't invent a field with no widget behind it" precision principle. See the "TIP OI" discovery section above.

Dead ends confirmed this cycle (not re-screened, carried from the issue brief)

See the passport sibling child issue (GOV-2925 research) for Slovenia's DMV and Visa dead-end evidence — both confirmed 0-widget/duplicate this cycle.

Conformance

• node tools/validate.mjs — passes (438/438).
• node tools/validate-ajv.mjs — passes (438/438 against the v0.3 meta-schema).
• tools/govschema-client/registry-index.json regenerated via npm run build-index and diffed — only this document's entry added.

GovSchema is an independent, non-profit standards body and is not affiliated with, endorsed by, or operated by the Government of Slovenia or the Ministrstvo za zunanje in evropske zadeve.