Tunisia Application for a National Identity Card (Form IL.01-12/2013)

Candidate selection

GOV-4652 ("GovSchema Standard Research"). GOV-4638 (a prior cycle of the same recurring routine) scouted Tunisia's National ID (CIN) candidate as STRONG and uncaveated — served from the same sicad.gov.tn portal as the Passport form it authored that cycle (tn/dgsn/passport-application, which opened Tunisia as the registry's 94th jurisdiction) — but banked it rather than authoring it, since that cycle's scope was the new- jurisdiction opening itself. This cycle re-scouted and confirmed the candidate live before authoring it, closing one more of Tunisia's six verticals (2/6). Tunisia's remaining four verticals (Taxes, Business Formation, Visa, DMV) are unchanged open backlog — see tn/dgsn/passport-application's own VERIFICATION.md for that record.

Reaching the live source

Found via a site search for the CIN application, landing on http://www.sicad.gov.tn/Fr/Imprime_Demande-de-carte-didentite-nationale-AR_66_3_D293 (the "AR" suffix in this landing page's own slug reflects the linked form's monolingual-Arabic content, not a separate/alternate edition — no sibling French-labelled CIN form was found on the portal, unlike the Passport form's own bilingual specimen).

• Plain unauthenticated curl request (realistic desktop User-Agent header; no session/cookie state, no CAPTCHA/WAF challenge).
• Same HTTP-only hosting property as the companion Passport schema (https:// to this domain returns ECONNREFUSED) — re-verify via http:// in any future cycle.
• Landing page: HTTP 200, 51,707 bytes.
• Linked PDF: http://www.sicad.gov.tn/Fr/upload/1428663336.pdf — HTTP 200, 40,619 bytes retrieved, matching GOV-4638's own banked estimate ("41KB") almost exactly.
• PDF header %PDF-1.5\r%... at byte 0.
• sha256 of the retrieved bytes: 1ccece129f681dc936c65ea22921bc83e69760d2607d58a71fb6bb9731d2fe63.
• 2 pages, confirmed via pdfjs-dist's numPages.
• getAnnotations() returned 0 annotations on both pages — a flat, print-and-fill specimen, not an interactive AcroForm.

Authority attribution

Same header block as the companion Passport schema — "الجمهورية التونسية" (Republic of Tunisia) / "وزارة الداخلية" (Ministry of the Interior) / "الإدارة العامة للأمن الوطني" (DGSN) — so authority is attributed identically. sicad.gov.tn is again modelled as the hosting portal, not the issuing authority.

Extraction method

pdfjs-dist getTextContent() extracted a completely clean text layer on both pages — every label, blank line, and footnote present at its correct x/y position, right-to-left reading order resolved the same way as the companion Passport schema. Unlike that schema, this specimen carries no French text anywhere — every visible string on both pages is Modern Standard Arabic (confirmed by inspecting the full getTextContent() item list; no Latin-script string appears except the form number IL.01-12/2013 itself). This is a new translation circumstance for this registry: prior Tunisian/bilingual sources let the French half double-check the Arabic-to-English translation; here, every field label below is this registry's own direct Arabic-to-English translation with no source-printed bilingual crutch.

To reduce translation risk, this specimen was additionally rendered to PNG at 3x scale via node-canvas (unlike the companion Passport schema, which skipped rendering since its checkboxes were plain numbered list items) — rendering succeeded cleanly with no glyph-path failures, letting every checkbox grid, table border, and line grouping be visually confirmed against the extracted text-layer positions rather than relying on coordinate math alone. This also resolved one genuine layout ambiguity the text layer alone left uncertain: the marital-status checkbox grid has only three columns on this specimen (single, married, widowed — no "divorced" option), confirmed visually, versus the companion Passport schema's four-option version (which does include divorced).

Document structure

Page 1 (the entire applicant-facing form) — header (Republic of Tunisia / Ministry of the Interior / DGSN); a dashed fee box (payment receipt number, fiscal stamp fee amount) top-right; a 3-option numbered request-type checklist top-left (first-time, loss, replacement); an office reference block (الجهة/العدد — authority/number — plus an adjoining blank stamp box) between the title and the applicant's own data, modelled as out of scope (see below); the applicant's own family name and sex (male/female checkboxes); first name; father's and grandfather's first names; date of birth (day/month/year boxes) and place of birth, beside a 3-option marital-status checkbox grid (single, married, widowed); mother's first name and family name; spouse's first name and family name (conditional on marital status); profession; home address, beside a blood-type box; governorate; previous/old ID card number; an organ-donor opt-in checkbox with an adjoining sworn-liability declaration and mandatory signature box; and finally an entirely office-only tail (a fingerprint-classification grid, right-thumbprint box, file number/date, and the receiving center chief's own signature), followed by a tear-off citizen deposit receipt (issued-to-holder line, registration number/date/office, officer's signature) below a scissors-icon cut line.

Page 2 — an internal DGSN processing memo, not applicant-facing: two numbered sign-off lines for the data-entry agent (system data entry; photo/fingerprint entry), each with a name and signature blank; then a routing paragraph addressed to the Head of the Sub-Directorate for National Identification, naming a file number and turnaround period; a document-routing checklist of eleven possible supporting-document types (each with its own checkbox, ticked by the submitting office to indicate which accompany this specific file); and the sign-off of the Head of the Technical and Scientific Police Squad. No applicant-supplied data appears anywhere on this page — the same "officer-performed-duty, not applicant data" pattern as the companion Passport schema's page 2.

Scope: sections and fields excluded

• The office reference block (الجهة/العدد/unlabeled stamp box, printed between the form's title and the applicant's own first field) is excluded — an intake-office file/reference number, not applicant-supplied.
• The fingerprint-classification grid, right-thumbprint box, file number/date, and receiving-center chief's signature (bottom of page 1) are excluded — explicitly under the "بيانات خاصة بالإدارة" ("administration-only data") heading.
• The tear-off citizen deposit receipt (bottom of page 1, below the scissors-icon cut line) is excluded — issued by the receiving office back to the applicant as proof of filing, not filled in by the applicant.
• Page 2 is excluded in its entirety — the receiving office's own internal data-entry sign-off and document-routing memo, the same reasoning as the companion Passport schema's page 2 exclusion.

Scope: documents[] inferred from an internal checklist, not an applicant-facing list

Unlike the companion Passport schema (which omits documents[] entirely, since its source names no supporting documents anywhere), this specimen's page 2 does print a named list of eleven supporting-document types — but as an internal office checklist (ticked by the submitting office to record what already accompanies a given file), not as applicant-facing instructions. This registry's source-fidelity standard treats a named list as sufficient grounds to model documents[] even when the list's audience is internal, since the document names themselves are drawn directly from the source rather than invented — but the requiredWhen conditions gating each one are this registry's own inference, not something the source states explicitly for any item. Each documents[] entry's handling field discloses this. Two items (residenceCertificate, employmentCertificate) and one more (bloodTypeCertificate, schoolAttendanceCertificate, parentalAuthorization) were left unconditional-optional rather than guessing a requiredWhen the source does not state — in particular, bloodTypeCertificate was deliberately not gated on bloodType being non-empty, since this registry has previously hit a real bug gating requiredWhen on notEquals "" against an optional string field (see the notequals-empty-string-absent-field-bug reference); the same reasoning applies to employmentCertificate against the free-text profession field. The remaining five (birthCertificateExtract, certificateOfNationality, marriageCertificate, deathCertificate, lossDeclaration, organDonationConsentDeclaration) each have a one-field correlate defensible enough to gate on (requestType or maritalStatus equality, or isOrganDonor equals true).

Scope: judgment calls on requiredness

This source has the same lack of a consistent required-field marking convention as the companion Passport schema — the (*) marks found here denote the shared "mark X in the correct box" checkbox-instruction footnote, not a required-field indicator (confirmed: it appears beside every checkbox group — requestType, sex, maritalStatus, isOrganDonor — not just some). Requiredness was therefore assigned by engineering judgment, following the same standard this registry applied to the companion schema:

1. requestType modelled required — the applicant must indicate why they are filing.
2. familyName/firstName/fatherFirstName/grandfatherFirstName/ sex/dateOfBirth/placeOfBirth/maritalStatus/motherFirstName/ motherFamilyName/homeAddress/governorate/applicantSignature modelled required as core identity fields, matching the companion Passport schema's treatment of the identical name/parentage/birth fields it shares.
3. profession modelled required, matching the companion Passport schema's own treatment of the identical field (rather than optional, since a "no profession" applicant can presumably still print e.g. "sans profession").
4. bloodType modelled optional — a field with no counterpart on the companion Passport schema, and not everyone knows their blood type at filing time; consistent with this registry's standard treatment of comparable non-universal disclosures (e.g. that schema's otherNationalities).
5. paymentReceiptNumber/fiscalStampFeeAmount modelled optional — identical judgment call and identical field pair to the companion Passport schema.
6. previousNationalIdCardNumber gated on requestType in [LOSS, REPLACEMENT] — only meaningful when this application replaces an existing card.
7. spouseFirstName/spouseFamilyName gated on maritalStatus equalling MARRIED — same adjacency-based reasoning as the companion Passport schema's spouse block, though this specimen omits spouseNationality (no such blank is printed here).
8. isOrganDonor modelled as an optional boolean, not a required enum — the specimen prints a single opt-in checkbox (not a yes/no pair), so leaving it unmarked is itself a valid, meaningful answer (declining to register as a donor), not a missing response.

Conformance

2 mock scenarios plus 1 negative case were run programmatically (a small one-off Node script evaluating this schema's own fields[]/documents[] requiredWhen conditions — not committed as fixture files, following this registry's own precedent for single flat-PDF national-ID/passport schemas): (1) a single, first-time applicant who opts in to organ donation — correctly requires birthCertificateExtract, certificateOfNationality, and organDonationConsentDeclaration, and nothing else conditional; (2) a married applicant replacing a card lost previously — correctly requires spouseFirstName/spouseFamilyName (via maritalStatus = MARRIED), previousNationalIdCardNumber (via requestType = LOSS), marriageCertificate (via maritalStatus), and lossDeclaration (via requestType); (3) a negative case — the same married applicant with spouseFirstName/spouseFamilyName omitted — correctly flags both as missing-but-required. All three requiredWhen conditions in this schema (maritalStatus, requestType, isOrganDonor) were exercised true and false at least once across the three scenarios.

Validated clean with node tools/validate.mjs and node tools/validate-ajv.mjs (ajv 2020-12 against spec/v0.3/govschema.schema.json). registry-index.json regenerated via npm run build-index in tools/govschema-client/.

Models 22 fields[] across 5 steps, 11 documents[] entries.