법률의견서 평가를 엄브렐러와 논증 무결성 감사로 다시 설계해 보았습니다

📝 한줄 요약

오늘 오전 2시부터 법률의견서 평가 Skill을 하나의 긴 문서에서 라우터·근거 프레임·실질 평가·런타임·검증·운영이 분리된 엄브렐러 구조로 다시 설계했습니다. 마지막에는 LARP의 고수준 논증 감사 원리를 법률용 argument-audit overlay로 독립 구현했고, 전체 회귀 69개·static validator·실제 CLI read-back까지 통과했습니다.

핵심만 먼저 말하면 다음과 같습니다.

• 법률의견서 평가는 점수표부터 만드는 작업이 아니라, 무엇을 평가할 수 있는지 먼저 고정하는 작업이었습니다.

• basis는 법령·판례·사실·가정·보류를 분리하고, 그 다음에야 core와 점수 경로가 열립니다.

• 평가자·검증자·조정자를 붙이는 것보다 중요한 것은 각 역할의 정보 경계와 실패 반환을 고정하는 일이었습니다.

• decision-moment replay와 model replay는 서로 다른 상태로 기록했고, provider 인증 실패는 실제 모델 호출 전에 차단했습니다.

• LARP는 법률판단이나 Gold로 복사하지 않고, 주장·근거·인용·경쟁가설의 연결을 검사하는 비점수 sidecar로만 적용했습니다.

• 최종 argument-audit는 COMPLETE가 되어도 점수·법적 결론·Gold를 만들지 않습니다.

🎯 이런 분들께 도움돼요

• 법률의견서 평가 시스템을 단순 점수표 이상으로 설계하려는 분

• 여러 AI 평가자를 붙였지만 결과가 정말 독립적인지 확인하기 어려운 분

• 법령·판례·증거·기준일을 평가 전에 분리하고 싶은 법무·감사 담당자

• 실제 처분이나 판결이 아직 없는 사전예측형 법률의견서를 평가하는 분

• AI 평가의 “성공”과 실제 법률 품질·Gold·사건 결과를 구분하고 싶은 분

• argument map, evidence trace, decision point를 법률 업무에 적용하려는 분

😫 문제 상황 (Before)

처음의 법률의견서 평가는 다음처럼 보였습니다.

의견서 읽기
→ 루브릭으로 점수 매기기
→ 부족한 점 쓰기
→ 평균 또는 조정 점수 만들기

하지만 실제로 한 문서를 평가하려고 하면 서로 다른 작업이 한꺼번에 섞여 있었습니다.

• 이 문서가 답해야 할 질문은 무엇인가

• 원 의견서가 실제로 제공되었는가

• 사실과 가정은 구분되어 있는가

• 기준일에 맞는 법령과 판례인가

• 인용한 권위의 원문은 확인되었는가

• 각 법률요건은 어떤 증거와 연결되는가

• 상대방의 최강 반론은 무엇인가

• 문서의 결론을 바꿀 수 있는 사실은 무엇인가

• 지금 숫자 점수를 만들어도 되는가

• 실제 결과가 없는 사전예측을 어떻게 평가할 것인가

이 질문들을 한 명의 평가자가 한 번에 처리하면, 결과 JSON에 점수가 남더라도 그 점수가 어디에서 나왔는지 추적하기 어려웠습니다. 반대로 평가자를 여러 명으로 늘리면 독립성이 자동으로 생기는 것도 아니었습니다. 같은 프롬프트와 같은 누락 자료를 보면 여러 모델이 같은 실수를 반복할 수 있기 때문입니다.

이번 작업의 대표 입력은 실제 의뢰인의 문서가 아닌 합성 납품지연 법률의견서 fixture로 고정했습니다.

계약일: 2026-01-10
약정 납품일: 2026-02-01
실제 납품일: 2026-02-20
주장한 대체구매 비용: 1,000,000원
기준일: 2026-02-20
관할: 대한민국
필수 검토 권위: 민법 제390조·제393조·제396조

