# Verification record — `ca/esdc/social-insurance-number-application` v1.0.0 This file is the **source-review record** for this document version, per the [`manual-source-review-v1`](../../../../../practices/manual-source-review-v1.md) practice. It documents the provenance of the published fields and flow, records a mock-data test run of the field set, and states the current verification claim honestly. ## Current claim - **`status`:** `draft` - **`verification.method`:** `manual-source-review-v1` - **`verification.lastVerifiedAt`:** `2026-07-01` The document was **derived from and cross-checked against** the official source below, but the full field-by-field comparison the practice requires (`manual-source-review-v1` → Procedure step 2) has **not** yet been independently re-verified by a second reviewer. It therefore remains `draft`, not `verified`. ## Why this candidate was advanced now `ca/esdc/social-insurance-number-application` was already a tier-1 candidate in `discovery/catalog.json`, noted as the GB/IE counterpart to `gb/hmrc/national-insurance-number-application` and `ie/dsp/pps-number-application`. Unlike several candidates declined earlier this session (CA CDL, GB first-provisional licence, DE passport application), this process has a genuine downloadable, fillable application form — closing this gap completes the tax/benefits-identifier family across all five focus-vertical jurisdictions this session has touched (US, GB, IE, DE, and now CA). ## Sources examined - **Document `(id, version)`:** `ca/esdc/social-insurance-number-application` / `1.0.0` - **Spec version:** GovSchema `0.2.0` - **Authority:** Employment and Social Development Canada, Service Canada (ESDC) - **Primary source URL:** - **Official form id:** `Form GC-NAS2120 (2023-06-004) E` - **Form PDF:** — fetched directly with a plain `curl` request; HTTP 200, no access block. Parsed with the `pdf-parse` npm package (`PDFParse.getText()`); all 8 pages (the Information Guide for Applicants, the application form itself — items 1-13 — and the mail-application checklist) extracted as clean, legible text and transcribed field-by-field from that output. - **Retrieved / reviewed:** 2026-07-01 - **Reviewer:** GovSchema Engineering (initial authoring source-review) ## Not a time-versioned (edition) form A SIN is issued once per lifetime; a SIN application/amendment is not filed "for" a recurring tax/award year — applying the GSP-0005 §2 coexistence test, there is no scenario where two editions of the GC-NAS2120 data model need to coexist for the same applicant. This document is therefore authored at the plain (non-edition) registry path, `registry/ca/esdc/social-insurance-number-application/1.0.0/`. A future form revision that changes the field set ships as a new `version`, not an edition. ## Scope decisions - **Modeled:** the application form's own biographic fields (items 1-13): application type, applicant name/DOB/gender, parents' names at birth, place of birth, family name at birth and prior names, previous-SIN history, status in Canada, contact information, mailing address, and the signature/representative block. - **Out of scope — identity-document requirements (Step 1 of the Information Guide).** Which specific original documents (birth certificate, permanent resident card, work/study permit, etc.) an applicant must present is a rich, status-dependent branching structure (citizen / registered Indian / permanent resident / temporary resident / other, each with its own document list, plus representative-specific document requirements). This is process guidance about what to physically bring, not itself form-field data collected on GC-NAS2120, and is out of scope for this document. - **Out of scope — the "for office use only" sections** at the bottom of the form (items A-H) — administrative fields completed by Service Canada staff, not the applicant. - **Out of scope — more than two parents.** The form provides items 4 and 5 for two parents; the guide's own note about attaching a separate sheet for jurisdictions recognizing up to four parents is out of scope for this flat field set (see GSP-0009). ## What was confirmed against the source - **Process identity and channels.** No fee; online (10 business days), by mail using this form (20 business days), or in person (issued same-visit, form not required) are all confirmed directly from the Information Guide and recorded in the document `description`. - **Application-type options.** The seven checkbox options on the form's own header ("I am applying for a(n)") transcribed directly, including the "900 series SIN" (temporary SIN) expiry-date-change option. - **Item-by-item field set (items 1-13).** Name, date of birth, optional gender/multiple-birth fields (the guide explicitly states gender is optional, unlike every other item 1-13), two parents' names at birth, place of birth, family name at birth (distinct from the current name in item 1), prior other names, previous-SIN history (with the exact "yes / no / unknown (don't recall)" options), status-in-Canada checkboxes, residing-in-Canada sub-question, phone numbers, mailing address, and the signature/ representative-relationship block — all transcribed field-by-field from the decoded PDF text. - **Signature rules.** The age-based signing-authority rules (parent/guardian for under 12; child/parent/guardian for 12-to-majority; representative/ guardian/lawyer for a represented minor or adult) and the "X"-signature two-witness rule are recorded in `signatureDate`'s description, transcribed from the Information Guide's Step 2. ## Mock-data test run Per the issue's phase-4 instruction to test-run the schema with valid mock data, a representative filled-out application was authored and checked field-by-field against every `type`/`required`/`validation` constraint in `schema.json` (string length, regex pattern, enum membership, date format, boolean type, and the conditional-field notes called out in field descriptions): ```json { "applicationType": "first_sin", "firstGivenName": "David", "otherGivenNames": "Wei", "familyName": "Chen", "dateOfBirth": "2001-11-02", "parent1GivenNames": "Li Ming", "parent1FamilyNameAtBirth": "Chen", "parent2GivenNames": "Wei", "parent2FamilyNameAtBirth": "Zhang", "placeOfBirthCity": "Toronto", "placeOfBirthProvinceOrState": "Ontario", "placeOfBirthCountry": "Canada", "familyNameAtBirth": "Chen", "hadPreviousSin": "no", "statusInCanada": "canadian_citizen", "currentlyResidingInCanada": true, "primaryPhoneNumber": "+16195550199", "mailingAddressStreet": "900 Bay Street", "mailingAddressCity": "San Diego", "mailingAddressProvinceOrState": "CA", "mailingAddressCountry": "United States", "mailingAddressPostalCode": "92109", "signatureDate": "2026-08-01" } ``` This models David Wei Chen — the new individual owner introduced in the sibling `us/ca/dmv/vehicle-title-transfer` mock scenario this session — applying for his first SIN as a Canadian-born citizen now residing abroad (a plausible scenario: a Canadian citizen living in the U.S. who still needs a SIN for Canadian tax or benefits purposes), signing for himself with no representative. The scenario exercises the `hadPreviousSin: no` path (no `previousSinNumber` needed) and omits the optional gender, multiple-birth, evening-phone, in-care-of, and representative fields. A one-off Node script (`node:fs` + a hand-rolled per-field validator, not committed to the repo) confirmed every populated field satisfies its `type` and `validation` constraint and that no required field was left unset: ``` PASS — mock first-SIN application (Canadian-born citizen) satisfies the schema field-level constraints. ``` Both registry validators were run against the schema document itself (not the mock data) and pass: ``` $ node tools/validate.mjs registry/ca/esdc/social-insurance-number-application/1.0.0/schema.json ok registry/ca/esdc/social-insurance-number-application/1.0.0/schema.json $ cd tools && node validate-ajv.mjs ../registry/ca/esdc/social-insurance-number-application/1.0.0/schema.json ok registry/ca/esdc/social-insurance-number-application/1.0.0/schema.json [v0.2] ``` ## Independent re-review (2026-07-01, GOV-338/GOV-340 fix-up) A second reviewer performed a structural cross-check of the live Form GC-NAS2120 PDF — extracting both rendered text and the underlying AcroForm field/widget data (`pdfjs-dist`) — and raised two field-fidelity findings against v1.0.0 as originally authored. Both were independently reproduced (PDF re-fetched directly from `catalogue.servicecanada.gc.ca`, HTTP 200; AcroForm annotations and page text extracted with `pdfjs-dist`) and are resolved as follows: - **`gender` enum was missing the "X" option.** The AcroForm's `rb_ApplicantSex` field has three distinct radio-button widgets — `buttonValue` `1`/`2`/`3` at rects `x≈398.8/452.8/502.3`, all at `y≈584–592` — each with an adjacent label at the same y-coordinate: `Male@(410.2,586.0)`, `Female@(464.2,586.0)`, `X@(513.7,586.0)`. This is the federal "X" sex designation Canada has offered on ID/documents since 2019, not a footnote or rendering artifact. **Fixed:** `gender.validation.enum` is now `["male", "female", "x"]`. - **`parent2GivenNames` / `parent2FamilyNameAtBirth` were modeled as optional; should be required.** Page 5 (Step 2 — Complete the Application Form) of the Information Guide reads verbatim: "You must fully complete items 1 to 13, except gender information (in item 3), which is optional. The parent listed in item 4 must not be repeated in item 5." Item 5 (the second parent) is one of items 1–13 and is not the named gender exception, so it is mandatory like every other non-exempted item. **Fixed:** both fields are now `required: true`, matching `parent1GivenNames` / `parent1FamilyNameAtBirth`'s `minLength: 1` constraint. Both fixes are reflected in `schema.json`; this closes both blockers raised in the [PR #49 re-review](https://github.com/hellogov-ai/govschema/pull/49#issuecomment-4858942972). **Not fixed here (non-blocking per the re-review):** `primaryPhoneNumber` / `eveningPhoneNumber` (item 11) remain optional. Item 11 falls under the same "items 1–13 must be fully complete" clause, but the reviewer flagged this only as a consistency question, not a blocker — the guide does not distinguish a required vs. supplementary phone number the way it does for gender, and a single item can reasonably have an internally-optional sub-field (e.g. an evening number as a backup contact channel). Left as-is pending a source that resolves it either way; a future reviewer may reopen this as its own finding. ## What is NOT yet independently verified - **Constraint patterns** (SIN 9-digit format, phone E.164, postal code) are reasonable encodings, not citations of a published ESDC validation rule. - **The online application's exact screen-by-screen flow** was not directly observed (it requires signing in); this document is sourced from the paper GC-NAS2120 form and its Information Guide, which the guide states covers the same underlying data for the mail channel and is a reasonable proxy for the online channel's biographic fields. ## Path to a `verified` claim (next step) To advance this document to `status: verified`, a reviewer applies `manual-source-review-v1` (Procedure step 2 field-by-field comparison, step 3 flow comparison) against the live Form GC-NAS2120 PDF, ideally with an observed run of the online application, confirms the sources are still authoritative, resolves any discrepancy by shipping a new schema **version** (immutability — VERSIONING §3, practice Procedure step 5), and records the outcome here plus sets `status: verified` with a current `verification.lastVerifiedAt` / `nextReviewBy`. This v1.0.0 record stays as the authoring provenance. ## Re-verification Per the practice's **Cadence**, `nextReviewBy` is set to **2027-01-01** (6 months). Re-check the source on or before that date, on any `source.url` change, or when Service Canada publishes a new Form GC-NAS2120 revision.