# Verification record — `ee/vm/long-stay-visa-application` v1.0.0 This file is the **source-review record** for this document version, per the [`manual-source-review-v1`](../../../../../practices/manual-source-review-v1.md) practice. ## Current claim - **`status`:** `draft` - **`verification.method`:** `manual-source-review-v1` - **`verification.lastVerifiedAt`:** `2026-07-09` - **`maturity.level`:** `structural-reference` ## Why this cycle picked up Estonia's Visa vertical This is the recurring "GovSchema Standard Research" cycle (GOV-1970). Estonia already had 5 of 6 verticals (Passport, DMV, Business Formation, Taxes, National ID, opened via GOV-1698/1705/1712/1721/1728) — Visa was its last remaining gap, and CATALOG.md's jurisdiction table already flagged `EE Visa` as `✗` while its "Known Gaps" prose section did not yet mention Estonia at all, i.e. a fresh, previously unscreened gap rather than a reconfirmed dead end. ## Sources examined - **Document `(id, version)`:** `ee/vm/long-stay-visa-application` / `1.0.0` - **Spec version:** GovSchema `0.3.0` - **Authority:** Ministry of Foreign Affairs (Valisministeerium, VM). - **Overview/document-checklist source:** , fetched live (HTTP 200, no gate). Confirms the application is generated via an online wizard (not a static PDF), states the visa is valid up to 365 days within 12 consecutive months, lists the required-documents checklist used for this schema's `documents[]` entries, and publishes an official "Purpose of the trip" financial-means table (Studies, Doctoral studies (PhD), Short term employment, Short term employment in Start-up company, Seasonal work, Start-up business, Teleworking (digital nomad visa), and a general "for all other applicants" row) that was used only as a cross-check, not as the schema's own `purposeOfJourney` enum (see below — the wizard's own dropdown uses a materially different, coarser 8-category list). - **Primary field-by-field source: the live wizard itself, all 13 pages, independently walked with a real browser.** Page 1 () is reachable by plain `curl` (HTTP 200, server-rendered, session token embedded in the URL path, "Page 1/13") and asks for an email address plus a CAPTCHA image code — a genuine bot-mitigation gate, not completable by a static fetch. This cycle used the `agent-browser` skill (a real headless Chromium session driven via Playwright, with the `/paperclip/chrome-sysroot` shared libraries) to load the CAPTCHA image, read its characters directly, and submit page 1. Because the wizard's session state does not survive a client disconnect through Playwright's own multiplexed `launchServer`/ `chromium.connect()` protocol (contexts are torn down server-side on disconnect), the browser was instead launched with `--remote-debugging-port` and driven across multiple separate tool calls via `chromium.connectOverCDP()`, which does preserve state across reconnects. Every one of the 13 pages was then filled with plausible mock data and submitted in sequence (with two negative round-trips — page 6's phone field rejecting a `+` prefix with "Forbidden symbols in text fields," and page 7's `visaEndDate` rejecting a value more than 12 months after `visaStartDate` with "The period of validity of a D-visa cannot exceed 12 months (1 year)" — both confirmed live and reflected in this schema), reaching the final page 13/13 confirmation screen (its exact 4-paragraph consent text is reproduced in the `declarationOfAccuracy`- equivalent attestation below). The application was **not** submitted for printing, to avoid registering a real application record with fabricated data. Field names/ids, labels, full enum option text (including the purpose-of-journey and marital-status radio lists, and the EU-relative relationship options), and structural details (e.g. the two-column applicant/sponsor means-of-support matrix, the structured employer/host/ accommodation/home address blocks) were all read directly from the live DOM and screenshots, not inferred. - **Secondary source (cross-check only):** , a relocation firm's field-by-field walkthrough of the same 13 wizard pages (written for a Wise Payments employee's employment-purpose D-visa, and separately describing the family-visit-purpose alternative). Its "Page N/13" wording, page ordering, and the two purpose labels it names ("Short-term employment" / "Visiting family or friends" — matching this schema's `short-term-employment-in-estonia` / `visiting-family-or-friends` enum values) match the live wizard exactly, corroborating it as reliable for the one detail this cycle's own live walkthrough did not independently field-name-verify: the host-**person** (rather than host-company) variant of page 9, since the live walkthrough exercised page 9 only via the "Business" purpose branch (see "What is NOT modelled" below). The blog also describes an "insurance end date" field as part of the same page as financial means (its own step 11, corresponding to page 10); this was **not** observed on the live page 10 for the "Business" purpose branch tested, so it is not modelled here — flagged as a possible purpose- conditional field not independently confirmed, rather than invented (see "What is NOT modelled" below). - **Duplicate-detection comparison.** Per this registry's established convention (Poland's, Portugal's, and Switzerland's national D-visa forms were each found to be field-for-field duplicates of `de/auswaertiges-amt/national-visa-application`, while Spain's and the Czech Republic's were each independently confirmed genuinely distinct), this wizard's full field sequence was compared against the German template's `schema.json` before authoring. **Verdict: genuinely distinct, not a duplicate.** The two forms share only the shape of their opening identity/travel-document items (name, date/place of birth, nationality, sex, marital status, travel-document type/number/dates) — a Schengen-harmonized convention common across every EU member state's national long-stay visa form in this registry. Estonia's wizard then diverges sharply: an EU/EEA/Swiss-citizen-or-UK-Withdrawal-Agreement close-relative section (page 5) with the relative's own passport/ID number and date of birth, which Germany's form has no counterpart for at all; a mandatory current-or-previous employment-or-education block (page 6) with a full structured employer/school address (street/house/ apartment/postal code/city/county), where Germany's form only asks a "trade or profession trained for" free-text pair; a two-column (applicant vs. sponsor) means-of-support checkbox matrix (page 10 — cash, credit card, accommodation provided/prepaid, transport prepaid, salary, other, independently repeated for both columns) distinct from Germany's single free-text `meansOfSubsistence` field; a host organization/person section (page 9) with its own registration code and a named contact person, which Germany's form has no counterpart for; and its own 8-category purpose-of-journey taxonomy (Business, Medical reasons, Study, Short term employment in Estonia, Visiting family or friends, Remote working, Startup enterpreneurship [sic], Other) sharing no labels with Germany's 6-category list (Employment, Study, Au pair, Language course, Family reunion, Other). Conversely, Germany's form has several sections entirely absent from Estonia's wizard: an unconditional father/ mother identity block, a `previouslyInGermany`/accompanying-family-members question, and criminal-conviction/notifiable-disease declarations. Net: a genuinely distinct national wizard sharing only its opening Schengen-harmonized item shape with Germany's, not a field-for-field republication of it — authored as its own schema, consistent with the Spain/Czech Republic precedent rather than the Poland/Portugal/ Switzerland duplicate precedent. - **Companion Schengen (short-stay) visa form.** Not examined this cycle; Estonia's own Schengen short-stay visa process was not in scope for this gap (this document closes the long-stay/national Visa gap specifically). A future cycle could screen it against `fr/france-visas/schengen-visa-application` following this registry's established convention. - **Retrieved / reviewed:** 2026-07-09. - **Reviewer:** GovSchema Engineering (Standards Engineer — initial authoring source review). ## What the wizard's 13 pages map to - **Page 1/13** (email + CAPTCHA) — a wizard session-identification/ bot-mitigation mechanic, not modelled as an application-content field (the same treatment this registry gives other portal/session-routing steps, e.g. `de/auswaertiges-amt/national-visa-application`'s excluded Bund ID account-registration gate). The applicant's own contact email is instead modelled from page 12's distinct, explicitly-labelled "E-mail address of the applicant or their contact person for forwarding notifications regarding the application" field (`contactEmail`), which is a documented part of the application record rather than a session mechanic. - **Page 2/13** (names, date/place of birth) → `surname` through `cityOfBirth`. `formerNames` was observed live as a **required** field (unlike `de/auswaertiges-amt/national-visa-application`'s optional `formerSurname`) — the wizard offers no "not applicable" option for it, unlike the adjacent surname/first-name "absent in travel document" checkboxes, so an applicant with no former names may need to enter a placeholder; flagged in the field's own `description` rather than silently marking it optional against what was actually observed. - **Page 3/13** (nationality, sex, marital status) → `nationality` through `maritalStatusOtherDetails`. The "Other citizenships" control is a multi-select list of all countries; per GSP-0009 (no array/repeating- field type in GovSchema v0.3), collapsed into one free-text `otherCitizenships` field. - **Page 4/13** (travel document) → `travelDocumentType` through `travelDocumentValidUntil`. - **Page 5/13** (EU/EEA/Swiss/UK-Withdrawal-Agreement close relative) → `euRelativeAccompanying` through `euRelativeTravelDocumentNumber`, all `requiredWhen euRelativeAccompanying` is `true`. This section has no counterpart in `de/auswaertiges-amt/national-visa-application` or `cz/mzv/zadost-o-udeleni-dlouhodobeho-viza`. - **Page 6/13** (profession, current occupation, employer/school and its full structured address) → `profession` through `employerOrSchoolPhone`. `profession` is modelled as free text rather than an enum: the wizard's own dropdown offers a long standard occupation list (a sample of 14 options was confirmed live, e.g. Administrative/technical/service staff, Architect, Artist, Banker, ... Electronics expert) but the full list was not exhaustively captured, and GovSchema convention (see e.g. this registry's coded-country-field treatment) is to model as free text rather than publish a truncated/incomplete enum. - **Page 7/13** (duration and dates) → `intendedStayDurationDays` through `visaEndDate`. The "Member State of destination" line is a static, pre-filled, non-interactive display of "ESTONIA" on the live page (no ``/`