이 fixture는 지연 사실, 귀책, 인과관계, 통상손해·특별손해, 예견가능성, 과실상계, 증거계획, 반론, 손해액 계산을 한꺼번에 시험하기 좋았습니다. 동시에 계약 조항·시장가격 자료·직접 판례·실제 결과가 없으면 어디까지나 합성 사전예측이라는 한계도 분명했습니다.

🛠️ 사용한 도구

• Hermes Agent: parent router, child skill, runner, route planner와 검증기를 실제 파일로 연결했습니다.

• legal-opinion-evaluator v5: 엄브렐러 진입점·공통 상태·handoff·Gold firewall을 담당했습니다.

• legal-opinion-evaluation-core: 한 의견서의 실질 평가와 루브릭을 parent에서 분리했습니다.

• evidence-basis-framer: 공식·추론·보조·보류 근거와 claim receipt를 점수 전에 만들도록 했습니다.

• ensemble runner / route planner: QUICK·ENSEMBLE·strict precondition·proof bundle·fail-closed 흐름을 실행했습니다.

• decision-moment replay engine: source hash·context boundary·authority receipt·contamination·annotation disagreement를 모델 호출 없이 검사했습니다.

• argument-integrity audit engine: pre-read registration, E→M→P→H chain, quote·coverage·rival·reconstruction을 결정형으로 감사했습니다.

• 합성 fixture: private 의견서와 실제 사건 결과를 공개하지 않고 같은 입력을 반복 검증했습니다.

이번 글은 내부 실행 과정을 설명하지만, private 원문·업무 대화 정보·내부 절대경로·임시 로그·인증정보를 사례 본문에 옮기지 않았습니다.

🔧 작업 과정

1. 오전 2시 10분: 긴 Skill을 엄브렐러로 분리했습니다

작업을 시작한 요청은 다음과 같았습니다.

legal-opinion-evaluator skill v5를 엄브렐러 구조로 다시 설계한다.

먼저 기존 Skill을 다시 읽으면서 입력 게이트, 법률 루브릭, 앙상블 런타임, Gold 정책, 운영 책임이 어디에서 겹치는지 표시했습니다. 결론은 “문서가 길다”가 아니라 “서로 다른 책임이 같은 파일과 같은 상태 필드에 섞여 있다”는 것이었습니다.

그래서 parent는 다음만 소유하도록 줄였습니다.

무엇을 평가할지 결정
→ 필요한 child 선택
→ 공통 상태와 handoff 적용
→ proof와 finalization 확인

실질 평가 루브릭은 core child로 분리하고, 근거 프레임은 별도의 basis child가 담당하도록 했습니다. 이후 module registry와 route registry를 만들고, 기존 runner·reference·mock fixture·직접 호출 호환성은 보존했습니다.

이때 처음부터 고정한 원칙은 다음이었습니다.

basis가 점수를 만들지 않는다.
core가 Gold를 혼자 승격하지 않는다.
runtime 성공이 법률 품질을 증명하지 않는다.
score_allowed와 gold_eligible을 합치지 않는다.

검증 결과: v5 static validator PASS, Python compile PASS, 기존 runner 32개 회귀 PASS. 정상 Mock ENSEMBLE은 3명의 평가자·검증자·조정자가 동작했고, fail-closed fixture는 grader 실패 후 조정자를 호출하지 않고 점수를 null로 유지했습니다.

2. 오전 3시 15분: 근거가 점수보다 먼저 오도록 만들었습니다

엄브렐러 구조만으로는 충분하지 않았습니다. 법률의견서에서 가장 위험한 부분은 “점수는 만들어졌지만 그 점수를 지탱하는 권위·사실·증거의 층위가 섞이는 것”이기 때문입니다.

그래서 다음 근거 frame을 먼저 만들도록 했습니다.

