# Verification record — `kr/mois/resident-registration-card-reissuance` 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 states the current verification claim honestly. ## Current claim - **`status`:** `draft` - **`verification.method`:** `manual-source-review-v1` - **`verification.lastVerifiedAt`:** `2026-07-06` Every field in this schema was read directly from the text layer of the official two-page form PDF. It remains `draft`, not `verified`, because a live intake walkthrough at an Eup/Myeon office or Dong community centre and a second independent reviewer's field-by-field pass have not yet occurred — see "What is NOT yet independently verified" below. ## Access notes - The form was retrieved directly from `law.go.kr`'s own form-download endpoint (`flDownload.do`), HTTP 200, `Content-Type: application/pdf`, no login or CAPTCHA required. The response's `Content-Disposition` header confirms the file as `[별지 제32호서식] 주민등록증 재발급신청서(주민등록법 시행령).pdf`. - This is a genuine text-layer PDF (not a scanned image): every field, checkbox, and instructional note in this schema's `sourceRef` values was extracted with `pdfjs-dist` (legacy build, text-content mode, grouped by y-coordinate into reading-order lines) and read directly, not inferred from a summary or OCR. - The PDF's own header identifies it as amended `2016. 12. 30.`; a second, older `2014. 12. 31.` amendment of the same attached form number was also found during search but not used, since the 2016 revision is the current version served by `law.go.kr`'s own By-law info page for this form (`lsBylInfoPLinkR.do?...&bylNo=0032`). - No official filled-in worked example (like the two `kr/nec` specimen PDFs) was found for this form; the conformance packet below is therefore a synthetic fixture built directly from the blank form's own field labels and instructional notes, not a transcription of a real filled example. ## Sources examined - **Document `(id, version)`:** `kr/mois/resident-registration-card-reissuance` / `1.0.0` - **Spec version:** GovSchema `0.3.0` - **Authority:** Ministry of the Interior and Safety (행정안전부, MOIS), which administers the Resident Registration Act (주민등록법); the form is filed in practice at the applicant's local 읍ㆍ면사무소 (Eup/Myeon office) or 동 주민센터 (Dong community centre), not directly with MOIS. - **Primary source (directly retrieved, HTTP 200, text layer read in full):** — 주민등록법 시행령 [별지 제32호서식] <개정 2016. 12. 30.> 주민등록증재발급신청서 - **By-law listing page:** - **Retrieved / reviewed:** 2026-07-06 (initial authoring); independently re-retrieved and re-extracted 2026-07-06 for the GOV-1358 review gate - **Reviewer:** GovSchema Engineering (initial authoring source-review); GovSchema Engineering, Standards Engineer (GOV-1358 independent review gate) ## What was confirmed against the source | Source element | Field(s) | |---|---| | 신청인 block (성명(한글), 주민등록번호, 주소 (시ㆍ도/시ㆍ군ㆍ구), 연락처) | `applicantNameKorean`, `applicantResidentRegistrationNumber`, `applicantAddress`, `applicantContact` | | 재발급 사유 checkbox grid (11 boxes incl. 그 밖의 사유) | `reissueReason`, `reissueReasonOtherText` | | 첨부서류 item 2 exceptions (가–마: 분실, 영주귀국/재외국민 with prior surrender, 3년/1년 미수령 파기) | `previousIdCardSurrenderedBeforeDeparture`, `previousIdCard` document | | 주민등록증 발급신청 확인서 [ ] 교부 [ ] 미교부 | `applicationConfirmationIssuance` | | 주민등록증 수령 방법 (신청 기관 방문/주민등록기관 방문/등기우편) | `receiptMethod` | | 주민등록증 수령 안내 SMS 서비스 [ ] 신청 [ ] 미신청 | `smsReceiptNotification` | | 등기우편 수령 주소 block + '주민등록 주소와 같음' + postal-code note | `registeredMailSameAsRegisteredAddress`, `registeredMailPostalCode`, `registeredMailAddress` | | Main declaration date line (년 월 일) | `applicationDate` | | 방문 재발급 신청인 block (성명, 주민등록번호, 주소, 연락처) + 첨부서류 item 3 | `isVisitIssuanceForSeverelyDisabled`, `visitReissuanceApplicantName`, `visitReissuanceApplicantResidentRegistrationNumber`, `visitReissuanceApplicantAddress`, `visitReissuanceApplicantContact`, `disabilityProofDocument` document, `visitReissuanceApplicantIdDocument` document | | Page 2 fee-exemption consent paragraph + 8-category checkbox row + date line | `consentToAdministrativeInfoVerification`, `basicLivingSecurityRecipient`, `personOfIndependenceMerit`, `personOfNationalMerit`, `agentOrangeAftereffectPatient`, `warVeteran`, `may18DemocracyMovementMeritPerson`, `specialMissionPerformer`, `singleParentFamilyProtectionRecipient`, `consentDate` | | 첨부서류 item 1 (photo spec) | `photo` document | | Fee column ("수수료 5,000원") + page 2 유의사항 item 7 (fee-charging cases) | `reissuanceFee` document | Office-assigned fields (접수 번호/접수일, 처리 기간) were deliberately excluded, consistent with prior GovSchema precedent of modeling only applicant-facing fields (e.g. `kr/koroad/driving-licence-application`, `kr/nec/overseas-voter-registration`). The routing line at the form's foot ("읍ㆍ면ㆍ동장 및 출장소장 귀하") is administrative routing, not an applicant-supplied field, and is not modelled. Signature/seal marks accompanying both date lines are a physical signing-event detail, not a data field, and are not modelled — consistent with `kr/moj/visa-application`'s precedent for the same kind of line. One interpretive judgment call remains open for a future reviewer (a second, originally flagged here, was resolved by the GOV-1358 review-gate pass — see "Resolved during review" below): 1. **Fee logic granularity.** 유의사항 item 7 narrows the `damaged` and `appearanceChange` fee triggers to exclude natural wear and disaster/accident causes respectively, and a checked fee-exemption category may waive the fee entirely. Neither narrowing is separately encoded as its own field — `reissuanceFee`'s `requiredWhen` is reason-level only, with both caveats documented in its `sourceRef`. This mirrors `sg/ica/identity-card-replacement`'s precedent of not encoding a fee amount/condition more precisely than the source form's own checkbox structure supports. ## Resolved during review - **`방문 재발급 신청인` scope (GOV-1358 review gate, 2026-07-06).** The original authoring pass modelled the `방문 재발급 신청인` block as *the severely disabled applicant's own* confirmation block, explicitly framed as "not a distinct proxy/representative's block," and flagged that framing as an unconfirmed judgment call. Independent re-review of the source PDF's back-page 유의사항 (usage notes) found item 2 states directly: "중증 장애인에 대한 주민등록증 방문 발급 신청은 해당 중증 장애인이나 법정대리인 또는 보호자(중증장애인의 세대주, 배우자 및 직계혈족)가 할 수 있습니다" ("The application for home-visit issuance ... for a severely disabled person may be made by the severely disabled person themselves, their legal representative, or a guardian — the severely disabled person's household head, spouse, or lineal blood relative"). This contradicts the original "not a distinct proxy" framing: the block's name/RRN/address/contact fields may in practice belong to a legal representative or guardian, not the disabled applicant. No field structure change was needed — `visitReissuanceApplicantName` et al. were already generic, unattributed fields — but `isVisitIssuanceForSeverelyDisabled`'s `description` and `sourceRef` were corrected to cite 유의사항 item 2 and state the block may belong to a legal representative or guardian, not only the disabled applicant. Fixed pre-merge in `schema.json`. ## Mock-data conformance run A from-scratch GSP-0013 condition evaluator (`requiredWhen`/`visibleWhen`, supporting `equals`/`notEquals`/`in`/`greaterThan(OrEqual)`/`lessThan(OrEqual)` plus `all`/`any`/`not` composition) was written against this schema and run over seven fixtures: 1. **Lost card, counter pickup, no fee exemption** — `previousIdCard` correctly NOT required (lost is an explicit exception); `reissuanceFee` correctly required. 0 violations. 2. **Name change, registered mail to a different address** — `previousIdCard` correctly required; `reissuanceFee` correctly NOT required (name change is not a fee-triggering reason); `registeredMailPostalCode`/`registeredMailAddress` correctly required. 0 violations. 3. **Permanent return, previous card already surrendered before departure** — `previousIdCard` correctly NOT required. 0 violations. 4. **Permanent return, previous card NOT surrendered** — `previousIdCard` correctly required. 0 violations. 5. **Home/counter-visit issuance for a severely disabled applicant, with a fee-exemption category claimed** — all four visit-applicant fields, both visit-specific documents, and the exemption/consent fields correctly required and satisfied. 0 violations. 6. **`reissueReason: other` with `reissueReasonOtherText` omitted** — the evaluator correctly flagged the missing conditional field (plus the correctly-still-required `previousIdCard`, since `other` is not one of the old-card exceptions). 7. **`isVisitIssuanceForSeverelyDisabled: true` with the visit block and its two documents omitted** — the evaluator correctly flagged all six missing required fields/documents. Fixtures 1–5 also passed the repo's structural validator (`tools/validate. mjs`) and full JSON Schema draft 2020-12 meta-schema validator (`tools/ validate-ajv.mjs`) for the schema document itself (both run directly against `schema.json`, which fixtures 1–5 do not modify). `conformance/kr/mois/resident-registration-card-reissuance/1.0.0/ application-packet.json`/`.txt` publish fixture 1 (the lost-card, counter- pickup scenario) as the committed demoable packet, per this registry's `application-packet.json` convention (GSP-0016). ## What is NOT yet independently verified - A live intake walkthrough at an Eup/Myeon office or Dong community centre has not been performed; this document is sourced entirely from the gazetted blank form (no official filled-in worked example was found for this specific form). - The fee-exemption category list's actual waiver effect (whether checking a category always fully waives the KRW 5,000 fee, or only waives it conditional on the reissue reason) is not stated on the form itself and is not machine-enforced here — see "Fee logic granularity" above. - Whether `applicantContact`/`visitReissuanceApplicantContact` are mandatory in practice at intake — the form provides a labelled box but no asterisk distinguishing it from the unambiguously required identity fields; this document conservatively models it as required, consistent with the block's own visual grouping alongside name/RRN/address, but this is a judgment call, not a form-marked requirement. ## Path to a `verified` claim (next step) To advance to `status: verified`, a reviewer applies `manual-source-review-v1` (Procedure step 2) by confirming the field set directly against a live MOIS or local-office intake channel, or an authoritative MOIS-published field-level checklist; 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`. ## Re-verification Per the practice's **Cadence**, `nextReviewBy` is set to **2027-01-06** (6 months). Re-check the sources on or before that date and on any `source.url` change.