Kenya Application for Identity Card (Form Reg. 136A)

This file is the source-review record for this document version. It documents the provenance of the published fields/documents and states the current verification claim honestly.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-12

This is GovSchema Standard Research cycle GOV-2500. It opens Kenya's National ID & Civic Documents vertical (2 of 6), via Form Reg. 136A, "Ombi ya Kitambulisho / Application for Identity Card", prescribed under the Registration of Persons Act, Cap. 107.

Vertical scouting (Kenya's five remaining open verticals)

Kenya was opened last cycle (GOV-2493, Business Formation, 1/6). This cycle screened all five remaining verticals in parallel before choosing where to author:

• Passport — Directorate of Immigration Services, operating entirely through eCitizen (dis.ecitizen.go.ke). The current 2026 ePassport flow is online-application-then-mandatory-in-person-biometric-capture; the one legacy AcroForm found (a bilingual "Form 19 (Revised 2012)", 88 widgets, hosted only on an embassy mirror) is a superseded pre-digital specimen, not confirmed as the current authoritative artifact — the classic "strong AcroForm superseded by mandatory e-channel" dead end (cf. GOV-2449's note on Thailand). Dead end.
• DMV — NTSA. Both driving-licence application/renewal and vehicle-registration/transfer are now exclusively handled through the login-gated NTSA TIMS/eCitizen portal with mandatory in-person biometric capture for licences; "NTSA Form C" (Traffic Act, Cap. 403 §9) still circulates on third-party mirrors as a 0-AcroForm-widget flat PDF, described by current guides only as a conditional/legacy artifact, not the primary submission channel. Dead end.
• Taxes — KRA's IT1_Individual_Resident_Return Excel workbook (kra.go.ke, version 19.0.3, March 2026) is a genuine, currently maintained, richly structured (34-sheet, well over 100 field) offline-preparation template later uploaded to the login-gated iTax portal. This is a real, strong candidate — set aside this cycle only in favour of National ID's more tractable single-form scope, and flagged below as next cycle's strongest backlog candidate.
• Visa — Kenya's eTA system (etakenya.go.ke, replacing the old evisa.go.ke since Gazette Supplement No. 1 of 2024-01-02) is a pure online wizard with a hard payment gate (~US$34) and no government-published specimen form of any kind; only a third-party travel-agency guide reconstructs the field list. Dead end (no unauthenticated specimen to cite).
• National ID — Reg. 136A (this schema). A genuine, currently-referenced, 33-widget fillable AcroForm; chosen as this cycle's candidate.

Sources examined

Source 1 — Reg. 136A PDF (chosen as source.url)

• URL: http://www.kenyaembassystockholm.com/pdfs/REG_136Dx.pdf — a Kenyan diplomatic mission's own site. Fetched directly via curl: HTTP 200, Content-Type: application/pdf, 40,414 bytes, Last-Modified: Mon, 04 Jul 2022 08:52:06 GMT, sha256: 54466885dc7d70f3f0efacc63385dd6206337ed7f160b1114b719cf092183b9b.
• NRB's own current intake channel (usajili.go.ke/nrb, confirmed live via a fresh HTTP 200 fetch this cycle) describes first-time/replacement ID registration only as an in-person/eCitizen process and publishes no downloadable specimen of this or any equivalent form — consistent with several other jurisdictions' legacy Reg./paper forms in this registry, an embassy-hosted mirror is cited in source.url rather than an agency-hosted copy, because none exists.
• Cross-checked against a second, independent mirror: https://kenyaembassydc.org/wp-content/uploads/REG_136Dx.pdf — HTTP 200, 40,889 bytes, sha256: 1762b6e53463bb1d2dc0e3d8d4d002f2039f6e228af1dc16f929e44e41c3a756 (a different hash/byte size from Source 1, i.e. a distinct re-save, not a byte-identical mirror). pdfjs-dist extraction of both files independently confirms an identical 33-widget AcroForm — same 3-page structure, same per-page widget counts (21/12/0), same internal XFA-style field names (topmostSubform[0].Page1[0].TextField1[0], etc.) in both files. This resolves the two-mirror ambiguity: both are the same form, one simply re-saved/re-uploaded, not a materially different edition — no scope discrepancy to disclose beyond the byte-level difference itself.
• A third candidate mirror, kenyahighcom.org.uk/wp-content/uploads/2021/01/REG-136A.pdf, returned HTTP 404 on direct fetch this cycle and was not used.

Source 2 — pdfjs-dist structural extraction (own re-derivation)

• getDocument().promise + page.getAnnotations() across all 3 pages of Source 1 confirms 33 real Tx (text) AcroForm widgets — 21 on page 1, 12 on page 2, 0 on page 3 — and getFieldObjects() confirms IsAcroFormPresent: true. 0 widgets are Btn (checkbox/radio) type — material to the item-22 scoping decision below.
• Every widget's own internal fieldName is a generic XFA-style token carrying no semantic meaning (TextField1[4], TextField5[0], etc.), so each of the 33 widgets was mapped to its printed label by extracting page.getTextContent() per page (keeping each text item's PDF-space x/y from its transform matrix) and correlating each widget's rect against the nearest text-content item at matching y-coordinate — the same technique this registry has used for other out-of-order/generic-named AcroForms (cf. dk/skattestyrelsen, GOV-2253). The full widget → label correlation: Page 1 (21 widgets, all preceding a numbered item list preceded by one unnumbered header line): Page 2 (12 widgets): All 33 widgets are accounted for by this mapping; no widget is left unexplained and no printed item is claimed to have a widget it does not.
  • TextField1[0] → header line, "Nambari ya Kitambulisho (Identity Card No.)" (before item 1)
  • TextField1[1] → item 1, "Majina Kamili (Full Names)"
  • TextField5[0] → item 2, "Tarehe ya Kuzaliwa (Date of birth)"
  • TextField2[0] → item 3, "Mume/Mke (Male/Female)"
  • TextField1[2] → item 4, "Majina ya baba (Father's name)"
  • TextField1[3] → item 5, "Majina ya Mama (Mother's Name)"
  • TextField3[0] → item 6, "Marital Status"
  • TextField1[4] → item 7, "Majina ya Mume (Husband's full names)"
  • TextField1[5] → item 8, "Nambari ya kitambulisho ya Mume (Husband's ID/No.)"
  • TextField1[6] → item 9, "Wilaya ya kuzaliwa (District Of Birth)"
  • TextField1[7] → item 10, "Kabila (Tribe)"
  • TextField1[8] → item 11, "Ukoo (Clan)"
  • TextField1[9] → item 12, "Mlango (Family)"
  • TextField1[10] → item 13, "Wilaya ya Makao (Home District)"
  • TextField1[11] → item 14, "Tarafa (Division)"
  • TextField1[12] → item 15, "Eneo la Bunge (Constituency)"
  • TextField1[13] → item 16, "Mtaa (Location)"
  • TextField1[14] → item 17, "Mtaa Mdogo (Sub-location)"
  • TextField1[15] → item 18, "Kijiji (Village/Estate)"
  • TextField1[16] → item 19, "Anwani (Home Address)"
  • TextField1[17] → item 20, "Kazi (Occupation)"
  • TextField1[0] → item 21(a), "Telephone Number"
  • TextField1[1] → item 21(b), "Email"
  • TextField1[2] → item 22(1)(a), "Applicant's Birth Certificate Number"
  • TextField1[3] → item 22(1)(b), "Applicant's Passport Number"
  • TextField1[4] → item 22(1)(b), "R.Number" (second blank on the same line)
  • TextField1[5] → item 22(2)(a), "Parent's Identity card Number"
  • TextField1[6] → item 22(2)(b), "Passport number" (parent's)
  • TextField1[7] → item 22(2)(b), "R. Number" (parent's, second blank)
  • TextField1[8] → item 22(3), "Certificate of registration or naturalization Certificate Number"
  • TextField1[9] / TextField1[10] → item 22(4), "Any other Document" (two consecutive blank lines — modelled as description + number)
  • TextField4[0] → item 23, "Tarehe (Date)" (the date half of the "Sahihi …… Tarehe ……" signature/date line; no widget exists for the signature half itself, so it is not modelled as a field, consistent with this registry's general practice of not treating raw signature capture as a data field)
• Confirmed no-widget regions (i.e. genuinely out of scope, not merely deprioritized): the pre-printed "REG. 136C SERIAL NUMBER" / "FINGERPRINT CLASSIFICATION" header block; the "RIGHT/LEFT HAND THUMB PRINT (official use)" boxes; the entire item 24 witness block (name, ID/passport no., address, signature/date); the "FOR OFFICIAL USE ONLY" block (items 25–26: identifying officer, registration officer, office of issue, both official stamps). getAnnotations() returns zero widgets anywhere in these regions, confirmed independently rather than inferred from the section headings alone.

Source 3 — legal-currency and administering-body check

• Confirmed via fresh web search that the Registration of Persons Act, Cap. 107, and the Registration of Persons Rules, 2024 (published on interior.go.ke) both remain in force in 2026, and that a 2026 Legal Notice (No. 76, Registration of Persons (Amendment) Rules, 2026) actively amends this same instrument (an ID-replacement fee waiver extended through October 2026) — i.e. the underlying legal instrument is actively maintained, not dormant.
• Confirmed the National Registration Bureau (NRB) is the current administering body via a direct, live fetch of https://usajili.go.ke/nrb (HTTP 200) and https://interior.go.ke (HTTP 200, redirected from www.interior.go.ke) — NRB sits under the State Department for Immigration and Citizen Services, within the Ministry of Interior and National Administration (Executive Order No. 2 of 2023).
• kenyalaw.org's consolidated Registration of Persons Rules reference "Form Reg. 136A/B/C" by name in their schedules; a direct fetch of new.kenyalaw.org for the full schedule text returned HTTP 403 (WAF block) this cycle — disclosed as a limitation, consistent with the same WAF behaviour this registry's ke/brs schema (GOV-2493) already recorded against the same host.

Field inventory and scoping/disclosure decisions

• existingIdCardNumber (the unlabelled field above item 1) is modelled as optional, on the reading that this single form serves both first-time applicants (who leave it blank) and applicants replacing a previously issued card (who enter their existing number). The form's own text never uses the words "replacement" or "first-time" — this is an inference from the field's position and NRB's general dual-purpose framing of this process, not a printed instruction, and is disclosed as a judgment call rather than presented as a literal quote from the source.
• maritalStatus (item 6) is modelled as free-text string, not enum, because the source prints only a blank line with no candidate values — inventing an enum not present on the source would violate source-fidelity (SPEC.md §3 principle 2).
• Item 22's "(TICK WHERE APPLICABLE)" instruction has no corresponding checkbox/radio widget — confirmed independently (all 33 widgets are Tx type, 0 are Btn). The five alternative supporting-evidence reference numbers (birth certificate; passport [+ its own undefined "R.Number"]; parent's ID card; parent's passport [+ its own "R. Number"]; certificate of registration/naturalization; any other document) are each modelled as independently optional string fields, with the "at least one of these must be supplied" requirement captured instead at the documents[] level (supportingIdentityDocument, category: identity-document, required: true, acceptedTypes enumerating the five alternatives). The spec's exclusivityGroups (§8.4) does not fit here (boolean fields only), and crossFieldValidation's requirePresent (§8.3) needs a triggering when condition rather than expressing "at least one of N independently optional fields" — so this "at least one" constraint is disclosed in prose (in schema.json's own verification.notes and here) rather than encoded as a machine-checkable rule.
• The two "R.Number"/"R. Number" fields (next to the passport-number blanks, applicant's and parent's) are modelled with a plain description stating the form itself does not define what they are, rather than guessing a meaning (e.g. "refugee number" or "registration number") not stated on the source.
• applicantDeclaration (documents[], category: attestation) quotes item 23's certification text verbatim in both languages as printed: "Nathibitisha kuwa maelezo yote niliyoyatoa Ni ya kweli. (I certify that all the information I have given is correct.)"

Conformance run

Two mock conformance fixtures were built against schema.json with a from-scratch, ajv-free checker script (evaluates required/requiredWhen, per-type validation keywords, and documents[] required/requiredWhen directly against the meta-schema's own rules) — not any author-provided tooling, since no shared tools/conformance-runner.mjs exists yet in this repo:

• first-time-unmarried-applicant-birth-certificate.json — an unmarried first-time female applicant in Kisumu County, supporting evidence = birth certificate. 0 errors.
• replacement-married-applicant-parent-id-and-passport.json — a married female applicant in Nyeri County replacing an existing card, with husband's details, supporting evidence = parent's ID + passport (exercising the optional husband/parent/passport-R.Number fields together). 0 errors.

Four mutation-control fixtures, each a single deliberate violation of the first valid fixture, each correctly raised exactly 1 error:

• mutation-control-missing-required-field.json — removes occupation (required) → 1 error.
• mutation-control-email-pattern-violation.json — sets email to "not-an-email" → 1 error (pattern violation).
• mutation-control-missing-required-document.json — omits the applicantDeclaration document → 1 error.
• mutation-control-sex-enum-violation.json — sets sex to "unspecified" (not in the ["male","female"] enum) → 1 error.

node tools/validate.mjs and node tools/validate-ajv.mjs (JSON Schema draft 2020-12 meta-schema conformance) both pass clean for registry/ke/nrb/application-for-identity-card/1.0.0/schema.json.

Backlog note

Kenya now stands at 2 of 6 verticals (Business Formation, National ID); Passport, DMV, and Visa are confirmed dead ends per the scouting summary above (not to be re-screened absent a material change, e.g. a new unauthenticated specimen appearing). Taxes (KRA's IT1 individual resident return, kra.go.ke, a genuine, currently-maintained, richly structured Excel workbook) is flagged as the strongest ready-to-author backlog candidate for a future cycle.