official  = 공식 법령·판례·행정자료
inferred  = 사실·문언으로부터의 추론
auxiliary = 보조자료·설명·검색 단서
hold      = 아직 확인되지 않아 보류하는 항목

hold를 평균점수나 moderator로 숨기지 않는 것이 핵심이었습니다. 필수 권위가 확인되지 않으면 점수는 보류하고, 무엇을 추가로 확인해야 재개되는지를 반환하도록 했습니다.

합성 납품지연 fixture에서는 민법 제390조·제393조·제396조를 필수 권위로 두고, 계약서·가격자료·직접 판례가 확인되지 않은 상태를 별도 불확실성으로 남겼습니다. 실제 결과가 아직 없다는 이유만으로 fixture 전체를 평가불가로 만들지 않고, 사전예측의 구조·조건·증거계획·불확실성 공개를 평가 대상으로 고정했습니다.

검증 결과: 정상 Mock ENSEMBLE, retry 복구, strict fail-closed, Hermes QUICK canary를 분리 read-back했습니다. QUICK canary는 DEFERRED, PASS_WITH_LIMITATIONS, final_total=null로 종료되었습니다. 불충분한 가상 권위를 점수화하지 않은 결과였습니다.

3. 오전 9시 37분부터: 계획과 실행을 분리했습니다

다음 문제는 “route를 문서에 적어 두었지만 runner가 실제로 다른 경로로 실행할 수 있다”는 것이었습니다.

그래서 route_planner가 먼저 결정형 receipt를 만들고, runner는 그 receipt를 받아 실행하게 했습니다.

request
→ route_id
→ required modules
→ authority mode
→ score policy
→ minimum execution profile
→ runner execution
→ proof bundle

--strict-v5에서는 parent가 다음 두 receipt를 제공하지 않으면 평가자 fan-out 자체를 중단합니다.

basis_frame.status = COMPLETE
authority_pack.status = COMPLETE

이 구조는 “검증이 부족하지만 일단 모델을 불러서 점수를 받아 보자”는 유혹을 차단했습니다. 점수 허용 여부는 모델의 자신감이 아니라 route policy, input gate, basis, authority, verification이 함께 결정합니다.

이어 실제 ENSEMBLE v3에서 verifier가 잘못된 동일가중 산식을 사용한 문제를 재현했습니다. 단순히 verifier의 FAIL을 삭제하지 않고, runner가 canonical rubric 가중치로 deterministic recompute를 하도록 했습니다. 모델의 arithmetic 오류를 보정할 수는 있지만, 실제 총점 불일치는 계속 fail-closed로 남겼습니다.

검증 결과:

전체 회귀: 49 tests, OK
ENSEMBLE v3: 7/7 calls successful
grader totals: A 88.0 / B 77.0 / C 80.0
final_total: 80.0
verification: PASS
Gold scope: SCOPED_GOLD: ex-ante-prediction

여기서도 모델 다양성은 UNVERIFIED_DEFAULT로 남겼습니다. provider가 여러 개처럼 보이는 것과 실제 모델·endpoint 다양성이 입증되는 것은 다르기 때문입니다.

4. 오전 11시 47분부터: 판단 순간을 별도 overlay로 분리했습니다

이 단계의 실제 요청은 다음과 같았습니다.

TutorMoments 원리를 참고하여 legal-opinion-evaluator v5 엄브렐러를 계속 확장한다.

법률의견서 전체를 한 번에 평가하는 방식만으로는 “어느 지점에서 어떤 도움이나 검증이 필요했는가”를 비교하기 어려웠습니다. 그래서 TutorMoments의 고수준 원리를 참고해 decision-moment-replay overlay를 추가했습니다.

이 overlay는 다음을 별도로 기록합니다.

• 판단 분기점

• 분기점 전후의 context boundary

• 공개된 자료와 withheld 자료

• 기대 행동 목록

• authority receipt

