# Verification record — `bg/mvnr/zayavlenie-za-izdavane-na-natsionalna-viza-tip-d` v1.0.0

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-2830**. This schema **advances
Bulgaria's Visa vertical to 2 of 6**, following the Taxes vertical opened in
GOV-2821 (NRA's Form ОКД-5, `bg/nra/deklaratsiya-za-registratsiya-na-samoosiguryavashto-se-litse`,
PR #466) and extended in the same cycle (Обр. 2001,
`bg/nra/godishna-danachna-deklaratsiya-chl-50-zddfl`, PR #467).

## Jurisdiction/vertical screening this cycle

Per this cycle's brief, DMV and Business Formation were screened first as the
likely-strongest remaining candidates, followed by Visa. Both DMV and Business
Formation turned out to be genuine dead ends for a first-party, unauthenticated
fetch this cycle:

- **DMV (МВР/КАТ vehicle registration).** Fetched `mvr.bg`'s own vehicle-
  registration service page directly
  (`https://mvr.bg/opp/административни-услуги/услуги-по-регистрация-на-пс/извършване-на-първоначална-регистрация-на-превозно-средство`
  — HTTP 200 and real page content at the time of this cycle's own screening
  fetch, but a later re-fetch during schema authoring (~20 minutes afterward,
  same session) found this same URL now returns 404 — a genuine
  Cloudflare-served "Страницата не е намерена" page, re-confirmed with
  `curl -v`, not a transient network blip; evidence of `mvr.bg`'s own CMS
  being reorganized or unstable mid-cycle, disclosed here rather than a
  fabricated citation). The page's own procedure text, captured at the time
  of the successful fetch, states plainly: *"Заявлението се генерира от
  информационна система на МВР. Данните са попълнени автоматично.
  Заявителят само проверява данните и удостоверява с подписа си верността им.
  Заявителят не е необходимо предварително да попълва заявление."* ("The
  application is generated by MVR's information system. The data is filled in
  automatically. The applicant only checks the data and certifies its accuracy
  with their signature. The applicant does not need to fill out an application
  in advance.") — a system-generated-at-the-counter form, structurally
  identical to this registry's other MVR/counter-service dead ends (e.g.
  Bulgaria's own National ID, screened weak in GOV-2821). No downloadable
  blank form exists for an agent to fill out independently. Not pursued
  further.
- **Business Formation (Registry Agency / Агенция по вписванията, Commercial
  Register application forms А1-А13).** Fetched `portal.registryagency.bg`'s
  own document-templates page directly
  (`https://portal.registryagency.bg/document-template-cr`, HTTP 200,
  28,925 bytes of static HTML). The page's category sections (e.g. "Заявление,
  влизащо в сила от 30.06.2024 г.", "Б. Заявления за вписване на прокура, клон,
  залог, запор и ликвидация") each render as an empty
  `<div class="group-items group-items-NNN"></div>` in the raw, unauthenticated
  HTML response — the actual template file links are populated client-side by
  JavaScript after page load (confirmed: no `.pdf`/`.doc`/`.docx` href appears
  anywhere in the fetched HTML; `portal.registryagency.bg`'s own bundled
  `js.js` was also fetched and inspected, and contains no discoverable REST
  endpoint pattern; three guessed API-style paths were probed directly and all
  either 404'd or redirected to a generic error page). This is the same
  portal-shell-with-no-static-attachment pattern GOV-2821 already found for
  NRA's self-employed-registration lead on `nra.bg`'s own WebSphere Portal.
  A genuine fetch of the actual A4/etc. template content would require a
  JavaScript-executing browser, which was not attempted this cycle (logged as
  a candidate for a future cycle with browser-rendering tooling, rather than
  falling back to a third-party mirror for a jurisdiction-opening/vertical-
  advancing schema). Not pursued further this cycle.
- **Visa (МВнР, Ministry of Foreign Affairs) — chosen.** Fetched `mfa.bg`'s own
  "Формуляри за виза" (Visa Forms) consular-services page directly
  (`https://www.mfa.bg/bg/uslugi-patuvania/konsulski-uslugi/patuvane-bulgaria/formuliari-viza`),
  which lists both the short-stay Schengen "C" visa specimen and the national
  long-stay "D" visa application, each as a direct PDF download in multiple
  languages, explicitly marked "Безплатен образец" (free specimen). The "D"
  visa application (this schema's source) was chosen over the "C" visa
  specimen because it is Bulgaria's own national long-stay instrument (not an
  EU-harmonized form shared verbatim across all Schengen states, several of
  which this registry already models — e.g. `de/auswaertiges-amt`, `ee/vm`,
  `at/bmeia`), making it the more distinctive and valuable addition. Confirmed
  a genuine, unauthenticated, first-party, plain-text-layer PDF (no
  CAPTCHA/WAF/login gate) — see Source verification below.

## Source verification (independently fetched this cycle)

- **Source page:** `https://www.mfa.bg/bg/uslugi-patuvania/konsulski-uslugi/patuvane-bulgaria/formuliari-viza`
  ("Формуляри за виза") — lists the Bulgarian-language "Type D" national visa
  application as
  `Заявление за виза за дългосрочно пребиваване тип D-BG.pdf`, alongside
  English/Russian/French/Turkish editions of the same form and the separate
  Schengen "C" visa specimen.
- **Fetched file:** `https://www.mfa.bg/upload/137205/%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5%20%D0%B7%D0%B0%20%D0%B2%D0%B8%D0%B7%D0%B0%20%D0%B7%D0%B0%20%D0%B4%D1%8A%D0%BB%D0%B3%D0%BE%D1%81%D1%80%D0%BE%D1%87%D0%BD%D0%BE%20%D0%BF%D1%80%D0%B5%D0%B1%D0%B8%D0%B2%D0%B0%D0%B2%D0%B0%D0%BD%D0%B5%20%D1%82%D0%B8%D0%BF%20D-BG.pdf`
  (percent-encoded form of "Заявление за виза за дългосрочно пребиваване тип D-BG.pdf";
  this schema's `source.url`).
  - **HTTP 200**, `Content-Type: application/pdf`, **144,794 bytes** (matches
    the `Content-Disposition` header's own `size=144794`).
  - **`sha256`:** `427738994b1e3a87ff1d6fa35d1ef8ad2678464d70bb70ac922eb794cfcff932`.
  - `Last-Modified: Tue, 14 Jan 2025 07:56:22 GMT`.
  - **4 pages.** Confirmed via `pdfjs-dist@3` (legacy build, Node.js):
    a genuine text-layer PDF, not a scanned image — every label, checkbox
    glyph (`□`), and table cell extracts as a discrete text-positioned item.
    Zero AcroForm `Widget` annotations on pages 1-3; page 4 carries 2
    annotation entries that are plain (non-form) link/markup annotations, not
    fillable widgets.
  - All 4 pages independently rendered to PNG at 2x scale via `pdfjs-dist` +
    `node-canvas` (`standardFontDataUrl` supplied) and visually cross-checked
    against the text-layer transcript — this confirmed the exact printed row
    counts for the two tabular sections (item 19's children table: exactly 4
    blank rows; item 23's previous-stays table: exactly 3 numbered rows), and
    confirmed the entire right-hand "Попълва се служебно" (to be completed by
    the official) column on pages 1-2 is consular-adjudication-only (receipt
    date/application number/receiving officer, supporting-documents-provided
    checklist, decision, validity, entry count, permitted days) — none of it
    applicant-fillable.

## Extraction method

Text-layer extraction via `pdfjs-dist@3` (legacy build), reusing this
registry's established Node.js + `pdfjs-dist` render/extract technique (see
e.g. `gh/gis`, `jo/cspd`, `rs/mfa` prior cycles). No AcroForm widget
correlation was needed (this source has none, unlike a fillable-PDF AcroForm
specimen) — field boundaries were instead read directly off the printed
numbered items (1-36) and table headers, cross-checked against the page
renders described above.

## Field derivation, by form part

- **Part I — Данни за кандидата (applicant data, items 1-10).** Name (surname,
  former surname(s), given names), date/place/country of birth, current
  nationality with two optional adjoining columns ("nationality at birth, if
  different" and "other nationality"), previous nationalities (free text, "if
  the answer is positive, please state the dates and grounds for
  acquisition/loss"), sex, and residence address with adjoining email/phone
  sub-fields.
- **Part II — Документ за пътуване (travel document, items 11-16).** An
  enumerated document-type field (ordinary/diplomatic/service/official/special
  passport, or other with its own detail field), document number, dates of
  issue/expiry, issuing country, and an optional national ID number.
- **Part III — Семейно положение (marital status, items 17-20).** An
  enumerated marital-status field (with an "other, specify" detail field);
  a spouse/registered-partner identification block, `requiredWhen`
  `maritalStatus` is `married` or `registered partnership` for its five core
  identity fields (former surname and previous nationality kept as
  unconditionally-optional `visibleWhen` companions, per this registry's
  `de/auswaertiges-amt` precedent for supplementary-but-not-mandatory
  conditional fields); a children table modeled as a bounded 4-row repeating
  group (`child1`...`child4`, each with family name, given names, a combined
  date-and-place-of-birth field matching the source's own single printed
  column, nationality, and address) — the exact row count (4) was confirmed
  by rendering the page, not guessed; and a single free-text parental-rights/
  legal-guardian field for minor applicants (the source prints no boolean
  toggle tying this to an explicit age condition, so it is left unconditionally
  optional rather than an invented `requiredWhen` gate).
- **Part IV — Цел на пътуването (purpose of travel, items 21-36).** An
  enumerated purpose field (work/family reunification/cultural activity/
  sport/medical reasons/study/retiree/other, with its own "other" detail
  field); planned arrival date; a previous-Bulgaria-stays boolean gating a
  bounded 3-row table (`previousStay1`...`previousStay3` — row 1's three
  sub-fields `requiredWhen` the boolean is true, rows 2-3 kept as optional
  `visibleWhen` companions, since the source's own three numbered rows are an
  upper bound, not a mandate to fill all three); a residence-elsewhere boolean
  gating permit number/validity/residence-period detail fields; planned stay
  dates; intended place of stay; an intends-to-live-outside-Bulgaria boolean
  and a family-members-traveling-together boolean, each gating its own "please
  specify" detail field per the form's own printed instruction; current
  profession and employer/inviting-organization/school details; free-text
  additional-purpose information; and four Yes/No declarations (prior
  refusal/prior conviction/prior expulsion/notifiable disease), each gating
  its own "if yes, indicate the period and reason" (or equivalent) detail
  field per the form's own printed instruction. Item 36 (funding sources) is
  modeled as two parallel checkbox groups — applicant's own means (with a
  means-of-subsistence sub-checklist: cash, traveller's cheques, credit card,
  prepaid accommodation, prepaid transport, other-with-detail) and sponsor
  funding (with its own sub-checklist: cash, accommodation provided, all
  costs covered, prepaid transport, other-with-detail, plus a dedicated
  boolean for funding by the entity already named in item 30) — none of these
  checkboxes are mutually exclusive on the source, so none are modeled as an
  enum.
- **Signature block.** Place and date; the applicant's signature (name
  standing in for a physical signature, per this registry's `ro/anaf`/
  `ro/dgpci`/`bg/nra` precedent); an optional guardian/legal-representative
  signature line for minor applicants (left unconditionally optional, mirroring
  the `guardianDetails` field above).

108 `fields[]` entries in total, plus 2 `documents[]` entries: the applicant
photograph (the "СНИМКА" box on page 1) and the multi-paragraph data-
processing-consent/truthfulness declaration printed immediately above the
signature block on page 4 (the criminal/administrative-liability and
visa-fee-non-refundable warnings, and the NVIS data-retention notice).

## Scoping and modeling judgment calls

- **Excludes the entire "Попълва се служебно" column.** Every field in the
  right-hand consular-only column on pages 1-2 (application receipt date and
  number, receiving officer's name/signature, the supporting-documents-
  provided checklist, the decision — inadmissible/refused/issued — and its
  validity/entry-count/permitted-days fields) is consular-adjudication-only,
  never filled in by the applicant. Excluded entirely, consistent with this
  registry's `rs/mfa`/`gr/mfa` consular-only-column precedent.
- **Children table bounded to 4 rows, previous-stays table bounded to 3 rows —
  both counts confirmed by rendering, not guessed.** Consistent with this
  registry's established bounded-repeating-group convention (e.g. `ng/nis`'s
  `child1`...`child4`) for a printed table with a fixed number of blank rows,
  rather than modeling an unbounded list type this spec line does not support.
- **No invented `requiredWhen` gates beyond what the form itself prints.** The
  parental-rights/legal-guardian field (item 20) and the corresponding
  guardian signature line have no printed boolean toggle tying them to an
  explicit age condition (the source only carries a parenthetical "(for
  underage persons)"), so both are modeled as unconditionally optional rather
  than gated on a fabricated `isMinor` field that does not exist on the form.
- **Funding-source checkboxes modeled as independent booleans, not an enum.**
  The source's own item 36 layout allows checking any combination of
  applicant-funded and sponsor-funded boxes (e.g. partial self-funding plus a
  sponsor covering accommodation), so none of `fundedByApplicant`/
  `fundedBySponsor`/`fundedByOtherEntity`/`fundedByEntityInField30` or their
  respective means-of-subsistence sub-checklists are modeled as mutually
  exclusive.
- **`travelDocumentType`/`maritalStatus`/`purposeOfTravel` enum values kept in
  English**, consistent with this registry's cross-jurisdiction enum-value
  convention (native-language text lives in each field's `label`); the
  enumerated options themselves are a direct, complete transcription of the
  form's own printed checkbox list for each item.
- **No `edition` axis.** This is a standing national-visa application form,
  not a dated annual filing; consistent with this registry's convention for
  non-time-versioned application forms.

## Conformance run

No PDF/AcroForm widget-count cross-check applies (see Source verification —
this source has zero fillable Widget annotations). In its place, two
hand-authored mock instances were built and checked against `schema.json`'s
own `required`/`requiredWhen`/`validation.enum`/`validation.maxLength` grammar
with a disposable, from-scratch Python checker (not committed, per this
registry's own established practice of not committing one-off verification
scripts):

- **`single-applicant-basic`** — an unmarried applicant with no children, no
  prior Bulgaria stay, no residence in a third country, self-funded via cash,
  filing for work. 33 of 108 fields populated. **PASS.**
- **`married-with-family-and-sponsor`** — a married applicant filing through
  a spouse's employment sponsor, exercising the full spouse-identification
  block, both children (a bounded 2-of-4 use of the children table), one
  prior refusal (Germany, 2016), a residence-elsewhere declaration, two prior
  Bulgaria stays (a bounded 2-of-3 use of the previous-stays table), an
  "other" travel-document type with its own detail field, and full sponsor-
  funding detail. 77 of 108 fields populated. **PASS.**

Four mutation-control checks confirmed the checker actually enforces the
gates rather than passing vacuously: dropping `travelDocumentNumber` from the
first instance (unconditionally required — correctly flagged missing);
dropping `spouseFamilyName` from the second instance while `maritalStatus`
stayed `married` (conditionally required — correctly flagged missing);
setting `sex` to an out-of-enum value (correctly flagged as an enum
violation); and setting `previouslyStayedInBulgaria` to `true` on the first
instance without adding the corresponding `previousStay1From`/`To`/`Place`
fields (correctly flagged all three as missing). Each mutation raised exactly
its one expected error.

```
$ node tools/validate.mjs registry/bg/mvnr/zayavlenie-za-izdavane-na-natsionalna-viza-tip-d/1.0.0/schema.json
ok   registry/bg/mvnr/zayavlenie-za-izdavane-na-natsionalna-viza-tip-d/1.0.0/schema.json
1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/bg/mvnr/zayavlenie-za-izdavane-na-natsionalna-viza-tip-d/1.0.0/schema.json
ok   registry/bg/mvnr/zayavlenie-za-izdavane-na-natsionalna-viza-tip-d/1.0.0/schema.json [v0.3]
1/1 document(s) validated against the meta-schema (ajv 2020-12).
```

`tools/node_modules` did not exist in this worktree at the start of this
cycle; `npm ci --include=dev` installed `ajv`/`ajv-formats` cleanly with no
wipe. `pdfjs-dist`/`canvas` were reused from a pre-existing scratch
installation at `/tmp/pdfscratch` (outside the repo, left over from a prior
cycle's own verification work) rather than installed fresh inside `tools/`,
so this cycle's own extraction tooling could not collide with `tools/`'s
committed dependency set at all.

`tools/govschema-client/registry-index.json` was regenerated via `npm run
build-index` inside `tools/govschema-client/` — see the diff in this PR for
the updated jurisdiction/document counts.

## Scope and jurisdiction notes

- Advances Bulgaria's **Visa vertical** to 2 of 6 (the vertical did not exist
  before this cycle; GOV-2821 opened Bulgaria via Taxes only). DMV and
  Business Formation were screened and found to be genuine dead ends this
  cycle (see above); Passport and National ID (both likely МВР, and National
  ID already spot-checked weak in GOV-2821) remain open, unscreened Bulgaria
  backlog candidates.
- `jurisdiction.level` is `national` — MVnR is Bulgaria's national foreign
  ministry and sole issuer of Bulgarian visas.
- `process.type` is `application`, matching this registry's convention for
  visa application forms (e.g. `de/auswaertiges-amt`, `ee/vm`, `rs/mfa`).
- `process.language` is `bg`: the modeled edition is the Bulgarian-language
  specimen. English/Russian/French/Turkish editions of the same form are
  published on the same source page but not modeled by this v1.0.0.

## Re-verification

Per the practice's cadence, `nextReviewBy` is set to **2027-01-14** (6
months). A future review should prioritize: (1) confirming the source PDF's
`Last-Modified` date (2025-01-14) has not been superseded by a newer edition;
(2) re-attempting Business Formation (Registry Agency's А1-А13 Commercial
Register application templates) with a JavaScript-executing browser, since
this cycle's static-HTML fetch could not reach the actual template files;
(3) whether Bulgaria's remaining unscreened verticals (Passport, National ID)
should be scouted; (4) whether the Schengen "C" visa specimen also hosted on
this same MVnR source page is worth a companion schema, given several other
jurisdictions' Schengen-harmonized visa forms are already modeled elsewhere
in this registry.