Ethiopia Individual Taxpayers Registration Application (TIN Registration)

PATCH 1.0.0 → 1.0.1

GOV-4250 (GOV-4249 review gate follow-up). The 1.0.0 record claimed this schema models 34 fields[]; the actual fields[] array has 38 entries (confirmed via node -e "require('./schema.json').fields.length" → 38, and independently re-confirmed during the GOV-4249 review gate's own pdfjs-dist re-extraction of all 4 pages). Purely a prose correction to a summary count — no field, validation, or structural change of any kind — so this ships as a PATCH per VERSIONING.md's immutability rule rather than editing the published 1.0.0 directory. Every other detail below is otherwise identical to 1.0.0's own record.

Candidate selection

GOV-4246 ("GovSchema Standard Research"). This cycle re-scanned CATALOG.md's own Known Gaps section and By-Jurisdiction table fresh, re-confirmed the routine's 4 standing National ID candidates (DE Steuer-ID, SG NRIC loss/ damage + re-registration, NZ RealMe, remaining voter registration) all remain resolved, and found that Malta (the most recently deepened jurisdiction) had reached 5 of 6 verticals with only Taxes remaining as a confirmed dead end — i.e. essentially exhausted for this cycle. Rather than force a re-screen of a gated Malta Taxes source, this cycle instead scouted 3 single-vertical-published jurisdictions (Georgia, Ethiopia, Uzbekistan — each already in the registry with only its Visa vertical authored) across their 5 remaining verticals apiece, via 3 parallel research passes:

• Georgia: Business Formation (NAPR's downloadable LLC founding-agreement .docx template) came back STRONG; Taxes came back WEAK (a real Ministry-of-Finance-ordered declaration form likely exists in law, but its rendered field content was not pinned down this cycle); Passport and National ID both came back WEAK/DEAD END (prose-only process pages, no downloadable form, real filing is via a login-gated e-service); DMV came back a hard DEAD END (exam-booking only, no form artifact of any kind). Left as disclosed, ready-to-author backlog — see CATALOG.md's Known Gaps section.
• Ethiopia: Taxes (this schema, the Ministry of Revenue's TIN Registration Form) and Business Formation (the Ethiopian Investment Commission's Investment Permit Application) both came back STRONG; Passport came back STRONG-with-caveat (a consular-embassy-mirrored copy of the same underlying form, not the current domestic online-portal variant, worth double-checking before authoring); National ID (Fayda/NIDP) and Driving Licence both remain DEAD ENDs (in-person biometric enrollment only; no field-level downloadable form found for either, confirming the prior cycle's own "weaker" characterization). Business Formation and Passport are left as disclosed, ready-to-author backlog for a future cycle — see CATALOG.md's Known Gaps section.
• Uzbekistan: all 5 remaining verticals confirmed WEAK/DEAD END this cycle. my.gov.uz's services are consistently unauthenticated at the description/overview level but require a login/digital-signature session for any actual field-level form, across Taxes, Business Formation, Passport, National ID, and Driving Licence alike — extending and confirming the prior cycle's own partial finding to cover all 5 verticals, not just some.

Picked Ethiopia's TIN Registration Form as the strongest, cleanest candidate: a directly downloadable PDF served from the Ministry of Revenue's own public /api/forms listing, with no login/CAPTCHA/WAF gate at any point in retrieval. Opens Ethiopia's Taxes vertical (2 of 6; Visa, et/ics/e-visa-application, was already published).

Reaching the live source

Target: https://www.mor.gov.et/Forms/1758114796961-717652740-form-TIN%20Registration%20Form%20For%20individual%2027.7.2017%20-%20Copy.pdf.

• The Ministry of Revenue's own public forms API, https://www.mor.gov.et/api/forms, was fetched directly and lists this form as entry id 8: title "በግብር ከፋይነት ለመመዝገብ (ግለሰብ) የሚቀርብ ማመመልከቻ ቅፅ" ("Application form for registering as an individual taxpayer"), category "የታክስ ከፋዮች ምዝገባ ቅፆች" / "Tax Payers Registration Forms", with a direct pdfFile URL matching the target above.
• mor.gov.et's TLS certificate chain required an insecure-mode (-k) bypass from this sandbox's CA trust store to connect at all, but once connected the served content itself carries no login/CAPTCHA/WAF gate of any kind — confirmed by fetching both the API listing and the PDF itself directly.
• HTTP 200, Content-Type: application/pdf, 1,162,355 bytes.
• sha256 of the retrieved bytes: fc664f2147b2631821535a8a93023f722dd08db66795dcfc9840cb9c0224a292. Independently re-fetched and re-hashed this cycle (not trusted from any prior scouting pass's report alone), consistent with this registry's standing skepticism practice.
• Confirmed mechanically: the retrieved bytes begin %PDF-1.5. All 4 pages return page.getAnnotations() with 0 entries — a flat, print-and-fill specimen, not an interactive AcroForm PDF.

Extraction method

pdfjs-dist's standard getTextContent() API (vendored at /tmp/node_modules/pdfjs-dist/legacy/build/pdf.js, the CommonJS legacy build) decodes both the Amharic and English text cleanly — no custom glyph-index font encoding or ToUnicode CMap workaround needed, the same outcome this registry has now confirmed for every Ethiopian and Maltese flat/scanned PDF screened to date. Text was rendered per page, grouped by y-coordinate row (3-unit tolerance) and sorted by x-coordinate, to reconstruct each bilingual field label in its printed layout position; raw per-item x/y coordinates were also inspected directly to disambiguate section boundaries (e.g. confirming the three Type of Application options are stacked vertically as separate checkbox-style lines, not a single run of text).

Page 1 was independently confirmed to carry 0 extractable text items and only 8 drawing operators (a cover/letterhead page bearing the national emblem, no applicant-facing content) — excluded from field extraction on that basis, not merely assumed empty.

Models 38 fields[] across 6 steps (Registration & Occupation; Personal Details; Additional Personal Details; Residential Address; Business Address; Certification) plus 3 documents[] entries.

Disclosed source-fidelity findings

1. The form's own blanket "fill all fields / use N/A" instruction drives required: true for the great majority of fields. The printed instructions read, verbatim: "Fill all fields ... Mark 'N/A' for not relevant." Because "N/A" is itself a valid literal value satisfying a required: true string field, every field without a more specific printed conditional of its own — including the Ethiopian Digital ID (Fayda) number (a still-rolling-out national program, not yet universally issued, confirmed by this cycle's own separate Ethiopia National-ID scouting pass), and the entire Spouse Name and Business Address blocks (both plainly headed, with no printed marital-status or business-ownership checkbox of their own) — is modelled required: true per this blanket instruction, rather than left optional by an assumption the printed text does not support. This is a deliberate departure from this registry's more typical practice of leaving a plausibly-inapplicable field optional absent a printed gate; here the form's own instruction text explicitly accounts for inapplicability via a literal fill-in value, so required: true is the more source-faithful choice.
2. The two "(For non-Ethiopians)" fields carry a narrower, more specific printed conditional, and are requiredWhen-gated accordingly. Citizenship and Work Permit No. are each printed with the qualifier "(ለውጭ ሀገር ዜጎች) / (For non-Ethiopians)" — a condition narrower than the form's general fill-all/N/A instruction and specific to a fact (non-Ethiopian citizenship) the form does not otherwise ask directly. Modelled as requiredWhen a directly-supplied isNonEthiopianCitizen boolean gate is true — the same directly-supplied-boolean-gate convention this registry's own mt/identita/national-identity-card-application (addressHasChanged) established for a printed conditional with no checkbox of its own. The accompanying workPermitDocument attachment is gated the same way, reflecting the Attachments block's own closing clause, "work permit (for foreigners)."
3. Ethiopian personal-name convention, not a Western surname split. Ethiopian names follow a given-name/father's-name/grandfather's-name convention rather than a Western given-name/surname split. Modelled as firstName/middleName/lastName for both the applicant's own name and mother's name, with lastName representing the paternal grandfather's given name per this convention — disclosed here rather than silently mismatched against a Western surname assumption a consuming agent might otherwise bring to a lastName field.
4. Certification block's "Full Name" line excluded as redundant. Page 4's Certification block reprints a "ስም ከነአያት/ Full Name" line alongside the signature and date; this is excluded as a redundant restatement of firstName/middleName/lastName already captured in Personal Details, rather than modelled as a duplicate field.
5. Office-use reverse side of page 4 excluded as back-office data. The block printed under the heading "በታክስ ባለስልጣኑ ባለሙያ ብቻ የሚሞላ/ TO BE USED BY TAX AUTHORITY ONLY" — the registering officer's name/employee ID/ signature/date, the authorizing official's name/employee ID/signature/ date, the tax-center name, the assigned TIN, and the file number — is excluded in full, since none of it is applicant-supplied.

Conformance

2 valid mock scenarios and 7 mutation-control fixtures committed under conformance/et/mor/individual-tin-registration/1.0.1/:

• valid-ethiopian-trader-with-business-address.json — an Ethiopian citizen, Trader occupation, a real business address, no citizenship/work- permit fields supplied (gate false).
• valid-non-ethiopian-employee.json — a non-Ethiopian citizen (Ghanaian), Employee occupation, citizenship and work-permit number supplied (gate true), the entire Business Address block filled with the literal "N/A" per the form's own fill-all/N/A convention.
• 7 mutation controls: a missing statically-required field (mutation-missing-firstname-required.json); an invalid applicationType enum value (mutation-invalid-applicationtype-enum.json); an invalid occupation enum value (mutation-invalid-occupation-enum.json); a missing citizenship while isNonEthiopianCitizen is true (mutation-missing-citizenship-requiredwhen.json); a missing workPermitNumber while isNonEthiopianCitizen is true (mutation-missing-workpermitnumber-requiredwhen.json); a missing signature (mutation-missing-signature-required.json); and an unknown top-level field (mutation-unknown-field-rejected.json).

An ephemeral, from-scratch conformance checker (deriving required/ requiredWhen rules directly from this schema's own fields[], discarded after use, not committed) ran all 9: both valid scenarios at 0 errors, all 7 mutation controls each raising exactly 1 error, and confirmed every requiredWhen field reference resolves (0 dangling references).

Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (587/587 both), individually and as part of the full registry run. registry-index.json regenerated via npm run build-index in tools/govschema-client/ (586 → 587 entries).