• annotation consensus와 disagreement

• contamination 여부

• trajectory metric

중요한 점은 behavioral replay를 법률점수나 Gold로 승격하지 않는 것입니다. clean replay는 metric 분모에 포함하지만, context leakage·hash mismatch·미해결 annotation·authority pending은 제외 또는 차단 receipt로 남깁니다.

처음에는 replay engine이 연결되지 않은 경우를 명시적으로 REPLAY_ENGINE_NOT_CONNECTED로 차단했습니다. 이후 deterministic engine을 연결해 모델을 부르지 않고 fixture 자체를 검증했습니다. 그 다음에야 명시적 provider·model·prompt를 받아 단일 model trajectory canary를 실행했습니다.

검증 결과:

deterministic replay full suite: 57 tests, OK
model replay full suite: 59 tests, OK
clean replay: INCLUDED
contaminated replay: EXCLUDED
score_authorization: NOT_APPLICABLE
final_total: null
gold_eligible: false

단일 OpenAI Codex·gpt-5.6-luna trajectory는 verify_official_receipt 행동을 보인 한 건의 behavior evidence일 뿐, 법률점수나 모델 다양성 증거가 아닙니다.

5. 오후 12시 35분부터: 인증 상태와 호출 성공을 분리했습니다

Anthropic 경로에서는 “로그인되어 있다”와 “실제 호출할 수 있다”가 다르다는 문제가 드러났습니다.

auth registry: LOGGED_IN
actual credential probe: 403
non-interactive model ID: not confirmed

이 상태에서 모델 ID를 추측해 호출하지 않았습니다. 대신 provider preflight를 추가하고, 인증 실패는 모델 subprocess 전에 차단하도록 했습니다.

auth preflight
→ PASS이면 model call
→ 403이면 PROVIDER_CREDENTIAL_FAILED
→ model_calls=0
→ score_authorization=NOT_APPLICABLE

이 실패는 시스템이 작동하지 않았다는 뜻이 아니라, 작동하지 않는 provider를 작동한 것처럼 보고하지 않는 운영 게이트가 작동했다는 뜻입니다.

검증 결과: provider credential 403 테스트 PASS, 전체 suite 60 tests OK, Claude live canary는 BLOCKED_AUTH_403_AND_MODEL_ID_DISCOVERY로 유지했습니다. 이 결과를 성공 canary로 포장하지 않았습니다.

6. 오후 4시 8분: LARP를 법률 권위가 아닌 overlay로 읽었습니다

판례 리버스 엔지니어링 작업에서는 판결문만으로 사실관계·당사자 공방·법원의 판단경로·가능한 반사실을 추출하는 작업을 진행했습니다. 이 과정에서 LARP의 논증 감사·증거 추적·시간축·민감도 원리를 참고했습니다.

여기서 중요한 경계가 있었습니다.

LARP의 verdict
≠ 법률적 진실
≠ 판례의 canonical schema
≠ Gold 정답

판결문에 언급되지 않았다는 이유만으로 당사자가 실제로 주장하지 않았다고 단정하지 않았습니다. 심급 관계와 source scope를 다시 고정하고, 확인된 내용·판결문상 미언급·기록 미확인·반사실적 제안을 서로 다른 상태로 두었습니다.

LARP는 원문 prompt·script·fixture를 복제하지 않고, 법률 domain의 독립 계약으로 다시 표현했습니다.

7. 오후 4시 41분: 주장·근거·인용 연결을 별도 감사로 완성했습니다

마지막으로 v5 엄브렐러에 argument-audit route를 추가했습니다.

governance
→ basis
→ reasoning
→ argument-integrity audit

이 route는 법률점수를 만들지 않습니다. 입력을 읽기 전에 다음을 먼저 등록합니다.

primary hypothesis
competing hypothesis
expected evidence
user stop gate
repair owner

그 다음 다음 구조를 감사합니다.

