평가 계획
아래 내용은 평가 결과가 아니라 계획이다. 아직 검증하지 못한 주장을 시험하기 위해 통과 기준을 미리 정했다.
구조에서 확인되는 점
현재 구조만으로 확인할 수 있는 범위는 다음과 같다.
- 수작업 표와 비교하면 원본·변환·판단 근거가 구조적으로 연결돼 재검토와 변경 영향 추적이 가능하다.
- 성공 건수만 보고하는 파이프라인과 비교하면 미처리·미지원·검토 필요 상태가 드러나므로 누락을 발견하는 것 자체가 가능하다.
- 단순 파일 hash와 비교하면 revision의 변경 사유와 현재 사용 상태를 설명할 수 있다.
- 설계상 원문을 온체인에 공개하지 않고도 결과 commitment와 revision 상태를 검증할 수 있다.
사용자가 누락을 더 빨리 찾는지는 별도 실험이 필요하다.
평가가 필요한 항목
| 평가 질문 | 방법 | 사전 등록 통과 기준 |
|---|---|---|
| 누락·중복을 더 쉽게 찾는가 | 동일 fixture를 기존 수작업/연동 결과와 coverage 인터페이스로 각각 검토 | 정답셋 대비 탐지율, 발견 시간, false positive를 측정 |
| silent drop이 없는가 | 지원·미지원·실패 fixture의 terminal outcome 전수 대조 | 모든 in-scope 입력이 결과 또는 명시적 상태를 가짐 |
| 결과를 설명할 수 있는가 | 결과에서 원본까지 찾는 사용자 과업 테스트 | 5명 중 4명 이상이 원본·정책·예외를 찾음 |
| 검토 생산성이 나아지는가 | 세무 전문가 3명이 기존 자료와 Evidence Pack을 교차 검토 | 2명 이상이 준비·검토 시간 30% 이상 감소를 보고하고, 치명적 누락 0 |
| 재현 가능한가 | 동일 입력·버전 반복 실행과 revision diff 검증 | canonical ID 변화 0. 버전이 다르면 원인을 설명 가능 |
| GIWA 검증이 동작하는가 | 정상·변조·폐기(superseded) revision 시나리오 | 정상 current revision은 통과, 변조본과 폐기본은 거부 |
기준을 미리 고정하는 이유
결과를 본 뒤 성공 조건을 바꾸지 않도록 임계값을 미리 정한다.
이 중 두 평가는 아직 없는 인터페이스에 의존한다. coverage 인터페이스와 Evidence Pack이다. 세무 원가와 리포트가 만들어지기 전에는 실행할 수 없다. GIWA 시나리오는 contract가 배포되기 전에는 실행할 수 없다. GIWA 무결성 검증을 참고하라.
현재 주장과의 관계
이 평가들이 결과를 내기 전까지, 이 문서는 속도·정확도·누락률에 대한 비교 표현을 쓰지 않는다. 주장 경계를 참고하라.