# Schema 초안 리뷰 가이드 (7단계)

> 원칙: **사람은 원본 JSON을 직접 보지 않는다.** 기계가 잡을 수 있는 결함은 검증기 게이트(8단계)가
> 먼저 0건으로 만들고, 사람은 "기계가 못 잡는 것"만 본다. 그래야 "오류 과다" 문제가 재발하지 않는다.

## 검토 순서
1. **먼저 검증기 통과** → `zero P0` 확보 (P0가 남은 초안은 검토 대상 아님)
2. 아래 항목은 사람만 판단 가능 → 검토
3. 고객 검토는 P0=0인 깨끗한 초안 + 결함 리포트로만 진행

## 사람이 검토할 항목 (기계가 못 잡는 것)

### A. 사실 정확성 (출처 대조)
- [ ] `name` / `legalName` 이 공식 표기와 정확히 일치하는가 (공백·영문병기 포함)
- [ ] 주소·전화가 **현재 유효한** 값인가 (출처가 오래되지 않았는가)
- [ ] `foundingDate` 등 날짜가 공시값과 일치하는가
- [ ] 인물의 `jobTitle` 이 **현직** 기준인가

### B. 엔티티 정합
- [ ] `sameAs` 가 **정확히 그 엔티티**를 가리키는가 (동명 오정합 없는가)
- [ ] `@id` 참조가 의도한 엔티티로 연결되는가 (Hotel→올바른 Organization)
- [ ] 브랜드 티어(`brand.name`)가 프로퍼티와 일치하는가 (The Shilla/Monogram/Stay)

### C. 언어·번역
- [ ] 언어별 초안의 `inLanguage` 와 실제 값 언어가 일치하는가
- [ ] 번역값이 공식 다국어 표기와 일치하는가 (임의 번역 아님)

### D. 범위 적절성
- [ ] 스키마를 붙이면 안 되는 페이지(mypage/login/booking)에 초안이 없는가
- [ ] 누락된 핵심 엔티티가 없는가 (엔티티-타입 맵 대조)

## 검토 결과 처리
- 수정 필요 → 클레임 레지스터에서 값 수정 후 **빌더 재실행**(JSON 직접 수정 금지: 원천은 항상 클레임)
- 충돌 발견 → `conflict=Y`, `status=PENDING` → 출처 권위로 해소
- 검토 완료 → 저작자·검수자 서명, P1은 `decision-log`에 기록

## 서명
- 저작(빌드): ______  / 일자: 2026-__-__
- 검수(사실확인): ______ / 일자: 2026-__-__
- 게이트(검증기 PASS) 확인: ______ / 일자: 2026-__-__