E = evidence
M = meaning / legal significance
P = proposition / application
H = conditional effect or conclusion

각 노드와 간선은 출처·권위 receipt와 연결되어야 합니다. 중앙 주장에 source reference가 없거나, E→M→P→H chain이 끊기거나, 경쟁가설에 expected evidence가 없거나, 인용문이 source text와 맞지 않으면 실패 코드를 반환합니다.

대표적인 실패 반환은 다음과 같습니다.

ARGUMENT_SOURCE_HASH_INVALID
ARGUMENT_REGISTRATION_NOT_PRE_READ
ARGUMENT_EXPECTED_EVIDENCE_MISSING
ARGUMENT_ORPHAN_NODE
ARGUMENT_CHAIN_GAP
ARGUMENT_WARRANT_GAP
ARGUMENT_QUOTE_MISMATCH
ARGUMENT_STOP_GATE_MISSING
ARGUMENT_REPAIR_OWNER_MISSING

이 route의 clean 결과는 다음과 같습니다.

status: COMPLETE
engine: deterministic-offline
score_authorization: NOT_APPLICABLE
score_allowed: false
final_total: null
gold_eligible: false
model_calls: 0

COMPLETE라는 말도 여기서는 “논증 map이 계약상 재구성 가능하다”는 뜻일 뿐입니다. 법률적으로 옳다는 뜻도, 인용한 법령이 현행이라는 뜻도, 향후 소송 결과를 맞힌다는 뜻도 아닙니다.

최종 검증 결과:

argument-integrity targeted tests: 5 tests, OK
전체 evaluator suite: 69 tests, OK
py_compile: PASS
static validator: PASS
CLI route: argument-audit
operation_mode: OFFLINE
calls: 0
audit_status: COMPLETE
envelope audit: COMPLETE

✅ 결과 (After)

Before / After

오늘 확인한 수치

초기 v5 runner 회귀: 32 tests
strict runtime 단계: 47 tests
ENSEMBLE arithmetic closure: 49 tests
decision-moment overlay: 53 → 57 tests
model replay: 59 tests
provider preflight hardening: 60 tests
최종 argument-integrity 반영 후: 69 tests
최종 static validator: PASS
최종 argument-audit CLI: COMPLETE / OFFLINE / calls=0

시간 절약이나 비용 절감률은 측정하지 않았습니다. 오늘 확인한 것은 운영 성능이 아니라 상태 분리·실패 차단·증거 연결·재현 가능한 read-back입니다.

💬 이 과정에서 배운 AI 활용 팁

1. “모델을 더 붙여 달라”를 역할·정보 경계 문제로 다시 쓰기

평가자 수를 늘리기 전에 각 평가자가 무엇을 보며 무엇을 보지 않는지 먼저 적어야 합니다. 모델 세 개가 같은 누락 자료를 공유한다면 세 번의 답변이지 세 개의 독립 검토가 아닙니다.

2. 계획·구현·실행·검증을 서로 다른 문장으로 쓰기

다음 네 문장은 서로 다릅니다.

구현했다.
실행했다.
성공했다.
법률적으로 타당하다.

이번 작업에서는 각각 파일, runner receipt, 실제 output, authority·human gate를 통해 별도로 확인했습니다.

3. 실패를 숨기지 말고 다음 단계의 입력으로 만들기

DEFERRED, REPLAY_ENGINE_NOT_CONNECTED, PROVIDER_CREDENTIAL_FAILED, ARGUMENT_CHAIN_GAP은 모두 “실패했으니 지운다”가 아니라 “어떤 입력이 부족한지 알려 주는 상태”입니다.

4. 숫자보다 score authorization을 먼저 보기

final_total=80.0이 있다는 사실보다, 그 숫자가 어떤 gate를 통과해 허용되었는지가 중요합니다. 반대로 COMPLETE인 argument map도 숫자 점수를 허용하지 않을 수 있습니다.

