Thai National ID Card Application Form — Royal Thai Embassy, Washington, D.C.

This file is the source-review record for this document version, per the manual-source-review-v1 practice.

Current claim

• status: draft
• verification.method: manual-source-review-v1
• verification.lastVerifiedAt: 2026-07-15
• maturity.level: structural-reference

This is GovSchema Standard Research cycle GOV-3228, scouted from GOV-3225 ("GovSchema Standard Research"). It closes Thailand's registry coverage to full 6/6 verticals — Passport (th/mfa/passport-application-royal-thai-embassy-london), Taxes (th/rd/pit-90-personal-income-tax-return), Business Formation (th/dbd/boj-1-application-to-register-a-limited-company), Visa (th/mfa/non-immigrant-visa-b-application-for-employment), and DMV (th/dlt/vehicle-registration-application) were already modelled; National ID was the sole remaining gap.

Candidate screening this cycle (both confirmed dead ends, per the issue brief)

• ThaID digital-ID app/login — a login-gated single-page application with no field-level form to model. Confirmed a dead end by an earlier cycle; not re-attempted per the issue brief's explicit instruction.
• DOPA/BORA in-country counter process — the primary domestic National ID issuance path. Independently re-confirmed this cycle: dopa.go.th/app_form and bora.dopa.go.th/download/ list only prose service guides and internal manuals, no citizen-fillable blank application form. Independent sources (consistent with this registry's own th/mfa/passport-application-royal-thai-embassy-london National-ID screening note from an earlier cycle) confirm issuance is strictly in-person and counter-only: a DOPA officer enters the applicant's data directly into the BORA system and captures a live photograph and fingerprints biometrically, printing the internal บ.ป.1 request form from the system itself — the applicant never completes a paper form in advance. Not pursued.

Source verification (independently re-derived, not trusted from the issue brief as final)

• URL: https://image.mfa.go.th/mfa/0/91fPdh6NtO/Consular-Services/Consular_service-forms/2.1_Thai_ID_Card_Application_Form.pdf
• Fetched independently via curl:
  • HTTP 200, Content-Type: application/pdf, Content-Length: 118599 bytes — matches the issue brief's own recorded byte size (~118KB) exactly.
  • sha256: caf0eb02d4cd97e5cff7f3cd0d9a987084bc785f599917d5da84d371329f7674 (computed via sha256sum on the freshly-downloaded file; first hash on record for this file, the issue brief did not record one to cross-check against).
• Parsed with pdfjs-dist@3.11.174 (legacy build, per this registry's pinned version — the 4.x line has previously failed node-canvas rendering in this environment): getAnnotations() confirms 0 Widget annotations on the form's single page (a plain print-and-fill form, not an AcroForm); getTextContent() confirms a real, fully extractable bilingual Thai/English text layer — not a scanned image. Every field below was read via coordinate-sorted line grouping (getTextContent() items grouped by rounded y, ordered by x), the same technique used across this registry's other flat-print-form entries (th/mfa/passport-application-royal-thai-embassy-london, np/donidcr/national-identity-card-application).
• Grepped the extracted text for * and for Thai/English words for "required"/"mandatory" (จำเป็น, บังคับ) — zero matches anywhere on the form. No required-field marking convention of any kind exists on this source.

Consular-vs-domestic scope, disclosed

This schema models the Washington, D.C. consular variant, not the primary in-country DOPA/BORA process (confirmed a dead end above) — disclosed in the schema's own title and description rather than presented as the canonical domestic form. This same template's filename and layout pattern recurs across multiple Thai consular posts (Washington D.C., Sydney, Jakarta — per the issue brief's own note), supporting treatment as a stable Ministry of Foreign Affairs (MFA) standard template, not a one-off local variant — but it remains embassy/consular-scoped: the form's own "Current Address in the U.S." block, and its distribution from the Washington, D.C. embassy's own consular-forms page, make this an overseas-Thai-national specimen for U.S. residents specifically, not a domestic nationwide one.

No required-field marker exists anywhere on this form

Confirmed above (zero * characters, zero "required"/"mandatory" text anywhere in the extracted text layer). Requiredness is therefore a disclosed judgment call, following this registry's established precedent for no-marker forms (np/donidcr/national-identity-card-application, th/mfa/passport-application-royal-thai-embassy-london, bd/dip):

• Marked required: applicationDate, titlePrefix, applicantNameThai, applicantNameEnglish, nationalIdNumber, applicationPurpose, and the current-U.S.-address/contact fields the Embassy needs to process a mail-in request and reach the applicant (addressHouseNo, addressRoad, addressCity, addressState, addressZipCode, phoneNumber, email). This form has no separate delivery-preference or appointment-booking mechanism (unlike th/mfa/passport-application-royal-thai-embassy-london's explicit postal-return-vs-in-person-collection choice), so both phoneNumber and email are treated as the Embassy's only means of contacting the applicant — a disclosed judgment call rather than an assumption that one channel alone would suffice.
• addressAptSuite is left optional, since not every address includes a unit number.
• religion, bloodType, occupation are printed as bare, unqualified blanks with no surrounding text suggesting they are essential to processing an ID-card request (unlike the applicant's own identity and contact particulars) — left optional, consistent with np/donidcr/national-identity-card-application's treatment of the same class of bare demographic blank (caste/sex/religion/occupation on that form).

applicationPurpose and the New-card/Replacement sections

The source's own "มีความประสงค์ขอมีบัตรประจำตัวประชาชน" (Purpose for Acquiring New Thai ID Card) section presents two mutually exclusive top-level request types, each as a prose statement followed by its own checkbox row (no AcroForm checkbox widgets exist anywhere on this specimen):

• ขอมีบัตรใหม่ (New card) — due to expiry (บัตรหมดอายุ) or loss/theft (บัตรสูญหายหรือถูกทำลาย).
• ขอเปลี่ยนบัตร (Replacement) — due to one or more independently selectable reasons.

Modelled as a two-value applicationPurpose enum (new-card / replacement) rather than two booleans plus an exclusivityGroups entry, matching this registry's established convention for bare "choose one of these statements" prose selectors (cf. th/mfa/passport-application-royal-thai-embassy-london's deliveryPreference).

• newCardReason (Expired vs. Lost/Stolen) is a second mutually exclusive pair nested under the new-card purpose. Modelled as an enum with requiredWhen: { field: "applicationPurpose", equals: "new-card" } — per spec §10, its static required is therefore false, and its effective requiredness collapses to false whenever applicationPurpose is not new-card.
• oldCardBackNumber is explicitly qualified "ถ้ามี" ("if any") by the source itself, so it is modelled as unconditionally optional, with a visibleWhen (not requiredWhen) tying its presentational relevance to the new-card purpose.
• The eight Replacement reasons (replacementTitleChanged, replacementAddressChanged, replacementThaiFirstNameChanged, replacementThaiLastNameChanged, replacementThaiFirstAndLastNameChanged, replacementEnglishNameChanged, replacementDamaged, replacementOther) are modelled as independent boolean fields, not a single enum, because the source's own checkbox layout allows more than one to apply simultaneously (e.g. a title change and an address change on the same request) — unlike the New-card-vs-Replacement and Expired-vs-Lost/Stolen choices, each of which is printed as a single mutually exclusive pair. Each carries a visibleWhen: { field: "applicationPurpose", equals: "replacement" }; all are left optional since the source imposes no explicit "select at least one" instruction to validate against.
  • replacementThaiFirstNameChanged, replacementThaiLastNameChanged, and replacementThaiFirstAndLastNameChanged are printed as three distinct, seemingly overlapping checkboxes. Modelled exactly as printed (three separate booleans) rather than collapsed into two, per this registry's precision-over-editorializing convention — the source is the authority on its own redundancy, not this schema.
  • replacementOther carries its own free-text blank on the source, modelled as replacementOtherDescription with requiredWhen: { field: "replacementOther", equals: true }.

Excluded as out of scope

Consistent with this registry's established treatment of biometric/wet-ink capture on print-and-fill government forms (np/donidcr/national-identity-card-application, do/mirex/passport-application, il/mot/medical-examination-driving-license-renewal):

• ลายมือชื่อ (Sign) — ผู้ขอมีบัตร (Applicant's Signature) — a physical handwritten signature mark, excluded outright.
• ตัวบรรจง (Printed) — the block-letter name confirmation accompanying the signature — excluded as it duplicates the already-modelled applicantNameThai and exists solely to make a handwritten signature legible, not as a distinct data value. Unlike some of this registry's other Nepal/Thailand specimens, this form carries no separate declaration-date blank near the signature to retain as its own field.
• The form's header (embassy name), title, and certification prose ("ข้าพเจ้า ขอรับรองว่าข้อความดังกล่าวข้างต้นเป็นความจริงทุกประการ") are boilerplate, not data fields.

authority.url — disclosed sandbox-networking limitation

authority.url points to the Ministry of Foreign Affairs' main domain (https://www.mfa.go.th, independently confirmed reachable this cycle, HTTP 200) rather than the Washington, D.C. embassy's own site (thaiembdc.org): every attempt to reach the embassy's own domain from this sandbox's network egress returned an identical TLS handshake failure (curl and openssl s_client both fail against its Cloudflare-fronted IP with SSL routines: ... handshake failure), while MFA's own image.mfa.go.th CDN (the source PDF's own host) and www.mfa.go.th both resolved normally. This is disclosed as a sandbox-networking limitation, not a claim that the embassy's own site is unreachable in general — the source PDF itself was independently fetched and hashed directly from MFA's CDN, unaffected by this.

Conformance

An ephemeral, from-scratch conformance checker (deriving required/enum/ requiredWhen/visibleWhen rules directly from this schema's own fields[], discarded after use, not committed) ran the following fixtures in conformance/th/mfa/thai-national-id-card-application/1.0.0/:

• valid-new-card-lost-stolen.json (all required fields, applicationPurpose new-card, newCardReason lost-stolen, oldCardBackNumber populated) — 0 errors.
• valid-replacement-multiple-reasons.json (all required fields, applicationPurpose replacement, three of the eight replacement-reason booleans true simultaneously including replacementOther with replacementOtherDescription populated) — 0 errors.
• mutation-control-missing-required-field.json (drops nationalIdNumber) — exactly 1 error.
• mutation-control-invalid-national-id-pattern.json (nationalIdNumber set to an 11-digit string) — exactly 1 error.
• mutation-control-invalid-enum-purpose.json (applicationPurpose set to renewal, not in the enum) — exactly 1 error.
• mutation-control-invalid-email-pattern.json (email set to a malformed address) — exactly 1 error.
• mutation-control-requiredwhen-new-card-reason-missing.json (applicationPurpose new-card with newCardReason omitted) — exactly 1 error.
• mutation-control-requiredwhen-other-description-missing.json (replacementOther true with replacementOtherDescription omitted) — exactly 1 error.

Structural validation

• node tools/validate.mjs — full registry, 491/491 document(s) passed (3/3 mapping.json companions also passed) after adding this document.
• node tools/validate-ajv.mjs (ajv 2020-12 against spec/v0.3) — full registry, 491/491 document(s) validated.
• npm run build-index re-run in tools/govschema-client/ to regenerate registry-index.json with this document included.

Maturity

structural-reference: every field traces to a specific labelled blank or checkbox row confirmed on this form's own extracted text layer and its independently re-derived source hash. No live filing at the Embassy was attempted. GovSchema is an independent, non-profit standards body and is not affiliated with, endorsed by, or operated by the Government of Thailand, the Ministry of Foreign Affairs, or the Royal Thai Embassy.