Egyptian Civil Status Record Request Abroad (Registration / Renewal / Issuance / Addition)

Why this candidate

The recurring "GovSchema Standard Research" routine (this cycle, GOV-3462) re-scanned CATALOG.md's own live backlog fresh. The most recently-disclosed open item was the GOV-3447 cycle's own note, made while closing Egypt's Taxes vertical: "Egypt's Business Formation, DMV, Passport, and Visa verticals remain re-confirmed weak/dead per the GOV-3410 cycle; National ID is open, unscreened backlog." The GOV-3410 cycle itself had confirmed Egypt's domestic civil-registry/ID-card channel is a dead end (traffic.moi.gov.eg is WAF-blocked; other moi.gov.eg subdomains are either account-gated or unreachable), so this cycle searched specifically for a channel outside the domestic Ministry of Interior portal — Egyptian consular missions abroad, which other jurisdictions in this registry (e.g. th/mfa/thai-national-id-card-application, mn/gasr/foreign-passport-application) have already established as a legitimate, independently-sourced channel for civic-document processes when the domestic portal is authenticated/gated.

Sources examined

Primary source

• Authority: Consulate General of the Arab Republic of Egypt, London (Ministry of Foreign Affairs, on behalf of the Civil Status Sector, Ministry of Interior), https://egyptconsulate.co.uk/.
• Document — "نموذج: قيد/تجديد/إصدار/إضافة" ("Form: Registration / Renewal / Issuance / Addition").
  • Landing page (directly retrieved, HTTP 200, plain unauthenticated fetch): https://egyptconsulate.co.uk/downloadable-forms/, listed as "Renew – Addition Forms" alongside the consulate's visa, passport, and nationality forms.
  • URL (directly retrieved, HTTP 200, plain unauthenticated curl with a standard desktop User-Agent, re-fetched a second time this cycle to confirm liveness): https://egyptconsulate.co.uk/wp-content/uploads/2021/01/Add.pdf
  • File identity: genuine PDF (%PDF-1.6 header), 78,322 bytes, sha256:7f3f3bf5302b39adfe50fb54737e7452e78d8e2285efacab3b78f9a23bb2e8d1, 1 page, byte-identical across both fetches. The document's own printed header reads "قنصلية جمهورية مصر العربية - لندن - نموذج: قيد/تجديد/إصدار/إضافة".
  • Form type: a genuine AcroForm PDF — 49 /Widget annotations (45 text fields named Text1–Text45, 4 checkbox fields named Check Box1–Check Box4), unlike the static print-layout PDF used for this registry's eg/eta/small-enterprise-tax-declaration.
  • Extraction method: pdfjs-dist@5 (scratch directory, not a repository dependency). page.getAnnotations() gave each widget's field name, type, and rect; page.getTextContent() gave each text item's string plus its transform (x, y) position. Because this is an RTL-typeset document, items were grouped into visual rows by y-proximity and read right-to-left (descending x) within each row to reconstruct the printed reading order, and each widget's rect midpoint was then matched to the row/blank-underscore-run it visually falls within.
  • Rendering attempt — disclosed limitation: attempted to additionally render the page to a PNG via pdfjs-dist + node-canvas for a pixel-level visual check. After fixing an initial Fontconfig load failure (FONTCONFIG_FILE=/paperclip/.config/fontconfig/fonts.conf), the render failed on a different code path than the blank-canvas failure previously disclosed in eg/eta/small-enterprise-tax-declaration's own VERIFICATION.md: a TypeError inside pdfjs-dist's paintInlineImageXObject / drawImageAtIntegerCoords, consistent with this specific PDF embedding an inline background image the sandboxed node-canvas pipeline cannot paint. This is disclosed as a tooling gap (a second, distinct symptom of the same underlying sandboxed-render limitation), not a claim that the source form lacks content.
  • Corroboration in place of a visual render: the semantic field list derived from the text/widget-position cross-reference was independently sanity-checked by summing the widget count each semantic field implies (accounting for multi-widget dates and the two non-widget printed option groups described below) against the PDF's actual widget inventory. The two totals — 45 text widgets and 4 checkbox widgets — matched exactly, which is treated as strong corroboration of the row-to-field mapping despite the render-tooling gap.

No corroborating secondary source was sought for this schema beyond the primary PDF itself: the document is a genuine, directly-fetched, unaltered government-mission intake form with printed Arabic labels legible from the extracted text layer, and its own field semantics (personal/passport/ military/professional/marital/contact/address/relative/attachment particulars) are self-evident from those labels without requiring cross-validation against a second source, unlike the eg/eta schema's Form 25, whose reading-order ambiguity specifically required corroboration.

Scope and disclosed boundaries

This schema models the form's single page in full: the request-type selection; personal particulars (name in Arabic/English, place and date of birth, religion); passport particulars (number, issuing authority, issue and expiry dates); military conscription status; professional particulars (profession on passport, current profession, qualification, specialization, qualification date); arrival date and marital status (plus conditional spouse particulars); contact and address details in the country of residence and in Egypt; a nearest-relative contact in Egypt; two free-text supplementary request-detail lines; the child-addition sub-request (name, date and place of birth); and three free-text attached-document description lines.

Explicitly out of scope, and disclosed rather than silently omitted:

• The applicant's signature, the "لندن في: / /٢٠٠" signing-date line, and the consul's own visa/endorsement block — none of these three areas has an AcroForm widget at all (confirmed: all 45 Text widgets are already accounted for by the fields above), consistent with this being a physically-signed, in-person or postal submission rather than a digitally-submitted one. No corresponding fields[] entries were added for them.
• Egypt's Business Formation, DMV, Passport, and Visa verticals — re-confirmed weak/dead in the GOV-3410 cycle; not re-screened this cycle.

Modelling decisions worth disclosing

• Two printed option groups have no corresponding AcroForm widget: the four request-type labels (قيد/تجديد/إصدار/إضافة) in the header, and the three military-conscription-status options (أداء الخدمـة/إعفـاء مؤقت/إعفـاء نهــائي). The physical form expects these to be marked by hand rather than typed. Both are still modelled as enum fields here (requestType, conscriptionStatus) — the same treatment this registry's eg/eta/small-enterprise-tax-declaration schema gave its own non-fillable businessVolumeBracket selector — since the data is meaningful and part of the form's own printed structure, even though no digital widget backs it.
• Multi-widget dates are collapsed into single date-typed fields. dateOfBirth, passportIssueDate, passportExpiryDate, qualificationDate, and arrivalDate are each backed by 3 separate text widgets on the source form (day/month/year, with dateOfBirth and passportExpiryDate additionally having a literal printed "19"/"20" century prefix before their 2-digit year widget) — modelled as one semantic date field each, consistent with how this registry's eg/eta schema modelled taxPeriodFrom/taxPeriodTo as single date fields rather than separate day/month/year fields.
• relativePhoneNumber1/relativePhoneNumber2 — only two fields, not three. The "رقم الهاتف:" row's text layer shows three period-separated blank segments, but only two AcroForm widgets actually exist at that row's y-position; the field count here follows the true widget count rather than the visually-implied segment count.
• addressInUk is one semantic field despite spanning two widgets. The source form's country-of-residence address blank wraps across two separate ruled underscore lines (two widgets), which is modelled as one logical address string with a generous maxLength rather than two separate fields, since both widgets record the same logical value.
• spouseName/spouseNationality are requiredWhen maritalStatus equals married — a reasonable inference from context (a "spouse" field is only meaningful for a married applicant) rather than an explicit conditional instruction printed on the form itself, disclosed here as an interpretive judgment call.
• childName/childDateOfBirth/childPlaceOfBirth are requiredWhen requestType equals addition — the form's own printed item 3 text ("٣-إضافة نجلي/كريمتي____مواليد____في____") explicitly labels this sub-request as the "إضافة" (addition) case, unlike the generic blank lines 1–2 above it.
• additionalRequestDetail1/additionalRequestDetail2 are free text, modelling the form's own two generic blank declaration lines (items 1–2 under "أرجو التفضل بالموافقة علي:ـــ") that precede the child-addition line (item 3) — the form provides no further printed structure for what belongs on these two lines beyond the general request-approval heading.
• requiredWhen gates use equals, never notEquals against an optional field — following this registry's own established notEquals-empty-string-absent-field bug avoidance practice.

Conformance fixtures

Fixtures are committed under conformance/eg/mfa/civil-status-record-request/1.0.0/: two valid submissions (a minimal single, renewal-type applicant with no spouse/child sub-request; a fuller married applicant filing an addition request with a child, both optional relative-phone fields, and both request-detail lines) plus eight mutation-control fixtures, one per required/requiredWhen/ validation rule exercised: one missing unconditionally-required field (currentProfession); three requiredWhen-gated missing fields (spouse name when married, child name when requestType is addition, child place of birth when requestType is addition); two invalid enum values (maritalStatus, requestType); one below-minLength empty string (fullNameArabic); and one above-maxLength string (additionalRequestDetail1). All ten fixtures (8 mutation + 2 valid) were checked with a from-scratch, throwaway Node mock validator implementing this schema's own required/requiredWhen/validation rules (not committed — consistent with this registry's established per-cycle practice): 10/10 fixtures behaved as expected. Both tools/validate.mjs and tools/validate-ajv.mjs pass across the full registry with this schema added (525/525); tools/verify-sources.mjs, scoped to this schema's directory, reports the cited URL clear.

Known gaps

• No further Egyptian civic-document channel was screened this cycle beyond this consular form; the domestic Ministry of Interior National ID card process (moi.gov.eg) remains confirmed account-gated/WAF-blocked per the GOV-3410 cycle, unchanged.
• This schema's field semantics rest on a position-sorted text/widget-rect cross-reference rather than a pixel-level visual confirmation of the source PDF's layout (see "Rendering attempt" above) — worth a follow-up visual re-check in a future cycle with a working render path.
• The consulate's own broader "Downloadable Forms" page lists companion forms (visa, passport, nationality, "Acquiring Egyptian Nationality", bank details for صندوق تحيا مصر) not modelled here, left as potential future companion-schema candidates if a genuinely new vertical/process is identified among them.

Verification method assessment

manual-source-review-v1 — a human/agent read the primary source directly (both its AcroForm widget inventory and its position-sorted text layer) and transcribed its fields, cross-checking the resulting semantic field count against the source's own widget count as an internal consistency check in place of a visual render (which failed in this sandboxed environment). No automated re-verification tooling exists yet for this schema; nextReviewBy is set 6 months out per the practice's default cadence.