🌍 다른 업무에 적용한다면?

감사 대응 메모

evidence: 감사 지적·계약·문서
meaning: 위반 사실과 법적 의미
proposition: 조치의 법적 근거와 요건 적용
hypothesis: 처분 가능 / 처분 제한
hypothesis evidence: 통지·시정기회·권한·기준일 자료

계약 해지 검토

계약 조항, 위반 사실, 통지, 시정기회, 해지 사유, 손해자료를 각각 evidence node로 만들고, “해지 가능”과 “절차상 해지 제한”을 경쟁가설로 등록할 수 있습니다.

행정심판·소송 준비

청구원인, 처분사유, 입증자료, 권위 receipt, 반론, 구제수단을 분리해 어느 주장이 source 없이 남아 있는지 먼저 찾을 수 있습니다. 다만 argument-audit가 법적 승패를 판정하는 것은 아닙니다.

내부 AI 품질관리

모델 답변을 바로 점수화하지 않고, 답변의 주장·근거·인용·불확실성·repair owner를 별도 receipt로 남길 수 있습니다. 이 구조는 일반 LLM 답변 품질관리에도 적용할 수 있지만, 법률 conclusion으로 자동 승격해서는 안 됩니다.

🚀 앞으로의 계획

이번 구현은 다음 범위까지 닫혔습니다.

contract
→ implementation
→ regression
→ static validation
→ real CLI read-back

다음 단계는 별도 승인과 자료를 전제로 합니다.

1. raw opinion에서 argument node를 추출하는 LLM-assisted adapter

2. 공식 법령·판례 receipt와 argument node의 자동 연결

3. 비식별 실제 의견서에 대한 human adjudication

4. 합성 사전예측 fixture와 사람 판정의 비교

5. actual notice·disposition·judgment가 생겼을 때 OUTCOME_VALIDATION

6. LARP seed adapter를 한국 판결문의 표·호증·판시 구조에 맞게 확장

7. Anthropic credential·비대화형 model ID가 확인된 뒤 별도 Claude canary

이번 글에서 말하는 Gold는 다음처럼 제한합니다.

SCOPED_GOLD: ex-ante-prediction

이는 정해진 기준일·관할·사실 전제·권위 범위에서 사전예측형 의견서의 구조·근거·조건부 논증·불확실성 처리가 평가계약을 통과했다는 뜻입니다. 실제 승소·처분 적법성·손해액·OUTCOME_GOLD를 의미하지 않습니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 엄브렐러 route와 입력 게이트 고정

다음 [법률의견서/검토문]을 평가하기 전에 원문 제공 여부, 질의, 확정 사실, 미확인 사실, 기준일, 관할, 필수 권위, 첨부자료를 카드로 정리하세요. 평가 목적이 [구조점검/법률평가/앙상블/논증감사] 중 무엇인지 선택하고, EVALUABLE, LIMITED, DEFERRED 중 하나를 먼저 지정하세요. 근거는 official, inferred, auxiliary, hold로 분리하고, 점수·Gold를 만들 수 있는 조건과 만들 수 없는 조건을 별도로 적으세요. [의견서 원문], [질의], [사실·전제], [기준일·관할], [필수 권위 receipt]를 실제 자료로 교체하세요.

프롬프트 2: 독립 평가자·검증자·조정자

[평가자 A/B/C] 중 하나의 관점만 맡아 [범위·사실·출처 / 법리·권위·논증 / 증거·사용성·반론]을 독립 평가하세요. 다른 평가자의 결과는 보지 않았다고 전제하고, 모든 판단을 [문서 locator]와 [source receipt]에 연결하세요. 이후 검증자는 점수를 보기 전에 [필수 권위], [결정적 사실], [증거 공백], [최강 반론], [산술·citation map] 체크리스트를 작성하세요. 충돌이 생기면 평균·다수결 대신 [충돌 문항]만 [원문], [공식 receipt], [Gold contract]로 다시 확인하세요.

