Democratic Republic of the Congo Visa Application

Candidate selection

GOV-5798 ("GovSchema Standard Research"). A prior cycle (GOV-5791) scouted 18 new-jurisdiction candidates in parallel and banked the Democratic Republic of the Congo as one of 16 countries with at least one reachable, unauthenticated candidate document (noted there as "DR Congo Passport and Visa AcroForms"), without authoring any of the 16 (Papua New Guinea's Form A-17 was judged the strongest single candidate that cycle and authored instead). This cycle re-scouted DR Congo specifically and found the Ministère des Affaires Étrangères et Coopération Internationale's (MAECI, Ministry of Foreign Affairs and International Cooperation) own "Formulaire de Demande de Visa / Visa Application Form" — a genuine 83-widget AcroForm distributed unauthenticated by the Embassy of the Democratic Republic of the Congo in Washington, DC — to be the stronger of the two banked candidates (a richer field set than the DGM passport-application track, which was not found as a directly downloadable form this cycle). Opens the Democratic Republic of the Congo as the registry's 102nd jurisdiction, via the Visa vertical (1 of 6).

Reaching the live source

Target: https://www.ambardcusa.org/wp-content/uploads/2018/07/Visas_application_writable.pdf ("Formulaire de Demande de Visa / Visa Application Form," Ministère des Affaires Étrangères et Coopération Internationale, distributed by the Embassy of the Democratic Republic of the Congo in Washington, DC).

• Re-fetched directly: HTTP 200, Content-Type: application/pdf, 601,971 bytes.
• sha256 of the retrieved bytes: ab7c73f01a0cbfdfc32d7bfed7abda4afb672757712e1a4d922219754c9d00cb.
• No login, CAPTCHA, or WAF gate on the asset itself. The bare ambardcusa.org domain root now 301-redirects to ambadrcusa.org (a rebrand/consolidation of the embassy's own site since this file was first published in 2018), but the direct asset path (/wp-content/uploads/2018/07/...) continues to resolve on the original host with no redirect — confirmed directly this cycle, not assumed.
• The Ministry's own national site, https://diplomatie.gouv.cd, is live (HTTP 200) and is used as authority.url; the specific visa-application PDF was not found hosted there directly, consistent with this registry's established pattern of consular/embassy-hosted distribution for a national ministry's own form (see e.g. ng/nis/application-for-visa-entry-permit, sourced the same way from an embassy mirror of a Nigeria Immigration Service form).
• Confirmed mechanically via pdfjs-dist: the document is a genuine AcroForm (not a flat/print-and-fill specimen) with 2 pages, 58 form-field annotations on page 1 and 25 on page 2 (83 total raw widgets — Btn checkboxes and Tx text fields), each carrying an internal PDF field name independently extracted via page.getAnnotations().

Extraction method

pdfjs-dist (getAnnotations() for the 83 raw form-field widgets; getTextContent(), row-grouped by y-coordinate and sorted by x-coordinate per page, for the surrounding printed labels/instructions/footnotes) — no glyph-index or canvas rendering workaround was needed; the embedded fonts decode cleanly to readable French/English text. Each raw widget was matched to its printed label and numbered item (1–16 on page 1, unnumbered continuation plus Items 1–5 on page 2) by cross-referencing its rect (x, y) coordinates against the nearest text row.

Field modelling and disclosed findings

Models 60 fields[] across 7 steps mirroring the form's own numbered sections (Section B Items 1–16 on page 1, continuing unnumbered onto page 2 before its own numbered Items 1–5), 3 documents[] entries (2 supporting documents from Section A's own attachment checklist, 1 attestation from the Item 5 declaration), and 1 crossFieldValidation rule.

Disclosed findings, all confirmed directly against the raw annotation/text extraction rather than assumed:

1. No printed required/optional signal anywhere on the form. Unlike several sibling schemas in this registry (e.g. Identità-family asterisk conventions), this form marks no field as mandatory or optional with any printed symbol — footnote markers (1) through (8) are cross-references to explanatory notes, not requiredness signals. Every field's required/optional status here is a disclosed domain judgment call: core identity, passport, purpose-of-travel, and visa-type questions (the form's own numbered items 1–16) are modelled required; supplementary family/contact detail not itself numbered as its own item (email, father/ mother's name and nationality, spouse detail when inapplicable, residency card, prior DRC visa, travel-supporting-document reference, place of mission, visa processing period) is modelled optional.
2. Two internal PDF field names are reused/mismatched across the document, a source-side authoring artifact rather than a schema modelling choice:
   • The residency card's own "Date d'expiration" line (Item 13, page 1) is internally named voyage a specifier — the same internal name used correctly elsewhere on the same page for Item 11's genuinely distinct "Autres types de titre de voyage à spécifier" field. Disambiguated here by rect position (y≈255 vs. y≈332), not by the internal field name; modelled as residencyCardExpiration, distinct from otherTravelDocumentTypeDetails.
   • The "Transit" radio checkbox itself (the only one of the form's four visa-type options — Transit / Une seule entrée / Deux entrées / Multiples entrées — implemented as an independent Btn widget rather than one bound radio group) is internally named Aller Du, reusing the label of its own first date sub-field rather than "Transit." Confirmed by rect position (y≈90, aligned with the "Transit a. Aller du/Depart from" text line, distinct from the Transit Aller du text-field widget at the same row). Modelled as one value (TRANSIT) of the visaType enum, consistent with how this registry already collapses the form's other independent-checkbox-implemented single-choice groups (maritalStatus, passportType, purposeOfTravel) into a single enum field each — nothing in the live PDF technically prevents multiple checkboxes from being ticked at once in any of these four groups, but the form's own layout and instructions present each as a single choice.
   • A minor, separate spelling inconsistency: the "Multiples entrées" internal field name for the group's own two date pairs is inconsistent between Multiples entrees (first pair) and Multiple entrees (second pair, singular). Disclosed, not corrected; both pairs are modelled as multipleEntriesFirstFrom/To and multipleEntriesLastFrom/To.
3. **Footnote (3) ("joindre la photocopie du visa de voyage dans le pays de la dernière destination/Please attach a copy of the travel visa for the country of final destination") has no inline reference point anywhere on the form* — confirmed by searching every extracted text item across both pages for the substring; it appears only once, in the footnote-definitions block itself at the bottom of page 2. Unlike every other footnote ((1), (2), (4), (5), (6), (7)), which each have a confirmed inline (n) marker next to the item they annotate, (3) is orphaned. Not modelled as a field or document, since its intended attachment point cannot be determined from the source; disclosed rather than guessed. Footnote (*8) (embassy index/registration-number convention for the visa number) is likewise unreferenced inline, but its own text makes clear it belongs to the chancery-only section (see below), so it is excluded for that reason rather than treated as a second orphan.
4. hasSponsor is a directly-supplied gate, not itself a printed checkbox. Page 2's own Items 2–3 distinguish a sponsored traveller (providing an inviting individual/legal entity's name, address, phone number, and a "Garantie de la prise en charge") from a self-funded traveller (providing "Preuves des moyens de subsistances" instead), but the form prints no single yes/no control selecting between the two paths — the applicant's own choice of which block to fill is the only signal. Modelled as a boolean gate, the same convention this registry's mt/identita/long-stay-visa-application established for its own hasHostInMalta, with sponsorName/sponsorAddress/ sponsorPhoneNumber/sponsorshipGuarantee each requiredWhen hasSponsor equals true and proofOfFinancialMeans requiredWhen hasSponsor equals false.
5. The "SECTION À REMPLIR PAR LA CHANCELLERIE / SECTION TO BE FILLED OUT BY CHANCERY" (visa application number, chancery officer's own notes, chancellor's signature) is excluded entirely — it is completed by embassy staff processing the application, not by the applicant, consistent with this registry's convention of modelling only the applicant-facing side of a government process.
6. Bilingual French/English source, no discrepancy found. Every label extracted and quoted in sourceRef above prints both languages side by side on the form itself (e.g. "Nom / Name," "Date de naissance/Date of Birth"); the two language versions of every label were cross-read against each other during extraction and found consistent throughout, with no translation mismatch.

Conformance testing

2 valid mock scenarios (a single, unmarried business traveller requesting a single-entry visa, self-funded with no sponsor; a married traveller requesting a multiple-entry visa, sponsored by an inviting organisation, with an "Autres" passport type requiring a specified travel-document detail) plus 8 mutation-control fixtures (a missing statically-required field; a missing spouseName while maritalStatus is MARRIED; a missing otherTravelDocumentTypeDetails while passportType is OTHER; a missing transitDepartureFrom while visaType is TRANSIT; a missing sponsorName while hasSponsor is true; a missing proofOfFinancialMeans while hasSponsor is false; an invalid maritalStatus enum value; an unknown top-level field), committed under conformance/cd/maeci/visa-application/1.0.0/. An ephemeral, from-scratch conformance checker (deriving required/requiredWhen rules directly from this schema's own fields[]/documents[], discarded after use, not committed) ran all 10: both valid scenarios at 0 errors, all 8 mutation controls each raising exactly 1 error, confirmed every requiredWhen field reference resolves (0 dangling references), and confirmed the single crossFieldValidation rule (dateOfExpiration after dateOfIssue) holds on both valid scenarios. Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs, individually and as part of the full registry run.