프롬프트 3: argument-integrity 사전등록과 map 감사

본문을 해석하기 전에 [primary hypothesis]와 [competing hypothesis]를 등록하고, 각 가설의 [expected evidence]를 적으세요. 그 다음 주장을 E(evidence) → M(meaning) → P(proposition) → H(conditional effect) 노드로 분리하고 각 노드에 [source_refs] 또는 [authority_receipt_ids]를 연결하세요. [quote], [coverage], [warrant], [rival parity], [reconstruction]을 검사하고, 끊어진 chain·고립 노드·source 없는 중심 주장·인용 불일치가 있으면 failure code와 [repair owner]를 반환하세요. 이 감사는 법률점수·Gold를 만들지 말고 score_authorization=NOT_APPLICABLE, final_total=null을 유지하세요.

📚 도움받은 글

이 사례는 외부의 평가·판단 구조와 논증 감사 아이디어를 참고했지만, 원문 prompt·script·fixture·문장을 복제하지 않고 법률의견서 평가용 계약으로 다시 설계했습니다.

1. MOSL님 — 「논술 채점 Skill에 세 명의 채점자와 조정자를 붙여 보았다」
   URL: https://www.gpters.org/nocode/post/added-three-graders-moderator-9OOBF1LEefC1KM3
   참고한 부분은 독립 평가자·검증자·조정자의 역할 분리입니다. 이를 법률 domain에서는 권위 receipt, 기준일, 증거 연결, Gold 범위와 결합했습니다.

2. tearess/LARP repository — 「LARP — Layer-grounded Argument Reasoning Probe」
   URL: https://github.com/tearess/LARP.git
   라이선스 notice: CC BY-NC-SA 4.0
   참고한 부분은 pre-read hypothesis, 논증 map, quote·coverage·rival·reconstruction을 별도 감사 대상으로 두는 고수준 원리입니다. 원문 prompt·script·fixture·protected asset은 복제하지 않았고, LARP verdict를 법적 진실이나 Gold로 사용하지 않았습니다.

3. Allen Institute for AI(Ai2) — 「TutorMoments: Do AI tutors know when to help and when to hold back?」
   URL: https://huggingface.co/blog/allenai/tutormoments
   참고한 부분은 판단 순간, context boundary, bounded replay, human annotation과 outcome의 분리입니다. 법률 evaluator에서는 이를 decision-moment-replay와 behavior-only 계약으로 바꾸고, 법률점수·Gold와 분리했습니다.

🏁 마무리

오늘의 작업은 평가자 수를 늘리는 일이 아니었습니다. 법률 AI가 어떤 조건에서 무엇을 주장할 수 있는지, 무엇을 보류해야 하는지, 실패했을 때 어디로 돌아가야 하는지를 파일·계약·receipt로 고정하는 일이었습니다.

가장 중요한 변화는 점수의 정밀도가 아니라 판단의 층위를 분리한 것입니다.

무엇이 입력되었는가
→ 무엇이 공식적으로 확인되었는가
→ 어떤 논증 연결이 존재하는가
→ 어떤 역할이 실제로 실행되었는가
→ 무엇을 검증했는가
→ 어디까지 Gold로 부를 수 있는가

그리고 마지막 argument-audit는 이 원칙을 다시 확인했습니다.

논증 map이 완성되었다고 해서 법적 결론이 확정되는 것은 아니다. 다만 어떤 근거가 어떤 주장으로 연결되었는지, 어디에서 수리를 시작해야 하는지는 더 투명하게 볼 수 있다.

실제 결과자료가 생기는 날에는 별도의 OUTCOME_VALIDATION을 실행해야 합니다. 오늘 완성한 것은 결과를 미리 맞히는 장치가 아니라, 결과를 기다리는 동안에도 평가 과정이 정직하고 재현 가능하도록 만드는 엄브렐러입니다.