chore: add Stage 1 v6 and v7 artifacts

This commit is contained in:
2026-07-21 10:48:36 +09:00
parent 32b1a35dca
commit e82c9e2848
174 changed files with 215995 additions and 0 deletions
@@ -0,0 +1,258 @@
# Stage 1 Part 1 개선 전략 보고서 — 두 비효율 리포트 비교 분석 (Claude v1)
- 비교 대상 문서:
- `Part_1_Inefficiency_Report_Codex_v1.md` (이하 **Codex 리포트**)
- `Part_1_Inefficiency_Report_Claude_v1.md` (이하 **Claude 리포트**)
- 분석 대상 작업: `Stage_1_Part_1_v2.yml`의 `Task_B1_quality_gate_evidence_indexed`(**B1 게이트**), `Task_B2_quality_gate_event_candidates`(**B2 게이트**) 및 그 주변 DAG
- 선별 기준: **최소의 노력**(LLM 추론은 꼭 필요한 곳에만 필요한 수준으로, 100% 결정적 작업은 Python 코드화, 토큰 경제성 최대화)으로 **최대의 효과**(최고 품질 유지, 토큰 경제성 증대, 에이전트 속도 최대화)
- 참고: Claude 리포트 §7.2(대안 B)는 지시에 따라 본 비교·선별에서 제외하였다.
---
## 0. 결론 요약
1. 두 리포트는 **서로 독립적으로 동일한 핵심 진단과 동일한 해법 방향에 도달했다.** 진단 — 비효율의 본체는 "fan-out 결과를 모아서 넘기는 것" 자체가 아니라, 그 fan-in을 LLM 컨텍스트로 수행(합계 약 500KB 입력)하고 통합 결과 전체(약 141~146KB)를 LLM 출력 토큰으로 재작성하게 하며, 이 대형 LLM 호출 2개를 `reasoning: high`로 파이프라인 꼬리에서 직렬 실행하는 구조다. 해법 — 두 게이트를 **결정적(Python) reducer로 전환**하고, 결정적 검사로 좁혀진 의미론적 예외가 있을 때만 소형 LLM 판정을 조건부 실행한다(예외 0건이면 LLM 0회).
2. 독립적으로 수렴한 이 합의 사항들은 신뢰도가 가장 높으므로 **전부 채택**한다. 두 리포트가 갈리는 지점은 5개이며, 본 보고서 §3에서 각각 판정했다. 핵심 판정: 예외 판정기는 단일 조건부 task(Claude안)에 Codex의 micro-pack 상한을 내장, `evidence_indexed.json`의 중복 배열은 제거(Claude안)하되 Codex의 호환성 우려를 fixture 검증 항목으로 흡수, audit/handoff 확정은 기존 SHA writer 무수정 유지 + 초소형 GC 신설(Claude안), 잔존 LLM reasoning은 기본 low + Codex의 3개 기준 충족 시에만 high escalation.
3. 실행 결과가 실증한 품질 결함은 합산 5건이다: **E-019 항목 통째 소실**(양 리포트 공통 발견), **candidate 필드 16종 무단 탈락**(Claude 고유), **B1 최종본 동일 배열 2중 수록**(Claude 고유 — Codex는 입력측 중복으로 실측), **dedup 3건 미기록**(Claude 고유), **audit `source_refs` shape 불일치로 handoff에서 ref 전량 소실 + `review_gate_count` 4≠1 오계수**(Codex 고유). 5건 모두 LLM-writer 구조의 산물이며, 결정적 reducer 전환으로 **구조적으로 불가능**해진다.
4. 이번 7/10 실행에서 게이트의 LLM 추론이 추가로 발견한 결함은 **0건**이었다(Claude 리포트 실증 — 유일 finding은 mapper self-warning의 릴레이 1건). 즉 개정 구조였다면 이번 실행의 게이트 구간은 LLM 0회 또는 초소형 1회로 끝났다. 이것이 "정상 경로 LLM 호출 2→0"이라는 개정 목표의 실증 근거다.
5. 예상 효과: 게이트 구간 LLM 입력 ~500KB → 0~수 KB, LLM 출력 ~146KB → 0~1KB, 게이트 구간 벽시계 수 분 → 수십 초(code 2회 + 조건부 소형 LLM ≤1회), Part 1 $2.09 중 게이트 2호출 몫 사실상 제거. 하류(Part 2/3/4)가 소비하는 파일 경로·스키마·sidecar 계약은 완전 동일하므로 **downstream DAG 변경 0건**.
---
## 1. 두 리포트의 공통 진단 — 합의 사항 (전부 채택)
두 리포트가 독립적으로 일치한 항목. 교차 검증이 완료된 것과 같으므로 추가 검토 없이 개정의 확정 전제로 삼는다.
| # | 합의 내용 | Codex 근거 | Claude 근거 |
|---|---|---|---|
| C-1 | 게이트의 **논리적 기능과 최종 산출물 3종은 삭제 불가.** `evidence_indexed.json`, `evidence_event_candidates.json`, `stage1_part1_soft_gate_handoff.json`은 Part 2/3/4가 실제로 읽는다 | §6 (Part 2 Stage A, Part 3 LES0, Part 4 FL0 직접 소비) | §6.1 (grep 실증: P2 5개소·P3 4개소·P4 3개소 등) |
| C-2 | **비효율의 본체 3중 구조**: ① fan-in을 LLM 컨텍스트로 수행 ② 통합 결과 전체를 LLM 출력으로 재작성 ③ 대형 호출 2개의 직렬 연쇄 + reasoning high | §3 (B2 게이트 최소 입력 308,269B 실측), §2.1 | §3 (증폭 ①②③), §2.1 |
| C-3 | 검증 항목의 **대부분은 결정적 대체 가능.** completeness·형식·유일성·집합 멤버십·exact dedup·정렬·병합·ID 확정·직렬화·count 집계는 100% Python | §5.1, §5.2 (작업별 판정표) | §4 (10+1개 항목 중 7개 완전 대체, 4개는 "후보 추출(결정적)→판정(LLM)" 분해) |
| C-4 | **E-019 항목 통째 소실** (30 part → 29 items, 후보 74→71) — 그런데 completeness check는 PASS. final writer와 validator를 한 LLM에 맡긴 보존성 위반 | §4.1 (기대/실제 대조표, E-019 후보 3건 명시) | §5 Q-1 (읽기는 했으나 재작성에서 소실; Part 4 `_lien_extinction_notice_scan`·Part 2 notice 도메인 실질 피해 가능성) |
| C-5 | 해법 = **결정적 reducer + 조건부 예외 판정.** 예외 0건이면 LLM task 자체를 실행하지 않음 | §7.1 (deterministic by default 원칙), §7.2 | §7.1 (Part 3 LES1/LES2에서 이미 검증된 샌드위치 패턴 이식) |
| C-6 | **B2 게이트 입력 다이어트**: 참조 무결성에 필요한 것은 finalized E-ID 집합(~30개 문자열, ~0.5KB)뿐인데 91.8KB 전문을 읽음 → compact manifest로 대체 | §3.4, §6, §7.2 B | §2.1, §6.2-2 |
| C-7 | **동일 ordinal B1→B2 mapper streaming은 효율적 — 유지** | §2.1, §8 | §2.1 (DAG 도해) |
| C-8 | **audit의 count·severity·source_refs는 LLM 자유 생성 금지** — 실제 배열 길이와 named object 스키마로 결정적 생성 | §4.2, §7.2 D, §10 | §6.2-6, §7.1 GC |
| C-9 | **모델 일괄 하향은 답이 아님.** 두 게이트는 이미 flash-lite — 개선 수단은 정상 경로의 LLM 호출 수를 2→0으로 만드는 것 | §9 | §4 핵심 관찰, §6.2-5 |
| C-10 | planner(`evidence_shard_plan.json`) 전문 로드 불필요 — 게이트에 필요한 것은 `expected_ordinals`/`shard_count` 수준의 소수 키 | §3.4 (shards/dynamic_fanout 27,165B×2 중복 실측) | §1 표, §6.2-3 |
---
## 2. 각 리포트의 고유 기여 — 통합안에 반영할 항목
### 2.1 Codex 리포트 고유 기여 (채택)
| # | 내용 | 반영처 |
|---|---|---|
| X-1 | **handoff에서 source ref 전량 소실 결함** (§4.2): B2 audit이 `source_refs`를 배열로 출력 → 결정적 writer가 기대하는 named object와 불일치 → 최종 sidecar의 review item ref가 전부 빈 배열. `review_gate_count=4` vs 실제 finding 1건 오계수 동반 | GC의 named object 스키마 강제 + count=len() 규칙 (§4 GC) |
| X-2 | **보존성 invariant의 정식화** (§5.2): `set(final evidence_index) == planner expected`, `len(items) == shard_count`, 모든 input part는 final item 또는 명시적 BLOCK finding에 정확히 1회 대응. dedup 시에도 source evidence item과 provenance는 보존 — 스키마가 표현 못 하면 후보 보존, semantic merge는 Stage 2로 | GA-2의 write 전·후 검증 (§4 GA-2) |
| X-3 | **핫픽스 7종** (§10): 위 invariant + "dedup group 없는데 후보 수 감소 → BLOCK", "ref shape 불일치 시 `HANDOFF_SOURCE_REF_SHAPE_INVALID` 기록" 등 전부 Python 구현 | §6 로드맵 — 별도 선행 구현하지 않고 GA/GC에 1회만 구현 (중복 작업 회피) |
| X-4 | **micro-pack 상한** (§7.2 C): pack당 evidence item ≤2, event candidate ≤8, source excerpt ≤1,500자, exception type 1종만, full planner/final/meeting/evidence 금지, 출력은 `exception_id, decision, severity, source_refs, concise_basis`만 | GB 입력·출력 규칙 (§4 GB) |
| X-5 | **reasoning escalation 3기준** (§7.2 C): ① 서로 다른 source가 같은 법률행위의 날짜·당사자·목적물을 실질 충돌 표시 ② authority drift가 source trace 유효성을 좌우 ③ chronology 판단이 hard block 여부를 좌우 — 이때만 high 허용 | GB 모델 설정 (§5) |
| X-6 | **tool-level allowlist에 의한 authority drift 구조적 차단** (§5.1): B1 mapper의 localdocs 접근을 assigned shard + 명시된 meeting slice로 제한하면 전역 raw 재독해 검사를 표본/예외 감사로 강등 가능 | §6 로드맵 Phase 2 (런타임 지원 여부 확인 후) |
| X-7 | **sub-task별 telemetry 추가 후 v.6 fixture로 A/B 실행** 권고 (§13) — 게이트 외 구간(mapper 등)이 런타임 증가에 기여했을 가능성을 계측으로 규명 | §7 검증 계획 (telemetry 추가) |
### 2.2 Claude 리포트 고유 기여 (채택)
| # | 내용 | 반영처 |
|---|---|---|
| Y-1 | **Q-2: candidate 필드 16종 무단 탈락** (§5): YAML의 pass-through 지시에도 28필드 중 12필드만 잔존. 탈락분에 `fraction_ref`·`legal_effect_candidate`·`defense_candidate` 등 v1/v2에서 하류 연계 위해 일부러 강화한 필드 포함 — **복원 필요.** 결정적 조립(dict 복사)이면 필드 소실이 구조적으로 불가능 | GA-2 pass-through 규칙 + fixture 검증 "candidate 28필드 보존" (§4, §7) |
| Y-2 | **Q-3: B1 최종본 2중 수록** (§5): `items`와 `evidence_indexed` 키가 바이트 동일한 30개 배열 — 91.8KB가 parts 합 54.3KB보다 커진 원인. 스키마 문구의 양자택일 모호성을 LLM이 "둘 다"로 해석 | §3 판정 D-1 (단일 배열 확정) |
| Y-3 | **Q-4: `dedup_findings: null`** (§5): 후보 3건 감소가 기록 없는 소실로 남음 | GA-2 dedup 기록 의무화 (§4) |
| Y-4 | **"이번 실행에서 LLM 추론의 추가 발견 0건" 실증** (§4): 전 항목 PASS, 유일 finding은 mapper self-warning 릴레이 → 개정 구조였다면 게이트 LLM 0회 또는 초소형 1회 | §0 결론 4, 개정 효과 추정의 실증 근거 |
| Y-5 | **audit 2종의 하류 소비 0건 grep 실증** (§6.1): `B1_*.json`/`B2_*.json`은 Part 1 내부(B2 게이트, SHA writer)만 소비 → **내부 인터페이스로 자유 재정의 가능.** SHA writer가 읽는 필드 4종만 유지하면 충분 | GA/GC audit 스키마 설계 자유도 (§4) |
| Y-6 | **B2→B1 직렬 의존의 실질 사유 분해** (§2.1): (a) 참조 무결성 — E-ID 목록만 필요 (b) review finding 승계 — audit 일부 필드만 필요. 의존 자체는 정당, 전달 표면만 수십 배 과대 | §4 개정 DAG (의존 유지, 전달물 축소) |
| Y-7 | **기존 파이프라인 자산 재사용 구현 디테일** (§7.1): Part 3 LES2의 budget_gate(항목 수·문자 수 상한) 재사용, `COMMON_CACHE_PREFIX_STAGE_1` 블록은 신규 LLM task(GB)에만 부착, SKILL.md의 code-executor 보일러플레이트(localdocs MCP httpx, `{{__user_hash__}}`)를 GA/GC에 그대로 사용 | §4 task 명세, 구현 노력 최소화 |
| Y-8 | **fixture 기반 검증 계획과 기대값** (§7.3): 7/10 실행물 재사용, 2-run 바이트 동일성(결정론) 검증, 의심 항목 주입 테스트 | §7 검증 계획 |
| Y-9 | **mapper self-warning 승격 판정 경로는 실제 작동 중인 유일한 실질 산출** (§6.3): review finding → sidecar → Part 2 승계 체인 보존 필수 | GB의 승격 판정 역할, §5 삭제 금지 목록 |
---
## 3. 상충 지점 판정
두 리포트가 갈리는 5개 지점. 판정 기준은 선별 기준 그대로 — 최소 노력·최대 효과·품질 무손실.
### D-1. `evidence_indexed.json`의 중복 배열 — **제거 (Claude안 채택, Codex 우려는 검증 항목으로 흡수)**
- Codex: 내부 parser들이 `items` 우선 소비이므로 제거 가능성 높으나, 외부 Stage 2/구버전 소비자 호환성 검증 전 제거는 비권장. 1차 개정에서는 alias 유지하되 B2 게이트 입력에서만 배제 (§6).
- Claude: 하류 3개 Part 전부 `items` 기준 소비를 grep으로 실증 — 중복 배열 1개 제거 가능 (§6.1).
- **판정**: v3에서 `items` 단일 배열로 확정한다. 근거 — ① Claude 리포트가 소비 지점을 실증했고 ② 결정적 writer 전환 후에도 중복은 파일 크기(및 하류 컴파일러 read량)를 2배로 유지하므로 토큰 경제성 원칙에 반하며 ③ Q-3의 원인인 스키마 모호성("`items` 또는 v.2 호환 구조")을 문구 차원에서 해소해야 재발이 막힌다. Codex의 호환성 우려는 기각이 아니라 **fixture 검증 항목으로 전환**한다: 개정 산출물로 Part 2 Stage A·Part 3 LES0·Part 4 FL0 파서를 실제 통과시켜 확인하고, v.6 외부(Stage 2 등)에 `evidence_indexed` 키를 읽는 소비자가 없는지 1회 grep으로 확정한 뒤 제거를 확정한다.
### D-2. 예외 판정기 형태 — **단일 조건부 task (Claude안) + Codex micro-pack 상한 내장**
- Codex: `Task_B12_quality_exception_adjudicator_*`를 dynamic fan-out으로 신설, exception cluster별 개별 LLM task (§7.2 C).
- Claude: 단일 `Task_B1B2_gate_llm_adjudicator`(GB)에 의심 항목 compact 목록 일괄 입력, budget_gate로 상한 (§7.1).
- **판정**: 단일 조건부 GB를 채택한다. 근거 — 실증 예외 건수가 0~1건 수준(Y-4)인데 cluster별 fan-out은 DAG 복잡도와 task 스폰 오버헤드만 추가한다(최소 노력 위반). 다만 Codex의 pack 상한(X-4)을 GB의 입력 구성 규칙으로 그대로 내장해 "단일 호출이 비대해지는" 위험을 차단하고, 의심 항목이 budget_gate 상한을 초과하는 드문 경우에만 fan-out으로 escalation하는 조항을 남긴다. Codex의 "exception 0건이면 LLM task를 생성하지 않음" 원칙은 양안 공통이므로 그대로 유지.
### D-3. audit/handoff 확정 주체 — **기존 SHA writer 무수정 + 초소형 GC 신설 (Claude안 채택)**
- Codex: 기존 `Task_B2_SHA256_soft_gate_handoff_writer`를 확장해 audit 2종 작성까지 통합 (§7.2 D).
- Claude: GB 판정 병합·audit 확정은 GC(GA 내 또는 초소형 code-executor)가 수행, 검증된 SHA writer는 무수정 연결 (§7.1).
- **판정**: GC 신설을 채택한다. 근거 — SHA writer는 이번 실행에서 유일하게 결함 없이 작동한 결정적 구성요소이고 Part 2가 소비하는 sidecar 계약의 생산자다. 이를 무수정으로 두면 회귀 위험이 0이 된다. Codex가 D안으로 달성하려던 목표(audit과 handoff의 count·source_refs 불일치 차단)는 GC가 audit을 결정적으로 확정하고 SHA writer가 그것을 그대로 파생하는 구조로 동일하게 달성된다(X-1 반영: named object 스키마 강제, count는 `len()`으로만). SHA writer로의 통합(task 1개 절감)은 v3 안정화 후 선택적 후속 단순화로 남긴다.
### D-4. 잔존 LLM reasoning 수준 — **기본 low, 유형별 medium, Codex 3기준 충족 시에만 high**
- Codex: exception 판정 기본 `reasoning=medium, verbosity=low`, 3개 기준 충족 시 high escalation (§7.2 C).
- Claude: 잔존 국소 판정은 low로 충분, 필요시 medium (§6.2-5).
- **판정**: 절충한다. self-warning 승격 분류·coverage 사유 서술 같은 경량 판정은 low, 날짜·법률행위 충돌 판정 등은 medium, Codex의 3기준(X-5)에 해당하는 경우에만 high. 근거 — 집계·분류 작업에 high reasoning이 기여한 증거가 이번 실행에 없고(Y-4), 반대로 법률적 모호성의 최고 난도 케이스에 대한 안전판(escalation)은 품질 무손실 원칙상 남겨야 한다.
### D-5. authority drift 검사 방식 — **1차: 의심신호 spot-check (Claude안), 2차: tool allowlist (Codex안)**
- Codex: mapper localdocs를 tool-level allowlist로 제한하거나 `source_support_manifest`를 추가해 구조적으로 차단 → 전역 재독해 검사를 표본/예외 감사로 강등 (§5.1).
- Claude: 상시 검사 삭제, 결정적 통합기가 낸 의심 신호(예: doc_type상 있어야 할 key_dates/key_amounts 공백, mapper self-warning 존재) 문서에 한해 해당 shard 원문만 GB 입력에 첨부 (§6.2-4).
- **판정**: 1차 개정(v3)에서는 Claude안을 채택한다 — GA-1의 결정적 검사에 신호 규칙 몇 줄을 추가하는 것으로 끝나 추가 노력이 거의 0이다. Codex의 tool allowlist는 더 근본적인 차단이므로 **런타임(Liti-agent)이 task별 localdocs 접근 제한을 지원하는지 확인 후 Phase 2로** 적용한다. `source_support_manifest`는 mapper 30개의 출력량을 늘려 mapper 구간 토큰을 증가시키므로(토큰 경제성 상충) allowlist가 불가능한 경우의 대안으로만 보류한다.
---
## 4. 최종 권고 아키텍처 (통합안)
### 4.1 개정 DAG
```text
Task_Evidence_shard_planner (Python, 기존 유지)
|
+-- Task_B1_map_doc_001..030 (LLM, 기존 유지)
| | same-ordinal streaming (유지 — C-7)
| v
| Task_B2_map_events_001..030 (LLM, 기존 유지)
| |
| all B1 parts all B2 parts
v |
GA-1 Task_B1_gate_merge_deterministic |
(code-executor) |
- evidence_indexed.json (items 단일) |
- finalized_evidence_id_manifest |
- B1 precheck + suspects |
| | |
| +---------------------------+
| |
| v
| GA-2 Task_B2_gate_merge_deterministic (code-executor)
| - evidence_event_candidates.json (전 필드 pass-through)
| - conservation 검사 (write 전·후)
| - B2 precheck + suspects
| |
| +-------------+--------------+
| | suspects = 0 | suspects > 0
| v v
| (GB 미실행, GB Task_B1B2_gate_llm_adjudicator
| "no suspects" 기록) (LLM flash-lite, 조건부, micro-pack)
| | |
| +-------------+--------------+
| v
+----------------> GC Task_B12_gate_audit_finalizer (code-executor, 초소형)
- B1/B2 audit 확정 (count=len, named source_refs)
|
v
Task_B2_SHA256_soft_gate_handoff_writer (기존 Python, 무수정)
|
v
OUT
```
하류에 보이는 것: `evidence_indexed.json`(중복 배열 제거 외 item 스키마 동일), `evidence_event_candidates.json`(경로·envelope·스키마 동일 + Q-2 탈락 필드 복원으로 오히려 하류 v2 필드 정상 공급), `quality_gates/*.json`(SHA writer 소비 필드 동일), sidecar 완전 동일. **Part 2/3/4 YAML 변경 0건.**
### 4.2 Task별 명세
**GA-1 `Task_B1_gate_merge_deterministic`** (code-executor / Python)
- 입력: `evidence_shard_plan.json`(코드 파싱이므로 로드 무해 — C-10), `evidence_indexed_parts/E-*.json` 30개. ~~`evidence_all.json` 전문, `client_meeting.md` 전문~~ 상시 로드 삭제 (D-5).
- 수행: expected/received/stale set 비교 → part 단일 item·스키마·`E-{ordinal:03d}` 형식 검사 → ordinal·proposed ID·source pointer·content hash 검사 → stable sort로 전 item 보존 병합 → final `evidence_index` 확정 → exact duplicate(doc_uid·content hash·정규화 title) 및 component coverage 규칙 검사 → **의심 신호 규칙**으로 duplicate-alias 후보쌍·coverage 의심건·authority-drift 의심건 추출 → mapper self-warning 전량 `review_candidates[]`로 승계 (Y-9).
- 출력: `evidence_indexed.json`(**`items` 단일 배열** — D-1), `finalized_evidence_id_manifest.json`(~0.5KB — C-6), B1 precheck/suspects(audit skeleton).
**GA-2 `Task_B2_gate_merge_deterministic`** (code-executor / Python)
- 입력: `evidence_event_candidate_parts/E-*.json` 30개, `finalized_evidence_id_manifest.json`, GA-1 suspects. ~~full `evidence_indexed.json`, full B1 audit, full planner 중복 객체~~ 제거 (C-6, Y-6).
- 수행: expected/received/stale set 비교 → schema invariant(empty candidates + null zero_event_reason 포함) → 참조 무결성(manifest 집합 멤버십) → candidate ID 형식·유일성 → `identity_signature` exact dedup(canonical 우선순위 규칙은 YAML에 이미 결정적으로 명문화되어 있으므로 그대로 코드화, **`dedup_findings[]` 기록 의무** — Y-3) → EVT-ID finalize → **candidate 전 필드 dict 복사 pass-through** (Y-1: 항목·필드 소실이 구조적으로 불가능) → 날짜 역전 스캔·REQUIRED_EVENT_SUBKINDS 공백 검사로 chronology/coverage 의심건 추출.
- **보존성 invariant (write 전·후 각 1회 — X-2, X-3):**
```text
set(final.items[*].evidence_index) == set(planner.expected_evidence_ids)
len(final.items) == planner.shard_count
sum(input part candidates) == sum(final candidates) + len(dedup_findings)
dedup group 없이 candidate 수 감소 → BLOCK
모든 input part는 final item 또는 명시적 BLOCK finding에 정확히 1회 대응
candidate 필드 수 보존 (dict copy + count 재검증)
```
- 출력: `evidence_event_candidates.json`, B2 precheck/suspects, (GA-1 suspects와 합산한) `B12_exception_pack.json`.
**GB `Task_B1B2_gate_llm_adjudicator`** (LLM, **조건부** — suspects 0건이면 미실행)
- 입력: 의심 항목 compact 목록만. **micro-pack 상한 (X-4):** pack당 evidence item ≤2, event candidate ≤8, source excerpt ≤1,500자, exception type 1종. authority-drift 의심 문서에 한해 해당 shard 원문만 첨부 (D-5). full planner/final/meeting/evidence 금지. Part 3 LES2의 budget_gate 방식 재사용 (Y-7). 상한 초과 시에만 fan-out escalation (D-2).
- 출력: 항목별 `{exception_id, decision, severity, issue_type, source_refs, concise_basis}`만 (수백 토큰).
- `COMMON_CACHE_PREFIX_STAGE_1` 블록은 이 신규 task에 부착, 기존 블록 무수정 (Y-7).
**GC `Task_B12_gate_audit_finalizer`** (code-executor / Python, 초소형)
- GA precheck + GB 판정을 병합해 `quality_gates/B1_evidence_indexed_gate.json`·`B2_event_candidates_gate.json` 확정. audit 2종은 하류 소비 0건이 실증되었으므로(Y-5) SHA writer가 읽는 인터페이스 필드(`hard_gate_findings[]`, `review_findings[]`, `review_gate_summary`, `handoff_export_summary`)와 결정적 체크 결과로 국한해 재정의.
- **모든 count는 실제 배열 길이에서만 계산, `source_refs`는 named object(`evidence_indexes`/`event_candidate_ids`/`meeting_clause_refs`/`doc_titles`) 스키마 강제, shape 불일치는 schema failure** (X-1, C-8). 서사적 자유서술 필드(`stage2_risk_notes[]` 등 소비자 없는 부분)는 결정적 생성 범위로 국한.
**SHA writer** (기존 Python task): **무수정** (D-3).
---
## 5. 모델·토큰 경제성 판단
| 작업군 | 실행 주체 | 모델/설정 |
|---|---|---|
| completeness, 형식, 집합, exact dedup, 정렬, 병합, ID 확정, 직렬화, count, digest | Python (GA-1/GA-2/GC) | LLM 없음 — 정상 경로 게이트 LLM 호출 **2 → 0** (C-9) |
| self-warning 승격 분류, coverage 누락 사유 서술 | GB | `gemini-3.1-flash-lite`, reasoning **low**, verbosity low |
| 모호한 alias·chronology·법률행위 충돌 판정 | GB | 동일 모델, reasoning **medium** |
| Codex 3기준(X-5) 해당 케이스 | GB | 동일 모델, reasoning **high**로 제한 escalation (D-4) |
| B1/B2 mapper 60개 | 기존 유지 | 본 개정 범위 외 (v.6 런타임 증가 원인의 나머지 후보 — X-7의 telemetry로 후속 계측) |
예상 효과(추정 명시): 게이트 구간 LLM 입력 ~500KB → 0~수 KB, 출력 ~146KB → 0~1KB, 벽시계 수 분 → 수십 초, Q-1~Q-4 및 X-1 결함 구조적 차단, 하류 계약 무변경. 이번 7/10 실행과 동일 입력이었다면 GB는 self-warning 승격 1건 판정의 초소형 호출(또는 규칙 매핑으로 0회)이었다 (Y-4).
### 삭제·유지·조건부 최종 판정 (통합)
| 구분 | 항목 |
|---|---|
| **삭제 (정상 경로에서 제거)** | 게이트 2개의 full-context LLM merge·JSON 재작성 역할 / B1의 `evidence_all.json`·`client_meeting.md` 상시 전문 로드 / B2의 `evidence_indexed.json` 전문 로드·B1 audit 전문 import / LLM 생성 count·severity·ID sequence·schema envelope / `evidence_indexed.json` 중복 배열(D-1, fixture 검증 조건부) / `llm_reasoning: high` 상시 적용 |
| **유지 (변경 금지)** | 최종 산출물 3종의 경로·envelope·스키마 / 단일 writer 원칙과 fan-in 지점 / B2→B1 의존(전달물만 manifest로 축소) / HARD·REVIEW 분류와 BLOCK 의미론(rerun_target_task 라우팅 포함) / mapper self-warning 승격 경로 / SHA256 digest_guard sidecar와 그 결정적 writer / 동일 ordinal streaming |
| **조건부 (예외 시에만 LLM)** | suspected alias 판정 / 모호한 authority drift / relation key 불명확 chronology / 문서 의미 해석이 필요한 legal-effect coverage |
---
## 6. 이행 로드맵
**Phase 1 — v3 본 개정 (핵심, 즉시 착수)**
1. GA-1/GA-2/GB/GC를 반영한 `Stage_1_Part_1_v3.yml` 작성. task_procedure: `all Task_B1_map_doc_*`→GA-1, `all Task_B2_map_events_*`+GA-1→GA-2→GB(조건부)→GC→SHA writer(무수정). code-executor 보일러플레이트는 SKILL.md 기존 패턴 재사용 (Y-7).
2. Codex 핫픽스 7종(X-3)은 **별도 선행 작업으로 이중 구현하지 않는다** — 전부 GA-2 write 전·후 검증과 GC 스키마 강제로 1회만 구현된다(최소 노력). 단, v3 반영이 지연될 경우에 한해 임시 방편으로 기존 SHA writer에 conservation set-equality 검사만 추가해 E-019류 소실의 하류 전파를 차단한다.
3. `evidence_indexed` 중복 키 제거 전 v.6 외부 소비자 grep 1회 확정 (D-1).
**Phase 2 — 구조적 강화 (v3 안정화 후 선택)**
4. 런타임의 task별 localdocs allowlist 지원 확인 → B1 mapper 접근 제한으로 authority drift 구조 차단 (X-6). 불가 시에만 `source_support_manifest` 검토.
5. GC를 SHA writer로 통합해 task 1개 절감 (D-3의 후속 단순화).
6. sub-task별 telemetry(시간·토큰·read bytes·LLM call 수) 추가 후 v.5/v.6/v3 A/B 계측 — mapper 구간 등 게이트 외 원인 규명 (X-7).
---
## 7. 검증 계획 (fixture 기대값)
7/10 실행물(`Results_July_10_3_15pm`)을 회귀 fixture로 사용한다 (양 리포트 공통 + Claude §7.3 구체화).
1. **결정적 통합기 로컬 검증**: 이번 실행의 30개 part를 입력으로 GA-1/GA-2 실행 →
- `evidence_indexed.json`: 30 items, 단일 배열(중복 제거 외 item-level 동등)
- `evidence_event_candidates.json`: **30 items / 후보 74건 / E-019 3건(`lien_extinction_notice_dispatch`, `ongoing_physical_possession`, `lien_violation_candidate`) 보존** / candidate **28필드 전량 보존** / exact duplicate signature group 0개 확인
- 2-run 바이트 동일성(결정론 확인)
- GC 산출 audit: count == 실제 배열 길이, `source_refs` named object, sidecar 입력 인터페이스 필드 존재
2. **의심 항목 주입 테스트**: 고의 결측 part, 중복 signature, 날짜 역전, candidate 필드 삭제 → GB 트리거·BLOCK 경로·conservation BLOCK 확인.
3. **하류 무영향 검증**: 개정 산출물로 Part 2 Stage A·Part 3 LES0·Part 4 FL0 파서 통과 확인(특히 D-1의 단일 배열).
4. **실측 재실행**: v3로 Part 1 실행 → 시간·비용을 v.5/v.6과 비교. 목표: 정상 사례 게이트 LLM 호출 0회, 보존성 오류 0, audit count/source_refs 스키마 오류 0.
---
## 8. 채택하지 않은 권고와 사유
| 권고 | 출처 | 미채택 사유 |
|---|---|---|
| exception cluster별 dynamic fan-out adjudicator | Codex §7.2 C | 실증 예외 0~1건 규모에 과설계 — 단일 조건부 GB + budget 초과 시 escalation으로 대체 (D-2) |
| SHA writer 확장으로 audit 작성 통합 | Codex §7.2 D | 유일하게 무결함으로 작동한 구성요소의 무수정 유지가 회귀 위험 최소 — GC로 동일 목표 달성, Phase 2 옵션으로 보류 (D-3) |
| `evidence_indexed` alias 1차 유지 | Codex §6 | grep 실증(Y-5 방법론)으로 하류가 `items`만 소비 — 제거하되 호환성 우려는 fixture 검증으로 흡수 (D-1) |
| `source_support_manifest` 즉시 도입 | Codex §5.1 | mapper 30개 출력 토큰 증가로 토큰 경제성 상충 — allowlist 불가 시의 대안으로만 보류 (D-5) |
| adjudicator 기본 reasoning=medium | Codex §7.2 C | 경량 판정에는 low로 충분(실증 근거 Y-4) — 유형별 차등 + 3기준 high escalation으로 절충 (D-4) |
| 게이트 통째 삭제 | — | 양 리포트 공히 불가 판정 (C-1) — 검토 대상에서 제외 |
| 모델 일괄 하향 | — | 이미 flash-lite — 효과 제한적, 호출 자체 제거가 우선 (C-9) |
@@ -0,0 +1,632 @@
# Stage 1 Part 1 효율화 통합 개정 전략
## 0. 문서 목적과 최종 결론
이 문서는 다음 두 분석서를 비교·대조하여 Stage 1 Part 1 개정에 실제로 반영할 최적 전략을 확정한다.
- `Part_1_Inefficiency_Report_Codex_v1.md`
- `Part_1_Inefficiency_Report_Claude_v1.md`
두 문서의 공통 결론은 타당하다. 현재 병목은 fan-in 자체가 아니라 **모든 part와 선행 final을 대형 LLM context에 적재하고, LLM이 final JSON 전체를 다시 작성하게 하는 구조**다. fan-in과 단일 writer 원칙은 유지하되, 병합·정렬·ID 확정·스키마·집합 검증·count·serialization은 Python으로 이전하고 법률적·의미론적 예외만 조건부 LLM에 보내야 한다.
최종 채택안은 다음과 같다.
1. 기존 `Task_B1_quality_gate_evidence_indexed`와 `Task_B2_quality_gate_event_candidates`의 **task name과 DAG 위치는 유지**하되 실행유형을 LLM에서 Python deterministic reducer로 변경한다.
2. 두 reducer는 final authority file을 무손실로 작성하고, 판단이 필요한 항목만 하나의 `B1B2_exception_pack`으로 분리한다.
3. exception이 0건이면 LLM을 호출하지 않는다. exception이 있을 때만 bounded micro-pack 단위의 `Task_B1B2_gate_llm_adjudicator_*`를 실행한다.
4. 별도 Python `Task_B1B2_gate_finalize_audit`가 precheck와 adjudication decision을 병합하여 기존 B1/B2 audit schema를 작성한다.
5. 기존 `Task_B2_SHA256_soft_gate_handoff_writer`는 **수정하지 않고 그대로 유지**한다. 이는 변경 범위와 회귀 위험을 줄이는 데 Claude안이 Codex 초안보다 우수한 부분이다.
6. `evidence_indexed.json`, `evidence_event_candidates.json`, B1/B2 audit file, `stage1_part1_soft_gate_handoff.json`의 경로와 downstream 계약은 유지한다.
7. `evidence_indexed.json`의 duplicate alias 제거는 1차 개정에서 보류한다. Python 전환 후에는 토큰 비용이 아니며, 외부 소비자 호환성 확인 없이 제거할 실익보다 위험이 크다.
8. exact `identity_signature` 중복은 Python으로 탐지하되 Stage 1에서 candidate나 source item을 파괴적으로 삭제하지 않는다. canonical group은 audit에 기록하고 semantic merge는 provenance를 보존할 수 있는 downstream 단계로 넘긴다.
## 1. 두 분석서 비교
### 1.1 공통으로 채택할 결론
| 쟁점 | Codex | Claude | 통합 판정 |
|---|---|---|---|
| fan-in 자체 | 필요 | 필요 | 유지 |
| 병목 본체 | full-context LLM read/write | 3중 증폭: full read, full rewrite, serial high reasoning | Claude의 3중 설명을 채택 |
| deterministic 검사 | Python 전환 | 7개 완전 대체, 4개 hybrid | 전면 채택 |
| LLM 역할 | semantic exception만 | 조건부 국소 판정만 | 전면 채택 |
| B1/B2 final file | 삭제 불가 | 삭제 불가 | 경로·schema 유지 |
| soft-gate handoff | 삭제 불가 | 삭제 불가 | 기존 SHA writer 유지 |
| E-019 소실 | Critical | Q-1 중대 | 즉시 hotfix 및 회귀 fixture화 |
| audit count/source refs | deterministic 생성 | SHA 소비 필드만 유지 | named schema와 실제 array count 강제 |
| 모델 최적화 | flash-lite medium, low verbosity | flash-lite low | medium 기본, 단순 relay만 low |
| 검증 방식 | conservation invariant | 30/74 fixture, fault injection, 2-run determinism | 합쳐서 채택 |
### 1.2 Codex 문서에서 반드시 채택할 내용
1. 실측 fan-in byte와 duplicate payload 분석
2. `E-019` 및 candidate 3건 소실에 대한 conservation audit
3. B2 audit의 `source_refs` shape 오류와 review count 불일치
4. B2가 full `evidence_indexed.json` 대신 finalized evidence ID set만 읽어야 한다는 제안
5. B1 mapper 접근범위 allowlist와 `source_support_manifest`에 의한 authority drift 구조적 예방
6. write 전·후 item/candidate 보존성 invariant
7. 정상 경로의 LLM 호출을 2회에서 0회로 만드는 우선순위
8. sub-task별 runtime/token/read-byte telemetry 도입
### 1.3 Claude 문서에서 반드시 채택할 내용
1. fan-in 비효율을 `LLM 입력`, `LLM 전체 재작성`, `직렬 high reasoning`의 3중 증폭으로 분리한 설명
2. 10+1개 검증항목을 deterministic과 hybrid로 분해한 표
3. final candidate의 field pass-through 위반을 독립적인 중대 결함으로 식별한 점
4. B1/B2 audit은 Part 2~4가 직접 소비하지 않고 SHA writer만 소비한다는 내부 인터페이스 분석
5. Part 3/4의 `deterministic propose -> exception adjudication -> deterministic finalize` 패턴을 Part 1에 이식하는 제안
6. GC를 별도 Python task로 두고 기존 SHA writer를 무수정 유지하는 분리
7. 현재 30-part fixture, 의도적 결함 주입, 실제 실행 재측정을 포함한 이행계획
### 1.4 수정하여 채택하거나 보류할 내용
| 제안 | 최종 처리 | 이유 |
|---|---|---|
| `items`/`evidence_indexed` duplicate alias 즉시 제거 | 보류 | v.6 내부는 `items`를 우선 소비하지만 외부 Stage 2·구버전 소비자까지 검증되지 않음 |
| exact signature candidate 자동 삭제 | 수정 채택 | exact grouping은 Python, destructive dedup은 금지. 복수 증거의 동일 사건 입증력을 보존해야 함 |
| 모든 exception을 reasoning low로 처리 | 수정 채택 | self-warning relay는 low, 법률적 chronology·authority 판정은 medium, hard provenance 판단만 high escalation |
| 기존 SHA writer에 audit finalize 책임 추가 | 미채택 | 기존 검증된 digest/handoff writer의 blast radius가 커짐. 별도 GC가 더 안전함 |
| full planner를 새 compact file로 즉시 대체 | 부분 채택 | Python reducer가 full plan을 읽는 것은 토큰 비용이 0. LLM에는 전달하지 않고 GA output에 필요한 compact fields만 남기면 충분 |
| authority drift 상시 full raw 재검사 삭제 | 조건부 채택 | mapper tool allowlist와 source support가 선행되어야 품질 저하 없이 제거 가능 |
## 2. 실증 결함을 개정의 최우선 요구사항으로 반영
### 2.1 E-019 보존성 실패
현재 fixture의 결정론적 사실은 다음과 같다.
```text
planner expected evidence IDs: 30
B2 part files: 30
input event candidates: 74
final event items: 29
final event candidates: 71
missing item: E-019
missing candidates: 3
exact duplicate signatures: 0 groups
```
따라서 개정의 첫 번째 acceptance condition은 단순 PASS 문구가 아니라 다음 machine assertion이어야 한다.
```text
set(final.items[*].evidence_index) == set(plan.expected_evidence_ids)
len(final.items) == plan.shard_count
input_candidate_count == final_candidate_count + audited_non_destructive_alias_count
```
Stage 1에서는 duplicate signature group을 표시하더라도 candidate를 삭제하지 않으므로 1차 개정의 기본식은 `input_candidate_count == final_candidate_count`다.
### 2.2 candidate field pass-through 실패
Claude 문서의 Q-2는 실질적으로 옳지만 field 수는 더 정밀하게 표현할 필요가 있다.
- mapper candidate union: 28개 key
- final candidate union: 13개 key
- `candidate_id_proposed -> candidate_id`, `source_evidence_index_proposed -> source_evidence_index` rename을 반영한 후 final 전체에서 완전히 사라진 key: 15개
- retained candidate 71건을 개별 비교하면, **non-empty 값이 있었는데 해당 candidate final에서 사라진 field name은 17종**이다.
실제 non-empty loss가 확인된 field에는 다음이 포함된다.
```text
actio_relevance_candidates
amount
commercial_successor_candidates
current_state_candidate
defense_candidate
event_subkind
fraction_ref
legal_effect_candidate
legal_keywords
location
meeting_clause_refs
object_spec
participants
succession_candidate
support_locators
time_precision
time_text
```
따라서 Python reducer는 candidate를 새 object로 요약 재구성하면 안 된다. 다음 두 key rename과 `mapper_meta` 제외 외에는 deep-copy pass-through를 원칙으로 한다.
```text
candidate_id_proposed -> candidate_id
source_evidence_index_proposed -> source_evidence_index
all other candidate keys -> exact pass-through
```
### 2.3 audit 및 handoff source ref 실패
B2 audit은 `source_refs`를 문자열 배열로 출력했지만 SHA writer는 named object를 기대했다. 이 때문에 E-010/E-011/E-012/E-028가 최종 handoff에서 소실됐다. 또한 `review_findings` 1건을 `review_gate_count=4`로 잘못 계산했다.
GC는 다음 schema를 강제하고 count를 직접 계산해야 한다.
```json
{
"source_refs": {
"evidence_indexes": [],
"event_candidate_ids": [],
"meeting_clause_refs": [],
"doc_titles": []
}
}
```
`review_gate_count`, `b1_review_count`, `b2_review_count`는 LLM 출력값을 신뢰하지 않고 최종 array를 기준으로 Python이 계산한다.
## 3. 최종 개정 아키텍처
### 3.1 설계 원칙
```text
기계적으로 판정 가능한 것: Python이 판정·작성
법률적 의미가 모호한 것: exception으로 격리
exception이 없는 정상 경로: LLM 호출 0회
exception이 있는 경로: 작은 micro-pack만 LLM 판정
LLM은 final artifact 수정권 없음
final artifact와 audit: Python single writer
```
### 3.2 개정 DAG
```text
Task_Evidence_shard_planner
|
v
Task_B1_map_doc_* --------------------------------+
| same ordinal |
v |
Task_B2_map_events_* |
| |
| all B2 parts all B1 parts
| |
| v
| Task_B1_quality_gate_evidence_indexed
| [기존 이름 유지, Python GA-1]
| - evidence_indexed.json
| - B1 precheck/review candidates
| - finalized E-ID manifest
| |
+------------------------------------------+
|
v
Task_B2_quality_gate_event_candidates
[기존 이름 유지, Python GA-2]
- evidence_event_candidates.json
- B2 precheck/review candidates
- combined exception routing manifest
|
+-----------+------------+
| exception_count = 0 | exception_count > 0
v v
empty decision artifact Task_B1B2_gate_llm_adjudicator_*
[bounded dynamic fan-out]
| |
+-----------+------------+
v
Task_B1B2_gate_finalize_audit [Python GC]
- B1 gate audit
- B2 gate audit
|
v
Task_B2_SHA256_soft_gate_handoff_writer
[기존 구현 무수정]
|
v
OUT
```
### 3.3 기존 task name 유지의 이유
- planner barrier와 `task_procedure` 변경량을 줄인다.
- 기존 로그·운영 대시보드·rerun target 이름의 연속성을 보존한다.
- Part 2~4는 task name이 아니라 file contract를 소비하므로 내부 실행유형 변경은 downstream에 비가시적이다.
- 새로 필요한 이름은 adjudicator wildcard와 GC 두 개뿐이다.
## 4. Task별 개정 명세
### 4.1 GA-1: `Task_B1_quality_gate_evidence_indexed`
실행유형:
```yaml
mcp: code-executor
language: python
```
입력:
- `evidence_shard_plan.json`
- `evidence_indexed_parts/E-*.json`
- 해당 exception에서만 `evidence_shards/E-xxx.json`
상시 입력에서 제거:
- full `evidence_all.json`
- full `client_meeting.md`
주요 처리:
1. planner status, expected ordinal, stale part, file set 검사
2. part마다 실질 item이 정확히 1개인지 검사
3. `evidence_index_proposed`, ordinal, source pointer, hash 정합 검사
4. item 전체를 deep copy하고 `evidence_index`만 deterministic finalize
5. stable ordinal sort
6. exact duplicate는 hash/doc UID/title fingerprint로 group만 작성
7. semantic flag별 component presence rule 실행
8. suspicious alias/component/authority item만 exception candidate로 생성
9. `evidence_indexed.json` 작성
10. `B1_precheck.json`과 finalized E-ID list 작성
1차 개정에서는 `items`와 legacy `evidence_indexed` alias를 모두 유지한다. 단 B2 reducer와 LLM adjudicator는 legacy alias를 읽지 않는다.
authority drift 비용을 줄이기 위한 보강:
- mapper localdocs를 assigned shard와 허용된 meeting slice로 제한
- part에 `source_support_manifest` additive field 추가
- source ordinal/hash/locator mismatch는 Python hard finding
- 의미가 불명확한 경우에만 해당 shard를 exception micro-pack에 포함
### 4.2 GA-2: `Task_B2_quality_gate_event_candidates`
실행유형:
```yaml
mcp: code-executor
language: python
```
입력:
- `evidence_shard_plan.json`
- `evidence_event_candidate_parts/E-*.json`
- `B1_precheck.json.finalized_evidence_indexes`
- `B1_precheck.json.review_candidates`
제거할 입력:
- full `evidence_indexed.json`
- final B1 audit
주요 처리:
1. part count, expected/received ID set, stale part 검사
2. `event_candidates`/`zero_event_reason` invariant 검사
3. `source_evidence_index_proposed` membership 검사
4. proposed candidate ID format·ordinal·seq uniqueness 검사
5. candidate object deep-copy 후 두 ID key만 rename
6. 모든 optional component field를 그대로 보존
7. exact signature group 탐지 및 audit candidate 생성
8. candidate나 evidence item은 삭제하지 않음
9. parseable date와 명시적 group key에 한해 chronology rule 실행
10. semantic flag/component와 REQUIRED_EVENT_SUBKINDS의 coverage rule 실행
11. ambiguous chronology/coverage만 exception 생성
12. write 전·후 conservation invariant 실행
13. `evidence_event_candidates.json`과 `B2_precheck.json` 작성
### 4.3 GB: `Task_B1B2_gate_llm_adjudicator_*`
역할은 final writer가 아니라 **분류 전용 adjudicator**다.
허용 입력:
- 하나의 exception type
- 관련 evidence 최대 2건
- 관련 candidate 최대 8건
- source excerpt 총 1,500자 이하
- deterministic precheck와 rule violation 요약
금지 입력:
- full planner
- full evidence/index/event final
- full meeting
- 전체 B1/B2 part
- 관련 없는 exception
허용 출력:
```json
{
"exception_id": "P1GEX-0001",
"decision": "PASS|REVIEW|HARD_WARNING|BLOCK",
"issue_type": "...",
"source_refs": {
"evidence_indexes": [],
"event_candidate_ids": [],
"meeting_clause_refs": [],
"doc_titles": []
},
"concise_basis": "...",
"rerun_target_task": null
}
```
금지 권한:
- final item/candidate 생성·삭제·수정
- ID 재부여
- dedup 실행
- audit count 계산
- final JSON serialization
### 4.4 GC: `Task_B1B2_gate_finalize_audit`
Python single writer로 다음을 수행한다.
1. B1/B2 deterministic precheck와 GB decision 병합
2. mechanical BLOCK을 LLM이 downgrade하지 못하도록 precedence 적용
3. source ref named schema와 membership 검증
4. `hard_gate_findings[]`, `review_findings[]`, severity, count 계산
5. `quality_gates/B1_evidence_indexed_gate.json` 작성
6. `quality_gates/B2_event_candidates_gate.json` 작성
7. SHA writer가 요구하는 기존 필드 보존
기존 SHA writer는 top-level finding과 `checks[*]` 내부 finding을 모두 수집한다. 따라서 GC는 동일 finding을 두 위치에 중복 기록하지 않는다. canonical finding은 top-level 배열에 한 번만 두고, 각 check에는 `finding_ids[]`만 참조시키거나 finding 배열을 비워 둔다. `review_items` 40건 상한을 넘는 경우에는 조용히 절단하지 않고 overflow count와 `BLOCK_REVIEW` routing을 audit에 남긴다.
기존 SHA writer는 GC가 작성한 두 audit과 두 final artifact를 읽어 digest와 soft-gate handoff를 기존 방식대로 생성한다.
## 5. 검증항목별 실행유형 확정
| 검증 | Python 처리 | LLM 처리 |
|---|---|---|
| B1 shard completeness | 전부 | 없음 |
| B1 E-ID determinism | 전부 | 없음 |
| B1 duplicate alias | exact/fuzzy 후보 추출 | 후보쌍의 실질 동일성만 |
| B1 component coverage | required field rule | 문서 의미상 required 여부가 모호할 때만 |
| B1 authority drift | access/hash/locator 위반 | 의심 source와 part의 의미 비교만 |
| B2 schema invariant | 전부 | 없음 |
| B2 event completeness | 전부 | 없음 |
| B2 evidence reference integrity | 전부 | 없음 |
| B2 candidate ID/signature | format/set/group 전부 | semantic 동일성 판단이 꼭 필요할 때만 |
| B2 chronological ordering | date parse/reversal 후보 | relation group·법적 순서가 모호할 때만 |
| B2 legal-effect coverage | flag/subkind rule | 누락인지 문서 비해당인지 모호할 때만 |
| severity/count/audit schema | 전부 | 없음 |
## 6. Exception routing decision tree
```text
GA mechanical validation
|
+-- parse/schema/provenance/set failure?
| |
| +-- YES -> deterministic BLOCK
| | exception LLM 호출 금지
| |
| +-- NO
|
+-- semantic suspect 존재?
|
+-- NO -> exception_count=0
| empty decision artifact
| GC로 직행
|
+-- YES
|
+-- 단순 mapper self-warning relay?
| -> deterministic mapping 또는 reasoning=low
|
+-- alias/component/coverage ambiguity?
| -> reasoning=medium
|
+-- authority/chronology가 BLOCK 여부 좌우?
-> reasoning=high escalation 허용
```
Batch 정책:
- exception 1~8건: exception type별 한 번의 compact 호출
- 9건 이상: type·asset/claim group별 micro-pack 분할
- micro-pack 최대 8건, 병렬 실행 `max_concurrency=4`
- 동일 exception을 여러 pack에 중복 수록 금지
- total character budget 초과 항목은 자동 truncate하지 않고 `BLOCK_REVIEW` queue로 분리
- GC는 `B1B2_exception_manifest.json`을 항상 기다리고, manifest가 선언한 generated adjudicator task 전체를 barrier로 기다린다. generated task가 0개이면 빈 decision artifact를 정상 완료로 간주한다.
정상 fixture에서는 deterministic mapper self-warning을 규칙으로 relay할 수 있으면 GB 0회, 의미 판정이 필요하면 초소형 1회가 목표다.
## 7. IO 및 writer 계약
### 7.1 내부 신규 artifact
| 파일 | Writer | Reader | 목적 |
|---|---|---|---|
| `stage1_tmp/quality_gate/B1_precheck.json` | GA-1 | GA-2, GC | E-ID list, mechanical findings, B1 review candidates |
| `stage1_tmp/quality_gate/B2_precheck.json` | GA-2 | GC | conservation result, mechanical findings, B2 review candidates |
| `stage1_tmp/quality_gate/B1B2_exception_manifest.json` | GA-2 | GB router, GC | exception count, micro-pack descriptors, zero-exception status |
| `stage1_tmp/quality_gate/B1B2_exception_decisions/*.json` | GB | GC | 국소 판정 결과 |
### 7.2 유지할 외부 artifact
| 파일 | Writer | 계약 |
|---|---|---|
| `evidence_indexed.json` | GA-1 | 기존 envelope·item schema 유지 |
| `evidence_event_candidates.json` | GA-2 | `evidence_event_candidates.v1`, 전 field pass-through |
| `quality_gates/B1_evidence_indexed_gate.json` | GC | SHA writer 소비 필드 유지 |
| `quality_gates/B2_event_candidates_gate.json` | GC | SHA writer 소비 필드 유지 |
| `quality_gates/stage1_part1_soft_gate_handoff.json` | 기존 SHA writer | schema v1, digest 4종, hard/review summary 유지 |
단일 writer 경계:
```text
GA-1 only -> evidence_indexed.json
GA-2 only -> evidence_event_candidates.json
GC only -> B1/B2 audit files
SHA only -> stage1_part1_soft_gate_handoff.json
```
## 8. 삭제·유지·보류 판정
### 8.1 즉시 삭제 또는 정상 경로에서 제거
- B1/B2 gate의 full-context LLM read
- LLM의 final JSON 전체 재작성
- LLM의 ID finalize·sort·merge·count·serialization
- B1의 full `evidence_all.json`·meeting 상시 재독해
- B2의 full `evidence_indexed.json` read
- B2의 B1 final audit read
- exact set/regex/signature 검사를 위한 LLM reasoning
- `simple concat 금지, 반드시 LLM 검증` 규칙
마지막 규칙은 다음으로 교체한다.
```text
deterministic merge는 허용하되, conservation·schema·writer-boundary gate를 모두 통과해야 한다.
semantic exception만 LLM 판정 대상으로 한다.
```
### 8.2 반드시 유지
- B1/B2 fan-in과 single writer
- 동일 ordinal B1→B2 mapper streaming
- final 두 authority file
- hard/review 분리 및 BLOCK 의미론
- mapper self-warning 승계 경로
- B1→B2 finalized E-ID 의존
- SHA256 digest와 soft-gate handoff
- rerun target routing
### 8.3 1차 개정에서 보류
- `evidence_indexed` legacy alias 제거
- planner의 duplicate `shards`/`dynamic_fanout` 구조 개편
- cross-document candidate destructive dedup
- B1/B2 reducer를 하나의 combined task로 합치기
- mapper 모델 변경
이 항목들은 Python 전환의 핵심 효과와 무관하거나 호환성 위험이 더 크다.
## 9. 모델 및 토큰 경제성 전략
현재 gate 모델은 이미 `gemini-3.1-flash-lite`이므로 더 약한 모델로 일괄 교체하는 것보다 호출을 없애는 것이 우선이다.
권장값:
```yaml
llm_provider: google
llm_model: gemini-3.1-flash-lite
llm_reasoning: medium
llm_verbosity: low
```
단순 self-warning enum mapping은 Python으로 처리한다. LLM이 필요하더라도 low reasoning 별도 profile을 사용할 수 있다. high reasoning은 provenance나 chronology의 hard-block 여부가 실제로 걸린 exception에만 허용한다.
토큰 절감 원칙:
1. common prefix는 GB에만 한 번 적용
2. final JSON을 LLM 출력으로 생성하지 않음
3. full plan/final/meeting/evidence를 GB에 전달하지 않음
4. concise basis 200자 이하
5. source excerpt total budget 1,500자
6. zero-exception이면 model spawn 자체를 생략
## 10. 구현 순서
### Phase 0: 보존성 hotfix
현행 v.6에 먼저 다음 Python post-write 검사를 추가한다.
1. final evidence/event item set equality
2. candidate count conservation
3. candidate deep field pass-through
4. dedup group과 감소 수의 일치
5. named `source_refs` schema
6. audit count와 실제 array length 일치
불일치 시 `PASS`를 금지하고 `BLOCK`한다.
### Phase 1: GA-1/GA-2 구현
1. 기존 두 gate task의 이름을 유지한 채 `code-executor`로 교체
2. final 두 파일을 deep-copy 기반으로 작성
3. precheck와 combined exception manifest 생성
4. 현행 fixture로 deterministic output 검증
### Phase 2: GB/GC 연결
1. dynamic zero-or-more adjudicator fan-out 추가
2. strict decision JSON schema 적용
3. GC single writer로 B1/B2 audit 생성
4. 기존 SHA writer 무수정 연결
### Phase 3: downstream 및 성능 검증
1. Part 2 Stage A normalization 실행
2. Part 3 LES0 input pack compiler 실행
3. Part 4 FL0 fact source pack compiler 실행
4. Part 1 wall time, model calls, tokens, read bytes 비교
5. v.6과 artifact-level semantic diff 수행
## 11. 검증 계획
### 11.1 현재 fixture 회귀시험
```text
evidence_indexed items == 30
event items == 30
event candidates == 74
E-019 retained == true
E-019 candidate count == 3
candidate non-ID fields deep-pass-through == true
review source refs E-010/E-011/E-012/E-028 retained == true
```
### 11.2 fault injection
| 주입 결함 | 기대 결과 |
|---|---|
| B1 part 1개 삭제 | deterministic BLOCK, LLM 0회 |
| stale ordinal 추가 | deterministic BLOCK, LLM 0회 |
| invalid E-ID reference | deterministic BLOCK, LLM 0회 |
| empty candidates + null reason | deterministic BLOCK, LLM 0회 |
| exact signature group | 전 candidate 보존 + audit group 기록 |
| parseable date 역전 | exception 생성 또는 명시적 deterministic violation |
| ambiguous alias pair | GB 호출, source pair만 입력 |
| malformed source_refs | GC schema failure |
| exception 0건 | GB spawn 0회, GC 직행 |
| exception budget 초과 | micro-pack 분할 또는 BLOCK_REVIEW |
### 11.3 결정론 검증
- 같은 입력으로 final 두 artifact를 2회 생성했을 때 byte-identical
- audit은 `executed_at` 제외 후 semantic-identical
- array order는 planner ordinal과 candidate seq에 의해 고정
- 모든 count는 실제 array에서 재계산
### 11.4 성능 telemetry
- task별 wall time
- input/output token
- LLM call count
- exception count 및 pack bytes
- localdocs read file count/bytes
- Python reducer duration
- cache hit
- final artifact bytes
성공 KPI:
```text
정상 gate LLM calls: 2 -> 0
exception gate input: full global context -> bounded micro-pack
final conservation errors: 0
field pass-through errors: 0
audit source/count errors: 0
Part 2~4 contract regressions: 0
```
## 12. 최종 권고
가장 적합한 개정은 Claude의 `GA-1 -> GA-2 -> GB -> GC -> SHA writer` 분리 구조를 뼈대로 사용하되, Codex 문서의 보존성·source ref·compact dependency·authority isolation 요구사항을 결합하는 것이다.
다만 변경량을 최소화하기 위해 GA-1/GA-2는 새 이름으로 추가하지 않고 기존 B1/B2 quality gate task를 Python으로 전환한다. 기존 SHA writer는 건드리지 않으며, audit finalize만 GC로 분리한다. final artifact는 Python deep-copy로 생성하고 LLM은 어떠한 수정 권한도 갖지 않는다.
시행 우선순위는 다음과 같다.
1. E-019/item/candidate/field conservation hotfix
2. B1/B2 deterministic reducer 전환
3. conditional bounded exception adjudicator
4. deterministic audit finalizer
5. 기존 SHA writer 및 downstream 계약 회귀시험
6. runtime·token A/B 측정
이 경로가 가장 적은 위험과 작업으로 최고 품질, 토큰 경제성, 실행속도를 동시에 달성한다.
@@ -0,0 +1,455 @@
# Stage 1 Part 1 개정 작업 명세서 (Part_1_Improvement_Strategy_Claude_v1)
- **개정 대상**: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml` (3,404행)
- **개정 산출물**: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v3.yml` (신규 파일 — 원본 v2는 절대 덮어쓰지 않는다)
- **전략 근거**: `YAML_Prompts/1. Stage_1/v.6/Part_1_Improvement_Claude_v1.md` (이하 **개선전략서**)
- **본 문서의 성격**: 개정 실행자(LLM)가 본 문서만 읽고 v3 YAML을 100% 작성할 수 있도록, 편집 대상 anchor·신규 task 명세·데이터 계약·검증 기준을 빠짐없이 기술한 작업 명세서다. 본 문서와 v2 원본이 충돌하면 본 문서가 우선한다. 본 문서가 침묵하는 모든 사항은 **v2 원본을 그대로 보존**한다.
---
## 0. 개정 목표와 판단 배경 (요약)
### 0.1 무엇을 바꾸는가
v2의 두 LLM quality gate(`Task_B1_quality_gate_evidence_indexed`, `Task_B2_quality_gate_event_candidates`)는 합계 약 500KB를 LLM 컨텍스트로 읽고 약 146KB의 최종 JSON을 LLM 출력 토큰으로 재작성하며, `reasoning=high`의 대형 호출 2개가 파이프라인 꼬리에서 직렬 실행된다. 2026-07-10 실측에서 이 구조는 (Q-1) E-019 항목 통째 소실, (Q-2) candidate 필드 16종 무단 탈락, (Q-3) B1 최종본 동일 배열 2중 수록, (Q-4) dedup 미기록, (X-1) audit `source_refs` shape 불일치로 handoff에서 ref 전량 소실이라는 5건의 실증 결함을 만들었다. 반면 LLM 추론이 추가로 발견한 결함은 0건이었다.
개정은 개선전략서의 확정 아키텍처를 따른다: **두 게이트를 결정적(Python code-executor) reducer로 전환**하고(GA-1, GA-2), 결정적 검사로 좁혀진 의미론적 의심 항목이 있을 때만 소형 LLM 판정(GB)을 실행하며, audit 확정은 초소형 결정적 finalizer(GC)가 수행하고, 검증된 기존 `Task_B2_SHA256_soft_gate_handoff_writer`는 **무수정**으로 연결한다.
### 0.2 변호사 관점의 불변 원칙 (법률 품질 보존)
1. **증거 보존성이 최우선이다.** 소멸청구 통지서(E-019)처럼 유치권 소멸·통지 도달 lifecycle을 좌우하는 증거가 무단 소실되면 Part 4 `_lien_extinction_notice_scan`과 Part 2 notice 도메인이 오염된다. 병합·직렬화를 기계에 맡기는 1차 목적이 바로 이 보존성이다.
2. **법률적 불확실성은 review 큐로, 기계적 실패만 BLOCK으로.** v2의 HARD/REVIEW 분류 철학(suspected alias, coverage concern, chronology ambiguity는 review-only, 자동 BLOCK 금지)을 그대로 계승한다. 결정적 코드는 severity를 임의로 상향하지 않는다.
3. **canonical 결정의 법률적 우선순위 유지.** dedup canonical 규칙 (i) raw event > derived legal-effect event (ii) higher confidence (iii) more support_locators (iv) earlier ordinal, alias canonical 규칙 (i) 작은 ordinal (ii) 더 명시적 title (iii) 더 구체적 key_dates/key_amounts는 v2에 이미 결정적으로 명문화된 법률 판단의 산물이므로 코드로 그대로 이식한다.
4. **mapper self-warning의 승격 경로 보존.** "상계 항변 등 Stage 2 검토 필요" 류의 mapper self-warning → review finding → sidecar → Part 2 승계 체인은 이번 실행에서 실제 작동한 유일한 실질 산출이며, 반드시 유지한다.
### 0.3 개선전략서 대비 본 명세서의 구체화 결정 2건 (근거 포함)
| 결정 | 개선전략서 표기 | 본 명세서 확정안 | 근거 |
|---|---|---|---|
| N-1. GA-1/GA-2의 task 이름 | `Task_B1_gate_merge_deterministic`, `Task_B2_gate_merge_deterministic` (예시 명명) | **기존 이름 유지**: `Task_B1_quality_gate_evidence_indexed`, `Task_B2_quality_gate_event_candidates` (실행 유형만 LLM → code-executor로 치환) | v2의 planner 코드(약 856~904행)는 plan JSON 내부에 두 게이트의 task 이름을 문자열로 내장하고("next": "Task_B1_quality_gate_evidence_indexed" 등), B1/B2 mapper 프롬프트(1026행, 1621행 등)도 이름을 참조한다. 이름을 유지하면 planner·mapper를 **한 글자도 수정하지 않아도 되어** 편집 표면과 회귀 위험이 최소화된다. 개선전략서의 "최소 변경·하류 무영향" 원칙이 예시 명명보다 우선한다 |
| N-2. GB 조건부 실행 방식 | "suspects 0건이면 미실행" | **정적 task + empty-pack 즉시 종료** (기본): GB는 항상 스케줄되지만 첫 동작이 exception pack 1개 파일(수백 byte)만 읽는 것이고, `exception_count==0`이면 즉시 `"NO_SUSPECTS"` 출력 후 종료한다 | v2에서 확인되는 0-instance fan-out 메커니즘(planner의 `fanout_payload=[]`)은 mapper 미생성 시 후속 barrier(`all Task_B12_*`)가 정상 resolve되는지 v2 YAML만으로 보증할 수 없다. 정적 체인은 런타임 가정이 0이며, empty-pack 조기 종료 호출의 비용은 cache prefix + 소형 입력으로 무시 가능 수준이다. 런타임에서 0-instance wildcard barrier resolve가 실증되면 후속 버전에서 dynamic fan-out으로 전환할 수 있다(§9 Phase 2) |
---
## 1. 절대 불변 계약 (개정 실행자가 위반하면 안 되는 것)
아래 항목은 Part 2/3/4 및 기존 결정적 구성요소가 소비하는 인터페이스다. **v3에서 바이트 하나도 바꾸지 않는다.**
1. **최종 산출물 경로**: `evidence_indexed.json`, `evidence_event_candidates.json`, `quality_gates/B1_evidence_indexed_gate.json`, `quality_gates/B2_event_candidates_gate.json`, `quality_gates/stage1_part1_soft_gate_handoff.json`.
2. **`evidence_event_candidates.json` envelope**: top-level object, `schema_version: "evidence_event_candidates.v1"`, `items` 배열. 각 item은 `evidence_index`, `title`, `doc_type`, `source_pointer`, 그리고 non-empty `event_candidates` 또는 non-null `zero_event_reason`.
3. **`evidence_indexed.json` envelope**: top-level object, `schema_contract_version`, `items` 배열. 각 item은 v.2 item schema(`evidence_index`, `doc_uid`, `title`, `title_normalized`, `doc_type`, `key_*`, `source_pointer`, optional component fields). ※ `evidence_indexed` alias 배열의 처리만 §3 STEP 0-3의 조건부 결정을 따른다.
4. **`Task_B2_SHA256_soft_gate_handoff_writer`**: task 정의 전체(v2 2950~3363행)를 **무수정** 복사한다. 이 task의 `INPUT_PATHS` 4개 경로, sidecar 스키마, digest 로직, review item 변환 로직은 이번 실행에서 유일하게 무결함으로 작동한 구성요소다.
5. **audit 파일이 SHA writer에 제공해야 하는 필드** (writer 코드가 실제로 읽는 필드 — v2 3183~3310행에서 실증):
- top-level 및 `checks[]` 내부의 `hard_gate_findings[]`, `review_findings[]`
- `overall_severity`, `downstream_progression`, `stage2_auto_progression_allowed`, `block_reasons[]`
- 각 review finding의 `issue_type`(또는 `check_id`/`source_check`), `severity`, `domain_hints`, `target_stage_hints`, `target_task_hints`, `review_instruction`, `candidate_use_policy`(허용값: `prioritize_if_supported` | `preserve_as_needs_review` | `do_not_generate_without_support`), `concise_basis`, `gate_finding_id`, `lawyer_workflow_role`
- **`source_refs`는 반드시 named object** `{"evidence_indexes": [], "event_candidate_ids": [], "meeting_clause_refs": [], "doc_titles": []}` — writer의 `source_refs()` 함수는 dict가 아니면 nested ref를 전부 무시한다(7/10 실행의 X-1 결함이 정확히 이 지점에서 발생). 배열형 `source_refs` 생성은 스키마 위반으로 금지한다.
- review finding은 writer가 40개에서 절단하므로 GC도 최대 40개로 제한한다.
6. **task 이름**: `Task_A_client_goal`, `Task_Evidence_shard_planner`, `Task_B1_map_doc_*`, `Task_B2_map_events_*`, `Task_B1_quality_gate_evidence_indexed`, `Task_B2_quality_gate_event_candidates`, `Task_B2_SHA256_soft_gate_handoff_writer` 전부 유지.
7. **수정 금지 task**: `Task_A_client_goal`, `Task_Evidence_shard_planner`, `Task_B1_map_doc_*`, `Task_B2_map_events_*`, `Task_B2_SHA256_soft_gate_handoff_writer` — 이 5개 task 정의는 v2에서 v3로 **그대로 복사**한다.
8. **동일 ordinal streaming**: `Task_B2_map_events_*`의 `wait_until: ["Task_B1_map_doc_{same_ordinal}"]` 구조 유지.
9. **상태 메시지 문자열**: `"B1 quality gate BLOCK 발생: downstream 진행 금지"`, `"B2 quality gate BLOCK 발생: downstream 진행 금지"`, `"증거문서 authority catalog finalize 완료 (severity=<overall_severity>)"`, `"증거문서 사건행위 후보 finalize 완료 (severity=<overall_severity>)"` — GA-1/GA-2의 stdout이 동일 문자열을 출력한다(orchestrator 호환).
---
## 2. 개정 범위 총괄표
| # | v2 task (행 범위) | v3 처분 | 실행 유형 변화 |
|---|---|---|---|
| 1 | `Task_A_client_goal` (25~620) | 무수정 복사 | LLM 유지 |
| 2 | `Task_Evidence_shard_planner` (622~945) | 무수정 복사 | code-executor 유지 |
| 3 | `Task_B1_map_doc_*` (946~1539) | 무수정 복사 | LLM 유지 |
| 4 | `Task_B2_map_events_*` (1540~2204) | 무수정 복사 | LLM 유지 |
| 5 | `Task_B1_quality_gate_evidence_indexed` (2205~2546) | **전면 치환** → GA-1 결정적 reducer (§4) | LLM → **code-executor** |
| 6 | `Task_B2_quality_gate_event_candidates` (2547~2949) | **전면 치환** → GA-2 결정적 reducer (§5) | LLM → **code-executor** |
| 7 | `Task_B12_gate_llm_adjudicator` | **신설** → GB 조건부 국소 판정 (§6) | LLM (flash-lite, low) |
| 8 | `Task_B12_gate_audit_finalizer` | **신설** → GC audit 확정 (§7) | code-executor |
| 9 | `Task_B2_SHA256_soft_gate_handoff_writer` (2950~3363) | 무수정 복사 | code-executor 유지 |
| 10 | `task_procedure` (3364~3404) | **부분 개정** (§8) | — |
행 번호는 v2 원본 기준의 위치 참조이며, anchor는 `- task_name:` 라인이다. 치환 범위는 해당 `- task_name:` 라인부터 다음 `- task_name:` 라인 직전까지다.
---
## 3. STEP 0 — 사전 확인 (v3 작성 전 필수)
1. **STEP 0-1**: `Stage_1_Part_1_v2.yml`을 읽고 §2 총괄표의 8개 task anchor와 `task_procedure` anchor가 모두 존재함을 확인한다. 하나라도 없으면 작업을 중단하고 보고한다.
2. **STEP 0-2**: 결과 fixture `v.6/Results_July_10_3_15pm/`에 `evidence_shard_plan.json`, `evidence_indexed_parts/`(30개), `evidence_event_candidate_parts/`(30개)가 존재함을 확인한다(§10 검증에 사용).
3. **STEP 0-3 (alias 제거 확정)**: v.6 폴더의 `Stage_1_Part_2_v2.yml`, `Stage_1_Part_3_v1.yml`, `Stage_1_Part_4_v2.yml` 및 접근 가능한 Stage 2 명세 전체에서 정규식 `evidence_indexed"?\s*[\]\[:]`로 **`items`가 아닌 `evidence_indexed` 키를 파싱하는 소비자**를 검색한다.
- 소비자 0건(기대값): `evidence_indexed.json`은 v3에서 `schema_contract_version: "evidence_indexed.v3"` + **`items` 단일 배열**로 확정한다(중복 alias 제거 — Q-3 해소).
- 소비자 1건 이상: alias를 유지하되(`items`와 동일 배열 참조로 Python이 생성 — LLM 토큰 비용 0) 발견 지점을 개정 보고서에 기록한다.
---
## 4. STEP 1 — `Task_B1_quality_gate_evidence_indexed` 치환 명세 (GA-1)
v2 2205~2546행 블록 전체를 삭제하고 아래 명세의 code-executor task로 대체한다.
### 4.1 task 엔트리 골격
```yaml
- task_name: Task_B1_quality_gate_evidence_indexed
mcp: code-executor
tool_name: run_code
parameters:
language: python
requirements: "httpx"
network: "agent-network"
timeout: 240
code: |
# §4.3의 기능 명세를 구현한 Python 스크립트
```
- `preflight_files`, `llm_provider/llm_model/llm_reasoning/llm_verbosity`, `cache_control`, `use_tools`, `prompts` 필드는 **모두 제거**한다(code-executor task는 v2의 `Task_Evidence_shard_planner`/`Task_B2_SHA256_soft_gate_handoff_writer` 엔트리 형식을 따른다).
### 4.2 MCP 보일러플레이트 (강제)
Python 코드의 MCP 통신부는 v2 `Task_B2_SHA256_soft_gate_handoff_writer`(2959~3131행)의 다음 요소를 **그대로 복사**한다: `LOCALDOCS_URL`, `MCP_HEADERS`, `CLIENT`, `MSG_ID`, `_mid`, `_init`, `_parse`, `_call`, `_unwrap`, `read_raw`, `parse_json`, `write_doc`, `as_list`, `as_str_list`, `clip`. `_init`의 `clientInfo.name`만 `"task-b1-quality-gate-evidence-indexed"`로 바꾸고 `user_id: "{{__user_hash__}}"`, `workspace_id: "{{__workspace_hash__}}"` placeholder는 유지한다. 파일 목록 조회는 planner(726행)와 동일하게 `list_docs`를 `_call`로 호출한다.
### 4.3 기능 명세 (main 로직 — 순서 강제)
**입력** (read_docs): ① `evidence_shard_plan.json` ② `evidence_indexed_parts/E-*.json` 전체(plan의 `expected_ordinals` 기준으로 경로 구성). **v2가 읽던 `evidence_all.json` 전문과 `client_meeting.md` 전문은 읽지 않는다** — 단, §4.4 R-DRIFT 의심 신호가 발생한 ordinal에 한해 해당 shard 원문(`evidence_shards/E-{ordinal}.json` — plan의 `shards[*].shard_doc_path` 값 사용) 1건만 추가로 읽어 발췌를 exception pack에 첨부한다.
1. **입력 고정**: plan에서 `expected_ordinals`, `expected_evidence_ids`, `shard_count`, `barriers.B1_all_parts_barrier.require_files`, `stale_part_policy.detected_stale_parts`를 파싱한다.
2. **completeness (v2 CHECK_1의 결정적 이식)**: `detected_stale_parts` 비어있지 않음 → BLOCK. expected와 received ordinal의 set 차이 존재(누락 또는 초과) → BLOCK. 각 part 파싱 실패·빈 파일 → BLOCK.
3. **index determinism (CHECK_2)**: 각 part의 `evidence_index_proposed`가 정규식 `^E-\d{3}$`이고 자기 ordinal과 일치하지 않으면 → BLOCK.
4. **exact duplicate alias (CHECK_3의 결정적 부분)**: `doc_uid` 완전 일치 또는 `title_normalized` 완전 일치 그룹을 추출한다. 확정 중복은 canonical 규칙(§0.2-3)으로 1개만 남기고 `dropped_aliases`에 ordinal·사유를 기록한다. **유사(비완전일치) 의심쌍**(공백·조사 제거 후 일치, 또는 `key_dates`+`key_amounts`+`key_parties` 3종 동시 일치인데 title 상이)은 삭제하지 않고 suspect로 등록한다(§4.4 R-ALIAS).
5. **component coverage (CHECK_4의 결정적 이식)**: v2 CHECK_4의 10개 규칙을 `doc_type(또는 semantic flag) → 필수 non-empty 필드` rule table로 코드화한다(예: `registry_doc`이고 `registry_row_components` empty → coverage suspect). 규칙 위반은 suspect로 등록한다(§4.4 R-COVERAGE) — 결정적 코드가 severity를 직접 확정하지 않고 GB가 판정한다(원문에 실제로 해당 component가 "보이는지"는 의미론적 판단이기 때문).
6. **authority drift (CHECK_5의 강등)**: 상시 전역 검사를 삭제한다. §4.4 R-DRIFT 신호 발생 시에만 suspect 등록 + 해당 shard 발췌 첨부.
7. **finalize & merge**: ordinal 오름차순 stable sort → `evidence_index = evidence_index_proposed`(검증 통과 시) 확정 → item dict를 **그대로 복사**(전 필드 pass-through)하되 `evidence_index_proposed` 키를 `evidence_index`로 교체하고 `mapper_meta`는 item에서 제외(v2 CONSOLIDATION_RULES 계승, mapper_meta는 precheck에 기록).
8. **envelope 작성**: §3 STEP 0-3 결정에 따라 `{"schema_contract_version": "evidence_indexed.v3", "items": [...]}` (+조건부 alias). `json.dumps(ensure_ascii=False, indent=2)`로 직렬화하여 `evidence_indexed.json` 저장.
9. **write 전·후 보존성 검사**: `len(items) == shard_count`, `set(evidence_index) == set(expected_evidence_ids) - dropped_aliases의 제거분`, 모든 part가 items 또는 `dropped_aliases`에 정확히 1회 대응. 위반 시 파일을 쓰지 않고 BLOCK.
10. **mapper self-warning 승계**: 각 part의 self-warning/review 필드(`mapper_meta` 내 warning 포함)를 전량 `review_candidates[]`로 수집한다(승격 판정은 GB).
11. **중간 산출물 저장**: `stage1_tmp/quality_gate/finalized_evidence_id_manifest.json`(§4.5-A), `stage1_tmp/quality_gate/B1_precheck.json`(§4.5-B).
12. **stdout**: BLOCK 발생 시 `"B1 quality gate BLOCK 발생: downstream 진행 금지"` + status JSON, 정상 시 `"증거문서 authority catalog finalize 완료 (severity=<overall_severity>)"` + status JSON. 여기서 overall_severity는 precheck 기준 잠정값(BLOCK 또는 PASS — review성 판정은 GB/GC 확정 전이므로 suspect 존재 시 `PENDING_ADJUDICATION`을 status JSON에 병기).
13. **FAILURE_POLICY 계승**: 입력 파일 누락·파싱 불가·stale 감지 시 final 파일을 쓰지 않고 오류 보고 후 종료. tool 오류는 1회 재시도.
### 4.4 의심 신호 규칙 (suspect rules — GA-1)
| ID | 신호 | pack 첨부물 |
|---|---|---|
| R-ALIAS | doc_uid/title 비완전일치 유사쌍 (§4.3-4) | 두 item의 `title`, `title_normalized`, `key_dates`, `key_amounts`, `key_parties`만 |
| R-COVERAGE | doc_type rule table 위반 (§4.3-5) | 해당 item의 `doc_type`, 비어 있는 component 필드명, item의 key_* 필드 |
| R-DRIFT | (a) part의 key_dates·key_amounts가 모두 empty인데 doc_type이 `registry_doc`/`claim_doc`/`notice_doc` 계열, (b) `source_pointer`의 ordinal 표기와 자기 ordinal 불일치, (c) mapper self-warning에 drift/출처 관련 문구 존재 | 해당 shard 원문 발췌 ≤1,500자 + part의 관련 필드 |
### 4.5 중간 산출물 스키마
**A. `stage1_tmp/quality_gate/finalized_evidence_id_manifest.json`**
```json
{
"schema_version": "finalized_evidence_id_manifest.v1",
"source_task": "Task_B1_quality_gate_evidence_indexed",
"shard_count": 30,
"finalized_evidence_indexes": ["E-001", "E-002", "..."],
"dropped_aliases": []
}
```
**B. `stage1_tmp/quality_gate/B1_precheck.json`**
```json
{
"schema_version": "B1_precheck.v1",
"deterministic_checks": [
{"check_id": "shard_completeness", "severity": "PASS|BLOCK", "detail": "", "missing_ordinals": []},
{"check_id": "evidence_index_determinism", "severity": "PASS|BLOCK", "detail": "", "violations": []},
{"check_id": "duplicate_document_alias", "severity": "PASS|BLOCK", "detail": "", "duplicate_groups": [], "canonical_choices": []},
{"check_id": "document_component_coverage", "severity": "PASS", "detail": "", "missing_components": []},
{"check_id": "authority_drift_detection", "severity": "PASS", "detail": "", "drift_findings": []}
],
"hard_gate_findings": [],
"review_candidates": [],
"suspects": [],
"dropped_aliases": [],
"conservation": {"input_parts": 30, "final_items": 30, "dropped": 0},
"block": false
}
```
- `deterministic_checks[*].check_id`는 v2 B1 audit의 5개 check_id 문자열과 **완전히 동일**해야 한다(GC가 그대로 audit `checks[]`로 옮긴다). coverage/drift check는 결정적 단계에서 severity를 `PASS`로 두고 suspect만 등록한다 — 최종 severity는 GB 판정 후 GC가 기입한다.
- `suspects[*]`: `{"exception_id": "B1-SUS-001", "rule_id": "R-ALIAS|R-COVERAGE|R-DRIFT", "check_id": "<대응 check_id>", "ordinals": [], "payload": {...}, "excerpt": "≤1500자", "escalation_flag": false}`.
---
## 5. STEP 2 — `Task_B2_quality_gate_event_candidates` 치환 명세 (GA-2)
v2 2547~2949행 블록 전체를 삭제하고 code-executor task로 대체한다. 엔트리 골격·보일러플레이트는 §4.1~4.2와 동일하다(`clientInfo.name`: `"task-b2-quality-gate-event-candidates"`, timeout 240).
### 5.1 기능 명세 (순서 강제)
**입력** (read_docs): ① `evidence_shard_plan.json` ② `evidence_event_candidate_parts/E-*.json` 전체 ③ `stage1_tmp/quality_gate/finalized_evidence_id_manifest.json` ④ `stage1_tmp/quality_gate/B1_precheck.json`(suspects 병합용). **v2가 읽던 `evidence_indexed.json` 전문(91.8KB)과 `quality_gates/B1_evidence_indexed_gate.json`은 읽지 않는다** — 참조 무결성은 manifest의 E-ID 집합(~0.5KB)으로, B1 review 승계는 GC가 B1_precheck로 수행한다.
1. **입력 고정**: plan에서 `expected_ordinals`, `expected_evidence_ids`, `shard_count`, `barriers.B2_all_parts_barrier.require_files`, `stale_part_policy` 파싱. manifest에서 `finalized_evidence_indexes`를 set으로 고정.
2. **schema invariant gate (v2 PART_ITEM_SCHEMA_INVARIANT_GATE의 완전 이식 — 6개 invariant 전부)**: 각 part는 실질 item 정확히 1개 / `evidence_index_proposed`(또는 `evidence_index`)가 expected ID 및 manifest와 일치 / non-empty `event_candidates` XOR non-null `zero_event_reason` 규칙(`[]`+null 결합 → BLOCK) / candidate는 `candidate_id_proposed`·`source_evidence_index_proposed`·`identity_signature` 보유. 위반마다 `schema_invariant_findings[]`에 `{ordinal, part_path, reason, severity: "BLOCK", rerun_target_task: "Task_B2_map_events_{ordinal}"}` 기록(v2 2880행 형식 그대로).
3. **completeness (CHECK_1)**: stale/누락/초과 ordinal → BLOCK.
4. **reference integrity (CHECK_2)**: 각 candidate의 `source_evidence_index_proposed` ∉ `finalized_evidence_indexes` → BLOCK.
5. **candidate ID (CHECK_3 결정적 부분)**: `candidate_id_proposed` 정규식 `^EVT-\d{3}-\d{2}$` + ordinal 일치 + 같은 ordinal 내 seq 유일성 → 위반 시 BLOCK. cross-document `identity_signature` **완전 일치** 그룹은 canonical 규칙(§0.2-3)으로 dedup하고 **`dedup_findings[]`에 의무 기록**(Q-4 해소). dropped candidate의 원본 필드는 `dedup_findings[*].dropped_candidate`에 보존한다(증거 보존성).
6. **chronology (CHECK_4의 결정적 부분)**: v2 CHECK_4에 명문화된 4개 chain 순서 규칙(underlying_claim_arising < first_demand < demand_notice_dispatch <= demand_notice_arrival < debt_acknowledgement / lien chain / 경매 chain / 사해행위 chain)을 rule table로 코드화한다. **양쪽 날짜가 모두 ISO-parse 가능한 경우에만** 역전을 검사하고, 역전 발견 → suspect(R-CHRONO, `escalation_flag: true`). 날짜 null·불완전은 suspect(R-CHRONO, escalation_flag false). 코드가 직접 BLOCK하지 않는다(시간 모순의 법적 중대성 판정은 GB).
7. **coverage (CHECK_5)**: v2 CHECK_5의 REQUIRED_EVENT_SUBKINDS 9개 규칙을 `트리거 신호(doc_type/기존 candidate subkind 존재) → 기대 subkind set` rule table로 코드화 → 위반은 suspect(R-EVTCOV).
8. **finalize & merge**: ordinal 오름차순 정렬 → `candidate_id = candidate_id_proposed`, `source_evidence_index = source_evidence_index_proposed` 확정(키 교체) → **candidate dict 전 필드 그대로 복사**(Q-2 구조적 해소 — 어떤 필드도 선별·요약하지 않는다) → item 레벨도 전 필드 복사, `mapper_meta`만 제외.
9. **envelope 작성**: `{"schema_version": "evidence_event_candidates.v1", "items": [...]}` 저장.
10. **보존성 invariant (write 전·후 각 1회 — 위반 시 파일 미작성 + BLOCK)**:
```text
set(items[*].evidence_index) == set(expected_evidence_ids)
len(items) == shard_count
sum(part candidate 수) == sum(final candidate 수) + len(dedup_findings)
dedup_findings가 비어 있는데 candidate 수 감소 → BLOCK
candidate별 필드 수: final == input (키 교체 2건 외 증감 0)
모든 part는 items 또는 schema_invariant_findings에 정확히 1회 대응
```
11. **exception pack 통합**: B1_precheck의 `suspects[]` + `review_candidates[]`와 GA-2 자체 suspects를 병합하여 `stage1_tmp/quality_gate/B12_exception_pack.json`(§5.2) 저장. **micro-pack 상한 강제**: 항목당 evidence item ≤2, candidate ≤8, 발췌 ≤1,500자, exception type 1종. 상한 초과분은 절단하지 않고 `overflow_items[]`로 이월 기록한다(silent cap 금지).
12. **중간 산출물**: `stage1_tmp/quality_gate/B2_precheck.json`(§4.5-B와 동형, check_id는 v2 B2 audit의 5개 + `schema_invariant_findings` 배열, `dedup_findings[]` 포함).
13. **stdout**: §1-9의 B2 메시지 문자열 + status JSON(`exception_count` 포함).
### 5.2 `stage1_tmp/quality_gate/B12_exception_pack.json` 스키마
```json
{
"schema_version": "B12_exception_pack.v1",
"exception_count": 0,
"exceptions": [
{
"exception_id": "B1-SUS-001 | B2-SUS-001 | B1-RC-001(review_candidate)",
"source_gate": "B1|B2",
"rule_id": "R-ALIAS|R-COVERAGE|R-DRIFT|R-CHRONO|R-EVTCOV|R-SELFWARN",
"check_id": "<v2 audit check_id 대응값>",
"ordinals": ["019"],
"evidence_indexes": ["E-019"],
"candidate_ids": [],
"payload": {},
"excerpt": "≤1500자",
"escalation_flag": false
}
],
"overflow_items": [],
"budget": {"max_items_per_exception": 2, "max_candidates": 8, "max_excerpt_chars": 1500}
}
```
`exception_count == len(exceptions)`를 코드로 강제한다. mapper self-warning은 rule_id `R-SELFWARN`으로 전량 포함한다(이번 7/10 실행 기준이라면 pack에는 R-SELFWARN 1건만 존재했을 것).
---
## 6. STEP 3 — `Task_B12_gate_llm_adjudicator` 신설 명세 (GB)
`Task_B2_quality_gate_event_candidates` 엔트리 뒤, `Task_B12_gate_audit_finalizer` 앞에 신설한다.
### 6.1 task 엔트리 골격
```yaml
- task_name: Task_B12_gate_llm_adjudicator
preflight_files:
- stage1_tmp/quality_gate/B12_exception_pack.json
llm_provider: google
llm_model: gemini-3.1-flash-lite
llm_reasoning: low
llm_verbosity: low
cache_control:
mode: auto
ttl: 20m
use_tools:
- localdocs
prompts:
- role: user
content: |-
<COMMON_CACHE_PREFIX_STAGE_1> ... </COMMON_CACHE_PREFIX_STAGE_1>
<ROLE_PREFIX_STAGE_1_VALIDATION_GATE> ... </ROLE_PREFIX_STAGE_1_VALIDATION_GATE>
<STATIC_BLOCK_TASK_B12_GATE_LLM_ADJUDICATOR> ... </STATIC_BLOCK_TASK_B12_GATE_LLM_ADJUDICATOR>
<DYNAMIC_TAIL_TASK_B12_GATE_LLM_ADJUDICATOR> ... </DYNAMIC_TAIL_TASK_B12_GATE_LLM_ADJUDICATOR>
```
- `<COMMON_CACHE_PREFIX_STAGE_1>`과 `<ROLE_PREFIX_STAGE_1_VALIDATION_GATE>`는 v2 2223~2275행의 원문을 **바이트 동일하게 복사**한다(캐시 적중 유지). 기존 task들의 해당 블록은 수정하지 않는다.
- `llm_reasoning: low` 확정 근거: 실증상 판정 대상의 대부분이 self-warning 승격 분류이고(7/10 실행 기준 발견 0건), 고난도 케이스는 아래 ESCALATE 경로로 인간 검토에 회부한다. 런타임이 호출별 reasoning 변경을 지원하지 않으므로 high 상시 적용은 금지한다.
### 6.2 STATIC_BLOCK 필수 내용 (프롬프트 작성 지시)
1. **MISSION**: "B1/B2 결정적 reducer가 추출한 의심 항목만 국소 판정하는 예외 심판기다. 최종 파일을 쓰지 않고, 병합하지 않고, 새 사실을 창작하지 않는다. 판정 결과는 `stage1_tmp/quality_gate/B12_adjudication_decisions.json`에만 쓴다."
2. **EXECUTION_SEQUENCE**:
- ① `read_docs`로 `stage1_tmp/quality_gate/B12_exception_pack.json` **1개 파일만** 읽는다.
- ② `exception_count == 0`이면: `write_file`로 `{"schema_version":"B12_adjudication_decisions.v1","decisions":[],"no_suspects":true}`를 저장하고 `"NO_SUSPECTS"`만 출력 후 즉시 종료한다. 다른 어떤 파일도 읽지 않는다.
- ③ `exception_count > 0`이면: 각 exception을 pack에 포함된 payload·excerpt **만으로** 판정한다. 추가 read_docs 금지(발췌는 GA가 이미 pack에 내장).
- ④ 판정 decision enum: `DISMISS`(문제 없음) | `SOFT_WARNING_REVIEW` | `HARD_WARNING_REVIEW` | `CONFIRM_BLOCK`(provenance 오염·source trace 상실·final identity collision 등 v2 hard gate 승격 요건 충족 시에만) | `ESCALATE_TO_REVIEW`(`escalation_flag: true`이고 pack 정보만으로 확정 불가 — 날짜·당사자·목적물의 실질 충돌, drift가 source trace 유효성을 좌우, chronology가 block 여부를 좌우하는 경우).
- ⑤ `write_file`로 decisions 파일 저장, 건수 요약만 출력 후 종료.
3. **출력 item 스키마** (필드 고정, 자유 서술 금지):
```json
{
"exception_id": "<pack의 exception_id 그대로>",
"decision": "DISMISS|SOFT_WARNING_REVIEW|HARD_WARNING_REVIEW|CONFIRM_BLOCK|ESCALATE_TO_REVIEW",
"severity": "PASS|SOFT_WARNING|HARD_WARNING|BLOCK",
"issue_type": "<pack rule_id 기반 snake_case>",
"source_refs": {"evidence_indexes": [], "event_candidate_ids": [], "meeting_clause_refs": [], "doc_titles": []},
"concise_basis": "≤120자 한국어",
"candidate_use_policy": "prioritize_if_supported|preserve_as_needs_review|do_not_generate_without_support"
}
```
4. **ABSOLUTE_FORBIDDEN**: final 파일(`evidence_indexed.json`, `evidence_event_candidates.json`) 및 `quality_gates/*` 작성·재작성 / pack 외 파일 read / mapper part 수정 / 새 candidate·사실 창작 / `source_refs`를 배열로 출력(반드시 named object) / decision 없는 exception 방치(모든 exception_id에 정확히 1개 decision).
5. **판정 법률 기준**(STATIC_BLOCK에 포함): v2 HARD_REVIEW_GATE_CLASSIFICATION(2337~2343행, 2685~2690행)의 분류 원칙을 요약 이식한다 — "법률적 불확실성은 review, 기계적/출처/무결성 실패만 BLOCK. review는 사실 확정이 아니다."
---
## 7. STEP 4 — `Task_B12_gate_audit_finalizer` 신설 명세 (GC)
GB 뒤, SHA writer 앞에 신설한다. code-executor task(골격 §4.1, `clientInfo.name`: `"task-b12-gate-audit-finalizer"`, timeout 120).
### 7.1 기능 명세
**입력**: `stage1_tmp/quality_gate/B1_precheck.json`, `stage1_tmp/quality_gate/B2_precheck.json`, `stage1_tmp/quality_gate/B12_adjudication_decisions.json`, `stage1_tmp/quality_gate/B12_exception_pack.json`.
**출력**: `quality_gates/B1_evidence_indexed_gate.json`, `quality_gates/B2_event_candidates_gate.json`.
1. **checks[] 재구성**: precheck의 `deterministic_checks`를 audit `checks[]`로 옮기되, GB 판정이 있는 check는 severity를 갱신한다: 해당 check_id에 매핑된 decisions 중 최고 severity(BLOCK > HARD_WARNING > SOFT_WARNING > PASS, `DISMISS`→PASS, `ESCALATE_TO_REVIEW`→HARD_WARNING review). 각 check의 detail 배열 필드(`missing_ordinals`, `violations`, `duplicate_groups`, `canonical_choices`, `missing_components`, `drift_findings`, `format_violations`, `dedup_findings`, `ordering_violations`, `missing_subkinds_by_ordinal`)는 precheck·decisions에서 결정적으로 채운다.
2. **audit 스키마**: v2의 AUDIT_REPORT_SCHEMA(B1: 2419~2480행, B2: 2811~2876행)의 **모든 키를 동일하게** 생성한다. `gate_id`, `executed_at`(UTC ISO-8601, 코드 생성), `input_parts_count`, `expected_ordinals`, `planner_source`, `planner_shard_count`, `received_ordinals`, `checks`, `overall_severity`, `block_reasons`, `warning_reasons`, `hard_gate_findings`, `review_findings`, `rerun_targets`, `stage2_risk_notes`, `review_gate_summary`, `handoff_export_summary`, `downstream_progression`, `stage2_auto_progression_allowed`, B1의 `dropped_aliases`, B2의 `schema_invariant_findings`·`dedup_findings`, `schema_contract_version`(`"B1_quality_gate.v3"`/`"B2_quality_gate.v3"`).
3. **결정적 집계 규칙 (자유 생성 절대 금지)**:
- `hard_gate_findings[]` = precheck BLOCK findings + `CONFIRM_BLOCK` decisions. 각 항목에 `gate_finding_id`(`B1-HARD-001` 형식) 부여.
- `review_findings[]` = `SOFT_WARNING_REVIEW`/`HARD_WARNING_REVIEW`/`ESCALATE_TO_REVIEW` decisions + (GB no_suspects 시) 빈 배열. 각 finding은 §1-5의 SHA writer 소비 필드를 모두 포함하며 `source_refs`는 named object 그대로 전달. 최대 40개.
- `review_gate_summary.review_gate_count` = `len(review_findings)` (**다른 계산 금지** — X-1 오계수 재발 차단). `b1_review_count`/`b2_review_count`는 source_gate별 len.
- `overall_severity` = checks·hard_gate_findings의 최고 severity. `overall_severity=="BLOCK"` ⇔ `hard_gate_findings`(B2는 +`schema_invariant_findings`) 1개 이상.
- `downstream_progression`/`stage2_auto_progression_allowed`: v2 추가 제약(2482~2494행, 2878~2889행)의 대응 규칙을 코드로 그대로 구현.
- `handoff_export_summary`: `is_soft_handoff_writer: false`, `handoff_writer_task: "Task_B2_SHA256_soft_gate_handoff_writer"`, `handoff_path: "quality_gates/stage1_part1_soft_gate_handoff.json"`, `exported_review_count: len(review_findings)`, `handoff_status_candidate`: BLOCKED/READY_WITH_REVIEW/READY_NO_REVIEW (v2 2707~2708행 규칙).
- `block_reasons`/`warning_reasons`: findings의 한국어 mirror (clip 120자).
- `stage2_risk_notes[]`: review_findings의 `concise_basis`만 복사(자유 서술 신설 금지).
4. **stdout**: `{"status": "GATE_AUDITS_FINALIZED", "b1_overall": "...", "b2_overall": "...", "review_count": N, "hard_count": N}` + BLOCK 존재 시 해당 게이트의 §1-9 BLOCK 메시지 문자열 재출력.
---
## 8. STEP 5 — `task_procedure` 개정
v2 3364~3404행을 아래로 교체한다. **변경은 굵게 표시한 3개 노드의 edge뿐이며 나머지는 v2 그대로다.**
```yaml
task_procedure:
IN:
nexts: ["Task_A_client_goal", "Task_Evidence_shard_planner"]
wait_until: []
Task_A_client_goal:
nexts: []
wait_until: ["IN"]
Task_Evidence_shard_planner:
nexts: ["Task_B1_map_doc_*"]
wait_until: ["IN"]
Task_B1_map_doc_*:
nexts:
- "Task_B2_map_events_{same_ordinal}"
- "Task_B1_quality_gate_evidence_indexed"
wait_until: ["Task_Evidence_shard_planner"]
Task_B2_map_events_*:
nexts: ["Task_B2_quality_gate_event_candidates"]
wait_until: ["Task_B1_map_doc_{same_ordinal}"]
Task_B1_quality_gate_evidence_indexed:
nexts: ["Task_B2_quality_gate_event_candidates"]
wait_until: ["all Task_B1_map_doc_*"]
Task_B2_quality_gate_event_candidates:
nexts: ["Task_B12_gate_llm_adjudicator"]
wait_until: ["all Task_B2_map_events_*", "Task_B1_quality_gate_evidence_indexed"]
Task_B12_gate_llm_adjudicator:
nexts: ["Task_B12_gate_audit_finalizer"]
wait_until: ["Task_B2_quality_gate_event_candidates"]
Task_B12_gate_audit_finalizer:
nexts: ["Task_B2_SHA256_soft_gate_handoff_writer"]
wait_until: ["Task_B12_gate_llm_adjudicator"]
Task_B2_SHA256_soft_gate_handoff_writer:
nexts: ["OUT"]
wait_until: ["Task_B12_gate_audit_finalizer"]
OUT:
nexts: []
wait_until: ["Task_B2_SHA256_soft_gate_handoff_writer"]
prevs: []
nexts: []
```
주의: SHA writer는 이제 audit 2종이 GC에 의해 확정된 **후** 실행되므로 `wait_until`이 `Task_B12_gate_audit_finalizer`로 바뀐다. SHA writer의 task 정의 자체(INPUT_PATHS 포함)는 무수정이다 — 읽는 파일 4종의 경로가 동일하기 때문이다.
---
## 9. 단일 writer 책임표 및 BLOCK 전파 (v3 확정)
| 파일 | 단일 writer |
|---|---|
| `evidence_indexed.json` | GA-1 (`Task_B1_quality_gate_evidence_indexed`) |
| `evidence_event_candidates.json` | GA-2 (`Task_B2_quality_gate_event_candidates`) |
| `stage1_tmp/quality_gate/finalized_evidence_id_manifest.json`, `B1_precheck.json` | GA-1 |
| `stage1_tmp/quality_gate/B2_precheck.json`, `B12_exception_pack.json` | GA-2 |
| `stage1_tmp/quality_gate/B12_adjudication_decisions.json` | GB |
| `quality_gates/B1_evidence_indexed_gate.json`, `B2_event_candidates_gate.json` | GC |
| `quality_gates/stage1_part1_soft_gate_handoff.json` | SHA writer (기존, 무수정) |
BLOCK 전파: GA 단계의 기계적 BLOCK(stale/누락/파싱/형식/참조/보존성 위반)은 precheck에 기록되고 GB를 거치지 않고 GC가 BLOCK audit을 확정 → SHA writer가 `handoff_status: "BLOCKED"` sidecar 생성 → Part 2 Stage A가 차단. GB의 `CONFIRM_BLOCK`도 동일 경로다. v2와 마찬가지로 check-level BLOCK 시에도 final 파일은 작성하되(입력 자체 결손·보존성 위반 시에만 미작성) stdout에 BLOCK을 명시한다.
Phase 2 후속 과제(본 개정 범위 외, v3 안정화 후): ① 런타임의 0-instance wildcard barrier resolve 실증 시 GB를 GA-2 stdout `dynamic_fanout` 기반 조건부 spawn으로 전환(진정한 LLM 0회) ② B1 mapper localdocs tool-level allowlist에 의한 authority drift 구조 차단 ③ GC의 SHA writer 통합으로 task 1개 절감 ④ sub-task별 telemetry 추가 후 v.5/v.6/v3 A/B 계측.
---
## 10. 수용 기준 (Definition of Done — 전 항목 충족 시에만 개정 완료)
### 10.1 정적 검사
1. `Stage_1_Part_1_v3.yml`이 유효한 YAML로 파싱된다.
2. task 수 9개(§2 표의 1~9), `task_procedure` 노드가 §8과 일치한다.
3. §1의 수정 금지 task 5개가 v2와 diff 0이다(공백 포함).
4. GA-1/GA-2/GC 엔트리에 `llm_*`/`prompts` 필드가 없고, GB 엔트리에 `mcp: code-executor`가 없다.
5. GB 프롬프트의 COMMON_CACHE_PREFIX_STAGE_1·ROLE_PREFIX가 v2 원문과 바이트 동일하다.
6. v3 전체에서 `simple concat으로 작동(반드시 LLM 검증 수행)` 문구가 게이트 task에 존재하지 않는다(해당 FORBIDDEN 규칙은 결정적 전환으로 폐기).
### 10.2 fixture 회귀 (7/10 실행물 `Results_July_10_3_15pm` 입력)
GA-1/GA-2 코드를 fixture의 30개 B1 part·30개 B2 part·plan으로 로컬 실행하여:
```text
evidence_indexed.json: items == 30, (STEP 0-3 기본 결정 시) 중복 alias 배열 부재
evidence_event_candidates.json: items == 30, 후보 총 74건
E-019 항목 존재 + 후보 3건(lien_extinction_notice_dispatch, ongoing_physical_possession, lien_violation_candidate) 보존
candidate 필드: input 대비 증감 0 (candidate_id_proposed→candidate_id, source_evidence_index_proposed→source_evidence_index 키 교체 2건 제외)
identity_signature 완전일치 dedup group == 0, dedup_findings == []
2-run 결과: 최종 파일 2종 바이트 동일 (audit의 executed_at 필드만 비교 제외)
B12_exception_pack: R-SELFWARN 1건(상계 항변 self-warning) 외 GA 규칙상 발생분만 존재
```
### 10.3 주입 테스트 (fixture 사본 변조)
1. part 1개 삭제 → GA completeness BLOCK + rerun 대상 기록.
2. 서로 다른 ordinal에 동일 `identity_signature` 주입 → dedup 1건 + `dedup_findings` 기록 + 후보 합계 보존식 성립.
3. `event_candidates: []` + `zero_event_reason: null` 주입 → `schema_invariant_findings` BLOCK + `rerun_target_task: "Task_B2_map_events_{ordinal}"`.
4. 명시 날짜 역전 주입 → R-CHRONO suspect 생성(자동 BLOCK 아님) → GB 판정 경로 확인.
5. candidate 필드 1개 삭제 주입 → 보존성 invariant(필드 수) BLOCK.
6. 존재하지 않는 `source_evidence_index_proposed` 주입 → reference integrity BLOCK.
### 10.4 하류 무영향 검증
1. GC 산출 audit 2종을 SHA writer에 입력하여 sidecar가 생성되고, review item의 `source_refs` 4개 키에 값이 정상 매핑됨을 확인한다(X-1 재발 검사).
2. 개정 산출 최종 파일 2종 + sidecar로 Part 2 Stage A(`Task_C_BO_Stage_A_input_normalization`), Part 3 `Task_LES0_input_pack_compiler`, Part 4 `Task_FL0_fact_source_pack_compiler`의 입력 파싱이 통과함을 확인한다(특히 alias 제거 결정 시).
3. `stage1_tmp/` 신규 파일들이 Part 2/3/4의 어떤 입력 계약과도 충돌하지 않음을 확인한다(신규 디렉토리이므로 기본 통과).
### 10.5 실측
v3로 Part 1 전체 재실행 → 게이트 구간(GA-1→GA-2→GB→GC) LLM 호출이 suspects 유무에 따라 0~1회인지, Part 1 총 시간·비용이 v.6(8분 45초 / $2.09) 대비 감소했는지 기록한다.
---
## 11. 금지 사항 최종 목록 (개정 실행자 대상)
1. v2 원본 파일 덮어쓰기·이동·삭제 금지 (v3는 신규 파일).
2. §1 불변 계약의 파일 경로·envelope 키·enum·상태 문자열 변경 금지.
3. Part 2/3/4 YAML 수정 금지 (본 개정의 성립 조건이 "하류 무영향"이다).
4. GA/GC 코드에서 count·severity·ID를 입력 데이터 외 근거로 생성 금지 (모든 count는 `len()`, 모든 ID는 검증된 propose 값 또는 형식 규칙).
5. GA-2에서 candidate 필드 선별·요약·정규화 금지 (dict 복사 + 지정된 키 교체 2건만).
6. GB에 exception pack 외 입력 제공 금지, GB의 final 파일 write 금지.
7. dedup 시 dropped candidate의 원본 데이터 파기 금지 (`dedup_findings[*].dropped_candidate`에 보존 — semantic merge는 Stage 2 소관).
8. 의심 항목의 silent 절단 금지 (`overflow_items[]` 기록 의무).
9. `source_refs`의 배열형 생성 금지 (named object 4키 고정).
10. 본 명세서에 없는 "개선"의 임의 추가 금지 — 범위 밖 아이디어는 개정 보고서에 제안으로만 기록한다.
@@ -0,0 +1,189 @@
# Part 1 비효율 분석 및 개정 전략 보고서 (Claude v1)
- 대상: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml`의
`Task_B1_quality_gate_evidence_indexed` (이하 **B1 게이트**),
`Task_B2_quality_gate_event_candidates` (이하 **B2 게이트**)
- 근거 자료: v.6 YAML 4종 전체 + 실행 결과 `v.6/Results_July_10_3_15pm/` 실측 + Part 2/3/4 하류 소비 지점 grep 검증
- 실행 실적: Part 1 = 8분 45초 / $2.09 (v.5 대비 악화, Part 1이 4개 Part 중 최장 실행)
---
## 0. 결론 요약
1. **비효율의 본체는 "fan-out 결과를 모아서 넘기는 것" 자체가 아니라, 그 fan-in을 LLM 컨텍스트로 수행하고 통합 결과 전체를 LLM 출력 토큰으로 손으로 재작성하게 만든 구조다.** 두 게이트는 합쳐서 약 500KB를 LLM 입력으로 읽고, 약 141KB의 최종 JSON을 LLM 출력 토큰으로 재생성하며, 이 두 개의 대형 LLM 호출이 파이프라인 꼬리에서 **직렬**로 실행된다.
2. 두 게이트가 수행하는 10개 검증 항목 중 대부분은 결정적(Python) 검사로 완전 대체 가능하며, 실제 실행 결과에서 LLM 추론이 추가로 발견한 것은 **0건**이다(전 항목 PASS, 유일한 finding은 mapper가 이미 남긴 self-warning의 릴레이 1건).
3. 오히려 LLM-writer 구조가 **실증된 품질 결함 4건**을 만들었다: (Q-1) E-019 항목 통째 무단 누락(후보 3건 소실, completeness check는 PASS로 오판), (Q-2) candidate 필드 16종 무단 탈락(YAML의 pass-through 지시 위반), (Q-3) B1 최종본에 동일 배열 2중 수록(출력 2배), (Q-4) dedup 3건 미기록(`dedup_findings: null`).
4. 개정 방향: Part 3(LES1/LES2)·Part 4에서 이미 검증한 **"결정적 propose/조립 → 조건부 국소 LLM 판정 → 결정적 finalize" 샌드위치 패턴**을 두 게이트에 이식한다. 게이트 구간 예상 효과: 수 분 → 수십 초, 게이트 LLM 비용 사실상 제거, Q-1~Q-4 원천 차단.
---
## 1. 실측 데이터 (Results_July_10_3_15pm 기준)
| 파일/디렉토리 | 크기 | 비고 |
|---|---|---|
| `evidence_shard_plan.json` | 84,582 B | 두 게이트가 전문을 읽음. 게이트에 필요한 것은 `expected_ordinals`/`shard_count`뿐 |
| `evidence_indexed_parts/E-*.json` (30개) | 54,289 B | B1 mapper fan-out 산출물 |
| `evidence_event_candidate_parts/E-*.json` (30개) | 129,294 B | B2 mapper fan-out 산출물, 후보 총 74건 |
| `evidence_indexed.json` (B1 게이트가 LLM 출력으로 재작성) | **91,841 B** | parts 합(54KB)보다 큼 — 동일 배열이 `items`와 `evidence_indexed` 키로 2중 수록(§5 Q-3) |
| `evidence_event_candidates.json` (B2 게이트가 LLM 출력으로 재작성) | 49,327 B | 29 items / 후보 71건 — **E-019 항목·후보 3건 소실**(§5 Q-1, Q-2) |
| `quality_gates/B1_evidence_indexed_gate.json` | 2,552 B | 전 체크 PASS |
| `quality_gates/B2_event_candidates_gate.json` | 3,017 B | 전 체크 PASS, review finding 1건(mapper self-warning 릴레이) |
| `quality_gates/stage1_part1_soft_gate_handoff.json` | 2,773 B | 결정적 SHA writer 산출(READY_WITH_REVIEW) |
게이트별 LLM 입출력 규모(추정 포함):
- **B1 게이트 입력**: plan 84.6KB + B1 parts 30개 54.3KB + `evidence_all.json` 전문 + `client_meeting.md` 전문 (원문 2종은 결과 폴더 외 입력물, 합계 수십~수백 KB 추정). 출력: 91.8KB + audit 2.6KB ≈ **약 94KB를 출력 토큰으로 생성**.
- **B2 게이트 입력**: plan 84.6KB + B2 parts 30개 129.3KB + `evidence_indexed.json` 91.8KB + B1 audit 2.6KB ≈ **약 308KB**. 출력: 49.3KB + audit 3.0KB ≈ **약 52KB를 출력 토큰으로 생성**.
- 둘 다 `gemini-3.1-flash-lite` + `llm_reasoning: high` + localdocs 툴 루프(list → 다중 read → 메모리 검증 → 대형 write ×2). 출력 토큰 생성은 순차적이므로, 합계 약 14만 6천 바이트(대략 4만~5만 출력 토큰 수준)의 재작성 + high reasoning의 사고 토큰이 게이트 구간 벽시계 시간의 지배항이다.
---
## 2. 두 게이트의 실행 방식 (질문 6에 대한 답)
### 2.1 DAG 상 위치와 직렬화
```
Task_Evidence_shard_planner
├─ Task_B1_map_doc_001..030 (fan-out, max_concurrency 12)
│ └─ (same_ordinal) Task_B2_map_events_001..030 (fan-out, max_concurrency 12)
├─ all Task_B1_map_doc_* ──▶ Task_B1_quality_gate_evidence_indexed [LLM, 대형]
└─ all Task_B2_map_events_* ─┐
Task_B1_quality_gate ─┴▶ Task_B2_quality_gate_event_candidates [LLM, 대형]
└▶ Task_B2_SHA256_soft_gate_handoff_writer [code-executor, 결정적] ─▶ OUT
```
- B2 게이트는 `all Task_B2_map_events_*` **그리고** B1 게이트 완료를 함께 대기한다. B1 게이트는 B2 mapper들과 병렬로 돌 수 있으나, 꼬리에서 **B1 게이트 → B2 게이트 → SHA writer**의 3단 직렬 체인이 형성되고, 그중 앞 2단이 각각 위 §1 규모의 대형 LLM 호출이다.
- B2 게이트가 B1 게이트를 대기하는 실질적 이유는 두 가지다: (a) `evidence_indexed.json`(B1 final)을 읽어 후보의 `evidence_index` 참조 무결성을 검증, (b) B1 audit의 review finding을 가져와 soft handoff 통합 소스로 보존. **(a)에 필요한 정보는 finalized E-ID 목록(30줄)뿐인데 91.8KB 전문을 읽고, (b)는 2.6KB audit의 극히 일부 필드만 쓴다.** 즉 직렬 의존 자체는 정당하나, 의존을 만족시키는 데 전달되는 데이터 표면이 필요량의 수십 배다.
### 2.2 게이트 내부 절차 (공통 패턴)
두 게이트 모두 동일한 5단 패턴이다:
1. `list_docs`/`read_docs`로 plan + **모든** part 파일 + (B1: 원문 `evidence_all.json`·`client_meeting.md` / B2: B1 final 전문 + B1 audit)을 LLM 컨텍스트에 적재.
2. 5개 검증 항목을 "LLM 추론으로" 수행 (B1: shard completeness, index determinism, duplicate alias, component coverage, authority drift / B2: completeness, evidence reference integrity, candidate_id collision, chronological ordering, legal-effect coverage + schema invariant 사전검사).
3. E-###/EVT-### ID finalize, identity_signature dedup.
4. 최종 envelope JSON의 "정확한 serialized string"을 메모리에서 생성.
5. `write_file`로 최종 파일 + audit report 저장.
`ABSOLUTE_FORBIDDEN`에 "simple concat으로 작동(반드시 LLM 검증 수행)"이 명시되어 있어, 기계적 병합조차 LLM이 전량 손으로 재타이핑하도록 강제된다. 이것이 §1의 출력량을 만든 직접 원인이다.
---
## 3. 질문 7에 대한 답: "모아서 한 번에 넘기는" 것이 런타임을 증폭시키는가?
**부분적으로 그렇고, 더 정확히는 3중 증폭 구조다.**
- **fan-in 자체는 필요하다.** 단일 writer 원칙(최종 파일을 한 task만 작성)과 cross-document 검증(ID 충돌, 중복 서명, 참조 무결성)은 본질적으로 전 part를 한 곳에 모아야 가능하다. 따라서 "모아서 넘기는 설계"를 없애는 것이 답이 아니다.
- **증폭 ①: fan-in을 LLM 컨텍스트로 수행.** 30개 part + plan 전문 + 원문(B1) + 선행 final 전문(B2)을 전부 LLM 입력으로 밀어 넣는다. 필요 필드만 추리면 입력의 대부분은 불필요하다(§2.1, §6).
- **증폭 ②: 통합 결과 전체를 LLM 출력으로 재작성.** 게이트가 최종 파일의 단독 writer이므로, 병합·정렬·ID부여라는 기계적 작업의 결과물 141KB를 LLM이 토큰 단위로 다시 생성한다. LLM 호출에서 출력 토큰은 입력 토큰보다 수 배 느리고 비싸며, 이 재작성이 벽시계 시간의 지배항이다. **게다가 재작성은 무손실이 아니었다(§5).**
- **증폭 ③: 대형 LLM 호출 2개의 직렬 연쇄 + reasoning high.** B1 게이트 → B2 게이트가 순차이고, 둘 다 `llm_reasoning: high`로 사고 토큰까지 최대로 쓴다. 집계·병합 작업에 high reasoning이 기여한 증거는 실행 결과에 없다(발견 0건).
요약하면: *모아서 넘기는 것*이 아니라 *모은 것을 LLM에게 읽히고, LLM에게 다시 쓰게 하는 것*이 비효율의 본체다.
---
## 4. 10개 검증 항목의 성격 분류 — 무엇이 정말 LLM을 필요로 하는가
| # | 검증 항목 | 성격 | 결정적 대체 | 실행 결과 |
|---|---|---|---|---|
| B1-1 | shard completeness (expected vs received) | 집합 비교 | **완전 대체** (set diff) | PASS |
| B1-2 | evidence_index determinism (E-### 형식·유일성) | 정규식+유일성 | **완전 대체** | PASS |
| B1-3 | duplicate alias (제목/별칭 중복 의심) | 문자열 유사 + 판단 | 후보쌍 추출은 결정적(정규화 일치·n-gram), **판정만 LLM 잔존 가능** | PASS(발견 0) |
| B1-4 | component coverage (구성요소 누락) | mapper self-warning 승계 + 판단 | 규칙 기반 1차(필수 키 존재) + **의심건만 LLM** | PASS |
| B1-5 | authority drift (part 내용이 원문과 괴리) | 원문 대조 추론 | 상시 수행 불가(원문 필요). **조건부 spot-check로 강등** 권고(§6.3) | PASS(발견 0) |
| B2-0 | schema invariant (empty candidates + null zero_event_reason) | 키 존재 검사 | **완전 대체** | 위반 0 |
| B2-1 | event candidate completeness | 집합 비교 | **완전 대체** | PASS |
| B2-2 | evidence reference integrity (B1 E-ID 존재) | 집합 멤버십 | **완전 대체** (E-ID 목록만 필요) | PASS |
| B2-3 | candidate_id collision + identity_signature dedup | 형식·유일성·exact-match | **완전 대체** (canonical 우선순위 규칙도 이미 결정적으로 명문화됨: raw>derived, confidence, locators 수, ordinal) | PASS |
| B2-4 | chronological ordering (이행기·시효·도달일 시간 정합) | 날짜 비교 + 법률 판단 | 위반 후보 추출은 결정적(날짜 역전 스캔), **판정만 LLM 잔존 가능** | PASS(발견 0) |
| B2-5 | legal-effect coverage (payment/notice/auction/lien 등 누락) | 분포 검사 + 판단 | REQUIRED_EVENT_SUBKINDS 존재 검사는 결정적, **누락 의심 사유 서술만 LLM 잔존 가능** | PASS |
**핵심 관찰**: 10+1개 항목 중 7개는 100% 결정적 대체가 가능하고, 나머지 4개도 "의심 후보 추출(결정적) → 판정(LLM)"으로 분해하면 LLM 입력이 O(전체 데이터)에서 O(의심 항목)로 줄어든다. 이는 Part 3 LES1→LES2에서 이미 적용해 검증한 것과 동일한 구조다(LES2 판정 universe = 예외 항목만). 그리고 이번 실행에서 의심 항목은 사실상 0건이었다 — 즉 개정 구조였다면 **게이트 구간의 LLM 호출이 0회 또는 초소형 1회**로 끝났을 실행이다.
또한 유일한 review finding(`review_findings_in_mapper`, SOFT_WARNING, "상계 주장 등 일부 항변 사항은 Stage 2에서 검토 필요", refs E-010/E-011/E-012/E-028)은 mapper part가 이미 남긴 self-warning의 **분류·릴레이**였다. 이 승격 판정이야말로 국소 LLM 1회(또는 규칙 매핑)로 충분한 작업이다.
---
## 5. 실행 결과가 실증한 품질 결함 — LLM-writer 구조의 직접 비용
경량화 논거이기 이전에, 현행 구조가 **정확성 자체를 훼손**하고 있음이 이번 실행물에서 확인된다.
- **Q-1 (중대): E-019 항목 통째 누락.** `evidence_event_candidate_parts/E-019.json`(제목 "소멸청구 통지서", 후보 3건, zero_event 아님)이 최종 `evidence_event_candidates.json`에서 항목째 사라졌다(30 part → 29 items, 후보 74 → 71). 그런데 같은 게이트의 completeness check는 `received_ordinals`에 001~030 전부를 기록하고 PASS를 선언했다 — **읽기는 했으나 재작성에서 빠뜨린 것**으로, LLM 재생성 writer의 전형적 실패 양식이다. 소멸청구 통지서는 Part 4 `_lien_extinction_notice_scan`과 Part 2 notice 도메인이 소비해야 할 법적 중대 자료라 실질 피해 가능성이 있다.
- **Q-2 (중대): pass-through 위반 — candidate 필드 16종 무단 탈락.** YAML은 명시적으로 "mapper part의 모든 component field(participants, current_state_candidate, succession_candidate, legal_effect_candidate 등)는 그대로 보존한다"고 지시하지만, 최종본 candidate에는 28개 필드 중 12개만 남았다. 탈락: `amount`, `location`, `time_text`, `time_precision`, `event_end_date`, `fraction_ref`, `legal_effect_candidate`, `legal_keywords`, `defense_candidate`, `succession_candidate`, `commercial_successor_candidates`, `actio_relevance_candidates`, `current_state_candidate`, `source_fact_candidate`, `meeting_clause_refs`, `support_locators`. `fraction_ref`(지분 이전 추적)·`legal_effect_candidate`·`defense_candidate`는 v1/v2 개정에서 하류 연계를 위해 일부러 추가·강화한 필드들이다.
- **Q-3: B1 최종본 2중 수록.** `evidence_indexed.json`의 `items`와 `evidence_indexed` 키가 **바이트 동일한 30개 배열**을 각각 담고 있다(91.8KB, parts 합 54.3KB보다 커진 이유). 스키마 문구의 "top-level `items` 또는 v.2 호환 구조"라는 양자택일 모호성을 LLM이 "둘 다"로 해석한 결과로 보이며, 출력 토큰(=시간·비용)을 정확히 2배로 만든다.
- **Q-4: dedup 미기록.** 후보 3건 감소가 dedup이었다면 audit의 `dedup_findings`에 기록해야 하나 `null`이다(Q-1과 결합 시, 감소분은 기록 없는 소실이다).
**함의**: "simple concat 금지, 반드시 LLM 검증"이라는 FORBIDDEN 규칙은 품질을 지키기 위한 것이었지만, 실측 결과는 반대로 **결정적 병합이라면 원천적으로 불가능한 4종의 오류**를 만들었다. 병합·보존·직렬화는 기계가, 판단은 LLM이 해야 한다는 파이프라인 전반의 설계 원칙("결정적 propose → LLM 예외 판정 → 결정적 finalize")과 정확히 합치하는 증거다.
---
## 6. 삭제·축소 안전성 판정 (질문 5에 대한 답 — 하류 연계 근거)
### 6.1 절대 보존해야 할 인터페이스 (하류 소비 실증)
| 산출물 | 소비자 (grep 실증) | 보존 범위 |
|---|---|---|
| `evidence_indexed.json` | Part 2(5개소)·Part 3(4개소)·Part 4(3개소) | 파일 경로·envelope·item 스키마(`evidence_index`, `title`, `doc_type`, `source_pointer`, key_* 등) 전부 보존. 단 **중복 배열 1개는 제거 가능**(하류는 `items` 기준 소비) |
| `evidence_event_candidates.json` | Part 2(5개소)·Part 3(3개소)·Part 4(3개소) | `schema_version="evidence_event_candidates.v1"` envelope + item/candidate 전 필드 보존(오히려 Q-2 탈락분 **복원** 필요) |
| `quality_gates/stage1_part1_soft_gate_handoff.json` | Part 2 Stage_A(`PART1_SOFT_GATE_HANDOFF_FILE`, `_compact_part1_soft_gate_handoff`가 스키마 버전·digest_guard·review 요약을 검증·승계) | sidecar 스키마 v1 + `digest_guard` 4종 SHA256 + hard/review 요약 구조 완전 보존 |
| `quality_gates/B1_*.json`, `B2_*.json` (audit) | **Part 2/3/4 소비 0건.** Part 1 내부에서만 소비(B2 게이트가 B1 audit 읽기, SHA writer가 두 audit 읽어 sidecar 생성) | 파일은 유지하되 **내부 인터페이스로 재정의 가능** — SHA writer가 읽는 필드(`hard_gate_findings[]`, `review_findings[]`, `review_gate_summary`, `handoff_export_summary`)와 감사 가치가 있는 결정적 체크 결과만 있으면 충분 |
### 6.2 삭제해도 안전한 작업 (근거 포함)
1. **최종 파일의 LLM 재작성 전체.** 병합·정렬·ID finalize·dedup·직렬화는 §4에서 본 대로 전부 결정적 규칙으로 명문화되어 있다(canonical 우선순위까지 YAML에 이미 결정적 규칙으로 적혀 있음). code-executor로 옮기면 산출물 스키마는 동일하고 Q-1~Q-4가 구조적으로 불가능해진다. 하류는 파일 내용 스키마만 보므로 writer의 구현 주체 변경은 하류 비가시적이다.
2. **B2 게이트의 `evidence_indexed.json` 전문 로드.** 참조 무결성 검증에 필요한 것은 finalized E-ID 집합(≈30개 문자열)뿐. B1 결정적 writer가 audit(또는 초소형 사이드 파일)에 `finalized_evidence_indexes: ["E-001",...]`를 남기면 91.8KB → 약 0.5KB로 축소된다.
3. **두 게이트의 `evidence_shard_plan.json` 전문 로드.** 필요한 것은 `expected_ordinals`·`shard_count`·`stale_part_policy`. 결정적 코드는 json 파싱 후 해당 키만 쓰므로 "로드"는 무해해지지만(코드 실행이므로 토큰 비용 0), LLM 잔존 판정 호출에는 절대 전달하지 않는다.
4. **B1 게이트의 `evidence_all.json`·`client_meeting.md` 상시 전문 로드 (authority drift 상시 검사).** 실행 실적상 발견 0건, mapper가 이미 원문(shard)을 직접 읽고 part를 생성하며 self-warning 채널을 가진다. 하류에도 이 검사 결과를 소비하는 지점이 없다. → **상시 검사 삭제, 조건부 spot-check로 강등**: 결정적 통합기가 의심 신호(예: part의 key_dates/key_amounts가 비었는데 doc_type상 있어야 하는 유형, mapper self-warning 존재)를 낸 문서에 한해, 해당 shard 원문만 국소 LLM 판정 입력에 첨부한다.
5. **`llm_reasoning: high`.** 잔존하는 국소 판정 호출은 low(필요시 medium)로 충분하다. 집계 작업에 high가 기여한 증거 없음.
6. **audit report의 서사적 확장 필드 중 소비자 없는 부분** (`stage2_risk_notes[]` 등 자유서술): sidecar와 Part 2가 소비하지 않음. 유지 비용이 낮아 보이나 LLM이 생성하는 한 출력 토큰이므로, 결정적 생성으로 전환하면서 "결정적 체크 결과 + 승격 판정 결과"로 국한한다.
### 6.3 삭제하면 안 되는 것
- **단일 writer 원칙과 fan-in 지점 자체** (필요 — §3).
- **B2→B1 의존** (참조 무결성·review 통합에 필요 — 단 전달물은 §6.2-2처럼 축소).
- **mapper self-warning의 승격 판정 경로** (이번 실행의 유일한 실질 산출 — review finding → sidecar → Part 2 승계 체인은 실제로 작동 중).
- **`digest_guard` SHA256 sidecar와 그 결정적 writer** (이미 결정적이고 Part 2가 검증에 사용).
- **HARD/REVIEW 분류 규칙과 BLOCK 의미론** (rerun_target_task 등 재실행 라우팅 포함).
---
## 7. 개정 전략
### 7.1 권장안 A — 게이트 분해: "결정적 통합기 + 조건부 국소 판정" (Part 3/4 검증 패턴 이식)
```
[현행] all B1 parts ─▶ B1 LLM 게이트(읽기 전부·재작성 전부) ─▶ B2 LLM 게이트(읽기 전부·재작성 전부) ─▶ SHA writer
[개정] all B1 parts ─▶ GA-1 결정적 통합기(B1) ─┐
all B2 parts ─▶ GA-2 결정적 통합기(B2) ─┴▶ GB 조건부 국소 LLM 판정(의심항목만, 0건이면 skip) ─▶ GC 결정적 finalize/audit ─▶ SHA writer
```
- **GA-1 `Task_B1_gate_merge_deterministic`** (code-executor): plan 파싱 → 전 part 로드 → B1-1/B1-2 결정적 검사 → duplicate-alias 후보쌍·component-coverage 의심건·authority-drift 의심건을 **결정적 신호 규칙**으로 추출 → E-### finalize → `evidence_indexed.json` 조립·저장(**`items` 단일 배열**, Q-3 해소) → audit skeleton(결정적 체크 결과 + `finalized_evidence_indexes[]` + `suspect_items[]`) 저장. mapper self-warning은 전량 `review_candidates[]`로 승계.
- **GA-2 `Task_B2_gate_merge_deterministic`** (code-executor): GA-1 완료 대기(E-ID 목록만 사용) + 전 B2 part → schema invariant/completeness/참조 무결성/ID collision 결정적 검사 → identity_signature exact dedup(우선순위 규칙 코드화, `dedup_findings[]` 의무 기록 — Q-4 해소) → EVT-ID finalize → **candidate 전 필드 pass-through**로 `evidence_event_candidates.json` 조립·저장(Q-1·Q-2 구조적 해소: 조립이 `dict` 복사이므로 항목·필드 소실 불가) → 날짜 역전·REQUIRED_EVENT_SUBKINDS 공백 등 의심건 추출.
- **GB `Task_B1B2_gate_llm_adjudicator`** (LLM, flash-lite, reasoning **low**, 조건부): GA-1/GA-2가 추출한 의심 항목 + mapper self-warning의 **compact 목록만** 입력(항목당 발췌 수백 자, authority-drift 의심 문서에 한해 해당 shard 원문 첨부). 출력은 항목별 `{finding_id, severity, issue_type, concise_basis, source_refs}` 판정만(수백 토큰). **의심 항목 0건이면 이 task는 호출 없이 통과**(GA 산출 audit에 "no suspects" 기록). Part 3 LES2의 budget_gate 방식(항목 수·문자 수 상한)을 그대로 재사용한다.
- **GC (GA 내 또는 초소형 후속 code-executor)**: GB 판정을 audit의 `hard_gate_findings[]`/`review_findings[]`/`review_gate_summary`/`handoff_export_summary`로 병합(SHA writer가 읽는 인터페이스 동일 유지) → 기존 `Task_B2_SHA256_soft_gate_handoff_writer` 무수정 연결.
**하류 영향 없음 논증**: 최종 2개 파일의 스키마·경로·envelope 동일(+Q-2 복원으로 오히려 하류 v2 필드가 정상 공급됨), audit 파일의 SHA-writer 소비 필드 동일, sidecar 완전 동일. COMMON_CACHE_PREFIX_STAGE_1 블록은 GB(신규 LLM task)에 그대로 부착하고 기존 블록은 수정하지 않는다. SKILL.md의 code-executor 보일러플레이트(localdocs MCP httpx 패턴, `{{__user_hash__}}`)를 GA/GC에 그대로 사용한다.
**예상 효과(추정 명시)**: 게이트 구간 LLM 입력 ~500KB → 0~수 KB, LLM 출력 ~146KB → 0~1KB. 게이트 구간 벽시계 수 분 → code 2회(수 초~수십 초) + 조건부 LLM ≤1회. Part 1 $2.09 중 게이트 2호출이 차지하던 몫(입출력 규모상 mapper 60호출 대비 최대 단일 호출 2건)이 사실상 제거된다. 이번 실행과 동일 입력이었다면 GB는 self-warning 승격 1건만 판정하는 초소형 호출(또는 규칙 매핑으로 0회)이었다.
### 7.2 대안 B — 구조 유지 최소 개정 (권장하지 않음, 비교용)
현행 LLM 게이트 골격을 유지한 채: (i) `llm_reasoning: high → low`, (ii) B2 입력에서 `evidence_indexed.json` 전문 제거(B1 audit에 E-ID 목록 추가), (iii) B1 산출 envelope의 중복 배열 금지 문구를 단일 형태로 확정, (iv) authority drift를 "self-warning 있는 문서만 해당 shard 대조"로 축소, (v) pass-through 위반 시 BLOCK을 POST_WRITE_VERIFICATION에 추가(필드 수 count 검증).
→ 입력은 절반 이하로 줄지만 **출력 재작성 병목(약 96KB: 중복 제거된 B1 46KB + B2 50KB)은 그대로 남고**, Q-1/Q-2류(재작성 소실)는 지시문 강화로 완화될 뿐 구조적으로 차단되지 않는다. 실행 시간 개선 폭도 제한적일 것으로 추정된다. 안 A가 파이프라인의 기존 설계 원칙과도 정합하므로 A를 권장한다.
### 7.3 이행 순서 및 검증 계획
1. GA-1/GA-2/GB/GC를 v.6 YAML에 반영한 `Stage_1_Part_1_v3.yml` 작성(task_procedure 갱신: `all Task_B1_map_doc_*`→GA-1, `all Task_B2_map_events_*`+GA-1→GA-2→GB(조건부)→GC→SHA writer).
2. 결정적 통합기 fixture 검증: 이번 실행의 30개 part를 입력으로 GA-1/GA-2를 로컬 실행 → (a) `evidence_indexed.json`이 현행 대비 중복 배열 제거 외 item-level 동등, (b) `evidence_event_candidates.json`에 **E-019 3건 포함 74후보(중복 제외 시 dedup_findings 기록과 정확 일치)** + candidate 28필드 보존, (c) 2-run 바이트 동일성(결정론), (d) sidecar 입력 인터페이스 필드 존재.
3. 의심 항목 주입 테스트(고의 결측 part, 중복 signature, 날짜 역전)로 GB 트리거·BLOCK 경로 확인.
4. 실 실행으로 Part 1 시간·비용 재측정 후 v.5/v.6과 비교.
---
## 부록 A. 근거 실측 로그 요약
- v.6 4개 YAML은 v.5 산출본과 byte-identical (diff 확인).
- 게이트 audit 실측: B1 checks 5종 전부 PASS(`received_ordinals` 30/30), B2 checks 전부 PASS + `schema_invariant_findings: []`, `overall_severity: PASS`, `hard_gate_findings: []`, review 1건(SOFT_WARNING, mapper self-warning 릴레이, refs E-010/E-011/E-012/E-028), `downstream_progression: ALLOWED_WITH_WARNING`.
- sidecar 실측: `handoff_status: READY_WITH_REVIEW`, `stage2_auto_progression_allowed: true`, digest_guard SHA256 4종 정상.
- 최종본 대조: `evidence_indexed.json` — `items` 30 == `evidence_indexed` 30 (JSON 정규화 후 동일); `evidence_event_candidates.json` — items 29(E-019 부재), 후보 71/74, zero-event 1건(E-016, REFERENCE_ONLY_DOC)은 정상 처리, `dedup_findings: null`.
- 하류 참조 건수: evidence_indexed.json → P2:5 / P3:4 / P4:3, evidence_event_candidates.json → P2:5 / P3:3 / P4:3, `soft_gate_handoff` → P2 Stage_A 소비 확인, audit 2종 → P2/P3/P4 참조 0건.
@@ -0,0 +1,556 @@
# Stage 1 Part 1 B1/B2 Quality Gate 비효율 및 최적화 보고서
## 0. 결론 요약
검토 대상 중 사용자가 `B2_quality_gate_event_indexed`라고 지칭한 첫 작업의 YAML상 실제 이름은 `Task_B1_quality_gate_evidence_indexed`이다. 두 번째 작업의 실제 이름은 `Task_B2_quality_gate_event_candidates`이다. 본 보고서는 이 두 작업을 각각 **B1 gate**, **B2 gate**로 부른다.
최종 결론은 다음과 같다.
1. 두 gate의 **논리적 기능과 최종 산출물은 삭제하면 안 된다.** `evidence_indexed.json`과 `evidence_event_candidates.json`은 Part 2, Part 3, Part 4가 실제로 읽는 downstream authority file이다.
2. 그러나 두 gate에서 수행하는 작업 대부분은 LLM 추론이 아니라 Python으로 완전히 결정할 수 있는 검증·정렬·병합·ID 확정·스키마 검사다. **정상 경로의 full-context LLM 실행은 제거할 수 있다.**
3. 현재는 B1 gate와 B2 gate가 각각 모든 mapper part를 한 번에 다시 읽는 global fan-in 구조다. 특히 B2 gate는 30개 B2 part 외에 84,582-byte planner, 91,841-byte B1 final, B1 audit까지 다시 읽는다. 이것이 사용자가 의심한 “앞 작업의 결과를 한 번에 모아 후행 작업에 넘기는 비효율”의 정확한 형태다.
4. 다만 각 mapper의 출력이 orchestrator 대화문에 모두 삽입되는 것은 아니다. part 파일을 localdocs로 다시 읽는 방식이다. 병목은 **대화 context 누적**이 아니라 **barrier 이후 대량 파일 재독해 + high-reasoning LLM의 전역 병합·검증**이다.
5. 실제 2026-07-10 결과에서 B2 gate는 30개 part가 모두 반영됐다고 `PASS`했지만, 최종 파일은 29개 item만 포함한다. `E-019` 전체와 그 안의 유치권 관련 event candidate 3개가 소실됐다. 따라서 현재 구조는 느릴 뿐 아니라 deterministic reducer보다 merge 품질도 낮다.
6. 최적 경로는 두 gate를 **deterministic reducer**로 전환하고, Python이 생성한 작은 exception pack에 실제 법률적·의미론적 모호성이 있을 때만 단일 LLM adjudicator를 실행하는 것이다.
7. 현재 gate 모델은 이미 `gemini-3.1-flash-lite`다. 주된 개선수단은 더 약한 모델로 바꾸는 것이 아니라 **LLM 호출 자체와 입력량을 제거하는 것**이다. 예외 추론이 발생할 때만 같은 모델을 `reasoning=medium`, `verbosity=low`로 사용한다.
## 1. 검토 범위와 근거
### 1.1 검토한 YAML
| Part | 파일 | 핵심 downstream 역할 |
|---|---|---|
| Part 1 | `Stage_1_Part_1_v2.yml` | client goal, evidence index, event candidates, Part 1 gate handoff 생성 |
| Part 2 | `Stage_1_Part_2_v2.yml` | Part 1 authority file을 정규화하여 BO 50건 및 3개 signal file 생성 |
| Part 3 | `Stage_1_Part_3_v1.yml` | BO·signals·evidence/event를 이용해 legal effect structure 생성 |
| Part 4 | `Stage_1_Part_4_v2.yml` | BO·legal effect·evidence/event를 이용해 Fact Ledger 생성 |
네 YAML의 task/model/DAG와 실제 downstream parser를 함께 확인하였다. Part 2의 `Task_C_BO_Stage_A_input_normalization`, Part 3의 `Task_LES0_input_pack_compiler`, Part 4의 `Task_FL0_fact_source_pack_compiler`가 모두 Part 1의 final authority file을 직접 소비한다.
### 1.2 검토한 2026-07-10 실행 결과
`Results_July_10_3_15pm`에는 다음 주요 결과가 존재한다.
- Part 1: 30개 evidence shard, 30개 B1 part, 30개 B2 part, `evidence_indexed.json`, `evidence_event_candidates.json`, B1/B2 gate report, soft-gate handoff
- Part 2: `BO.json` 50건, `actio_case_signals.json` 5건, `case_liability_signals.json` 50건, `legal_effect_signals.json` 50건
- Part 3: `legal_effect_structures.json` 및 LES intermediate/exception artifacts
- Part 4: `Fact_Ledger_base.json` 50건 및 Fact Ledger intermediate/report artifacts
Part 1 전체 런타임 8분 45초와 비용 $2.09만 제공되었고 sub-task별 timing/token log는 없다. 그러므로 특정 gate가 정확히 몇 초 또는 몇 달러를 소비했다고 단정할 수는 없다. 아래 평가는 YAML의 실제 fan-in, 모델 설정, 파일 크기와 결과 보존성에 근거한 구조적 평가다.
또한 v.5와 v.6 Part 1은 planner, 30-way B1/B2 mapper fan-out, B1/B2 gate, SHA256 handoff writer라는 기본 topology와 gate 모델이 같다. 따라서 v.6의 전체 런타임 증가를 두 gate의 “신설” 탓으로 돌릴 수는 없다. v.6의 확대된 schema·prompt·출력량, 실제 입력 사건의 복잡도, 모델 응답시간도 함께 계측해야 한다.
## 2. 현재 Part 1 실행 구조
```text
+----------------------+
IN ---------------------------------> | Task_A_client_goal |
| +----------------------+
|
+--> Task_Evidence_shard_planner (Python)
|
| dynamic_fanout = 30
v
+--------------------------+
| B1_map_doc_001 ... _030 | LLM, max_concurrency=12
+--------------------------+
| same-ordinal streaming edge
v
+----------------------------+
| B2_map_events_001 ... _030 | LLM, max_concurrency=12
+----------------------------+
|
| all B2 parts | all B1 parts
| v
| +------------------------------+
| | B1 quality gate |
| | all B1 parts + planner |
| | + evidence_all + meeting |
| | -> evidence_indexed.json |
| +------------------------------+
| |
+------------------------------+
barrier
|
v
+----------------------------------+
| B2 quality gate |
| all B2 parts + planner |
| + evidence_indexed + B1 audit |
| -> event final + B2 audit |
+----------------------------------+
|
v
B2_SHA256_soft_gate_handoff_writer (Python)
|
v
OUT
```
### 2.1 중요한 실행 특성
- B2 mapper는 모든 B1이 끝날 때까지 기다리지 않는다. 동일 ordinal의 B1 part가 생기면 해당 B2 mapper가 시작하는 streaming 구조다. 이 부분은 효율적이며 유지해야 한다.
- B1 gate는 `all Task_B1_map_doc_*` barrier 뒤에서 실행된다.
- B2 gate는 `all Task_B2_map_events_*`와 B1 gate 완료를 모두 기다린다.
- 따라서 두 gate는 Part 1 critical path의 직렬 말단에 있다.
- mapper 60개가 모두 LLM이고, 두 gate도 `gemini-3.1-flash-lite`, `reasoning=high`, `verbosity=medium`이다.
## 3. 실측 fan-in과 중복량
### 3.1 산출물 cardinality 및 크기
| 입력/산출물 | 파일 수 | 실제 byte | 비고 |
|---|---:|---:|---|
| `evidence_shards/E-*.json` | 30 | 76,682 | mapper별 raw shard |
| `evidence_indexed_parts/E-*.json` | 30 | 54,289 | B1 mapper 결과 |
| `evidence_event_candidate_parts/E-*.json` | 30 | 129,294 | B2 mapper 결과 |
| `evidence_shard_plan.json` | 1 | 84,582 | 두 gate가 전부 읽음 |
| `evidence_indexed.json` | 1 | 91,841 | B2 gate 및 Part 2~4가 읽음 |
| `evidence_event_candidates.json` | 1 | 49,327 | Part 2~4가 읽음 |
| B1 gate report | 1 | 2,552 | handoff source |
| B2 gate report | 1 | 3,017 | handoff source |
### 3.2 B1 gate 최소 입력량
B1 gate가 읽는 구조화 파일만 계산해도 다음과 같다.
```text
evidence_shard_plan.json 84,582 bytes
B1 mapper parts total 54,289 bytes
-------
known lower bound 138,871 bytes
```
여기에 `evidence_all.json` 전체와 `client_meeting.md` 전체, task prompt, MCP wrapper가 추가된다. B1 gate는 mapper가 이미 읽고 구조화한 raw evidence를 authority drift와 alias 판단을 위해 다시 읽는다.
### 3.3 B2 gate 최소 입력량
```text
evidence_shard_plan.json 84,582 bytes
B2 mapper parts total 129,294 bytes
evidence_indexed.json 91,841 bytes
B1 gate report 2,552 bytes
-------
known input total 308,269 bytes
```
여기에 B2 task prompt와 MCP wrapper가 추가된다. 이 전체를 한 LLM 호출이 읽고, schema 검사·병합·정렬·ID 확정·법률적 검토·JSON serialization까지 동시에 수행한다.
### 3.4 구조 내부의 중복
1. `evidence_shard_plan.json`의 `shards`와 `dynamic_fanout`은 exact same array다. compact JSON 기준 각 27,165 bytes가 중복된다.
2. `evidence_indexed.json`의 `items`와 `evidence_indexed` alias도 exact same 30-item array다. compact JSON 기준 각 31,118 bytes가 중복된다.
3. B2 gate는 evidence reference membership 검사를 위해 `E-001`~`E-030`의 set만 있으면 되는데, B1 final의 모든 component와 위 duplicate alias까지 읽는다.
4. B2 gate는 B1 review finding을 최종 sidecar로 직접 쓰지 않으면서 B1 audit 전체를 읽는다. 실제 통합은 뒤의 deterministic handoff writer가 다시 수행한다.
즉 “앞 작업의 개별 결과를 모두 모아 넘기는가?”에 대한 답은 **그렇다**이다. 다만 B2 gate가 모든 B1 part를 직접 받는 것은 아니고, 모든 B1 part가 합쳐진 full `evidence_indexed.json`을 중복 alias까지 포함해 받는다. 동시에 모든 B2 part 30개를 별도로 받는다.
## 4. 실제 결과에서 확인된 품질 결함
### 4.1 Critical: B2 final에서 E-019 전체 소실
결정론적으로 비교한 결과는 다음과 같다.
| 항목 | 기대값 | 실제값 |
|---|---:|---:|
| planner expected evidence IDs | 30 | 30 |
| B2 part files | 30 | 30 |
| B2 part candidate 합계 | 74 | 74 |
| final document items | 30 | 29 |
| final candidates | 74 | 71 |
| 누락 evidence | 없음 | `E-019` |
`E-019` part에는 다음 3개 후보가 존재한다.
- `lien_extinction_notice_dispatch`
- `ongoing_physical_possession`
- `lien_violation_candidate`
30개 part 전체의 `identity_signature`를 비교해도 exact duplicate group은 0개였다. 따라서 `E-019` 제거는 B2의 명시된 cross-document dedup 규칙으로 설명되지 않는다.
그런데 B2 audit은 다음을 동시에 기록했다.
- `input_parts_count = 30`
- `event_candidate_completeness = PASS`
- `overall_severity = PASS`
- `downstream_progression = ALLOWED_WITH_WARNING`
이는 final writer와 validator를 한 LLM에게 동시에 맡긴 결과로 발생한 보존성 위반이다. Part 2의 Stage A는 `evidence_event_candidates.json` 자체가 제공하는 item만 파싱하며 planner의 30개 expected ID와 final item set을 다시 대조하지 않는다. digest handoff도 “잘못 생성된 final file이 이후 바뀌지 않았음”만 보장하므로 이 누락은 정상 입력처럼 downstream에 전달된다.
### 4.2 High: B2 review source ref가 handoff에서 소실
B2 audit의 `review_findings`는 `source_refs`를 다음처럼 배열로 출력했다.
```json
"source_refs": ["E-010", "E-012", "E-011", "E-028"]
```
그러나 deterministic handoff writer는 다음 named object를 기대한다.
```json
"source_refs": {
"evidence_indexes": [],
"event_candidate_ids": [],
"meeting_clause_refs": [],
"doc_titles": []
}
```
그 결과 최종 `stage1_part1_soft_gate_handoff.json`의 해당 review item은 모든 source ref가 빈 배열이 되었다. B2 audit은 `review_gate_count=4`라고 적었지만 실제 `review_findings`는 1개이고, deterministic writer가 산출한 review item도 1개다. LLM이 evidence ref 4개를 finding 4개로 잘못 계수한 것으로 보인다.
이 결함도 gate audit schema를 LLM 자유 생성에 맡기면 안 된다는 근거다.
## 5. 두 gate의 작업별 필요성 판정
### 5.1 B1 gate
| 현재 작업 | 필요한가 | 최적 실행유형 | 판단 |
|---|---|---|---|
| part completeness/stale 검사 | 필수 | Python | 파일 set과 expected ID 비교 |
| `E-{ordinal:03d}` 형식·순서 검사 | 필수 | Python | regex와 ordinal equality |
| canonical ID 확정·정렬·병합 | 필수 | Python | stable sort와 pure transform |
| final envelope/alias 생성 | 필수 | Python | serialization 작업 |
| exact duplicate 판정 | 필수 | Python | `doc_uid`, planner content hash, normalized title |
| suspected alias 판정 | 조건부 | exception LLM | hash는 다르지만 title/fact fingerprint가 유사한 pair만 |
| component coverage | 필수 | 우선 Python | semantic flag별 required field 존재 검사 |
| component 의미가 모호한 경우 | 조건부 | exception LLM | 해당 item과 짧은 source excerpt만 |
| clear authority drift | 필수 | 구조적 차단/Python | source ordinal/hash/allowlist 위반 |
| ambiguous authority drift | 조건부 | exception LLM | 의심 part와 해당 shard만 제공 |
| severity·audit count 계산 | 필수 | Python | enum priority와 array length |
결론적으로 B1의 5개 check 중 1, 2와 final writing은 완전한 deterministic 작업이다. 3, 4, 5도 먼저 Python으로 candidate/exception을 좁힐 수 있다. 모든 30개 part, `evidence_all.json`, meeting 전체를 매 실행마다 LLM에 다시 읽힐 필요가 없다.
authority drift를 품질 저하 없이 경량화하려면 다음 중 하나를 함께 적용한다.
1. B1 mapper의 localdocs read를 assigned shard와 명시된 meeting slice로 tool-level allowlist하여 다른 evidence 접근을 구조적으로 금지한다.
2. B1 part에 additive `source_support_manifest`를 두어 주요 field group의 source locator·source hash·unsupported field path를 남긴다.
3. Python reducer는 ordinal/hash/locator 불일치가 있는 part만 exception으로 올린다.
tool isolation이 확실하다면 전역 raw 재독해를 통한 authority drift LLM 검사는 상시 작업이 아니라 표본 감사 또는 예외 작업으로 낮출 수 있다.
### 5.2 B2 gate
| 현재 작업 | 필요한가 | 최적 실행유형 | 판단 |
|---|---|---|---|
| part schema invariant | 필수 | Python | 현재 규칙 전부 구조 검사 |
| event part completeness | 필수 | Python | expected ID set equality |
| evidence reference integrity | 필수 | Python | compact finalized ID set membership |
| candidate ID format/uniqueness | 필수 | Python | regex/set 검사 |
| exact `identity_signature` collision | 필수 | Python | group-by로 탐지 |
| final ID 확정·정렬·병합 | 필수 | Python | 보존성 invariant 포함 |
| 날짜 형식·명시적 chain ordering | 필수 | Python | 같은 group key의 parseable date 비교 |
| 관계 group이 불명확한 chronology | 조건부 | exception LLM | 해당 chain만 micro-pack으로 제공 |
| named event coverage | 필수 | 우선 Python | semantic flag/component와 subkind set의 rule table |
| 문서 의미가 불명확한 coverage | 조건부 | exception LLM | 해당 evidence 1건만 제공 |
| audit severity/count/source ref | 필수 | Python | 자유 생성 금지 |
B2의 schema invariant, completeness, reference, candidate ID, serialization은 LLM에서 삭제해야 한다. chronological ordering과 legal-effect event coverage 자체는 삭제하면 안 되지만, **정형 규칙은 Python**, 의미론적 예외만 LLM으로 분리해야 한다.
cross-document duplicate를 처리할 때 source item 전체를 삭제해서는 안 된다. 최소 보존 invariant는 다음과 같다.
```text
set(final.items[*].evidence_index) == set(planner.expected_evidence_ids)
len(final.items) == planner.shard_count
모든 input part는 final item 또는 명시적 BLOCK finding에 정확히 1회 대응
```
candidate를 dedup하더라도 source evidence item과 provenance는 남겨야 한다. 현재 schema가 “모든 candidate가 dedup된 item”을 표현할 수 없다면 Stage 1에서는 후보를 보존하고, semantic merge는 Stage 2로 미루는 편이 안전하다.
## 6. Downstream 연계성과 삭제 안전성
| 파일/기능 | 직접 소비자 | 삭제 가능 여부 | 개정 원칙 |
|---|---|---|---|
| `evidence_indexed.json` | Part 2 Stage A, Part 3 LES0, Part 4 FL0 | 삭제 불가 | final schema 유지 |
| `evidence_event_candidates.json` | Part 2 Stage A, Part 3 LES0, Part 4 FL0 | 삭제 불가 | 1:1 evidence 보존 invariant 추가 |
| `B1_evidence_indexed_gate.json` | Part 1 handoff writer | 파일은 유지 권장 | Python이 생성한 compact audit로 대체 |
| `B2_event_candidates_gate.json` | Part 1 handoff writer | 파일은 유지 권장 | named source refs와 deterministic count 강제 |
| `stage1_part1_soft_gate_handoff.json` | Part 2 Stage A | 삭제 불가 | digest + review queue 계약 유지 |
| full `evidence_all.json` B1 gate read | B1 gate 내부 | 상시 read 삭제 가능 | exception item에 해당 shard만 읽기 |
| full `client_meeting.md` B1 gate read | B1 gate 내부 | 삭제 가능 | mapper/source manifest에서 필요한 alias cue만 전달 |
| full `evidence_indexed.json` B2 gate read | B2 gate 내부 | 삭제 가능 | `finalized_evidence_id_set` compact manifest 사용 |
| B1 audit의 B2 LLM import | B2 gate 내부 | 삭제 가능 | 최종 deterministic handoff writer가 통합 |
| LLM의 merge/serialization/count | 두 gate 내부 | 삭제해야 함 | Python single writer로 전환 |
| chronology/coverage 검증 자체 | B2 gate 내부 | 삭제 불가 | rule engine + exception adjudication |
Part 2~4는 task name이 아니라 final file contract를 소비한다. 따라서 gate 내부 구현을 Python으로 바꾸거나 B1/B2 exception adjudication을 합쳐도, 세 final JSON과 sidecar의 schema를 유지하면 downstream DAG는 변경할 필요가 없다.
`evidence_indexed.json`의 duplicate alias는 v.6 내부 parser들이 `items`를 우선 사용하므로 내부적으로는 제거 가능성이 높다. 다만 외부 Stage 2 또는 구버전 소비자 호환성 검증 없이 바로 제거하는 것은 권하지 않는다. 1차 개정에서는 final alias를 유지하되 **B2 gate 입력으로 full file을 사용하지 않는 것**만으로도 token 중복을 제거한다.
## 7. 권고 개정안: 최소 변경, 최대 효과
### 7.1 설계 원칙
```text
deterministic by default
|
+-- hard mechanical failure -> BLOCK, LLM 호출 없음
|
+-- no semantic exception -> final write, LLM 호출 없음
|
+-- semantic exception only -> compact micro-pack -> LLM adjudication
```
### 7.2 기존 task를 최대한 재사용하는 개정
#### A. `Task_B1_quality_gate_evidence_indexed`
실행유형을 LLM에서 `code-executor/Python`으로 변경한다.
입력:
- compact gate manifest
- `evidence_indexed_parts/E-*.json`
- 필요 시에만 해당 `evidence_shards/E-xxx.json`
출력:
- `evidence_indexed.json`
- `stage1_tmp/quality_gate/B1_precheck.json`
- `stage1_tmp/quality_gate/B1_exception_items.json`
- `stage1_tmp/quality_gate/finalized_evidence_id_manifest.json`
Python이 수행할 일:
1. expected/received/stale set 비교
2. part 단일 item 및 schema 검사
3. ordinal·proposed ID·source pointer·content hash 검사
4. stable order로 모든 item 보존
5. final `evidence_index` 확정
6. exact duplicate 및 component coverage rule 검사
7. ambiguous pair/item만 exception 생성
8. final JSON serialization
#### B. `Task_B2_quality_gate_event_candidates`
실행유형을 LLM에서 `code-executor/Python`으로 변경한다.
입력:
- compact gate manifest
- `evidence_event_candidate_parts/E-*.json`
- `finalized_evidence_id_manifest.json`
- `B1_exception_items.json`
제거할 입력:
- full `evidence_indexed.json`
- full `B1_evidence_indexed_gate.json`
- duplicate-heavy full planner object
출력:
- `evidence_event_candidates.json`
- `stage1_tmp/quality_gate/B2_precheck.json`
- `stage1_tmp/quality_gate/B12_exception_pack.json`
Python이 수행할 일:
1. expected/received/stale set 비교
2. 모든 part item의 invariant 검사
3. candidate ID/reference/signature/date parsing 검사
4. stable merge와 candidate ID 확정
5. final evidence item set equality를 write 전·후 모두 검사
6. rule-table chronology/coverage 검사
7. B1/B2 semantic exception만 bounded micro-pack으로 생성
8. final JSON serialization
#### C. `Task_B12_quality_exception_adjudicator_*` 신설
dynamic fan-out을 사용하여 exception cluster가 0개면 LLM task를 생성하지 않는다. exception이 있으면 cluster별 작은 pack만 제공한다.
권장 제한:
- 한 micro-pack당 evidence item 최대 2개
- event candidate 최대 8개
- source excerpt 최대 1,500자
- exception type은 하나만 포함
- full planner, full final JSON, full meeting, full evidence 금지
- 출력은 `exception_id`, `decision`, `severity`, `source_refs`, `concise_basis`만 허용
LLM 설정:
```yaml
llm_provider: google
llm_model: gemini-3.1-flash-lite
llm_reasoning: medium
llm_verbosity: low
```
다음 경우에만 `reasoning=high` escalation을 허용한다.
- 서로 다른 source가 같은 법률행위의 날짜·당사자·목적물을 실질적으로 충돌하게 표시
- authority drift 여부가 source trace의 유효성을 좌우
- chronology 판단 결과에 따라 hard block 여부가 달라짐
#### D. `Task_B2_SHA256_soft_gate_handoff_writer` 확장
기존 Python writer에 다음 책임을 추가한다.
1. B1/B2 precheck와 exception decision 병합
2. `quality_gates/B1_evidence_indexed_gate.json` 단일 작성
3. `quality_gates/B2_event_candidates_gate.json` 단일 작성
4. 모든 count를 실제 array length에서 계산
5. `source_refs` named object 강제
6. final file conservation invariant 재검증
7. 기존 SHA256 digest와 soft-gate handoff 작성
이렇게 하면 gate audit과 handoff를 동일한 deterministic writer가 생성하여 현재의 count·source-ref 불일치를 차단할 수 있다.
## 8. 개정 DAG
```text
Task_Evidence_shard_planner
|
v
B1_map_doc_* ------------------------------+
| same ordinal |
v |
B2_map_events_* |
| |
| all B2 parts all B1 parts
| v
| B1 deterministic reducer
| - evidence_indexed final
| - B1 precheck/exceptions
| - evidence ID manifest
| |
+----------------------------------+
|
v
B2 deterministic reducer
- event final
- conservation gate
- B12 exception pack
|
+----------+-----------+
| exception_count = 0 | exception_count > 0
v v
empty decision file B12 exception LLM fan-out
| |
+----------+-----------+
v
deterministic final audit + SHA256 handoff writer
|
v
OUT
```
이 개정은 동일 ordinal B1→B2 streaming을 보존한다. Part 2~4가 보는 final file name과 schema도 보존한다.
## 9. 모델 경량화 판단
두 기존 gate는 이미 flash-lite 계열을 사용하므로 단순 모델 하향의 기대효과는 제한적이다. 더 중요한 사실은 high reasoning 모델이 필요 없는 작업을 아예 LLM에 주고 있다는 점이다.
| 작업군 | 권장 실행 |
|---|---|
| file completeness, schema, regex, set equality, sort, merge, digest, count | Python only |
| exact hash/signature duplicate | Python only |
| explicit date chain with relation key | Python only |
| ambiguous alias/authority/chronology/coverage | flash-lite, medium reasoning, low verbosity |
| hard legal ambiguity 중 source trace에 중대한 영향 | 동일 모델 high reasoning으로 제한 escalation |
즉 모델을 일괄 하향하지 말고, **정상 사례의 LLM 호출 수를 2회에서 0회로 만드는 것**이 우선이다.
## 10. 즉시 적용할 핫픽스
최적화 리팩터링 전이라도 다음 항목은 즉시 보강해야 한다.
1. B2 write 전 `expected_evidence_ids == final evidence IDs` set equality를 검사한다.
2. `len(final.items) == planner.shard_count`를 강제한다.
3. `sum(input part candidate count)`와 `sum(final candidate count) + explicit dedup count`가 일치해야 한다.
4. dedup group이 없는데 candidate 수가 줄면 `BLOCK`한다.
5. `review_gate_summary.review_gate_count`는 `len(review_findings)`로만 계산한다.
6. `source_refs`가 named object가 아니면 schema failure로 처리한다.
7. handoff writer는 review item의 source ref가 모두 비어 있는데 원 gate finding에 ref 문자열이 있으면 조용히 통과시키지 말고 `HANDOFF_SOURCE_REF_SHAPE_INVALID`를 기록한다.
이 7개는 모두 Python으로 구현해야 한다.
## 11. 삭제·유지 최종 판정
### 삭제 또는 정상 경로에서 제거
- B1/B2 full-context LLM merge 및 JSON writer 역할
- B1 gate의 full `client_meeting.md` 재독해
- B1 gate의 full `evidence_all.json` 상시 재독해
- B2 gate의 full `evidence_indexed.json` 재독해
- B2 gate의 B1 audit import
- LLM이 만드는 count, timestamp, ID sequence, schema envelope, severity aggregate
- exact duplicate·regex·set equality를 위한 LLM 추론
### 반드시 유지
- B1/B2 logical gate 자체
- final evidence/event authority file
- completeness, provenance, schema, reference integrity
- chronology와 legal-effect coverage의 검증 목적
- hard/review gate 분리
- SHA256 handoff와 Part 2 blocking contract
- 동일 ordinal mapper streaming
### 예외 시에만 유지
- suspected alias adjudication
- ambiguous authority drift
- relation key가 불명확한 chronology
- 문서 의미 해석이 필요한 event coverage
## 12. 검증 및 성능 측정 기준
### 12.1 품질 acceptance gate
```text
final evidence item count == expected shard count
final event item count == expected shard count
final evidence ID set == planner expected ID set
every candidate source_evidence_index in finalized evidence ID set
input candidate count == final candidate count + explicitly audited dedup count
every review item has schema-valid named source_refs
audit summary counts == actual array lengths
no downstream file name/schema regression
```
현재 7월 10일 fixture를 회귀시험으로 사용하면 최소 기대값은 다음과 같다.
```text
evidence_indexed items: 30
evidence_event_candidates items: 30
input event candidates: 74
E-019 retained: true
E-019 candidate count: 3
exact duplicate identity_signature groups: 0
```
### 12.2 성능 계측
다음 sub-task별 telemetry를 추가해야 실제 개선효과를 판단할 수 있다.
- wall time
- provider/model
- input/output token
- localdocs read bytes 및 파일 수
- exception count
- LLM call count
- cache hit 여부
- final artifact bytes
- deterministic validation duration
목표 KPI는 특정 초 단위 예측보다 다음 비율로 두는 것이 안전하다.
- 정상 사례 B1/B2 quality gate LLM 호출: 2 → 0
- exception 사례 LLM 입력: full global input이 아니라 해당 exception micro-pack만
- B2 gate read volume: 308KB 이상의 full fan-in → B2 parts + compact manifest 중심
- final 보존성 오류: 0
- audit count/source ref schema 오류: 0
## 13. 최종 권고
우선순위는 다음과 같다.
1. `E-019`와 같은 item 소실을 차단하는 conservation hotfix를 먼저 적용한다.
2. B1/B2 gate의 merge·validation·audit aggregation을 Python으로 이전한다.
3. planner와 B1 final 대신 compact gate manifest를 gate 입력으로 사용한다.
4. B1/B2의 의미론적 예외를 하나의 bounded exception pipeline으로 합친다.
5. exception이 0이면 LLM task를 spawn하지 않는다.
6. Part 1 sub-task별 runtime/token/read-byte telemetry를 추가한 뒤 v.6 fixture로 A/B 실행한다.
두 gate를 통째로 삭제하는 것은 부적절하다. 반대로 현 상태처럼 모든 기계적 검증과 final writing을 high-reasoning LLM에 유지하는 것도 비용·속도·정확성 측면에서 정당화되지 않는다. 가장 안전하고 효율적인 개정은 **gate 책임은 유지하되 정상 경로는 deterministic하게 만들고, 법률적 모호성만 작게 잘라 LLM으로 보내는 것**이다.
@@ -0,0 +1,187 @@
# Stage 1 Part 2 개선 전략 보고서 — 두 비효율 리포트 비교 분석 (Claude v1)
- 비교 대상 문서:
- `Part_2_Inefficiency_Report_Claude_v1.md` (이하 **Claude 리포트**)
- `Part_2_Inefficiency_Report_Codex_v1.md` (이하 **Codex 리포트**)
- 분석 대상: `Stage_1_Part_2_v2.yml` (7,462행, **20개 task** = Python 14 + LLM 6) — Task_C_BO 파이프라인
- 선별 기준: **최소의 노력**(LLM 추론은 꼭 필요한 곳에만 필요한 수준으로, 100% 결정적 작업은 Python 코드화, 토큰 경제성 최대화)으로 **최대의 효과**(최고 품질 유지, 토큰 경제성 증대, 에이전트 속도 최대화)
- 집중 비교 항목(how_to_read): ① 비효율 판정 항목 ② 실행구조·병목 지점 ③ 삭제/축소 안전성(하류 연계 근거) ④ 권장 개정 전략
---
## 0. 결론 요약
1. 두 리포트는 Part 2의 성격 진단에서 완전히 일치한다: **구조(결정적 컴파일 + 도메인별 국소 LLM)는 이미 올바르며, 비효율은 LLM 호출의 입력·출력·모델이 전부 최대치로 설정된 것과 전후 Python task의 과잉 분할에 있다.** 두 리포트가 독립적으로 수렴한 4대 축 — ⓐ PostB_2 예외 판정기의 입력 증폭·상시 실행, ⓑ 워커 출력의 null/스캐폴드 낭비, ⓒ pro/high 일괄 배정, ⓓ Python task 통합 여지 — 는 그대로 개정 확정 항목으로 채택한다.
2. 계측의 정밀도는 Codex 리포트가 우위다: exception pack 재계산(6건, 18KB vs full 130KB = **7.16배 증폭**), sparse 환산 실측(candidate **35% 감소** + envelope 25.3%), 도메인 라우팅 중복 배수(event 2.56×, evidence 2.80×), **task 계수 20개(정확)**. Claude 리포트의 task 계수 "17개"는 오기이며 본 보고서에서 **20개로 교정**한다(원본 grep 재확인 완료). 반면 Claude 리포트는 prefix SHA 실측(워커 5개 동일·adjudicator 상이), domain_payload의 하류 `.get()` 소비 실증(null 생략 안전성의 직접 근거), publisher strict parser ↔ pro 재호출 결합 위험(F-9) 등 Codex에 없는 근거를 보탠다.
3. 가장 중요한 전략적 진전은 Codex의 **"결정적 defer 정책"**이다. Claude 리포트의 R-1은 "빈 pack이면 즉시 종료"까지였으나, Codex §7.8은 near-duplicate(`KEEP_SEPARATE`+cluster id), meeting-only(`MEETING_ONLY_EVIDENCE_GAP` warning), PriorAct 불명(null+review code) 등을 **결정적 정책으로 처리해 pack 자체를 비운다** — 7/10 fixture의 예외 6건 전원이 이 정책으로 처리 가능하므로 **fixture 기준 PostB LLM 호출 목표 0회**가 성립한다. 이를 채택하되, 실행 골격은 Part 1 v3에서 검증한 GB 패턴(정적 task + 빈 pack 즉시 종료)으로 구현해 런타임 조건부 스폰 불확실성을 피한다.
4. 상충 지점 중 가장 중대한 것은 **모델 배치**다: B3 하향(양측 합의)과 B4/B5 pro 유지(양측 합의)는 확정하되, **B1은 Claude가 유지·Codex가 하향, B2는 Claude가 하향 후보·Codex가 유지로 정반대 판정**을 냈다. 두 독립 분석이 상반된 도메인은 불확실성이 크다는 신호이므로, 1차 개정에서는 B1·B2 모두 pro를 유지하고 fixture A/B 실측으로만 하향을 결정한다(품질 우선 원칙).
5. 통합 권고안의 기대 효과(추정): 상시 pro/high 호출 6 → 3~5(A/B 결과에 따라), PostB LLM 입력 약 130KB → 0~18KB, 워커 출력 약 절반, task 20 → 9~10, 비용 $4.28 → **$2.50 이하 목표**, 런타임 7:40 → **5분 이내 목표**. 하류 계약 4파일(BO.json + signal 3종)의 경로·스키마는 완전 보존.
---
## 1. 공통 진단 — 합의 사항 (전부 채택)
두 리포트가 독립적으로 일치한 항목. 교차 검증 완료로 간주하고 개정의 확정 전제로 삼는다.
| # | 합의 내용 | Claude 근거 | Codex 근거 |
|---|---|---|---|
| C-1 | **하류 계약 4파일 불변** — `BO.json`(bh# 유일성·provenance·domain_payload 포함), signal 3종(schema_version·status·배열 키). Part 2 중간 산출물(seed 파일, publisher/join/ledger/compiled stdout)은 Part 3/4 직접 입력이 아니므로 자유 통합 가능 | §5 (P3:5/8/7/6, P4:3/4/5/4개소 grep) | §2 (외부 불변식 표 + 중간 파일 비소비 확인) |
| C-2 | **PostB_2 = 최대 단일 비효율.** 필요 입력은 exception_pack뿐인데 PostB_1 stdout 전문을 pro/high에 주입(프롬프트 자체가 런타임 제약을 자인), 예외 0건이어도 상시 실행 | F-1 (5091~5092행 자인 문구, 추정 200KB+) | P0-2 (**재계산 실측: pack 18,124B vs full 129,772B = 7.16×**, 예외 6건) |
| C-3 | **워커 출력의 스캐폴드 낭비** — null/[]/{} default와 반복 envelope를 pro 출력 토큰으로 재생성. sparse 출력 + Python expander로 전환 | F-2 (domain_payload leaf 54% null/empty, transport_refs·slice_guard 각 ~10KB) | P1-3 + §4.3 (**sparse 환산: candidate 94,830→61,670B = 35%↓**, envelope 25.3%) |
| C-4 | **pro/high 일괄 배정은 과잉, 그러나 일괄 하향 금지** — 도메인 차등 배치 + verbosity low. B4(사해행위)·B5(상속·통지·유치권)는 pro 유지, B3(토지·가액)는 하향 후보 | F-3, §3 판정표 | P0-1, §7.6 배치표 |
| C-5 | **B0→워커 5×5 barrier 불필요** — 각 워커는 자기 slice만 소비 → one-to-one edge | F-6 | P1-1 |
| C-6 | **publisher + domain_join + PostB_1 → 단일 결정적 reducer** (write→re-read 왕복 제거 포함) | F-5, R-4 | P1-4, §7.7 R0 |
| C-7 | **PostB_3 + PostB_4 → 단일 compile+gate+writer** | R-4 | §7.10 F0 |
| C-8 | **Middle ×3 → 단일 signal writer** (BO 1회 read로 3파일 생성, 기존 3파일·스키마 유지) | F-5, R-4 | P1-5, §7.11 S0 |
| C-9 | **Stage A context의 반복 주입** (Claude: 12개 task 실측 / Codex: 구조적 data amplification 판정) → 파일화 + compact manifest stdout | F-8 | P0-3, §7.3 |
| C-10 | **adjudicator의 COMMON_CACHE_PREFIX 불일치** — 워커 5개는 바이트 동일, adjudicator만 커스텀 → canonical prefix로 통일 | F-7 (SHA 실측 `adbdf43c…` vs `7207d2da…`) | P2-1 |
| C-11 | **이번 실행에서 adjudicator 실효 0** — seed 50 → BO 50, merge/drop 0 (LLM 판정이 아무것도 바꾸지 않음) | §1.2 | §4.5 (1:1 대응 + core 값 불변 대조) |
| C-12 | **도메인 5분할 자체는 유지** — 단일 거대 LLM 호출로의 통합은 prompt 비대화·실패 blast radius 확대로 금지 | §5 (품질 장치 유지 판정) | §10 |
| C-13 | Reason/PriorAct 품질 결함 — Reason 50건 동일 boilerplate, PriorAct 50/50 null (finalization 선언 대비 미이행) | §1.3-4 (F-9) | §4.5 |
---
## 2. 각 리포트의 고유 기여 — 통합안에 반영
### 2.1 Codex 리포트 고유 기여 (채택)
| # | 내용 | 반영처 |
|---|---|---|
| X-1 | **라우팅 중복 실측과 3등급 라우팅** (§4.2, §7.4): B2·B5가 event/evidence universe 전체를 재적재(중복 배수 event 2.56×·evidence 2.80×·meeting 2.05×). broad keyword 대신 event_subkind·doc_type·named component 우선, `primary/support/review_only` 3등급으로 slice 구성(primary만 full record), `ROUTING_BROADNESS_WARNING` 기록. **워커 입력 측 다이어트의 핵심** — Claude 리포트는 출력 측만 계측했다 | §4 R-2(입력), A0 계약 |
| X-2 | **결정적 defer 정책** (§7.8): exact dup은 provenance union 무손실일 때만 merge, near-dup은 `KEEP_SEPARATE`+cluster id, meeting-only는 warning 보존, Stage 2 법리 필요건은 `legal_theory_required`로 LLM 호출 금지, universe 밖 ref는 BLOCK. fixture 예외 6건 전원 결정적 처리 → **PostB LLM 0회 목표의 근거** | §4 R-1 |
| X-3 | **조건부 판정의 4중 발동 조건** (§7.9): ①writer가 단일 값 선택 필수 ②source-backed 후보 2개 이상 ③보존·defer 불가 ④compact payload로 충분 — 전부 충족 시에만 LLM. "판정 남발 방지"의 명문 기준 | §4 R-1 |
| X-4 | **품질 결함 추가 발견** (§4.5): source evidence가 빈 BO 2건(meeting-only assertion의 BO화 — 4억원 변제 관련), **13개 domain review가 BO·signal 어디에도 구조적으로 전달되지 않음**(비싼 pro 출력이 하류 미소비) | §4 R-6 (review handoff 신설) |
| X-5 | **review compact handoff 계약** (P1-6): review_id·severity·closed-enum issue_type·source refs 3종·downstream_owner만 구조 보존, 긴 서술은 LLM이 쓰지 않음 → `quality_gates/stage1_part2_review_handoff.json` 신설 | §4 R-6 |
| X-6 | **Stage A + B0 ×5 → A0 통합 compiler** (§7.3): slice를 파일로 저장하고 stdout에는 경로 manifest만. B0 코드 5중 복제(P1-2: 1,162행/79KB) 제거와 Stage A 반복 주입(C-9) 근본 해소를 겸함 | §4 R-3 (조건부 채택 — §3 D-2) |
| X-7 | Reason/PriorAct 생성 정책 (§7.10): 고정 enum/짧은 template, 명시적 prior link 존재 시에만 PriorAct/ReasonRefs 기입, Stage 1의 법적 인과 확정 금지 | §4 R-5 |
| X-8 | Stage-level 미사용 기본 모델(`openai/gpt-4o-2024-08-06`) 선언 삭제 (P2-2) | §4 R-7 |
| X-9 | **검증 불변식의 정밀화** (§9.2): BO 50건을 절대 불변식으로 두지 않되 candidate conservation·provenance union 위반 감소 금지, B4 actio·B5 notice/lien named fields 무손실, 13개 review 보존, meeting-only BO 2건 자동 삭제 금지, LES0/FL0 smoke test | §6 검증 계획 |
| X-10 | **task 계수 교정**: 정확한 현재 task 수는 20(Python 14 + LLM 6)이며 Claude 리포트의 17은 오기 (원본 재grep으로 확정) | 본 문서 전체 |
### 2.2 Claude 리포트 고유 기여 (채택)
| # | 내용 | 반영처 |
|---|---|---|
| Y-1 | **null 생략의 하류 안전성 실증**: Part 3 `_domain_payload()`(304~308행), Part 4 `domain_payload_compact`(312~314행)가 `.get()` 접근으로 compact 소비 → sparse 출력 계약(C-3)이 하류 무영향임을 grep으로 입증. Codex 리포트에는 이 안전성 근거가 없다 | §4 R-2의 안전 근거 |
| Y-2 | **prefix SHA 실측**: 워커 5개 `adbdf43c…` 바이트 동일(stripped 내용은 Part 1 canonical `6e01f72f…`와 동일), adjudicator `7207d2da…` 상이 — C-10의 정량 근거이자 통일 시 회귀 기준값 | §4 R-1/R-7 |
| Y-3 | **publisher strict parser ↔ pro 재호출 결합 위험** (F-9): `OUTPUT_SURFACE_HARD_RULE` 위반 1회가 max_iterations=2의 pro 전체 재호출을 유발할 수 있음 → SKILL.md §6.7 관용 파서(결정적 fence salvage)를 R0 파싱에 적용. Codex 미포착 | §4 R-4 |
| Y-4 | **BO 내부 중복의 정량 실측**: `BO_ID==id` 50/50, `EvidenceTitles==Evidence[*].source_title` 49/50, `core_field_base.amount==amount.value` 50/50 — 단 스키마 계약이므로 Stage 2 소비 확정 전 삭제 금지(Part 1 alias 판정과 동일한 조건부 처리) | §4 R-5 비고 |
| Y-5 | **Part 1 v3와의 패턴 일관성 논거**: PostB_2 개정을 Part 1 v3 GB(정적 task + pack 파일 + 빈 pack 즉시 종료 + flash-lite)와 동일 골격으로 구현하면 파이프라인 전체의 예외 처리 패턴이 단일화되어 유지보수 비용이 준다 | §4 R-1 실행 방식 |
---
## 3. 상충 지점 판정
### D-1. 워커 모델 배치 — **합의 도메인만 확정, 상반 도메인은 pro 유지 + A/B**
| 도메인 | Claude 판정 | Codex 판정 | 본 보고서 확정 |
|---|---|---|---|
| B1 금전채권·상호속용 | **pro 유지** (청구원인 구조의 법률 추론 실질) | **Flash 하향** (provisional seed, 최종 법리 아님) | **1차 pro 유지 + fixture A/B** |
| B2 담보·등기 | flash A/B 후보 (등기 row 추출 성격) | **pro 유지** (지분·담보·변제충당 chain의 높은 오류비용) | **1차 pro 유지 + fixture A/B** |
| B3 토지·가액 | flash A/B 후보 | Flash 하향 (medium) | **A/B 통과 시 Flash 확정** (양측 합의 유일 도메인) |
| B4 사해행위 | pro 유지 | pro 유지 | **pro 유지 확정** |
| B5 상속·통지·유치권·항변 | pro 유지 (+2분할 검토) | pro 유지 | **pro 유지 확정** |
판정 근거: 서로 독립인 두 분석이 B1·B2에서 **정반대 결론**을 냈다는 사실 자체가 해당 도메인의 난이도 판단이 표면 신호만으로 확정될 수 없음을 보여준다. 선별 기준의 "최고 품질 유지"가 우선하므로, 상반 판정 도메인의 하향은 전부 fixture A/B 실측(§6-3)을 통과한 경우로 한정한다. 하향 대상 모델명(Codex 표기 `gemini-3.5-flash`)은 실행 환경의 가용 모델 목록 확인 후 확정하며, 미가용 시 flash-preview/flash-lite 계열로 대체한다. verbosity는 5개 전부 low로 즉시 변경(합의).
### D-2. Stage A + B0 ×5 통합 — **Codex A0안을 조건부 채택 (채널 검증 후), 실패 시 Claude 최소안**
- Claude: 워커 입력 채널이 stdout 템플릿(중첩 필드 접근 불가 런타임 제약)이므로 B0 5분리는 정당 → edge만 1:1 수정.
- Codex: A0 1개로 통합, slice 5개를 **파일**로 저장, stdout에는 경로 manifest만.
- **판정**: Codex안이 우월하다 — task 6→1, B0 코드 5중 복제 제거(X-6), Stage A 반복 주입 근본 해소(C-9)를 동시에 달성하며, 파일화된 slice는 워커의 `preflight_files` 정적 경로로 주입 가능해 중첩 접근 제약을 우회한다. 단 **워커 입력 채널이 템플릿→preflight 인라인으로 바뀌는 것은 실행 방식 변화**이므로, 소형 테스트(slice 파일 1개를 preflight_files로 받는 워커 1개 실행)로 채널 안정성을 확인한 후 적용한다. 검증 실패 시 fallback: Claude 최소안(B0 5개 유지 + 공통 코드 config table화 + edge 1:1)으로도 X-7·C-5는 해소된다.
### D-3. PostB LLM의 목표 수준 — **정책은 Codex, 실행 골격은 Claude(Part 1 v3 GB)**
- Claude: pack 파일 + flash-lite + 빈 pack 즉시 종료 (호출 자체는 스케줄됨).
- Codex: 결정적 defer 정책으로 pack을 비워 fixture 기준 **0회**, non-deferrable만 조건부 실행.
- **판정**: 융합한다. pack 생성 정책은 Codex §7.8(결정적 defer 표)을 채택해 pack이 실질적으로 비워지게 하고, 실행 골격은 Part 1 v3 GB와 동일한 **정적 task + 빈 pack 즉시 종료**로 구현한다(0-instance 조건부 스폰의 런타임 불확실성 회피 — Part 1 개정 N-2와 동일 논거). 결과적으로 fixture 기준 LLM 실질 작동 0회(빈 pack 조기 종료의 잔여 비용은 소형 flash-lite 1회분)이며, 예외가 실재하는 사건에서만 X-3의 4중 조건을 통과한 항목이 판정된다.
### D-4. adjudicator 모델 — flash 계열 합의, **flash-lite로 통일**
Claude flash-lite(low~medium) vs Codex gemini-3.5-flash(medium). bounded selection + closed enum이라는 작업 성격 판정은 동일하다. Part 1 v3 GB가 flash-lite로 이미 확정되어 있으므로 파이프라인 일관성을 위해 flash-lite 계열로 통일하고, pack이 비지 않는 사건에서 판정 품질 문제가 관찰되면 flash로 상향한다.
### D-5. B5 2분할 (Claude 고유 제안) — **보류, Phase 2 이후 별도 실측**
Claude 리포트는 최장 워커 B5(19건/62.9KB)의 succession_notice / lien_asset_defense 2분할을 제안했으나 Codex는 제안하지 않았다. sparse 출력 계약(C-3)만으로 B5 출력이 ~40KB대로 줄어들 것으로 추정되므로, 1차 개정에서는 분할하지 않고 개정 후 실측에서 B5가 여전히 wall-clock 지배 항목일 때만 분할한다(도메인 수 증가는 라우팅·프롬프트 유지보수 비용을 동반).
---
## 4. 최종 권고안 (R-1 ~ R-7)
### 권고 DAG (Codex §7.1 기반 + D-2/D-3 판정 반영)
```text
IN
v
A0 context + domain-slice compiler [Python] ← Stage A + B0×5 통합 (D-2 조건부; fallback: B0 5개 유지+edge 1:1)
| 파일: stage_a_context / source_universe_manifest / domain_slices/B1~B5 (3등급 라우팅)
| stdout: 경로 manifest + digest만
+--> B1 [pro*] --+
+--> B2 [pro*] --+ * B1·B2는 A/B 후 결정, B3는 A/B 통과 시 flash,
+--> B3 [pro*] --+ B4·B5 pro 확정. 전원 verbosity low + sparse 출력 계약
+--> B4 [pro ] --+
+--> B5 [pro ] --+
v
R0 seed reducer + schema expander + exception planner [Python] ← publisher+domain_join+PostB_1 통합
| sparse→full 확장, 결정적 defer 정책(Codex §7.8), 관용 파서(Y-3)
| 파일: postb_seed_ledger / stage1_part2_exception_pack / stage1_part2_review_handoff
v
R1 exception adjudicator [flash-lite, 정적 task] ← pack 1파일만 read, 빈 pack 즉시 종료 (Part 1 v3 GB 골격)
v
F0 final BO compiler + gate + writer [Python] ← PostB_3+PostB_4 통합, Reason/PriorAct 정책(X-7)
v
S0 signal bundle writer [Python] ← Middle×3 통합, 기존 3파일·스키마 유지
v
OUT
```
| # | 권고 | 출처 판정 |
|---|---|---|
| R-1 | PostB_2 전환: 결정적 defer 정책(X-2) + 4중 발동 조건(X-3) + pack 파일 입력 + flash-lite + 빈 pack 즉시 종료 + canonical prefix 통일 | C-2, D-3, D-4, Y-2, Y-5 |
| R-2 | 워커 입출력 다이어트: 입력 = 3등급 라우팅 slice(X-1, primary만 full record), 출력 = sparse seed delta 계약(C-3, transport_refs·slice_guard 제거, null/빈값 미출력 — 하류 안전성 Y-1) + R0 expander, verbosity low | C-3, C-4, X-1, Y-1 |
| R-3 | A0 통합 compiler (조건부 D-2) — slice 파일화 + stdout manifest, B0 코드 config table화. 채널 검증 실패 시 fallback: B0 5개 유지 + edge 1:1(C-5)만 | X-6, C-9, C-5 |
| R-4 | Python task 통합: R0(=publisher+join+PostB_1, 관용 파서 포함), F0(=PostB_3+4), S0(=Middle×3) → task 20 → 9~10 | C-6, C-7, C-8, Y-3 |
| R-5 | Reason/PriorAct 정책(X-7): 고정 enum/짧은 template, prior link 실재 시에만 기입. BO 내부 중복 필드(Y-4)는 Stage 2 소비 grep 확정 전 유지 | C-13, X-7, Y-4 |
| R-6 | review compact handoff 신설(X-5): 13건 review의 issue_type·source refs·downstream_owner를 `quality_gates/stage1_part2_review_handoff.json`으로 구조 보존, LLM의 긴 서술 생성 금지 | X-4, X-5 |
| R-7 | 위생 항목: 모든 LLM task의 COMMON_CACHE_PREFIX 바이트 통일(role overlay는 prefix 밖), Stage-level 미사용 모델 선언 삭제(X-8) | C-10, Y-2, X-8 |
### 이행 순서
1. **Phase 1 (구조 무변경, 즉시)**: R-1 + edge 1:1(C-5) + verbosity low + R0 전신인 PostB_1에 defer 정책·pack 파일화만 선반영 + 관용 파서(Y-3) + R-7.
2. **Phase 2 (구조 통합, `Stage_1_Part_2_v3.yml`)**: R-2(sparse 계약) + R-3(A0, 채널 검증 후) + R-4(R0/F0/S0) + R-5 + R-6.
3. **Phase 3 (모델 A/B)**: B3 → flash 확정 시 반영, B1·B2는 A/B 결과로만 결정(D-1). B5 분할은 개정 후 실측에서 여전히 지배 항목일 때만(D-5).
---
## 5. 삭제·유지·조건부 최종 판정 (통합)
| 구분 | 항목 |
|---|---|
| **삭제 (정상 경로에서 제거)** | PostB_2의 full ledger 입력·상시 pro 실행 / 워커 출력의 transport_candidate_refs·slice_guard 에코·null 스캐폴드 / Stage A stdout의 12개소 원문 주입 / B0 코드 5중 복제(A0 채택 시) / 5×5 barrier / Stage-level 미사용 모델 선언 / LLM의 긴 review 서술 생성 |
| **유지 (변경 금지)** | BO.json·signal 3종의 경로·envelope·스키마(bh# 유일성, provenance, extensions.domain_payload 필드 자체) / 도메인 5분할과 워커의 법률 추론 역할 / Stage A universe 가드·PostB_4 게이트 의미론(F0로 계승) / BLOCK_REVIEW 라우팅 / meeting-only BO 2건(자동 삭제 금지, warning 보존) / BO 내부 중복 필드(Stage 2 소비 확정 전) |
| **조건부** | B1·B2·B3 모델 하향(fixture A/B 통과 시) / A0 통합(preflight 채널 검증 통과 시) / B5 2분할(개정 후에도 wall-clock 지배 시) / non-deferrable 예외의 LLM 판정(X-3 4중 조건 충족 시에만) |
---
## 6. 검증 계획 (fixture = Results_July_10_3_15pm)
1. **품질 불변식 (Codex §9.2 채택 + Claude 보강)**: source universe(evidence 30·event 71·meeting clause 41) 보존, 모든 BO source ref ⊂ Part 1 universe, 모든 candidate ref가 {최종 BO, provenance-union 병합, BLOCK/review}중 정확히 1곳으로 추적, B4 actio·B5 notice/lien/possession named fields 무손실, 13개 review의 issue_type·source refs가 review handoff에 보존, meeting-only BO 2건 보존, **candidate conservation: seed 후보 수 == BO 수 + 명시 병합 수 + 명시 BLOCK 수** (1차 구현 기준값: 50→50).
2. **sparse 왕복 검증 (Claude 방식)**: 7/10 seed 5종을 sparse로 축약 → R0 expander로 확장 → 원본과 **의미 동등**(false/0 등 유의미 값 보존, null/빈값만 복원) 확인 + 2-run 바이트 결정론.
3. **하류 무영향**: 개정 BO.json·signal 3종으로 Part 3 LES0·Part 4 FL0 파서 통과(특히 domain_payload null-생략본의 compact 소비).
4. **defer 정책 회귀**: fixture 예외 6건(schema risk 2, near-dup cluster 4)이 전부 결정적 처리되어 exception pack이 비고, R1이 즉시 종료함을 확인. 주입 테스트로 non-deferrable 예외(동일 사실에 상충하는 source-backed 값 2개)를 만들어 R1 발동 경로 확인.
5. **모델 A/B (D-1)**: 고정 slice 입력으로 B1/B2/B3의 pro vs flash 산출을 후보 수·source ref 집합·domain_review_queue 동등성 + 변호사 육안 대조로 판정.
6. **성능 합격 기준 (Codex §9.3 채택)**: task ≤10, PostB LLM 입력 ≤20KB(pack만), fixture PostB LLM 실질 0회, compact 도메인 출력 ≤70KB, 런타임 ≤5분, 비용 ≤$2.50 — 동일 조건 3회 중앙값, **품질 불변식 위반 시 성능 달성해도 실패**.
---
## 7. 채택하지 않은 권고와 사유
| 권고 | 출처 | 미채택/보류 사유 |
|---|---|---|
| B1 즉시 Flash 하향 | Codex §7.6 | Claude와 정반대 판정(청구원인 구조의 법률 추론 실질) — A/B 실측 전 하향 보류 (D-1) |
| B2 flash A/B 우선 후보 | Claude §3 | Codex와 정반대 판정(담보·변제충당 오류비용) — 동일하게 A/B로만 결정 (D-1) |
| B0 5개 유지 (템플릿 채널 전제) | Claude §2 | Codex A0안이 파일+preflight 채널로 제약을 우회하며 3중 효과(task·중복코드·주입) — 채널 검증 조건부로 A0 우선 (D-2) |
| 빈 pack에도 상시 LLM 스케줄만으로 충분 | Claude R-1 | Codex defer 정책이 pack 자체를 비워 한 단계 더 나감 — 정책 채택, 골격만 유지 (D-3) |
| B5 즉시 2분할 | Claude R-3 | sparse 계약의 출력 감소 효과를 먼저 실측 — 지배 항목 잔존 시에만 (D-5) |
| task 수 "17→10" 기준 계수 | Claude §6.6 | **오기 교정**: 정확한 계수는 20(Python 14+LLM 6) → 9~10 (X-10) |
| BO_ID==id 등 중복 필드 즉시 정리 | (양측 관찰) | 스키마 계약 — Stage 2 소비자 확정 전 변경 금지 (Part 1 alias 판정과 동일 원칙) |
@@ -0,0 +1,638 @@
# Stage 1 Part 2 통합 개정 전략
작성일: 2026-07-20
개정 대상: `Stage_1_Part_2_v2.yml`
비교 대상:
- `Part_2_Inefficiency_Report_Claude_v1.md`
- `Part_2_Inefficiency_Report_Codex_v1.md`
실측 기준: `Results_July_10_3_15pm`
## 0. 최종 판정
두 보고서의 핵심 진단은 일치한다. Part 2의 법률 도메인 분리 자체가 문제가 아니라, 그 앞뒤의 데이터 운반 방식과 모델 배치가 과도하다.
가장 효과가 큰 개정은 다음 네 가지다.
1. PostB LLM에 full seed ledger를 주입하지 않고, Python이 만든 compact exception pack만 동적 fan-out으로 전달한다.
2. 5개 domain worker는 유지하되 sparse seed delta만 출력하게 하고, schema default와 반복 metadata는 Python이 복원한다.
3. Stage A/B0 및 후속 Python chain을 compiler, reducer, final writer, signal writer의 네 task로 통합한다.
4. 법률 난도에 따라 모델을 차등 배치하되, 모델 하향은 fixture A/B와 법률 필드 불변식 통과 후 확정한다.
권장 target DAG는 상시 task 9개와 compact adjudication pack 수만큼의 동적 LLM task로 구성한다.
```text
상시 task = A0 1 + domain LLM 5 + R0 1 + F0 1 + S0 1 = 9
동적 task = R1 adjudicator pack N개
정상적인 no-exception 경로 = 9개
exception pack 1개 경로 = 10개
```
외부 계약인 `BO.json`, `actio_case_signals.json`, `case_liability_signals.json`, `legal_effect_signals.json`의 경로·envelope·필수 필드는 변경하지 않는다. 따라서 Part 3, Part 4 및 이후 Stage 2가 Part 2 내부 task 재편 때문에 깨져서는 안 된다.
질문의 method 2에 적힌 “Stage 2 작업의 효율성”은 전체 goal과 산출물명에 비추어 “Stage 1 Part 2를 효율화하면서 Stage 2 downstream 효율도 훼손하지 않는 것”으로 해석한다.
## 1. 비교의 신뢰 기준
### 1.1 live YAML로 확정한 사실
`Stage_1_Part_2_v2.yml`에는 실제로 20개 task가 있다.
| 구간 | task 수 | 실행 유형 |
|---|---:|---|
| Stage A normalization | 1 | Python |
| Stage B0 router | 5 | Python |
| Stage B domain worker | 5 | LLM |
| publisher + domain_join | 2 | Python |
| PostB | 4 | Python 3 + LLM 1 |
| signal writer | 3 | Python |
| 합계 | 20 | Python 14 + LLM 6 |
Claude 보고서의 “17개 task, code 11개”는 live YAML과 맞지 않는다. Codex 보고서의 “20개 task, Python 14개, LLM 6개”를 기준값으로 채택한다.
### 1.2 수치 차이의 해석
두 보고서의 worker output 크기 수치는 측정 표현이 다르므로 직접 충돌하지 않는다.
| 수치 | 의미 | 판정 |
|---|---|---|
| Claude: 206,681 bytes | 디스크에 저장된 pretty JSON 5개 파일의 합 | 실제 artifact 전송·저장 규모 파악에 유효 |
| Codex: 126,955 bytes | 같은 객체를 compact JSON으로 직렬화한 크기 | token surface와 구조별 중복 분석에 유효 |
| Codex: candidate 94,830 -> sparse 61,670 bytes | null·빈 값 제거 시 candidate 부분 감소량 | sparse output 설계 근거로 채택 |
PostB 입력도 마찬가지다. Claude의 약 200KB 이상은 raw/pretty representation 추정이고, Codex의 재계산값은 compact full object 129,772 bytes 대 compact exception pack 18,124 bytes다. 개정 효과 산정에는 같은 직렬화 조건을 사용한 `7.16x` 증폭값을 채택한다.
### 1.3 Part 1 기준 파일 차이
Claude 보고서는 `Stage_1_Part_1_Claude_v3.yml`, Codex 보고서는 `Stage_1_Part_1_Codex_v3.yml`을 참조했다. 현재 Part 2 개정에서는 최신 Part 1 기준을 `Stage_1_Part_1_Codex_v3.yml`로 둔다.
해당 파일은 다음 실행 패턴이 실제 YAML 문법으로 구현되어 있다.
```text
Python reducer
-> dynamic_fanout: []이면 adjudicator 0회
-> dynamic_fanout: [pack...]이면 adjudicator_* N회
-> deterministic finalizer가 all adjudicator_*를 대기
```
따라서 Part 2의 “예외가 없으면 LLM 0회”는 단순 아이디어가 아니라 현행 Liti-agent 명세에서 재사용 가능한 패턴이다.
## 2. 두 보고서의 공통 결론
### 2.1 비효율 판정
| 공통 판정 | 실측 또는 구조 근거 | 통합 전략 반영 |
|---|---|---|
| PostB_2 full-ledger 주입이 최대 단일 token 낭비 | compact exception만 필요하지만 seed 50건 전체 전달 | compact pack 전용 동적 adjudicator로 교체 |
| LLM 6개가 모두 Pro/high인 것은 과잉 | PostB는 bounded selection, 일부 worker는 provisional extraction/grouping | worker별 모델 차등화, PostB Flash-lite |
| worker output이 지나치게 큼 | null/empty scaffold, transport refs, slice guard 반복 | sparse delta 출력 + Python schema expander |
| B0 -> worker all-to-all wait가 불필요 | 각 worker는 자기 B0 slice만 소비 | 즉시 one-to-one edge 또는 A0 통합 |
| Python 후처리 chain이 잘게 쪼개짐 | write/re-read, full object 재직렬화, container/MCP 반복 | R0/F0/S0로 통합 |
| signal writer 3개가 동일 입력을 반복 소비 | BO와 upstream을 각 task가 다시 읽음 | 단일 S0가 기존 파일 3개 작성 |
| 5개 법률 domain을 한 거대 LLM으로 합치면 안 됨 | 도메인 법리·payload·failure boundary가 다름 | domain worker 5개 유지 |
| 외부 4개 산출물 계약은 불변이어야 함 | Part 3/4 직접 소비, Stage 2 handoff 연계 | 내부 구조만 변경, 외부 schema 회귀 검사 |
### 2.2 병목 위치
```text
현재 critical path
Stage A
-> B0 5개 전역 barrier
-> B1~B5 Pro/high 병렬 구간
-> publisher
-> domain_join
-> PostB_1
-> PostB_2 Pro/high + full ledger
-> PostB_3
-> PostB_4
-> signal writer 3개
```
병목 우선순위는 다음과 같다.
1. **P0:** PostB_2의 full-object 입력과 상시 Pro/high 호출
2. **P0:** worker 5개의 full schema 출력 및 반복 envelope
3. **P0:** 모든 domain에 동일한 최고 모델 배치
4. **P1:** publisher -> join -> ledger -> compiler -> writer 직렬 chain
5. **P1:** Stage A/B0 반복 parse와 5×5 대기 barrier
6. **P1:** signal writer 3개의 중복 입력·파일 read
7. **P2:** 좁은 common prefix와 adjudicator prefix 불일치
8. **P2:** 사용되지 않는 stage-level 기본 모델과 generic Reason prose
## 3. 차이점에 대한 채택 판정
### 3.1 Stage A와 B0의 통합
**Claude:** B0 분리는 nested stdout 접근 제약 때문에 정당하므로 유지하고 edge만 one-to-one으로 수정한다.
**Codex:** Stage A와 B0 5개를 A0 Python compiler 하나로 통합하여 artifact 5개를 쓴다.
**판정: Codex안을 최종 구조로 채택하되 Claude안을 hotfix로 사용한다.**
한 Python task가 domain slice 5개를 파일로 쓰고 각 worker가 자기 파일만 읽으면 nested stdout 제약을 우회할 수 있다. 현행 Part 1도 planner가 artifact와 `dynamic_fanout` descriptor를 함께 발행하는 방식을 사용하므로 실행 가능하다.
다만 개정 초기에는 다음 순서가 안전하다.
1. 먼저 B0 -> worker edge를 one-to-one으로 고쳐 전역 barrier를 제거한다.
2. 회귀 검사를 통과한 뒤 Stage A와 B0를 A0로 통합한다.
### 3.2 worker 모델 배치
**Claude:** B1/B4/B5는 Pro 유지, B2/B3만 Flash A/B 후보.
**Codex:** B1/B3는 Flash, B2/B4/B5는 Pro.
**판정: Codex의 target 배치를 채택하되 모든 하향은 A/B gate를 통과해야 한다.**
| Worker | target 모델 | 이유 | release 조건 |
|---|---|---|---|
| B1 Money/Successor | Flash, reasoning high | Stage 1 provisional grouping이며 최종 청구원인 법리 확정이 아님 | candidate/source/review 불변식 통과 전에는 Pro 유지 |
| B2 Secured/Registry | Pro, reasoning high | 지분, 담보, 등기 순위, 변제충당 chain의 오류비용이 높음 | 1차 개정에서 하향 금지 |
| B3 Land/Valuation | Flash, reasoning medium | 기간·점유·가액 source grouping 비중이 큼 | A/B 동등성 통과 |
| B4 Actio | Pro, reasoning high | 피보전채권, 무자력, 담보공제, 가액배상 구조 보존 필요 | Pro 유지 |
| B5 Succession/Notice/Lien/Asset/Defense | Pro, reasoning high | 상속, 통지, 유치권, possession two-track이 결합된 고위험 domain | Pro 유지 |
| R1 exception adjudicator | Flash-lite, reasoning medium | closed enum에 의한 compact exception 판정 | compact pack 외 입력 금지 |
Claude가 B2를 추출형으로 본 점은 일부 타당하나, 현재 B2 slice가 event/evidence universe 전체를 포함하고 registry·fraction·payment chain을 동시에 다룬다는 실측상 1차 하향은 위험하다. routing이 좁아지고 다수 fixture가 확보된 후 별도 A/B 대상으로 검토한다.
### 3.3 B5 분할
**Claude:** B5를 succession/notice와 lien/asset/defense로 분할하는 옵션을 제시한다.
**Codex:** B5를 유지하고 입력 narrowing과 sparse output을 우선한다.
**판정: 현재 개정에서는 B5 분할을 기각한다.**
이유:
- LLM 호출과 router surface가 각각 하나씩 늘어난다.
- succession은 notice sender·party standing과, notice는 lien extinction과 연결될 수 있어 완전히 독립적이지 않다.
- B5가 실제 wall-clock 최장 worker인지 확인할 task-level latency 로그가 없다.
- broad routing과 full schema 출력부터 제거하면 분할 없이도 입력·출력이 크게 감소한다.
B5 분할은 sparse/narrowing 이후에도 3회 실행 중앙값에서 B5가 worker 병렬 구간의 40% 이상을 차지할 때만 재검토한다.
### 3.4 PostB adjudicator의 존치 방식
**Claude:** task는 삭제하지 말고 compact pack + Flash-lite + empty pack 조기 종료로 경량화한다.
**Codex:** deterministic defer 규칙으로 대부분 처리하고 non-deferrable exception만 동적 LLM으로 보낸다.
**판정: 두 안을 결합한다. adjudication capability는 유지하되 상시 task는 제거한다.**
```text
R0 Python
|- auto-resolvable/deferable -> deterministic decision
|- non-deferrable -> dynamic_fanout pack
`- no pack -> R1 LLM 0회
R1 adjudicator_* N개
`- supplied values 중 closed decision만 반환
```
이는 “예외 판정 기능 삭제”가 아니다. 기능을 실제 예외가 있을 때만 생성되는 dynamic task로 바꾸는 것이다.
### 3.5 sparse output 적용 범위
**Claude:** Part 3/4가 `.get()`으로 소비하므로 null/empty key 생략이 안전하다고 본다.
**Codex:** LLM은 sparse delta만 출력하고 Python이 canonical schema를 복원한다.
**판정: Codex 경계를 채택한다.**
null/empty 생략은 **worker의 내부 중간 산출물에만** 적용한다. F0가 `BO.json`을 쓰기 전 현재 canonical schema와 default를 복원한다. 이 방식은 output token을 줄이면서 Stage 2의 미확인 consumer가 key 존재에 의존할 위험을 제거한다.
다음 값은 sparse 처리 시에도 제거하면 안 된다.
- `false`
- `0`
- 빈 문자열 자체가 명시적 source 값인 경우
- 명시적으로 확인된 `null`과 단순 미추출을 구별하는 schema field
- source provenance와 named legal-structure key
### 3.6 parser 관용화
Claude의 `parse_llm_json` deterministic salvage 제안은 채택한다. Markdown fence나 앞뒤 잡음 제거는 LLM 재호출 사유가 아니다.
단, 관용화는 syntax wrapper에만 적용한다.
- 허용: code fence 제거, 단일 JSON object 추출, UTF-8 BOM 제거
- 금지: 누락 사실 추정, enum 자동 의미변경, source ref 창작, candidate 자동 삭제
## 4. downstream 삭제·축소 안정성
### 4.1 반드시 보존할 외부 계약
| 파일 | 보존 항목 | 이유 |
|---|---|---|
| `BO.json` | 파일 경로, array envelope, 연속·유일 `bh#`, provenance, evidence, `extensions.domain_payload` | Part 3/4 및 이후 Stage 2의 핵심 사실·BO 입력 |
| `actio_case_signals.json` | schema version, status, `actio_case_signals[]` | 사해행위 structure routing |
| `case_liability_signals.json` | schema version, status, `case_liability_signals[]` | 책임·당사자 routing |
| `legal_effect_signals.json` | schema version, status, `bo_legal_effect_routes[]` | legal effect structure routing |
다음 법률 payload는 회귀 검사의 별도 보호 대상이다.
- B2: registry row, fraction, mortgage, payment allocation 관련 named 값
- B4: preserved claim, transfer, encumbrance, valuation, cap, defense
- B5: succession, notice lifecycle, lien state, possession two-track, asset alias, defense
### 4.2 내부에서 삭제·통합 가능한 것
| 현재 구조 | 개정 판정 | 안전 근거 |
|---|---|---|
| B0 task 5개 | A0로 통합 | worker별 slice artifact를 동일 의미로 생성 가능 |
| `transport_candidate_refs` LLM 출력 | 삭제 | provenance에서 Python이 무손실 재구성 가능 |
| full `slice_guard` LLM echo | 삭제 | A0 manifest/digest로 Python 검증 가능 |
| null/empty schema scaffold | LLM 출력에서 삭제 | R0/F0가 canonical default 복원 |
| publisher | R0에 통합 | 외부 consumer 없음, seed artifact write 유지 가능 |
| domain_join | R0에 통합 | 외부 consumer 없음, same-memory join 가능 |
| PostB_1 | R0에 통합 | ledger artifact와 exception pack을 R0가 생성 |
| PostB_3 + PostB_4 | F0로 통합 | 연속된 deterministic compile/gate/write |
| signal writer 3개 | S0로 통합 | BO를 한 번 읽고 기존 3개 파일 작성 가능 |
| generic `Reason` prose 생성 | fixed template/code로 축소 | 현 fixture 50건이 동일 boilerplate |
| stage-level 미사용 model | 삭제 | 모든 LLM task가 자체 provider/model 지정 |
### 4.3 삭제하거나 약화하면 안 되는 것
- 5개 domain별 법률 추론 경계
- candidate와 source provenance conservation
- source universe membership 검사
- Stage B seed 감사 artifact 자체
- exact duplicate의 provenance union 검사
- non-deferrable exception의 adjudication capability
- F0의 pre-write/post-write gate와 유일 writer 원칙
- meeting-only assertion 2건의 보존 및 evidence-gap warning
- 기존 13개 domain review의 issue type과 source refs
- Part 3 LES0 및 Part 4 FL0이 소비하는 외부 key
BO 수 50은 fixture 기준값이지 보편적 법칙은 아니다. 최종 안전성은 단순 count보다 다음 conservation 식으로 판단한다.
```text
모든 input candidate_ref
= final BO에 반영된 candidate_ref
+ 무손실 merge의 absorbed candidate_ref
+ BLOCK/blocked-review candidate_ref
```
## 5. 권장 개정 DAG
```text
IN
|
v
A0 Context + Domain Slice Compiler [Python]
| writes stage context, source manifest, B1~B5 slices
|
+--> B1 Money/Successor [Flash*]
+--> B2 Secured/Registry [Pro]
+--> B3 Land/Valuation [Flash*]
+--> B4 Actio [Pro]
+--> B5 Succession/Notice/Lien/Asset/Defense [Pro]
| * switch only after A/B acceptance
| \ | /
v v v v
R0 Seed Reducer + Schema Expander + Exception Planner [Python]
| writes seed ledger, review handoff, compact packs
|
+--> dynamic R1 Adjudicator_* [Flash-lite, 0..N]
| compact pack only
| closed decisions only
| /
v v
F0 Final BO Compiler + Gate + Single Writer [Python]
| writes BO.json once, rereads and audits
v
S0 Signal Bundle Writer [Python]
| writes the existing three signal files
v
OUT
```
## 6. task별 개정 명세
### 6.1 A0 Context + Domain Slice Compiler
입력:
- `client_meeting.md`
- `evidence_event_candidates.json`
- `evidence_indexed.json`
- `Default_Agent/Juristic_Act.md`
- `quality_gates/stage1_part1_soft_gate_handoff.json`
결정적 작업:
1. 현 Stage A와 동일한 source map, digest, acceptance gate를 생성한다.
2. 현 B0의 5개 domain config를 하나의 table로 옮긴다.
3. source를 `primary`, `support`, `review_only`로 분류한다.
4. primary에는 필요한 compact record를, support에는 ref와 최소 구조값을 넣는다.
5. broad keyword 단독 match는 primary 승격 사유로 사용하지 않는다.
6. B5의 activation reason을 succession, notice, lien, possession, asset, defense별로 기록한다.
7. 각 slice의 byte 수와 global universe 대비 비율을 기록한다.
권장 artifact:
```text
stage1_tmp/task_c_bo/stage_a_context.json
stage1_tmp/task_c_bo/source_universe_manifest.json
stage1_tmp/task_c_bo/domain_slices/B1.json
stage1_tmp/task_c_bo/domain_slices/B2.json
stage1_tmp/task_c_bo/domain_slices/B3.json
stage1_tmp/task_c_bo/domain_slices/B4.json
stage1_tmp/task_c_bo/domain_slices/B5.json
```
A0 stdout은 full context가 아니라 path, digest, count만 담은 manifest로 제한한다.
### 6.2 B1~B5 domain worker
각 worker는 자기 slice 하나만 읽는다. 다른 B0/B worker의 완료를 기다리지 않는다.
LLM output은 다음으로 제한한다.
- domain id와 status
- candidate ref
- BO classification과 짧은 Action
- exact source refs
- 실제 값이 채워진 domain payload delta
- closed enum review code와 해당 source refs
LLM이 출력하지 않을 항목:
- global source universe 재에코
- full `slice_guard`
- `transport_candidate_refs`
- 항상 null인 `Reason`, `PriorAct`, `ReasonRefs`
- schema를 맞추기 위한 빈 dict/list/null
- 긴 review prose
- Python이 계산 가능한 count, ordering, digest, ID
모든 worker의 `llm_verbosity`는 `low`로 한다. common cache prefix는 바이트 동일하게 두고, domain role/schema는 prefix 뒤 overlay로 둔다.
### 6.3 R0 Seed Reducer + Exception Planner
R0는 publisher, domain_join, PostB_1을 흡수한다.
작업 순서:
1. 5개 worker output을 strict parse한다.
2. fence/BOM 같은 wrapper만 deterministic salvage한다.
3. domain id와 source membership을 검사한다.
4. sparse delta를 canonical seed schema로 확장한다.
5. seed 5개 감사 artifact를 유지한다.
6. candidate/source index와 review code index를 만든다.
7. exact duplicate, near duplicate, schema risk, link ambiguity를 계산한다.
8. full seed ledger를 artifact로 저장한다.
9. deterministic exception policy를 적용한다.
10. non-deferrable 항목만 size-bounded pack으로 만들어 `dynamic_fanout`에 넣는다.
LLM에 보내지 않을 항목:
| 항목 | deterministic 처리 |
|---|---|
| exact duplicate | 모든 substantive field가 같고 provenance union이 무손실일 때만 merge |
| near duplicate | `KEEP_SEPARATE` + shared cluster id + review |
| meeting-only candidate | 보존 + `MEETING_ONLY_EVIDENCE_GAP` |
| optional prior link 미확정 | null 유지 + review code |
| Stage 2 법리 확정 필요 | `legal_theory_required`로 defer |
| source universe 밖 ref | BLOCK |
| 필수 type/enum 오류 | deterministic mapper 재검사 또는 BLOCK |
권장 artifact:
```text
stage1_tmp/task_c_bo/postb_seed_ledger.json
quality_gates/stage1_part2_review_handoff.json
quality_gates/stage1_part2_exception_pack.json
```
`stage1_part2_review_handoff.json`은 기존 13개 review의 긴 prose를 보존할 필요가 없다. 다음 compact schema면 충분하다.
```json
{
"review_id": "B2:R001",
"severity": "SOFT_WARNING|HARD_WARNING|BLOCK",
"issue_type": "closed_enum",
"candidate_refs": [],
"source_event_candidate_ids": [],
"source_evidence_indexes": [],
"source_meeting_clause_ids": [],
"downstream_owner": "Part3|Part4|Stage2|human_review"
}
```
이 파일을 Stage 2 handoff에 추가할지는 Stage 2 consumer 개정 시 별도로 결정한다. 이번 Part 2 개정에서는 감사 artifact로 보존하되 기존 4개 외부 산출물 계약을 변경하지 않는다.
### 6.4 R1 Dynamic Exception Adjudicator
R1은 `Task_C_BO_PostB_2_single_exception_adjudicator`의 상시 단일 task를 대체한다.
실행 조건:
1. F0가 진행하려면 하나의 값 또는 처리를 선택해야 한다.
2. 둘 이상의 source-backed 후보가 존재한다.
3. 둘 다 보존하거나 Stage 2로 defer할 수 없다.
4. compact record만으로 판정할 수 있다.
허용 decision은 closed enum으로 제한한다.
```text
KEEP_SEPARATE
MERGE_PROVENANCE_UNION
SPLIT
DROP_UNSUPPORTED
BLOCK_REVIEW
```
R1은 raw evidence, full Stage A context, full seed ledger를 읽지 않는다. compact pack이 부족하면 추론으로 채우지 않고 `BLOCK_REVIEW`를 반환한다.
pack 제한 예시:
- candidate 8건 이하
- source excerpt 총 1,500자 이하
- serialized pack 20KB 이하
- pack id와 output path 고정
### 6.5 F0 Final BO Compiler + Gate + Writer
F0는 PostB_3과 PostB_4를 통합한다.
1. seed ledger digest를 확인한다.
2. `dynamic_fanout` pack과 adjudication decision의 coverage를 검사한다.
3. candidate conservation을 검사한다.
4. deterministic ordering과 `bh#`를 부여한다.
5. sparse domain payload를 현재 BO canonical schema로 확장한다.
6. Evidence, EvidenceTitles, provenance, source index를 결정적으로 구성한다.
7. 명시적 prior link가 없으면 `PriorAct`와 `ReasonRefs`를 임의 생성하지 않는다.
8. `Reason`은 fixed code/template로만 구성한다.
9. pre-write schema/reference gate를 통과한 경우에만 `BO.json`을 한 번 쓴다.
10. 다시 읽어 JSON parse, count, ID, SHA-256, source membership을 검증한다.
F0만 `BO.json` writer 권한을 가진다.
### 6.6 S0 Signal Bundle Writer
S0는 BO를 한 번 읽고 다음 파일 세 개를 메모리에서 projection하여 각각 쓴다.
- `actio_case_signals.json`
- `case_liability_signals.json`
- `legal_effect_signals.json`
기존 파일별 schema version, status 규칙, array key를 그대로 유지한다. 각 파일 write 후 다시 읽어 count와 source BO id subset을 검사한다.
## 7. LLM과 Python의 경계
| 작업 | 실행 주체 | 이유 |
|---|---|---|
| input parse, digest, source membership | Python | 100% 결정적 |
| routing rule 적용과 slice 생성 | Python | config 기반 결정적 |
| 법률 domain별 provisional grouping | LLM | 문맥적 법률 추론 필요 |
| null/default/schema expansion | Python | 100% 결정적 |
| ordering, ID, count, serialization | Python | 100% 결정적 |
| exact duplicate 검사 | Python | 100% 결정적 |
| near duplicate 보존·review 부여 | Python | Stage 1 보수 정책으로 결정 가능 |
| meeting-only evidence gap | Python | source type으로 결정 가능 |
| non-deferrable 충돌 판정 | compact LLM | 실제 의미 선택이 필요한 예외만 |
| final BO gate/write/reread | Python | fail-closed 결정 작업 |
| signal projection | Python | 기존 BO의 결정적 projection |
## 8. 최소 작업으로 이행하는 순서
### Phase 1. 고효율 hotfix
기존 task 구조를 크게 바꾸기 전에 다음을 적용한다.
1. B0 -> worker의 `wait_until`을 자기 B0 하나로 줄인다.
2. worker `llm_verbosity`를 모두 low로 바꾼다.
3. 모든 LLM의 common cache prefix를 바이트 동일하게 만든다.
4. task별 role/schema는 common prefix 밖으로 이동한다.
5. PostB_1이 compact pack과 `dynamic_fanout`을 생성하게 한다.
6. PostB_2를 Flash-lite `adjudicator_*` map task로 교체한다.
7. parser에 wrapper-only deterministic salvage를 적용한다.
이 단계만으로 가장 큰 token 낭비와 불필요한 barrier를 제거할 수 있다.
### Phase 2. structural consolidation
1. Stage A와 B0 5개를 A0로 통합한다.
2. worker output을 sparse delta로 변경한다.
3. publisher, domain_join, PostB_1을 R0로 통합한다.
4. PostB_3과 PostB_4를 F0로 통합한다.
5. signal writer 3개를 S0로 통합한다.
6. 미사용 stage-level model 선언을 삭제한다.
완료 시 20개 task는 상시 9개와 동적 R1 N개가 된다.
### Phase 3. model A/B
모델 교체는 구조 개정 후 고정된 slice와 output contract를 기준으로 시행한다.
1. B3를 Flash/medium으로 A/B한다.
2. B1을 Flash/high로 A/B한다.
3. B2는 Pro를 유지한다.
4. B4/B5는 Pro를 유지한다.
5. R1은 Flash-lite/medium으로 고정한다.
B1/B3 A/B는 다음을 모두 만족해야 통과한다.
- candidate ref 집합 동등
- source ref 집합 동등
- protected named field의 값 동등
- review issue type과 source refs 동등
- unsupported 값의 hallucination 0
- lawyer spot review 통과
## 9. 기각하거나 유보할 제안
| 제안 | 판정 | 이유 |
|---|---|---|
| domain LLM 5개를 하나로 통합 | 기각 | prompt와 failure blast radius 증가, 법률 경계 훼손 |
| B5 즉시 2분할 | 유보 | 호출 수 증가, cross-domain 결속 가능성, latency 근거 부족 |
| B2 즉시 Flash 하향 | 기각 | registry/fraction/payment chain의 높은 오류비용 |
| PostB adjudication capability 완전 삭제 | 기각 | 실제 non-deferrable 충돌에 필요 |
| empty exception에도 LLM 호출 | 기각 | Part 1 dynamic fan-out 패턴으로 0회 구현 가능 |
| final BO의 null/empty key 즉시 삭제 | 기각 | Stage 2 consumer 범위 미확정, 외부 contract 위험 |
| BO alias/중복 field 즉시 제거 | 유보 | Stage 2 전체 소비자 확인 전 삭제 위험 |
| review prose 전량 유지 | 기각 | 비용 대비 downstream 소비 없음, compact code로 충분 |
| source 공유를 막는 배타 routing | 기각 | 동일 사실이 복수 법률 domain에 필요할 수 있음 |
## 10. 검증 계획
### 10.1 정적 검증
- YAML parser 통과
- task name 중복 0
- unreachable task 0
- old task reference 0
- `dynamic_fanout=[]`에서 R1 인스턴스 0개
- embedded Python 전부 syntax compile
- Python code가 `YAML_Prompts/1. Stage_1/SKILL.md` 제약 준수
- 모든 LLM common cache prefix hash 동일
- 모델별 role overlay가 prefix 밖에 위치
- `BO.json` writer 정확히 1개
- signal 파일별 writer 정확히 1개
### 10.2 7/10 fixture 품질 불변식
1. evidence index 30개와 event candidate 71개의 source universe를 보존한다.
2. 모든 final BO source ref는 Part 1 universe의 subset이어야 한다.
3. input candidate conservation 식을 만족한다.
4. 1차 회귀 기준으로 seed 50건과 BO 50건을 보존한다.
5. 기존 review 13건의 issue type과 source refs를 compact handoff에 보존한다.
6. meeting-only BO 2건을 삭제하지 않는다.
7. B4 protected actio fields를 보존한다.
8. B5 notice/lien/possession/asset named fields를 보존한다.
9. `BO.json` 및 signal 3종의 기존 envelope와 필수 key를 보존한다.
10. Part 3 LES0과 Part 4 FL0 smoke test를 통과한다.
### 10.3 예외 주입 검사
fixture 복제본에 다음을 주입한다.
- exact duplicate 1쌍
- near duplicate 1쌍
- source universe 밖 ref 1건
- conflicting amount/date 1건
- empty exception case
- oversized exception pack case
기대 결과:
| 주입 | 기대 처리 |
|---|---|
| exact duplicate | provenance-union 조건 통과 시 deterministic merge |
| near duplicate | KEEP_SEPARATE + review, R1 호출 없음 |
| outside-universe ref | BLOCK |
| non-deferrable conflict | compact R1 pack 생성 |
| empty exception | R1 인스턴스 0개 |
| oversized pack | split 또는 BLOCK_REVIEW, full-ledger fallback 금지 |
### 10.4 성능 합격 기준
동일 provider 가격·부하 조건에서 3회 이상 실행한 중앙값으로 판정한다.
| 지표 | 현재 | 1차 합격 | target |
|---|---:|---:|---:|
| 상시 task | 20 | 10 이하 | 9 |
| 상시 Pro/high LLM | 6 | 4 이하 | 3 |
| no-exception PostB LLM | 1 | 0 | 0 |
| PostB LLM input | full ledger | 20KB 이하 pack | 필요한 pack만 |
| worker candidate compact output | 94,830 bytes | 75,000 bytes 이하 | 약 62,000 bytes |
| runtime | 7분 40초 | 5분 30초 이하 | 5분 이하 |
| cost | $4.28 | $3.00 이하 | $2.50 이하 |
품질 불변식 하나라도 위반하면 성능 수치를 만족해도 개정 실패로 판정한다.
## 11. 최종 개정 명령
Part 2 v3 작성자는 다음 우선순위를 지켜야 한다.
1. 외부 BO/signal 계약과 법률 named field를 먼저 고정한다.
2. PostB full-ledger LLM 입력을 가장 먼저 제거한다.
3. 결정적 작업을 Python으로 이동한다.
4. worker의 법률 추론 경계는 유지한다.
5. sparse 표현은 내부 worker output에만 사용한다.
6. 비결정적이며 finalization에 필수인 compact exception만 LLM에 보낸다.
7. 모델 하향은 B3, B1 순서로 A/B gate를 통과한 뒤 적용한다.
8. B5 분할과 외부 schema 축소는 이번 개정 범위에서 제외한다.
한 문장으로 요약하면 다음과 같다.
> **Part 2의 5개 법률 domain worker는 유지하되, 입력은 narrow slice, 출력은 sparse delta로 줄이고, 전후 처리는 네 개 Python compiler/reducer/writer로 통합하며, PostB LLM은 동적으로 생성되는 non-deferrable compact exception에만 허용한다.**
@@ -0,0 +1,304 @@
# Stage 1 Part 2 개정 작업 명세서 (Part_2_Improvement_Strategy_Claude_v1)
- **개정 대상**: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml` (7,462행, 20 task = Python 14 + LLM 6)
- **개정 산출물**: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_Claude_v3.yml` (신규 파일 — 원본 v2는 절대 덮어쓰지 않는다)
- **전략 근거**: `YAML_Prompts/1. Stage_1/v.6/Part_2_Improvement_Claude_v1.md` (이하 **개선전략서**; R-1~R-7, D-1~D-5 판정 포함)
- **본 문서의 성격**: 개정 실행자(LLM)가 본 문서만 읽고 v3 YAML을 100% 작성할 수 있도록 anchor·신규 task 명세·데이터 계약·검증 기준을 기술한 작업 명세서다. 본 문서와 v2 원본이 충돌하면 본 문서가 우선한다. 본 문서가 침묵하는 사항은 v2 원본의 의미론을 보존한다. Part 1 개정에서 검증된 규율(SKILL.md 준수, fixture 회귀, 불변 계약 diff-0)을 동일하게 적용한다.
---
## 0. 개정 목표와 확정 결정
### 0.1 무엇을 바꾸는가 (개선전략서 R-1~R-7 요약)
Part 2의 구조(결정적 컴파일 + 도메인별 국소 LLM)는 유지하고, **LLM 호출의 입력·출력·모델과 전후 Python task 개수를 다이어트**한다: ① PostB_2를 결정적 defer 정책 + compact pack + flash-lite + 빈 pack 즉시 종료(Part 1 v3 GB 골격)로 전환, ② 워커 5개의 입력을 3등급 라우팅 slice로·출력을 sparse seed delta로 축소, ③ Python 14개를 4개(A0/R0/F0/S0)로 통합, ④ 도메인 review 13건의 compact handoff 신설, ⑤ 프리픽스 통일 및 위생 항목. 하류 계약 4파일(BO.json + signal 3종)은 완전 보존한다.
### 0.2 변호사 관점의 불변 원칙
1. **provenance 보존이 최우선**: 모든 seed candidate는 최종 BO 1건, provenance-union 병합, 또는 명시적 BLOCK/review 중 정확히 1곳으로 추적되어야 한다. near-duplicate는 Stage 1에서 병합하지 않고 `KEEP_SEPARATE` + cluster id로 보존한다(증거 소실 방지 — Part 1 개정에서 확립한 원칙과 동일).
2. **meeting-only BO 2건(무증거 변제 주장 등)은 자동 삭제 금지** — `MEETING_ONLY_EVIDENCE_GAP` warning과 함께 보존하여 Stage 2 검토에 회부한다.
3. **법리 확정의 Stage 경계 준수**: `legal_theory_required` 항목은 LLM 판정 대상이 아니라 Stage 2 회부 대상이다. Reason/PriorAct는 Stage 1이 임의 확정하지 않으며 고정 template/enum + 실재 prior link 시에만 기입한다.
4. **B4(사해행위)·B5(상속·통지·유치권) named fields 무손실**: preserved claim, transfer, encumbrance, valuation, cap, defense / notice lifecycle, lien state, possession two-track, asset alias 정보는 sparse화 과정에서도 값이 있으면 반드시 보존된다.
### 0.3 본 명세서의 확정 결정 (개선전략서의 조건부 항목 구체화)
| # | 결정 | 내용과 근거 |
|---|---|---|
| N-1 | **task 명명** | 워커 5개는 기존 이름 유지(`Task_C_BO_Stage_B_B1_Money_Successor` 등 — 프롬프트만 개정). 신설: `Task_C_BO_A0_context_and_domain_slice_compiler`(code), `Task_C_BO_R0_seed_reducer_and_exception_planner`(code), `Task_C_BO_R1_exception_adjudicator`(LLM), `Task_C_BO_F0_final_bo_compiler_gate_writer`(code), `Task_C_BO_S0_signal_bundle_writer`(code). Part 3/4는 Part 2 task 이름을 참조하지 않으므로(파일 계약만 소비) 신설 명명은 하류 무영향 |
| N-2 | **워커 입력 채널 (D-2)** | **Plan A(기본)**: A0가 slice 5개를 파일로 저장, 각 워커는 `preflight_files`에 자기 slice 파일 1개만 whitelist(`preflight: true`)하여 인라인 수신. **STEP 0-2의 채널 검증 통과가 전제**다. **Plan B(fallback)**: 검증 실패 시 Stage A + B0 ×5 구조 유지(B0 코드는 config table 공통화, edge만 1:1) + `{{prev.B0}}` 템플릿 채널 유지. 두 Plan 모두 아래 STEP들에 병기한다 |
| N-3 | **모델 동결 (D-1)** | v3 파일에서 워커 5개는 `gemini-3.1-pro-preview`/`reasoning: high` **유지**, `llm_verbosity: medium → low`만 변경. B1/B2/B3 하향은 v3 배포 후 §9-5의 A/B 절차로만 결정한다(두 리포트의 상반 판정 도메인은 실측 없이 하향 금지). R1은 `gemini-3.1-flash-lite`/`reasoning: low`/`verbosity: low` |
| N-4 | **R1 실행 골격** | Part 1 v3 GB와 동일: **정적 task + pack 파일 1개만 read + 빈 pack 즉시 종료**. 조건부 스폰(dynamic fan-out) 사용 금지(0-instance barrier의 런타임 불확실성 — Part 1 N-2와 동일 논거) |
| N-5 | **Stage-level 미사용 모델 선언 (R-7/X-8)** | v2 9~10행의 `llm_provider: openai`/`llm_model: gpt-4o-2024-08-06`은 **삭제를 시도**하되, STEP 0-4의 등록 smoke test 실패 시 유지한다(백엔드 스키마의 필수 여부 미확인 + Part 1 v3도 보유 중 — 실패해도 실행 비용 영향 없음) |
| N-6 | **bh# 안정성** | F0는 v2의 정렬·부여 규칙을 그대로 계승한다: PostB_1의 `deterministic_sort_key`(BehaviorTime null 여부→BehaviorTime→domain_order→BOType→ActionType→JuristicActLabel→Action→candidate_ref) 순 정렬 후 `bh{idx}` 연속 부여(v2 5443·5466행과 동일). 동일 입력에서 동일 bh# 산출을 보장한다 |
---
## 1. 절대 불변 계약 (위반 금지)
1. **최종 산출물 4파일의 경로·스키마**: `BO.json`(JSON array, 연속·유일 `bh#`, item 키: BO_ID·id·BOType·ActionType·JuristicAct·Action·Reason·PriorAct·ReasonRefs·Legal_Keywords·core_field_base·amount·EvidenceTitles·Evidence·source_evidence_indexes·provenance·downstream_seed_refs·extensions), `actio_case_signals.json`(`schema_version`·`status`·`actio_case_signals[]`), `case_liability_signals.json`(동형, `case_liability_signals[]`), `legal_effect_signals.json`(동형, `bo_legal_effect_routes[]`).
2. **BO item의 내부 중복 필드 유지**: `BO_ID==id`, `EvidenceTitles`, `core_field_base.amount` 등은 v.2 스키마 계약이므로 Stage 2 소비 확정 전 삭제 금지(개선전략서 Y-4).
3. **`extensions.domain_payload` 필드 자체 유지** — 단 null/[]/{} 값 키의 생략은 허용(Part 3 304~308행, Part 4 312~314행의 `.get()` compact 소비 실증).
4. **Part 1 v3 산출물 소비 계약 유지**: A0의 입력은 `client_meeting.md`, `evidence_event_candidates.json`, `evidence_indexed.json`, `Default_Agent/Juristic_Act.md`, `quality_gates/stage1_part1_soft_gate_handoff.json` — v2 Stage A와 동일(`evidence_all.json` 등 forbidden 목록도 계승).
5. **Part 1/3/4 YAML 수정 금지.**
6. **워커 5개의 도메인 분할·AUTHORITY_BOUNDARY·DOMAIN_SCOPE·법률 규칙 본문 유지**: 프롬프트 개정은 입력 채널(§6.1)·출력 계약(§6.2)·verbosity에 한정하며, 각 도메인의 법률 지시(예: B1의 이율 literal 보존 규칙, B4의 actio 구조, B5의 notice lifecycle)는 자구 그대로 보존한다.
7. **COMMON_CACHE_PREFIX_STAGE_1**: 워커 5개의 현행 블록(바이트 동일, SHA `adbdf43c…`)을 canonical로 삼아 **v3의 LLM task 6개 전부에 바이트 동일하게** 배치한다(R1 포함). role/도메인별 내용은 prefix 밖 블록에 둔다.
8. **상태 문자열·enum**: `READY`/`READY_WITH_REVIEW`/`FAILED`, `KEEP_SEPARATE`/`MERGE`/`SPLIT`/`DROP`/`BLOCK_REVIEW`, severity enum 등 v2의 값 문자열을 유지한다.
---
## 2. 현행 v2 anchor 지도 (편집 좌표)
anchor는 ` - task_name:` 라인이며, 범위는 해당 라인부터 다음 anchor 직전까지다.
| # | task (v2 행 범위) | v3 처분 |
|---|---|---|
| 1 | `Task_C_BO_Stage_A_input_normalization` (24~1015) | **A0로 흡수** (Plan B: 파일 출력형으로 개정 유지) |
| 2~6 | `Stage_B0_input_*` ×5 (1016~1343 / 1344~1564 / 1565~1779 / 1780~2004 / 2005~2227) | **A0로 흡수** (Plan B: config table 공통화하여 유지) |
| 7~11 | `Stage_B_B1~B5` (2228~2494 / 2495~2767 / 2768~3043 / 3044~3314 / 3315~3622) | **유지 + 프롬프트 개정** (§6) |
| 12 | `Stage_B_worker_output_publisher` (3623~3962) | **R0로 흡수** |
| 13 | `Stage_B_domain_join` (3963~4585) | **R0로 흡수** |
| 14 | `PostB_1_seed_ledger_compiler` (4586~5045) | **R0로 흡수** |
| 15 | `PostB_2_single_exception_adjudicator` (5046~5140) | **R1로 대체** (§8) |
| 16 | `PostB_3_final_bo_compiler` (5141~5556) | **F0로 흡수** |
| 17 | `PostB_4_final_gate_and_writer` (5557~5904) | **F0로 흡수** |
| 18~20 | `Middle_Input_*` ×3 (5905~6525 / 6526~6958 / 6959~7283) | **S0로 흡수** |
| — | `task_procedure` (7284~7462) | **전면 교체** (§10) |
Plan A의 v3 task 구성: A0 → B1~B5 → R0 → R1 → F0 → S0 = **10개**. Plan B: Stage A' + B0 ×5 + B1~B5 + R0 + R1 + F0 + S0 = 14개.
**코드 이식 원칙**: 흡수되는 Python task의 로직은 폐기가 아니라 **함수 단위 이식**이다. Stage A의 map 빌더들(meeting_clause_map·event_candidate_map·evidence_authority_map·taxonomy·hazard·`_compact_part1_soft_gate_handoff`), B0의 `DOMAIN_CONFIG`·필드 사영 목록(MEETING_FIELDS/EVENT_FIELDS/EVIDENCE_FIELDS), publisher의 가드 검증, domain_join의 사영·인덱스, PostB_1의 sort key·exception 규칙, PostB_3의 컴파일·Reason 규칙, PostB_4의 게이트·검증, Middle 3종의 signal 빌더를 각각 A0/R0/F0/S0로 옮기고, 중복 보일러플레이트만 1벌로 줄인다.
---
## 3. STEP 0 — 사전 검증 (v3 작성 전 필수)
1. **STEP 0-1**: v2에서 §2의 20개 anchor + `task_procedure`(7284행) 존재 확인. 불일치 시 중단·보고.
2. **STEP 0-2 (Plan A/B 결정 게이트)**: 소형 채널 테스트 — slice 형식의 JSON 파일 1개를 localdocs에 쓰고, `preflight: true` + `preflight_files: [그 파일]`인 미니 LLM task(flash-lite)가 파일 내용을 프롬프트에서 수신·인용할 수 있는지 1회 실행으로 확인한다. **통과 → Plan A, 실패 → Plan B.** 결과를 개정 보고서에 기록한다.
3. **STEP 0-3**: fixture(`Results_July_10_3_15pm`)에 Part 1 산출물 5종(A0 입력)과 도메인 seed 5종·BO.json·signal 3종이 존재함을 확인한다(§11 회귀에 사용).
4. **STEP 0-4**: stage-level 모델 선언(9~10행) 삭제본으로 YAML parse + 백엔드 등록 smoke test(`upload-agent`) 시도. 실패 시 선언 유지(N-5).
5. **STEP 0-5**: R1에 사용할 canonical prefix를 v2 2242~2284행(B1 워커의 COMMON_CACHE_PREFIX_STAGE_1 블록)에서 바이트 추출해 둔다.
---
## 4. 신규 데이터 계약 (파일 7종)
| 파일 | writer | 소비자 | 핵심 스키마 |
|---|---|---|---|
| `stage1_tmp/task_c_bo/stage_a_context.json` | A0 | R0, F0, S0 (파일 read) | v2 `stage_a_context` 객체와 동일 구조(schema_version `task_c_bo_stage_a_context.v1` 유지) |
| `stage1_tmp/task_c_bo/source_universe_manifest.json` | A0 | R0, F0, S0 | `{schema_version, input_digests_sha256, evidence_index_set[], event_candidate_ids[], meeting_clause_ids[], counts}` |
| `stage1_tmp/task_c_bo/domain_slices/B{1..5}.json` (Plan A) | A0 | 워커 (preflight) | v2 B0 slice 구조(`stage_b_domain_slice`, schema_version `task_c_bo_stage_b_domain_slice.v1`, READ_ONLY 필드 목록 동일) + **3등급 라우팅 확장**: `selected_*`는 `primary`만 full record, `support_refs[]`·`review_only_refs[]`는 id+1줄 요약, `routing_audit`에 `primary_ids/support_ids/review_only_ids/activation_reasons/source_count/slice_bytes/broadness_ratio` |
| `stage1_tmp/task_c_bo/postb_seed_ledger.json` | R0 | F0, S0 | v2 `postb_seed_ledger` stdout 객체와 동일 구조(ledger_candidates는 **expander로 full schema 확장 후** 수록, deterministic_sort_key 포함) |
| `quality_gates/stage1_part2_exception_pack.json` | R0 | R1 | `{schema_version: "stage1_part2_exception_pack.v1", has_exceptions, exception_count, exceptions[], budget}` — exception 항목: `{exception_id, exception_type: "canonical|field_conflict|link_ambiguity|semantic_risk", candidate_refs[], compact_payload(판정에 필요한 필드만), allowed_decisions[], escalation_flag}`. **X-3의 4중 조건을 통과한 항목만 수록** |
| `stage1_tmp/task_c_bo/postb_adjudication_decisions.json` | R1 | F0 | `{schema_version: "task_c_bo_postb_exception_adjudication.v1", status: "READY|READY_NO_EXCEPTIONS", exception_count, canonical_decisions[], field_decisions[], link_decisions[], semantic_gate_decisions[], blocked_review_items[]}` — v2 PostB_2 출력 스키마 유지(F0의 `_adjudication` 소비 로직 이식 호환) |
| `quality_gates/stage1_part2_review_handoff.json` | R0 (F0가 최종 status 갱신) | Stage 2 / 인간 검토 | `{schema_version: "stage1_part2_review_handoff.v1", review_items[]}` — 항목: `{review_id, source_domain, severity: "SOFT_WARNING|HARD_WARNING", issue_type(closed enum), source_event_candidate_ids[], source_evidence_indexes[], source_meeting_clause_ids[], downstream_owner: "C0|C1|C2|C3|C5|D|E|Stage2", template_note(고정 템플릿 1줄)}` — 워커의 domain_review_queue 13건 + defer 정책이 생성한 review code를 전량 수록. **자유 서술 금지** |
stdout 규약(SKILL.md §3.3): A0/R0/F0/S0 모두 **단일 JSON 라인**만 출력하며 full context/ledger를 stdout에 넣지 않는다(경로 manifest + digest + count + `message` 필드).
---
## 5. STEP 1 — A0 명세 (`Task_C_BO_A0_context_and_domain_slice_compiler`, Plan A)
code-executor 엔트리(v2 Stage A 형식: language python, requirements httpx, network agent-network, timeout 240). MCP 보일러플레이트는 v2 Stage A(43~145행)를 이식하고 `clientInfo.name`만 `"task-c-bo-a0-context-and-domain-slice-compiler"`로 변경. SKILL.md 필수사항(user/workspace hash, raw_decode fallback) 유지.
1. v2 Stage A의 정규화 로직 전체 이식(입력 5종 read → meeting/event/evidence map·taxonomy·hazard·digest·part1 handoff compact — 24~1015행의 함수군 그대로).
2. `stage_a_context.json`·`source_universe_manifest.json` 파일 write (stdout 발행 대신 — C-9 해소).
3. v2 B0 ×5의 `DOMAIN_CONFIG`(도메인별 terms/sources/hazard_keys/taxonomy_axes — 1016~2227행)를 **config table 1개**로 통합하고 공통 라우팅 함수 1벌로 5개 slice를 생성한다(X-7 해소).
4. **3등급 라우팅(X-1)**: (a) `event_subkind`·`doc_type`·`legal_effect_candidate`·named component·registry/fraction/notice/lien key 매칭 → `primary`, (b) broad term 단독 매칭 또는 source-ref closure 유입 → `support`(id+title+1줄), (c) 잔여 참조 → `review_only`(id만). broad term(`등기`·`변제`·`항변`·`점유`·`목적물` 등)은 단독으로 primary 승격 불가. slice가 universe의 60%를 넘으면 `ROUTING_BROADNESS_WARNING`을 routing_audit에 기록(자동 실패 금지).
5. `domain_slices/B{1..5}.json` write. 각 slice에 v2 B0 출력과 동일한 가드 필드(`router_status`, `domain_id`, `source_stage_a_*`, `stage_b_worker_contract`)를 유지한다(워커의 ABSOLUTE_SYSTEM_RULES 검증 호환).
6. stdout: `{"status":"READY","message":"...","stage_a_path":...,"source_manifest_path":...,"domain_slice_paths":{...},"input_digests_sha256":{...},"routing_summary":{도메인별 primary/support count}}` 1줄.
7. FAILURE_POLICY: 입력 누락·파싱 불가 시 파일 미작성, FAILED JSON 1줄 + raise (v2 Stage A와 동일).
**Plan B(STEP 0-2 실패 시)**: Stage A는 위 1·2·6·7만 적용(파일 출력형으로 개정), B0 ×5는 유지하되 5중 복제 코드를 공통 함수+config로 재작성하고 3등급 라우팅(4)을 적용하며, stdout은 자기 slice 1개만 발행한다. edge는 §10 Plan B대로 1:1.
---
## 6. STEP 2 — 워커 5종 프롬프트 개정 (B1~B5 공통)
각 워커의 task 엔트리·법률 본문(AUTHORITY_BOUNDARY/DOMAIN_SCOPE/WORKFLOW의 도메인 규칙)은 유지하고 다음만 변경한다.
### 6.1 입력 채널
- **Plan A**: `preflight: false` → **`preflight: true`** + `preflight_files: [stage1_tmp/task_c_bo/domain_slices/B{n}.json]`(자기 slice 1개만). 프롬프트의 `<B0_DOMAIN_SLICE_INPUT>{{prev.…}}</B0_DOMAIN_SLICE_INPUT>` 블록을 "preflight로 제공된 slice 파일의 `stage_b_domain_slice` 객체만 사용하라"는 지시로 교체. ABSOLUTE_SYSTEM_RULES의 검증 항목(schema_version·router_status·domain_id·worker_contract)은 유지.
- **Plan B**: 현행 `{{prev.Task_C_BO_Stage_B0_input_*}}` 채널 유지.
- 3등급 slice 소비 규칙 추가: "`support_refs`/`review_only_refs`는 존재 확인·ref 인용에만 사용하고 사실 인용의 근거는 primary record로 한정한다."
### 6.2 sparse seed delta 출력 계약 (OUTPUT_CONTRACT 교체)
**emit 규칙** (신설, 5개 워커 공통 문구):
- 값이 null/[]/{}/빈 문자열인 키는 **출력하지 않는다**(의미 있는 false·0은 유지). R0가 canonical schema로 확장하며, 키 부재는 null로 해석된다.
- **출력 금지 목록**: `transport_candidate_refs`(R0가 provenance에서 재구성), `slice_guard`의 source_universe 전체 에코(→ `source_stage_a_created_at_utc`와 `input_digests_summary`(digest들의 결합 SHA 1개)만 유지), `Reason`, `PriorAct`, `ReasonRefs`, `downstream_seed_refs`, 긴 review `description`.
- `domain_review_queue` 항목은 §4 review_handoff 스키마의 필드만 출력한다(closed enum issue_type + source refs 3종 + downstream_owner; 서술은 `template_note` 생략 — R0가 고정 템플릿 부여).
- OUTPUT_SURFACE_HARD_RULE(단일 raw JSON)은 유지.
- `llm_verbosity: medium → low` (5개 전부).
- 스키마 예시 블록은 sparse 예시로 교체하되, **candidate의 실질 필드(BOType·ActionType·JuristicAct·Action·core_field_base·amount·source refs·domain_payload의 유의미 값)와 B4/B5 named fields는 그대로 요구**한다(§0.2-4).
### 6.3 프리픽스
COMMON_CACHE_PREFIX_STAGE_1 블록은 현행 바이트 그대로 유지(5개 동일성 보존 — 회귀 기준 SHA `adbdf43c…`는 들여쓰기 포함 기준이므로 블록을 편집하지 않는 한 자동 충족).
---
## 7. STEP 3 — R0 명세 (`Task_C_BO_R0_seed_reducer_and_exception_planner`)
code-executor(timeout 240). publisher(3623~3962)+domain_join(3963~4585)+PostB_1(4586~5045)의 로직을 이식·통합한다.
1. **입력**: 워커 5개의 stdout(`{{prev.Task_C_BO_Stage_B_B1_Money_Successor.json_output}}` 등 5개 — r''' raw string으로 주입, SKILL §6.1) + `stage_a_context.json`·`source_universe_manifest.json` 파일 read.
2. **관용 파서(Y-3)**: SKILL §6.7 `parse_llm_json` 패턴으로 워커 출력의 코드펜스·잡음을 결정적으로 salvage한 후 strict 검증. `OUTPUT_SURFACE_HARD_RULE` 위반은 salvage 성공 시 warning 기록으로 강등(pro 재호출 차단).
3. **가드 검증**(publisher 이식): domain_id·schema_version·worker_contract·digest 대조.
4. **seed 파일 5종 write**(감사 아티팩트 유지 — 기존 경로 `stage1_tmp/task_c_bo_stage_b_domain_seed_outputs/*.json`에 **expander 적용 후의 full schema로** 저장, 기존 파일 형식 호환).
5. **schema expander**: sparse candidate → canonical full schema 확장(§6.2 금지 목록의 default 복원: Reason=null, PriorAct=null, ReasonRefs=[], downstream_seed_refs=4-key null 객체, transport_candidate_refs 재구성, domain_payload 미출력 키의 null 복원). **expander는 schema default만 채우고 사실을 창작하지 않는다.**
6. **membership·invariant 검사**(domain_join+PostB_1 이식): source ref ⊆ universe(위반 → BLOCK), candidate_ref 형식·유일성, prop_id 매핑.
7. **결정적 defer 정책(X-2 — LLM에 보내지 않는 예외)**:
| 예외 | 결정적 처리 |
|---|---|
| exact duplicate (정규화 candidate 동일) | provenance union이 무손실일 때만 canonical merge + `EXACT_DUPLICATE_MERGE` 기록 |
| near duplicate (shared source refs, 비동일) | `KEEP_SEPARATE` + `near_dup_cluster_id` + review code |
| meeting-only candidate (source evidence 공백) | 보존 + `MEETING_ONLY_EVIDENCE_GAP` review code |
| PriorAct/선행관계 불명 | null 유지 + review code |
| Stage 2 법리 확정 필요(`legal_theory_required`) | review handoff 회부, LLM 금지 |
| source ref가 universe 밖 | BLOCK (hard) |
| 필수 schema type/enum 오류 | BLOCK 또는 해당 워커 rerun 지시 기록 |
8. **exception pack 생성(X-3)**: 다음 4중 조건을 **모두** 충족하는 항목만 pack에 수록 — ① F0가 진행하려면 단일 값 선택이 필수 ② source-backed 후보 2개 이상 ③ 보존·defer 불가 ④ compact payload로 판정 충분. 항목당 compact_payload는 판정 필요 필드만(후보당 ≤2KB), full ledger·Stage A 참조 금지.
9. **review handoff 생성**: 워커 review 13건 + defer 정책 review code를 §4 스키마로 전량 수록(고정 template_note 부여).
10. **ledger 파일 write** + **conservation invariant**(write 전·후): `len(seed candidates) == len(ledger_candidates) + len(EXACT_DUPLICATE_MERGE 흡수분)`, 모든 candidate_ref의 1:1 추적성, 정렬 안정성(N-6 sort key).
11. **stdout 1줄**: `{"status","message","ledger_path","exception_pack_path","review_handoff_path","has_exceptions","exception_count","candidate_counts":{입력/최종/병합/BLOCK}}`.
---
## 8. STEP 4 — R1 명세 (`Task_C_BO_R1_exception_adjudicator`)
Part 1 v3의 `Task_B12_gate_llm_adjudicator`와 동일 골격. LLM task 엔트리:
```yaml
- task_name: Task_C_BO_R1_exception_adjudicator
llm_provider: google
llm_model: gemini-3.1-flash-lite
llm_reasoning: low
llm_verbosity: low
max_iterations: 1
use_tools: [localdocs]
cache_control: {mode: auto, ttl: 20m}
preflight_files:
- quality_gates/stage1_part2_exception_pack.json
```
프롬프트 구성: STEP 0-5에서 추출한 canonical COMMON_CACHE_PREFIX_STAGE_1(바이트 동일) + 신규 STATIC_BLOCK:
1. MISSION: "R0가 추출한 non-deferrable compact exception만 판정한다. 파일 병합·BO 작성·사실 창작 금지."
2. EXECUTION: ① pack 1파일만 read ② `has_exceptions == false`면 `{"postb_exception_adjudication": {…, "status": "READY_NO_EXCEPTIONS", "exception_count": 0, 전 배열 []}}`를 decisions 파일에 write 후 `"NO_EXCEPTIONS"` 출력·즉시 종료 ③ 예외 존재 시 compact_payload만으로 판정(추가 read 금지) ④ decision은 `allowed_decisions` 내 값 또는 `BLOCK_REVIEW`만 ⑤ decisions 파일 write(§4 스키마 — v2 PostB_2 출력 스키마와 동일) ⑥ 건수 요약 1줄 출력·종료.
3. ABSOLUTE_FORBIDDEN: pack 외 파일 read / BO.json·ledger·handoff 작성 / 새 candidate_ref·bh#·사실 창작 / pack에 없는 exception_id / markdown fence.
4. 판정 기준(v2 PostB_2의 Allowed judgment types·Required rules 이식): canonical(KEEP_SEPARATE/MERGE/SPLIT/DROP/BLOCK_REVIEW), field conflict(제공값 중 선택), link ambiguity(나열된 ref/NO_LINK/BLOCK_REVIEW), semantic risk(PASS/WARNING/BLOCK_REVIEW). 판정 불충분 시 항상 BLOCK_REVIEW(확신 없는 확정 금지).
---
## 9. STEP 5 — F0 명세 (`Task_C_BO_F0_final_bo_compiler_gate_writer`)
code-executor(timeout 240). PostB_3(5141~5556)+PostB_4(5557~5904) 로직 이식·통합.
1. 입력: `postb_seed_ledger.json`·`postb_adjudication_decisions.json`·`stage_a_context.json`(또는 manifest) 파일 read. `{{prev}}` 대형 주입 제거.
2. adjudication 검증(v2 `_adjudication` 이식): schema_version·status 검사, `blocked_review_items` 존재 시 FAILED_NEEDS_REVIEW.
3. 결정 적용(v2 `_decision_sets`·`_field_decision_map`·`_link_decision_map` 이식): EXACT_DUPLICATE_MERGE(R0 결정)+R1 canonical/field/link 결정 반영.
4. **bh# 부여(N-6)**: ledger 정렬 순서에서 dropped/merged 제외 후 `bh{idx}` 연속 부여 — v2 5443·5466행 로직 그대로.
5. **Reason/PriorAct 정책(R-5/X-7)**: v2 5511행의 2분기 template을 계승하되 enum화 — `ReasonRefs` 실재 시 "ReasonRefs에 기재된 선행 BO와 source evidence/event chain으로 연결됨", 부재 시 "source evidence 및 event candidate에 의해 독립적으로 확인되는 BO". 자유 서술 생성 금지. PriorAct는 명시적 prior link 결정이 있을 때만 기입.
6. 게이트(v2 PostB_4 이식): Stage A freshness, bo_items 비어있지 않음, pre-gate blockers 공백, item별 스키마·provenance ⊆ universe·downstream_seed_refs 키 검증, **conservation**(seed→BO 추적성: BO 수 + 병합 흡수 수 + BLOCK 수 == seed 후보 수).
7. `BO.json` 단일 write → reread → JSON parse·bh# 연속성·count·SHA-256 검증(v2와 동일).
8. review handoff의 최종 status 갱신(BLOCK_REVIEW 항목 반영).
9. stdout 1줄: `{"status","message","bo_count","merged","blocked","gates":[…]}`.
---
## 10. STEP 6 — S0 명세 + task_procedure
### S0 (`Task_C_BO_S0_signal_bundle_writer`)
code-executor(timeout 180). Middle ×3(5905~7283)의 signal 빌더 함수를 이식·통합: `BO.json` **1회** read + `source_universe_manifest.json`(+필요 시 ledger compact index) → 메모리에서 3개 projection 생성 → `actio_case_signals.json`·`case_liability_signals.json`·`legal_effect_signals.json` write(각 파일의 schema_version·status 규칙·검증 로직은 v2의 `_validate` 이식). v2가 B4 stdout을 참조하던 부분은 ledger의 B4 도메인 candidate(전 필드 보존됨)로 대체한다. stdout 1줄.
### task_procedure (Plan A — 전면 교체)
```yaml
task_procedure:
IN:
nexts: [Task_C_BO_A0_context_and_domain_slice_compiler]
wait_until: []
Task_C_BO_A0_context_and_domain_slice_compiler:
nexts:
- Task_C_BO_Stage_B_B1_Money_Successor
- Task_C_BO_Stage_B_B2_Secured_Registry
- Task_C_BO_Stage_B_B3_Land_Valuation
- Task_C_BO_Stage_B_B4_Actio
- Task_C_BO_Stage_B_B5_Succession_Notice_Lien_Asset_Defense
wait_until: [IN]
Task_C_BO_Stage_B_B1_Money_Successor:
nexts: [Task_C_BO_R0_seed_reducer_and_exception_planner]
wait_until: [Task_C_BO_A0_context_and_domain_slice_compiler]
# B2~B5 동일 형식 (각각 A0만 대기)
Task_C_BO_R0_seed_reducer_and_exception_planner:
nexts: [Task_C_BO_R1_exception_adjudicator]
wait_until:
- Task_C_BO_Stage_B_B1_Money_Successor
- Task_C_BO_Stage_B_B2_Secured_Registry
- Task_C_BO_Stage_B_B3_Land_Valuation
- Task_C_BO_Stage_B_B4_Actio
- Task_C_BO_Stage_B_B5_Succession_Notice_Lien_Asset_Defense
Task_C_BO_R1_exception_adjudicator:
nexts: [Task_C_BO_F0_final_bo_compiler_gate_writer]
wait_until: [Task_C_BO_R0_seed_reducer_and_exception_planner]
Task_C_BO_F0_final_bo_compiler_gate_writer:
nexts: [Task_C_BO_S0_signal_bundle_writer]
wait_until: [Task_C_BO_R1_exception_adjudicator]
Task_C_BO_S0_signal_bundle_writer:
nexts: [OUT]
wait_until: [Task_C_BO_F0_final_bo_compiler_gate_writer]
OUT:
nexts: []
wait_until: [Task_C_BO_S0_signal_bundle_writer]
```
**Plan B**: `IN → Stage_A' → B0_i ×5(각각 Stage_A'만 대기) → 워커 i(자기 B0_i만 대기 — 1:1) → R0(워커 5개 대기) → R1 → F0 → S0 → OUT`.
---
## 11. 수용 기준 (Definition of Done)
### 11.1 정적 검사
1. `Stage_1_Part_2_Claude_v3.yml` YAML parse 성공, task 수 10(Plan A)/14(Plan B), task_procedure가 §10과 일치, unreachable task 0, 구 task 참조(`{{prev.Task_C_BO_Stage_B0_…}}` 등 폐기 채널) 잔존 0.
2. 모든 embedded Python `ast.parse` 통과, SKILL.md 준수(full boilerplate, `{{__user_hash__}}`/`{{__workspace_hash__}}`, raw_decode fallback, **stdout 단일 JSON 라인**, `r'''…'''` 템플릿 주입).
3. `BO.json` writer 정확히 1개(F0), signal 3파일 writer 정확히 1개(S0), review handoff writer R0(+F0 status 갱신).
4. LLM task 6개의 COMMON_CACHE_PREFIX_STAGE_1 바이트 동일(기준: v2 워커 블록).
5. 워커 5개의 llm_model/reasoning은 v2와 동일(pro-preview/high — N-3), verbosity만 low. R1은 flash-lite/low.
6. 워커의 도메인 법률 본문(AUTHORITY_BOUNDARY·DOMAIN_SCOPE·도메인 규칙)이 v2 대비 자구 보존(입출력 계약·채널 변경분 제외).
### 11.2 fixture 회귀 (7/10 실행물 입력, 코드 로컬 실행)
1. **A0**: slice 5종 생성, 각 slice의 primary/support 분리로 B2·B5의 event/evidence 전체 재적재(중복 배수 2.56×/2.80×)가 유의미하게 감소, universe(evidence 30·event 71·meeting 41) 보존.
2. **sparse 왕복**: 7/10 seed 5종을 §6.2 규칙으로 sparse화 → R0 expander로 확장 → 원본과 의미 동등(유의미 값 보존, default만 복원) + **2-run 바이트 결정론**.
3. **R0 defer**: fixture 예외 6건(schema risk 2 = meeting-only, near-dup cluster 4)이 전부 결정적 처리되어 `has_exceptions=false`, R1이 NO_EXCEPTIONS 조기 종료. review handoff에 워커 review 13건 + defer review code 전량 수록(source refs 보존).
4. **F0**: BO 50건, bh1~bh50 연속·유일, **v2 산출 BO.json과 item-level 의미 동등**(Reason 2분기 template 포함), conservation 성립(50 = 50 + 0 + 0), meeting-only BO 2건 보존, B4/B5 named fields 무손실.
5. **S0**: signal 3종 5/50/50 items, schema_version·status 규칙 유지.
6. **주입 테스트**: ① universe 밖 source ref → R0 BLOCK ② exact duplicate 주입 → provenance union merge + conservation 성립 ③ non-deferrable field conflict 주입(동일 사실에 상충하는 source-backed 값 2개) → pack 수록·R1 발동 경로 ④ 워커 출력에 코드펜스 주입 → R0 관용 파서 salvage 성공(재호출 없음).
7. **하류 무영향**: 개정 BO.json·signal 3종으로 Part 3 LES0·Part 4 FL0 파서 통과(domain_payload null-생략본 포함).
### 11.3 성능 합격 기준 (실 재실행, 동일 조건 3회 중앙값)
task ≤10(Plan A), R1 입력 = pack만(≤20KB), fixture에서 R1 실질 작동 0회, 워커 compact 출력 합계 ≤70KB 목표, 런타임 ≤5분, 비용 ≤$2.50. **§11.2 품질 불변식 위반 시 성능 달성해도 실패.**
### 11.4 모델 A/B (v3 배포 후, D-1)
고정 slice 입력으로 B1/B2/B3의 pro vs flash 계열 산출을 후보 수·source ref 집합·review queue 동등성 + 변호사 육안 대조로 판정 → 통과 도메인만 v3.1에서 하향. B4/B5는 대상 아님. **B5 2분할(개선전략서 D-5)**은 v3 실측에서 B5가 여전히 워커 구간 wall-clock 지배 항목일 때만 별도 개정으로 검토한다(v3 범위 밖).
---
## 12. 금지 사항 최종 목록
1. v2 원본 덮어쓰기·이동·삭제 금지 (v3는 신규 파일).
2. §1 불변 계약(4파일 스키마, BO 내부 중복 필드, domain_payload 필드, 워커 법률 본문, enum 문자열) 변경 금지.
3. Part 1/3/4 YAML 수정 금지.
4. 워커 모델·reasoning 하향 금지(v3 시점 — A/B는 §11.4 절차로만).
5. R1에 pack 외 입력 제공 금지, R1의 파일 병합·BO 작성 금지, expander의 사실 창작 금지.
6. near-duplicate 자동 병합 금지(provenance union 무손실 exact dup 제외), meeting-only BO 자동 삭제 금지.
7. review 항목의 silent drop 금지(13건 + 신규 code 전량 handoff 수록).
8. LLM의 긴 review 서술·Reason 자유 서술 생성 금지.
9. count·ID·순서를 입력 데이터 외 근거로 생성 금지(bh#는 N-6 규칙, count는 len()).
10. 본 명세서에 없는 "개선"의 임의 추가 금지 — 범위 밖 아이디어는 개정 보고서에 제안으로만 기록.
@@ -0,0 +1,201 @@
# Part 2 비효율 분석 및 개정 전략 보고서 (Claude v1)
- 대상: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml` (7,462행, 17개 task) — Task_C_BO 파이프라인
- 근거 자료: v.6 YAML 4종(Part 1은 `Stage_1_Part_1_Claude_v3.yml` 기준) 전체 + `v.6/Results_July_10_3_15pm/` 실측(BO.json, 도메인 seed 5종, signal 3종) + Part 3/4 하류 소비 지점 grep 검증
- 실행 실적: Part 2 = 7분 40초 / **$4.28 (4개 Part 중 최고 비용, Stage 1 전체 $6.95의 62%)**
---
## 0. 결론 요약
1. **Part 2는 Part 1(v2)과 달리 이미 "결정적 컴파일 + 국소 LLM" 원칙으로 설계되어 있다.** 17개 task 중 11개가 code-executor이고, 병합·ID 확정·게이트·signal 생성은 전부 Python이다. 따라서 Part 1식 "LLM writer 전면 치환" 여지는 없다. 비효율은 다른 곳에 있다: **① 6개 LLM 호출 전부가 `gemini-3.1-pro-preview` + `reasoning: high`로 일괄 상향**되어 있고, ② 그중 1개(PostB_2 예외 판정기)는 **필요 입력의 수십 배(전체 ledger)를 주입받으면서 항상 실행**되며, ③ 워커 5개의 출력 206,681B 중 상당분이 **null/empty 스캐폴드(leaf의 54%)와 이중 배선 필드**라는 점이다.
2. **최대 단일 비효율은 PostB_2다.** 프롬프트 스스로 "Full upstream object is provided only because some runtimes do not support stable nested field access. You must read only `postb_seed_ledger.exception_pack`"이라고 적어 놓고, 50개 후보 전체 payload가 담긴 PostB_1 stdout(추정 200KB+)을 pro-preview high 호출에 통째로 주입한다. 이것은 Part 1 개정에서 제거한 "full fan-in을 LLM 컨텍스트로 수행" 문제의 재현이며, 해법도 동일하다 — **Part 1 v3의 GB 패턴(compact exception pack 파일 + flash-lite + 빈 팩 즉시 종료) 이식**. 이번 7/10 실행에서 seed 50건 → BO 50건으로 **merge/drop 0건**이었다는 실측은, 이 사건에서 pro-preview 판정기가 실질 기여 없이 최대 비용 경로로 실행되었음을 보여준다.
3. **워커 5개(B1~B5)는 Part 2의 정당한 비용 중심이다.** 도메인별 BO seed 생성은 Stage 1에서 가장 법률 추론 밀도가 높은 작업(금전채권·상호속용, 담보·등기, 사해행위, 상속·유치권)이므로 모델 일괄 하향은 권고하지 않는다. 대신 **출력 계약 슬리밍(null 생략, 이중 배선 제거)과 verbosity 하향으로 출력 토큰을 줄이고**, 추출 성격이 강한 B2/B3에 한해 fixture A/B로 하향을 검증한다.
4. **wall-clock의 숨은 소비자는 직렬 code task 12개다.** publisher→domain_join→PostB_1→…→Middle×3이 각각 컨테이너 부팅 + MCP 왕복을 반복하고, 같은 50개 후보를 5회 재직렬화하며, publisher가 쓴 파일을 domain_join이 즉시 재독해한다. 통합으로 17→10 task로 줄일 수 있다.
5. 예상 효과(추정 명시): LLM 입력 약 200KB 제거(PostB_2), LLM 출력 30~45% 감소(워커 슬리밍), 비용 $4.28 → $2.5~3.0 수준, 런타임 7:40 → 5분 내외. 하류 계약(BO.json, signal 3종의 경로·스키마)은 완전 보존.
---
## 1. 실측 데이터 (Results_July_10_3_15pm 기준)
### 1.1 task 구성과 모델
| 구간 | task | 유형 | 모델 설정 |
|---|---|---|---|
| Stage A | `Task_C_BO_Stage_A_input_normalization` | code | — (stdout으로 stage_a_context 발행, 파일 미작성) |
| B0 라우터 ×5 | `Stage_B0_input_{money_successor, secured_registry, land_valuation, actio, succession_notice_lien_asset_defense}` | code | — (Stage A stdout을 도메인 slice로 절단) |
| **Stage B 워커 ×5** | `Stage_B_B1~B5` | **LLM** | **gemini-3.1-pro-preview, reasoning=high**, verbosity=medium, max_iterations=2, use_tools=[], cache ttl 1h |
| 게시·조인 | `worker_output_publisher`, `domain_join` | code | — |
| PostB | `PostB_1_seed_ledger_compiler` | code | — |
| **예외 판정** | `PostB_2_single_exception_adjudicator` | **LLM** | **gemini-3.1-pro-preview, reasoning=high**, verbosity=low, max_iterations=1 |
| 최종 | `PostB_3_final_bo_compiler`, `PostB_4_final_gate_and_writer` | code | — (PostB_4가 BO.json 단일 writer + 게이트) |
| Middle ×3 | `Middle_Input_{actio_case, case_liability, legal_effect}_signals` | code | — (signal 3종 파일 writer) |
### 1.2 산출물 실측
| 산출물 | 크기 | 실측 내용 |
|---|---|---|
| 도메인 seed 5종 (`stage1_tmp/task_c_bo_stage_b_domain_seed_outputs/`) | 합계 **206,681 B** | B1: 13건/49,793B · B2: 7건/38,901B · B3: 6건/29,322B · B4: 5건/25,747B · **B5: 19건/62,918B** — 5개 전부 `READY_WITH_REVIEW`, review 합계 13건 |
| `BO.json` | 175,126 B | **50 items (seed 50건 → BO 50건, merge/drop 0)**, BO_ID 유일성 통과 |
| `actio_case_signals.json` | 9,990 B | 5 items |
| `case_liability_signals.json` | 15,565 B | 50 items |
| `legal_effect_signals.json` | 19,093 B | 50 items |
### 1.3 출력물 내부의 중복·공백 실측 (결정론적 대조)
1. seed 후보들의 `extensions.domain_payload` leaf 값의 **54%가 null/[]/{}/빈 문자열**(BO.json 기준 782/1,451) — 출력 스키마가 도메인 공통 30여 키를 전 후보에 강제한 결과이며, 워커가 pro-preview 출력 토큰으로 이 스캐폴드를 매번 재타이핑한다.
2. `transport_candidate_refs[]`(파일당 1.0~3.6KB)는 각 후보의 `provenance`와 동일한 source id 3종을 이중 배선한다.
3. `transport_metadata.slice_guard`(파일당 1.3~3.3KB)는 Stage A digest·universe를 워커 출력에 재에코한다 — 가드 검증은 publisher(code)가 수행 가능하므로 LLM 출력에 실릴 필요가 없다.
4. BO.json 내부: `BO_ID == id` (50/50 동일), `EvidenceTitles == Evidence[*].source_title` (49/50 동일), `core_field_base.amount == amount.value` (50/50 동일), `Reason`은 **50건 전부 동일한 보일러플레이트 1종**("source evidence 및 event candidate에 의해 독립적으로 확인되는 BO"). `extensions.domain_payload`가 파일 바이트의 29%를 차지한다.
5. Stage A의 stdout(stage_a_context — meeting/event/evidence map 전체 포함)은 `{{prev.…}}` 템플릿으로 **12개 task에 원문 주입**된다(B0 ×5, publisher, domain_join, PostB_1, PostB_3, PostB_4, Middle ×3). LLM 토큰은 아니지만 転送·재파싱이 12회 반복된다.
---
## 2. 실행 구조와 병목 (DAG 분석)
```text
Stage_A(code) ──> B0 ×5(code) ══all-to-all══> 워커 B1~B5 ×5(LLM pro/high, 병렬)
│ (.json_output 템플릿)
v
publisher(code, seed 5파일 write) ─> domain_join(code, 방금 쓴 5파일 재독해)
│
v
PostB_1(code, ledger 전체를 stdout으로) ─> PostB_2(LLM pro/high, ledger 전문 주입) ─> PostB_3(code) ─> PostB_4(code, BO.json write+gate)
│
Middle ×3(code, 각각 BO.json 재독해) ─> OUT
```
- **critical path의 LLM 구간은 2개**: 워커 병렬 구간(최장 워커 = B5, 출력 62.9KB + high 사고 토큰)과 PostB_2. 나머지는 12개의 직렬/준직렬 code task로, 각각 컨테이너 기동과 MCP 세션 초기화를 반복한다.
- **B0→워커 all-to-all 대기**: 각 워커는 자기 slice 하나(`{{prev.Stage_B0_input_<자기도메인>}}`)만 소비하는데 `wait_until`은 B0 5개 전부다. 가장 느린 B0가 모든 워커의 시작을 지연시킨다.
- **write→즉시 re-read 왕복**: publisher가 seed 5파일을 쓰고 domain_join이 같은 파일을 다시 읽는다(감사 목적 명시). 목적은 정당하나 두 task를 합치면 왕복 없이 동일 감사가 가능하다.
- 워커의 입력 채널이 stdout 템플릿(중첩 필드 접근 불가 런타임 제약) 때문에 B0가 5개로 분리된 것은 **정당한 설계**다(비효율 아님).
---
## 3. LLM 6호출의 필요성 판정
| 호출 | 실질 작업 | 현재 설정 | 판정 |
|---|---|---|---|
| B1_Money_Successor | 금전채권·변제기·채무승인·상호속용 seed 생성 (13건) | pro-preview/high | **유지** — 청구원인 구조의 법률 추론 실질. 출력 슬리밍만 적용 |
| B2_Secured_Registry | 담보·등기·경매 seed (7건) | pro-preview/high | 유지 기본, **flash 계열 A/B 후보** (등기 row 추출 성격 강함) |
| B3_Land_Valuation | 토지·점유·차임·감정 seed (6건) | pro-preview/high | 유지 기본, **flash 계열 A/B 후보** (추출 성격 최강, 후보 최소) |
| B4_Actio | 사해행위·가액배상 seed (5건) | pro-preview/high | **유지** — 피보전채권·사해성 판단은 최고 난도 |
| B5_Succession_Notice_Lien_Asset_Defense | 상속·통지·유치권·항변 seed (19건) | pro-preview/high | **유지 + 분할 검토** — 후보 19건/출력 62.9KB로 최장 워커. 상속·통지 vs 유치권·항변은 법리적으로 독립이므로 2분할 병렬화 가능 |
| PostB_2 adjudicator | exception pack 항목의 **제한된 선택 판정**(KEEP_SEPARATE/MERGE/SPLIT/DROP/BLOCK_REVIEW, 제공된 값 중 선택만 허용) | pro-preview/high + **ledger 전문 주입** | **강등 + 입력 교체** — bounded selection은 Part 1 v3 GB와 동일 성격. flash-lite/low~medium + pack 전용 입력으로 전환. 이번 실행 실측: 50→50 무변경 |
모델 판정 원칙은 Part 1 개정과 일관되게 한다: **일괄 하향이 아니라, 법률 추론이 실질인 곳(워커 B1/B4/B5)은 유지하고, 기계적 선택 판정(PostB_2)과 추출 성격 도메인(B2/B3)만 하향 또는 A/B 검증**한다.
---
## 4. 비효율 판정 목록 (F-1 ~ F-9)
| # | 심각도 | 비효율 | 실측 근거 |
|---|---|---|---|
| **F-1** | **중대** | PostB_2가 필요 입력(exception_pack, 추정 수 KB)의 수십 배인 **PostB_1 stdout 전문(ledger_candidates 50건 full payload 포함, 추정 200KB+)**을 pro-preview high로 읽음. 예외 0건이어도 항상 동일 규모로 실행 | 프롬프트 5091~5092행의 자기 인정 문구, ledger는 seed 206KB의 재직렬화본, 이번 실행 merge/drop 0 |
| **F-2** | **중대** | 워커 출력 206,681B 중 null/empty 스캐폴드(payload leaf 54%) + `transport_candidate_refs` 이중 배선(~10KB) + `slice_guard` 에코(~10KB)를 pro-preview **출력 토큰**으로 재생성 | §1.3-1~3 |
| **F-3** | **중대** | LLM 6호출 전부 pro-preview + reasoning high 일괄 적용 — PostB_2는 bounded selection, B2/B3는 추출 성격 | §3 판정표 |
| F-4 | 중 | 직렬 code task 12개의 기동·MCP 왕복 반복 + 동일 50건 후보의 5회 재직렬화(seed→join→ledger→compiled→BO) | §2 |
| F-5 | 중 | publisher가 쓴 seed 5파일을 domain_join이 즉시 재독해(왕복), Middle ×3가 BO.json(175KB)을 각각 재독해 | §2, 6145/6752/7173행 |
| F-6 | 중 | B0→워커 all-to-all wait (워커는 자기 B0 1개만 필요) | task_procedure 7343~7387행 |
| F-7 | 중 | **PostB_2가 워커 5개와 다른 커스텀 COMMON_CACHE_PREFIX 사용** — 같은 pro-preview 모델인데 프리픽스 캐시 공유 포기 (워커 5개는 바이트 동일, 내용은 Part 1 canonical과 동일하나 들여쓰기 상이) | prefix SHA 실측: 워커 5개 `adbdf43c…` 동일, PostB_2 `7207d2da…` 상이 |
| F-8 | 하 | Stage A stdout이 12개 task에 원문 주입(전송·재파싱 12회) — LLM 비용은 없음 | §1.3-5 |
| F-9 | 하 | BO.json 내부 중복(BO_ID==id, EvidenceTitles==Evidence.source_title 49/50, core_field_base.amount==amount.value 50/50, Reason 동일 문자열 50회) + `OUTPUT_SURFACE_HARD_RULE` 위반 시 publisher strict parser가 pro 재호출(max_iterations 2)을 유발할 수 있는 취약 결합 | §1.3-4 |
**Part 1과의 대조로 명확해지는 점**: Part 1 v2의 병목이 "LLM이 병합·재작성까지 수행"이었다면, Part 2의 병목은 "**LLM 호출의 입력·출력·모델이 전부 최대치로 설정**"된 것이다. 구조는 이미 올바르므로 개정은 호출의 다이어트에 집중한다.
---
## 5. 삭제·축소 안전성 판정 (하류 연계 근거)
| 산출물/구조 | 소비자 (grep 실증) | 판정 |
|---|---|---|
| `BO.json` (경로·item 스키마) | Part 3(5개소) · Part 4(3개소) | **불변** — 스키마 키 삭제 금지 |
| `actio_case_signals.json` / `case_liability_signals.json` / `legal_effect_signals.json` | Part 3(8/7/6개소) · Part 4(4/5/4개소) | **불변** |
| `extensions.domain_payload` | Part 3 `_domain_payload()`(304~308행), Part 4 `domain_payload_compact`(312~314행)가 **`.get()` 접근으로 compact 소비** | 필드 유지. 단 **null/empty 키 생략은 안전** (소비자가 키 부재를 기본값 처리) — F-2 슬리밍의 근거 |
| 도메인 5분할 구조, Stage A universe 가드, PostB_4 사전·사후 게이트, seed 파일 감사 체계 | Part 2 내부 품질 장치 | **유지** — 이 장치들 덕분에 Part 2에는 Part 1의 E-019류 소실 결함이 없다 |
| `transport_candidate_refs`, `slice_guard` 에코 | Part 3/4 소비 0건 (publisher/join 내부 검증용) | **LLM 출력에서 제거 가능** — publisher(code)가 `bo_seed_candidates[*].provenance`에서 결정적으로 재구성·검증 |
| BO_ID==id 등 내부 중복 필드 | v.2 BO 스키마 계약 (Stage 2 소비 범위 미확정) | **1차 개정에서는 유지** — Part 1 alias 판정과 동일하게, Stage 2 소비자 grep 확정 전 스키마 변경 금지 |
| PostB_2 task 자체 | 예외 판정 경로 (BLOCK_REVIEW 라우팅 포함) | **삭제 불가, 경량화만** — 예외가 실재하는 사건에서 병합·충돌 판정은 필요하다 |
---
## 6. 개정 전략 (권장안)
### 6.1 R-1: PostB_2를 Part 1 v3 GB 패턴으로 전환 (F-1, F-3, F-7 해소)
```text
[현행] PostB_1(code) ──ledger 전문 stdout──> PostB_2(pro/high, 항상 실행) ──> PostB_3
[개정] PostB_1(code) ──ledger stdout──────────────────────────────────────> PostB_3
└─ write: stage1_tmp/task_c_bo/postb_exception_pack.json (compact, 예외 항목+발췌만)
│
v
PostB_2' (flash-lite, reasoning=low~medium, use_tools: [localdocs], preflight_files: pack 1개)
- pack 파일 1개만 read. `has_exceptions == false`면 빈 decisions 저장 후 즉시 종료
- 출력: stage1_tmp/task_c_bo/postb_adjudication_decisions.json
- PostB_3는 decisions 파일을 read (STAGE_A/LEDGER 템플릿 유지)
```
- 근거: PostB_2의 판정은 "제공된 값 중 선택"으로 제한된 bounded selection이며, 이는 Part 1 v3에서 flash-lite/low로 확정한 GB와 동일한 작업 성격이다. 확신 없는 케이스는 이미 `BLOCK_REVIEW` enum으로 인간 검토 라우팅이 존재한다.
- 프리픽스는 워커 5개와 동일한 canonical COMMON_CACHE_PREFIX로 통일한다(F-7).
- 기대 효과: LLM 입력 ~200KB 제거, 예외 0건 사건(이번 실행이 그 사례)에서 사실상 0비용 통과.
### 6.2 R-2: 워커 출력 계약 슬리밍 (F-2 해소)
1. **null/empty 생략 계약**: OUTPUT_CONTRACT에 "값이 null/[]/{}인 키는 emit하지 않는다. 하류는 키 부재를 null로 해석한다"를 명시한다(Part 3/4의 `.get()` 소비 실증으로 안전). 스키마 예시는 전체 키를 보여주되 emit 규칙을 분리 기술한다.
2. **`transport_candidate_refs` 제거**: publisher(code)가 `bo_seed_candidates[*].candidate_ref + provenance`에서 결정적으로 재구성한다.
3. **`slice_guard` 에코 축소**: 워커는 `source_stage_a_created_at_utc`와 `input_digests_sha256`의 SHA 1개(요약 digest)만 반향하고, 전체 가드 대조는 publisher가 B0 slice(stdout 보존)와 직접 수행한다.
4. `llm_verbosity: medium → low` (JSON 산출 task에 medium 서술 여지가 불필요).
- 기대 효과: 워커 출력 30~45% 감소(206KB → 약 115~145KB) = pro-preview 출력 토큰·사고 토큰·벽시계 동시 감소. **candidate 실질 내용(법률 추론 결과)은 감소 폭에 포함되지 않는다.**
### 6.3 R-3: 모델 차등화 A/B (F-3 해소, 품질 가드 포함)
- PostB_2': flash-lite 확정(R-1).
- B2_Secured_Registry, B3_Land_Valuation: 7/10 fixture의 B0 slice를 고정 입력으로 `gemini-3.1-flash-preview`(또는 flash-lite/high) A/B 실행 → seed 후보의 (a) 후보 수·source ref 집합 동일성, (b) domain_review_queue 실질 동등성, (c) 변호사 육안 대조를 통과하면 하향 확정. **B1/B4/B5는 pro 유지**(법률 추론 실질).
- B5 분할 옵션: `B5a_Succession_Notice`(상속·통지)와 `B5b_Lien_Asset_Defense`(유치권·목적물·항변)로 2분할 — 법리적으로 독립 도메인이므로 결속 훼손 없음. 최장 워커 출력 62.9KB가 절반으로 나뉘어 워커 병렬 구간의 wall-clock 상한이 내려간다. B0 라우터 1개 추가 필요(터무니없는 비용 아님, code task).
### 6.4 R-4: code task 통합 및 DAG 수정 (F-4, F-5, F-6, F-8 해소)
| 통합 | 내용 |
|---|---|
| publisher + domain_join + PostB_1 → `Stage_B_join_and_ledger_compiler` 1개 | 워커 5개 stdout을 직접 받아 (a) 가드 검증·seed 5파일 write(감사 아티팩트 유지) (b) join (c) ledger 컴파일 + exception pack 파일 write까지 한 번에. write→re-read 왕복 제거 |
| PostB_3 + PostB_4 → `PostB_final_compile_gate_writer` 1개 | 컴파일과 게이트·write는 연속 결정 작업 |
| Middle ×3 → `Middle_signals_writer` 1개 | BO.json 1회 read로 signal 3파일 write (병렬 이득 없음 — 모두 수초짜리 code) |
| B0→워커 edge 수정 | 각 워커 `wait_until: [자기 B0 1개]`로 축소 |
- task 수 17 → 10, 직렬 code 구간의 기동·MCP 세션 왕복 약 7회분 제거. Stage A stdout 주입처도 12 → 7로 감소(F-8 부분 해소).
### 6.5 R-5: publisher 파서 관용화 (F-9 해소)
- SKILL.md §6.7의 `parse_llm_json` 패턴(코드펜스·잡음 결정적 salvage)을 통합 join task의 seed 파싱에 적용한다. `OUTPUT_SURFACE_HARD_RULE`은 유지하되, 규칙 위반 1회가 pro-preview 전체 재호출(max_iterations 2)로 이어지는 결합을 끊는다 — fence 제거는 기계 작업이지 LLM 재실행 사유가 아니다.
### 6.6 기대 효과 종합 (추정 명시)
| 항목 | 현행 | 개정 후 추정 |
|---|---|---|
| LLM 호출 | 6회 전부 pro/high | 정상 경로 5회(pro 워커) + flash-lite 소형 1회(예외 있을 때만 실질 작동) |
| PostB_2 입력 | ledger 전문 ~200KB+ | pack 수 KB (예외 0이면 즉시 종료) |
| 워커 출력 | 206.7KB | 약 115~145KB |
| task 수 / 직렬 code 구간 | 17 / 12개 | 10 / 5개 |
| 비용 | $4.28 | **$2.5~3.0 추정** (B2/B3 하향 확정 시 추가 하락) |
| 런타임 | 7:40 | **5분 내외 추정** (B5 분할 시 워커 구간 추가 단축) |
---
## 7. 이행 순서 및 검증 계획
1. **R-1 + R-5 먼저** (구조 변경 없이 최대 효과·최소 위험): PostB_1에 pack 파일 write 추가, PostB_2 교체, join 파서 관용화. fixture 회귀 — BO.json 50 items 바이트 수준 동등(Reason 등 결정적 필드 동일), 예외 0 경로에서 adjudicator 조기 종료 확인.
2. **R-2 + R-4**: 출력 계약 개정 + task 통합 → `Stage_1_Part_2_v3.yml`. fixture 회귀 — seed 후보 수 50±0(내용 동등성은 candidate_ref·source ref 집합으로 판정), BO.json이 Part 3 `LES0`/Part 4 `FL0` 파서를 통과, signal 3종 5/50/50 유지, `domain_payload` null-생략본에 대한 Part 3/4 compact 소비 정상 동작 확인.
3. **R-3 A/B**: 고정 B0 slice로 B2/B3 모델 비교 → 통과 시 하향 반영. B5 분할은 별도 실측 후 결정.
4. 재실행 계측: sub-task별 시간·토큰 telemetry(Part 1 개정과 동일 항목)를 붙여 v.6 대비 비용·런타임을 A/B 기록한다.
5. 회귀 불변 조건: `BO.json`·signal 3종의 파일 경로/envelope/스키마 키, PostB_4 게이트 의미론, `BLOCK_REVIEW` 라우팅, Stage A universe 가드.
---
## 부록 A. 근거 실측 로그 요약
- task 17개 중 LLM 6개(전부 gemini-3.1-pro-preview, reasoning=high), code 11개.
- 도메인 seed: B1 13/49,793B · B2 7/38,901B · B3 6/29,322B · B4 5/25,747B · B5 19/62,918B (합 50건/206,681B, 전부 READY_WITH_REVIEW, review 13건).
- BO.json: 50 items/175,126B, BO_ID 유일, seed→BO 50→50 (merge/drop 0), `Reason` 1종 보일러플레이트 ×50, `BO_ID==id` 50/50, `EvidenceTitles==Evidence[*].source_title` 49/50, `core_field_base.amount==amount.value` 50/50, domain_payload 바이트 29%·leaf null/empty 54%(782/1,451).
- COMMON_CACHE_PREFIX: 워커 5개 바이트 동일(sha `adbdf43c…`, stripped 내용은 Part 1 canonical `6e01f72f…`와 동일), PostB_2는 커스텀 프리픽스(sha `7207d2da…`).
- 하류 소비: BO.json → P3:5/P4:3, actio/case_liability/legal_effect signals → P3:8/7/6, P4:4/5/4. domain_payload는 P3 304~308행, P4 312~314행에서 `.get()` compact 소비.
- PostB_2 프롬프트 5091~5092행: "Full upstream object is provided only because some runtimes do not support stable nested field access. You must read only `postb_seed_ledger.exception_pack`."
@@ -0,0 +1,688 @@
# Stage 1 Part 2 비효율성 분석 및 최적화 전략
작성일: 2026-07-20
분석 대상: `Stage_1_Part_2_v2.yml`
실측 fixture: `Results_July_10_3_15pm`
## 0. 결론
Part 2의 7분 40초, $4.28이라는 비용은 단일 원인보다 다음 세 구조가 결합한 결과로 판단된다.
1. 5개 Stage B domain worker와 PostB adjudicator를 모두 `gemini-3.1-pro-preview/high`로 실행한다.
2. 약 50개 seed 전체가 든 PostB_1 객체를 예외 6건만 판정하는 LLM에 통째로 전달한다.
3. 같은 Stage A context를 5개 B0 router와 여러 후속 Python task에 반복 삽입하고, publisher, domain join, seed ledger, final compiler, final writer, 3개 signal writer를 별도 code-executor 호출로 직렬 연결한다.
최적 해법은 Stage B의 법률 도메인 분리는 유지하되 다음과 같이 실행 surface를 축소하는 것이다.
- Stage A normalization과 5개 B0 router를 Python task 1개로 통합한다.
- 5개 LLM worker는 유지하되 B1/B3에는 Flash, B2/B4/B5에는 Pro를 배치한다.
- LLM은 완성 schema가 아니라 sparse seed delta만 출력하고, null/빈 배열/default 채움은 Python이 수행한다.
- publisher, domain_join, PostB_1을 하나의 deterministic reducer로 통합한다.
- near-duplicate는 Stage 1에서 억지로 병합하지 않고 `KEEP_SEPARATE + review`로 결정한다.
- 최종 BO 작성에 반드시 필요한 비결정적 예외만 compact pack으로 조건부 LLM에 보낸다.
- PostB final compiler와 final gate/writer를 단일 Python writer로 통합한다.
- 3개 signal writer를 하나의 Python task로 통합하되 기존 3개 파일은 그대로 작성한다.
이 구조는 현재 20개 task를 통상 9개, 비결정적 예외가 있을 때 10개 안팎으로 줄인다. 외부 계약인 `BO.json`, `actio_case_signals.json`, `case_liability_signals.json`, `legal_effect_signals.json`은 변경하지 않는다.
## 1. 분석 범위와 전제
### 1.1 읽은 작업 명세
Stage 1 전체 연결을 다음 파일로 확인했다.
| Part | 기준 파일 | 역할 |
|---|---|---|
| Part 1 | `Stage_1_Part_1_Codex_v3.yml` | client goal, evidence index, event candidates, Part 1 gate handoff |
| Part 2 | `Stage_1_Part_2_v2.yml` | BO와 3개 signal 생성 |
| Part 3 | `Stage_1_Part_3_v1.yml` | legal effect structures 생성 |
| Part 4 | `Stage_1_Part_4_v2.yml` | Fact Ledger 생성 및 sealed gate 적용 |
질문의 method 1에는 첫 문장에서 `Codex_v3`를 지정한 뒤 목록에서 `Claude_v3`라고 적은 불일치가 있다. 최신 Part 1 작업 명세라는 문맥, 직전 개정 이력 및 명시적 지시를 우선하여 `Stage_1_Part_1_Codex_v3.yml`을 기준으로 분석했다.
### 1.2 판정 한계
- 전체 Part 2 런타임과 비용은 제공됐지만 task별 latency, input/output token, cache hit 로그는 결과 폴더에 없다.
- 따라서 특정 task가 정확히 몇 달러를 소비했다고 배분하지 않는다.
- 파일 크기, task/model 설정, DAG, 실제 산출물 수량 및 동일 규칙의 재계산 결과는 실측값이다.
- 성능 절감률은 목표와 검증 기준으로 제시하며 보장값으로 표현하지 않는다.
## 2. Stage 1 전체 handoff
```text
Part 1 Codex v3
client_goal.json
evidence_indexed.json
evidence_event_candidates.json
Part 1 quality gates / soft-gate handoff
|
v
Part 2 v2
BO.json
actio_case_signals.json
case_liability_signals.json
legal_effect_signals.json
|
v
Part 3 v1
legal_effect_structures.json
|
v
Part 4 v2
Fact_Ledger_base.json
```
Part 3의 LES0과 Part 4의 FL0은 Part 2의 `BO.json`과 3개 signal을 직접 읽는다. 반면 Part 2의 다음 중간 파일은 Part 3/4의 직접 입력이 아니다.
- `stage1_tmp/task_c_bo_stage_b_domain_seed_outputs/*.json`
- Stage B publisher stdout
- Stage B domain_join stdout
- PostB seed ledger stdout
- PostB compiled bundle stdout
따라서 Part 2 내부 task와 중간 artifact는 자유롭게 통합할 수 있다. 단, 다음 외부 불변식은 유지해야 한다.
| 외부 파일 | 유지할 핵심 계약 |
|---|---|
| `BO.json` | JSON array, 연속·유일 `bh#`, provenance, evidence, `extensions.domain_payload` |
| `actio_case_signals.json` | `schema_version`, `status`, `actio_case_signals[]` |
| `case_liability_signals.json` | `schema_version`, `status`, `case_liability_signals[]` |
| `legal_effect_signals.json` | `schema_version`, `status`, `bo_legal_effect_routes[]` |
## 3. 현재 Part 2 구조
### 3.1 현재 DAG
```text
+--> B0-B1 --+
+--> B0-B2 --+
IN -> Stage A normalize +--> B0-B3 --+-- 5x5 barrier --> 5 Pro/high workers
+--> B0-B4 --+ |
+--> B0-B5 --+ v
worker output publisher
|
v
domain_join
|
v
PostB_1 seed ledger compiler
|
v
PostB_2 Pro/high exception adjudicator
|
v
PostB_3 final BO compiler
|
v
PostB_4 final gate + BO writer
/ | \
v v v
actio signal liability legal effect
\ | /
OUT
```
각 worker는 자기 B0 slice만 prompt에 삽입한다. 즉, 5개 B0 결과 모두를 한 worker prompt에 합치는 직접적인 token fan-in은 없다. 그러나 모든 worker가 모든 B0 task 완료를 기다리므로 불필요한 전역 barrier가 존재한다.
### 3.2 task와 모델
| 구간 | task 수 | 실행 유형 | 모델/특징 |
|---|---:|---|---|
| Stage A | 1 | Python | 4개 주요 입력 normalize |
| Stage B0 | 5 | Python | 같은 Stage A 객체를 각 task가 다시 parse·route |
| Stage B | 5 | LLM | 모두 Gemini 3.1 Pro, reasoning high |
| publisher/domain join | 2 | Python | 5개 output 저장 후 재읽기·결합 |
| PostB | 4 | Python 3 + LLM 1 | adjudicator도 Gemini 3.1 Pro/high |
| Middle Input | 3 | Python | 같은 대형 upstream 4종을 각 task에 반복 삽입 |
| 합계 | 20 | Python 14 + LLM 6 | 모든 LLM이 Pro/high |
정적 규모는 다음과 같다.
| 항목 | 실측 |
|---|---:|
| Part 2 YAML | 7,462행, 446,306 bytes |
| Python task | 14개 |
| embedded Python | 5,630행, 287,323 bytes |
| B0 Python만 | 5개, 1,162행, 79,102 bytes |
| LLM task | 6개 |
| LLM 정적 prompt | 1,400행, 78,944 bytes |
## 4. 실행 결과 계측
### 4.1 Part 2 주요 산출물
| 파일 | 크기 | 수량/상태 |
|---|---:|---|
| `BO.json` | 175,126 bytes | BO 50건 |
| `actio_case_signals.json` | 9,990 bytes | signal 5건 |
| `case_liability_signals.json` | 15,565 bytes | signal 50건 |
| `legal_effect_signals.json` | 19,093 bytes | route 50건 |
| B1 domain seed | 49,793 bytes | seed 13, review 3 |
| B2 domain seed | 38,901 bytes | seed 7, review 3 |
| B3 domain seed | 29,322 bytes | seed 6, review 2 |
| B4 domain seed | 25,747 bytes | seed 5, review 3 |
| B5 domain seed | 62,918 bytes | seed 19, review 2 |
5개 domain worker 모두 `READY_WITH_REVIEW`를 반환했다. domain review item은 총 13건이다.
### 4.2 source routing 중복
worker output의 `slice_guard.source_universe` 기준 결과는 다음과 같다.
| Domain | meeting | event | evidence | seed |
|---|---:|---:|---:|---:|
| B1 Money/Successor | 14 | 17 | 11 | 13 |
| B2 Secured/Registry | 15 | 71 | 30 | 7 |
| B3 Land/Valuation | 11 | 12 | 8 | 6 |
| B4 Actio | 3 | 11 | 5 | 5 |
| B5 Succession/Notice/Lien/Asset/Defense | 41 | 71 | 30 | 19 |
전체 universe는 event 71개, evidence 30개, meeting clause 41개다. B2와 B5는 event/evidence universe 전체를 다시 싣는다. 도메인 간 합산/유일 수량의 중복 배수는 다음과 같다.
- meeting: `84 / 41 = 2.05x`
- event: `182 / 71 = 2.56x`
- evidence: `84 / 30 = 2.80x`
B2의 `변제`, `등기`, `말소`와 B5의 `점유`, `인도`, `목적물`, `항변`, `party_assertion` 등 넓은 keyword가 source-ref closure와 결합해 과다 routing을 만든다. 공유 source 자체는 법률상 필요할 수 있으므로 단순 배타 routing은 금지해야 한다. 다만 `직접 관련`, `참조 관련`, `검토 후보`의 3등급으로 분리하지 않고 모두 full authority record로 넘기는 현재 방식은 비경제적이다.
### 4.3 LLM output 비대화
5개 domain seed 파일을 compact JSON으로 환산하면 전체 126,955 bytes다.
- 실제 seed candidate 본체: 94,830 bytes
- transport metadata: 9,841 bytes
- transport candidate refs: 9,614 bytes
- review queue: 6,159 bytes
- handoff guard: 5,350 bytes
candidate 이외 반복 envelope가 전체의 약 25.3%다. 또한 candidate에서 `null`, `{}`, `[]` default를 제거한 sparse 표현을 실측하면 다음과 같다.
| Domain | 현재 candidate bytes | sparse bytes | 감소율 |
|---|---:|---:|---:|
| B1 | 24,910 | 12,701 | 49.0% |
| B2 | 16,862 | 10,621 | 37.0% |
| B3 | 13,411 | 9,944 | 25.9% |
| B4 | 11,855 | 8,233 | 30.6% |
| B5 | 27,792 | 20,171 | 27.4% |
| 합계 | 94,830 | 61,670 | 35.0% |
LLM이 full target schema를 매번 채울 이유가 없다. false/0처럼 의미 있는 값은 유지하고, null·빈 배열·빈 객체만 Python expander가 보충하면 candidate 출력만 약 35% 줄일 수 있다. 반복 envelope까지 줄이면 domain LLM output surface는 현재의 절반 안팎을 목표로 할 수 있다.
### 4.4 PostB adjudicator 입력 증폭
PostB_2 prompt는 “nested field access가 안정적이지 않다”는 이유로 `postb_seed_ledger.exception_pack`만 필요하면서 PostB_1 전체 stdout을 삽입한다.
7/10 fixture의 seed 50건에 PostB_1과 동일한 규칙을 적용한 재계산 결과:
- schema risk: 2건
- link ambiguity: 0건
- exact duplicate bucket: 0건
- near-duplicate cluster: 4개, candidate 8건
- 총 exception item: 6건
같은 규칙으로 만든 대략적 JSON 크기:
- exception pack: 18,124 bytes
- full PostB_1 object: 129,772 bytes
- 불필요한 LLM input 증폭: 약 7.16배
더구나 현재 PostB_2는 `has_exceptions=false`여도 Pro/high LLM을 호출해 `READY_NO_EXCEPTIONS`를 출력하게 되어 있다.
### 4.5 실제 BO 품질 신호
최종 BO 50건과 domain seed 50건을 `source_domain + Action + BOType + ActionType`로 대조한 결과 50건 모두 1:1 대응했다.
- merge, split, drop으로 core candidate가 달라진 흔적: 0건
- `PriorAct == null`: 50/50
- `Reason`: 50건 모두 사실상 generic template
- source evidence가 빈 BO: 2건
- 4억원 변제·채무 미특정 사실 2개로, meeting-only assertion을 BO화한 경우다.
이는 현재 PostB Pro/high adjudicator가 적어도 이 fixture에서는 seed 수와 핵심 값을 바꾸지 않았음을 의미한다. near-duplicate를 합치지 않은 것은 Stage 1 provenance 보존 관점에서 타당하다. 반면 `PriorAct`, `Reason`, `ReasonRefs`를 finalization 대상으로 선언했으나 실제로 유의미하게 채우지 못한 점은 품질 결함이다.
또한 13개 domain review의 상세 내용은 임시 domain seed 파일에는 있으나 최종 BO와 3개 signal에는 review id·source refs 형태로 직접 전달되지 않는다. signal은 `READY_WITH_REVIEW` status만 표시한다. 비싼 LLM이 생성한 상세 review prose가 downstream에서 구조적으로 소비되지 않는 셈이다.
## 5. 비효율성 판정
### P0-1. 모든 법률 worker에 Pro/high를 일률 배정
**판정:** 과잉 배정.
Stage B worker는 최종 청구원인이나 법률효과를 확정하지 않는다. prompt도 명시적으로 provisional seed 생성, null 보존, Stage 2 법리 확정을 요구한다. 따라서 모든 domain에 최고 모델을 쓰는 것은 역할 경계와 맞지 않는다.
다만 B2의 담보·등기·변제충당, B4의 사해행위·가액배상, B5의 상속·통지·유치권은 source grouping 자체가 복잡하다. 이 세 domain을 즉시 Flash-lite로 내리는 것은 권고하지 않는다.
### P0-2. PostB LLM에 full seed ledger 전달
**판정:** 가장 명확한 token 비경제성.
LLM은 예외 6건만 판정하지만 약 7배 큰 full object를 읽는다. full ledger는 artifact로 저장하고 LLM에는 exception pack만 전달해야 한다. 예외 0건에는 호출 자체가 없어야 한다.
### P0-3. Stage A context의 반복 전송
**판정:** 구조적 data amplification.
Stage A output 전체가 다음에 반복 삽입된다.
- 5개 B0 router
- worker output publisher
- domain_join
- PostB_1
- PostB_3
- PostB_4
- 3개 signal writer
모든 task가 full context를 필요로 하지 않는다. freshness와 source-universe 검증에는 digest와 compact manifest면 충분한 경우가 많다.
### P1-1. B0 5×5 barrier
**판정:** prompt fan-in은 아니지만 DAG barrier가 불필요하다.
각 worker는 자기 B0 output만 읽는다. 그런데 각 B0 task가 5개 worker 모두를 next로 지정하고, 각 worker는 B0 다섯 개를 모두 기다린다. 최소 수정은 one-to-one edge다.
```text
B0-B1 -> Worker-B1
B0-B2 -> Worker-B2
B0-B3 -> Worker-B3
B0-B4 -> Worker-B4
B0-B5 -> Worker-B5
```
권장 구조에서는 B0 전체를 하나의 router compiler로 통합하므로 이 barrier 자체가 사라진다.
### P1-2. B0 코드 5중 복제
**판정:** 유지보수와 실행 모두 비효율적.
5개 B0 task는 공통 parser, matcher, projection, taxonomy/hazard subset, Part 1 review routing 코드를 반복한다. 차이는 주로 `DOMAIN_CONFIG`다. config table과 공통 함수 1벌로 통합할 수 있다.
### P1-3. LLM이 default-filled full schema를 작성
**판정:** output token 낭비이며 schema 오류 가능성도 높인다.
`Reason:null`, `PriorAct:null`, 빈 `ReasonRefs`, 빈 downstream refs, 여러 빈 domain payload 필드는 전부 결정적 default다. Python이 채우는 편이 더 빠르고 정확하다.
### P1-4. publisher -> domain_join -> PostB_1의 연속 재직렬화
**판정:** 세 task를 하나의 deterministic reducer로 합칠 수 있다.
현재 publisher가 5개 LLM JSON을 검증·저장하고, domain_join이 다시 5개 파일을 읽어 project하며, PostB_1이 다시 seed ledger와 exception pack을 만든다. downstream은 이 세 stdout을 직접 소비하지 않는다.
### P1-5. signal writer 3개가 같은 대형 upstream을 반복 소비
**판정:** 단일 Python writer로 통합 가능.
세 task 모두 다음을 각각 삽입한다.
- Stage A output
- PostB seed ledger
- PostB compiled bundle
- B4 worker output
동일한 BO/source index를 한 번 읽고 메모리에서 3개 signal을 생성한 뒤 파일 3개를 쓰면 된다.
### P1-6. review prose 생성 비용과 handoff 불일치
**판정:** 현재 형태의 긴 `description` 생성은 비경제적.
review가 downstream 사실·법리 검토에 중요하다면 compact structured handoff로 보존해야 한다. 보존하지 않는다면 LLM이 긴 설명을 쓰게 해서는 안 된다.
권장 최소 필드:
```json
{
"review_id": "B2:R001",
"severity": "SOFT_WARNING|HARD_WARNING",
"issue_type": "closed enum",
"source_event_candidate_ids": [],
"source_evidence_indexes": [],
"source_meeting_clause_ids": [],
"downstream_owner": "C0|C2|C5|D|Stage2"
}
```
설명문은 fixed template로 Python이 생성하거나 downstream UI에서 렌더링한다.
### P2-1. 공통 cache prefix 범위가 좁고 adjudicator prefix가 다름
5개 worker의 common prefix hash는 동일하지만 공유되는 부분은 약 3.4KB에 그친다. output contract와 공통 authority rules의 상당 부분이 task별 block에서 반복된다. adjudicator는 다른 common prefix를 사용한다.
공통 rule과 compact seed-delta contract를 dynamic input보다 앞에 두고, 모든 LLM task의 `<COMMON_CACHE_PREFIX_STAGE_1>`을 바이트 동일하게 유지한다. task별 domain schema와 role은 prefix 밖 overlay로 둔다. 모델이 다르면 cache가 모델별로 나뉠 수 있으므로 Flash group과 Pro group 각각의 hit를 계측해야 한다.
### P2-2. 사용되지 않는 Stage-level 기본 모델
Stage에 `openai/gpt-4o-2024-08-06`가 선언돼 있지만 6개 LLM task 모두 자체 provider/model을 지정한다. 실행비용의 직접 원인은 아니나 오독과 fallback 위험을 없애기 위해 삭제하는 편이 낫다.
## 6. task별 유지·통합·삭제 판정
| 현재 task | 판정 | 개정 방향 |
|---|---|---|
| Stage A input normalization | 유지·통합 | B0 routing까지 한 Python task에서 수행 |
| B0 input 5개 | 삭제 | domain config table 기반 단일 router로 대체 |
| B1 worker | 유지·경량화 | Flash, sparse output |
| B2 worker | 유지 | Pro, input narrowing, sparse output |
| B3 worker | 유지·경량화 | Flash, sparse output |
| B4 worker | 유지 | Pro, actio named fields 보존 |
| B5 worker | 유지 | Pro, notice/lien/possession/asset named fields 보존 |
| worker output publisher | 삭제·통합 | reducer에 writer/validation 흡수 |
| domain_join | 삭제·통합 | reducer에 projection/index 흡수 |
| PostB_1 seed ledger compiler | 삭제·통합 | reducer가 ledger artifact와 exception pack 생성 |
| PostB_2 adjudicator | 조건부화 | non-deferrable compact exception만 Flash 판정 |
| PostB_3 final compiler | 통합 | final gate/writer와 단일 writer 구성 |
| PostB_4 final gate/writer | 유지·통합 | BO의 유일 writer 유지 |
| 3개 Middle Input task | 삭제·통합 | signal bundle writer 1개로 대체 |
## 7. 권장 최적화 구조
### 7.1 권장 DAG
```text
IN
|
v
A0 context + domain-slice compiler [Python]
| writes Stage A artifact, global manifest, 5 narrow slices
|
+--> B1 Money/Successor worker [Flash]
+--> B2 Secured/Registry worker [Pro]
+--> B3 Land/Valuation worker [Flash]
+--> B4 Actio worker [Pro]
+--> B5 Succession/Notice/Lien/Asset/Defense worker [Pro]
\ | /
\ | /
v v v
R0 seed reducer + schema expander + exception planner [Python]
| writes full seed ledger + compact review handoff
|
+--> no non-deferrable exception ----------------------+
| |
+--> compact exception pack -> R1 adjudicator_* [Flash]|
v
F0 final BO compiler + gate + single writer [Python]
|
v
S0 signal bundle writer [Python]
| writes the existing three signal files
v
OUT
```
### 7.2 권장 task 수
| 구분 | 현재 | 권장 |
|---|---:|---:|
| Python task | 14 | 4 |
| 상시 LLM task | 6 | 5 |
| 조건부 LLM | 0 | 0 또는 제한적 1~N |
| 총 task | 20 | 통상 9, 예외 시 약 10 |
### 7.3 A0 compiler 계약
입력:
- `client_meeting.md`
- `evidence_event_candidates.json`
- `evidence_indexed.json`
- `Default_Agent/Juristic_Act.md`
- `quality_gates/stage1_part1_soft_gate_handoff.json`
작업:
1. 현재 Stage A normalization과 동일한 source map 및 digest를 만든다.
2. global source universe를 별도 manifest 1개에만 저장한다.
3. 5개 domain config를 loop로 실행한다.
4. routing을 `primary`, `support`, `review_only`로 구분한다.
5. LLM slice에는 primary full compact record와 support ref/minimal summary만 넣는다.
6. domain별 source count와 max-byte budget을 검사한다.
출력 artifact 예시:
```text
stage1_tmp/task_c_bo/stage_a_context.json
stage1_tmp/task_c_bo/source_universe_manifest.json
stage1_tmp/task_c_bo/domain_slices/B1.json
stage1_tmp/task_c_bo/domain_slices/B2.json
stage1_tmp/task_c_bo/domain_slices/B3.json
stage1_tmp/task_c_bo/domain_slices/B4.json
stage1_tmp/task_c_bo/domain_slices/B5.json
```
stdout에는 full context를 넣지 않고 다음 manifest만 둔다.
```json
{
"status": "READY",
"stage_a_path": "stage1_tmp/task_c_bo/stage_a_context.json",
"source_manifest_path": "stage1_tmp/task_c_bo/source_universe_manifest.json",
"domain_slice_paths": {"B1": "...", "B2": "...", "B3": "...", "B4": "...", "B5": "..."},
"input_digests_sha256": {}
}
```
### 7.4 routing 개선 원칙
1. broad Korean noun 하나만으로 primary routing하지 않는다.
2. `event_kind`, `event_subkind`, `doc_type`, `legal_effect_candidate`, named component, registry/fraction/notice/lien key를 keyword보다 우선한다.
3. `등기`, `변제`, `항변`, `점유`, `목적물` 같은 broad term은 보조 신호로만 쓴다.
4. source-ref closure로 따라온 항목은 `support` 등급으로 표시한다.
5. B5가 모든 사건의 catch-all이 되지 않도록 succession, notice, lien, possession, asset_alias, defense의 activation reason을 각각 기록한다.
6. source를 다른 domain에서 제거하지 않는다. 중복 허용과 full-payload 중복은 구분한다.
7. 한 domain slice가 전체 event/evidence universe의 일정 비율을 넘으면 자동 실패시키지 말고 `ROUTING_BROADNESS_WARNING`을 기록한다.
권장 audit 필드:
```json
{
"primary_ids": [],
"support_ids": [],
"review_only_ids": [],
"activation_reasons": [],
"source_count": {},
"slice_bytes": 0,
"broadness_ratio": 0.0
}
```
### 7.5 LLM sparse output 계약
LLM은 다음만 출력한다.
- domain id와 status
- candidate ref
- 의미 있는 BO 분류값
- 짧은 Action
- source refs
- 채워진 domain payload 값
- compact review code
다음은 출력하지 않는다.
- 반복 input digest와 global source universe
- 별도 `transport_candidate_refs`
- 항상 null인 `Reason`, `PriorAct`
- 항상 빈 `ReasonRefs`
- 항상 빈 downstream seed refs
- schema를 맞추기 위한 빈 dict/list/null field
- 긴 review description
R0 Python이 canonical schema로 확장한다. expander는 누락을 임의 사실로 채우지 않고 schema default만 채운다.
### 7.6 모델 배치
| Task | 권장 모델 | reasoning | verbosity | 근거 |
|---|---|---|---|---|
| B1 Money/Successor | `gemini-3.5-flash` | high | low | source grouping과 provisional seed, 최종 법리 판단 아님 |
| B2 Secured/Registry | `gemini-3.1-pro-preview` | high | low | 지분·담보·변제충당·등기 chain의 높은 오류비용 |
| B3 Land/Valuation | `gemini-3.5-flash` | medium | low | 상태/가액 source grouping 중심 |
| B4 Actio | `gemini-3.1-pro-preview` | high | low | 피보전채권·무자력·담보공제·가액배상 구조가 핵심 |
| B5 Succession/Notice/Lien/Asset/Defense | `gemini-3.1-pro-preview` | high | low | 여러 고위험 법률 구조가 결합됨 |
| conditional exception adjudicator | `gemini-3.5-flash` | medium | low | closed decision enum, compact candidate만 사용 |
B1/B3를 Flash-lite까지 낮추는 것은 1차 개정에서 권고하지 않는다. 먼저 Flash로 fixture 동등성을 검증한 후에만 추가 하향한다.
### 7.7 R0 deterministic reducer
R0는 다음을 한 번에 수행한다.
1. 5개 LLM JSON strict parse
2. domain id, source membership, candidate ref 검사
3. sparse candidate를 full schema로 확장
4. global candidate index와 source index 생성
5. exact duplicate, near duplicate, schema risk, link ambiguity 검사
6. review code 정규화
7. full seed ledger artifact 저장
8. compact exception pack 생성
9. adjudicator fan-out descriptor 또는 no-exception marker 출력
권장 artifact:
```text
stage1_tmp/task_c_bo/postb_seed_ledger.json
quality_gates/stage1_part2_review_handoff.json
quality_gates/stage1_part2_exception_pack.json
```
stdout에는 full ledger를 넣지 않는다.
### 7.8 LLM에 보내지 않을 예외
다음은 deterministic policy로 처리한다.
| 예외 | 처리 |
|---|---|
| exact byte/schema duplicate | provenance union이 무손실일 때만 canonical merge |
| near duplicate | `KEEP_SEPARATE`, shared cluster id와 review code 부여 |
| meeting-only candidate | 보존, `MEETING_ONLY_EVIDENCE_GAP` warning |
| optional PriorAct 불명 | null 유지, review code |
| Stage 2 법리 확정 필요 | `legal_theory_required`, LLM 호출 금지 |
| source ref가 universe 밖 | BLOCK |
| 필수 schema type/enum 오류 | BLOCK 또는 mapper rerun |
7/10 fixture의 4개 near cluster와 meeting-only schema risk 2건은 위 정책으로 모두 결정적 처리할 수 있다. 따라서 이 정책 기준 fixture의 PostB LLM 호출 목표는 0회다.
### 7.9 조건부 adjudicator에 보낼 예외
다음 조건을 모두 충족할 때만 LLM을 실행한다.
1. final BO writer가 진행하려면 하나의 값을 선택해야 한다.
2. 둘 이상의 source-backed candidate가 존재한다.
3. 두 값을 모두 보존하거나 Stage 2로 defer할 수 없다.
4. compact payload가 판정에 충분하다.
LLM이 불충분하다고 판단하면 `BLOCK_REVIEW`를 반환한다. full Stage A, raw evidence, full seed ledger를 읽게 해서는 안 된다.
### 7.10 F0 단일 BO writer
PostB_3과 PostB_4를 통합한다.
F0는 다음 순서로 실행한다.
1. seed ledger artifact read + digest 확인
2. conditional adjudication part가 있으면 exception id coverage 확인
3. candidate conservation 확인
4. deterministic ordering과 `bh#` 부여
5. source evidence object 구성
6. `Reason`, `PriorAct`, `ReasonRefs` 정책 적용
7. BO schema 및 reference gate
8. `BO.json` 1회 write
9. reread, JSON parse, SHA-256 및 count 검증
`Reason`은 generic prose를 길게 생성하지 않는다. source chain이 없으면 fixed enum/code와 짧은 template을 사용하고, 명시적 prior link가 있을 때만 `PriorAct`/`ReasonRefs`를 채운다. 최종 법적 인과관계를 Stage 1이 임의 확정하지 않는다.
### 7.11 S0 signal bundle writer
세 signal task를 하나로 통합한다.
입력:
- `BO.json`
- source universe manifest
- 필요한 경우 seed ledger의 compact index
출력:
- `actio_case_signals.json`
- `case_liability_signals.json`
- `legal_effect_signals.json`
각 파일의 기존 schema와 status 규칙을 유지한다. BO를 한 번 읽고 3개 projection을 메모리에서 만든다.
## 8. 최소 개정 우선순위
전체 구조 개정 전에 가장 적은 수정으로 효과를 확인하려면 다음 순서가 적절하다.
### Phase 1: 즉시 적용
1. B0와 worker의 5×5 edge를 one-to-one으로 수정한다.
2. B1/B3 모델을 Flash로, 모든 worker verbosity를 low로 변경한다.
3. PostB_1이 full ledger를 artifact로 저장하고 stdout에는 exception pack만 반환하게 한다.
4. near duplicate와 meeting-only risk를 deterministic defer 대상으로 바꾼다.
5. PostB adjudicator를 조건부 Flash task로 변경한다.
6. 모든 LLM의 common prefix를 동일한 full prefix로 교체하고 role overlay를 분리한다.
### Phase 2: 구조 통합
1. Stage A와 5개 B0를 A0 compiler로 통합한다.
2. worker output을 sparse delta schema로 변경한다.
3. publisher, domain_join, PostB_1을 R0 reducer로 통합한다.
4. PostB_3/4를 F0로 통합한다.
5. 3개 signal task를 S0로 통합한다.
Phase 1 결과로 비용·시간이 충분히 줄어도 Phase 2의 full-object handoff와 중복 Python 유지보수 문제는 남는다. 최종 v3에는 Phase 2까지 반영하는 것을 권고한다.
## 9. 회귀 및 성능 검증
### 9.1 정적 검증
- YAML parse 성공
- task name 중복 0
- DAG unreachable task 0
- old task reference 0
- 모든 embedded Python syntax compile
- localdocs full boilerplate 및 user/workspace hash 전달
- `BO.json` writer 정확히 1개
- 각 signal 파일 writer 정확히 1개
- 모든 LLM common cache prefix hash 동일
- stage-level 미사용 model 제거
### 9.2 7/10 fixture 품질 불변식
1. evidence index 30개와 event candidate 71개의 source universe를 보존한다.
2. 모든 최종 BO source ref는 Part 1 universe의 subset이어야 한다.
3. 모든 Stage B candidate ref는 다음 중 하나로 추적돼야 한다.
- 최종 BO 1건
- provenance-union merge의 absorbed ref
- BLOCK/blocked review item
4. B4 actio payload의 preserved claim, transfer, encumbrance, valuation, cap, defense 정보가 소실되지 않는다.
5. B5의 notice lifecycle, lien state, possession two-track, asset alias named fields가 소실되지 않는다.
6. 13개 기존 review item의 issue type과 source refs가 compact handoff 또는 BO review flag로 보존돼야 한다.
7. meeting-only BO 2건은 자동 삭제하지 않는다.
8. Part 3 LES0 및 Part 4 FL0 smoke test를 통과한다.
BO 수 50 자체를 절대 불변식으로 두지는 않는다. 다만 candidate conservation과 provenance union을 만족하지 않는 감소는 금지한다. 1차 구현에서는 안전을 위해 50건 보존을 기준값으로 삼는 것이 좋다.
### 9.3 성능 합격 기준
| 지표 | 현재 | 1차 목표 |
|---|---:|---:|
| Part 2 총 task | 20 | 10 이하 |
| 상시 Pro/high LLM | 6 | 3 이하 |
| PostB LLM input | 약 130KB 재구성값 | exception pack만, 20KB 안팎 |
| 7/10 fixture PostB LLM | 1회 | 0회 목표 |
| compact domain output | 126,955 bytes | 70,000 bytes 이하 목표 |
| runtime | 7분 40초 | 5분 이내 1차 목표 |
| cost | $4.28 | $2.50 이하 1차 목표 |
runtime과 cost 목표는 동일 provider 가격·부하 조건에서 3회 이상 반복 실행한 중앙값으로 판정한다. 품질 불변식을 하나라도 위반하면 성능 목표를 달성해도 실패다.
## 10. 최종 권고
Part 2의 도메인별 법률 추론 자체를 하나의 거대 LLM 호출로 합치는 것은 권고하지 않는다. 금전채권, 담보·등기, 토지·가액, 사해행위, 상속·통지·유치권의 판단 경계가 달라 prompt가 더 커지고 실패 blast radius가 커진다.
반대로 현재처럼 모든 전후 처리와 schema 채움을 task별로 잘게 분리하고, 모든 도메인에 Pro/high를 쓰는 것도 적절하지 않다.
가장 효율적인 개정은 다음 한 문장으로 요약된다.
> **도메인 LLM 5개는 유지하되 입력과 출력을 절반 수준으로 줄이고 모델을 차등 배치하며, 그 앞뒤의 14개 Python task를 4개 deterministic compiler/reducer/writer로 통합하고, LLM 예외 판정은 non-deferrable compact exception에만 허용한다.**
이 방식이 현재 Part 2의 법률적 provenance, named domain payload, Part 3/4 handoff를 보존하면서 runtime과 비용을 동시에 줄이는 최적 경로다.
@@ -0,0 +1,155 @@
# Stage 1 Part 3 개정 전략 선별 보고서 (Claude v1)
- 비교 대상: `Part_3_Inefficiency_Report_Claude_v1.md` ↔ `Part_3_Inefficiency_Report_Codex_v1.md`
- 목적: 두 분석의 교차 검증·상충 판정을 거쳐 Part 3 개정에 가장 적합한 전략을 선별
- 선별 기준: 최소의 노력(LLM 추론은 꼭 필요한 곳에 필요한 수준만, 100% 결정론 작업은 Python화, 토큰 경제성 최대화)으로 최대의 효과(최고 품질 유지, 토큰 경제성 증대, 에이전트 속도 최대화)
- 작성 관점: 20년 이상 경력의 대한민국 최고 수준 변호사 + 세계적 수준의 AI 아키텍트
## 0. 총평
두 보고서는 서로 다른 방법으로 같은 결론에 도달했다. Claude 보고서는 Part 3 전체 코드를 7/10 실행물로 **바이트 일치 재실행**하여 데이터 흐름과 LLM 판정의 실효성을 실측했고, Codex 보고서는 YAML 계약 추적과 산출물 계측으로 **예외가 과잉 생성되는 원인 메커니즘**을 해부했다. 핵심 진단 8개 항목이 독립적으로 일치하므로 사실 기반은 매우 견고하다. 차이는 처방의 결에 있다: Claude는 구조 통합(4→3 task)과 결정론 defer로 "전송·호출 자체의 소거"를, Codex는 타입 어휘 정규화와 상태 모델 교정으로 "예외 발생 원인의 소거"를 겨냥한다. 이 둘은 경합하지 않고 **정확히 상호보완**이며, 본 보고서는 두 축을 모두 채택한 통합 골격을 확정한다. 한편 공통 캐시 프리픽스에 대해서는 두 보고서의 판정이 상충하는데, 3-way 바이트 재실측 결과 **양쪽 모두 부분적으로 부정확**했음을 확인하고 §3에서 공개 정정한다.
## 1. 비교 분석
### 1.1 비효율 판정 항목 비교
**양측 공통 판정 (독립 교차 검증 — 신뢰도 최상).** 다음 8개는 두 보고서가 서로 다른 방법으로 동일하게 확인했으므로 개정의 확정 근거로 삼는다.
| # | 공통 판정 | Claude 근거 | Codex 근거 |
|---|---|---|---|
| 1 | LES2가 예외 유무와 무관하게 상시 실행 | P3-6 | §1-1 |
| 2 | 예외 과잉 생성 → BO 50건 전부 예외화 (47건) | P3-7 | §5.1 |
| 3 | LES2 판정 30건 중 28건 BLOCK_REVIEW (93%) | P3-7 실측 | §5.2 실측 |
| 4 | budget_overflow 17건이 LLM도 못 보고 자동 차단 | P3-8 | §5.4 |
| 5 | 성공 판정이 review_required를 해제하지 못함 → 50/50 포화, 큐 78건 | P3-9 | §5.3 |
| 6 | input pack 대형 물질화 + 미사용 필드(bo_by_id·signals_by_bo_id·events·client_goal) | P3-1·P3-2 (55% 미사용 실측) | §5.5·§5.6 (동일 필드 판정) |
| 7 | seed bundle 중복(진단·type_index_seed·내장 exception pack) + 별도 pack 파일 소비자 0 | P3-4 | §5.7 |
| 8 | 실패 시 `sys.exit(0)` — 실패의 정상종료 위장 | P3-14 | §5.10 |
양측의 크기 계측이 수 KB 단위로 다른 것(예: bo_by_id 82.7KB vs 89.0KB)은 직렬화 기준 차이일 뿐 판정은 동일하다.
**Claude 보고서 고유 발견 (Codex 미포착).**
- **LES3 `SEED_RAW` 주입의 구조적 사장(P3-5)**: LES1 stdout의 루트 키에 `legal_structure_seed_bundle`이 존재하지 않아 LES3의 stdout 파싱이 **100% 실패**하고 매 실행 422KB 파일을 재읽는다. Codex는 LES0→LES1의 이중 채널만 지적했고 LES3의 dead injection은 포착하지 못했다. 32.6KB 주입 제거 + 파일 읽기 일원화의 직접 근거.
- **LLM 부가가치 0의 최종 산출물 수준 실증**: 구조물 50건 전부의 대표 타입이 결정론 우선순위 규칙(priority-first)과 100% 일치하고 split 0건임을 실측 — Codex의 "비차단 판정 2건뿐"(과정 증거)을 넘어, **LES2를 결정론 기본값으로 대체해도 최종 파일이 동일**하다는 결과 증거다. 결정론 defer의 무손실성을 보증하는 가장 강한 근거.
- **`evidence_all.json`(87KB) 기여 0의 실험적 확정**: 포함/제외 재실행 비교로 evidence authority 30건 전부 동일함을 증명. Codex는 같은 제거를 "coverage 검증 후 조건부"로 남겼는데, Claude 실측이 그 조건을 이미 충족시켰으므로 **무조건 제거로 격상**한다.
- 바이트 일치 재현 방법론: 중간 파일 3종(416,115/422,236/52,982B)의 재현 일치로 모든 수치의 신뢰성을 담보.
**Codex 보고서 고유 발견 (Claude 미포착 — 채택 가치 높음).**
- **타입 어휘 오염의 정량 해부(§5.1)**: `candidate_structure_types`에 canonical 법률구조 family 외에 `event`/`state`, 행위 분류(법률행위 등), 세부 사건명(변제·상계 등)까지 승격되어 출현 263회·distinct 69종에 이르고, **canonical enum만 남기면 복수 role BO가 50→14로 감소**한다는 실측. Claude 보고서가 "합집합 과다"로 뭉뚱그린 원인을 어휘 수준에서 해부해, 예외 발생 자체를 상류에서 줄이는 처방(closed enum)의 근거를 만들었다. 법률적 논거도 타당하다: 하나의 사실이 대여금·승계책임·사해행위에 동시 연결되는 것은 모순이 아니라 대체적·예비적 청구를 보전하는 정상적 다중 라우팅이다.
- **multi-routing의 최종 인덱스 미반영(§5.3.1)**: LES3가 `by_bo_id`·`by_candidate_structure_type` 인덱스에 대표 타입 하나만 넣어, PRESERVE_MULTI_ROUTING 판정이 나와도 전체 canonical 타입이 인덱스로 전달되지 않는다. 코드 재확인 결과 사실이다(by_type은 `structure["candidate_structure_type"]`만 키로 사용). LLM 판정의 downstream 효용을 더 낮추는 실재 품질 결함.
- **asset ref-first 결정 규칙(§5.8)**: 자산 동일성은 fuzzy 라벨 유사도가 아니라 `REG-*`/`SCH-*` 등기행·별지목록 ref가 우선한다는 원칙. 실측 asset 예외 6건의 다수가 `SCH-016-01 ↔ 성수동 256 대` 같은 ref-라벨 쌍이므로, ref 우선 규칙만으로 예외가 소멸한다. 법률상으로도 권리객체 오병합을 막는 더 안전한 규칙.
- **`SPLIT_BATCH_THEN_BLOCK`의 명칭-실행 불일치(§5.4)**: phase 2가 DAG에 없어 실제로는 TRUNCATE_THEN_BLOCK이며, 사건이 복잡할수록 검토가 줄어드는 역설을 명시.
- **`pending_exception_ids` 상태 모델 설계(§7.1 P0)**: review 신호 복원을 boolean 해제가 아니라 exception ID 단위 상태 재계산(`expected = resolved ∪ blocked ∪ deterministic_review` coverage 등식)으로 설계 — Claude R-5보다 엄밀하다.
**상충 판정 1건 — 공통 캐시 프리픽스.** Claude 보고서는 "Part 1/2 canonical과 바이트 동일(58f2b72d) — 유지 자산", Codex 보고서는 "Part 1·2 v3(3,385B, 6e01f72f)와 불일치 — 교체 필요"로 정반대다. 3-way 바이트 재실측 결과:
| 파일 | 프리픽스 블록 | SHA-256 앞 12자리 |
|---|---:|---|
| Part 3 v1 (LES2) / Part 4 v2 | 3,829B (들여쓰기 포함 원형) | 58f2b72d6c26 |
| Part 2 Claude v3 (워커 5 + R1) | 3,829B | 58f2b72d6c26 |
| Part 1 Claude v3 / Part 1 Codex v3 | 3,385B (들여쓰기 제거형) | 6e01f72f1803 |
즉 **두 보고서 모두 반쪽만 봤다**: Claude는 Part 2 라인만 대조해 "동일"로, Codex는 Part 1 계열만 대조해 "불일치"로 판정했다. 실상은 배포본 자체가 Part 1(3,385B) ↔ Part 2·3·4(3,829B)로 이원화되어 있다. 판정은 §2 X-11에서 확정한다(요지: 캐시 실익은 같은 모델 간에만 발생하므로, Part 3 L1은 직전 실행되는 같은 모델의 Part 2 R1 블록(3,829B)과 정합시키는 것이 적중 확률이 가장 높고, Part 1 GB의 3,829B 정렬은 별도 1줄 후속 작업으로 제안).
### 1.2 실행구조·병목 비교
완전 직렬 4-task 체인이라는 구조 인식은 동일하다. 병목 규명은 상호보완적이다: Claude는 **전송 병목**을 바이트 흐름으로 계량했고(pack 3중 물질화 930KB, LES1 run_code 페이로드 297KB, LES3의 422KB 상시 재읽기, stdout 총 290KB), Codex는 **LLM 병목의 원인**을 계량했다(어휘 오염 → 50/50 예외 → 30건 monolithic 프롬프트 — 단일 대형 프롬프트의 항목 간 주의력 경쟁·JSON 누락 위험 지적 포함). Codex가 스스로 인정했듯 task별 타임스탬프가 없어 구간별 소요는 양쪽 다 추정이지만, $0 비용·3:40 실측에서 LLM 구간(reasoning high·30건 판정·28건 차단 사유 서술)과 대형 페이로드 왕복이 지배 요인이라는 결론은 공유된다. 종합하면 병목 제거는 두 축을 모두 요구한다: **(a) 예외를 애초에 만들지 않는 상류 정규화(Codex 축), (b) 그래도 남는 전송·호출의 구조적 소거(Claude 축).**
### 1.3 삭제/축소 안전성 비교 (downstream 근거)
최종 계약에 대한 판정은 완전히 일치한다: `legal_effect_structures.json`의 스키마·status·5-way index는 Part 4 FL0가 직접 검증하고 FL2는 LES 모호성을 재판정할 수 없으므로 **불변 계약 + review 신호 약화 금지**다. 중간 아티팩트 삭제 판정도 필드 단위로 일치한다(§1.1 공통 6·7). 양측 판정을 병합한 안전성 표는 다음과 같다.
| 대상 | 판정 | 근거 (양측 합산) |
|---|---|---|
| 최종 파일명·스키마·5-way index | 변경 금지 (additive 확장만 허용) | Part 4 validator 직접 검증 (양측 일치) |
| BO/evidence conservation 게이트 | 유지·강화 | 구조 누락은 Fact Ledger 누락으로 전파 (Codex §6) |
| unresolved 예외·review 신호 | 삭제 금지, **재계산으로 정밀화** | FL2 재판정 불가 (양측); coverage 등식으로 봉인 (Codex P0) |
| pack의 bo_by_id·signals_by_bo_id·events·client_goal | 삭제 확정 | 소비 0 실측 (양측 독립 확인) |
| `evidence_all.json` read | **무조건 삭제로 격상** | Codex "조건부" + Claude 포함/제외 실험 기여 0 → 조건 충족 |
| `evidence_event_candidates.json`·`client_goal.json` read | 삭제 확정 | related_event_candidates까지 미소비 (Codex §5.5, Claude 소비표와 정합) |
| seed bundle의 진단·type_index_seed·내장 pack | 삭제/외부화 확정 | LES3 참조 0회 (양측); exception pack은 단일 authoritative 파일화 |
| LES3 SEED_RAW 주입 | 삭제 확정 | 100% 사장 실증 (Claude 고유) |
### 1.4 권장 개정 전략 비교와 판정
| 쟁점 | Claude 제안 | Codex 제안 | 판정 |
|---|---|---|---|
| task 골격 | LES0+LES1 병합 → 3-task (L0→L1→L2) | 4-task 유지, 병합은 2차 보류 (§7.7) | **병합 채택.** Part 2 개정에서 publisher+domain_join+PostB_1→R0 3,000행 병합을 함수 단위 이식 + 골든 회귀로 이미 실증했고, LES0·LES1은 소비자가 파이프 내부뿐인 순수 결정론 체인이라 위험이 더 낮다. 병합 시에만 pack 3중 물질화(930KB)가 통째로 소멸한다. Codex의 책임 경계 우려는 코드 내부 함수 경계(컴파일러부/시드부)로 대응 |
| LLM 형태 | 단일 조건부 태스크 (Part 2 R1 골격) | wildcard fan-out (pack당 3~4건, 병렬 2) | **단일 조건부 태스크 채택.** 양측 모두 개정 후 예외 실질 0회를 기대하는 상황에서 fan-out 기계장치는 복잡도 과잉이다. Codex 자신의 pack 한도(항목 3~4·12KB)는 잔여 예외의 pack 구성 규칙으로 흡수하고, 사건 다양화로 예외가 상시 다건 재발하면 그때 wildcard로 확장한다(D-1) |
| 예외 축소 방법 | 보존적 defer 기본값 (PRESERVE/SEPARATE) + 4중 조건 pack | canonical enum 정규화 + ref-first 자산 규칙 + 진짜 비가역성만 LLM | **양측 병행 채택.** Codex 축이 예외 발생을 상류에서 줄이고(50→14 복수 role), Claude 축이 잔여를 결정론으로 처리해(대표타입 100% 일치 실증) LLM행을 0으로 만든다. 순서: 정규화 먼저, defer는 그 뒤 안전망 |
| review 모델 | 판정 반영해 review_required 해소 | pending_exception_ids + ID 단위 재계산 + coverage 등식 | **Codex 설계 채택** (Claude 방향과 동일하되 더 엄밀) |
| LES2 모델/사양 | flash-lite/low (R1 정합) + BLOCK_REVIEW 안전판 | flash-lite, reasoning medium, verbosity low | **flash-lite/low 채택.** 잔여 예외는 판정 불충분 시 BLOCK_REVIEW로 인간 검토에 안전하게 떨어지므로 low로 충분하며 Part 1 GB·Part 2 R1과 사양 문법이 통일된다. 비용은 이미 $0이므로 이 선택의 목적은 속도·일관성 |
| 프리픽스 | 현행 유지 (부분 오판) | 3,385B로 교체 (부분 오판) | **§3 정정 후 X-11로 확정**: L1은 Part 2 R1과 동일한 3,829B 블록(같은 모델·직전 실행·TTL 내 적중 가능). Part 1 GB의 3,829B 정렬은 별도 후속(D-2) |
| multi-routing 인덱스 반영 | (미포착) | named field + 전 타입 인덱싱 (§5.3.1) | **채택 (additive 한정).** 필수 필드 추가·기존 키 변경 없이 additive로만 — Part 4 validator는 필수 키만 검사하므로 양립 |
## 2. 선별된 개정 전략 (최소 노력 / 최대 효과)
### 2.1 개정 골격 — 4 task → 3 task
```text
IN → L0_structure_seed_reducer (Python; LES0+LES1 병합. pack 비물질화·canonical 정규화·
| ref-first 자산 규칙·defer 정책·exception pack/slim seed 파일 write)
↓
L1_exception_adjudicator (LLM 조건부; gemini-3.1-flash-lite/low/low, preflight=pack 1파일.
| has_exceptions=false → no-exception 판정 파일 write 후 즉시 종료.
↓ 실측 근거상 실질 0회)
L2_final_structure_index_writer (Python; SEED_RAW 제거, pending_exception_ids 재계산,
| multi-routing additive 인덱싱, conservation 게이트, 단독 writer)
↓
OUT
```
Part 1 v3(GA→GB→GC)·Part 2 v3(A0→워커→R0→R1→F0→S0)와 동일한 "결정론 reducer → 조건부 adjudicator → 결정론 writer" 문법으로 Stage 1 전체가 통일된다.
### 2.2 채택 작업 목록
| ID | 작업 | 출처 | 핵심 근거 | 기대 효과 |
|---|---|---|---|---|
| X-1 | **canonical routing enum 정규화**: `candidate_structure_types`를 Part 4가 role로 해석하는 canonical 10종으로 제한하고, 비-routing 라벨(event/state·행위분류·세부사건명)은 `nonrouting_labels`로 보존(삭제 아님) | Codex P2 | 출현 263/distinct 69 → 복수 role BO 50→14 | 예외 발생 원인 소거 |
| X-2 | **multi-routing 보존 기본값**: canonical 복수 타입은 전부 보존 + 대표는 고정 priority — 복수 타입 자체는 예외 아님 | 양측 | 대표타입 50/50 결정론 일치 실증 (Claude) | type 예외 24건 → 0 |
| X-3 | **asset ref-first 동일성 규칙**: 동일 `REG-*`/`SCH-*` ref → 동일 클러스터 확정, Part 2 `asset_alias` ref-라벨 연결 활용, ref 상이 → 클러스터 분리+번들 보존, ref 없는 자유문구 → SEPARATE + review (임의 병합 금지) | Codex §5.8 + Claude 보존 기본값 | asset 예외 6건 다수가 ref-라벨 쌍 | asset 예외 6건 → ~0 |
| X-4 | **4중 조건 pack 수록 한정** (Part 2 X-3 이식): ①writer가 단일 값 선택 필수 ②source-backed 후보 2+ ③보존·defer 불가 ④compact 근거로 판정 충분 — 충족 항목만 LLM행. budget cap은 잔여가 소수이므로 사실상 소멸(초과 시 자동차단이 아니라 pack 분할을 기본으로 명세) | Claude + Codex §5.4 | LES2가 93%를 "근거 불충분" 차단 → ④ 사전 적용이 곧 그 판정 | LLM 호출 실질 0회, 17건 임의 절단 소멸 |
| X-5 | **pending_exception_ids 상태 모델**: seed의 boolean 대신 예외 ID 목록. L2가 resolved/blocked/split/auto_review를 ID별 재계산, `expected = resolved ∪ blocked ∪ deterministic_review` coverage 등식 강제, 미지 ID·중복 판정·후보 밖 값 hard fail | Codex P0 | 50/50 포화·큐 78건 실측 | review 신호 변별력 복원 — 변호사가 봐야 할 것만 큐에 |
| X-6 | **multi-routing의 최종 인덱스 반영 (additive)**: 구조물에 `candidate_structure_types[]` named field 추가, `by_candidate_structure_type`·`by_bo_id`를 전체 canonical 타입으로 생성. 기존 키·형태 유지 | Codex §5.3.1 | 보존 판정이 인덱스에서 소실되는 실결함 | Part 4 라우팅 정보 무손실 |
| X-7 | **L0 통합 + 입력·채널 다이어트**: LES0+LES1 병합, input pack 비물질화(파일·stdout·주입 3채널 소멸), 입력 read 8→5 (`evidence_all`·`client_goal`·`evidence_event_candidates` 제거 — 기여 0/소비 0 실측), stdout은 manifest 1줄 | Claude R-1·R-2 + Codex P1 | pack 3중 물질화 930KB·미사용 55% | 전송 최대 절감 + task/세션 1개 감소 |
| X-8 | **아티팩트 단일화**: exception pack을 유일한 authoritative 파일로(seed 내장 제거), slim seed bundle에는 `exception_pack_ref{path, sha256, expected_exception_ids}`만. 진단·type_index_seed 제거(감사 필요분은 소형 audit 파일) | 양측 + Codex §7.6 ref 설계 | seed 422KB 중 ~80KB 미소비 + pack 이중 저장 | seed bundle 422KB → 250KB 이하 |
| X-9 | **L2 dead code 제거**: SEED_RAW 주입 삭제, seed는 파일 읽기로 일원화. L1 출력 파싱에 §6.7 관용 파서(코드펜스 salvage — max_iterations 재호출 방지) | Claude P3-5·P3-15 | 주입 100% 사장 실증 | 32.6KB 낭비 제거 + 재호출 차단 |
| X-10 | **SKILL 정합 일괄**: read_docs raw_decode fallback, 실패 시 FAILED 1줄 + 비정상 종료(성공 exit 위장 금지), 검증 실패 시 기존 final file overwrite 금지, `r"""…"""` 주입, stdout 전 task 단일 JSON 라인 | 양측 | Part 1/2 v3 확립 기준 | 강건성·오류 전파 차단 |
| X-11 | **프리픽스**: L1에 Part 2 Claude v3 R1과 바이트 동일한 3,829B 블록 채택 (같은 flash-lite 모델·직전 Part 실행·TTL 내 캐시 적중 가능성 최대) | §3 정정 결과 | 3-way 실측 | 유일하게 캐시 실익 있는 선택 |
### 2.3 기각·유보 항목
| ID | 항목 | 판정 근거 |
|---|---|---|
| N-1 | LES2 wildcard fan-out (Codex P4) | 기대 예외 0회 하에서 기계장치 과잉. 단일 조건부 태스크로 시작, pack 구성 한도(3~4건·12KB)는 X-4에 흡수 |
| N-2 | LES0·LES1 병합 보류 (Codex §7.7) | Part 2에서 동일 규모 병합의 방법론(함수 단위 이식+골든 회귀)이 이미 실증됨. 보류 시 pack 3중 물질화가 잔존해 최대 절감 항목을 놓침 |
| N-3 | 프리픽스 3,385B 교체 (Codex §5.9) | 배포 라인 이원화를 간과한 판정 — §3 정정. 단 Codex가 제기한 "교차 Part 캐시 정합" 문제의식 자체는 타당하며 X-11·D-2로 수용 |
| N-4 | reasoning medium (Codex §7.5) | BLOCK_REVIEW 안전판이 있으므로 low로 통일 (GB·R1 문법 정합). 판정 품질 우려는 골든 회귀와 D-1 모니터링으로 통제 |
### 2.4 후속·범위 밖 제안
- **D-1**: 사건 유형 다양화 시 예외 발생률 모니터링 — 상시 다건 재발이 확인되면 그때 wildcard fan-out(Codex P4 설계 재사용)으로 확장.
- **D-2**: Part 1 v3의 GB 프리픽스를 3,829B 블록으로 정렬하는 1줄 수정(flash-lite 3형제 GB·R1·L1의 캐시 공유 완성) — Part 3 개정 범위 밖이므로 별도 작업으로.
- **D-3**: issue cluster가 7/10에서 BO당 1개(50:50)로 퇴화한 문제 — 클러스터링 키 고도화는 효율이 아닌 기능 개선 주제로 이관.
### 2.5 검증 기준 (개정 작업 명세서에 반영할 DoD 골자)
정적: YAML parse·task 3개·DAG 정합, embedded Python ast 전부 통과, SKILL 정합(boilerplate·hash·raw_decode·단일 JSON stdout·raw string), L1 프리픽스가 Part 2 R1과 바이트 동일, final writer 단일성.
동적(7/10 fixture 골든 회귀): ① BO 50건이 final `by_bo_id`에 100% 존재 + evidence conservation ② 최종 파일이 Part 4 FL0 validator 무수정 통과 ③ 개정 전 인정된 canonical routing type 누락 0 (X-1의 nonrouting 라벨은 `nonrouting_labels`에서 전량 추적 가능) ④ coverage 등식 성립 ⑤ 단순 multi-routing만으로 review 생성 0 — 축소된 review 항목 전량이 audit에서 추적 가능 ⑥ 예외 실질 0회 → L1 즉시 종료 경로 ⑦ 2-run 바이트 결정론 ⑧ 주입 테스트(진짜 비가역 예외 주입 → pack 수록·L1 발동·BLOCK_REVIEW 시 L2 중단).
성능 목표(실 재실행, cold/warm 구분 3회 median — Codex §11.3 방법론 채택): 중간 파일 891KB → 300KB 이하, stdout 290KB → ~1KB, LLM 실행 상시 1회 → 조건부 0회, 런타임 3:40 → 40% 이상 단축(목표 1분대), 비용 $0 유지.
## 3. 정정 사항 (양 보고서의 부정확 지점 공개)
**Claude 보고서 정정**: "LES2 프리픽스가 Part 1/2 canonical과 바이트 동일(58f2b72d)"이라는 판정은 **Part 2 Claude v3 기준으로만 참**이다. Part 1 Claude v3(및 Part 1 Codex v3)는 들여쓰기 제거형 3,385B(6e01f72f)를 사용하므로 Part 1 라인과는 불일치한다. "유지 자산" 결론은 X-11과 같이 조건부로 수정한다.
**Codex 보고서 정정**: "Part 1·2 v3와 불일치하므로 3,385B 블록으로 교체해야 한다"는 판정은 **Part 2 Claude v3가 3,829B를 사용한다는 사실을 간과**했다. 3,385B로 교체하면 직전 실행 Part(Part 2)의 같은 모델 태스크(R1)와 어긋나 캐시 실익이 없다. 캐시는 모델 단위로 격리되므로, 실익이 있는 유일한 정합 대상은 같은 flash-lite 계열이며 그중 시간적으로 가장 가까운 것은 Part 2 R1(ttl 20m 내 도달)이다.
이 상충은 배포본 자체의 이원화(Part 1: 3,385B ↔ Part 2·3·4: 3,829B)에서 비롯되었으며, 근본 해소는 D-2(Part 1 정렬)로 제안한다.
## 4. 결론
채택 전략은 "**Codex의 원인 소거 + Claude의 구조 소거**"의 병행이다. canonical enum 정규화(X-1)와 ref-first 자산 규칙(X-3)이 예외의 발생 자체를 상류에서 제거하고, 보존적 defer(X-2·X-4)가 잔여를 결정론으로 처리하며 — 이 무손실성은 대표타입 50/50 일치라는 최종 산출물 실측으로 이미 보증되어 있다 — L0 통합(X-7)과 아티팩트 단일화(X-8·X-9)가 930KB의 유령 전송을 소거한다. pending_exception_ids 상태 모델(X-5)과 multi-routing 인덱싱(X-6)은 효율화를 넘어 현행의 실재 품질 결함(review 포화, 라우팅 정보 소실)을 바로잡는다. 최종 산출물 계약과 review 신호는 Part 4의 재판정 불가 원칙에 따라 additive 확장 외에는 손대지 않는다. 다음 단계는 본 선별 결과를 LLM이 100% 수행 가능한 개정 작업 명세서(`Part_3_Improvement_Strategy_Claude_v1.md`)로 구체화하는 것이다.
@@ -0,0 +1,521 @@
# Stage 1 Part 3 최적 개정 전략
- 작성일: 2026-07-20
- 비교 대상:
- `Part_3_Inefficiency_Report_Claude_v1.md`
- `Part_3_Inefficiency_Report_Codex_v1.md`
- 개정 대상: `Stage_1_Part_3_v1.yml`
- 최우선 기준: 최소 변경으로 법률적 정보 보존, LLM 호출 최소화, 토큰·전송량 절감, 실행속도 향상
## 1. 최종 판정
두 보고서는 핵심 원인에 관하여 실질적으로 일치한다. Part 3의 주된 비효율은 모델 성능보다 다음 구조에서 발생한다.
1. LES1이 정상적인 multi-routing까지 대량의 예외로 만든다.
2. LES2는 예외 유무와 무관하게 항상 실행되며 최대 30건을 한 번에 판정한다.
3. LES2가 해결한 예외도 LES3에서 `review_required` 해제로 연결되지 않는다.
4. LES0 input pack과 LES1 seed/exception이 파일, stdout, template에 중복 물질화된다.
5. Part 4가 쓰지 않는 중간 필드와 Part 3 계산에 기여하지 않는 원문 입력을 계속 운반한다.
7/10 실행물에서는 merge 후 예외 47건 중 30건이 LES2로 전달되고, 17건이 budget overflow로 차단되었다. LES2가 받은 30건 중 28건은 다시 `BLOCK_REVIEW`가 되었으며, 최종 구조 50건 전부가 review 대상으로 남았다. 따라서 **LES2 모델만 낮추는 조치는 핵심 해결책이 아니다.**
가장 적합한 1차 개정은 다음 한 경로다.
> LES0과 LES1의 책임 경계는 유지하되 payload를 축소하고, LES1에서 canonical multi-routing과 ref 기반 자산 처리를 결정적으로 수행하며, 진짜 비가역적 예외만 wildcard LES2에 보내고, LES3가 exception ID별 최종 review 상태를 다시 계산한다.
이 경로는 현행 Part 4 계약을 유지하면서 가장 적은 구조 변경으로 가장 큰 효과를 얻는다.
## 2. 두 보고서 비교·채택 결과
### 2.1 공통 결론: 전부 채택
| 공통 판정 | Claude | Codex | 최종 채택 |
|---|---|---|---|
| LES0 pack의 파일/stdout/template 중복 | 지적 | 지적 | stdout manifest화, payload 단일화 |
| LES1 미사용 input 필드 | 지적 | 지적 | 삭제 |
| `evidence_all.json`의 Part 3 기여 없음 | byte 동일 재현 | 조건부 삭제 | coverage gate와 함께 read 제거 |
| seed bundle의 미소비·중복 필드 | 지적 | 지적 | authoritative exception pack 한 곳만 유지 |
| LES2 무조건 실행 | 지적 | 지적 | 조건부 wildcard로 전환 |
| type 예외 과다 | 47건 실측 | 69종/263회 원인 분석 | canonical enum + multi-routing 기본 보존 |
| budget 30건 초과 17건 auto-block | 지적 | 지적 | hard cap 절단 폐기, micro-pack fan-out |
| LES2 판정 효용 부족 | 28/30 block | 동일 | true exception만 LLM 사용 |
| review queue 50/50 포화 | 지적 | 지적 | `pending_exception_ids` 기반 재계산 |
| Python failure가 `sys.exit(0)` | 지적 | 지적 | FAILED 출력 후 raise/non-zero |
| Part 4 final 계약 보존 | 지적 | 지적 | file/schema/5개 index 불변 |
### 2.2 차이점과 최종 선택
#### A. LES0·LES1 즉시 병합 여부
- Claude: 즉시 `L0_structure_seed_reducer`로 병합한다.
- Codex: 1차 개정에서는 유지·축소하고, 계측 후 2차 병합한다.
**최종 선택: 즉시 병합하지 않는다.**
거짓 예외 제거와 LES2 무호출 fast path가 전체 runtime에서 가장 큰 효과를 낸다. LES0·LES1 병합은 MCP 세션 1회와 중간 read/write를 더 줄일 수 있지만, source pack compilation과 legal routing seed 생성의 책임을 한 70KB 이상 코드에 결합한다. 최소 작업이라는 본 요청의 기준상 1차 개정에서는 payload 축소만 시행한다. 개정 후 LES0→LES1이 Part 3 runtime의 15% 이상이면 2차로 병합한다.
#### B. LES2 조건부 실행 방식
- Claude: 하나의 조건부 adjudicator가 exception pack을 preflight하고 no-exception이면 종료한다.
- Codex: `dynamic_fanout: []`를 사용하는 wildcard adjudicator로 만든다.
**최종 선택: wildcard `Task_LES2_exception_adjudicator_*`를 사용한다.**
LLM task 내부의 no-exception 분기는 provider 요청 자체를 없애지 못할 수 있다. 반면 Part 1·2 v3에서 이미 사용하는 wildcard 문법은 `dynamic_fanout: []`일 때 LLM instance를 0개로 만든다. 남은 예외도 독립 micro-pack으로 병렬 처리할 수 있다.
#### C. LES2 모델 하향 여부
- Claude: 조건부 0회화를 우선하고 모델 하향은 A/B 검증 후 적용한다.
- Codex: `gemini-3.1-flash-lite`, medium reasoning, low verbosity를 권고한다.
**최종 선택: flash-lite/medium/low를 기본값으로 적용하되 동일 fixture 회귀를 통과시킨다.**
잔여 LES2는 raw evidence를 읽거나 법률상 최종 결론을 내리는 task가 아니다. 제공된 후보와 closed enum 사이에서 routing decision만 내린다. Part 1·2의 예외 adjudicator와 동일한 모델 수준이면 충분하다. 회귀에서 decision coverage 또는 blocked rate가 악화될 때만 해당 pack 유형을 `gemini-3.5-flash`로 되돌린다.
#### D. common cache prefix 판정
Claude 보고서는 Part 3 prefix가 upstream canonical과 같다고 보았고, Codex 보고서는 Part 1·2 Codex v3와 다르다고 보았다. 실제 파일 hash는 다음과 같다.
| 파일 | bytes | SHA-256 |
|---|---:|---|
| Part 1 Claude/Codex v3 | 3,385 | `6e01f72f1803767b6bb16b5aef6cf34760e6dc1b293c316c75e990d09ad5fe63` |
| Part 2 Codex v3 | 3,385 | `6e01f72f1803767b6bb16b5aef6cf34760e6dc1b293c316c75e990d09ad5fe63` |
| Part 2 Claude v3 | 3,829 | `58f2b72d6c2650739c45d85cc57899150434db86a97bf19cd5a59d92d11dfbb5` |
| Part 3 v1 | 3,829 | `58f2b72d6c2650739c45d85cc57899150434db86a97bf19cd5a59d92d11dfbb5` |
현재 연계 기준인 Part 1·2 Codex v3에 맞춰 Part 3은 **3,385-byte `6e01...fe63` block을 그대로 복사**한다. 내용이 비슷한 것이 아니라 byte-identical해야 한다. 향후 Part 2 Claude v3를 production으로 선택한다면 Part 2까지 한꺼번에 같은 canonical block으로 통일해야 한다.
#### E. multi-routing의 final 반영 범위
Claude는 deterministic `PRESERVE_MULTI_ROUTING`을 채택했고, Codex는 현행 LES3가 복수 type을 `routing_audit`에만 남기고 final index에는 대표 type 하나만 반영하는 문제까지 확인했다.
**최종 선택: Codex의 보강안을 채택한다.**
모든 canonical type을 final structure의 `candidate_structure_types[]`, `by_bo_id.candidate_structure_types`, `by_candidate_structure_type`에 반영한다. Part 4가 요구하는 5개 index의 이름과 object 형태는 바꾸지 않는다. 이 보강이 없으면 `PRESERVE_MULTI_ROUTING`이 선언에 그치고 downstream 전달은 불완전하다.
#### F. asset ambiguity 처리
- Claude: 기본값을 `SEPARATE_CLUSTER + review`로 둔다.
- Codex: `REG-*`/`SCH-*`와 Part 2 `asset_alias`를 우선하여 결정적으로 동일성을 해소한다.
**최종 선택: 두 안을 결합한다.**
정확한 ref 연결은 결정적으로 병합하고, 서로 다른 ref는 별도 cluster와 multi-asset bundle로 보존한다. ref 없는 자유문구는 임의 병합하지 않고 `SEPARATE_CLUSTER + review`를 기본값으로 한다. 이 방식이 등기·별지목록상 권리객체를 잘못 합치는 위험을 가장 낮춘다.
## 3. 선별된 필수 개정 작업
| 우선순위 | 개정 묶음 | 노력 | 기대 효과 | 채택 |
|---|---|---:|---:|---|
| P0 | review 상태 재계산 + exception exact coverage | 중 | 품질 매우 큼, 무효 LLM 판정 제거 | 즉시 |
| P0 | canonical multi-routing + ref-first asset 처리 | 중 | 예외 47건의 대부분 제거 | 즉시 |
| P1 | LES0 5-file diet + compact stdout/artifact | 낮음~중 | 전송·parse·MCP I/O 대폭 축소 | 즉시 |
| P1 | LES2 conditional wildcard micro-pack | 중 | no-exception LLM 0회, 잔여 예외 병렬화 | 즉시 |
| P1 | seed/exception 중복 제거 | 낮음 | 중간 파일·재읽기 축소 | 즉시 |
| P2 | Python/SKILL 강건성 정비 | 낮음 | 재시도·silent failure 방지 | 즉시 |
| P3 | LES0+LES1 물리적 병합 | 높음 | Python task 1회 추가 절감 | 계측 후 보류 |
### 3.1 최우선: review 상태 모델 수정
현행 seed의 단일 `review_required` boolean을 다음 구조로 바꾼다.
```json
{
"pending_exception_ids": [],
"deterministic_review_codes": [],
"resolved_exception_ids": [],
"blocked_exception_ids": []
}
```
역할은 다음과 같이 분리한다.
- LES1: `pending_exception_ids`와 deterministic review code만 생성
- LES2: 자신에게 배정된 exception ID의 decision만 생성
- LES3: expected/decision/defer/block 집합을 대조하여 최종 상태 계산
- LES3 final `review_required`: unresolved, `BLOCK_REVIEW`, review-sensitive split, deterministic defer인 경우에만 `true`
다음 conservation을 hard gate로 둔다.
```text
expected_exception_ids
== resolved_exception_ids
∪ deterministic_resolution_ids
∪ blocked_exception_ids
∪ deferred_review_exception_ids
```
집합은 서로 중복되면 안 된다. 성공적으로 해결된 exception만 있었던 BO는 review queue에서 제거한다.
### 3.2 canonical structure type과 deterministic multi-routing
Part 4가 실제 module/role에 사용하는 type만 routing enum으로 인정한다.
```text
money_claim
commercial_successor
secured_debt
registry_invalidity
land_use_gain
valuation
fraudulent_transfer
preserved_claim
succession_notice_lien_asset_defense
general_legal_effect
```
다음 값은 법률적 의미가 있더라도 routing type으로 쓰지 않는다.
- `event`, `state`
- `법률행위`, `사실행위`, `준법률행위`, `소송행위`
- `변제`, `상계`, `상속포기`, `소유권이전` 등 세부 사건·행위 label
- Part 4 mapping에 없는 임시 transport tag
이 값들은 삭제하지 않고 `nonrouting_labels[]` 또는 signal audit에 보존한다.
복수 canonical type은 다음과 같이 처리한다.
1. 모든 type을 보존한다.
2. 대표 type은 고정 priority로 선택한다.
3. 모든 type에 대응하는 `legal_effect_roles`를 생성한다.
4. final `by_bo_id`와 `by_candidate_structure_type`에 전부 반영한다.
5. 단순 복수 role이라는 이유로 exception을 만들지 않는다.
type exception은 다음 4개 조건을 모두 충족할 때만 생성한다.
1. LES3가 단일값 또는 split을 선택해야 final write가 가능하다.
2. source-backed 후보가 2개 이상이다.
3. 전체 보존 또는 Stage 2 defer가 불가능하다.
4. 제공할 compact context만으로 안전한 LLM 판정 가능성이 있다.
하나라도 충족하지 않으면 LLM에 보내지 않는다. 정보 보존이 가능하면 `PRESERVE_MULTI_ROUTING`, 불충분하면 식별 가능한 deterministic review로 남긴다.
### 3.3 ref-first asset identity
LES0에서 다음 deterministic map을 만든다.
```text
asset_alias_by_ref[REG-*|SCH-*]
-> canonical_label_candidate
-> evidence_index
-> registry/schedule metadata
```
Part 2의 `extensions.domain_payload.asset_alias`에 있는 `schedule_refs`와 `registry_refs`도 같은 map에 결합한다.
판정 순서는 다음과 같다.
1. 동일 `REG-*`/`SCH-*`: 같은 asset cluster
2. alias map이 ref와 자유문구를 명시적으로 연결: 같은 cluster
3. 서로 다른 ref: 별도 cluster
4. 하나의 BO가 여러 ref를 포함: 각 cluster를 보존하고 multi-asset bundle 생성
5. ref 없는 자유문구만 존재: `SEPARATE_CLUSTER + deterministic review`
6. 상충하는 source-backed ref 때문에 merge 여부가 권리효과를 바꾸고 defer할 수 없는 경우만 LES2 exception
fuzzy 문자열 유사도만으로 자산을 병합하지 않는다.
### 3.4 LES0 input diet와 compact channel
Part 3 필수 read를 다음 5개로 제한한다.
```text
BO.json
evidence_indexed.json
actio_case_signals.json
case_liability_signals.json
legal_effect_signals.json
```
Part 3 read에서 제거한다.
- `client_goal.json`: LES1/LES3가 사용하지 않음
- `evidence_all.json`: Claude의 byte-identical 재실행에서 evidence authority 기여 0
- `evidence_event_candidates.json`: `related_event_candidates`가 LES1/LES3에서 사용되지 않음
단, 제거 후 다음 gate를 통과해야 한다.
```text
input BO ids == candidate BO ids == seed BO ids
input evidence refs contains all seed evidence refs
every REG/SCH ref used by a seed resolves to evidence_indexed or BO asset_alias
```
LES0 input pack에는 BO별 compact candidate만 저장한다. 다음 중복 필드는 제거한다.
- top-level `bo_by_id`
- top-level `signals_by_bo_id`
- `events_by_evidence_index`
- `client_goal_compact`
- `related_event_candidates`
stdout은 payload가 아니라 다음 manifest 한 줄만 반환한다.
```json
{
"les0_manifest": {
"schema_version": "stage1_legal_structure_input_manifest.v2",
"status": "READY",
"artifact_path": "stage1_tmp/legal_effect_structure_input_pack.json",
"run_fingerprint": "sha256:...",
"bo_count": 50,
"candidate_count": 50
}
}
```
LES1은 manifest의 path/hash를 검증한 뒤 파일을 한 번 읽는다. 정상 경로와 fallback 경로를 중복 운영하지 않는다.
### 3.5 seed/exception artifact 단일화
LES1 산출물은 역할별로 다음과 같이 나눈다.
| Artifact | 포함 내용 | 제외 내용 |
|---|---|---|
| slim seed bundle | structure seeds, issue map, asset map, evidence index seed, pending IDs | full diagnostics, final type index, embedded exception pack |
| exception pack | exception items, audit/defer rows, pack plan, fingerprint | full seed/BO/signal |
| LES1 stdout | manifest + `dynamic_fanout` | seed/exception 전체 본문 |
seed bundle에서 제거한다.
- `candidate_structure_type_index_seed`: LES3가 final structure에서 재생성
- full `ambiguity_diagnostics`: exception pack audit로 이전
- embedded `legal_structure_exception_pack`: 별도 pack을 authoritative source로 사용
- LES3가 사용하지 않는 full `multi_asset_bundles`: 필요한 bundle ref/member만 seed item 또는 exception context에 남김
LES3는 seed와 exception pack의 path, schema, SHA-256, `run_fingerprint` 일치를 확인한다.
### 3.6 LES2를 conditional wildcard micro-adjudicator로 전환
task 이름은 다음과 같이 바꾼다.
```text
Task_LES2_exception_adjudicator_*
```
LES1 stdout은 실제 LLM 대상이 있을 때만 `dynamic_fanout`에 pack을 넣는다.
```json
{
"les1_manifest": {
"status": "READY",
"seed_path": "stage1_tmp/legal_effect_structure_seed_bundle.json",
"exception_pack_path": "stage1_tmp/legal_effect_structure_exception_pack.json",
"pack_count": 0,
"run_fingerprint": "sha256:..."
},
"dynamic_fanout": []
}
```
pack 규칙은 다음과 같다.
| 항목 | 값 |
|---|---:|
| items per pack | 최대 3~4 |
| serialized bytes | 최대 12 KB |
| candidate values per item | 최대 8 |
| `max_concurrency` | 2 |
| model | `gemini-3.1-flash-lite` |
| reasoning | `medium` |
| verbosity | `low` |
| max iterations | 2 |
| tools | `localdocs`만 허용 |
| preflight | `false` |
| cache TTL | `1h` |
각 wildcard instance는 자신의 `item`만 읽고 다음 한 파일만 쓴다.
```text
stage1_tmp/legal_effect_structure_adjudication_parts/PACK-###.json
```
허용 decision은 exception type별 closed enum으로 제한하고, selected value와 source ref는 input 후보의 부분집합이어야 한다. 출력 본문은 파일로 저장하고 stdout은 `pack_id`, status, output path, decision count만 반환한다.
### 3.7 LES3 final gate/writer 강화
LES3는 다음 입력만 읽는다.
- slim seed bundle
- authoritative exception pack
- 존재하는 모든 adjudication part
DAG에서 다음을 기다린다.
```text
Task_LES1_deterministic_structure_seed_builder
all Task_LES2_exception_adjudicator_*
```
LES3 수행 순서는 다음과 같다.
1. 세 artifact의 schema/fingerprint/hash 검증
2. expected exception과 decision/defer/block exact coverage 검증
3. unknown·duplicate exception ID 및 후보 밖 value 차단
4. 최종 review 상태 재계산
5. 모든 canonical type을 final structure와 type index에 투영
6. BO/evidence/issue/asset/type index conservation 검증
7. `legal_effect_structures.json` 단독 write
8. write 후 재읽기와 schema/coverage 재검증
LES1 stdout을 `SEED_RAW`로 주입하는 dead path는 삭제한다.
### 3.8 Python/SKILL 강건성 정비
LES0, LES1, LES3에 공통 적용한다.
- localdocs direct MCP의 `user_id`/`workspace_id` hash 전달 유지
- `read_docs` JSON parse에 `JSONDecoder.raw_decode` fallback 적용
- template 삽입이 남는 경우 raw string 사용
- FAILED compact JSON 출력 후 `raise` 또는 non-zero 종료
- 코드펜스가 포함된 adjudication JSON은 보수적으로 salvage하고 warning 기록
- final writer 검증 실패 시 기존 final file overwrite 금지
- stdout은 한 줄 compact JSON으로 제한
## 4. 최종 권장 DAG
```text
IN
|
v
LES0 compact input compiler (Python)
| - 5 files only
| - compact artifact + manifest
v
LES1 deterministic seed/exception planner (Python)
|\
| +-- true LLM exceptions --> LES2_exception_adjudicator_* (0..N, max 2 parallel)
| |
| +-- decision part files
|
+-- no exception: dynamic_fanout = []
|
+------------------------------+
v
LES3 final gate/writer (Python)
- waits LES1 + all LES2_*
- exact coverage/review recomputation
- writes final file only
|
v
OUT
```
정의 task 수는 LES0, LES1, LES2 wildcard template, LES3의 4개를 유지한다. 정상 no-exception 실행에서는 wildcard instance가 생성되지 않으므로 실제 실행 task는 Python 3개다.
## 5. 삭제·유지·보류 최종 판정
### 5.1 즉시 삭제 또는 축소
| 대상 | 판정 | 이유 |
|---|---|---|
| Part 3의 `client_goal.json` read | 삭제 | downstream seed/writer 미사용 |
| Part 3의 `evidence_all.json` read | 삭제 + coverage gate | 실측 기여 0, structured evidence가 대체 |
| Part 3의 `evidence_event_candidates.json` read | 삭제 | 관련 event projection 미사용 |
| LES0 full-pack stdout | 삭제 | file artifact와 중복 |
| top-level `bo_by_id`/`signals_by_bo_id` | 삭제 | 미사용 또는 candidate 내부 중복 |
| `candidate_structure_type_index_seed` | 삭제 | LES3 재생성 가능 |
| seed 내 full diagnostics/exception pack | 삭제 | authoritative exception pack으로 통합 |
| LES3 `SEED_RAW` 주입 | 삭제 | 현행 root가 달라 항상 fallback |
| 30건 monolithic LES2 | 삭제 | wildcard micro-pack으로 대체 |
| 성공 후에도 남는 seed review boolean | 삭제 | pending/resolved 상태로 대체 |
### 5.2 반드시 유지·강화
| 대상 | 판정 | 이유 |
|---|---|---|
| `legal_effect_structures.json` file/schema | 유지 | Part 4 직접 소비 |
| 5개 `structure_index` | 유지·내용 강화 | BO/Fact Ledger join surface |
| BO/evidence coverage | 강화 | 누락 전파 방지 |
| issue/asset/type exception audit | 유지 | Part 4 재판단 금지 |
| source IDs와 REG/SCH refs | 원형 유지 | 법률상 객체·근거 추적 |
| LES3 단독 writer | 유지 | 중복·경합 방지 |
| LLM `BLOCK_REVIEW` 경로 | 유지 | 불충분 근거에서 추론 강행 방지 |
### 5.3 1차 개정에서 보류
| 대상 | 보류 이유 | 재검토 조건 |
|---|---|---|
| LES0+LES1 물리적 병합 | 책임 경계와 대형 코드 변경 위험 | 개정 후 해당 구간이 runtime 15% 이상 |
| LES2 완전 삭제 | 다른 사건에서 진짜 identity/split 예외 가능 | 다수 fixture에서 0건이 장기 확인될 때 |
| issue clustering 기능 고도화 | 효율화 범위를 넘어서는 법률 모델 변경 | 별도 정확도 과제로 수행 |
| Part 4 구조 개정 | 현행 계약으로 충분 | 회귀에서 multi-routing 소비 누락 발견 시 |
## 6. 구현 순서
### Phase 1: 품질 결함 제거
1. canonical routing enum과 nonrouting label 분리
2. deterministic multi-routing 및 ref-first asset 규칙 적용
3. seed를 `pending_exception_ids` 기반으로 변경
4. LES3 review 재계산과 all-type index 생성
### Phase 2: 데이터 이동 축소
1. LES0 read를 5개로 축소
2. compact candidate pack과 manifest stdout 적용
3. slim seed/authoritative exception pack 분리
4. LES3 dead `SEED_RAW` 제거
### Phase 3: LLM fast path
1. LES2를 wildcard template으로 변경
2. micro-pack size/count gate 적용
3. flash-lite/medium/low 및 canonical cache prefix 적용
4. LES3의 all-wildcard coverage 검증 연결
### Phase 4: 강건성·회귀
1. raw_decode, non-zero failure, tolerant JSON parser 적용
2. YAML parse 및 모든 embedded Python compile
3. 7/10 fixture golden regression
4. cold/warm 3회 runtime·token·cache 계측
## 7. 검증 및 합격 기준
### 7.1 정적 검증
- YAML parse 성공
- dangling task/DAG reference 0
- embedded Python compile 성공
- direct MCP user/workspace context 누락 0
- 모든 LLM wildcard의 common prefix SHA-256이 `6e01...fe63`
- LES1의 `dynamic_fanout`과 LES3의 `all Task_LES2_exception_adjudicator_*` 연결 확인
- `legal_effect_structures.json` writer가 LES3 하나뿐임
### 7.2 기능·법률 품질 검증
| 검증 항목 | 합격 기준 |
|---|---|
| BO conservation | source BO IDs = seed BO IDs = final `by_bo_id` IDs |
| evidence conservation | 모든 seed evidence ref가 final evidence index에 존재 |
| asset ref conservation | 모든 REG/SCH ref가 원형 유지되고 미지 ref 0 |
| canonical type conservation | source-backed canonical type 누락 0 |
| multi-routing | 모든 canonical type이 structure와 2개 type 관련 index에 반영 |
| exception coverage | expected = resolved + deterministic + deferred + blocked |
| review precision | 해결된 예외만 있는 구조는 review에서 제거 |
| unresolved safety | 불충분·상충 예외는 식별 가능한 ID로 review 유지 |
| Part 4 호환성 | 현행 Part 4 FL0 validator 무수정 통과 |
| 결정론 | 동일 입력 2회 실행 결과 byte-identical |
### 7.3 성능 합격 기준
| 지표 | 현행 | 목표 |
|---|---:|---:|
| input pack file | 416,115 B | 200 KB 이하 |
| seed bundle file | 422,236 B | 250 KB 이하 |
| LES0 stdout | 257 KB 수준 | 2 KB 이하 |
| LES1 stdout | 32.6 KB 수준 | no-exception 4 KB 이하 |
| LLM 호출 | 항상 1회 | true exception pack 수만큼, fixture 목표 0회 |
| auto-block by item cap | 17건 | 0건 |
| blanket structure review | 50/50 | 0건; 실제 review 사유만 유지 |
| Part 3 runtime | 3분 40초 | 3회 median 40% 이상 단축 |
| 비용 | `$0` | 증가 금지 |
성능 결과는 task별 elapsed time, input/output token, cache hit, pack count, serialized bytes를 함께 기록한다. 전체 runtime만 측정하면 다음 병목을 다시 찾을 수 없다.
## 8. 최종 실행 지침
1차 개정에서는 **task 병합보다 false exception 제거와 true zero-LLM fast path를 우선**한다. 이 두 작업이 현행 3분 40초 중 가장 큰 LLM·review 낭비를 제거한다.
구조유형은 하나를 억지로 고르는 대상이 아니라 source-backed canonical type을 모두 보존하는 routing surface로 취급한다. 자산은 ref를 우선하고, 동일성이 불확실하면 병합보다 분리를 선택한다. 이는 처리속도를 높이면서 청구원인·항변·담보·사해행위 구조가 Stage 2에서 누락되는 위험도 줄인다.
최종 개정 성공의 기준은 단순히 LES2 호출 수가 줄어드는 것이 아니다. `legal_effect_structures.json`의 외부 계약과 BO/evidence/type 보존을 유지하면서, LLM이 실제로 필요한 예외만 보고, 최종 review queue가 변호사가 실제로 검토할 항목만 남기는 상태가 되어야 한다.
@@ -0,0 +1,206 @@
# Stage 1 Part 3 개정 작업 명세서 (Claude v1)
- 개정 대상: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml` (2,639행, task 4개)
- 산출물: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_Claude_v3.yml` (신규 파일 — v1 원본은 수정·이동·삭제 금지)
- 근거 문서: `Part_3_Improvement_Claude_v1.md` (채택 전략 X-1~X-11, 기각 N-1~N-4, 후속 D-1~D-3)
- 작성 관점: 20년 이상 경력의 대한민국 최고 수준 변호사 + 세계적 수준의 AI 아키텍트. 본 명세서는 LLM이 읽고 추가 판단 없이 100% 수행할 수 있도록 작성되었다. 명세에 없는 "개선"의 임의 추가는 금지한다(§12-9).
---
## 0. 개정 목표와 원칙
1. **골격 전환**: `LES0→LES1→LES2(상시 LLM)→LES3` 4-task 직렬 체인을 `L0(결정론 reducer)→L1(조건부 LLM adjudicator)→L2(결정론 final writer)` 3-task로 재편한다. Part 1 v3(GA→GB→GC)·Part 2 v3(R0→R1→F0)와 동일한 문법이다.
2. **예외의 상류 소거**: canonical routing enum 정규화(X-1)와 ref-first 자산 규칙(X-3)으로 예외 발생 자체를 제거하고, 잔여는 보존적 defer(X-2)와 4중 조건 pack(X-4)으로 결정론 처리한다. 7/10 fixture 기준 LLM 호출 실질 0회가 목표이며, 이 무손실성은 "대표 타입 50/50 결정론 일치·split 0" 실측으로 이미 보증되어 있다.
3. **전송의 구조 소거**: input pack 3중 물질화(파일 416KB + stdout 257KB + 코드 주입 257KB)와 LES3의 사장된 SEED_RAW 주입(32.6KB)을 제거하고, stdout은 전 task 1줄 요약 JSON으로 제한한다.
4. **품질 결함 교정**: pending_exception_ids 상태 모델(X-5)로 review 신호 변별력을 복원하고, multi-routing을 최종 인덱스에 additive로 반영한다(X-6).
5. **불변 계약 준수**: `legal_effect_structures.json`의 파일명·schema_version·필수 필드·5-way index·status enum은 변경 금지(additive 확장만 허용). Part 4 FL0 validator가 무수정 통과해야 한다.
6. **SKILL.md 100% 준수**: 모든 Python task는 `YAML_Prompts/1. Stage_1/SKILL.md`의 제약(localdocs 보일러플레이트, `{{__user_hash__}}`/`{{__workspace_hash__}}`, read_docs raw_decode fallback, stdout 단일 JSON 라인, `r"""…"""` 템플릿 주입)을 준수한다.
7. **프리픽스(X-11)**: L1의 `COMMON_CACHE_PREFIX_STAGE_1`은 **현행 Part 3 LES2 블록을 바이트 그대로 유지**한다. 이 블록(3,829B, sha256 앞 12자리 `58f2b72d6c26`)은 Part 2 Claude v3의 R1과 바이트 동일하며, 같은 flash-lite 모델로 직전 Part에서 실행되는 R1과의 캐시 정합이 유일한 실익이다. 들여쓰기 제거·재정렬 금지. (Part 1 GB의 3,829B 정렬은 D-2 — 본 개정 범위 밖.)
---
## 1. 불변 계약 (변경 금지 목록)
1. **최종 파일** `legal_effect_structures.json`: 파일명, `schema_version: "stage1_legal_effect_structures.v1"`, `status ∈ {READY, READY_WITH_REVIEW}`, `legal_effect_structures[]`의 필수 필드 13종(structure_id, candidate_structure_type, structure_label, source_bo_ids, issue_cluster_ids, asset_cluster_ids, evidence_indexes, linked_claim_group_ids, linked_liability_group_ids, linked_actio_signal_ids, legal_effect_roles, basis, review_required), `structure_index`의 5개 섹션(by_bo_id, by_issue_cluster_id, by_asset_cluster_id, by_evidence_index, by_candidate_structure_type), `quality_gate`(bo_coverage·evidence_coverage·review_queue). **키 삭제·이름 변경·타입 변경 금지. 신규 키 추가(additive)만 허용.**
2. **ID 규칙**: `REG-*`/`SCH-*`/BO ID(bh#)/evidence index(E-###)/claim·liability group id/signal id는 절대 renumber·창작 금지. `LES-###`/`IC-###`/`AC-###`는 L2가 현행과 동일한 결정론 순서로 부여한다.
3. **LLM 판정 계약**: 결정 enum(현행 LES2 OUTPUT_CONTRACT의 exception_type별 enum과 BLOCK_REVIEW), "후보 밖 값 생성 금지", "불충분 시 BLOCK_REVIEW" 원칙 유지.
4. **review 신호**: unresolved/blocked/split 예외는 review_queue에서 삭제 금지. 축소(해소)되는 항목은 전량 audit 파일에서 추적 가능해야 한다.
5. Part 1/2/4 YAML은 수정하지 않는다.
---
## 2. 현행 구조 매핑 (개정 대상 앵커)
| 현행 task (v1 시작 행) | 처분 |
|---|---|
| `Task_LES0_input_pack_compiler` (53행) | **L0로 흡수** — 컴파일 함수군 이식, pack 물질화 폐지 |
| `Task_LES1_deterministic_structure_seed_builder` (724행) | **L0로 흡수** — seed/예외 생성 로직 이식 + X-1/X-2/X-3/X-4/X-5 개정 |
| `Task_LES2_single_cluster_exception_adjudicator` (1665행) | **L1로 대체** — 조건부·pack 파일 입력·flash-lite/low. 프리픽스 블록(1679~1721행)은 바이트 유지 |
| `Task_LES3_final_structure_index_writer` (1894행) | **L2로 개정** — SEED_RAW 제거, 상태 재계산, additive 인덱싱 |
| `task_procedure` (21행) | **전면 교체** (§10) |
**코드 이식 원칙**: 흡수되는 로직은 폐기가 아니라 **함수 단위 이식**이다. LES0의 `_compact_bo`·`_actio_signals_by_bo`·`_case_signals_by_bo`·`_legal_routes_by_bo`·`_collect_evidence_authority`(evidence_all 인자 제거판)·`_normalize_structure_type`·`_asset_kind`·`_asset_strings`·`_extract_asset_candidates`·`_dedupe_assets`, LES1의 `_score_issue`·`_hard_issue_keys`·`_issue_decision`·`_asset_decisions`(X-3 개정)·`_structure_type_decision`(X-2 개정)·`_merge_exceptions`·`_add_issue_seed`·`_add_asset_seeds`·`_add_evidence_index`·`_norm_text`·`_asset_norm`·`_legal_unit_tokens`, LES3의 `_validate_decisions`·`_validate_decision_enum`·`_validate_decision_subsets`·`_issue_ids_for_item`·`_asset_ids_for_item`·`_type_plan_for_item`·`_build_structures`·`_build_structure_index`·`_quality_gate`·`_validate_payload`를 각각 L0/L2로 옮기고, 중복 MCP 보일러플레이트만 1벌로 줄인다. 개정 지점은 본 명세서가 명시한 곳으로 한정한다.
---
## 3. STEP 0 — 사전 검증 (v3 작성 전 필수)
1. **STEP 0-1**: v1에서 §2의 앵커 4개 + `task_procedure`(21행) 존재 확인. 불일치 시 중단·보고.
2. **STEP 0-2**: fixture(`Results_July_10_3_15pm`)에 L0 입력 5종(`BO.json`, `evidence_indexed.json`, `actio_case_signals.json`, `case_liability_signals.json`, `legal_effect_signals.json`)과 골든 산출물(`legal_effect_structures.json`, sha256 앞 12자리 `021b5d8f8ec2`) 및 중간 실행물 3종(input pack 416,115B / seed bundle 422,236B / exception pack 52,982B)이 존재함을 확인한다(§11 회귀에 사용).
3. **STEP 0-3**: L1 프리픽스 canonical을 v1의 1679~1721행 `<COMMON_CACHE_PREFIX_STAGE_1>…</COMMON_CACHE_PREFIX_STAGE_1>` 블록에서 바이트 추출하고, Part 2 Claude v3의 R1 블록과 바이트 동일함을 확인한다(불일치 시 중단·보고 — X-11 전제 붕괴).
4. **STEP 0-4**: preflight 파일 채널(Plan A) 가용성은 Part 2 v3 배포와 공유되는 전제조건이다. Part 2 v3의 STEP 0-2 채널 테스트가 이미 통과되어 있으면 재검 불요. 미확인 상태면 동일한 소형 테스트(파일 1개 write → `preflight: true` + `preflight_files`로 flash-lite 미니 task가 내용을 인용하는지 1회 확인)를 수행한다. **실패 시 Plan B**: L1은 `preflight: false`로 두고 L0 stdout에 exception pack 요약(`has_exceptions`, `exceptions[]`)을 포함시켜 `{{prev.Task_L0_structure_seed_reducer.json_output}}` 템플릿으로 주입한다(예외 0이면 요약이 수십 바이트에 불과).
---
## 4. 신규 데이터 계약 (파일 5종)
| 파일 | writer | 소비자 | 핵심 스키마 |
|---|---|---|---|
| `stage1_tmp/legal_effect_structure_seed_bundle.json` | L0 | L2 | `{legal_structure_seed_bundle: {schema_version: "stage1_legal_structure_seed_bundle.v2", status, structure_seed_items[], issue_cluster_seed_map, asset_cluster_seed_map, evidence_index_seed, multi_asset_bundles[], exception_pack_ref: {path, sha256, expected_exception_ids[]}}}` — **v1의 `ambiguity_diagnostics`·`candidate_structure_type_index_seed`·내장 exception pack은 수록 금지** |
| `stage1_tmp/legal_effect_structure_exception_pack.json` | L0 | L1 (preflight) | Part 2 pack 형식으로 교체: `{schema_version: "stage1_legal_structure_exception_pack.v2", has_exceptions, exception_count, exceptions[], budget}` — exception 항목은 v1 필드(exception_id `LEX-###`, exception_type, source_bo_ids, candidate_values, basis_fields, score_table→score_summary 상위 3, conflict_flags, allowed_decisions, merged_from_count, compact_context) 유지. **X-4 4중 조건 통과 항목만 수록** |
| `stage1_tmp/legal_effect_structure_adjudication.json` | L1 | L2 | `{legal_structure_exception_adjudication: {…}}` — v1 LES2 OUTPUT_CONTRACT의 루트·필드·enum 그대로(스키마 버전 `stage1_legal_structure_exception_adjudication.v1` 유지). L2의 `_validate_decisions` 이식 호환 |
| `stage1_tmp/legal_effect_structure_audit.json` | L0 (L2가 review 추적 필드 추가) | 인간 감사 | `{schema_version: "stage1_legal_structure_audit.v1", nonrouting_labels_by_bo_id, deterministic_resolutions[], merge_groups[], review_reduction_trace[]}` — 소형(목표 40KB 이하). §1-4의 추적성 요건을 이 파일이 담보 |
| `legal_effect_structures.json` | L2 (유일 writer) | Part 4 FL0 | **§1-1 불변 + additive**: 구조물에 `candidate_structure_types[]`·`pending_exception_state` 추가, `structure_index.by_candidate_structure_type`을 전체 canonical 타입으로 생성(§9-4) |
폐지: input pack 파일(`stage1_tmp/legal_effect_structure_input_pack.json`)은 쓰지 않는다.
stdout 규약(SKILL §3.3): L0/L2는 **단일 JSON 라인**만 출력한다(경로·sha·count·status·has_exceptions). pack·bundle 내용을 stdout에 넣지 않는다.
---
## 5. STEP 1 — L0 명세 (`Task_L0_structure_seed_reducer`)
code-executor 엔트리(language python, requirements httpx, network agent-network, timeout 180). MCP 보일러플레이트는 v1 LES1(747~888행)을 1벌만 이식하고 `clientInfo.name`을 `"stage-1-legal-effect-l0-structure-seed-reducer"`로 변경. SKILL 필수사항(user/workspace hash, **read_docs raw_decode fallback — v1의 strict `json.loads` 2곳을 SKILL §6.4 GOOD 패턴으로 교체**) 적용.
1. **입력 read 5종**: `BO.json`, `evidence_indexed.json`, `actio_case_signals.json`, `case_liability_signals.json`, `legal_effect_signals.json`. **`evidence_all.json`·`client_goal.json`·`evidence_event_candidates.json`은 읽지 않는다**(기여 0/소비 0 실측). `_collect_evidence_authority`는 evidence_all 인자를 제거하고 evidence_indexed + BO.Evidence 2원으로 동작(포함/제외 산출 동일 실측이 근거). `_require_signal_root` 검증 3종 유지.
2. **컴파일(LES0 이식)**: `_compact_bo`·signal 매핑 3종·evidence authority·candidate_inputs 구성을 메모리 내 변수로만 생성한다. **pack 파일 write·stdout 발행·중간 dict의 bo_by_id/signals_by_bo_id/events_by_evidence_index/client_goal_compact 구성은 전부 제거**(미사용 실측). `_compact_bo`의 반환 필드 중 candidate_inputs가 실제 소비하는 필드(keyword_fields 구성원, provenance.source_domain, downstream_seed_refs, domain_payload 소비 키, source_evidence_indexes, Evidence excerpt)는 유지한다.
3. **X-1 canonical enum 정규화**: `CANONICAL_STRUCTURE_TYPES = [money_claim, commercial_successor, secured_debt, registry_invalidity, land_use_gain, valuation, fraudulent_transfer, preserved_claim, actio_remedy_or_cap, succession_notice_lien_asset_defense]` + fallback `general_legal_effect`를 closed enum으로 선언한다. `_candidate_structure_types`는 기존 소스(legal_effect_signals·case_liability·actio_scope 매핑·domain tag·source_domain)를 유지하되, `_normalize_structure_type` 결과가 **enum에 속하는 값만** `candidate_structure_types`에 넣고, 속하지 않는 값(`event`/`state`, 행위 분류, 세부 사건명 등)은 삭제하지 말고 `nonrouting_labels`로 분리 보존한다(audit 파일 §4). v1의 "정규화 실패 문자열 그대로 반환"(474행) 경로를 제거한다.
4. **X-2 multi-routing 결정론**: `_structure_type_decision`을 개정한다 — canonical 타입이 복수여도 **예외를 생성하지 않는다**. 전 타입 보존 + `STRUCTURE_TYPE_PRIORITY`(v1 757~769행 순서 유지)로 대표 선정 + 전 타입의 downstream role 부여. type 예외는 §5-6의 4중 조건을 통과하는 경우(현행 스키마에서 상호 배타 필드 충돌 또는 source-backed split 필요성이 구체적 근거로 존재)로만 한정한다. v1의 "role 2종 이상이면 예외"(1172~1185행) 규칙을 삭제한다.
5. **X-3 asset ref-first 규칙**: `_asset_decisions`를 개정한다 — (a) 동일 `REG-*`/`SCH-*` ref 공유 → 동일 클러스터 확정(현행 keyed 그룹핑 유지). (b) **BO `domain_payload.asset_alias`의 `schedule_refs`/`registry_refs` ↔ `alias_strings`/`canonical_label_candidate` 연결을 alias map으로 구축**하여, unkeyed 라벨이 alias로 keyed ref와 연결되면 동일 클러스터로 결정론 병합한다(예외 아님 — 7/10 asset 예외 6건의 해소 경로). (c) 하나의 BO에 서로 다른 ref 복수 → 클러스터 분리 + multi_asset_bundle 보존(현행 로직 유지, 예외 생성만 제거). (d) ref 없는 자유문구 간 동일성 불명 → **`SEPARATE_CLUSTER` 보존 + review code**(LLM 금지, fuzzy 병합 금지). asset 예외는 4중 조건 통과 시로만 한정.
6. **X-4 exception pack 수록 4중 조건**: ① L2가 진행하려면 단일 값 선택이 필수 ② source-backed 후보 2개 이상 ③ 보존·defer로 처리 불가 ④ compact payload(항목당 ≤2KB)로 판정 충분. 전부 충족하는 항목만 pack에 수록한다. **budget 자동 차단(`budget_overflow`) 로직을 제거한다** — 수록 항목이 방어 상한(30건 또는 직렬화 40KB)을 넘으면 초과분을 자동 차단이 아니라 `deterministic_review`로 라우팅하고 exception_id를 유지한 채 audit·review 추적에 명시 항목으로 남긴다(임의 절단·추적성 공백 금지). `_merge_exceptions`(서명 병합)와 `LEX-###` 부여는 이식 유지.
7. **X-5 상태 모델**: structure_seed_items에서 `review_required` boolean 대신 **`pending_exception_ids: []`**(해당 seed에 걸린 LEX id 목록)와 `deterministic_review_codes: []`(defer 정책이 남긴 review 사유)를 기록한다. issue/asset/evidence seed map의 `review_required`도 동일 원칙으로 대체한다.
8. **issue 결정(현행 유지)**: `_issue_decision`의 hard-key 우선·score 규칙은 7/10에서 예외 0건이므로 로직 유지. `auto_blocked`(후보 전무) 항목은 `deterministic_review_codes: ["missing_candidate_values"]`로 기록.
9. **출력**: §4의 seed bundle(v2, slim)·exception pack(v2)·audit 파일 3종 write + stdout 1줄: `{"status", "message", "seed_bundle_path", "exception_pack_path", "audit_path", "seed_count", "has_exceptions", "exception_count", "deterministic_resolution_count", "nonrouting_label_count"}`.
10. **FAILURE_POLICY**: 입력 누락·파싱 불가 시 파일 미작성, FAILED 단일 JSON 라인 출력 후 **raise**(`sys.exit(0)` 금지 — P3-14 교정).
---
## 6. STEP 2 — L1 명세 (`Task_L1_exception_adjudicator`)
LLM task 엔트리:
```yaml
- task_name: Task_L1_exception_adjudicator
llm_provider: google
llm_model: gemini-3.1-flash-lite
llm_reasoning: low
llm_verbosity: low
max_iterations: 1
use_tools: [localdocs]
cache_control: {mode: auto, ttl: 20m}
preflight: true
preflight_files:
- stage1_tmp/legal_effect_structure_exception_pack.json
```
프롬프트 구성: STEP 0-3에서 추출한 canonical `COMMON_CACHE_PREFIX_STAGE_1`(3,829B, **바이트 그대로** — X-11) + 신규 STATIC_BLOCK(Part 2 v3 R1 골격):
1. MISSION: "결정론 reducer(L0)가 non-deferrable로 판정한 compact exception만 판정한다. 파일 병합·최종 파일 작성·사실 창작 금지."
2. EXECUTION: ① preflight로 제공된 pack의 `has_exceptions` 확인 ② **false이면 no-exception 판정 객체**(`{"legal_structure_exception_adjudication": {"schema_version": "stage1_legal_structure_exception_adjudication.v1", "status": "READY_NO_EXCEPTIONS", "decisions": [], "blocked_review_items": [], "adjudication_gate": {...}}}`)를 `write_file(overwrite=true)`로 `stage1_tmp/legal_effect_structure_adjudication.json`에 저장하고 `"NO_EXCEPTIONS"`만 출력 후 즉시 종료(terminate) ③ true이면 각 exception을 `compact_context`만으로 판정(추가 read 금지) ④ 판정 규칙·enum·필드 규칙은 v1 LES2의 DECISION_RULES·OUTPUT_CONTRACT(1789~1892행)를 이식(exception_type별 enum 제한, 후보 밖 값 금지, subset 규칙, 불충분 시 BLOCK_REVIEW) ⑤ 결과를 위 경로에 write ⑥ `"L1 예외 판정 완료 (decisions=<건수>)"`만 출력 후 종료.
3. ABSOLUTE_FORBIDDEN: pack 외 파일 read / `legal_effect_structures.json`·seed bundle·audit 작성 / 새 BO·evidence·structure·cluster ID·사실 창작 / pack에 없는 exception_id / markdown fence.
4. FAILURE_POLICY: pack 부재·파싱 불가 시 판정 파일을 쓰지 않고 `FAILED: <사유>`만 출력. tool 오류는 1회만 재시도.
Plan B(STEP 0-4 실패 시): `preflight: false`, `<L0_EXCEPTION_PACK>{{prev.Task_L0_structure_seed_reducer.json_output}}</L0_EXCEPTION_PACK>` 주입으로 대체하고 L0 stdout에 pack 요약을 포함시킨다(§3-4).
---
## 7. STEP 3 — L2 명세 (`Task_L2_final_structure_index_writer`)
code-executor(timeout 180). v1 LES3(1894~2638행) 이식 + 다음 개정:
1. **입력 채널 정리(X-9)**: `SEED_RAW`·`ADJUDICATION_RAW` 템플릿 주입을 **제거**한다(SEED_RAW는 100% 사장 실증). 입력은 파일 read 3종: seed bundle(v2) + exception pack(v2, `exception_pack_ref.sha256` 대조) + adjudication 파일. adjudication 파일 내용 파싱에는 SKILL §6.7 관용 파서(코드펜스 salvage 후 strict 검증)를 적용한다.
2. **판정 검증(이식+개정)**: `_expected_exceptions`는 seed bundle 내장 pack 대신 **exception pack 파일**에서 읽는다. `_validate_decisions`의 커버리지·enum·subset·중복·미지 ID hard fail은 이식 유지하되, expected 집합과의 등식을 X-5 모델로 확장한다: `expected_exception_ids == resolved_ids ∪ blocked_ids` (L0의 deterministic_review 항목은 pack에 없으므로 별도 집합).
3. **X-5 review 상태 재계산**: 구조물별 `review_required`를 다음으로만 산정한다 — 해당 seed의 `pending_exception_ids` 중 **blocked**(BLOCK_REVIEW 판정 또는 blocked_review_items)가 존재, 또는 `deterministic_review_codes` 존재, 또는 split 구조. **비차단 판정으로 해소된 예외는 review를 발생시키지 않는다.** review_queue에는 (a) blocked exception(식별 항목), (b) deterministic_review 항목(식별 항목 — v1에서 누락되던 자동차단 추적성 복원), (c) review_required 구조만 남긴다. 해소된 항목은 audit 파일의 `review_reduction_trace[]`에 {exception_id, 해소 방법, 근거}로 전량 기록한다(§1-4).
4. **X-6 multi-routing additive 인덱싱**: 구조물 top-level에 `candidate_structure_types[]`(routing_audit에만 있던 전 타입)를 추가하고, `structure_index.by_candidate_structure_type`을 **전체 canonical 타입 기준으로** 생성한다(구조가 보유한 모든 타입에 대해 해당 타입 키 아래 등록 — 기존 대표 타입 항목의 필드 구조는 유지). `by_bo_id` row의 `candidate_structure_types`도 전 타입 합집합으로 채운다. 기존 키·오브젝트 형태는 변경하지 않는다(additive).
5. **빌더·게이트 이식 유지**: `_build_structures`(LES-/IC-/AC- 부여 순서 동일), `_build_structure_index`(5-way), `_quality_gate`(BO/evidence coverage), `_validate_payload`(교차 참조 검증 — additive 필드 검증 추가), write 전 검증 → write → 재읽기 검증 순서 유지. **검증 실패 시 기존 final file을 overwrite하지 않는다**(검증을 write 앞에 두는 현행 순서 유지가 곧 이 보장).
6. **stdout 1줄**: `{"status", "message", "written_file", "payload_status", "structure_count", "review_queue_count", "resolved_exception_count", "blocked_exception_count"}`. FAILURE_POLICY는 §5-10과 동일(FAILED 1줄 + raise).
---
## 8. 모델·프리픽스 규칙 요약
| task | 유형 | 모델/사양 | 프리픽스 |
|---|---|---|---|
| L0 | code-executor | — | — |
| L1 | LLM 조건부 | gemini-3.1-flash-lite / low / low / max_iterations 1 | 현행 LES2 블록 바이트 유지 (= Part 2 R1과 동일, 58f2b72d) |
| L2 | code-executor | — | — |
v1 헤더에 stage-level LLM 선언은 없으므로 관련 조치 불요. LES2의 `gemini-3.5-flash/high/medium/2` → L1 사양으로 교체하는 것은 N-4 판정(BLOCK_REVIEW 안전판 전제)에 따른 것이며, 잔여 예외의 판정 품질 우려는 §11 주입 테스트와 D-1 모니터링으로 통제한다.
---
## 9. task_procedure (전면 교체)
```yaml
task_procedure:
IN:
nexts: [Task_L0_structure_seed_reducer]
wait_until: []
Task_L0_structure_seed_reducer:
nexts: [Task_L1_exception_adjudicator]
wait_until: [IN]
Task_L1_exception_adjudicator:
nexts: [Task_L2_final_structure_index_writer]
wait_until: [Task_L0_structure_seed_reducer]
Task_L2_final_structure_index_writer:
nexts: [OUT]
wait_until: [Task_L1_exception_adjudicator]
OUT:
nexts: []
wait_until: [Task_L2_final_structure_index_writer]
```
---
## 10. 수용 기준 (Definition of Done)
### 10.1 정적 검사
1. `Stage_1_Part_3_Claude_v3.yml` YAML parse 성공, task 수 3, task_procedure가 §9와 일치, unreachable task 0, 폐기 참조(`SEED_RAW`, `ADJUDICATION_RAW`, `legal_effect_structure_input_pack`, `{{prev.Task_LES0…}}`, `{{prev.Task_LES1…}}`, `budget_overflow`) 잔존 0.
2. embedded Python 전부 `ast.parse` 통과, SKILL 준수(boilerplate·hash placeholder·raw_decode fallback·stdout 단일 JSON 라인·`r"""…"""`·실패 시 raise).
3. `legal_effect_structures.json` writer 정확히 1개(L2), exception pack·seed bundle·audit writer 정확히 1개(L0), adjudication writer 1개(L1).
4. L1 프리픽스가 Part 2 Claude v3 R1 블록과 **바이트 동일**.
5. L1 사양 §8 일치(flash-lite/low/low/1, preflight pack 1파일).
### 10.2 fixture 회귀 (7/10 실행물 입력, 코드 로컬 실행)
1. **L0**: 입력 5종만 read, pack 파일 미생성, seed 50건, `has_exceptions=false`(X-1~X-4 적용 결과 — 7/10의 47건 예외가 전부 결정론 해소), nonrouting_labels에 비-canonical 라벨 전량 보존, seed bundle ≤250KB.
2. **L1 경로**: has_exceptions=false → no-exception 판정 파일 + 즉시 종료 시뮬레이션.
3. **L2 골든 동등**: 최종 `legal_effect_structures.json`이 현행 골든(021b5d8f8ec2) 대비 — (a) 구조 50건·`LES-###` 순서·**대표 candidate_structure_type 50건 완전 일치** (b) source_bo_ids/evidence_indexes/linked_* 필드 동일 (c) IC/AC 매핑의 결정론 동등 (d) additive 필드(candidate_structure_types 등)와 review 재계산 차이만 허용 — review 축소분은 audit `review_reduction_trace`에서 전량 추적 가능 (e) BO 50건 by_bo_id 100% + evidence coverage PASS (f) **Part 4 FL0 validator 무수정 통과**(로컬 실행) (g) canonical 타입 보존: 개정 전 최종 산출의 canonical routing 타입 집합이 개정 후 candidate_structure_types 합집합의 부분집합.
4. **coverage 등식**: `expected_exception_ids == resolved ∪ blocked` + deterministic_review 전량 식별 항목화. 단순 multi-routing만으로 생성된 review 0건.
5. **2-run 바이트 결정론** (L0/L2 산출 전 파일).
6. **주입 테스트**: ① 진짜 비가역 type 충돌(상호 배타 필드가 실제 충돌하는 합성 케이스) 주입 → pack 수록·L1 발동 경로 ② ref 상충 자산 주입 → 결정론 분리 보존(pack 미수록) ③ L1 BLOCK_REVIEW 시뮬레이션 → L2 review_queue에 식별 항목 반영 ④ adjudication 파일 부재/코드펜스 → L2가 관용 파서로 salvage 또는 FAILED(최종 파일 미작성) ⑤ 커버리지 등식 위반(누락 판정) → L2 hard fail.
7. **성능 실측(사전 추정)**: 중간 파일 합계·stdout 합계를 §10.3 목표와 대조해 기록.
### 10.3 성능 합격 기준 (실 재실행, cold/warm 구분 3회 median)
중간 파일 891KB → 300KB 이하, stdout 290KB → 2KB 이하, LLM 실행 상시 1회 → 조건부(정상 fixture 0회), 런타임 3:40 → 40% 이상 단축, 표시 비용 $0 유지. task별 elapsed·token·cache hit 기록 권장. **§10.2 품질 불변식 위반 시 성능 달성해도 실패.**
---
## 11. 개정 보고서 기재 의무
v3 저장 시 다음을 최종 보고에 명시한다: (1) 7/10 기준 예외 47→0의 해소 내역(X-1 정규화로 소거된 건수 / X-3 alias 병합 건수 / defer 보존 건수), (2) review_queue 78→N의 축소 내역과 audit 추적 경로, (3) Plan A/B 중 적용 채널, (4) D-1(예외 발생률 모니터링)·D-2(Part 1 GB 프리픽스 정렬)·D-3(issue cluster 고도화)의 후속 이관.
## 12. 금지 사항 최종 목록
1. v1 원본 덮어쓰기·이동·삭제 금지 (v3는 신규 파일).
2. §1 불변 계약(최종 파일 스키마·5-way index·ID 규칙·판정 enum) 변경 금지 — additive만 허용.
3. Part 1/2/4 YAML 수정 금지.
4. canonical 타입을 하나만 남기는 축소 금지 — 모든 타당한 multi-routing 타입 보존.
5. 자산의 fuzzy 문자열 병합 금지 — ref/alias 근거 없는 병합은 SEPARATE 보존.
6. unresolved/blocked 예외의 review 삭제 금지, 해소 항목의 무추적 삭제 금지(audit 필수).
7. L1에 pack 외 입력 제공 금지, L1의 최종 파일·seed·audit 작성 금지, 후보 밖 값 생성 금지.
8. nonrouting 라벨의 파괴적 삭제 금지(audit 보존 필수).
9. 본 명세서에 없는 "개선"의 임의 추가 금지 — 범위 밖 아이디어는 개정 보고서에 제안으로만 기록.
10. 실패의 `sys.exit(0)` 위장 금지, 검증 실패 상태에서 최종 파일 overwrite 금지.
@@ -0,0 +1,132 @@
# Stage 1 Part 3 비효율성 분석 보고서 (Claude v1)
- 분석 대상: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml` (2,638행, task 4개)
- 실행 실측: 런타임 3분 40초 / 비용 $0 (7/10 실행, `Results_July_10_3_15pm`)
- 참조 명세: Part 1 `Stage_1_Part_1_Claude_v3.yml`, Part 2 `Stage_1_Part_2_Claude_v3.yml`(개정 완료본), Part 4 `Stage_1_Part_4_v2.yml`
- 작성 관점: 20년 이상 경력의 대한민국 최고 수준 변호사 + 세계적 수준의 AI 아키텍트
## 0. 분석 방법 — 실행물 기반 실측
본 보고서의 모든 정량 수치는 추정이 아니라 **7/10 실행물로 Part 3 전체 코드를 로컬 재실행하여 얻은 실측**이다. 재실행 결과가 실제 실행물과 바이트 단위로 일치함을 먼저 확인하였다: LES0가 쓴 `legal_effect_structure_input_pack.json` 416,115B, LES1이 쓴 `legal_effect_structure_seed_bundle.json` 422,236B와 `legal_effect_structure_exception_pack.json` 52,982B가 모두 실제 실행물과 동일 바이트로 재현되었다. 따라서 아래의 stdout 크기·예외 건수·미사용 필드 판정은 실제 7/10 실행에서 일어난 일 그 자체다.
## 1. Part 3 실행 구조와 데이터 흐름 실측
Part 3는 완전 직렬 4-task 체인이다: `IN → LES0(input pack 컴파일, Python) → LES1(결정론 seed/예외 생성, Python) → LES2(예외 판정, LLM: gemini-3.5-flash/high/medium, max_iterations 2) → LES3(최종 writer, Python) → OUT`. 병렬 구간이 전혀 없으므로 DAG 관점의 이득은 0이고, 효율은 오로지 각 단계의 페이로드와 LLM 소비가 결정한다.
7/10 실행에서 실측된 데이터 흐름은 다음과 같다.
| 구간 | 채널 | 실측 크기 |
|---|---|---|
| LES0 입력 | localdocs read ×8 (client_goal, BO, evidence_indexed, **evidence_all 87,436B**, event_candidates, signal 3종) | 합계 약 340KB |
| LES0 → 파일 | `legal_effect_structure_input_pack.json` (indent=2) | 416,115B |
| LES0 → stdout | **pack 전체를 compact JSON으로 재출력** | 257,367B |
| LES0 stdout → LES1 | `{{prev.…}}` 템플릿으로 **LES1 코드 안에 재주입** | 257,367B (run_code 페이로드 약 297KB) |
| LES1 → 파일 | seed bundle 422,236B + exception pack 52,982B | 475,218B |
| LES1 → stdout | 요약 + adjudicator_input 전체 | 32,617B |
| LES1 stdout → LES2 | 프롬프트 주입 (정적 블록 14,154B 포함 프롬프트 총 46,771B) | 32,617B |
| LES1 stdout → LES3 | `SEED_RAW` 템플릿 주입 — **아래 P3-5: 100% 사장** | 32,617B |
| LES3 입력 | seed bundle **파일 재읽기**(항상) + LES2 stdout | 422,236B + α |
| LES3 → 파일 | `legal_effect_structures.json` (최종, write 후 재읽기 검증) | 254,991B |
즉 최종 산출물 255KB를 만들기 위해 중간 아티팩트 891KB가 파일로 쓰이고, 290KB가 stdout으로, 322KB가 코드/프롬프트 주입으로 이동한다. 그리고 이 모든 것의 유일한 실질 소비자는 파이프라인 내부의 바로 다음 task 하나씩이다.
## 2. 비효율 판정 항목
### 2.1 토큰·전송 비경제
**P3-1. input pack의 3중 물질화.** LES0는 같은 내용을 (1) 파일 416KB, (2) stdout 257KB, (3) LES1 코드 주입 257KB로 세 번 실어 나른다. stdout과 템플릿 주입은 백엔드 컨텍스트/로그와 run_code 요청에 그대로 누적된다. Part 2 v2에서 지적되어 v3(A0)가 "파일 write + stdout 1줄 요약"으로 해소한 것과 동일한 유형(C-9)이며, Part 3에는 아직 그대로 남아 있다.
**P3-2. pack 내용의 55%가 유일 소비자(LES1)에게 미사용.** pack의 compact 크기 약 232KB 중 LES1 코드가 실제로 참조하는 키는 `candidate_inputs_by_bo_id`(98.5KB)와 `evidence_authority_by_index`(5.3KB)뿐이다. `bo_by_id` 82.7KB는 변수 할당 후 한 번도 참조되지 않고, `signals_by_bo_id` 42.2KB는 `candidate_inputs_by_bo_id` 안에 각 BO의 `signals`로 **완전히 중복 재수록**되어 있으며, `events_by_evidence_index` 2.9KB와 `client_goal_compact` 0.6KB도 참조 0회다. 미사용 합계 약 128KB(55%)가 세 채널(P3-1)로 각각 운반된다.
**P3-3. `evidence_all.json`(87KB) 읽기의 기여가 실측 0.** LES0의 evidence authority 수집기를 evidence_all 포함/제외로 각각 재실행해 비교한 결과, 30개 evidence index 전부에서 산출이 완전히 동일했다. `evidence_indexed.json`과 `BO.json.Evidence`가 이미 전 항목을 커버하기 때문이다. Part 3에서 가장 큰 입력 파일 하나가 순수 낭비다.
**P3-4. seed bundle의 이중 저장·미소비 필드.** LES1이 쓰는 seed bundle 422KB 중 LES3가 읽지 않는 필드가 약 80KB다: `ambiguity_diagnostics` 34.9KB, `candidate_structure_type_index_seed` 43.4KB, `multi_asset_bundles` 2.0KB(모두 LES3 참조 0회 — LES3는 by_type 인덱스를 구조물에서 재계산한다). 또한 exception pack이 seed bundle **내부에 32.6KB로 내장**되고 **별도 파일로 53KB 재저장**되는데, 별도 파일을 읽는 소비자는 Part 3/Part 4 어디에도 없다(LES3는 내장본을 사용). input pack 파일 역시 정상 경로에서는 아무도 읽지 않는다(LES1의 템플릿 실패 시 fallback 전용).
**P3-5. LES3의 `SEED_RAW` 주입은 구조적으로 사장(死藏)되어 있다.** LES3는 `SEED_RAW = r'''{{prev.Task_LES1_…}}'''`로 LES1 stdout 32.6KB를 주입받아 seed bundle로 파싱을 시도하고, 실패 시 파일을 읽는 설계다. 그런데 LES1 stdout의 루트 키는 `legal_structure_les0_seed_generation`과 `legal_structure_exception_adjudicator_input`뿐이고 `legal_structure_seed_bundle`이 **없다**. 따라서 이 파싱은 100% 실패하고 LES3는 **매 실행 항상** 422KB 파일을 다시 읽는다. 의도한 최적화가 한 번도 작동한 적 없는 dead code이며, 32.6KB 주입은 순수 낭비다.
### 2.2 LLM 추론 비효율 — "판정이 산출물을 바꾸지 못했다"
**P3-6. LES2는 예외 유무와 무관하게 무조건 실행된다.** 조건부 실행·조기 종료 구조(Part 1 v3 GB, Part 2 v3 R1의 "pack만 preflight, 예외 없으면 즉시 종료" 패턴)가 없다. 입력도 파일이 아니라 LES1 stdout 전체(32.6KB)를 프롬프트에 싣는 방식이고, 이 중 첫 465B(les0_seed_generation 요약)는 계약상 불필요하다.
**P3-7. 예외 생성 과다 → LLM 판정의 실질 무효화 (핵심 실측).** 7/10 실행에서:
| 단계 | 실측 |
|---|---|
| LES1이 생성한 예외 (병합 후) | **47건** (BO 50건 대비 94% — 사실상 전 항목이 "예외") |
| 그중 LLM에 전달 | 30건 (budget cap) — type 24 + asset 6 |
| LES2 판정 결과 | **28건(93%)이 BLOCK_REVIEW 회신** (insufficient_compact_record 24 + conflicting_allowed_decisions 4) |
| 실질 판정 | ≤2건 |
| 최종 산출물에 미친 영향 | **0** — 구조물 50건 전부의 대표 타입이 결정론 우선순위 규칙(priority-first)과 100% 일치, split 0건, multi-routing 전건 보존 |
즉 LES2를 통째로 제거하고 "PRESERVE_MULTI_ROUTING + 우선순위 대표 타입"이라는 결정론 기본값을 적용했어도 `legal_effect_structures.json`은 **동일하게** 나왔다. 원인은 두 가지다. 첫째, `_candidate_structure_types`가 signal·domain tag·source_domain 매핑을 전부 합집합하므로 거의 모든 BO가 복수 타입을 갖게 되고, 복수 타입이 서로 다른 downstream role로 매핑되면 기계적으로 예외가 된다(과다 생성). 둘째, 판정에 필요한 근거를 1.2KB compact 레코드로 제한했기 때문에 LLM 스스로 "근거 불충분"을 93% 선언한다. 예외로 보낼 필요조건(Part 2 개정에서 정립한 X-3 4중 조건: 단일 값 선택이 필수 + 후보 2개 이상 + 보존·defer 불가 + compact로 판정 충분)을 적용하면 이 47건 중 pack에 남을 항목은 사실상 0건이다.
**P3-8. budget_overflow에 의한 임의 절단.** 자동 차단 17건의 사유는 전부 `budget_overflow`(max_llm_items=30 초과)다. 즉 예외 47건 중 어떤 17건이 LLM 판정도 받지 못하고 조용히 review로 빠지는지가 정렬 순서(유형 → BO 수 → id)라는 임의 기준으로 결정된다. 판정 대상 선별이 법률적 중요도가 아니라 큐 순서로 정해지는 구조다(과다 생성의 2차 피해).
**P3-9. 판정 결과가 review 신호에 반영되지 않아 리뷰 큐가 포화된다.** LES1은 예외가 하나라도 걸린 seed에 `review_required=true`를 찍는데, LES2가 그 예외를 확신 있게 판정해도 이 플래그를 해소하는 로직이 없다. 결과: **구조물 50건 전부 review_required=true, review_queue 78건**(structure_review_required 50 + blocked_exception 28). 변별력 0인 리뷰 신호는 인간 검토자와 Stage 2 모두에게 무의미하며, LLM이 수행한 판정 노동의 가치도 소거된다. 또한 자동 차단 17건은 최종 review_queue에 식별 가능한 항목으로 남지 않고(감사 필드에만 존재) 구조물 플래그로만 뭉개져 추적성 공백이 있다.
**P3-10. 사양 과잉(부차적).** enum 선택형 라우팅 판정에 `llm_reasoning: high` + `llm_verbosity: medium` + `max_iterations: 2`가 설정되어 있다. 비용은 실측 $0(flash 계열)이므로 금전 문제는 아니나, 30건 판정 + 28건 블록 사유 서술 출력은 3:40 런타임 중 LLM 구간을 불필요하게 늘린다. 한편 LES2의 `COMMON_CACHE_PREFIX_STAGE_1`은 Part 1/2 canonical과 **바이트 동일**(sha256 앞 8자리 58f2b72d)임을 확인했다 — 이 부분은 이미 정합하며 유지하면 된다.
### 2.3 DAG·실행 구조 비효율
**P3-11. 순수 결정론 작업의 3-task 분할.** LES0·LES1·LES3는 전부 결정론 Python인데 별개 run_code task로 분리되어, MCP 세션 초기화 3회, localdocs 왕복 다수(입력 8 read + 중간 파일 write 3/재읽기 2), run_code 왕복 3회가 발생한다. LES0→LES1은 다른 소비자가 전혀 없는 pack을 사이에 두고 갈라져 있을 뿐이므로 합치면 pack 자체(파일 416KB + stdout 257KB + 주입 257KB)가 사라진다. 완전 직렬 체인이라 분리로 얻는 병렬성 이득도 없다.
**P3-12. run_code 페이로드 비대.** LES1 요청은 코드 약 40KB + 주입 257KB ≈ 297KB다. 파일 채널로 바꾸면 코드만 남는다.
### 2.4 강건성·SKILL 정합 (Part 1/2 v3에서 확립한 기준 대비)
**P3-13.** 세 Python task 모두 read_docs 응답을 strict `json.loads`로만 파싱한다(SKILL.md가 금지한 "Extra data 취약" 패턴 — raw_decode fallback 부재). Part 1/2 v3에서는 전 task에 fallback을 적용했다.
**P3-14.** 실패 시 `sys.exit(0)` — 실패가 정상 종료로 위장되어 백엔드가 FAILED를 태스크 실패로 감지하지 못할 수 있다(Part 1/2 v3는 FAILED JSON 출력 + raise).
**P3-15.** LES3의 LES2 출력 파서는 코드펜스 salvage가 없고 오히려 tail 검사(````` 잔여물)로 실패하므로, LLM이 펜스를 붙이면 max_iterations 2에 의한 **재호출**이 유발된다. Part 2 v3 R0의 §6.7 관용 파서(salvage 후 warning 강등)와 대조된다.
### 2.5 유지해야 할 강점 (실측 확인)
공통 캐시 프리픽스의 바이트 정합(P3-10), 최종 산출물의 5-way 인덱스·커버리지 게이트·write 후 재읽기 검증, 예외 서명 병합(merged_from 9건 절감), LES3의 결정 enum·부분집합 검증은 견실하며 개정에서 그대로 보존할 자산이다.
## 3. 효율화 방안 — 최소 작업 / 최대 효과
개정 원칙은 Part 1/2 개정에서 검증된 문법의 이식이다: **결정론이 전부 처리하고, LLM은 결정론이 처리할 수 없는 소수 예외만 조건부로 본다. 채널은 파일로 단일화하고 stdout은 1줄 요약만 낸다.** 최종 산출물 `legal_effect_structures.json`의 스키마·인덱스 5종·Part 4 소비 필드(FL0의 `_compact_structure`가 읽는 13개 필드 + `by_bo_id`/`by_issue_cluster_id`/`by_asset_cluster_id` 인덱스 + status)는 불변 계약으로 고정한다.
**R-1. task 통합: 4 → 3 (LES0+LES1 → L0).** LES0와 LES1을 단일 code task `L0_structure_seed_reducer`로 합친다. input pack은 파일·stdout·주입 어디에도 물질화하지 않고 메모리 내 변수로만 존재시킨다. 이것만으로 P3-1·P3-2·P3-11·P3-12가 한꺼번에 소멸한다(pack 관련 전송 930KB 제거, run_code 1회·MCP 세션 1회 절감). L0의 산출은 (a) slim seed bundle 파일, (b) exception pack 파일(조건부 LLM용, Part 2 형식), (c) stdout 1줄 요약뿐이다.
**R-2. 입력 다이어트.** L0 입력에서 `evidence_all.json` 읽기를 제거한다(P3-3 — 기여 0 실측이므로 downstream 위험이 없다). seed bundle에서 LES3 미소비 필드(진단·type_index_seed·bundles)는 제거하거나 별도 소형 audit 파일로 이전한다(P3-4). exception pack은 단독 파일 1곳에만 저장하고 seed bundle 내장을 제거한다 — L2(현 LES3)의 `_expected_exceptions`가 파일을 읽도록 1줄 변경. 예상 seed bundle: 422KB → 약 250KB 이하.
**R-3. 결정론 defer 정책 도입으로 LLM 실질 0회화 (Part 2 X-2/X-3 이식).** 실측이 근거다: 판정 47건 중 최종 산출을 바꾼 것이 0건이므로, 아래 기본값은 7/10 사건에서 **무손실**이 보장된다.
| 예외 유형 | 결정론 기본값 (보존적) | 근거 |
|---|---|---|
| ambiguous_candidate_structure_type (24건) | `PRESERVE_MULTI_ROUTING` + 우선순위표 대표 타입 | 실측상 LLM 결과와 100% 동일. multi-routing 보존은 정보 무손실이며 Part 4는 전 타입을 소비 |
| ambiguous_asset_cluster (6건) | `SEPARATE_CLUSTER` 보존 + review code | 암묵 병합 금지 원칙(Part 2 near-dup KEEP_SEPARATE와 동형). 병합은 인간/후속 단계 결정 |
| ambiguous_issue_cluster (0건) | 현행 hard-key/score 규칙 유지 | 7/10에서 이미 결정론이 전건 처리 |
pack 수록은 X-3 4중 조건(①최종 writer가 단일 값을 선택해야만 진행 가능 ②source-backed 후보 2개 이상 ③보존·defer 불가 ④compact 근거로 판정 충분)을 전부 충족하는 항목으로 한정한다. LES2가 93%를 "근거 불충분"으로 되돌려 보낸 실측이 보여주듯, ④를 사전 적용하면 보낼 것이 거의 없다. 이로써 budget_overflow 임의 절단(P3-8)도 소멸한다(잔여 예외가 cap보다 훨씬 적어짐).
**R-4. LES2 → L1 조건부 어드주디케이터로 전환.** Part 1 v3 GB / Part 2 v3 R1과 동일 골격: `preflight_files: [exception pack]`만 입력, `has_exceptions=false`면 no-exception 판정 파일을 쓰고 "NO_EXCEPTIONS" 출력 후 즉시 종료. 프리픽스는 현행 canonical 블록(바이트 동일) 유지. `llm_verbosity`는 low로(enum 선택 출력), 모델·reasoning은 실질 0회화가 전제이므로 현행 유지를 기본으로 하되 flash-lite/low 하향은 통제된 A/B로만 검토(N-3 원칙 준용). max_iterations 재호출 의존 대신 L2에 §6.7 관용 파서를 이식한다(P3-15).
**R-5. L2(최종 writer) 정비.** 사장된 `SEED_RAW` 주입 제거(P3-5 — 파일 읽기로 일원화), 판정·defer 결과를 review 신호에 반영: 결정론/LLM 판정이 확정한 항목은 `review_required`를 해소하고, BLOCK_REVIEW·defer-review·자동 차단만 review_queue에 **식별 가능한 항목으로** 남긴다(P3-9). 이는 효율화이자 품질 회복이다 — 리뷰 큐가 "변호사가 실제로 봐야 할 것"만 담게 된다. 최종 파일 스키마는 불변.
**R-6. SKILL 정합 일괄 적용.** read_docs raw_decode fallback(P3-13), 실패 시 FAILED 1줄 출력 + raise(P3-14), stdout 전 task 1줄 JSON(P3-1의 stdout 측면), `r"""…"""` 템플릿 주입 유지.
**검증 계획(개정 시).** 7/10 fixture로 골든 회귀: L0→(L1)→L2 재실행 → `legal_effect_structures.json`이 현행 산출과 의미 동등(구조 50건, 대표 타입/IC/AC id 매핑, 커버리지 게이트 PASS, Part 4 FL0 파서 통과)해야 하며, review_queue는 축소가 **의도된 개선**이므로 "축소 전 항목의 전량이 audit에 추적 가능"을 통과 기준으로 삼는다. 2-run 바이트 결정론 포함.
## 4. 기대 효과 정량 요약
| 지표 | 현행 (실측) | 개정 후 (추정) |
|---|---|---|
| task 수 | 4 (직렬) | 3 (L1은 실질 0회 조기 종료) |
| LLM 호출 | 1회 무조건, 프롬프트 46.8KB, 판정 30건 | 예외 없으면 즉시 종료(수백 토큰), 있어도 pack만 |
| stdout 총량 | 약 290KB | 약 1KB (요약 3줄) |
| run_code 페이로드 | 약 340KB (LES1 297KB 포함) | 약 90KB (코드만) |
| 중간 파일 IO | 891KB write + 422KB re-read | 약 250KB write (slim bundle + pack) |
| 입력 read | 8파일 (evidence_all 87KB 포함) | 7파일 |
| 런타임 | 3분 40초 | 1분 내외 예상 (LLM 구간 소거 + 전송 1/4) |
| 비용 | $0 | $0 (유지) |
| 최종 산출 | 255KB, review 50/50 포화 | 스키마 동일, review 신호 변별력 복원 |
## 5. 잔여 리스크와 열린 질문
첫째, LES2를 "실질 0회"로 만드는 근거는 7/10 사건 1건의 실측이다. 사건 유형이 달라지면(예: 자산 동일성 다툼이 실제 쟁점인 사건) asset 예외 중 일부는 진짜 판정 가치가 있을 수 있으므로, L1을 **제거하지 않고 조건부로 남기는** 본 설계가 안전하다. 둘째, R-5의 review 신호 복원은 후속 소비자(Stage 2·인간 검토)의 기대를 바꾸므로, 축소된 큐가 감사 파일에서 전량 추적 가능해야 한다(검증 계획에 반영). 셋째, issue cluster가 7/10에서 BO당 1개(50:50)로 퇴화한 것은 클러스터링 키 설계의 개선 여지를 시사하나, 이는 효율이 아닌 기능 고도화 주제이므로 본 개정 범위 밖 제안으로만 남긴다.
---
*본 보고서의 수치는 전량 7/10 실행물과 로컬 바이트-일치 재실행에서 실측되었다. 다음 단계는 본 보고서를 기반으로 한 개정 전략 수립(Codex 보고서와의 비교 포함)이다.*
@@ -0,0 +1,634 @@
# Stage 1 Part 3 비효율성 분석 및 최적화 보고서
- 작성일: 2026-07-20
- 분석 대상: `Stage_1_Part_3_v1.yml`
- 연계 기준: 최적화된 Part 1·2와 현행 Part 4의 입출력 계약
- 평가 관점: 대한민국 민사소송 실무와 대규모 LLM 파이프라인 아키텍처를 함께 고려한 엄격 평가
## 1. 결론 요약
현행 Part 3은 `BO.json`과 3개 signal을 `legal_effect_structures.json`으로 전환하고 Part 4에 필요한 5개 index를 생성한다는 **외부 작업 목표는 달성**한다. 그러나 내부 실행 방식은 다음 이유로 효율성과 결과 품질 모두에서 개정이 필요하다.
1. LES2가 예외 유무와 무관하게 항상 한 번 실행된다.
2. 법률구조 유형이 아닌 `event`, `state`, 행위유형, 세부 사건 태그까지 `candidate_structure_types`로 승격하여 50개 BO 전부를 구조유형 예외로 만든다.
3. 하나의 BO가 여러 downstream 역할을 갖는 정상적인 multi-routing까지 LLM 판단 대상으로 보낸다.
4. 실측상 LES2 입력 30건 중 28건이 `BLOCK_REVIEW`로 끝났고, 예산 초과 17건은 LES2에 들어가지도 못했다.
5. LES3는 LES2가 예외를 해결해도 LES1의 `review_required: true`를 해제하지 않아, 최종 50개 구조 전부가 review queue에 남았다.
6. LES0은 LES1이 쓰지 않는 원문·상위 집합을 포함한 416,115 byte input pack을 파일로 쓰고 동일 내용을 stdout으로도 전송한다.
7. LES1 seed bundle은 진단·예외·재생성 가능한 index를 중복 보존하여 422,236 byte까지 커진다.
8. Part 1·2 v3의 common cache prefix와 Part 3의 prefix가 바이트 단위로 달라 upstream cache를 공유할 수 없다.
따라서 최적 개정 방향은 **“결정적 정규화로 예외 자체를 먼저 제거하고, 남은 비가역적 모호성만 조건부 micro-pack LLM으로 판정하며, LES3가 해결 상태를 다시 계산하도록 하는 것”**이다. 현재 fixture에서는 LES2 호출을 30건에서 원칙적으로 0건까지 줄일 수 있는 구조가 타당하다. 다만 실제 0건 달성 여부는 개정 후 동일 fixture 재실행으로 검증해야 한다.
## 2. 분석 범위와 근거
### 2.1 읽은 작업 명세서
| Part | 기준 파일 | 확인한 핵심 |
|---|---|---|
| Part 1 | `Stage_1_Part_1_Codex_v3.yml` | shard map, 결정적 B1/B2 gate, 조건부 wildcard adjudicator, 최종 audit/writer |
| Part 2 | `Stage_1_Part_2_Codex_v3.yml` | 5개 domain worker, 결정적 R0, 조건부 `R1_*`, F0 단독 writer, signal writer |
| Part 3 | `Stage_1_Part_3_v1.yml` | LES0 → LES1 → 단일 LES2 → LES3 구조 및 모든 Python/LLM 계약 |
| Part 4 | `Stage_1_Part_4_v2.yml` | `legal_effect_structures.json` 소비 계약, Fact Ledger 생성, LES2 재판단 금지 규칙 |
### 2.2 실행 결과 근거
`Results_July_10_3_15pm`의 Part 3 관련 산출물 전체를 계측하였다.
| 산출물 | 크기 | 핵심 수치 |
|---|---:|---|
| `BO.json` | 175,126 B | BO 50건 |
| `evidence_indexed.json` | 91,841 B | evidence 30건 및 registry/schedule component |
| `actio_case_signals.json` | 9,990 B | Part 3 입력 signal |
| `case_liability_signals.json` | 15,565 B | Part 3 입력 signal |
| `legal_effect_signals.json` | 19,093 B | Part 3 입력 signal |
| `legal_effect_structure_input_pack.json` | 416,115 B | LES0 중간팩 |
| `legal_effect_structure_seed_bundle.json` | 422,236 B | LES1 seed 및 중복 진단 |
| `legal_effect_structure_exception_pack.json` | 52,982 B | LES2 예외 30건 |
| `legal_effect_structures.json` | 254,991 B | 최종 구조 50건, review queue 78건 |
제공된 Part 3 전체 실행시간은 3분 40초, 표시 비용은 `$0`이다. 다만 결과 폴더에는 task별 timestamp, provider token usage, cache hit 여부가 없으므로 LES0·LES1·LES2·LES3별 정확한 소요시간을 사후 배분할 수는 없다. 아래 병목 판정은 YAML 구조, 실제 pack 크기, 예외 수와 최종 판정 결과에 근거한다. `$0` 표시는 계산량이나 wall-clock 지연이 없다는 의미가 아니다.
## 3. Stage 1 전체 흐름에서 Part 3의 위치
최적화된 Part 1·2는 이미 다음 패턴을 사용한다.
```text
deterministic planner/reducer
|
+---- no exception ------------------+
| |
+---- dynamic_fanout -> LLM_* --------+--> deterministic final writer
```
반면 Part 3은 예외가 없어도 단일 LES2를 반드시 통과한다.
```text
Part 1 v3 Part 2 v3
evidence + events -----> BO + 3 signals
|
v
Part 3 v1 (현행)
+-------------------------------+
| |
v |
LES0 input compiler |
| |
v |
LES1 seed builder |
| |
v |
LES2 single LLM, 항상 실행 |
| |
v |
LES3 final writer |
+-------------------------------+
|
v
Part 4 Fact Ledger
```
Part 3만 최적화된 upstream의 조건부 adjudication 패턴을 따르지 않는 것이 첫 번째 구조적 불일치다.
## 4. 현행 Part 3 작업 구조
| Task | 실행 유형 | 주요 입력 | 주요 출력 | 현재 역할 |
|---|---|---|---|---|
| `Task_LES0_input_pack_compiler` | Python | client goal, BO, evidence 3종, signals 3종 | `legal_effect_structure_input_pack.json` 및 전체 pack stdout | 8개 파일을 하나의 중간팩으로 통합 |
| `Task_LES1_deterministic_structure_seed_builder` | Python | LES0 stdout 또는 input pack 파일 | seed bundle, exception pack, LES2 compact input | issue/asset/type seed 및 예외 생성 |
| `Task_LES2_single_cluster_exception_adjudicator` | LLM | LES1의 adjudicator input | 단일 adjudication JSON | 최대 30개 예외를 한 호출에서 판정 |
| `Task_LES3_final_structure_index_writer` | Python | seed bundle 및 LES2 응답 | `legal_effect_structures.json` | 최종 구조와 5개 index 생성 |
현행 DAG는 완전 직렬이다.
```text
IN
|
v
LES0 (Python, 대형 input pack 작성 + 전체 stdout)
|
v
LES1 (Python, seed/exception 작성 + 30건 LLM pack stdout)
|
v
LES2 (Gemini 3.5 Flash, high/medium, 항상 1회)
|
v
LES3 (Python, final writer)
|
v
OUT
```
## 5. 실측으로 확인된 핵심 비효율
### 5.1 가장 큰 병목: 정상적인 multi-routing을 예외로 오인
LES0은 다음 값을 모두 `candidate_structure_types`에 합친다.
- `legal_effect_signals.candidate_structure_types`
- `case_liability_signals.liability_candidate_type`
- `actio_case_signals.actio_scope`의 일부 매핑값
- `domain_legal_effect_tag`, `legal_effect_tags`
- BO source domain의 coarse type
그 후 알려진 값으로 정규화되지 않은 문자열도 그대로 반환한다. 실제 input pack에는 다음이 함께 들어갔다.
- 법률구조 family: `money_claim`, `secured_debt`, `registry_invalidity`, `fraudulent_transfer` 등
- transport/state label: `event`, `state`
- 행위 분류: `법률행위(legal_acts)`, `사실행위(factual_acts)`, `준법률행위(quasi-legal_acts)`
- 세부 사건명: `변제`, `상계`, `소유권이전`, `임의경매`, `상속포기` 등
실측치는 다음과 같다.
| 항목 | 수치 |
|---|---:|
| candidate type 전체 출현 수 | 263 |
| distinct type 수 | 69 |
| 현행 role 규칙상 복수 downstream role로 판정된 BO | 50 / 50 |
| Part 4가 명시적으로 아는 canonical type만 남겼을 때 복수 role BO | 14 / 50 |
LES1은 type들이 둘 이상의 downstream role로 매핑되면 곧바로 `ambiguous_candidate_structure_type`을 만든다. 이 규칙 때문에 모든 BO가 한 번씩 예외가 되었다.
법률적으로도 이 판정 방식은 적절하지 않다. 하나의 사실이 대여금 청구, 승계책임, 담보관계, 사해행위 또는 가액산정에 동시에 연결되는 것은 모순이 아니라 **대체적·예비적 청구와 법률요건 사실을 보전하기 위한 정상적인 다중 라우팅**이다. Stage 1에서 하나만 고르는 행위는 오히려 downstream 법리 검토 범위를 부당하게 축소할 수 있다.
**판정:** 여러 canonical type의 공존 자체는 LLM 예외가 아니다. canonical type 전체를 보존하고, 대표 type만 고정 priority로 정하면 된다.
### 5.2 LES2의 실질적 판정 효용이 매우 낮음
LES1 결과는 다음과 같다.
| 예외 처리 단계 | 수치 |
|---|---:|
| raw type 예외 | 50 |
| asset 예외 | 6 |
| merge 후 대표 예외 | 47 |
| LES2에 전달 | 30 |
| budget 초과로 auto-block | 17 |
| LES2 결과 중 `BLOCK_REVIEW` | 28 |
| LES2가 비차단 판정한 건 | 2 |
최종 `legal_effect_structures.json`의 review queue는 다음과 같다.
| review 유형 | 건수 |
|---|---:|
| `structure_review_required` | 50 |
| `blocked_exception` | 28 |
| 합계 | 78 |
특히 type 예외 24건은 LES2에서 전부 차단되었다. 고성능 LLM이 처리한 예외 중 실제로 해소된 것은 asset 예외 2건뿐이다. 이 호출은 runtime을 사용하면서도 review queue를 거의 줄이지 못했다.
### 5.3 성공한 LLM 판정도 review 상태를 해제하지 못함
LES1은 `issue_exc`, `asset_excs`, `type_exc` 중 하나라도 있으면 seed의 `review_required`를 `true`로 고정한다. LES3는 최종 구조를 만들 때 다음 의미의 OR 연산만 한다.
```text
final review_required
= seed.review_required
OR blocked BO
OR split structure
```
LES2가 `SAME_CLUSTER`, `SEPARATE_CLUSTER`, `PRESERVE_MULTI_ROUTING` 등으로 예외를 성공적으로 해결한 경우에도 `seed.review_required`를 지우는 경로가 없다. 따라서 LES2의 성공 판정이 final review workload를 감소시키지 않는다.
**판정:** 이는 단순 성능 문제가 아니라 판정 상태 모델의 결함이다. seed에는 `review_required` 대신 `pending_exception_ids`를 두고, LES3가 unresolved/blocked/split 예외만으로 최종 review 상태를 다시 계산해야 한다.
### 5.3.1 `PRESERVE_MULTI_ROUTING`도 final index에 충분히 반영되지 않음
LES3는 type decision의 복수 `candidate_structure_types`를 구조 내부 `routing_audit`에는 남기지만, `structure_index.by_bo_id`와 `structure_index.by_candidate_structure_type`에는 대표 `candidate_structure_type` 하나만 넣는다. Part 4의 compact structure도 대표 type 하나를 중심으로 읽는다.
따라서 LES2가 어렵게 `PRESERVE_MULTI_ROUTING`을 선택해도 모든 canonical routing type이 final index를 통해 전달된다는 보장이 없다. 이는 LES2 판단의 downstream 효용을 더 낮춘다.
**개정 원칙:** LES3는 대표 type과 별개로 `candidate_structure_types[]` 전체를 final structure의 named field로 보존하고, `by_bo_id` 및 `by_candidate_structure_type`을 모든 canonical type에 대해 생성해야 한다. 기존 5개 index의 key 이름과 object 형태는 유지하므로 Part 4 계약과 양립한다.
### 5.4 30건 hard cap과 실제로 구현되지 않은 phase 2
LES1의 예산은 다음과 같다.
```text
max_llm_items = 30
max_candidate_values_per_item = 8
max_chars_per_item = 1200
overflow_policy = SPLIT_BATCH_THEN_BLOCK
```
그러나 실제 DAG에는 split batch phase 2가 없다. 30건을 넘는 17건은 `budget_overflow`로 auto-block되고, 재판정 task가 생성되지 않는다. 명칭은 `SPLIT_BATCH_THEN_BLOCK`이지만 실행은 사실상 `TRUNCATE_THEN_BLOCK`이다.
이 방식은 다음 문제를 함께 만든다.
- 사건이 복잡할수록 LLM 검토를 더 받는 것이 아니라 더 많은 항목이 자동 차단된다.
- auto-block 항목은 exception pack에서 빠지고, final에는 개별 exception ID가 없는 포괄 review 상태만 남을 수 있다.
- 단일 30건 prompt가 길어져 독립 항목 간 주의력 경쟁과 JSON 누락 위험이 증가한다.
### 5.5 LES0의 과도한 read와 대형 중간팩
LES0은 8개 파일을 각각 MCP로 읽는다. 그러나 LES1의 실제 소비 관계를 추적하면 다음과 같다.
| input pack 필드 | compact JSON 크기 | LES1 실제 소비 | 판정 |
|---|---:|---|---|
| `bo_by_id` | 89,045 B | 변수에 할당만 하고 사용하지 않음 | 삭제 |
| `candidate_inputs_by_bo_id` | 102,148 B | 사용 | 유지·축소 |
| `evidence_authority_by_index` | 5,384 B | 사용 | 최소 필드 유지 |
| `signals_by_bo_id` | 42,199 B | 사용하지 않음; candidate에 이미 중복 | 삭제 |
| `events_by_evidence_index` | 2,669 B | 사용하지 않음 | 삭제 |
| `client_goal_compact` | 793 B | 사용하지 않음 | 삭제 |
`candidate_inputs_by_bo_id.related_event_candidates`도 LES1에서 읽지 않는다. 따라서 Part 3 관점에서 `client_goal.json`과 `evidence_event_candidates.json`의 read는 제거할 수 있다.
`evidence_all.json`은 evidence excerpt 보강 목적으로만 쓰인다. Part 3은 merits fact extraction을 다시 하는 단계가 아니며 최종 구조에는 evidence index가 핵심이다. 다음 조건을 충족하면 Part 3 read 대상에서 제거할 수 있다.
1. `evidence_indexed.json`이 evidence ID, title/source pointer, registry/schedule component를 제공한다.
2. BO가 자신의 `source_evidence_indexes`를 보존한다.
3. Part 4가 필요한 원문/excerpt는 Part 4 source pack에서 독립적으로 읽는다.
현행 Results 폴더에도 `evidence_all.json`은 보존되어 있지 않다. 다만 실제 운영 workspace에서만 존재하는 원문이 있으므로, 제거 전 fixture에서 evidence coverage conservation을 반드시 확인해야 한다.
### 5.6 대형 stdout과 파일 재읽기의 중복
LES0은 416,115 B input pack을 파일로 저장한 뒤 같은 pack 전체를 stdout으로 출력한다. LES1은 stdout parse에 실패하면 동일 파일을 다시 읽는다. 이 구조는 다음 비용을 만든다.
- localdocs write
- orchestration stdout 저장·전달
- 다음 task의 template 확장 및 JSON parse
- fallback 시 localdocs read
Python task 간 전달에 원문 전체가 필요하지 않다. stdout은 schema, status, path, hash, count만 포함하는 manifest로 제한하고, 실제 payload는 하나의 authoritative artifact에서 읽어야 한다.
### 5.7 seed bundle 내부 중복
실측 seed bundle의 compact component 크기는 다음과 같다.
| component | compact JSON 크기 | LES3 소비 여부 |
|---|---:|---|
| `structure_seed_items` | 75,377 B | 사용 |
| `issue_cluster_seed_map` | 21,162 B | 사용 |
| `asset_cluster_seed_map` | 19,430 B | 사용 |
| `evidence_index_seed` | 15,363 B | 사용 |
| `multi_asset_bundles` | 2,484 B | final writer 직접 사용 안 함 |
| `candidate_structure_type_index_seed` | 41,367 B | 사용 안 함; LES3가 final index 재생성 |
| `ambiguity_diagnostics` | 34,864 B | 사용 안 함 |
| 내장 `legal_structure_exception_pack` | 32,629 B | expected exception 검증에 사용 |
동일 exception pack은 별도 52,982 B 파일로도 저장된다. 즉 진단 배열, seed 내장 pack, 별도 pack에 같은 예외 데이터가 반복된다.
**판정:** 별도 exception pack을 authoritative artifact로 유지하고 seed에는 `exception_pack_path`, hash, expected exception IDs만 둔다. `candidate_structure_type_index_seed`는 삭제하고 LES3가 final structures로부터 재생성한다.
### 5.8 자산 alias/ref를 충분히 이용하지 않아 발생하는 false exception
실측 asset 예외 6건 중 다수는 다음 조합이다.
- `SCH-016-01` ↔ `성수동 256 대`
- `SCH-016-04` ↔ `평택시 ... 서정빌라 101호`
- `SCH-016-05` ↔ `흑석동 201호`
- 복수 부동산을 함께 적은 BO
`evidence_indexed.json`에는 `SCH-016-01` 등의 `schedule_ref`와 `canonical_label_candidate`가 이미 존재한다. 최적화된 Part 2 v3도 `asset_alias`에 `schedule_refs`/`registry_refs`를 보존하도록 명시한다. 그런데 현행 LES1은 keyed candidate와 unkeyed label을 별도 그룹으로 만든 후, 두 그룹이면 다시 LLM 예외를 만든다.
법률상 자산 동일성은 fuzzy 문자열 유사도보다 등기행·별지목록 ref가 우선한다. 다음 우선순위로 결정해야 한다.
1. 같은 `REG-*` 또는 `SCH-*` ref: 동일 cluster
2. Part 2 `asset_alias`가 ref와 label을 명시적으로 연결: 동일 cluster
3. 하나의 BO가 서로 다른 ref를 명시: 별도 cluster를 보존하고 multi-asset bundle 생성
4. ref 없는 자유문구만 있고 동일성이 불명확: 임의 병합하지 않고 `SEPARATE_CLUSTER + review` 또는 실제 비가역성이 있을 때만 LLM
이 규칙은 LLM보다 빠르고, 권리객체의 잘못된 병합을 방지하므로 법률적으로도 더 안전하다.
### 5.9 모델과 cache 설정의 과잉
현행 LES2는 다음 설정이다.
```text
model = gemini-3.5-flash
reasoning = high
verbosity = medium
max_iterations = 2
```
그러나 LES2가 허용하는 작업은 제공된 후보 중 enum 하나를 선택하거나 `BLOCK_REVIEW`를 반환하는 좁은 routing 판정이다. raw evidence, 외부 tool, 새로운 법률사실 생성은 모두 금지되어 있다. 이 작업에 `high` reasoning과 `medium` verbosity는 과도하다.
common prefix도 최적화된 Part 1·2와 다르다.
| 파일군 | prefix bytes | SHA-256 |
|---|---:|---|
| Part 1 Codex v3 / Part 2 Codex v3 | 3,385 | `6e01f72f1803767b6bb16b5aef6cf34760e6dc1b293c316c75e990d09ad5fe63` |
| Part 3 v1 / Part 4 v2 | 3,829 | `58f2b72d6c2650739c45d85cc57899150434db86a97bf19cd5a59d92d11dfbb5` |
문구가 유사해도 들여쓰기와 내용이 달라 byte-identical cache prefix가 아니다. Part 3은 Part 1·2 v3의 3,385-byte canonical block을 그대로 사용해야 한다.
### 5.10 실패를 성공 exit로 보고하는 문제
LES0, LES1, LES3는 exception을 잡아 `FAILED` JSON을 출력한 뒤 `sys.exit(0)`으로 종료한다. 이 경우 orchestration이 task 성공으로 오인하여 후속 task를 실행할 수 있다. 이는 재실행·디버깅 비용과 잘못된 최종 산출물 위험을 높인다.
실패 시 compact FAILED manifest를 출력하되 반드시 non-zero exit 또는 exception re-raise를 사용해야 한다. writer는 검증 실패 시 기존 final file을 overwrite해서는 안 된다.
## 6. Downstream 계약과 삭제 안전성
Part 4는 `legal_effect_structures.json`에 대해 다음을 강제한다.
- `schema_version == "stage1_legal_effect_structures.v1"`
- `status in {READY, READY_WITH_REVIEW}`
- `legal_effect_structures[]`
- `structure_index.by_bo_id`
- `structure_index.by_issue_cluster_id`
- `structure_index.by_asset_cluster_id`
- `structure_index.by_evidence_index`
- `structure_index.by_candidate_structure_type`
또한 Part 4 FL2는 LES2의 issue/asset/type ambiguity를 다시 판정하지 못한다. 그러므로 Part 3 최적화 시 **final contract와 unresolved review 신호는 절대 약화하면 안 된다.**
| 변경 대상 | 삭제/변경 안전성 | 근거 |
|---|---|---|
| final file name 및 schema | 변경 금지 | Part 4가 직접 검증 |
| final 5개 index | 변경 금지 | Part 4 source pack과 Fact Ledger join key |
| BO/evidence conservation gate | 유지·강화 | 구조 누락 시 Fact Ledger 누락으로 전파 |
| `client_goal_compact` in LES0 pack | 삭제 가능 | LES1/LES3 미사용, Part 4는 별도 입력 사용 |
| `events_by_evidence_index` 및 `related_event_candidates` | 삭제 가능 | LES1/LES3 미사용 |
| top-level `bo_by_id` | 삭제 가능 | LES1에서 할당만 하고 사용하지 않음 |
| top-level `signals_by_bo_id` | 삭제 가능 | candidate record에 필요한 ID/type가 이미 투영됨 |
| `candidate_structure_type_index_seed` | 삭제 가능 | LES3가 final structures에서 index 재생성 |
| seed 내 진단/exception 중복 | 삭제 가능 | 하나의 authoritative exception pack과 hash로 대체 |
| raw `evidence_all.json` Part 3 read | 조건부 삭제 | evidence ID/source conservation 검증 후 제거 |
| unresolved exception 및 review queue | 삭제 금지 | Part 4가 LES ambiguity를 재판단할 수 없음 |
## 7. 권장 개정 전략
### 7.1 P0: 정확성 결함을 먼저 수정
1. seed의 `review_required` boolean을 `pending_exception_ids`로 바꾼다.
2. LES3가 `resolved`, `blocked`, `split`, `auto_review` 상태를 exception ID별로 계산한다.
3. 최종 `review_required`는 unresolved/blocked/split인 경우에만 `true`로 한다.
4. `expected_exception_ids == decision_ids ∪ deterministic_resolution_ids ∪ blocked_ids`를 강제한다.
5. 중복 decision, 미지 exception ID, 후보 밖 selected value를 hard fail한다.
6. BO ID와 evidence ID conservation을 final write 전후 모두 검증한다.
7. Python task 실패는 non-zero로 종료한다.
### 7.2 P1: LES0 input diet
Part 3의 필수 read를 원칙적으로 다음 5개로 줄인다.
```text
BO.json
evidence_indexed.json
actio_case_signals.json
case_liability_signals.json
legal_effect_signals.json
```
LES0의 authoritative payload는 BO별 한 개의 compact record로 제한한다.
```json
{
"bo_id": "bh24",
"hard_issue_keys": {},
"canonical_structure_types": [],
"nonrouting_labels": [],
"asset_candidates": [],
"evidence_indexes": [],
"linked_claim_group_ids": [],
"linked_liability_group_ids": [],
"linked_actio_signal_ids": [],
"basis_codes": []
}
```
full BO와 full signal row를 중복 보존하지 않는다. stdout에는 다음만 출력한다.
```json
{
"les0_manifest": {
"status": "READY",
"artifact_path": "stage1_tmp/legal_effect_structure_input_pack.json",
"run_fingerprint": "sha256:...",
"bo_count": 50,
"candidate_count": 50
}
}
```
### 7.3 P2: 구조유형을 closed canonical routing enum으로 제한
Part 4가 실제로 module/role로 해석하는 type을 canonical enum으로 삼는다.
```text
money_claim
commercial_successor
secured_debt
registry_invalidity
land_use_gain
valuation
fraudulent_transfer
preserved_claim
succession_notice_lien_asset_defense
general_legal_effect
```
세부 법률효과·행위·상태 label은 삭제하지 말고 `nonrouting_labels` 또는 signal audit에 보존한다. 다만 `candidate_structure_types`와 예외 판정에는 넣지 않는다.
canonical type이 여러 개이면 다음을 결정적으로 수행한다.
1. 모든 type을 `candidate_structure_types`에 보존한다.
2. `representative_candidate_structure_type`은 고정 priority로 선택한다.
3. 모든 type으로 `legal_effect_roles`와 `by_candidate_structure_type` index를 만든다.
4. 복수 type 자체만으로 exception을 만들지 않는다.
LLM type 예외는 다음 경우로 한정한다.
- 서로 다른 type을 하나의 structure에 보존하면 final schema의 상호 배타 필드가 충돌하는 경우
- source-backed split 여부가 downstream 권리·청구 누락에 직접 영향을 주는 경우
- deterministic priority로도 대표값을 정할 수 없고 대표값이 실제 writer 동작을 변경하는 경우
현행처럼 단순히 downstream role 수가 2개 이상이라는 이유로 예외를 만들면 안 된다.
### 7.4 P3: asset ref 우선의 결정적 동일성 규칙
LES0에서 `evidence_indexed.schedule_items`와 registry component로 다음 map을 만든다.
```text
asset_alias_by_ref[REG-* or SCH-*]
-> canonical_label_candidate
-> evidence_index
-> usable_in_relief / section / row metadata
```
Part 2 v3의 `asset_alias.schedule_refs`/`registry_refs`와 결합하여 동일 ref는 같은 cluster로 묶는다. 여러 다른 ref가 존재하면 임의 병합하지 않고 별도 cluster와 bundle을 보존한다.
LLM asset 예외는 **상충하는 source-backed ref가 같은 법률상 자산을 가리킨다고 주장하면서, merge 여부가 실제 권리효과를 바꾸는 경우**로만 제한한다. 단순 자유문구 차이는 보수적 분리와 review flag로 처리할 수 있다.
### 7.5 P4: LES2를 조건부 wildcard micro-adjudicator로 전환
Part 1·2 v3에서 이미 검증한 구조를 그대로 이식한다.
```text
Task_LES1_deterministic_structure_seed_builder
outputs:
les1_manifest
dynamic_fanout: [] or [PACK-001, PACK-002, ...]
Task_LES2_exception_adjudicator_*
one compact pack per instance
writes one decision part file
Task_LES3_final_structure_index_writer
waits:
LES1
all Task_LES2_exception_adjudicator_*
```
권장 pack 한도는 다음과 같다.
| 항목 | 권장값 |
|---|---:|
| exception items per pack | 최대 3~4 |
| serialized pack size | 최대 12 KB |
| candidate values per item | 최대 8 |
| `max_concurrency` | 2 |
| model | `gemini-3.1-flash-lite` |
| reasoning | `medium` |
| verbosity | `low` |
| max iterations | 2 |
| tools | `[]` |
| preflight | `false` |
예외가 없으면 wildcard instance는 0개이고 LES3가 `READY_NO_EXCEPTIONS` 경로로 즉시 진행한다. 예외가 있더라도 독립 pack을 최대 2개씩 병렬 처리한다.
Part 3의 모든 LES2 wildcard instance는 Part 1·2 v3와 **완전히 동일한 3,385-byte common cache prefix**를 사용해야 한다. `cache_control.ttl`은 순차 Stage 1 전체 시간을 고려하여 `1h`로 둔다.
### 7.6 P5: 중간 artifact 단일화
다음 원칙을 적용한다.
- input pack: compact BO candidate records만 저장
- seed bundle: LES3가 실제 사용하는 seed/map만 저장
- exception pack: 예외 상세의 유일한 authoritative source
- decision parts: wildcard pack별 독립 파일
- stdout: path, hash, count, status, dynamic fanout만 출력
- final file: LES3만 작성
seed bundle에서 제거할 항목은 다음과 같다.
- `candidate_structure_type_index_seed`
- 전체 `ambiguity_diagnostics`
- 내장 full `legal_structure_exception_pack`
대신 다음만 둔다.
```json
{
"exception_pack_ref": {
"path": "stage1_tmp/legal_effect_structure_exception_pack.json",
"sha256": "...",
"expected_exception_ids": []
}
}
```
### 7.7 LES0·LES1 병합은 2차 최적화로 보류
LES0과 LES1은 모두 Python이며, 병합하면 한 번의 task/session과 input pack write/read를 없앨 수 있다. 그러나 첫 개정에서 두 작업을 합치면 source compilation과 legal routing seed 생성의 책임 경계가 한 코드에 결합된다.
가장 적은 변경으로 가장 큰 효과를 얻는 1차 개정은 다음이다.
1. LES0 payload 축소 및 stdout manifest화
2. LES1 false exception 제거
3. LES2 conditional wildcard화
4. LES3 review 상태 재계산
개정 후 계측에서 LES0→LES1 I/O가 전체 Part 3 runtime의 15% 이상이면 2차로 `LES01_compact_seed_exception_planner` 병합을 시행한다.
## 8. 권장 개정 DAG
```text
+----------------------------+
| no true exception |
| dynamic_fanout = [] |
v |
IN --> LES0 compact compiler --> LES1 deterministic reducer -------+--> LES3 final gate/writer --> OUT
| | ^
| | true exceptions |
| v |
| +-------------------------+ |
| | LES2_adjudicator_001 |-- decision ----+
| | LES2_adjudicator_002 |-- decision ----+
| | ... max_concurrency=2 | |
| +-------------------------+ |
| all
+-- compact artifact + hash -----------------------------+
```
## 9. Task별 개정 명세 요약
| Task | 유지/변경 | 핵심 개정 |
|---|---|---|
| LES0 | 유지·축소 | 5개 필수 파일만 read, compact candidate record, ref alias map, manifest stdout |
| LES1 | 유지·핵심 개정 | canonical type closed enum, multi-routing deterministic, ref-first asset clustering, pending exception ID, dynamic packs |
| LES2 | 단일 task 삭제 후 wildcard로 대체 | true exception만 micro-pack 판정, lite model, medium/low, 병렬 2개 |
| LES3 | 유지·강화 | all wildcard wait, exact coverage, resolved review 해제, hash/conservation, final 단독 writer |
## 10. 품질 보존 규칙
최적화는 단순 삭제가 아니라 다음 법률·데이터 보존 규칙을 전제로 한다.
1. canonical type을 하나만 남기지 말고 모든 타당한 multi-routing type을 보존한다.
2. 상충하는 자산 ref를 fuzzy match로 병합하지 않는다.
3. `REG-*`, `SCH-*`, BO ID, evidence ID, claim/liability/signal ID를 renumber하지 않는다.
4. unresolved 예외는 review queue에 남긴다.
5. Part 4가 LES ambiguity를 재판단하지 않으므로 Part 3에서 exception coverage를 봉인한다.
6. final 5개 index와 source BO/evidence coverage를 현행과 동일하거나 더 엄격하게 검증한다.
7. LLM은 후보 밖 값을 만들지 못하고, 불충분하면 `BLOCK_REVIEW`만 반환한다.
## 11. 개정 후 검증 기준
### 11.1 정적 검증
- YAML parse 성공
- 모든 task name과 DAG reference 일치
- Python code 전부 compile 성공
- localdocs direct MCP boilerplate에 user/workspace hash 포함
- read parser의 `raw_decode` fallback 포함
- 실패 경로 non-zero exit
- 모든 LLM task의 common prefix hash 일치
- wildcard parent의 `dynamic_fanout` 및 LES3의 `all Task_LES2_*` wait 확인
### 11.2 동일 fixture 회귀 검증
| 검증 항목 | 통과 기준 |
|---|---|
| BO conservation | 입력 BO 50건이 final `by_bo_id`에 100% 존재 |
| evidence conservation | seed evidence ID가 final index에 100% 연결 |
| final schema | Part 4의 현행 validator 무수정 통과 |
| canonical type 보존 | 개정 전 인정된 canonical routing type 누락 0 |
| exception coverage | expected = resolved + blocked + deterministic review |
| blanket review 제거 | 단순 multi-routing만으로 review 생성 금지 |
| writer authority | LES3 외 `legal_effect_structures.json` write 0건 |
### 11.3 성능 목표
아래는 구현 후 측정할 acceptance target이며 현재 달성 실측치가 아니다.
| 지표 | 현행 | 1차 목표 |
|---|---:|---:|
| input pack | 416,115 B | 200 KB 이하 |
| seed bundle | 422,236 B | 250 KB 이하 |
| LES2 전달 예외 | 30 + auto-block 17 | 정상 fixture 0, 예외 발생 시 pack당 3~4 |
| LLM task 실행 | 항상 1회 | 조건부 0..N |
| structure review | 50 / 50 | 실제 unresolved/split만 |
| Part 3 runtime | 3분 40초 | 3회 median 기준 40% 이상 단축 |
| Part 3 표시 비용 | `$0` | 증가 금지 |
runtime은 cold/warm cache를 구분하여 최소 3회씩 측정하고 median을 사용한다. task별 elapsed time, prompt/input/output token, cache hit, pack count도 함께 기록해야 다음 최적화가 가능하다.
## 12. 최종 권고
Part 3의 최우선 과제는 더 빠른 모델로 단일 LES2를 그대로 돌리는 것이 아니다. **LES1이 만들어내는 거짓 예외를 제거하고, 해결된 판정이 review 상태에 실제 반영되도록 상태 모델을 바로잡는 것**이 먼저다.
권장 적용 순서는 다음과 같다.
1. LES3의 `pending_exception_ids` 기반 review 재계산
2. canonical structure type과 deterministic multi-routing 도입
3. schedule/registry ref 기반 asset 정규화
4. LES0 read/payload/stdout 축소
5. LES2 conditional wildcard micro-pack 전환 및 lite model 적용
6. seed/exception artifact 중복 제거
7. 동일 fixture 회귀·성능 측정 후 필요할 때만 LES0·LES1 병합
이 순서를 따르면 Part 4의 외부 계약과 법률상 보수적 검토 원칙을 유지하면서, 현행 30건 monolithic LLM 호출과 17건 예산 차단, 50건 blanket review를 함께 제거할 수 있다.
@@ -0,0 +1,135 @@
# Stage 1 Part 4 개정 전략 선별 보고서 (Claude v1)
- 비교 대상: `Part_4_Inefficiency_Report_Claude_v1.md` ↔ `Part_4_Inefficiency_Report_Codex_v1.md`
- 목적: 두 분석의 교차 검증·상충 판정을 거쳐 Part 4 개정에 가장 적합한 전략을 선별
- 선별 기준: 최소의 노력(LLM 추론은 꼭 필요한 곳에 필요한 수준만, 100% 결정론 작업은 Python화, 토큰 경제성 최대화)으로 최대의 효과(최고 품질 유지, 토큰 경제성 증대, 에이전트 속도 최대화)
- 작성 관점: 20년 이상 경력의 대한민국 최고 수준 변호사 + 세계적 수준의 AI 아키텍트
## 0. 총평
Part 4에서는 두 보고서의 수렴도가 시리즈 중 가장 높다. 핵심 실증 — **FL2(pro-preview/high, $0.58 전액)가 42건을 판정했으나 최종 `Fact_Ledger_base.json`이 한 행도 바뀌지 않았다** — 에 양측이 서로 다른 방법으로 독립 도달했다(Claude: 42건 전량 KEEP_AS_IS 가상 판정을 FL3에 투입한 대조 실험으로 50행 완전 동일 재현 / Codex: 후보본·최종본 전후 비교로 변경 행 0·필드 0 확인). 예외 42건의 발생 원인(cardinality 오분류), pack 602KB의 중복 구조, 미소비 필드 목록까지 수치 단위로 일치하므로 사실 기반은 확정이다. 차이는 이번에도 처방의 결이다: Claude는 구조 소거(FL0+FL1 병합, pack 비물질화)와 근거 실질화(빈 excerpt 교정)를, Codex는 FL3 게이트의 실질 결함 3건(경계 위반 patch 적용, 비엄밀 coverage, blocked 상태의 READY 위장)과 upstream review 승계를 잡았다. 본 보고서는 Codex의 게이트·승계 발견을 코드 수준에서 재검증해 전량 채택하고, 프리픽스 상충은 Part 3 비교에서 확립한 3-way 실측 판정을 재적용해 정리한다.
## 1. 비교 분석
### 1.1 비효율 판정 항목 비교
**양측 공통 판정 (독립 교차 검증 — 확정 사실).**
| # | 공통 판정 | Claude | Codex |
|---|---|---|---|
| 1 | 예외 42건(role 40 + weak 2) = 후보 50행의 84% — cardinality 오분류가 원인 | P4-1 | §6.1 |
| 2 | **FL2 실질 효과 0** (최종본 무변경) — 두 방법으로 독립 실증 | P4-3 대조 실험 | §7.3 전후 비교 |
| 3 | FL2 무조건 실행 + pro-preview/high 과대 사양 | P4-4 | §7.1·7.2 |
| 4 | 예외 pack 147KB의 3중 이동(파일 내장·stdout 재출력·프롬프트 주입) + 항목 비대 | P4-2·P4-5 | §6.3 |
| 5 | pack 602KB: bo/signal/evidence의 전역+BO별 이중 수록, event 2계열·client_goal·index 4종 미소비 | P4-6 (소비 추적) | §5.1·5.2 (수치 일치) |
| 6 | `evidence_all.json` 의존 문제 | P4-7 (기여 0 실측) | §4.2 (재현성 관점) |
| 7 | 최종 스키마·possession/notice/lien 게이트 3종·FL3 골격은 보존 자산 | §2.5 | §15.3 |
**Claude 보고서 고유 발견.**
- **빈 증거 발췌(P4-9)**: FL0의 excerpt 수집 키가 `evidence_indexed.json`의 실제 필드(`key_facts`/`key_dates`/`key_amounts`)와 불일치하여 **evidence authority 30건 전부 excerpt=None**. credibility/proof_strength가 제목 문자열에만 의존하고, FL2에 제공된 `related_evidence_excerpts`가 빈 껍데기였다 — FL2 무효과의 근인 중 하나이자, 조건부 판정 체계에서 잔여 예외가 실제로 발생할 미래 사건을 위해 반드시 교정해야 할 품질 결함. Codex 미포착.
- `datetime.now()` 3곳(FL0/FL1/FL3)에 의한 2-run 바이트 결정론 파괴 — 골든 회귀 검증력 저하. Codex 미언급.
- read_docs **envelope 계층** strict `json.loads`(3 task) — SKILL Extra-data 취약. Codex 미언급.
- FL1 재현 바이트 일치(candidate 50행·예외 42건 완전 재현) 방법론 — 모든 판정의 신뢰 기반.
**Codex 보고서 고유 발견 (코드 재검증 결과 전량 사실 — 채택 가치 최상).**
- **경계 위반 patch의 실제 적용(§9.2)**: `_apply_patch`가 `allowed_output_fields` 밖 필드에 warning을 남긴 뒤 **그대로 `row[key] = value`를 실행**함을 코드로 재확인했다. LLM의 권한 경계 위반이 경고와 함께 최종 파일에 반영되는 실재 결함이다. 7/10에서는 발화하지 않았지만(전량 KEEP_AS_IS), 잔여 예외가 실재할 사건에서 봉인이 뚫리는 구멍이다.
- **비엄밀 coverage(§9.1)**: `expected ⊆ decided ∪ blocked`만 검사 — 미지 ID·중복 decision·양쪽 동시 수록·예외 0건에서의 임의 decision을 차단하지 못함을 재확인. Part 2/3 개정에서 확립한 coverage 등식이 Part 4에는 없다.
- **blocked 상태의 READY 위장(§9.3)**: FL3 stdout status가 blocked review 유무와 무관하게 `READY` 고정임을 재확인. 최종 파일이 상태 없는 배열이므로 이 stdout이 유일한 상태 신호인데 변별력이 없다.
- **upstream review 미승계(§8)**: Part 3의 review 상태를 FL1이 코드·플래그로, FL3가 report로 승계하지 않는다. Part 3 Claude_v2 개정으로 review가 실질 항목만 남게 된 지금, "실질 review의 결정론 승계"는 LLM 0회로 품질을 올리는 정확한 처방이다.
- **weak_derived_fact의 언어 편향(§6.2)**: 실제 2건("물품대금 지급 최고" 10자, "목적물 특정" 6자 — 재확인)은 법률상 유의미한 사실 표제다. 문자열 길이는 한국어 법률 표제의 완결성을 대변하지 못한다. 결정적 재작성 fallback + review 처방 채택.
- 회귀 fixture 12종 설계(§16.3) — 검증 계획에 통합 채택.
### 1.2 실행구조·병목 비교
구조 인식(직렬 4-task, FL2 상시 실행이 비용·런타임 지배, 중간 파일 1,020KB)은 완전히 일치한다. Codex의 병목 한 줄 요약 — "모델 자체보다, 정상 다중값을 대량 예외로 오분류하고 예외 0건에도 FL2를 반드시 실행하는 직렬 구조" — 은 Claude 실측과 정확히 합치하며 본 보고서의 공식 병목 정의로 채택한다. I/O 계량은 Codex(§5.3: localdocs 19회·MCP 세션 3개)가 더 세밀하고, 페이로드 계량은 양측 일치(FL2 프롬프트 ≈170KB = prefix 3.8K + overlay 9.7K + 주입 147~156KB)한다.
### 1.3 삭제/축소 안전성 비교 (downstream 근거)
`Fact_Ledger_base.json`의 27필드 닫힌 스키마와 행 순서·`F-###` 규칙은 Stage 2 핵심 handoff 계약으로 양측 모두 불변 판정이다. 양측 판정을 병합한 안전성 표:
| 대상 | 판정 | 근거 (양측 합산) |
|---|---|---|
| 최종 파일 스키마·writer report | 변경 금지 (status 규칙 정밀화는 additive) | Stage 2 소비 계약 (양측) |
| possession/notice/lien 게이트 3종 | 유지 (경량화 금지) | 법률상 sealed 게이트 (양측) |
| cardinality 기반 role/claim 예외 | 삭제 확정 | false positive 실증 + 최종 스키마가 원래 복수값 보존형 (양측) |
| 길이 기반 weak_derived_fact 예외 | 삭제 확정 → 결정적 재작성 fallback + review | 한국어 표제 실례 2건 (Codex) |
| pack의 중복·사장 필드 (signal global, event 2계열, client_goal, index 4종, bo 이중 수록) | 삭제 확정 | 소비 0 추적 (양측 일치) |
| `evidence_all.json` read | **제거 확정** | Claude 포함/제외 실험 기여 0 (30/30 동일) — Codex의 optional화 제안은 실측으로 상회. 부재·제거 사실은 manifest에 기록(Codex 재현성 지적 수용) |
| FL2 단일 필수 task | 조건부로 대체 확정 | 무효과 실증 (양측) |
| FL0·FL1·FL3 골격 | 삭제 금지, 병합·강화만 | provenance join·결정론 게이트·단독 writer (양측) |
| 중간 파일 파일명 | 유지 (내부 payload만 축소) | Stage 2·감사 도구 소비 미확인 (Codex §10 신중론 수용) |
### 1.4 권장 개정 전략 비교와 판정
| 쟁점 | Claude | Codex | 판정 |
|---|---|---|---|
| task 골격 | FL0+FL1 병합 → 3-task | 병합은 P2 보류, 4-task 유지 | **병합 채택.** Part 2(3,000행)·Part 3(LES0+LES1)에서 동일 병합을 골든 회귀로 2회 실증했고, 602KB pack의 3중 물질화는 병합 시에만 통째로 소멸한다. Codex의 회귀 위험 우려는 확립된 방법론(함수 단위 이식 + 바이트 재현 확인 + 골든 회귀)으로 통제 |
| LLM 형태 | 단일 조건부 (R1/L1 골격) | wildcard fan-out (shard 4건/25KB, flash-lite/medium) | **단일 조건부 채택.** 양측 모두 정상 경로 0회를 기대하는 상황에서 fan-out은 과잉 장치(Part 3 비교 N-1과 동일 판정). Codex의 shard 상한은 pack 구성 규칙(항목 ≤2KB·유형별 최소 context)으로 흡수 |
| 모델 사양 | flash-lite/**low** | flash-lite/**medium** | **low 채택.** BLOCK_REVIEW 안전판이 있어 판정 불충분은 인간 검토로 안전하게 낙하하며, GB·R1·L1과 문법 통일(Part 3 비교 N-4와 동일 판정) |
| 프리픽스 | 현행 유지 (= R1·L1과 바이트 동일) | 3,385B로 교체 | **현행 유지 확정.** 재실측: FL2의 3,829B(58f2b72d)는 Part 2 Claude v3 R1·Part 3 Claude v2 L1과 **바이트 동일**. Codex의 교체 주장은 Part 3 비교(§3 정정)에서 판정한 것과 동일하게 자사 v3 라인(3,385B) 기준의 오인이다. Claude 배포 라인에서 3,385B로 바꾸면 오히려 직전 Part의 같은 모델 태스크와 어긋나 캐시 실익이 사라진다. Part 1 GB 정렬은 D-2로 별도 |
| FL3 게이트 | (미포착) | exact coverage 등식·patch hard reject·status 규칙 | **Codex 설계 전량 채택** (코드 재검증 완료 — 실재 결함 3건) |
| upstream review 승계 | (미포착) | LES review의 결정론 승계 | **채택** — Part 3 Claude_v2의 실질 review·audit 체계와 접속 |
| 품질 교정 | excerpt 키 교정 (빈 발췌 30/30) | (미포착) | **채택** — 잔여 예외의 판정 근거 실질화 전제 조건 |
## 2. 선별된 개정 전략 (최소 노력 / 최대 효과)
### 2.1 개정 골격 — 4 task → 3 task
```text
IN → F0_fact_ledger_reducer (Python; FL0+FL1 병합. pack 비물질화, 입력 9→6
| (evidence_all·event_candidates·client_goal 제거),
| excerpt 키 교정, 예외 3분법(pass/deterministic review/
↓ true exception), LES review 결정론 승계,
F1_exception_adjudicator slim candidate bundle + exception pack 파일 write)
| (LLM 조건부; flash-lite/low/low/1, preflight=pack.
↓ has_exceptions=false → 즉시 종료. 실측 기대 0회)
F2_final_gate_and_writer (Python; exact coverage 등식, patch hard reject,
| status 3단 규칙, 게이트 3종 유지, 단독 writer)
↓
OUT
```
### 2.2 채택 작업 목록
| ID | 작업 | 출처 | 핵심 근거 |
|---|---|---|---|
| X-1 | **cardinality 예외 폐지**: role/module 복수 = 정상 다중 라우팅(최종 스키마 자체가 배열 보존형). 명시적 상호배타 conflict가 있을 때만 true exception | 양측 | 40건 false positive + KEEP_AS_IS 무손실 실증 |
| X-2 | **weak_derived_fact 교정**: 길이 트리거 삭제. 빈 값은 BO action/object/date로 결정적 재작성, 실패 시 review code | Codex §6.2 | 한국어 표제 실례 2건 |
| X-3 | **true exception 4중 조건 한정** (Part 2 X-3 이식): 단일 값 선택 필수 + source-backed 상충 근거 2+ + 보존·defer 불가 + compact 판정 충분. 항목당 ≤2KB·유형별 최소 context(전 유형 공통의 비대 envelope 폐지). legal_theory 계열은 LLM 금지·Stage 2 회부 | Claude + Codex §13 | 실측 기준 pack 0건 기대 |
| X-4 | **F0 통합 + pack 비물질화 + 입력 다이어트**: FL0+FL1 병합, fact_source_pack 파일 폐지(602KB 소멸), 입력 9→6 (`evidence_all`·`evidence_event_candidates`·`client_goal` 제거 — 기여 0/소비 0 실측; 제거 사실 manifest 기록), slim candidate bundle에는 후보 50행 + F2 검증용 ID 집합만(예외 pack 내장 제거 — 단독 파일화) | Claude R-1 + Codex §12 | 중복·사장 ~430KB 소거 |
| X-5 | **F1 조건부 전환**: flash-lite/low/low/max_iterations 1, `preflight_files: [exception pack]`, 무예외 시 no-exception 판정 파일 write 후 즉시 종료. SPLIT_FACT enum 삭제(실제 autosplit 미수행 — Codex §14.3), 프리픽스는 현행 블록 바이트 유지 | 양측 + §1.4 판정 | $0.58 → 0, LLM 구간 소거 |
| X-6 | **F2 게이트 강화(전량 Codex 설계)**: ① `expected == decided ∪ blocked` + `decided ∩ blocked = ∅` + 중복·extra ID 0 + count 정합 ② patch는 `allowed_output_fields ∩ FINAL_FIELD_SET` 밖이면 **적용 거부 + BLOCK**(warning 후 적용 금지) ③ status 3단 규칙(무결 READY / 검토 존재 READY_WITH_REVIEW / 위반 FAILED + overwrite 금지) | Codex §9·§15 | 실재 결함 3건 코드 확인 |
| X-7 | **LES review 결정론 승계**: Part 3 v2의 실질 review·blocked·audit 항목을 관련 Fact의 review code + `must_consider` + writer report로 승계, blocked 존재 시 READY 광고 금지 | Codex §8 | LLM 0회로 품질 상승 |
| X-8 | **증거 발췌 실질화**: excerpt 수집 키를 `key_facts`/`key_dates`/`key_amounts`로 교정 — credibility 판정과 잔여 예외 판정 근거의 회복 | Claude P4-9 | 30/30 빈 발췌 실측 |
| X-9 | **SKILL 정합 일괄**: 실패 시 FAILED 1줄 + raise(`sys.exit(0)` 폐지), envelope 계층 raw_decode, `datetime.now` 제거(2-run 바이트 결정론 확보), F2의 F1 출력 파싱에 §6.7 관용 파서 | Claude P4-11 | Part 1~3 확립 기준 |
| X-10 | **변별 신호 보강(additive 한정)**: must_consider/legal_centrality 필드·의미는 유지하되 변별 정보는 `skeleton_validation_codes`로 보강 | Claude P4-10 | Stage 2 계약 보호 |
### 2.3 기각·유보 항목
| ID | 항목 | 판정 근거 |
|---|---|---|
| N-1 | 프리픽스 3,385B 교체 (Codex §7.4) | 재실측 기각: FL2는 이미 Claude 배포 라인(R1·L1)과 바이트 동일. 교체 시 캐시 실익 상실. Stage 1 프리픽스 완전 통일은 D-2(Part 1 GB 1건 정렬)가 정도(正道) |
| N-2 | wildcard fan-out (Codex §11·14) | 기대 0회에 과잉 장치. shard 한도는 X-3에 흡수. 재발 시 확장(D-1) |
| N-3 | FL0+FL1 병합 보류 (Codex P2) | 2회 실증된 방법론 + 602KB 비물질화 효과가 병합에 결부 → 1차 포함 |
| N-4 | reasoning medium (Codex §14.2) | BLOCK_REVIEW 안전판 전제 low로 통일 (GB·R1·L1 문법) |
| N-5 | evidence_all optional 유지 (Codex §4.2) | 기여 0 실측으로 제거 확정. 재현성 문제의식은 manifest 기록으로 수용 |
### 2.4 후속·범위 밖
- **D-1**: 사건 다양화 시 true exception 발생률 모니터링 — 상시 다건화되면 wildcard 확장(Codex 설계 재사용).
- **D-2**: Part 1 GB 프리픽스의 3,829B 정렬(1줄) — flash-lite 4형제(GB·R1·L1·F1) 캐시 통일의 마지막 퍼즐.
- **D-3**: 중간 파일의 debug-mode 조건부 생성(Codex P2-3) — Stage 2·감사 도구 소비 확인 후.
### 2.5 검증 기준 (개정 작업 명세서 DoD 골자)
정적: task 3·DAG·ast·SKILL(hash/raw_decode/단일 stdout/raise/raw string)·F1 프리픽스가 R1·L1과 바이트 동일·writer 단일성·폐기 참조 0. 동적(7/10 골든): ① F0 has_exceptions=false + 예외 42건의 해소 내역 audit 추적 ② 최종 `Fact_Ledger_base.json` 50행이 현행과 의미 동등(KEEP_AS_IS 실증으로 사실상 동일 기대 — 타임스탬프 제거 반영) ③ writer report 게이트 결과 동일 + LES review 승계 항목 추가 확인 ④ 2-run 바이트 결정론 ⑤ 주입 테스트(Codex §16.3 fixture 12종 통합: true conflict → pack·F1 발동 / 임의 extra decision → F2 실패 / out-of-scope patch → 거부·차단 / blocked → READY_WITH_REVIEW / BO·ref conservation / notice·possession 게이트 유지) ⑥ Stage 2 소비 필드 무변경. 성능(실 재실행 3회 median): 중간 파일 1,020KB→150KB, stdout 157KB→1KB, LLM 조건부 0회, 비용 $0.58→≈0, 런타임 3:06→90초 이하(no-exception p95, Codex §16.2 채택).
## 3. 정정 사항
**프리픽스 상충의 재확인**: Codex 보고서는 Part 3 비교 때와 동일하게 "Part 1~3 v3가 3,385B이므로 Part 4도 교체"를 주장하나, 이는 Codex 자기 배포 라인 기준이다. Claude 배포 라인 실측(본 세션): Part 2 Claude v3 R1 = Part 3 Claude v2 L1 = Part 4 v2 FL2 = **3,829B(58f2b72d) 바이트 동일** — 즉 Claude 라인에서는 Part 4가 이미 정합 상태이고, 유일한 이탈은 Part 1 v3(3,385B)이다. 따라서 Part 4 개정에서 프리픽스는 손대지 않고, D-2로 Part 1을 정렬하는 것이 Stage 1 통일의 올바른 경로다. 한편 Claude 보고서도 Codex가 잡은 FL3의 실질 결함 3건(patch 적용·coverage·status)을 놓쳤음을 기록한다 — §2.2 X-6으로 전량 수용했다.
## 4. 결론
채택 전략은 "**양측 공통의 원인 소거(cardinality 예외 폐지) + Claude의 구조 소거(F0 통합·pack 비물질화·근거 실질화) + Codex의 봉인 강화(exact coverage·patch hard reject·status 규칙·review 승계)**"다. FL2 무효과의 이중 실증 덕분에 이 개정의 무손실성은 시리즈 중 가장 강하게 보증되어 있으며, 7/10 기준 LLM 0회·비용 $0로 현행 최종 파일을 그대로 재현하면서 FL3의 봉인 구멍 3개를 막아 품질은 오히려 올라간다. Part 4 개정이 완료되면 Stage 1 전체가 "결정론 reducer → 조건부 flash-lite 판정 → 결정론 writer" 단일 문법으로 통일된다. 다음 단계는 본 선별 결과를 LLM이 100% 수행 가능한 개정 작업 명세서(`Part_4_Improvement_Strategy_Claude_v1.md`)로 구체화하는 것이다.
@@ -0,0 +1,563 @@
# Stage 1 Part 4 최적 개정 방안
## 1. 문서 목적
이 문서는 다음 두 분석서를 비교·검증하여 `Stage_1_Part_4_v2.yml`의 최적 개정 방향을 확정한다.
- `Part_4_Inefficiency_Report_Claude_v1.md`
- `Part_4_Inefficiency_Report_Codex_v1.md`
선별 기준은 다음과 같다.
1. 사실·증거·법률효과 후보와 Stage 2 handoff 품질을 훼손하지 않는다.
2. 100% 결정 가능한 작업은 Python으로 처리한다.
3. LLM은 명시적 근거가 충돌하여 하나의 Stage 1 투영을 선택해야 하는 경우에만 실행한다.
4. 가장 적은 YAML·Python 변경으로 비용과 런타임의 가장 큰 병목부터 제거한다.
5. 중간 파일 삭제나 최종 스키마 변경은 downstream 소비 확인 없이 시행하지 않는다.
현재 연계 기준은 다음 Codex 개정본으로 고정한다.
- `Stage_1_Part_1_Codex_v3.yml`
- `Stage_1_Part_2_Codex_v3.yml`
- `Stage_1_Part_3_Codex_v2.yml`
- 개정 대상: `Stage_1_Part_4_v2.yml`
Claude 보고서가 참조한 Claude branch의 prefix·모델 설정은 비교 근거로만 사용하고, 실제 Part 4 개정은 위 Codex branch의 계약과 일치시킨다.
## 2. 통합 결론
두 보고서의 핵심 결론은 일치한다.
> Part 4의 주 병목은 FL2 모델보다 FL1이 정상적인 다중 라우팅을 대량의 예외로 오분류하고, FL2를 고사양 단일 LLM task로 무조건 실행하는 구조다.
7월 10일 fixture에서 확인된 핵심 수치는 다음과 같다.
| 항목 | 실측값 | 판정 |
|---|---:|---|
| Fact 후보 | 50행 | 정상 |
| 예외 | 42건 | 과잉 |
| 예외가 연결된 Fact | 40행, 80% | exception path가 main path로 변질 |
| `ambiguous_legal_role` | 40건 | 정상 복수값의 false positive |
| `weak_derived_fact` | 2건 | 문자열 길이 heuristic 오류 |
| exception pack | 146,998B, minified | LLM 입력 과대 |
| FL1 stdout | 약 156,444B | pack 재출력 비효율 |
| FL2 | Gemini Pro/high, 필수 1회 | 과대 사양·무조건 실행 |
| 후보 대비 최종 변경 | 행 0, 필드 0 | LLM 한계효용 0 |
| `fact_source_pack.json` | 602,059B | 중복·사장 데이터 과다 |
| candidate bundle | 418,076B | 예외 내장으로 비대 |
| 최종 `Fact_Ledger_base.json` | 128,855B | 보존해야 할 handoff |
따라서 1차 개정의 중심은 **FL2 정상 경로 0회화**다. FL0+FL1 통합은 장기적으로 유효하지만, LLM 병목 제거보다 수정 범위가 크므로 1차 필수 개정에서 제외하고 재측정 후 조건부로 시행한다.
## 3. 두 보고서의 공통 판정
### 3.1 공통 비효율 판정
두 보고서는 다음 항목에 사실상 합의한다.
1. `ambiguous_legal_role`은 다중 role/module 개수만으로 생성되는 false exception이다.
2. `weak_derived_fact`의 글자 수 기준은 한국어 법률 사실표제에 부적절하다.
3. FL2가 42건을 판정했지만 최종 후보를 변경하지 않았다.
4. FL2는 예외 0건에도 실행되는 완전 직렬 병목이다.
5. `gemini-3.1-pro-preview/high`는 제한된 projection adjudication에 과대 사양이다.
6. 동일 exception pack이 candidate 파일, stdout, LLM prompt에 중복 물질화된다.
7. FL0 source pack은 전역 map과 BO별 payload를 중복 저장한다.
8. `client_goal_compact`, event map, 일부 structure index는 source pack 이후 소비되지 않는다.
9. FL1의 possession/notice/lien deterministic gate와 FL3 sole-writer 구조는 유지해야 한다.
10. `Fact_Ledger_base.json`의 27개 필드, 행 순서, Fact ID 규칙은 Stage 2 계약이므로 보존해야 한다.
11. LLM은 조건부 경량 task로 남겨 진짜 projection conflict만 처리해야 한다.
### 3.2 공통 권고 중 즉시 채택할 내용
- cardinality-only exception 폐지
- 문자열 길이 기반 weak-fact exception 폐지
- FL2를 조건부 wildcard adjudicator로 변경
- 정상 사건에서 wildcard 인스턴스 0개
- exception pack을 파일 또는 shard로 저장하고 stdout에는 전체 pack을 출력하지 않음
- FL2 입력을 유형별 최소 context로 축소
- 최종 writer의 닫힌 스키마·참조 검증 유지
- 7월 10일 fixture에 대한 골든 회귀
- Stage 2 공개 handoff 파일명과 최종 schema 불변
## 4. 차이점 비교와 채택 판정
### 4.1 비교표
| 쟁점 | Claude 보고서 | Codex 보고서 | 통합 판정 |
|---|---|---|---|
| FL0+FL1 | 즉시 통합, task 4→3 | 우선 유지·축소, 병목 잔존 시 통합 | **2차 조건부 채택** |
| FL2 실행 방식 | 경량 conditional adjudicator | 0-instance wildcard | **Codex 방식 채택** |
| FL2 모델 | flash-lite/low/max 1 | flash-lite/medium/max 2 | **medium/max 2 채택** |
| common prefix | Claude branch prefix 유지 주장 | Codex Part 1~3 prefix와 불일치 지적 | **현재 Codex prefix로 통일** |
| evidence excerpt | 30/30 비어 있음, key 보강 | 주로 pack·예외 구조 분석 | **Claude 발견 채택** |
| priority signal | `must_consider`·critical 50/50 포화 | upstream review 승계 결함 강조 | **둘 다 채택, 단계 분리** |
| upstream LES review | 상세 언급 약함 | deterministic 승계 필수 | **Codex 제안 P0 채택** |
| FL3 coverage | 현행 강점으로 평가 | subset 검사·extra ID 허용 결함 | **Codex exact gate 채택** |
| patch whitelist | 정책 유지 | 허용 밖 field도 warning 후 적용 결함 | **Codex hard reject 채택** |
| blocked status | 안전판 유지 | blocked인데 READY 가능 | **Codex fail-closed 채택** |
| Python SKILL | parser·exit·timestamp 결함 지적 | 주 분석 범위 아님 | **Claude 발견 채택** |
| `evidence_all` | 제거 | archive에 부재, 제거 또는 optional | **필수 의존 제거 채택** |
| 내부 파일 물리 삭제 | source pack 소멸 | downstream 확인 전 보류 | **1차 삭제 보류** |
### 4.2 FL0+FL1 즉시 통합을 보류하는 이유
통합은 최종 목표로 타당하다. source pack 602KB의 write/read와 MCP session 하나를 제거할 수 있기 때문이다. 그러나 즉시 통합하려면 다음을 동시에 바꿔야 한다.
- 두 Python 코드 블록과 helper namespace 병합
- source pack schema 또는 파일 폐기
- candidate bundle에 FL3 validation context 이관
- FL3 read contract 변경
- intermediate audit 및 재현 계약 변경
- downstream 또는 운영 도구의 중간 파일 소비 여부 확인
반면 FL1 exception 조건과 DAG만 고치면 7월 10일 fixture의 42개 LLM 판정을 모두 없앨 수 있다. 비용과 런타임의 가장 큰 원인을 훨씬 작은 변경으로 제거할 수 있으므로, 1차 개정에서는 FL0와 FL1의 task 경계를 유지한다.
다음 조건을 충족하지 못할 때만 2차로 통합한다.
- no-exception Part 4 p95 runtime 90초 이하
- source pack 330KB 이하
- deterministic MCP I/O가 전체 runtime의 40% 미만
### 4.3 FL2 모델 수준 판정
Claude의 `low/max_iterations 1`은 비용 면에서 더 작지만, 실제로 남길 true exception은 명시적 상충 근거를 비교하는 작업이다. 현재 Codex Part 1~3의 exception adjudicator가 사용하는 `flash-lite/medium/max_iterations 2`와 통일하는 편이 다음 이유에서 낫다.
- rare exception에 필요한 최소 비교 추론 확보
- JSON schema 오류 시 한 번의 복구 여지
- Stage 1 전체 model policy 통일
- 정상 경로에서는 task가 0개이므로 비용 차이가 사실상 없음
따라서 Part 4 FL2는 `gemini-3.1-flash-lite`, `reasoning: medium`, `max_iterations: 2`로 고정한다. Pro escalation은 두지 않는다. 해결 불가능한 항목은 `BLOCK_REVIEW`가 맞다.
### 4.4 common cache prefix 판정
현재 Codex Part 1~3의 LLM task는 다음 prefix를 공유한다.
- bytes: 3,385
- SHA-256: `6e01f72f1803767b6bb16b5aef6cf34760e6dc1b293c316c75e990d09ad5fe63`
Part 4 v2는 3,829B, SHA-256 `58f2b72d6c2650739c45d85cc57899150434db86a97bf19cd5a59d92d11dfbb5`를 사용한다. Claude 보고서의 canonical 판단은 Claude branch 기준이므로 현재 Codex branch에는 적용하지 않는다.
Part 4 개정본은 Part 1~3의 3,385B prefix를 바이트 단위로 복제해야 한다.
### 4.5 수치 오류 정정
Claude 보고서의 `Fact_Ledger_base.json` 175,126B 표기는 실제로 `BO.json`의 크기다. 7월 10일 최종 Fact Ledger의 실제 크기는 128,855B다.
또한 `42/50=84%`는 예외 건수를 Fact 수로 나눈 값이다. 예외와 연결된 Fact는 40행이므로 영향 행 비율은 80%다. 2개 Fact가 복수 예외를 가진다.
이 오류는 Claude 보고서의 주 결론에는 영향을 주지 않지만, 개정 후 정량 비교의 baseline은 위 정정값을 사용해야 한다.
## 5. 추가로 채택할 품질 개선
### 5.1 evidence excerpt 스키마 불일치
실제 source pack의 evidence authority 30건은 다음 상태였다.
- excerpt가 비어 있는 record: 30/30
- title 존재: 30/30
- priority 존재: 0/30
- authentication 존재: 0/30
FL0는 `excerpt`, `summary`, `content`, `text`, `body`만 찾지만 `evidence_indexed.json`은 주로 `key_facts`, `key_dates`, `key_amounts`를 제공한다. 그 결과 evidence score와 rare FL2 exception에 핵심 사실이 전달되지 않는다.
개정 시 다음 compact field를 결정적으로 생성한다.
```json
{
"evidence_index": "E-001",
"title": "string",
"key_facts": [],
"key_dates": [],
"key_amounts": [],
"doc_type": "string",
"source_pointer": {},
"authentication": null
}
```
긴 raw text는 source pack에 넣지 않는다. exception별로 필요한 `key_facts`만 상한을 두고 전달한다.
### 5.2 priority signal 포화
최종 50행은 전부 다음 값을 가진다.
- `must_consider: true`
- `legal_centrality: critical`
`must_consider`는 non-drop 안전장치일 수 있으므로 1차 개정에서 false로 낮추지 않는다. 대신 다음처럼 처리한다.
1. upstream review·blocking 여부를 별도 code와 writer report에 명시한다.
2. `legal_centrality` 산정 근거를 결정적 code로 기록한다.
3. Stage 2 소비 검증 후 enum 값의 변별 기준을 조정한다.
즉, 포화 문제는 인정하지만 보존 안전성보다 앞세워 즉시 값을 낮추지는 않는다.
### 5.3 Part 3 review 승계
Part 4는 Part 3의 다음 정보를 LLM 없이 승계해야 한다.
- root `READY_WITH_REVIEW`
- `structure.review_required`
- `quality_gate.review_queue[]`
- `source_bo_ids`
- `review_code`
- `downstream_owner`
- blocked exception 정보
관련 Fact에는 최소 다음을 적용한다.
- `LES_REVIEW_REQUIRED` 또는 구체적 review code
- `must_consider: true`
- writer report의 affected Fact/BO 목록
- blocking review가 있으면 final writer status `READY_WITH_REVIEW`
- 필요한 경우 `BLOCK_FINAL_DRAFTING`
Part 4 FL2는 LES 법리나 structure type을 재판정하지 않는다.
### 5.4 Python SKILL 및 결정성
Claude 보고서의 다음 지적은 채택한다.
1. FL0·FL1·FL3의 실패 경로에서 `sys.exit(0)`을 제거한다.
2. 실패는 non-zero exit 또는 exception으로 agent에 전달한다.
3. `read_docs` outer/inner JSON 모두 `json.loads` 후 `raw_decode` fallback을 사용한다.
4. LLM output parser는 raw JSON, text envelope, code fence를 처리한다.
5. intermediate semantic artifact에서 불필요한 `created_at_utc`를 제거한다.
6. 시간정보가 필요한 operational report는 semantic equality 검사에서 분리한다.
7. `run_fingerprint`로 동일 입력 여부를 검증한다.
8. `{{__user_hash__}}`, `{{__workspace_hash__}}` 전달을 유지한다.
## 6. 최종 선별 전략
### 6.1 1차 필수 개정 P0
가장 작은 변경으로 가장 큰 효과를 내는 작업이다.
1. FL1의 `ambiguous_legal_role` cardinality trigger를 삭제한다.
2. `ambiguous_claim_chain`도 배열 cardinality만으로 예외화하지 않는다.
3. `weak_derived_fact`의 문자 수 trigger를 삭제한다.
4. 빈 `derived_fact`는 deterministic template로 보충한다.
5. FL2를 `Task_FL2_fact_exception_adjudicator_*` wildcard로 변경한다.
6. FL1이 true exception 0건이면 `dynamic_fanout: []`를 출력한다.
7. FL3가 FL1과 `all Task_FL2_*`를 기다리도록 DAG를 바꾼다.
8. FL2 모델을 flash-lite/medium/max 2로 변경한다.
9. current Codex common prefix를 바이트 동일하게 적용한다.
10. FL3 exact coverage, patch whitelist, blocked-status gate를 강화한다.
11. Part 3 review queue를 Fact와 writer report에 deterministic하게 승계한다.
12. failure exit와 JSON parser를 SKILL에 맞게 수정한다.
### 6.2 같은 릴리스의 P1
P0 이후에도 변경 위험이 낮고 효과가 큰 작업이다.
1. exception pack을 candidate bundle과 분리한다.
2. stdout은 전체 pack 대신 `dynamic_fanout` manifest만 출력한다.
3. exception을 유형별 shard로 저장한다.
4. shard당 최대 4건, dynamic payload 25KB 이하를 강제한다.
5. `evidence_all.json` 필수 의존을 제거한다.
6. `client_goal.json`과 `evidence_event_candidates.json`을 Part 4 입력에서 제거한다.
7. 단, 이 파일들 자체는 Stage 1 handoff에서 삭제하지 않는다.
8. evidence compact를 실제 `key_facts/key_dates/key_amounts`에 맞춘다.
9. source pack의 전역 map/BO별 사본 중 하나만 유지한다.
10. FL0에서 다섯 structure index를 검증하되 source pack에는 `by_bo_id`와 필요한 ID set만 기록한다.
### 6.3 재측정 후 조건부 P2
다음은 1차 성능검증 후에만 시행한다.
1. FL0와 FL1을 단일 deterministic compiler로 통합한다.
2. `fact_source_pack.json` 생성을 debug mode로 제한한다.
3. candidate bundle에 FL3용 최소 validation context를 내장한다.
4. FL3의 대형 source pack 재읽기를 제거한다.
5. `legal_centrality` 값의 변별 기준을 변경한다.
6. internal projection 파일의 물리적 삭제 여부를 Stage 2 consumer audit 후 결정한다.
## 7. 개정 DAG
### 7.1 1차 권고 DAG
```text
IN
|
v
FL0 slim source compiler [Python]
|
v
FL1 candidate + exception planner [Python]
| \
| \ true exception shard 1..N
| v
| FL2 exception adjudicator_* [LLM, 0..N]
| |
+----+
v
FL3 exact final gate + sole writer [Python]
|
v
OUT
```
정상 경로는 다음과 같다.
```text
FL0 -> FL1(dynamic_fanout=[]) -> FL3
```
진짜 예외가 있을 때만 다음 경로가 열린다.
```text
FL0 -> FL1 -> FL2_0 ... FL2_N -> FL3
```
### 7.2 task procedure 계약
```text
FL0.nexts = [FL1]
FL1.nexts = [FL2_*, FL3]
FL2_*.nexts = [FL3]
FL3.wait_until = [FL1, all FL2_*]
```
FL1 stdout root는 `dynamic_fanout`을 포함해야 한다. 각 item은 full exception이 아니라 shard path, shard ID, expected exception IDs, run fingerprint만 포함한다.
## 8. 작업별 개정 계약
### 8.1 FL0
**유지할 역할**
- upstream schema/status 검증
- BO·structure·evidence reference 검증
- `structure_index.by_bo_id` 검증
- compact source map 작성
- Part 3 review-by-BO 작성
**삭제·축소할 내용**
- `client_goal_compact`
- 사용되지 않는 event map 두 벌
- BO·signal·evidence의 global/per-BO 이중 저장
- 검증 후 소비되지 않는 네 structure index의 재직렬화
- `evidence_all.json` 필수 read
**주의사항**
`evidence_event_candidates.json`을 Part 4가 읽지 않더라도 Part 1 결과물과 Stage 1 handoff에서는 유지한다. Part 4의 입력 축소와 전역 산출물 삭제는 다른 문제다.
### 8.2 FL1
FL1은 문제를 세 경로로 나눈다.
| 경로 | 조건 | 처리 |
|---|---|---|
| deterministic pass | 정상 복수값, unique projection | 그대로 보존 |
| deterministic review | source 누락, legal theory 필요, upstream review | code·gate로 전달 |
| true LLM exception | 동일 scalar projection에 source-backed 후보 2개 이상이 실제 충돌 | FL2 shard |
true exception은 다음 네 조건을 모두 만족해야 한다.
1. 하나의 Stage 1 output field를 선택해야 한다.
2. 명시적 source-backed 후보가 둘 이상이다.
3. 배열 보존이나 downstream defer로 해결할 수 없다.
4. compact context만으로 안전하게 비교할 수 있다.
하나라도 불충족하면 LLM에 보내지 않는다.
### 8.3 FL2
**설정**
- provider: `google`
- model: `gemini-3.1-flash-lite`
- reasoning: `medium`
- max_iterations: `2`
- tools: none
- common prefix: current Codex canonical prefix
- prompt input: 해당 shard만
**허용 decision**
- `KEEP_AS_IS`
- `PATCH`
- `BLOCK_REVIEW`
현재 FL3가 autosplit하지 않으므로 `SPLIT_FACT`는 제거한다.
**금지 사항**
- Part 3 structure/type 재판정
- raw evidence 탐색
- 새 Fact·BO·evidence·structure ID 생성
- legal theory 확정
- allowed field 밖 patch
### 8.4 FL3
다음 hard gate를 모두 구현한다.
1. `expected_exception_ids == decision_ids ∪ blocked_ids`
2. `decision_ids ∩ blocked_ids == ∅`
3. duplicate·extra·missing exception ID 0건
4. decision의 fact ID, BO ID, exception type이 원본과 일치
5. `patch.keys ⊆ allowed_output_fields ∩ FINAL_FIELD_SET`
6. 허용 밖 patch는 warning 후 적용하지 않고 hard reject
7. expected BO ID set과 final source BO ID set 보존
8. Fact ID uniqueness와 deterministic ordering
9. evidence/structure ref가 authoritative set의 부분집합
10. FL2 `FAILED`면 final overwrite 금지
11. unresolved blocked review가 있으면 `READY` 금지
12. Part 3 blocked review를 writer report와 drafting gate에 승계
status는 다음과 같이 고정한다.
| 조건 | status | final write |
|---|---|---|
| 모든 gate 통과, block 없음 | `READY` | 허용 |
| sealed ledger는 가능하나 review/block 존재 | `READY_WITH_REVIEW` | 허용 + drafting gate |
| schema·coverage·conservation 위반 | `FAILED` | overwrite 금지 |
## 9. 삭제·축소 안전성
### 9.1 즉시 안전
- false exception trigger 삭제
- FL2의 정상 경로 0회화
- exception pack stdout 제거
- source pack 내부 중복 필드 제거
- Part 4의 `client_goal` read 제거
- Part 4의 event-candidate read 제거
- `evidence_all` 필수 의존 제거
- Pro 모델 제거
- `SPLIT_FACT` enum 제거
이 작업은 최종 Stage 2 handoff 파일을 삭제하지 않고 Part 4 내부 read·intermediate 계약만 축소한다.
### 9.2 반드시 유지
- `Fact_Ledger_base.json`
- FINAL_FIELDS 27종과 닫힌 schema
- `source_bo_id`, evidence ref, linked structure ref
- Fact ordering과 `F-###` 규칙
- possession/legal-cause conflict gate
- notice receipt drafting gate
- lien extinction notice review gate
- Part 3 `structure_index.by_bo_id` 검증
- final sole-writer 원칙
### 9.3 downstream 확인 전 보류
- `fact_source_pack.json` 파일 자체 삭제
- `Fact_Ledger_base_candidate.json` 파일 자체 삭제
- writer report 삭제 또는 이름 변경
- `must_consider` true를 false로 낮추는 의미 변경
- `legal_centrality` enum 값 재분류
- Stage 1의 `client_goal.json`, `evidence_event_candidates.json` 산출 중단
- 최종 Fact Ledger 필드 추가·삭제
두 보고서는 최종 Fact Ledger의 Stage 2 소비를 확인했지만, 모든 Stage 2·감사 도구의 internal projection 파일 소비 지도를 완결하지는 않았다. 따라서 물리 파일 삭제는 별도 consumer audit 후 결정한다.
## 10. 구현 순서
### 단계 A: 비용 병목 제거
1. FL1 exception trigger 수정
2. FL2 wildcard DAG 적용
3. flash-lite/medium과 common prefix 적용
4. no-exception direct path 구현
### 단계 B: 안전성 강화
1. FL3 exact coverage
2. patch hard whitelist
3. blocked/failed status 규칙
4. upstream LES review 승계
5. BO/evidence/structure conservation gate
### 단계 C: 입력·토큰 축소
1. exception pack 별도 파일·shard
2. stdout manifest화
3. evidence compact key 수정
4. FL0 dead field·중복 제거
5. 불필요한 Part 4 input read 제거
### 단계 D: Python 계약 정비
1. non-zero failure
2. outer/inner raw-decode fallback
3. code-fence tolerant result parser
4. semantic timestamp 제거와 run fingerprint
5. SKILL checklist 검증
### 단계 E: 재측정
P0·P1 적용 후 runtime profile을 수집한다. no-exception p95가 90초를 넘을 때만 FL0+FL1 통합을 시행한다.
## 11. 검증 계획
### 11.1 정적 검증
- YAML parse 성공
- 모든 task_procedure 노드가 실제 task 또는 wildcard와 일치
- wildcard parent stdout에 `dynamic_fanout` 존재
- Python code compile 성공
- 모든 code-executor가 user/workspace hash 전달
- 모든 Python read parser가 raw-decode fallback 보유
- 모든 LLM task의 common prefix hash 동일
- FL2 모델·reasoning·iterations 일치
- 최종 writer 1개만 `Fact_Ledger_base.json` 작성
### 11.2 7월 10일 골든 회귀
기대 결과는 다음과 같다.
- candidate Fact 50행 보존
- `ambiguous_legal_role` false exception 40건 제거
- `weak_derived_fact` false exception 2건 제거
- true FL2 shard 0개
- LLM 호출 0회
- 최종 Fact 50행 의미 동등
- BO ID·evidence ref·structure ref 보존
- existing notice weak review 2건 보존
- Part 3 review 승계는 기존보다 강화
### 11.3 주입 fixture
1. multi-role non-conflict: 배열 보존, FL2 미실행
2. true scalar projection conflict: shard 생성, FL2 실행
3. empty derived fact: deterministic fallback 또는 review
4. missing calculation basis: hallucination 없이 review
5. upstream blocked LES review: `READY_WITH_REVIEW`
6. extra decision ID: FL3 failure
7. duplicate decision ID: FL3 failure
8. out-of-scope patch: 미적용 + failure/block
9. missing BO: conservation failure
10. unknown evidence/structure ref: failure
11. code-fenced LLM JSON: parser 성공
12. malformed LLM JSON: retry 후 fail-closed
13. notice receipt missing: drafting block
14. possession/legal-cause conflict: hard warning
### 11.4 정량 합격 기준
| 지표 | baseline | 합격 기준 |
|---|---:|---:|
| 7월 10일 false exception | 42 | 0 |
| 정상 경로 FL2 task | 1 | 0 |
| 정상 경로 LLM 비용 | $0.58 포함 | $0 |
| source pack | 602,059B | 330KB 이하 |
| candidate bundle | 418,076B | 200KB 이하 |
| FL1 stdout | 약 156,444B | 1KB 이하 권고 |
| Part 4 common prefix 종류 | current Codex와 불일치 | Stage 1 전체 1종 |
| Part 4 runtime | 3분 6초 | no-exception p95 90초 이하 |
| out-of-scope patch 적용 | 가능 | 0 |
| final Fact count | 50 | 50 |
## 12. 최종 권고
Part 4의 최적 개정은 전면 통합이 아니라 **가짜 예외 제거 → FL2 wildcard 0회 경로 → FL3 fail-closed 강화 → source pack 축소** 순서다.
두 보고서가 공통으로 증명한 가장 중요한 사실은 고사양 LLM이 42건을 판정하고도 최종 Fact를 바꾸지 않았다는 점이다. 따라서 먼저 이 호출을 없애야 한다. 동시에 Codex 보고서가 확인한 FL3 경계 결함과 Part 3 review 승계 누락을 고쳐야 비용 절감이 품질 저하로 이어지지 않는다. Claude 보고서의 evidence-key mismatch와 Python SKILL 결함은 같은 릴리스에서 함께 교정한다.
FL0+FL1 통합은 좋은 2차 최적화지만 1차 필수 작업은 아니다. P0·P1만으로도 정상 사건의 Part 4 LLM 비용을 0으로 만들고, 토큰·중간 파일 크기를 크게 줄이며, 현재보다 강한 법률·데이터 안전 게이트를 확보할 수 있다.
@@ -0,0 +1,207 @@
# Stage 1 Part 4 개정 작업 명세서 (Claude v1)
- 개정 대상: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml` (2,027행, task 4개)
- 산출물: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_Claude_v3.yml` (신규 파일 — v2 원본은 수정·이동·삭제 금지)
- 근거 문서: `Part_4_Improvement_Claude_v1.md` (채택 전략 X-1~X-10, 기각 N-1~N-5, 후속 D-1~D-3)
- 작성 관점: 20년 이상 경력의 대한민국 최고 수준 변호사 + 세계적 수준의 AI 아키텍트. 본 명세서는 LLM이 읽고 추가 판단 없이 100% 수행할 수 있도록 작성되었다. 명세에 없는 "개선"의 임의 추가는 금지한다(§12-10).
---
## 0. 개정 목표와 원칙
1. **골격 전환**: `FL0→FL1→FL2(상시 pro-preview LLM)→FL3` 4-task 직렬 체인을 `F0(결정론 reducer)→F1(조건부 flash-lite adjudicator)→F2(결정론 gate/writer)` 3-task로 재편한다. Part 1 v3(GA→GB→GC)·Part 2 v3(R0→R1→F0)·Part 3 v2(L0→L1→L2)와 동일 문법이며, 이로써 Stage 1 전체가 단일 문법으로 통일된다.
2. **예외의 상류 소거**: cardinality 기반 가짜 예외(role/module 복수 = 정상 다중 라우팅, X-1)와 문자열 길이 기반 예외(X-2)를 폐지하고, true exception은 4중 조건(X-3)을 통과하는 항목으로 한정한다. 7/10 fixture 기준 LLM 호출 실질 0회가 목표이며, 무손실성은 "42건 전량 KEEP_AS_IS 대조 실험 = 최종 50행 완전 동일"이라는 이중 실증(Claude 대조 실험 + Codex 전후 비교)으로 보증되어 있다.
3. **전송의 구조 소거**: `fact_source_pack.json` 602KB(내부 중복·사장 필드 포함)를 물질화하지 않고, 예외 pack의 3중 이동(candidate 내장 + stdout 재출력 + 프롬프트 주입)을 단독 파일 + preflight 1회로 단일화한다.
4. **봉인 강화(품질 개선)**: F2에 exact coverage 등식, 경계 위반 patch의 hard reject(경고 후 적용 금지), status 3단 규칙을 도입하고, Part 3의 실질 review 상태를 결정론으로 승계한다(X-6·X-7).
5. **근거 실질화**: 증거 발췌 수집 키를 `evidence_indexed.json`의 실제 필드로 교정한다(X-8 — 현행은 30/30 빈 발췌).
6. **불변 계약 준수**: `Fact_Ledger_base.json`(FINAL_FIELDS 27종 닫힌 스키마, `F-###` 연속 규칙, 최상위 배열 형식)과 writer report 파일은 Stage 2 소비 계약으로 변경 금지(additive 확장만 허용).
7. **SKILL.md 100% 준수** + **프리픽스(N-1 판정)**: F1의 `COMMON_CACHE_PREFIX_STAGE_1`은 **현행 FL2 블록을 바이트 그대로 유지**한다. 이 블록(3,829B, sha256 앞 12자리 `58f2b72d6c26`)은 Part 2 Claude v3 R1·Part 3 Claude v2 L1과 바이트 동일함이 실측되어 있다. 들여쓰기 제거·재정렬 금지. (Part 1 GB의 정렬은 D-2 — 본 개정 범위 밖.)
---
## 1. 불변 계약 (변경 금지 목록)
1. **최종 파일** `Fact_Ledger_base.json`: 최상위 배열, 행당 FINAL_FIELDS 27종(fact_id, source_bo_id, type, date, parties, object_spec, amount, action, evidence_refs, credibility, legal_centrality, proof_strength, legal_effect_roles, claim_chain_ref, linked_structures, must_not_drop_in_claim_types, must_consider, state_context, money_claim_effect, commercial_successor_effect, actio_roles, linked_actio_structures, downstream_module_candidates, skeleton_validation_codes, derived_fact, derivation_basis, legal_calculation_object) 전 필드 존재 + 임의 필드 금지, `F-###` 연속·유일, 행 순서는 source_bo_id 정렬 기반의 현행 결정론 순서. enum(credibility/legal_centrality/proof_strength) 유지. **키 삭제·이름 변경·타입 변경 금지.** 변별 정보 보강은 `skeleton_validation_codes` 값 추가로만(additive, X-10).
2. **writer report** `stage1_tmp/fact_ledger/fact_ledger_writer_report.json`: 파일명·기존 필드 유지, 신규 필드(status, LES 승계 기록)는 additive.
3. **결정론 게이트 3종 보존**: `_possession_conflict_scan`·`_notice_receipt_gate_scan`·`_lien_extinction_notice_scan`과 그 review code 6종(POSSESSION_CAUSE_CONFLICT, LEGAL_CAUSE_STATE_UNKNOWN_REVIEW, NOTICE_RECEIPT_UNVERIFIED, NOTICE_RECEIPT_EVIDENCE_WEAK_REVIEW, LIEN_ASSERTED_AFTER_EXTINCTION_NOTICE_REVIEW, BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING)은 자구 수준 이식(경량화 금지).
4. **ID 규칙**: BO ID·evidence index·structure/cluster ID·claim/liability group id renumber·창작 금지. `F-###`은 F2가 현행 규칙(정렬 순서 연속 부여)으로 부여.
5. **LLM 판정 계약**: 후보 밖 값 금지, 불충분 시 BLOCK_REVIEW, "LES2 모호성 재판정 금지" 경계(v2 FL2의 PROHIBITED_EXCEPTION_INTERPRETATION 취지) 유지.
6. Part 1/2/3 YAML은 수정하지 않는다.
---
## 2. 현행 구조 매핑 (개정 대상 앵커)
| 현행 task (v2 시작 행) | 처분 |
|---|---|
| `Task_FL0_fact_source_pack_compiler` (53행) | **F0로 흡수** — 컴파일 함수군 이식(발췌 키 교정), pack 물질화 폐지 |
| `Task_FL1_deterministic_fact_ledger_candidate_builder` (617행) | **F0로 흡수** — row builder·게이트 3종 이식 + X-1/X-2/X-3/X-7 개정 |
| `Task_FL2_single_fact_exception_adjudicator` (1333행) | **F1로 대체** — 조건부·pack 파일 preflight·flash-lite/low. 프리픽스 블록(1347~1389행)은 바이트 유지 |
| `Task_FL3_final_fact_ledger_gate_and_writer` (1563행) | **F2로 개정** — X-6 봉인 강화, 채널 정리 |
| `task_procedure` (21행) | **전면 교체** (§9) |
**코드 이식 원칙**: 흡수 로직은 함수 단위 이식이다. FL0의 `_bo_items`·`_bo_id`·`_compact_bo`·`_validate_legal_effect_structures`·`_compact_structure`·`_build_evidence_authority`(**발췌 키 교정판** — §5-2)·`_build_signal_hints_by_bo_id`·`_compact_signal`·`_collect_bo_refs`·`_linked_by_bo`, FL1의 `_score_evidence`·`_legal_roles`·`_modules`·`_linked_structures`·`_parties`·`_derived_fact`·`_basis`·`_claim_chain_ref`·`_legal_calculation_object`·`_build_row`·`_possession_conflict_scan`·`_notice_receipt_gate_scan`·`_lien_extinction_notice_scan`·`_validate_candidate_bundle`(개정 스키마 반영), FL3의 `_apply_patch`(X-6 개정)·`_exception_allowed_fields`·`_validate_adjudication_coverage`(X-6 개정)·`_linked_ids_from_source`(입력원 변경)·`_validate_refs`·`_normalize_final_row`·게이트/report 조립부를 각각 F0/F2로 옮기고, 중복 MCP 보일러플레이트는 1벌로 줄인다. 개정 지점은 본 명세서가 명시한 곳으로 한정한다.
---
## 3. STEP 0 — 사전 검증 (v3 작성 전 필수)
1. **STEP 0-1**: v2에서 §2의 앵커 4개 + `task_procedure`(21행) 존재 확인. 불일치 시 중단·보고.
2. **STEP 0-2**: fixture(`Results_July_10_3_15pm`)에 F0 입력 6종(`BO.json`, `legal_effect_structures.json`, `actio_case_signals.json`, `case_liability_signals.json`, `legal_effect_signals.json`, `evidence_indexed.json`)과 골든 산출물(`Fact_Ledger_base.json`, sha256 앞 12자리 `b589ff166a7d`, 50행) 및 중간 실행물(`fact_source_pack.json` 602,059B / `Fact_Ledger_base_candidate.json` 418,076B / `fact_ledger_writer_report.json` 452B)이 존재함을 확인한다(§10 회귀에 사용).
3. **STEP 0-3**: F1 프리픽스 canonical을 v2의 1347~1389행 블록에서 바이트 추출하고, Part 2 Claude v3 R1·Part 3 Claude v2 L1 블록과 바이트 동일(3,829B, `58f2b72d6c26`)함을 확인한다. 불일치 시 중단·보고.
4. **STEP 0-4**: preflight 파일 채널(Plan A)은 Part 2/3 개정과 공유되는 배포 전제조건이다. 기확인 상태면 재검 불요. **Plan B**: 실패 시 F1은 `preflight: false`로 두고 F0 stdout에 exception pack 요약을 포함시켜 `{{prev.Task_F0_fact_ledger_reducer.json_output}}` 템플릿으로 주입한다(예외 0이면 요약 수십 바이트).
---
## 4. 신규 데이터 계약 (파일 5종)
| 파일 | writer | 소비자 | 핵심 스키마 |
|---|---|---|---|
| `stage1_tmp/fact_ledger/Fact_Ledger_base_candidate.json` | F0 | F2 | `{fact_ledger_candidate_bundle: {schema_version: "stage1_fact_ledger_candidate_bundle.v2", status, candidate_items[](FINAL_FIELDS 27종 완전형), ref_manifest: {bo_ids[], structure_ids[], evidence_ids[]}, les_review_inheritance: {by_fact_id: {…review codes/원천}}, exception_pack_ref: {path, sha256, expected_exception_ids[]}, compile_gate}}` — **v2의 exception_pack 내장·created_at_utc는 수록 금지**. `ref_manifest`는 F2 참조 검증용(602KB pack 재읽기 대체) |
| `stage1_tmp/fact_ledger/fact_exception_pack.json` | F0 | F1 (preflight) | `{schema_version: "stage1_fact_ledger_exception_pack.v2", has_exceptions, exception_count, exceptions[], budget}` — 항목: `{exception_id "FX-###", exception_type, fact_id, source_bo_id, severity, trigger_reason, candidate_fact_row_subset, compact_context(유형별 최소 — §5-6), allowed_output_fields, allowed_decisions, conflict_flags}`. **X-3 4중 조건 통과 항목만, 항목당 ≤2KB** |
| `stage1_tmp/fact_ledger/fact_adjudication.json` | F1 | F2 | `{fact_exception_adjudication: {…}}` — v2 FL2 OUTPUT_CONTRACT 이식하되 decision enum은 `PATCH|KEEP_AS_IS|BLOCK_REVIEW`(**SPLIT_FACT 삭제** — X-5), schema_version `stage1_fact_exception_adjudication.v1` 유지 |
| `Fact_Ledger_base.json` | F2 (유일 writer) | Stage 2 | **§1-1 불변** |
| `stage1_tmp/fact_ledger/fact_ledger_writer_report.json` | F2 | Stage 2/감사 | 기존 필드 + additive: `status`(§7-5 3단 규칙), `les_review_inheritance[]`, `deterministic_review_items[]`. **created_at_utc 제거**(2-run 결정론 — X-9) |
폐지: `stage1_tmp/fact_ledger/fact_source_pack.json`은 쓰지 않는다.
stdout 규약(SKILL §3.3): F0/F2는 단일 JSON 라인만 출력한다(경로·sha·count·status·has_exceptions). pack·bundle 내용을 stdout에 넣지 않는다(v2 FL1의 147KB 예외팩 stdout 재출력 폐지).
---
## 5. STEP 1 — F0 명세 (`Task_F0_fact_ledger_reducer`)
code-executor(language python, requirements httpx, network agent-network, timeout 180). MCP 보일러플레이트는 v2 FL1(약 700~790행)을 1벌 이식하고 `clientInfo.name`을 `"stage-1-fact-ledger-f0-reducer"`로 변경. **envelope 계층에도 raw_decode fallback 적용**(v2는 inner에만 존재 — X-9).
1. **입력 read 6종**: §3-2의 6파일. **`evidence_all.json`·`evidence_event_candidates.json`·`client_goal.json`은 읽지 않는다**(기여 0/소비 0 실측 — X-4). stdout manifest에 `"removed_inputs": ["evidence_all.json", "evidence_event_candidates.json", "client_goal.json"]`을 1회 기록한다(재현성 고지). `_validate_legal_effect_structures`의 스키마·인덱스·참조 검증은 전량 이식 유지한다(검증은 메모리에서 수행하고 pack에 재직렬화하지 않는다).
2. **X-8 발췌 실질화**: `_build_evidence_authority`를 개정한다 — excerpt 수집을 `record.get("key_facts")`(리스트 → " / " 결합) 우선, 보조로 `key_dates`·`key_amounts` 결합 요약을 사용하고 기존 키(`excerpt/summary/content/text/body`)는 fallback으로 유지한다. `_score_evidence`는 무변경 이식(입력 텍스트가 실질화되므로 판정 근거가 회복된다).
3. **후보 50행 생성**: FL1의 `_build_row`와 스캔 게이트 3종을 이식하되, 입력을 pack 파일이 아니라 메모리 구조(§5-1에서 구축한 bo_by_id·structure_by_id·structure_index.by_bo_id·signal_hints·evidence_authority)로 직접 연결한다. `bo_fact_inputs` 중간 표현은 메모리 내에서만 구성하며 어떤 채널에도 물질화하지 않는다.
4. **X-1/X-2 예외 생성 교정**: `_exceptions_for_row`에서 (a) `ambiguous_legal_role`(roles>2 & modules>1)과 `ambiguous_claim_chain`(그룹 합>2) trigger를 **삭제**한다 — 복수 role/module/그룹은 배열형 최종 스키마에 그대로 보존되는 정상 상태다. (b) `weak_derived_fact`의 길이(<12자) trigger를 삭제한다 — `derived_fact`가 빈 경우는 현행 결정적 재작성(`_derived_fact`)이 이미 처리하며, 재작성 후에도 비면 LLM행이 아니라 `EMPTY_DERIVED_FACT` review code로 남긴다(현행 코드 유지).
5. **X-3 잔여 유형의 4중 조건 한정**: `legal_calculation_required`·`unresolved_asset_cluster_projection`·`unresolved_structure_role_projection`은 ① F2가 진행하려면 단일 값 선택 필수 ② **source-backed 상충 후보 2개 이상이 compact 레코드에 실재** ③ 보존·defer 불가 ④ compact로 판정 충분 — 을 전부 충족할 때만 pack에 수록한다. 단순 누락(amount 부재 등)은 후보 2개가 없으므로 ② 불충족 → `CALCULATION_BASIS_INCOMPLETE_REVIEW` 등 deterministic review code로 전환한다. legal_theory 계열 표지는 무조건 LLM 금지·Stage 2 회부.
6. **예외 항목 compact 계약**: 유형별 최소 context만 수록(전 유형 공통의 비대 envelope 폐지 — v2의 related_bo_compact 전체·structure 8종·signal 전체·excerpt 8종 내장 금지). 항목당 직렬화 ≤2,000자. 방어 상한(30건 또는 40KB) 초과분은 자동 차단이 아니라 exception_id를 유지한 채 deterministic review로 라우팅하고 audit 추적 항목으로 남긴다.
7. **X-7 LES review 결정론 승계**: `legal_effect_structures.json`에서 (a) 구조별 `review_required=true`, (b) `pending_exception_state.blocked` 비공백(Part 3 v2 additive 필드 — 부재 시 무시), (c) `quality_gate.review_queue`의 실질 항목을 수집하여, 관련 fact 행에 `LES_REVIEW_REQUIRED`(또는 더 구체적 코드) 부여 + `must_consider=true` + candidate bundle의 `les_review_inheritance`에 {fact_id, source_bo_id, 원천 항목} 기록. LLM에 보내지 않는다.
8. **출력**: §4의 slim candidate bundle·exception pack 파일 write(+pack sha를 bundle의 `exception_pack_ref`에 기록) + stdout 1줄: `{"status","message","candidate_path","exception_pack_path","fact_count","has_exceptions","exception_count","deterministic_review_count","les_inheritance_count","removed_inputs"}`.
9. **FAILURE_POLICY**: 입력 누락·파싱 불가 시 파일 미작성, FAILED 단일 JSON 라인 출력 후 **raise**(`sys.exit(0)` 금지). `datetime` 사용 금지(타임스탬프 필드 자체를 산출물에서 제거 — X-9).
---
## 6. STEP 2 — F1 명세 (`Task_F1_fact_exception_adjudicator`)
LLM task 엔트리:
```yaml
- task_name: Task_F1_fact_exception_adjudicator
llm_provider: google
llm_model: gemini-3.1-flash-lite
llm_reasoning: low
llm_verbosity: low
max_iterations: 1
use_tools: [localdocs]
cache_control: {mode: auto, ttl: 20m}
preflight: true
preflight_files:
- stage1_tmp/fact_ledger/fact_exception_pack.json
```
프롬프트 구성: STEP 0-3에서 추출한 canonical `COMMON_CACHE_PREFIX_STAGE_1`(3,829B **바이트 그대로**) + 신규 STATIC_BLOCK(Part 3 v2 L1 골격):
1. MISSION: "결정론 reducer(F0)가 non-deferrable로 판정한 compact 투영 예외만 판정한다. 파일 병합·최종 파일 작성·사실 창작·LES 모호성 재판정 금지."
2. EXECUTION: ① preflight pack의 `has_exceptions` 확인 ② **false이면 no-exception 판정 객체**(`{"fact_exception_adjudication": {"schema_version": "stage1_fact_exception_adjudication.v1", "status": "READY_NO_EXCEPTIONS", "decisions": [], "blocked_review_items": [], "adjudication_gate": {...}}}`)를 `write_file(overwrite=true)`로 `stage1_tmp/fact_ledger/fact_adjudication.json`에 저장하고 `"NO_EXCEPTIONS"`만 출력 후 즉시 종료(terminate) ③ true이면 각 항목을 compact_context만으로 판정(추가 read 금지) ④ 판정 규칙·필드 규칙은 v2 FL2의 DECISION_RULES·OUTPUT_CONTRACT(1471~1561행)를 이식하되 decision enum은 `PATCH|KEEP_AS_IS|BLOCK_REVIEW`로 축소(X-5), **"필요 필드가 allowed 밖이어도 포함 가능" 완화 조항(v2 1477행)은 삭제** — patch는 `allowed_output_fields` 안에서만(F2가 hard reject하므로 계약 일치) ⑤ 결과 write ⑥ `"F1 예외 판정 완료 (decisions=<건수>)"`만 출력 후 종료.
3. ABSOLUTE_FORBIDDEN·PROHIBITED_EXCEPTION_INTERPRETATION: v2 FL2의 해당 블록(LES 재판정 금지, 원본 파일 read 금지, ID·사실 창작 금지, 파일 작성은 판정 파일 1개만, markdown fence 금지)을 이식.
4. FAILURE_POLICY: pack 부재·파싱 불가 시 판정 파일 미작성, `FAILED: <사유>`만 출력. tool 오류 1회만 재시도.
Plan B(STEP 0-4 실패 시): `preflight: false` + `<F0_EXCEPTION_PACK>{{prev.Task_F0_fact_ledger_reducer.json_output}}</F0_EXCEPTION_PACK>` 주입(§3-4).
---
## 7. STEP 3 — F2 명세 (`Task_F2_final_fact_ledger_gate_and_writer`)
code-executor(timeout 180). v2 FL3(1563~2027행) 이식 + 다음 개정:
1. **채널 정리**: `ADJUDICATION_RAW` 템플릿 주입 제거 → 파일 read 2종(candidate bundle + adjudication 파일; adjudication 파싱에 §6.7 관용 파서 — 코드펜스 salvage 후 strict 검증). exception pack은 bundle의 `exception_pack_ref.sha256` 대조 후 파일 read. **`fact_source_pack.json` 재읽기 폐지** — 참조 검증 ID 집합은 bundle의 `ref_manifest`에서 취한다(`_linked_ids_from_source` 대체).
2. **X-6① exact coverage 등식**: `_validate_adjudication_coverage`를 강화한다 — `expected_exception_ids == decided ∪ blocked`(등식), `decided ∩ blocked == ∅`, 중복 decision·미지 ID·예외 0건에서의 임의 decision hard fail, `adjudication_gate.input_exception_count`·decision_count와 실제 배열 길이 정합 검사, decision의 fact_id/source_bo_id/exception_type이 원 예외와 일치하는지 검사.
3. **X-6② patch hard reject**: `_apply_patch`를 개정한다 — patch key가 `allowed_output_fields ∩ FINAL_FIELD_SET` 밖이면 **해당 decision 전체를 거부**하고 그 fact를 BLOCK 처리(`BLOCK_REVIEW_PRESENT` code + must_consider=true + report 기재). **warning 후 적용(v2 1835~1842행) 금지.** `SPLIT_FACT` 분기는 enum 삭제에 따라 미지 decision으로 처리(hard fail).
4. **적용·검증·게이트**: KEEP_AS_IS/BLOCK/PATCH 적용, `_normalize_final_row`·`_validate_refs`(ref_manifest 기준)·닫힌 스키마 검증·게이트 3종·`gate_review_code_summary`는 이식 유지. X-7 승계 항목을 report의 `les_review_inheritance`로 기재.
5. **X-6③ status 3단 규칙**: stdout·report status를 — 게이트 전부 통과 + blocked 0 + 승계 review 0 → `READY` / blocked 또는 deterministic·LES review 존재(ledger 봉인은 가능) → `READY_WITH_REVIEW`(+ drafting gate 기록) / 스키마·coverage·보존·patch 위반 → `FAILED` + **기존 최종 파일 overwrite 금지**(검증을 write 앞에 두는 순서 유지) — 로 산정한다. v2의 "일률 READY"(2003행) 폐지.
6. **conservation**: 후보 BO 집합 == 최종 행 source_bo_id 집합, `F-###` 연속·유일 검증 유지. write → 재읽기 검증 유지.
7. **stdout 1줄**: `{"status","message","written_file","report_file","fact_count","blocked_review_count","resolved_exception_count","deterministic_review_count","les_inheritance_count","drafting_gate_count"}`. FAILURE_POLICY는 §5-9와 동일(FAILED 1줄 + raise, datetime 금지).
---
## 8. 모델·프리픽스 규칙 요약
| task | 유형 | 모델/사양 | 프리픽스 |
|---|---|---|---|
| F0 | code-executor | — | — |
| F1 | LLM 조건부 | gemini-3.1-flash-lite / low / low / max_iterations 1 | 현행 FL2 블록 바이트 유지 (= Part 2 R1 = Part 3 L1, 58f2b72d) |
| F2 | code-executor | — | — |
v2의 FL2 사양(pro-preview/high/medium/2)을 위로 교체하는 근거는 무효과 이중 실증 + BLOCK_REVIEW 안전판이며(개선보고서 §1.4), pro 계열 escalation 경로는 두지 않는다(판정 불가는 인간 검토가 정답 — Codex §14.2 원칙 채택).
---
## 9. task_procedure (전면 교체)
```yaml
task_procedure:
IN:
nexts: [Task_F0_fact_ledger_reducer]
wait_until: []
Task_F0_fact_ledger_reducer:
nexts: [Task_F1_fact_exception_adjudicator]
wait_until: [IN]
Task_F1_fact_exception_adjudicator:
nexts: [Task_F2_final_fact_ledger_gate_and_writer]
wait_until: [Task_F0_fact_ledger_reducer]
Task_F2_final_fact_ledger_gate_and_writer:
nexts: [OUT]
wait_until: [Task_F1_fact_exception_adjudicator]
OUT:
nexts: []
wait_until: [Task_F2_final_fact_ledger_gate_and_writer]
```
---
## 10. 수용 기준 (Definition of Done)
### 10.1 정적 검사
1. `Stage_1_Part_4_Claude_v3.yml` YAML parse 성공, task 수 3, task_procedure §9 일치, unreachable 0, 폐기 참조(`fact_source_pack`, `ADJUDICATION_RAW`, `{{prev.Task_FL1…}}`, `{{prev.Task_FL2…}}`, `SPLIT_FACT`, `bo_fact_inputs`) 잔존 0.
2. embedded Python 전부 `ast.parse` 통과, SKILL 준수(boilerplate·`{{__user_hash__}}`/`{{__workspace_hash__}}`·envelope 포함 raw_decode·stdout 단일 JSON 라인·`r"""…"""`·실패 raise·`datetime` 부재).
3. `Fact_Ledger_base.json` writer 정확히 1개(F2), candidate/pack writer 1개(F0), adjudication writer 1개(F1), report writer 1개(F2).
4. F1 프리픽스가 Part 2 Claude v3 R1·Part 3 Claude v2 L1 블록과 **바이트 동일**.
5. F1 사양 §8 일치(flash-lite/low/low/1, preflight pack 1파일).
6. 게이트 3종·review code 6종(§1-3) 자구 보존.
### 10.2 fixture 회귀 (7/10 실행물 입력, 코드 로컬 실행)
1. **F0**: 입력 6종만 read, pack 파일 미생성, 후보 50행이 v2 FL1 후보와 필드 동등(candidate_items 27필드 — 발췌 실질화에 따른 credibility/proof_strength 변화는 허용하되 변화 내역 기록), `has_exceptions=false`(42건 전량 결정론 해소: X-1로 40건, X-2로 2건 — 해소 내역이 stdout count와 audit 추적으로 확인 가능), candidate bundle ≤200KB.
2. **F1 경로**: 무예외 → no-exception 판정 파일 + 즉시 종료 시뮬레이션.
3. **F2 골든 동등**: 최종 `Fact_Ledger_base.json`이 현행 골든(`b589ff166a7d`, 50행)과 — (a) 행 수·`F-###` 순서·source_bo_id 시퀀스 동일 (b) 27필드 값 동등(KEEP_AS_IS 이중 실증에 따라 사실상 동일 기대; 허용 편차는 X-8 발췌 실질화가 credibility/proof_strength/derivation에 미치는 문서화된 개선 + X-7 승계로 추가되는 review code·must_consider뿐이며 전량 diff 목록화) (c) writer report의 게이트 결과(NOTICE_RECEIPT_EVIDENCE_WEAK_REVIEW 2건 등) 보존 + les_review_inheritance 추가 확인.
4. **2-run 바이트 결정론** (candidate·pack·최종·report 4파일 — 타임스탬프 제거로 성립).
5. **주입 테스트**: ① true 투영 충돌 합성(동일 필드에 source-backed 상충 후보 2개) → pack 수록·F1 발동 경로·비차단 판정 반영 ② 임의 extra/중복 decision → F2 hard fail ③ allowed 밖 patch → 거부 + BLOCK 처리(적용 0) ④ blocked 존재 → status `READY_WITH_REVIEW` + drafting gate ⑤ coverage 등식 위반(판정 누락) → F2 hard fail ⑥ adjudication 코드펜스 → 관용 파서 salvage / 부재 → FAILED + 최종 파일 미작성 ⑦ BO conservation 위반 합성 → hard fail ⑧ notice/possession/lien 게이트 회귀(현행 코드 6종 발화 케이스 유지) ⑨ LES review 주입(Part 3 산출에 review_required/blocked 합성) → fact code·report 승계.
6. **Stage 2 계약**: 최종 파일 27필드·배열 형식·enum 무변경 확인.
### 10.3 성능 합격 기준 (실 재실행, cold/warm 구분 3회 median)
중간 파일 1,020KB → 200KB 이하, stdout 157KB → 2KB 이하, LLM 실행 상시 1회(pro/high) → 조건부(정상 fixture 0회, flash-lite), 비용 $0.58 → ≈$0, 런타임 3:06 → no-exception 경로 90초 이하 목표. **§10.2 품질 불변식 위반 시 성능 달성해도 실패.**
---
## 11. 개정 보고서 기재 의무
v3 저장 시 최종 보고에 명시한다: (1) 예외 42건의 해소 내역(X-1 40건 / X-2 2건)과 audit 추적 경로, (2) 골든 대비 diff 전량 목록(발췌 실질화·LES 승계로 인한 문서화된 개선 포함), (3) Plan A/B 중 적용 채널, (4) D-1(예외 발생률 모니터링)·D-2(Part 1 GB 프리픽스 3,829B 정렬 — Stage 1 flash-lite 4형제 캐시 통일의 마지막 퍼즐)·D-3(중간 파일 debug-mode화)의 후속 이관.
## 12. 금지 사항 최종 목록
1. v2 원본 덮어쓰기·이동·삭제 금지 (v3는 신규 파일).
2. §1 불변 계약(최종 파일 27필드 스키마·행 규칙·게이트 3종·review code 6종) 변경 금지 — additive만 허용.
3. Part 1/2/3 YAML 수정 금지.
4. 복수 role/module/claim group의 축소 선택 강제 금지 — 배열 보존이 기본값.
5. F1에 pack 외 입력 제공 금지, F1의 최종 파일·candidate·report 작성 금지, 후보 밖 값·allowed 밖 patch 생성 금지.
6. 경계 위반 patch의 "경고 후 적용" 금지 — 거부·차단만 허용.
7. blocked·deterministic review·LES 승계 review의 silent drop 금지(전량 report·audit 추적).
8. LLM의 긴 서술·사실 창작 금지, pro 계열 escalation 금지.
9. 실패의 `sys.exit(0)` 위장 금지, 검증 실패 상태의 최종 파일 overwrite 금지, `datetime` 사용 금지.
10. 본 명세서에 없는 "개선"의 임의 추가 금지 — 범위 밖 아이디어는 개정 보고서에 제안으로만 기록.
@@ -0,0 +1,110 @@
# Stage 1 Part 4 비효율성 분석 보고서 (Claude v1)
- 분석 대상: `YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml` (2,027행, task 4개)
- 실행 실측: 런타임 3분 6초 / 비용 $0.58 (7/10 실행, `Results_July_10_3_15pm`)
- 참조 명세: Part 1 `Stage_1_Part_1_Claude_v3.yml`, Part 2 `Stage_1_Part_2_Claude_v3.yml`, Part 3 `Stage_1_Part_3_Claude_v2.yml`(개정 완료본)
- 작성 관점: 20년 이상 경력의 대한민국 최고 수준 변호사 + 세계적 수준의 AI 아키텍트
## 0. 분석 방법 — 실행물 기반 실측
Part 3 분석과 동일한 방법론을 적용했다. Part 4의 결정론 task(FL1·FL3) 전체 코드를 7/10 실행물 입력으로 로컬 재실행하여 실제 중간 산출물과의 일치를 먼저 확인했다: FL1이 생성한 `Fact_Ledger_base_candidate.json`의 candidate 50행과 exception pack 42건이 실제 실행물(418,076B)과 **완전 일치**로 재현되었다. 따라서 아래의 모든 수치는 실제 7/10 실행에서 일어난 일 그 자체이며, 특히 §2.2의 "LLM 무효과" 판정은 재현 환경에서의 대조 실험으로 증명된 것이다.
## 1. Part 4 실행 구조와 데이터 흐름 실측
Part 4는 Part 3 v1과 동형의 완전 직렬 4-task 체인이다: `IN → FL0(source pack 컴파일, Python) → FL1(결정론 후보/예외 생성, Python) → FL2(예외 판정, LLM: **gemini-3.1-pro-preview/high/medium, max_iterations 2, 무조건 실행**) → FL3(최종 writer, Python) → OUT`. Stage 1 4개 Part 중 Part 1·2·3이 모두 "결정론 reducer → 조건부 경량 adjudicator → 결정론 writer" 문법으로 개정된 지금, Part 4만 유일하게 "상시 실행되는 고사양 LLM" 패턴이 남아 있으며, **Part 4 비용 $0.58의 전액이 FL2(pro-preview) 한 태스크에서 발생**한다.
| 구간 | 채널 | 실측 크기 |
|---|---|---|
| FL0 입력 | localdocs read ×9 (client_goal, BO, **legal_effect_structures 255KB**, signal 3종, evidence_indexed, **evidence_all 87KB**, event_candidates) | 합계 약 640KB |
| FL0 → 파일 | `fact_source_pack.json` | **602,059B** (Stage 1 전체에서 가장 큰 중간 파일) |
| FL1 → 파일 | `Fact_Ledger_base_candidate.json` (후보 50행 + **exception pack 147.5KB 내장**) | 418,076B |
| FL1 → stdout | 요약 + **exception pack 전체 재출력** | **156,445B** |
| FL1 stdout → FL2 | `{{prev.…}}` 프롬프트 주입 | 156,445B (프롬프트 총계 ≈ 170KB: prefix 3.8KB + 정적 블록 9.7KB + 주입) |
| FL3 입력 | pack 602KB + candidate 418KB 파일 재읽기 + FL2 stdout 주입 | 1,020KB+ |
| FL3 → 파일 | `Fact_Ledger_base.json` 175,126B + writer report 452B | 175,578B |
최종 산출물 175KB를 만들기 위해 중간 파일 1,020KB가 쓰이고 다시 읽히며, 156KB가 stdout·프롬프트로 이동한다. 그리고 §2.2가 보여주듯 이 흐름의 정점인 LLM 판정은 최종 산출물을 한 바이트도 바꾸지 못했다.
## 2. 비효율 판정 항목
### 2.1 예외 과잉 생성 — Part 3에서 이미 반증된 원리의 재현
**P4-1. 정상적 다중 라우팅을 예외로 오인 (42건/50행 = 84%).** 7/10 실행에서 FL1은 예외 42건을 생성했다: `ambiguous_legal_role` 40건 + `weak_derived_fact` 2건. `ambiguous_legal_role`의 트리거는 "`legal_effect_roles` 3개 이상 AND `downstream_module_candidates` 2개 이상"인데, 후보 50행의 분포를 실측하면 (roles>2, modules>1)이 40행, (False, True)가 10행 — 즉 **구조 연계가 정상적으로 풍부한 행일수록 기계적으로 예외가 된다**. 하나의 사실이 대여금 청구·사해행위·담보관계 모듈에 동시에 라우팅되는 것은 Part 3 개정에서 확정한 원리대로 대체적·예비적 청구를 보전하는 **정상 상태**이지 판정 대상이 아니다. Part 3(LES1)의 type 예외 과잉 생성과 정확히 동형의 질병이다.
**P4-2. 예외 항목의 페이로드 비대.** 예외 1건의 크기가 중앙값 3,368B, 최대 6,410B다(42건 합계 147.5KB). 각 항목이 `related_bo_compact` 전체, `related_structure_snippets` 최대 8개, `related_signal_hints`, `related_evidence_excerpts` 최대 8개를 통째로 내장하기 때문인데, §2.4에서 보듯 이 "증거 발췌"는 실제로는 전부 비어 있다.
### 2.2 LLM 추론 비효율 — 판정이 산출물을 바꾸지 못했다 (핵심 실측)
**P4-3. FL2의 실질 효과 0 — 대조 실험으로 증명.** 실제 실행물의 candidate bundle과 exception pack을 입력으로, **42건 전부를 `KEEP_AS_IS`로 판정한 가상 adjudication을 FL3에 투입**해 최종 `Fact_Ledger_base.json`을 재생성한 결과, 실제 실행의 최종본과 **50행 완전 동일**했다. writer report 실측도 이를 뒷받침한다: blocked 0, patch 정책 경고 0, 미적용 patch 0, row 경고 0. 즉 pro-preview/high가 170KB 프롬프트로 42건을 판정한 결과는 전량 KEEP_AS_IS(또는 기존 값과 동일한 patch)였고, **Part 4 비용 $0.58 전액과 런타임의 LLM 구간이 최종 산출물 기여 0에 소비되었다**. Part 3 LES2(93% BLOCK, 효과 0)에 이어, Stage 1에서 "결정론이 만든 가짜 예외를 고사양 LLM에게 보내는" 패턴이 두 번째로 반증된 것이다.
**P4-4. 무조건 실행 + 최고 사양 모델.** FL2는 예외 유무와 무관하게 항상 실행되며, Stage 1 조건부 판정 태스크 중 유일하게 **pro-preview + reasoning high + verbosity medium + max_iterations 2**다(Part 1 GB·Part 2 R1·Part 3 L1은 모두 flash-lite/low/low/1 + 조기 종료). 판정 작업의 실체는 enum 선택(PATCH/KEEP_AS_IS/SPLIT_FACT/BLOCK_REVIEW)이므로 이 사양은 어떤 기준으로도 과잉이고, 실측상 그 판정의 부가가치는 0이었다.
**P4-5. 예외 데이터의 3중 물질화.** 동일한 exception pack 147.5KB가 (1) candidate bundle 파일 내장, (2) FL1 stdout 전체 재출력(156KB), (3) FL2 프롬프트 주입으로 세 번 이동한다. Part 1/2/3 개정이 확립한 "pack 단독 파일 + preflight" 채널이면 한 번이면 된다.
### 2.3 토큰·전송 비경제
**P4-6. fact_source_pack 602KB의 내부 중복과 사장 필드.** pack 구성의 실측과 소비 추적:
| pack 필드 | compact 크기 | 소비 실측 | 판정 |
|---|---:|---|---|
| `bo_fact_inputs` | 126.3KB | FL1 사용 | 유지하되 내부 중복 제거 |
| `legal_effect_structures_compact` | 125.8KB | `structure_by_id`만 FL1·FL3 사용. **내장 5-way `structure_index`는 다운스트림 소비 0** (FL0 자신이 메모리에서 by_bo_id를 쓴 뒤 통짜 재수록) | index 재수록 삭제 |
| `bo_by_id` | 45.0KB | FL1 스캔 3종 + FL3 사용 — 단 `bo_fact_inputs[].bo_compact`와 **완전 중복** | 한쪽만 유지 |
| `signal_hints_by_bo_id` | 35.5KB | **소비 0** (`bo_fact_inputs[].signal_hints`와 중복) | 삭제 |
| `evidence_authority_by_index` | 7.6KB | FL3가 key 집합만 사용 (`bo_fact_inputs[].evidence_authority`와 중복) | key 목록으로 축소 |
| `event_candidates_by_evidence_index` | 2.8KB | **소비 0** — `bo_fact_inputs[].event_candidates`도 FL1 참조 0회 | **양쪽 모두 삭제** |
| `client_goal_compact` | 1.5KB | FL1·FL3 소비 0 | 삭제 |
즉 602KB 중 실제로 하류가 소비하는 정보는 후보행 구성에 필요한 ~170KB 안팎이며, 나머지는 중복(bo/signal/evidence의 global+per-BO 이중 수록)과 사장 필드(이벤트 2계열·client_goal·index 재수록)다.
**P4-7. 입력 read의 낭비.** `evidence_all.json`(87KB)은 authority 빌더에서 setdefault 보충 역할만 하는데, 포함/제외 재실행 비교 결과 **30개 evidence 전부에서 산출 완전 동일**(기여 0 — Part 3 P3-3과 동일 실측). `evidence_event_candidates.json`은 위 표대로 산출이 전혀 소비되지 않고, `client_goal.json`의 compact도 소비 0이다. 9개 read 중 3개가 불필요하다.
**P4-8. FL3의 이중 대형 재읽기.** FL3는 pack 602KB와 candidate 418KB를 모두 재읽지만, pack에서 실제로 쓰는 것은 ID 집합 3종(ref 검증용)과 bo_by_id의 notice 필드뿐이다. slim pack이면 이 재읽기 자체가 수십 KB로 준다.
### 2.4 품질 결함 (효율과 별개로 교정 필요)
**P4-9. 증거 발췌가 전부 비어 있다.** FL0의 excerpt 수집 키(`excerpt/summary/content/text/body`)가 `evidence_indexed.json`의 실제 필드(`key_facts`, `key_dates`, `key_amounts`)와 일치하지 않아, **evidence authority 30건 전부 excerpt=None**이다. 그 결과 (a) `_score_evidence`의 credibility/proof_strength 판정이 제목 문자열에만 의존하고, (b) FL2에 제공된 `related_evidence_excerpts`가 사실상 빈 껍데기였다 — FL2가 42건을 판정할 실질 근거 자체가 프롬프트에 없었던 셈이며, 이는 전량 KEEP_AS_IS 결과의 한 원인으로 추정된다.
**P4-10. 변별 신호의 포화.** 최종 50행 전부 `must_consider=true`, 전부 `legal_centrality="critical"`이다(구조 연계가 있으면 무조건 critical/must_consider로 산정). Part 3 개정 전의 review 50/50 포화와 동형으로, Stage 2에 전달되는 우선순위 신호의 변별력이 0이다.
**P4-11. SKILL 정합 결함 3종.** (a) 실패 시 `sys.exit(0)` — FL0/FL1/FL3 모두 실패를 정상 종료로 위장. (b) read_docs **envelope 계층**의 strict `json.loads`(3 task 모두 — inner content에는 raw_decode가 있으나 envelope에는 없음). (c) `datetime.now()` 타임스탬프 3곳(FL0/FL1/FL3 산출물) — 동일 입력 2-run 바이트 결정론이 구조적으로 불가능해 골든 회귀 검증력을 약화시킨다. 또한 FL3의 FL2-stdout 파서는 코드펜스 tail에서 실패해 max_iterations 2 재호출을 유발하는 구조다(Part 3 P3-15와 동일).
### 2.5 유지해야 할 강점 (실측 확인)
FL2의 `COMMON_CACHE_PREFIX_STAGE_1`은 canonical(58f2b72d, Part 2 R1·Part 3 L1과 바이트 동일)이며, FL0의 stdout은 이미 1줄 요약이다(Part 3 LES0의 257KB stdout 같은 결함 없음). FL3의 닫힌 스키마 검증(FINAL_FIELDS 27종 강제·임의 필드 거부), patch의 allowed_fields 정책, coverage 검증, possession/notice/lien 결정론 게이트 3종(도메인 법리가 코드화된 자산), FL2 프롬프트의 "LES2 모호성 재판정 금지" 경계는 견실하므로 개정에서 그대로 보존한다.
## 3. 효율화 방안 — 최소 작업 / 최대 효과
Part 1·2·3 개정에서 세 번 검증된 동일 문법의 이식이다. 최종 산출물 `Fact_Ledger_base.json`(FINAL_FIELDS 27종 스키마·행 순서·`F-###` 규칙)과 writer report는 Stage 2 소비 계약이므로 불변으로 고정한다.
**R-1. task 통합: 4 → 3 (FL0+FL1 → F0').** FL0과 FL1을 단일 결정론 reducer로 병합하고 fact_source_pack을 물질화하지 않는다(602KB 파일·중복 필드 전체 소멸). F0'의 산출은 (a) slim candidate bundle 파일(후보 50행 + FL3 검증용 ID 집합 — exception pack 내장 제거), (b) exception pack 단독 파일(조건부 LLM용), (c) stdout 1줄 요약뿐이다. 입력 read는 9 → 6으로 줄인다(`evidence_all`·`evidence_event_candidates`·`client_goal` 제거 — 기여 0/소비 0 실측).
**R-2. 예외 생성 교정 — LLM 실질 0회화.** `ambiguous_legal_role`(다중 role/module)은 예외 생성 자체를 폐지하고 정상 다중 라우팅으로 보존한다(Part 3 X-2 확립 원리; KEEP_AS_IS 전량 실증이 무손실 보증). 잔여 유형(weak_derived_fact, legal_calculation_required, 투영 미완 계열)은 Part 2 X-3의 4중 조건(단일 값 선택 필수 + source-backed 근거 2+ + 보존·defer 불가 + compact 판정 충분)을 통과할 때만 pack에 수록하고, 불충족분은 `skeleton_validation_codes`의 결정론 review로 남긴다. 7/10 실측 기준 pack 수록 0건이 예상 결과다. 예외 항목의 compact 계약(항목당 ≤2KB, 빈 발췌 금지)도 함께 강제한다.
**R-3. FL2 → F1' 조건부 어드주디케이터.** Part 1 GB·Part 2 R1·Part 3 L1과 동일 골격: `gemini-3.1-flash-lite/low/low/max_iterations 1`, `preflight_files: [exception pack]`, `has_exceptions=false`면 no-exception 판정 파일을 쓰고 즉시 종료. 프리픽스는 현행 canonical 블록 바이트 유지. **비용 $0.58 → $0, LLM 구간 런타임 소거.** BLOCK_REVIEW 안전판과 "LES 모호성 재판정 금지" 경계는 현행 문구를 이식한다.
**R-4. F2'(최종 writer) 정비.** candidate 파일 + exception pack 파일 + 판정 파일의 3-파일 read로 일원화(602KB pack 재읽기 소멸 — ref 검증용 ID 집합은 slim bundle에 수록), §6.7 관용 파서 적용, patch 적용·게이트 3종·닫힌 스키마 검증은 현행 이식.
**R-5. 품질 교정 동반.** (a) excerpt 수집 키를 `key_facts`/`key_dates`/`key_amounts`로 교정해 증거 근거를 실질화(P4-9 — credibility 판정과 잔여 예외 판정 근거의 회복), (b) `must_consider`/`legal_centrality` 산정에 변별 기준 도입은 Stage 2 소비 계약 영향이 있으므로 필드·의미는 유지하되 변별 신호를 `skeleton_validation_codes`로 보강하는 additive 방식으로 한정, (c) SKILL 정합 일괄(실패 raise, envelope raw_decode, 타임스탬프 제거 또는 고정 — 2-run 결정론 확보).
**검증 계획(개정 시).** 7/10 골든 회귀: F0'→(F1')→F2' 재실행 → `Fact_Ledger_base.json` 50행이 현행 최종본과 의미 동등(KEEP_AS_IS 실증 덕분에 사실상 바이트 동등 기대 — 타임스탬프 제거 반영), writer report 게이트 결과 동일, 주입 테스트(진짜 계산 근거 결핍 주입 → pack 수록·F1' 발동 / 판정 누락 → coverage hard fail / 코드펜스 → salvage), 2-run 바이트 결정론, Stage 2 소비 필드 무변경.
## 4. 기대 효과 정량 요약
| 지표 | 현행 (실측) | 개정 후 (추정) |
|---|---|---|
| task 수 | 4 (직렬) | 3 (F1'는 실질 0회 조기 종료) |
| LLM | pro-preview/high 무조건 1회, 프롬프트 ≈170KB, 판정 42건 → **효과 0 실증** | flash-lite/low 조건부 (fixture 0회) |
| 비용 | $0.58 (전액 FL2) | ≈ $0 |
| 중간 파일 | 1,020KB (pack 602 + candidate 418) | ≈ 150KB (slim bundle + pack) |
| stdout | 157KB (FL1 예외팩 재출력 포함) | ≈ 1KB |
| 입력 read | 9파일 (기여 0인 evidence_all 87KB 포함) | 6파일 |
| 런타임 | 3분 6초 | 1분 내외 예상 (LLM 구간 소거 + IO 1/4) |
| 최종 산출 | 175KB, must_consider 50/50 포화 | 스키마·행 불변 (KEEP_AS_IS 실증), 변별 신호 additive 보강 |
## 5. 잔여 리스크와 열린 질문
첫째, "LLM 실질 0회"의 근거는 7/10 사건 1건의 실측이므로, F1'를 제거하지 않고 조건부로 남기는 설계가 안전하다 — 진짜 계산 근거 결핍(legal_calculation_required)이 실재하는 사건에서는 F1'가 발동해야 하며, 그 경우를 위해 R-5(a)의 excerpt 실질화가 선행되어야 판정 근거가 프롬프트에 실린다. 둘째, must_consider 포화는 Stage 2가 이 신호를 어떻게 소비하는지 확인 후 손대야 하므로 additive 보강으로 한정했다. 셋째, Part 4 개정이 완료되면 Stage 1 전체가 "결정론 reducer → 조건부 flash-lite 판정 → 결정론 writer" 단일 문법으로 통일되며, 이때 flash-lite 4형제(GB·R1·L1·F1')의 프리픽스 바이트 통일(Part 3 개선보고서 D-2: Part 1 GB의 3,829B 정렬)을 함께 마무리하는 것이 캐시 관점의 마지막 퍼즐이다.
---
*본 보고서의 수치는 전량 7/10 실행물과 로컬 재현(FL1 candidate/예외 완전 일치 재현, KEEP_AS_IS 대조 실험, evidence_all 포함/제외 실험)에서 실측되었다. 다음 단계는 Codex 보고서와의 비교를 거친 개정 전략 수립이다.*
@@ -0,0 +1,587 @@
# Stage 1 Part 4 비효율성 및 최적화 보고서
## 1. 평가 목적과 범위
이 보고서는 다음 네 작업명세서의 현재 연결 계약을 전제로 `Stage_1_Part_4_v2.yml`의 비효율성과 품질 위험을 평가한다.
1. `Stage_1_Part_1_Codex_v3.yml`
2. `Stage_1_Part_2_Codex_v3.yml`
3. `Stage_1_Part_3_Codex_v2.yml`
4. `Stage_1_Part_4_v2.yml`
실측 근거는 `Results_July_10_3_15pm`에 보존된 실행 결과다. 다만 이 결과는 개정 전 Part 1 v2, Part 2 v2, Part 3 v1, Part 4 v2를 실행한 결과이므로, 개정된 Part 1~3의 성능을 직접 측정한 결과는 아니다. 따라서 아래에서는 다음을 구분한다.
- **실측 판정**: 7월 10일 결과 파일에서 직접 확인한 사실
- **정적 판정**: 현재 Codex v3/v3/v2와 Part 4 v2의 YAML 계약을 비교해 확인한 사실
- **예상 효과**: Part 4 개정 후 재실행으로 검증해야 하는 목표
법률적 평가는 사실·증거·법률효과 후보를 보존하면서 Stage 1이 최종 법률판단을 선취하지 않아야 한다는 원칙에 따랐다. 아키텍처 평가는 결정적 연산을 Python에 두고, LLM은 구조화된 자료만으로도 복수의 합리적 투영이 남는 진정한 예외에만 사용하는 원칙에 따랐다.
## 2. 최종 판정
**Part 4의 가장 큰 병목은 FL2의 모델 자체보다 FL1이 정상적인 다중값을 대량의 LLM 예외로 오분류하고, FL2를 예외 0건에도 반드시 실행하도록 직렬 연결한 구조다.**
7월 10일 실행에서 다음이 확인되었다.
- 50개 Fact 후보 중 40개가 예외 대상이 되었다.
- 총 예외는 42건이었다.
- 그중 40건은 `ambiguous_legal_role`, 2건은 `weak_derived_fact`였다.
- FL2 입력의 `exception_pack`은 minified 기준 146,998바이트였다.
- FL2는 `gemini-3.1-pro-preview`, `reasoning: high`, `max_iterations: 2`로 실행되었다.
- FL2 실행 후 최종 Fact Ledger는 후보본과 **변경 행 0개, 변경 필드 0개**였다.
- Part 4 전체 실행시간은 3분 6초, 비용은 $0.58이었다.
즉, 이 실행에서 FL2의 한계효용은 0이었고, 최종 결과를 만들기 위한 작업은 사실상 전부 결정적이었다. 더구나 Part 3의 `review_required`와 `quality_gate.review_queue`는 Part 4가 읽고도 Fact Ledger 검토 코드로 충분히 승계하지 않는다. 비용은 정상적인 다중 역할을 재판단하는 데 쓰이고, 정작 upstream 검토 상태는 약하게 전달되는 품질·효율 역전이 발생한다.
가장 적은 개정으로 가장 큰 효과를 얻는 권고안은 다음과 같다.
1. FL1의 단순 cardinality 기반 예외를 제거한다.
2. FL2를 단일 필수 task에서 **조건부 wildcard task**로 바꾼다.
3. 정상 경로의 FL2 실행 횟수를 0으로 만든다.
4. 진정한 투영 충돌만 작은 shard로 보내고 `gemini-3.1-flash-lite/medium`을 사용한다.
5. FL0의 source pack은 값을 한 번만 저장하고 BO별 입력은 ID 참조만 갖게 한다.
6. FL3의 보존·참조·patch·upstream review 게이트는 강화한다.
## 3. 현재 Part 4 실행 구조
### 3.1 현재 DAG
```text
IN
|
v
FL0 fact_source_pack_compiler [Python]
| - 9개 JSON 읽기
| - 602 KB source pack 작성
v
FL1 deterministic_fact_ledger_candidate [Python]
| - 50개 후보 작성
| - 42개 예외 작성
| - 418 KB candidate bundle 작성
v
FL2 single_fact_exception_adjudicator [LLM, 필수 1회]
| - exception_pack 전체를 한 번에 입력
| - Gemini Pro/high
v
FL3 final_fact_ledger_gate_and_writer [Python]
| - source pack + candidate + LLM 결과 재결합
| - final ledger와 writer report 작성
v
OUT
```
모든 작업이 직렬이다. `exception_count == 0`이어도 FL2를 건너뛸 DAG 경로가 없다.
### 3.2 작업별 현재 역할
| 작업 | 실행유형 | 핵심 역할 | 현재 판정 |
|---|---|---|---|
| FL0 | Python | 9개 파일 검증·축약·join, source pack 작성 | 필요하나 과대 포장 |
| FL1 | Python | BO별 Fact 후보 및 예외 생성, possession/notice/lien gate | 핵심 작업, 예외 규칙 개정 필요 |
| FL2 | LLM | 전체 exception pack 일괄 판정 | 현재 구조의 주 병목 |
| FL3 | Python | patch 적용, 참조 검증, 최종 파일 작성 | 반드시 유지, fail-closed 강화 필요 |
## 4. 실측 입력·중간 산출물 분석
### 4.1 주요 파일 크기와 개수
| 파일 | 크기 | 주요 개수 |
|---|---:|---:|
| `BO.json` | 175,126 B | BO 50 |
| `legal_effect_structures.json` | 254,991 B | structure 50, review queue 78 |
| `evidence_indexed.json` | 91,841 B | evidence 30 |
| `evidence_event_candidates.json` | 49,327 B | item 29 |
| 3 signals 합계 | 44,648 B | 5 + 50 + 50 records |
| `client_goal.json` | 6,029 B | 1 object |
| `fact_source_pack.json` | 602,059 B | BO input 50 |
| `Fact_Ledger_base_candidate.json` | 418,076 B | 후보 50, 예외 42 |
| `Fact_Ledger_base.json` | 128,855 B | Fact 50 |
| `fact_ledger_writer_report.json` | 452 B | 경고·차단 0, notice weak review 2 |
보존된 입력 8개만 합쳐도 약 622 KB다. FL0는 이를 602 KB짜리 source pack으로 다시 작성하고, FL1은 418 KB짜리 candidate bundle을 추가 작성한다. 최종 파일은 129 KB이므로, 최종 결과에 이르기 전에 그 몇 배의 중간 JSON을 직렬로 읽고 쓴다.
### 4.2 재현성 결함
FL0의 `INPUT_FILES`는 `evidence_all.json`을 필수 입력으로 선언한다. 그러나 `Results_July_10_3_15pm`에는 해당 파일이 없다. 실행 당시에는 존재했으나 결과 묶음에서 누락되었을 수 있지만, 보존 결과만으로 Part 4를 재현할 수 없다는 점은 분명하다.
실제 `fact_source_pack.json`의 30개 evidence authority는 모두 `evidence_indexed.json` 출처였다. 따라서 현재 계약에서는 다음 중 하나를 택해야 한다.
- `evidence_indexed.json`을 authoritative source로 정하고 `evidence_all.json` 의존성을 제거한다.
- 정말 fallback이 필요하면 optional input으로 바꾸고, 부재를 manifest에 기록한다.
필수 입력으로 유지하면서 실행 결과 묶음에는 보존하지 않는 현재 방식은 피해야 한다.
## 5. FL0 비효율성
### 5.1 동일 정보의 중복 저장
`fact_source_pack.json`의 minified 구성요소를 분석하면 다음 중복이 확인된다.
| 데이터 | 전역 map | `bo_fact_inputs[]` 내 반복 | 판정 |
|---|---:|---:|---|
| BO compact | 48,376 B | 47,984 B | 거의 완전 중복 |
| signal hints | 34,708 B | 34,316 B | 거의 완전 중복 |
| evidence authority | 7,358 B | 16,227 B | BO별 반복 |
| event candidates | 2,466 B | 5,503 B | BO별 반복, FL1 직접 사용 안 함 |
또한 `legal_effect_structures_compact.structure_index`는 99,113바이트이며, 세부 구성은 다음과 같다.
| 인덱스 | 크기 | FL1/FL3 소비 여부 |
|---|---:|---|
| `by_bo_id` | 33,856 B | 사용 |
| `by_issue_cluster_id` | 27,070 B | source pack 이후 미사용 |
| `by_asset_cluster_id` | 16,746 B | source pack 이후 미사용 |
| `by_evidence_index` | 14,816 B | source pack 이후 미사용 |
| `by_candidate_structure_type` | 6,514 B | source pack 이후 미사용 |
FL0에서 다섯 인덱스를 모두 검증하는 것은 필요하다. 그러나 검증 후 FL1/FL3가 쓰지 않는 네 인덱스를 source pack에 다시 복제할 필요는 없다.
### 5.2 쓰지만 소비하지 않는 정보
다음 필드는 source pack에 작성되지만 후속 작업이 실질적으로 소비하지 않는다.
- `client_goal_compact`
- `event_candidates_by_evidence_index`
- `bo_fact_inputs[].event_candidates`
- `structure_index` 중 `by_bo_id` 외 네 인덱스
- `signal_hints_by_bo_id`와 `bo_fact_inputs[].signal_hints` 중 한쪽 사본
- `bo_by_id`와 `bo_fact_inputs[].bo_compact` 중 한쪽 사본
`client_goal.json`은 Stage 1 handoff 파일로 별도 보존하면 된다. Fact Ledger 투영을 위해 FL0 source pack 안에 다시 넣을 필요는 없다.
### 5.3 I/O 호출 수
현재 deterministic task의 localdocs tool 호출은 다음과 같다.
- FL0: 9 read + 1 write + 1 post-write reread = 11회
- FL1: 1 read + 1 write + 1 post-write reread = 3회
- FL3: 2 read + 2 write + 1 post-write reread = 5회
- 합계: 19회, MCP session 3개
post-write reread는 무결성 검증 가치가 있으므로 우선 삭제 대상이 아니다. 먼저 데이터 중복과 FL2 호출을 제거하고, 여전히 Python 구간이 병목일 때 FL0+FL1 병합을 2차 개정으로 검토하는 것이 변경 위험이 가장 낮다.
## 6. FL1 예외 분리의 구조적 문제
### 6.1 예외가 예외가 아닌 상태
실행 결과에서 50개 Fact 중 40개, 즉 80%가 하나 이상의 예외를 가졌다. 예외 처리율이 이 수준이면 exception path가 아니라 사실상의 main path다.
| 예외유형 | 건수 | FL1 trigger | 실질 판정 |
|---|---:|---|---|
| `ambiguous_legal_role` | 40 | role > 2 및 module > 1 | false positive |
| `weak_derived_fact` | 2 | 문자열 길이 < 12 | 한국어에 부적절한 heuristic |
| 기타 4종 | 0 | 누락·투영 실패 조건 | 이번 실행에서는 미발화 |
`ambiguous_legal_role` 40건의 대부분은 역할 3개, module 2개였다. 최종 스키마의 `legal_effect_roles[]`, `downstream_module_candidates[]`, `must_not_drop_in_claim_types[]`는 원래 복수값을 보존하도록 설계되어 있다. 따라서 복수값의 존재 자체는 모순도, 투영 실패도 아니다.
법률적으로도 Stage 1에서 병합적·예비적·선택적 청구 가능성과 복수 법률효과 후보를 보존하는 것이 안전하다. 단지 후보가 여러 개라는 이유로 하나를 선택하게 하면 청구구성이나 공격방어방법을 조기에 축소할 위험이 있다.
### 6.2 `weak_derived_fact`의 언어 편향
두 예외의 실제 `derived_fact`는 다음과 같다.
- `물품대금 지급 최고` 10자
- `목적물 특정` 6자
두 표현 모두 짧지만 법률상 의미를 가진 사실 표제다. 문자열 길이는 사실의 법률적 완결성이나 증거충실도를 대변하지 않는다. 이 조건은 다음처럼 바꾸는 것이 맞다.
1. `derived_fact`가 비어 있으면 BO의 action/object/date를 이용해 결정적으로 재작성한다.
2. 재작성 후에도 비어 있거나 핵심 source ref가 없으면 review code를 부여한다.
3. 길이만으로 LLM 예외를 만들지 않는다.
### 6.3 예외별 read diet가 지나치게 넓음
각 exception item은 유형과 무관하게 다음을 반복 포함한다.
- BO compact 전체
- 연관 structure 최대 8개
- issue/asset/evidence/type snippets
- 모든 signal hints
- evidence excerpts 최대 8개
그러나 `ambiguous_legal_role`은 역할·module·structure type의 충돌 여부만 보면 되고, `weak_derived_fact`는 BO core와 제한된 source excerpt만 필요하다. 모든 유형에 같은 context envelope을 사용한 결과, 예외 42건의 pack이 minified 146,998바이트로 후보 50개의 본문 95,258바이트보다 1.54배 커졌다.
## 7. FL2 비효율성과 품질 위험
### 7.1 필수 단일 호출
현재 FL2는 예외 유무와 관계없이 직렬로 한 번 실행된다. prompt는 다음 규모다.
- 전체 static prompt: 13,528 B, 215 lines
- common cache prefix: 3,829 B
- task overlay: 9,699 B
- dynamic exception pack: 146,998 B(minified 기준)
예외가 없는 사건에서도 13.5 KB static prompt를 Pro/high 모델에 보내고 `READY_NO_EXCEPTIONS`를 생성해야 FL3가 실행된다. 이는 Python으로 100% 처리할 수 있는 분기다.
### 7.2 모델 과대 사양
현재 FL2 권한은 법률구조를 새로 판단하거나 raw evidence를 읽는 것이 아니라, 이미 결정된 Part 3 구조를 Fact Ledger 필드에 투영하는 것이다. 이 범위에 `gemini-3.1-pro-preview/high`는 과대 사양이다.
복잡한 법리가 필요한 항목은 FL2가 해결할 항목이 아니라 `BLOCK_REVIEW` 또는 downstream legal-theory 작업으로 보내야 한다. 진정한 구조 투영 충돌만 남긴 뒤 `gemini-3.1-flash-lite/medium`으로 처리하는 편이 권한 경계와 비용 양쪽에서 우월하다.
### 7.3 실측 한계효용 0
FL2 전후를 비교한 결과는 다음과 같다.
- 변경된 Fact 행: 0
- 변경된 필드: 0
- blocked review: 0
- patch policy warning: 0
- unapplied patch: 0
42건 전부에 LLM 추론을 사용하고 후보와 완전히 동일한 최종 파일을 얻었다. 이 실행에 한해서는 FL2를 건너뛰어도 결과가 동일하다.
### 7.4 cache prefix 불일치
개정된 Part 1~3의 모든 LLM task는 동일한 prefix를 사용한다.
- bytes: 3,385
- SHA-256: `6e01f72f1803767b6bb16b5aef6cf34760e6dc1b293c316c75e990d09ad5fe63`
Part 4 v2의 FL2는 별도 prefix를 사용한다.
- bytes: 3,829
- SHA-256: `58f2b72d6c2650739c45d85cc57899150434db86a97bf19cd5a59d92d11dfbb5`
따라서 Stage 1 전체 common cache prefix가 깨진다. Part 4 개정 시 Part 1~3의 3,385바이트 prefix를 바이트 단위로 동일하게 사용해야 한다.
## 8. 놓치고 있는 upstream 검토 상태
7월 10일 `legal_effect_structures.json`은 다음 상태였다.
- root status: `READY_WITH_REVIEW`
- structure 50개 전부 `review_required: true`
- quality gate review queue 78개
- `structure_review_required` 50개
- `blocked_exception` 28개
FL0는 각 structure의 `review_required`를 compact 구조에 보존한다. 그러나 FL1은 이를 exception trigger, `skeleton_validation_codes`, `must_consider` 또는 writer report로 승계하지 않는다. FL3도 Part 3의 `quality_gate.review_queue`를 검증하거나 보고하지 않는다.
현재 Part 3 Codex v2의 review queue는 `source_bo_ids`, `review_code`, `downstream_owner`, blocked exception 정보 등을 구조적으로 제공하도록 개정되어 있다. Part 4는 이를 다시 LLM에 판단시키지 말고 다음과 같이 결정적으로 승계해야 한다.
- 관련 Fact에 `LES_REVIEW_REQUIRED` 또는 더 구체적인 review code 부여
- `must_consider: true`
- writer report에 affected `fact_id`와 `source_bo_id` 기록
- blocked exception은 최종 writer status를 `READY`로 광고하지 않도록 gate 설정
- legal-theory 항목은 Stage 2 owner로 전달하고 FL2가 재심하지 않음
이는 LLM 호출을 늘리지 않으면서 품질을 높이는 개정이다.
## 9. FL3의 안전성 결함
FL3는 반드시 유지해야 하지만 다음 계약은 강화해야 한다.
### 9.1 coverage 검사가 exact하지 않음
현재 검사는 `expected ⊆ decided ∪ blocked`만 확인한다. 따라서 다음을 차단하지 못한다.
- 예상하지 않은 extra exception ID
- 동일 exception의 중복 decision
- decision과 blocked에 동시에 들어간 ID
- exception 0건인데 임의 decision이 들어온 경우
- `input_exception_count`, decision count와 실제 배열의 불일치
### 9.2 허용되지 않은 patch도 실제 적용됨
현재 `_apply_patch`는 patch field가 `allowed_output_fields` 밖이면 warning을 남기지만, 그 뒤에도 `row[key] = value`를 실행한다. 즉, 경계 위반 patch가 경고와 함께 최종 파일에 반영된다.
수정 원칙은 명확하다.
- `patch.keys ⊆ allowed_output_fields ∩ FINAL_FIELD_SET`가 아니면 해당 decision을 거부한다.
- out-of-scope patch는 적용하지 않고 `BLOCK_REVIEW` 또는 gate failure로 보낸다.
- warning 후 적용은 금지한다.
### 9.3 blocked 상태에서도 READY를 출력할 수 있음
FL3의 stdout status는 blocked review가 있어도 일률적으로 `READY`다. 이는 downstream이 미해결 검토를 놓칠 수 있다.
최소 변경안은 최종 ledger를 sealed artifact로 계속 작성하되 다음을 강제하는 것이다.
- blocked 0건: `READY`
- blocked 또는 upstream blocking review 존재: `READY_WITH_REVIEW`
- final drafting이 허용되지 않는 경우 `BLOCK_FINAL_DRAFTING` gate 기록
- schema·coverage·보존 위반: final overwrite 금지, `FAILED`
## 10. 작업별 삭제·축소 안전성 판정
| 대상 | 판정 | 근거 |
|---|---|---|
| FL0 전체 삭제 | 금지 | provenance join과 upstream contract 검증 필요 |
| FL0 source pack 중복값 | 삭제 권고 | 전역 map과 BO별 사본이 중복 |
| `client_goal_compact` | source pack에서 삭제 권고 | FL1/FL3 미사용, 원본은 별도 handoff |
| `evidence_all.json` 필수 의존 | 삭제 또는 optional 권고 | 결과 묶음에 부재, 실제 authority는 indexed 30개 |
| 미사용 4개 structure index의 재직렬화 | 삭제 권고 | FL0에서 검증만 하고 source pack에는 미보존 가능 |
| FL1 전체 삭제 | 금지 | Fact row 작성과 deterministic safety gate의 핵심 |
| cardinality 기반 role/claim 예외 | 삭제 권고 | 배열형 최종 스키마와 충돌, false positive |
| 문자열 길이 기반 weak fact 예외 | 삭제 권고 | 한국어 의미 완결성과 무관 |
| possession/notice/lien scan | 유지 | Stage 1 sealed 품질 게이트 |
| FL2 단일 필수 task | 삭제 권고 | 조건부 wildcard로 대체 |
| FL2 기능 전체 | 조건부 유지 | 진정한 evidence-grounded projection conflict만 처리 |
| FL3 전체 삭제 | 금지 | sole writer·참조·보존·차단 gate 필요 |
| source pack/candidate 파일 자체 | 즉시 삭제 보류 | downstream·감사 소비 여부 확인 후 결정 |
| `Fact_Ledger_base.json` schema | 유지 | Stage 2 핵심 handoff 계약 |
중간 파일의 물리적 삭제는 Stage 2와 운영 감사 도구의 소비 여부를 별도로 검색한 뒤 결정해야 한다. 이번 1차 개정에서는 파일명은 유지하되 내부 payload를 축소하는 편이 안전하다.
## 11. 권고 개정안: 최소 변경, 최대 효과
### 11.1 개정 우선순위
#### P0: 즉시 적용
1. FL2를 `Task_FL2_exception_adjudicator_*` 조건부 wildcard로 변경한다.
2. FL1에서 true exception이 0건이면 FL3가 직접 실행되게 한다.
3. `ambiguous_legal_role`의 cardinality-only trigger를 제거한다.
4. `weak_derived_fact`의 문자열 길이 trigger를 제거한다.
5. FL2 모델을 `gemini-3.1-flash-lite`, reasoning `medium`으로 낮춘다.
6. Part 1~3과 동일한 common cache prefix를 사용한다.
7. FL3 patch whitelist와 exact coverage gate를 수정한다.
8. Part 3 review queue를 deterministic하게 Fact/보고서에 승계한다.
#### P1: 같은 개정에서 적용 권고
1. FL0 source pack의 전역 map/BO별 값 중복을 제거한다.
2. BO별 pack은 ID와 ref만 갖게 한다.
3. `evidence_all.json`을 제거하거나 optional fallback으로 바꾼다.
4. 예외 유형별 최소 context schema를 사용한다.
5. FL2 shard 크기와 항목 수에 상한을 둔다.
#### P2: 재측정 후 적용
1. FL0와 FL1을 하나의 deterministic compiler로 병합한다.
2. source pack을 writer가 읽지 않도록 candidate bundle에 최소 validation manifest를 넣는다.
3. 내부 중간 파일의 물리적 생성을 optional debug mode로 바꾼다.
P2는 추가 성능을 얻을 수 있지만 수정 범위와 회귀 위험이 커진다. 현재 병목의 대부분은 P0의 FL2 정상 경로 제거로 해결할 수 있으므로 1차 개정에는 포함하지 않아도 된다.
### 11.2 개정 DAG
```text
true exception 1..N
+-----------------------+
| v
IN -> FL0_slim -> FL1_candidate_and_exception_planner -> FL2_exception_*
| |
| true exception = 0 |
+------------------+-----------------+
v
FL3_exact_gate_writer
|
v
OUT
```
권장 `task_procedure` 의미는 다음과 같다.
```text
FL0 -> FL1
FL1 -> FL2_* and FL3
FL2_* -> FL3
FL3 waits for FL1 and all FL2_*
```
exception shard가 없으면 wildcard 인스턴스는 0개이고 FL3가 바로 실행된다. 이 패턴은 현재 개정된 Part 1~3의 conditional adjudicator 패턴과 일치한다.
## 12. FL0 개정 명세
### 12.1 입력 축소
필수 입력을 다음으로 제한한다.
- `BO.json`
- `legal_effect_structures.json`
- `actio_case_signals.json`
- `case_liability_signals.json`
- `legal_effect_signals.json`
- `evidence_indexed.json`
- `evidence_event_candidates.json`: provenance/event 보조가 필요한 경우만
`client_goal.json`은 Fact Ledger source pack에서 제외한다. `evidence_all.json`은 제거하거나 optional fallback으로 둔다.
### 12.2 정규화된 단일 저장
권장 source pack shape는 다음과 같다.
```json
{
"fact_source_pack": {
"schema_version": "stage1_fact_source_pack.v3",
"status": "READY|READY_WITH_REVIEW|FAILED",
"bo_by_id": {},
"structure_by_id": {},
"structure_refs_by_bo_id": {},
"signal_hints_by_bo_id": {},
"evidence_authority_by_index": {},
"event_hints_by_evidence_index": {},
"upstream_review_by_bo_id": {},
"source_integrity": {},
"source_counts": {}
}
}
```
`bo_fact_inputs[]`는 제거한다. FL1은 `bo_by_id`의 sorted key를 순회하면서 다른 map을 ID로 조회한다. 같은 BO, signal, evidence, event를 각 Fact input 안에 재복제하지 않는다.
### 12.3 유지해야 할 검증
- BO ID set과 `structure_index.by_bo_id` key의 관계
- 모든 structure source BO의 존재
- 모든 linked structure ID의 존재
- 모든 evidence ref의 존재
- Part 3 root schema/status
- 다섯 structure index의 schema와 내부 참조
- Part 3 quality gate coverage
다섯 인덱스는 메모리에서 검증하되 FL1이 쓰는 `by_bo_id`와 최종 ref set만 source pack에 보존한다.
## 13. FL1 개정 명세
### 13.1 예외 라우팅 3분법
FL1은 모든 문제를 LLM exception으로 만들지 말고 다음으로 분리한다.
| 경로 | 성질 | 처리 |
|---|---|---|
| deterministic pass | 정상 복수값, 완전한 구조 투영 | 후보에 그대로 보존 |
| deterministic review | 누락 사실, legal theory 필요, upstream review | code/gate 부여 후 downstream 전달 |
| true LLM exception | 동일 필드에 상충하는 2개 이상 근거가 있고 Stage 1 투영 선택이 필요 | 작은 shard로 FL2 전달 |
### 13.2 유형별 처리
| 기존 유형 | 개정 처리 |
|---|---|
| `ambiguous_legal_role` | role/module 개수만으로 발화 금지. 명시적 상호배타 conflict flag가 있을 때만 true exception |
| `ambiguous_claim_chain` | 여러 claim/liability ID를 배열에 보존. scalar 선택이 필요한 필드가 있을 때만 예외 |
| `weak_derived_fact` | 길이 기준 삭제. 빈 값은 deterministic template 보충, 실패하면 review |
| `legal_calculation_required` | 누락값을 LLM이 창조하지 않음. source에 복수의 명시 후보가 있을 때만 투영 예외, 그 외 downstream calculation review |
| `unresolved_asset_cluster_projection` | unique asset cluster는 deterministic. Part 3 자체가 blocked이면 review 승계 |
| `unresolved_structure_role_projection` | Part 3 type/role map으로 deterministic. 재법리 판단 필요 시 Stage 2 review |
### 13.3 exception shard 상한
- shard당 최대 4개 exception
- minified dynamic payload 권고 상한 25 KB
- 유형별 allowed fields만 포함
- 동일 BO/structure/evidence context는 shard-local dictionary에 한 번만 저장
- 상한 초과는 더 작은 shard로 분할
- 분할 불가 또는 context 부족은 LLM에 보내지 않고 `BLOCK_REVIEW`
## 14. FL2 개정 명세
### 14.1 실행 조건
다음 조건을 모두 만족할 때만 wildcard 인스턴스를 만든다.
1. true exception이 1개 이상이다.
2. exception이 Stage 1 projection authority 안에 있다.
3. 해결에 필요한 모든 후보와 provenance가 compact shard에 있다.
4. legal theory 확정이나 raw evidence 재독해가 필요하지 않다.
### 14.2 모델과 prompt
- provider: `google`
- model: `gemini-3.1-flash-lite`
- reasoning: `medium`
- max_iterations: 2
- tools: none
- common prefix: Part 1~3과 바이트 동일
- task overlay: exception schema, authority, output contract만 유지
Part 4의 투영 범위에서는 Pro/high escalation을 두지 않는 것이 원칙이다. Flash-lite가 안전하게 해결하지 못하는 항목은 법률난도가 높아서가 아니라 authority/context가 부족한 것이므로 `BLOCK_REVIEW`가 맞다.
### 14.3 출력 최소화
- input exception ID당 정확히 1개 decision
- `KEEP_AS_IS`, `PATCH`, `BLOCK_REVIEW`만 유지
- 실제 autosplit을 하지 않으므로 `SPLIT_FACT` 삭제
- rationale은 짧은 reason code만 허용
- patch는 allowed field만 포함
## 15. FL3 개정 명세
### 15.1 필수 hard gate
1. `expected_exception_ids == decision_ids ∪ blocked_ids`
2. `decision_ids ∩ blocked_ids == ∅`
3. ID 중복과 extra ID 0건
4. decision의 fact/BO/type가 원 exception과 정확히 일치
5. patch key는 allowed fields와 final schema의 교집합에 포함
6. candidate BO ID set과 upstream BO ID set의 보존
7. fact ID uniqueness와 결정적 ordering
8. evidence/structure ref가 authoritative set의 부분집합
9. Part 3 blocked/review 승계
10. possession/notice/lien sealed gate 유지
### 15.2 상태 규칙
| 조건 | writer status | 최종 파일 |
|---|---|---|
| 모든 gate 통과, block 없음 | `READY` | 작성 |
| 검토 항목은 있으나 ledger 봉인 가능 | `READY_WITH_REVIEW` | 작성 + drafting gate |
| schema/coverage/conservation/patch 위반 | `FAILED` | overwrite 금지 |
### 15.3 보존해야 할 현재 기능
- `POSSESSION_CAUSE_CONFLICT`
- `LEGAL_CAUSE_STATE_UNKNOWN_REVIEW`
- `NOTICE_RECEIPT_UNVERIFIED`
- `NOTICE_RECEIPT_EVIDENCE_WEAK_REVIEW`
- `LIEN_ASSERTED_AFTER_EXTINCTION_NOTICE_REVIEW`
- `BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING`
이 기능들은 결정적이고 법률상 중요한 Stage 1 sealed gate이므로 경량화 대상이 아니다.
## 16. 기대 효과와 검증 기준
### 16.1 7월 10일 fixture에 대한 기대 결과
개정 규칙을 같은 결과물에 적용하면 다음이 기대된다.
- 40건 `ambiguous_legal_role`: cardinality false positive로 제거
- 2건 `weak_derived_fact`: 빈 값이 아니므로 제거
- true LLM exception: 0건
- FL2 실행: 0회
- 최종 Fact Ledger: 기존 결과와 의미상 동일
- Part 3 review 상태: 기존보다 명확하게 writer report와 Fact code에 승계
### 16.2 정량 합격 기준
| 지표 | 현재 | 1차 목표 |
|---|---:|---:|
| 정상 사건 FL2 호출 | 1 | 0 |
| 7월 10일 false exception | 42 | 0 |
| FL2 모델 | Pro/high | Flash-lite/medium |
| source pack | 602,059 B | 330 KB 이하 권고 |
| candidate bundle | 418,076 B | 200 KB 이하 권고 |
| common prefix 종류 | Stage 1 내 2종 | 1종 |
| out-of-scope patch 적용 | warning 후 적용 가능 | 0, hard reject |
| Part 4 LLM 비용 | $0.58 포함 | no-exception 경로 $0 |
| Part 4 runtime | 3분 6초 | no-exception p95 90초 이하 권고 |
크기·시간 목표는 실제 Liti-agent 재실행으로 확정해야 한다.
### 16.3 회귀 검증 fixture
최소 다음 fixture를 자동화해야 한다.
1. no-exception fixture: FL2 0회, final 작성
2. multi-role non-conflict fixture: 배열 보존, LLM 미호출
3. genuine projection conflict fixture: FL2 shard 1개, exact patch
4. empty derived fact fixture: deterministic fallback 또는 review
5. upstream LES review fixture: Fact code와 writer report 승계
6. blocked LES exception fixture: `READY_WITH_REVIEW`와 drafting gate
7. malicious extra decision fixture: FL3 실패
8. out-of-scope patch fixture: patch 미적용 및 실패/차단
9. BO conservation fixture: expected BO와 final source BO set equality
10. unknown evidence/structure ref fixture: fail-closed
11. notice received-date missing fixture: drafting block 유지
12. possession/legal-cause conflict fixture: hard warning 유지
## 17. 최종 권고
Part 4는 전면 재설계할 필요가 없다. FL0·FL1·FL3의 deterministic 골격과 최종 `Fact_Ledger_base.json` 계약은 유지할 가치가 있다. 핵심은 다음 한 문장으로 요약된다.
> **정상적인 복수 역할과 짧은 한국어 사실표제를 예외에서 제거하고, 진정한 상충 투영만 조건부 Flash-lite shard로 보내며, Part 3 review와 FL3 hard gate를 결정적으로 강화한다.**
우선 P0만 적용해도 7월 10일 사례에서는 FL2를 완전히 건너뛰면서 현재 최종 파일을 그대로 재현할 수 있다. 그 뒤 source pack 단일 저장과 유형별 compact context를 적용하면 I/O와 토큰량을 추가로 줄일 수 있다. FL0+FL1 병합이나 중간 파일 제거는 재측정 후에 결정해야 하며, Stage 2·감사 도구 소비 확인 전에는 공개 handoff 파일명과 최종 Fact Ledger schema를 바꾸지 않는 것이 안전하다.
@@ -0,0 +1,177 @@
┌──────────────────────────┐
│Stage 1 -- Part 1 │
│Improvement Strategy │
│Claud vs Codex │
│--> Perform & Compare │
└──────────────────────────┘
<goal>
Stage 1 Part 1 4개 작업 명세서 yaml 파일을 분석한 두 개 문서 <YAML_Prompts/1. Stage_1/v.6/Part_1_Inefficiency_Report_Codex_v1.md>, <YAML_Prompts/1. Stage_1/v.6/Part_1_Inefficiency_Report_Claude_v1.md>를 비교 분석하여 Stage 1 개정 작업에 가장 적합한 전략 도출
</goal>
<description_of_two_markdown_documents>
<YAML_Prompts/1. Stage_1/v.6/Part_1_Inefficiency_Report_Codex_v1.md>, <YAML_Prompts/1. Stage_1/v.6/Part_1_Inefficiency_Report_Claude_v1.md>는 모두 <YAML_Prompts/1. Stage_1/v.6/Prompt_for_Inefficiency_v1.txt>에 제시된 프롬프트를 사용하여 Stage 1 4개 yaml 파일들의 에이전트 작업 효율성을 분석한 문서들이다.
</description_of_two_markdown_documents>
<what_to_read>
<Part_1_Inefficiency_Report_Codex_v1.md>에서 읽고 숙지해야 할 section 및 sub-section들:
2. 현재 Part 1 실행 구조
3. 실측 fan-in과 중복량
4. 실제 결과에서 확인된 품질 결함
5. 두 gate의 작업별 필요성 판정
- 5.1 B1 gate
- 5.2 B2 gate
6. Downstream 연계성과 삭제 안전성
7. 권고 개정안: 최소 변경, 최대 효과
- 7.1 설계 원칙
- 7.2 기존 task를 최대한 재사용하는 개정
8. 개정 DAG
9. 모델 경량화 판단
10. 즉시 적용할 핫픽스
11. 삭제·유지 최종 판정
13. 최종 권고
<Part_1_Inefficiency_Report_Claude_v1.md>에서 읽고 숙지해야 할 section 및 sub-section들:
2. 두 게이트의 실행 방식 (질문 6에 대한 답)
3. 질문 7에 대한 답: "모아서 한 번에 넘기는" 것이 런타임을 증폭시키는가?
4. 10개 검증 항목의 성격 분류 — 무엇이 정말 LLM을 필요로 하는가
5. 실행 결과가 실증한 품질 결함 — LLM-writer 구조의 직접 비용
6. 삭제·축소 안전성 판정 (질문 5에 대한 답 — 하류 연계 근거)
- 6.1 절대 보존해야 할 인터페이스 (하류 소비 실증)
- 6.2 삭제해도 안전한 작업 (근거 포함)
- 6.3 삭제하면 안 되는 것
7. 개정 전략
- 7.1 권장안 A — 게이트 분해: "결정적 통합기 + 조건부 국소 판정" (Part 3/4 검증 패턴 이식)
- 7.3 이행 순서 및 검증 계획
- 7.2 대안 B — 구조 유지 최소 개정 (권장하지 않음, 비교용): skip reading this subsection and do not consider it for any valuable information
</what_to_read>
<method>
1. <what_to_read>에 제시된 내용을 충실하게 준수하여, 두 개 마크다운 문서에서 필요 section & sub-section들을 읽고 숙지한다.
2. 1번 작업에서 구축한 내용에 기반을 두고, 두 개 markdown 문서를 비교 분석하여 Stage 1 작업의 효율성을 증대시키는 데 가장 필요한 작업들을 선별한다. 선별 기준은 최소의 노력(LLM 추론 작업은 꼭 필요한 곳에만 필요한 수준으로 사용, 100% deterministic task는 python code화, 토큰 경제성을 최대화)으로 최대의 효과(최고 품질 유지, 토큰 경제성 증대, 에이전트 속도 최대화)를 이룩하는 것이다.
3. 2번 작업 결과물을 <YAML_Prompts/1. Stage_1/v.6/Part_1_Improvement_Codex_v1.md>로 생성하고 저장한다.
</method>
=================================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 1 │
│Improvement Strategy Doc │
└──────────────────────────┘
<goal>
Stage 1 Part 1 yaml 작업 명세서 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml>를 개정하는 데 사용할 개정 작업 명세서 작성
</goal>
<method>
<YAML_Prompts/1. Stage_1/v.6/Part_1_Improvement_Claude_v1.md> 내용으로부터 기존 Stage 1 Part 1 yaml 작업 명세서인 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml>를 개정할 전략서를 작성한다.
전략서는 "20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점"에서 LLM이 읽고 정확하게 이해한 후, 100% 작업을 수행할 수 있는 작업 명세서로 작성한다.
작성한 작업 명세서는 <YAML_Prompts/1. Stage_1/v.6/Part_1_Improvement_Strategy_Claude_v1.md>로 생성하고 저장한다.
</method>
=================================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 1 │
│Update YAML to v3 │
└──────────────────────────┘
<goal>
기존 Stage 1 Part 1 작업명세서 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml>를 개정하여 v3 yaml 파일을 작성한다.
</goal>
<method>
1. <YAML_Prompts/1. Stage_1/v.6/Part_1_Improvement_Strategy_Claude_v1.md>를 읽고, 개정 작업 과정을 숙지한다.
2. <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml>를 복제하여 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_Claude_v3.yml>를 생성한다.
3. <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_Claude_v3.yml>에 1번 작업에서 숙지한 개정 작업과정을 정확하게 적용하여 v3.yml을 작성한다.
4. 3번 작업에서 작성한 v3.yml이 1번 작업의 개정 작업 과정을 100% 동일하게 수행했는지, 기존 v2.yml 작업 명세의 작업 목표를 최고 수준에서 달성하는지 두 가지를 "20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점"에서 엄격하게 평가한다.
5. 4번 과정의 평가를 통과할 때까지 v3.yml을 재작성한다.
6. 평가를 통과한 v3.yml을 overwrite하여 저장한다.
</method>
=================================================================================================================
@@ -0,0 +1,227 @@
Prompt for Improving Stage 1 Part 2
---------------------------------------------------------------------------------------------------------
<context>
Stage 1 4개 yaml 작업 명세서 4개
1) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml>
2) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>
3) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>
4) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>
를 Liti-agent를 통해 순차적으로 실행하였다.
순차 실행 후 얻은 결과물은 <YAML_Prompts/1. Stage_1/v.6/Results_July_10_3_15pm> 폴더에 저장되어 있다.
에이전트가 stage 1 4개 yaml 파일들을 실행했을 때의 런타임(run-time)과 cost는 아래와 같다:
{{
* Stage 1 Part 1
런타임: 8min 45sec
비용: $2.09
* Stage 1 Part 2
런타임: 7min 40sec
비용: $4.28
* Stage 1 Part 3
런타임: 3min 40sec
비용: $0
* Stage 1 Part 4
런타임: 3min 6sec
비용: $0.58
}}
Stage 1 yaml 개정 전 작업 명세
- <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_1.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_2.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_3.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_4.yml>
을 실행했을 때보다 런타임은 더 길어졌고, 비용도 더 상승했다.
그래서 Stage 1 yaml 작업 명세서 중 Part 2를 지금보다도 훨씬 더 최적화(필요 작업만 남기고 군더더기 작업들을 없애는 경량화 / 최고 품질의 추론이 필요 없을 때는 약간 낮은 성능의 LLM을 사용하여 추론 시간 단축 등)하려고 한다.
Stage 1 Part 1은 이미 최적화 작업을 마치고 yaml 작업 명세를 업데이트하였다. 업데이트한 Part 1 작업 명세서는 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_Claude_v3.yml>이며, 이 yaml 파일은 <YAML_Prompts/1. Stage_1/v.6/Part_1_Improvement_Strategy_Claude_v1.md>의 개정 작업 명세서를 반영하여 작성된 것이다.
</context>
<goal>
Stage 1 Part 2 작업의 비효율성을 검토하고, 작업 효율성을 최적화하는 개정 방안(혹은 전략)을 작성한다.
</goal>
<method>
0. <context>에 제시된 v.6 폴더의 Stage 1 작업 명세서 4개를 모두 읽고, 세부 작업 내용을 숙지한다.
1. 0번 작업 시 Part 1 작업 명세서는 Stage_1_Part_1_Claude_v3.yml를 읽는다. 즉,
1) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_Claude_v3.yml>
2) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>
3) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>
4) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>
를 읽고 Stage 1 전체 작업 명세를 숙지한다.
2. <context>에 제시된 <v.6/Results_July_10_3_15pm> 폴더에 있는 Stage 1 실행 결과물들을 파악한다.
3. Stage 1 Part 2 yaml 파일(<YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>)에 제시된 작업 명세를 정확하고 심도 깊게 이해하고,
4. Part 2 작업들의 비효율성(토큰 비경제성, LLM 추론 작업 비효율성, DAG workflow 비효율성 등)을 파악한다.
5. 4번 작업에서 파악한 Part 2 작업 명세의 비효율성을 효율화 할 수 있는 방안을 작성한다.
6. 1~5까지의 작업을 마친 후 결과 보고서를 <YAML_Prompts/1. Stage_1/v.6/Part_2_Inefficiency_Report_Claude_v1.md>로 생성하고 저장한다.
</method>
=========================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 2 │
│Improvement Strategy │
│Claud vs Codex │
│--> Ensemble │
└──────────────────────────┘
<goal>
Stage 1 Part 2 작업 명세서 yaml 파일을 분석한 두 개 문서 <YAML_Prompts/1. Stage_1/v.6/Part_2_Inefficiency_Report_Claude_v1.md>, <YAML_Prompts/1. Stage_1/v.6/Part_2_Inefficiency_Report_Codex_v1.md>를 비교 분석하여 Stage 1 Part 2 개정 작업에 가장 적합한 전략 도출
</goal>
<how_to_read>
<Part_2_Inefficiency_Report_Claude_v1.md>와 <Part_2_Inefficiency_Report_Codex_v1.md>를 다음 항목들에 집중하여 비교 분석한다:
- Part 2 비효율 판정 항목들
- Part 2 실행구조와 병목 발생 지점
- 삭제/축소 안정성 판정(downstream 작업 연계 근거)
- 권장 개정 전략
</how_to_read>
<method>
1. <how_to_read> 작업을 통해 구축한 비교 분석 내용에 근거하여,
2. Stage 2 작업의 효율성을 증대시키는 데 가장 필요한 작업들을 선별한다. 선별 기준은 최소의 노력(LLM 추론 작업은 꼭 필요한 곳에만 필요한 수준으로 사용, 100% deterministic task는 python code화, 토큰 경제성을 최대화)으로 최대의 효과(최고 품질 유지, 토큰 경제성 증대, 에이전트 속도 최대화)를 이룩하는 것이다.
3. 2번 작업 결과물을 <YAML_Prompts/1. Stage_1/v.6/Part_2_Improvement_Codex_v1.md>로 생성하고 저장한다.
</method>
=================================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 2 │
│Improvement Strategy Doc │
└──────────────────────────┘
<goal>
기존 Stage 1 Part 2 yaml 작업 명세서 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>를 개정하는 데 사용할 "개정 작업 명세서" 작성
</goal>
<method>
<YAML_Prompts/1. Stage_1/v.6/Part_2_Improvement_Claude_v1.md> 내용으로부터 기존 Stage 1 Part 2 yaml 작업 명세서인 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>를 개정할 전략서를 작성한다.
전략서는 "20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점"에서 LLM이 읽고 정확하게 이해한 후, 100% 작업을 수행할 수 있는 작업 명세서로 작성한다.
작성한 작업 명세서는 <YAML_Prompts/1. Stage_1/v.6/Part_2_Improvement_Strategy_Claude_v1.md>로 생성하고 저장한다.
</method>
=================================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 2 │
│Update YAML to v3 │
└──────────────────────────┘
<goal>
기존 Stage 1 Part 2 작업명세서 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>를 개정하여 v3 yaml 파일을 작성한다.
</goal>
<method>
1. <YAML_Prompts/1. Stage_1/v.6/Part_2_Improvement_Strategy_Codex_v1.md>를 읽고, 개정 작업 과정을 숙지한다.
2. <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>를 복제하여 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_Codex_v3.yml>를 생성한다.
3. <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_Codex_v3.yml>에 1번 작업에서 숙지한 개정 작업과정을 정확하게 적용하여 v3.yml을 작성한다. 작성 시, LLM 추론 작업 task는 모두 동일한 common cache prefix를 사용해야 하고, python code 작업은 <YAML_Prompts/1. Stage_1/SKILL.md>가 제시하는 python code 작성 제약을 100% 준수하도록 한다.
4. 3번 작업에서 작성한 v3.yml이 1번 작업의 개정 작업 과정을 100% 동일하게 수행했는지, 기존 v2.yml 작업 명세의 작업 목표를 최고 수준에서 달성하는지, LLM 추론 작업에서 동일한 common cache prefix를 사용하는지, python code 작업 시 <YAML_Prompts/1. Stage_1/SKILL.md>가 제시하는 python code 작성 제약을 100% 준수하는지 네 가지를 "20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점"에서 엄격하게 평가한다.
5. 4번 과정의 평가를 통과할 때까지 v3.yml을 재작성한다.
6. 평가를 통과한 v3.yml을 overwrite하여 저장한다.
</method>
@@ -0,0 +1,182 @@
---------------------------------------------------------------------------------------------------------
<context>
Stage 1 4개 yaml 작업 명세서 4개
1) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml>
2) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>
3) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>
4) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>
를 Liti-agent를 통해 순차적으로 실행하였다.
순차 실행 후 얻은 결과물은 <YAML_Prompts/1. Stage_1/v.6/Results_July_10_3_15pm> 폴더에 저장되어 있다.
에이전트가 stage 1 4개 yaml 파일들을 실행했을 때의 런타임(run-time)과 cost는 아래와 같다:
{{
* Stage 1 Part 1
런타임: 8min 45sec
비용: $2.09
* Stage 1 Part 2
런타임: 7min 40sec
비용: $4.28
* Stage 1 Part 3
런타임: 3min 40sec
비용: $0
* Stage 1 Part 4
런타임: 3min 6sec
비용: $0.58
}}
Stage 1 yaml 개정 전 작업 명세
- <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_1.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_2.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_3.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_4.yml>
을 실행했을 때보다 런타임은 더 길어졌고, 비용도 더 상승했다.
그래서 Stage 1 yaml 작업 명세서 중 Part 2를 지금보다도 훨씬 더 최적화(필요 작업만 남기고 군더더기 작업들을 없애는 경량화 / 최고 품질의 추론이 필요 없을 때는 약간 낮은 성능의 LLM을 사용하여 추론 시간 단축 등)하려고 한다.
Stage 1 Part 1과 2는 이미 최적화 작업을 마치고 yaml 작업 명세를 업데이트하였다. 업데이트한 Part 1 작업 명세서는 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_Claude_v3.yml>, <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_Claude_v3.yml>이며, 이 yaml 파일은 <YAML_Prompts/1. Stage_1/v.6/Part_1_Improvement_Strategy_Claude_v1.md>와 <YAML_Prompts/1. Stage_1/v.6/Part_2_Improvement_Strategy_Claude_v1.md>의 개정 작업 명세서를 각각 반영하여 작성된 것이다.
</context>
<goal>
Stage 1 Part 3 작업의 비효율성을 검토하고, 작업 효율성을 최적화하는 개정 방안(혹은 전략)을 작성한다.
</goal>
<method>
0. <context>에 제시된 v.6 폴더의 Stage 1 작업 명세서 4개를 모두 읽고, 세부 작업 내용을 숙지한다:
1) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_Claude_v3.yml>
2) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_Claude_v3.yml>
3) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>
4) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>
를 읽고 Stage 1 전체 작업 명세를 숙지한다.
2. <context>에 제시된 <v.6/Results_July_10_3_15pm> 폴더에 있는 Stage 1 실행 결과물들을 파악한다.
3. Stage 1 Part 3 yaml 파일(<YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>)에 제시된 작업 명세를 정확하고 심도 깊게 이해하고,
4. Part 3 작업들의 비효율성(토큰 비경제성, LLM 추론 작업 비효율성, DAG workflow 비효율성 등)을 파악하여 체계적으로 서술한다.
5. 4번 작업에서 파악한 Part 3 작업 명세의 비효율성을 효율화 할 수 있는 방안을 작성한다. 효율화 방식은 최소한의 작업으로 최대한의 효과를 거둘 수 있는 방식이어야 한다.
6. 1~5까지의 작업을 마친 후 결과 보고서를 <YAML_Prompts/1. Stage_1/v.6/Part_3_Inefficiency_Report_Claude_v1.md>로 생성하고 저장한다.
</method>
=========================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 3 │
│Improvement Strategy │
│Claud vs Codex │
│--> Ensemble │
└──────────────────────────┘
<goal>
Stage 1 Part 3 작업 명세서 yaml 파일의 비효율성 및 개선 방안을 분석한 두 개 문서 <YAML_Prompts/1. Stage_1/v.6/Part_3_Inefficiency_Report_Claude_v1.md>, <YAML_Prompts/1. Stage_1/v.6/Part_3_Inefficiency_Report_Codex_v1.md>를 비교 분석하여 Stage 1 Part 3 개정 작업에 가장 적합한 전략 도출
</goal>
<how_to_read>
<Part_3_Inefficiency_Report_Claude_v1.md>와 <Part_3_Inefficiency_Report_Codex_v1.md>를 다음 항목들에 집중하여 비교 분석한다:
- Part 3 비효율 판정 항목들
- Part 3 실행구조와 병목 발생 지점
- 삭제/축소 안정성 판정(downstream 작업 연계 근거)
- 권장 개정 전략
</how_to_read>
<method>
1. <how_to_read> 작업을 통해 구축한 비교 분석 내용에 근거하여,
2. Stage 1 Part 3 작업의 효율성을 증대시키는 데 가장 필요한 작업들을 선별한다. 선별 기준은 최소의 노력(LLM 추론 작업은 꼭 필요한 곳에만 필요한 수준으로 사용, 100% deterministic task는 python code화, 토큰 경제성을 최대화)으로 최대의 효과(최고 품질 유지, 토큰 경제성 증대, 에이전트 속도 최대화)를 이룩하는 것이다.
3. 2번 작업 결과물을 <YAML_Prompts/1. Stage_1/v.6/Part_3_Improvement_Claude_v1.md>로 생성하고 저장한다.
</method>
=================================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 3 │
│Improvement Strategy Doc │
└──────────────────────────┘
<goal>
기존 Stage 1 Part 3 yaml 작업 명세서 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>를 개정하는 데 사용할 "개정 작업 명세서" 작성
</goal>
<method>
<YAML_Prompts/1. Stage_1/v.6/Part_3_Improvement_Claude_v1.md> 내용으로부터 기존 Stage 1 Part 3 yaml 작업 명세서인 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>를 개정할 전략서를 작성한다.
전략서는 "20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점"에서 LLM이 읽고 정확하게 이해한 후, 100% 작업을 수행할 수 있는 작업 명세서로 작성한다.
작성한 작업 명세서는 <YAML_Prompts/1. Stage_1/v.6/Part_3_Improvement_Strategy_Claude_v1.md>로 생성하고 저장한다.
</method>
=================================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 3 │
│Update YAML to v2 │
└──────────────────────────┘
<goal>
기존 Stage 1 Part 3 작업명세서 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>를 개정하여 v2 yaml 파일을 작성한다.
</goal>
<method>
1. <YAML_Prompts/1. Stage_1/v.6/Part_3_Improvement_Strategy_Codex_v1.md>를 읽고, 개정 작업 과정을 숙지한다.
2. <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>를 복제하여 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_Codex_v2.yml>를 생성한다.
3. <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_Codex_v2.yml>에 1번 작업에서 숙지한 개정 작업과정을 정확하게 적용하여 v2.yml을 개정 작성한다. 작성 시, LLM 추론 작업 task는 모두 동일한 common cache prefix를 사용해야 하고, python code 작업은 <YAML_Prompts/1. Stage_1/SKILL.md>가 제시하는 python code 작성 제약을 100% 준수하도록 한다.
4. 3번 작업에서 작성한 v2.yml이 1번의 개정 작업 과정을 100% 동일하게 수행했는지, 기존 v1.yml 작업 명세의 작업 목표를 최고 수준에서 달성하는지, LLM 추론 작업에서 동일한 common cache prefix를 사용하는지, python code 작업 시 <YAML_Prompts/1. Stage_1/SKILL.md>가 제시하는 python code 작성 제약을 100% 준수하는지 네 가지를 "20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점"에서 엄격하게 평가한다.
5. 4번 과정의 평가를 통과할 때까지 v2.yml을 재작성한다.
6. 평가를 통과한 v2.yml을 overwrite하여 저장한다.
</method>
@@ -0,0 +1,191 @@
<context>
Stage 1 4개 yaml 작업 명세서 4개
1) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml>
2) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>
3) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>
4) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>
를 Liti-agent를 통해 순차적으로 실행하였다.
순차 실행 후 얻은 결과물은 <YAML_Prompts/1. Stage_1/v.6/Results_July_10_3_15pm> 폴더에 저장되어 있다.
에이전트가 stage 1 4개 yaml 파일들을 실행했을 때의 런타임(run-time)과 cost는 아래와 같다:
{{
* Stage 1 Part 1
런타임: 8min 45sec
비용: $2.09
* Stage 1 Part 2
런타임: 7min 40sec
비용: $4.28
* Stage 1 Part 3
런타임: 3min 40sec
비용: $0
* Stage 1 Part 4
런타임: 3min 6sec
비용: $0.58
}}
Stage 1 yaml 개정 전 작업 명세
- <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_1.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_2.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_3.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_4.yml>
을 실행했을 때보다 런타임은 더 길어졌고, 비용도 더 상승했다.
Stage 1 yaml 작업 명세서 중 Part 4를 지금보다도 훨씬 더 최적화(필요 작업만 남기고 군더더기 작업들을 없애는 경량화 / 최고 품질의 추론이 필요 없을 때는 약간 낮은 성능의 LLM을 사용하여 추론 시간 단축 등)하려고 한다.
Stage 1 Part 1, 2, 3은 이미 최적화 작업을 마치고 yaml 작업 명세를 업데이트하였다. 업데이트한 Part 1 작업 명세서는 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_Codex_v3.yml>, <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_Codex_v3.yml>, <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_Codex_v2.yml>이며, 이 yaml 파일은 <YAML_Prompts/1. Stage_1/v.6/Part_1_Improvement_Strategy_Codex_v1.md>와 <YAML_Prompts/1. Stage_1/v.6/Part_2_Improvement_Strategy_Codex_v1.md>, <YAML_Prompts/1. Stage_1/v.6/Part_3_Improvement_Strategy_Codex_v1.md>의 개정 작업 명세서를 각각 반영하여 작성된 것이다.
</context>
<goal>
Stage 1 Part 4 작업의 비효율성이 초래되는 원인을 식별하고, 작업 효율성을 최적화하는 개정 방안(혹은 전략)을 작성한다.
</goal>
<method>
0. <context>에 제시된 v.6 폴더의 Stage 1 작업 명세서 4개를 모두 읽고, 세부 작업 내용을 숙지한다:
1) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_Codex_v3.yml>
2) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_Codex_v3.yml>
3) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_Codex_v2.yml>
4) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>
를 읽고 Stage 1 전체 작업 명세를 숙지한다.
2. <context>에 제시된 <v.6/Results_July_10_3_15pm> 폴더에 있는 Stage 1 실행 결과물들을 파악한다.
3. Stage 1 Part 4 yaml 파일(<YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>)에 제시된 작업 명세를 정확하고 심도 깊게 이해하고,
4. Part 4 작업들의 비효율성(토큰 비경제성, LLM 추론 작업 비효율성, DAG workflow 비효율성 등)을 식별하여 체계적으로 서술한다.
5. 4번 작업에서 파악한 Part 4 작업 명세의 비효율성을 효율화 할 수 있는 방안을 작성한다. 효율화 방식은 최소한의 작업으로 최대한의 효과를 거둘 수 있는 방식이어야 한다.
6. 1~5까지의 작업을 마친 후 결과 보고서를 <YAML_Prompts/1. Stage_1/v.6/Part_4_Inefficiency_Report_Codex_v1.md>로 생성하고 저장한다.
</method>
=========================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 4 │
│Improvement Strategy │
│Claud vs Codex │
│--> Ensemble │
└──────────────────────────┘
<goal>
Stage 1 Part 4 작업 명세서 yaml 파일의 비효율성 및 개선 방안을 분석한 두 개 문서 <YAML_Prompts/1. Stage_1/v.6/Part_4_Inefficiency_Report_Claude_v1.md>, <YAML_Prompts/1. Stage_1/v.6/Part_4_Inefficiency_Report_Codex_v1.md>를 비교 분석하여 Stage 1 Part 4 개정 작업에 가장 적합한 전략 도출
</goal>
<how_to_read>
<Part_4_Inefficiency_Report_Claude_v1.md>와 <Part_4_Inefficiency_Report_Codex_v1.md>를 다음 항목들에 집중하여 비교 분석한다:
- Part 4 비효율 판정 항목들
- Part 4 실행구조와 병목 발생 지점
- 삭제/축소 안정성 판정(downstream 작업 연계 근거)
- 권장 개정 전략
</how_to_read>
<method>
1. <how_to_read> 작업을 통해 구축한 비교 분석 내용에 근거하여,
2. Stage 1 Part 4 작업의 효율성을 증대시키는 데 가장 필요한 작업들을 선별한다. 선별 기준은 최소의 노력(LLM 추론 작업은 꼭 필요한 곳에만 필요한 수준으로 사용, 100% deterministic task는 python code화, 토큰 경제성을 최대화)으로 최대의 효과(최고 품질 유지, 토큰 경제성 증대, 에이전트 속도 최대화)를 이룩하는 것이다.
3. 2번 작업 결과물을 <YAML_Prompts/1. Stage_1/v.6/Part_4_Improvement_Claude_v1.md>로 생성하고 저장한다.
</method>
=================================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 4 │
│Improvement Strategy Doc │
└──────────────────────────┘
<goal>
기존 Stage 1 Part 4 yaml 작업 명세서 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>를 개정하는 데 사용할 "개정 작업 명세서" 작성
</goal>
<method>
<YAML_Prompts/1. Stage_1/v.6/Part_4_Improvement_Claude_v1.md> 내용으로부터 기존 Stage 1 Part 4 yaml 작업 명세서인 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>를 개정할 전략서를 작성한다.
전략서는 "20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점"에서 LLM이 읽고 정확하게 이해한 후, 100% 작업을 수행할 수 있는 작업 명세서로 작성한다.
작성한 작업 명세서는 <YAML_Prompts/1. Stage_1/v.6/Part_4_Improvement_Strategy_Claude_v1.md>로 생성하고 저장한다.
</method>
=================================================================================================================
┌──────────────────────────┐
│Stage 1 -- Part 4 │
│Update YAML to v3 │
└──────────────────────────┘
<goal>
기존 Stage 1 Part 4 작업명세서 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>를 개정하여 v3 yaml 파일을 작성한다.
</goal>
<method>
1. <YAML_Prompts/1. Stage_1/v.6/Part_4_Improvement_Strategy_Codex_v1.md>를 읽고, 개정 작업 과정을 숙지한다.
2. <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>를 복제하여 <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_Codex_v3.yml>를 생성한다.
3. <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_Codex_v3.yml>에 1번 작업에서 숙지한 개정 작업과정을 정확하게 적용하여 v3.yml을 개정 작성한다. 작성 시, LLM 추론 작업 task는 모두 동일한 common cache prefix를 사용해야 하고, python code 작업은 <YAML_Prompts/1. Stage_1/SKILL.md>가 제시하는 python code 작성 제약을 100% 준수하도록 한다.
4. 3번 작업에서 작성한 v3.yml이 1번의 개정 작업 과정을 100% 동일하게 수행했는지, 기존 v2.yml 작업 명세의 작업 목표를 최고 수준에서 달성하는지, LLM 추론 작업에서 동일한 common cache prefix를 사용하는지, python code 작업 시 <YAML_Prompts/1. Stage_1/SKILL.md>가 제시하는 python code 작성 제약을 100% 준수하는지 네 가지를 "20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점"에서 엄격하게 평가한다.
5. 4번 과정의 평가를 통과할 때까지 v3.yml을 재작성한다.
6. 평가를 통과한 v3.yml을 overwrite하여 저장한다.
</method>
@@ -0,0 +1,50 @@
<context>
Stage 1 4개 yaml 작업 명세서 4개
1) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_1_v2.yml>
2) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_2_v2.yml>
3) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_3_v1.yml>
4) <YAML_Prompts/1. Stage_1/v.6/Stage_1_Part_4_v2.yml>
를 Liti-agent를 통해 순차적으로 실행하였다.
순차 실행 후 얻은 결과물은 <YAML_Prompts/1. Stage_1/v.6/Results_July_10_3_15pm> 폴더에 저장되어 있다.
에이전트가 stage 1 4개 yaml 파일들을 실행했을 때의 런타임(run-time)과 cost는 아래와 같다:
{{
* Stage 1 Part 1
런타임: 8min 45sec
비용: $2.09
* Stage 1 Part 2
런타임: 7min 40sec
비용: $4.28
* Stage 1 Part 3
런타임: 3min 40sec
비용: $0
* Stage 1 Part 4
런타임: 3min 6sec
비용: $0.58
}}
Stage 1 yaml 개정 전 작업 명세
- <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_1.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_2.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_3.yml> - <YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_4.yml>
을 실행했을 때보다 런타임은 더 길어졌고, 비용도 더 상승했다.
그래서 Stage 1 yaml 작업 명세서를 지금보다도 훨씬 더 최적화(필요 작업만 남기고 군더더기 작업들을 없애는 경량화 / 최고 품질의 추론이 필요 없을 때는 약간 낮은 성능의 LLM을 사용하여 추론 시간 단축 등)하려고 한다.
</context>
<goal>
Stage 1 Part 1에서 "B2_quality_gate_event_indexed"와 "B2_quality_gate_event_candidates" 작업들을 최적화하는 개정 방안(혹은 전략)을 작성한다.
</goal>
<method>
1. <context>에 제시된 v.6 폴더의 Stage 1 작업 명세서 4개를 모두 읽고, 세부 작업 내용을 숙지한다.
2. <context>에 제시된 <v.6/Results_July_10_3_15pm> 폴더에 있는 Stage 1 실행 결과물들을 파악한다.
3. Stage 1 Part 1 yaml 파일을 정확하고 심도 깊게 이해하고,
4. "B2_quality_gate_event_indexed"와 "B2_quality_gate_event_candidates" 작업들 내용을 파악하고,
5. 두 개 sub-task들의 downstream 작업과의 연계성을 감안하여, 반드시 필요하지 않은 작업들을 파악하고 그것들을 삭제해도 문제가 없는지 판단한다.
6. 특히, "B2_quality_gate_event_indexed" 작업 후 "B2_quality_gate_event_candidates" 작업이 어떻게 실행되는지 파악하여,
7. 두 개 작업 중 선행 작업의 개별 작업들의 결과물들을 모두 모아서 후행 작업들에 한 번에 넘겨줘서 런타임을 증폭시키는 비효율성이 초래되는지, 아니면 어떤 비효율성이 존재하는지 파악한다.
8. 1~7까지의 작업을 마친 후 결과 보고서를 <YAML_Prompts/1. Stage_1/v.6/Part_1_Inefficiency_Report_###_v1.md>로 생성하고 저장한다. (### = Codex | Clause)
</method>
@@ -0,0 +1,367 @@
{
"schema_version": "actio_case_signals.v1",
"status": "READY_WITH_REVIEW",
"actio_case_signals": [
{
"signal_id": "actio-signal-001",
"actio_scope": [
"preserved_claim"
],
"suspicion_level": "LOW",
"suspicion_reasons": "피보전채권 후보가 B4 seed/domain payload에서 확인됨",
"related_bo_ids": [
"bh28"
],
"related_evidence_indexes": [
"E-024"
],
"target_property_candidates": [],
"preserved_claim_candidates": [
{
"bo_id": null,
"claim_type_candidate": null,
"creditor_candidate": null,
"debtor_candidate": null,
"claim_date_candidate": null,
"related_evidence_indexes": [
"E-024"
]
}
],
"actio_role_hints": [
{
"role": "debtor_act",
"value_candidate": "강용원이 오국한에게 합계 2억원을 대여하여 사해행위취소소송의 피보전채권 발생",
"date_candidate": null,
"related_bo_ids": [
"bh28"
],
"related_evidence_indexes": [
"E-024"
]
}
]
},
{
"signal_id": "actio-signal-002",
"actio_scope": [
"fraudulent_act",
"beneficiary_or_transferee",
"target_asset"
],
"suspicion_level": "LOW",
"suspicion_reasons": "채무자 처분행위 또는 사해행위 후보 사실이 확인됨, 수익자 또는 전득자 후보가 확인됨, 취소·원상회복 대상 재산 후보가 확인됨",
"related_bo_ids": [
"bh27"
],
"related_evidence_indexes": [
"E-014"
],
"target_property_candidates": [
{
"asset_label": "신림동 상가",
"asset_kind": "unknown",
"related_bo_ids": [
"bh27"
],
"related_evidence_indexes": [
"E-014"
]
}
],
"preserved_claim_candidates": [
{
"bo_id": "bh27",
"claim_type_candidate": null,
"creditor_candidate": null,
"debtor_candidate": null,
"claim_date_candidate": null,
"related_evidence_indexes": [
"E-014"
]
}
],
"actio_role_hints": [
{
"role": "beneficiary",
"value_candidate": "{}",
"date_candidate": null,
"related_bo_ids": [
"bh27"
],
"related_evidence_indexes": [
"E-014"
]
}
]
},
{
"signal_id": "actio-signal-003",
"actio_scope": [
"target_asset"
],
"suspicion_level": "LOW",
"suspicion_reasons": "취소·원상회복 대상 재산 후보가 확인됨",
"related_bo_ids": [
"bh30"
],
"related_evidence_indexes": [
"E-004"
],
"target_property_candidates": [
{
"asset_label": "신림동 상가",
"asset_kind": "unknown",
"related_bo_ids": [
"bh30"
],
"related_evidence_indexes": [
"E-004"
]
},
{
"asset_label": "포천시 임야",
"asset_kind": "unknown",
"related_bo_ids": [
"bh30"
],
"related_evidence_indexes": [
"E-004"
]
}
],
"preserved_claim_candidates": [
{
"bo_id": "bh30",
"claim_type_candidate": null,
"creditor_candidate": null,
"debtor_candidate": null,
"claim_date_candidate": null,
"related_evidence_indexes": [
"E-004"
]
}
],
"actio_role_hints": [
{
"role": "debtor_act",
"value_candidate": "사해행위 당시 채무자 오국한의 무자력 상태 및 책임재산 보유 현황 (신림동 상가, 포천시 임야 등)",
"date_candidate": null,
"related_bo_ids": [
"bh30"
],
"related_evidence_indexes": [
"E-004"
]
}
]
},
{
"signal_id": "actio-signal-004",
"actio_scope": [
"target_asset",
"encumbrance",
"remedy_or_cap"
],
"suspicion_level": "LOW",
"suspicion_reasons": "취소·원상회복 대상 재산 후보가 확인됨, 담보권·가압류 등 부담 관련 단서가 확인됨, 원상회복 방법 또는 가액배상 한도 단서가 확인됨",
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
],
"target_property_candidates": [
{
"asset_label": "신림동 상가",
"asset_kind": "unknown",
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
]
},
{
"asset_label": "2021-08-01",
"asset_kind": "unknown",
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
]
},
{
"asset_label": "2022-04-18",
"asset_kind": "unknown",
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
]
},
{
"asset_label": "2024-10-17",
"asset_kind": "unknown",
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
]
}
],
"preserved_claim_candidates": [
{
"bo_id": "bh29",
"claim_type_candidate": null,
"creditor_candidate": null,
"debtor_candidate": null,
"claim_date_candidate": null,
"related_evidence_indexes": [
"E-014"
]
}
],
"actio_role_hints": [
{
"role": "remedy_or_cap",
"value_candidate": "원물반환 불가",
"date_candidate": null,
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
]
},
{
"role": "remedy_or_cap",
"value_candidate": "가액배상",
"date_candidate": null,
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
]
},
{
"role": "encumbrance",
"value_candidate": "{'date': '2021-08-01', 'event': '나임오 1번 근저당 설정(5000만원)'}",
"date_candidate": "2021-08-01",
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
]
},
{
"role": "encumbrance",
"value_candidate": "{'date': '2022-04-18', 'event': '강용일 2번 근저당 설정(1.5억원)'}",
"date_candidate": "2022-04-18",
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
]
},
{
"role": "encumbrance",
"value_candidate": "{'date': '2024-10-17', 'event': '강용일 2번 근저당 말소(오민한 대위변제)'}",
"date_candidate": "2024-10-17",
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
]
}
]
},
{
"signal_id": "actio-signal-005",
"actio_scope": [
"target_asset",
"defense"
],
"suspicion_level": "LOW",
"suspicion_reasons": "취소·원상회복 대상 재산 후보가 확인됨, 항변 또는 선의·악의 관련 반박 단서가 확인됨",
"related_bo_ids": [
"bh31"
],
"related_evidence_indexes": [
"E-003",
"E-010"
],
"target_property_candidates": [
{
"asset_label": "신림동 상가",
"asset_kind": "unknown",
"related_bo_ids": [
"bh31"
],
"related_evidence_indexes": [
"E-003",
"E-010"
]
}
],
"preserved_claim_candidates": [
{
"bo_id": "bh31",
"claim_type_candidate": null,
"creditor_candidate": null,
"debtor_candidate": null,
"claim_date_candidate": null,
"related_evidence_indexes": [
"E-003",
"E-010"
]
}
],
"actio_role_hints": [
{
"role": "defense",
"value_candidate": "{'defense_type': '계약명의신탁', 'content': '오국한 명의 취득이 수익자 자금에 의한 계약명의신탁이므로 사해행위가 아니라는 주장'}",
"date_candidate": null,
"related_bo_ids": [
"bh31"
],
"related_evidence_indexes": [
"E-003",
"E-010"
]
},
{
"role": "defense",
"value_candidate": "{'defense_type': '배상금감액', 'content': '수익자가 제공한 매수자금 4000만원 및 대여금 1000만원 참작 주장'}",
"date_candidate": null,
"related_bo_ids": [
"bh31"
],
"related_evidence_indexes": [
"E-003",
"E-010"
]
},
{
"role": "defense",
"value_candidate": "{'defense_type': '상계항변', 'content': '오민한의 5000만원 채권으로 강용원 채권을 상계한다는 주장'}",
"date_candidate": null,
"related_bo_ids": [
"bh31"
],
"related_evidence_indexes": [
"E-003",
"E-010"
]
}
]
}
]
}
@@ -0,0 +1,669 @@
{
"schema_version": "case_liability_signals.v1",
"status": "READY_WITH_REVIEW",
"case_liability_signals": [
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh1"
],
"related_evidence_indexes": [
"E-007"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:011",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh2"
],
"related_evidence_indexes": [
"E-021",
"E-027"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:001",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh3"
],
"related_evidence_indexes": [
"E-024"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:006",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh4"
],
"related_evidence_indexes": [
"E-024"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:007",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh5"
],
"related_evidence_indexes": [
"E-025"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:008",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh6"
],
"related_evidence_indexes": [
"E-026"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:009",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh7"
],
"related_evidence_indexes": [
"E-020"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:004",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh8"
],
"related_evidence_indexes": [
"E-021"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:002",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh9"
],
"related_evidence_indexes": [],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:010",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh10"
],
"related_evidence_indexes": [
"E-003",
"E-010"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:013",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh11"
],
"related_evidence_indexes": [
"E-027"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:003",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh12"
],
"related_evidence_indexes": [
"E-028"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:005",
"linked_structure_ids": []
},
{
"liability_candidate_type": "commercial_successor",
"related_bo_ids": [
"bh13"
],
"related_evidence_indexes": [
"E-011"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B1:012",
"linked_structure_ids": []
},
{
"liability_candidate_type": "secured_debt",
"related_bo_ids": [
"bh14"
],
"related_evidence_indexes": [
"E-013",
"E-025",
"E-026"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B2:001",
"linked_structure_ids": []
},
{
"liability_candidate_type": "registry_invalidity",
"related_bo_ids": [
"bh15"
],
"related_evidence_indexes": [
"E-010",
"E-014"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B2:004",
"linked_structure_ids": []
},
{
"liability_candidate_type": "secured_debt",
"related_bo_ids": [
"bh16"
],
"related_evidence_indexes": [
"E-015"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B2:006",
"linked_structure_ids": []
},
{
"liability_candidate_type": "registry_invalidity",
"related_bo_ids": [
"bh17"
],
"related_evidence_indexes": [
"E-012",
"E-013"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B2:003",
"linked_structure_ids": []
},
{
"liability_candidate_type": "secured_debt",
"related_bo_ids": [
"bh18"
],
"related_evidence_indexes": [],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B2:002",
"linked_structure_ids": []
},
{
"liability_candidate_type": "money_claim",
"related_bo_ids": [
"bh19"
],
"related_evidence_indexes": [
"E-007",
"E-011"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B2:005",
"linked_structure_ids": []
},
{
"liability_candidate_type": "secured_debt",
"related_bo_ids": [
"bh20"
],
"related_evidence_indexes": [
"E-029"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B2:007",
"linked_structure_ids": []
},
{
"liability_candidate_type": "land_use_gain",
"related_bo_ids": [
"bh21"
],
"related_evidence_indexes": [
"E-005"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B3:002",
"linked_structure_ids": []
},
{
"liability_candidate_type": "land_use_gain",
"related_bo_ids": [
"bh22"
],
"related_evidence_indexes": [
"E-006"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B3:004",
"linked_structure_ids": []
},
{
"liability_candidate_type": "land_use_gain",
"related_bo_ids": [
"bh23"
],
"related_evidence_indexes": [
"E-004"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B3:001",
"linked_structure_ids": []
},
{
"liability_candidate_type": "secured_debt",
"related_bo_ids": [
"bh24"
],
"related_evidence_indexes": [
"E-011"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B3:005",
"linked_structure_ids": []
},
{
"liability_candidate_type": "land_use_gain",
"related_bo_ids": [
"bh25"
],
"related_evidence_indexes": [
"E-023"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B3:003",
"linked_structure_ids": []
},
{
"liability_candidate_type": "land_use_gain",
"related_bo_ids": [
"bh26"
],
"related_evidence_indexes": [
"E-017",
"E-018",
"E-022"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B3:006",
"linked_structure_ids": []
},
{
"liability_candidate_type": "actio_related",
"related_bo_ids": [
"bh27"
],
"related_evidence_indexes": [
"E-014"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B4:002",
"linked_structure_ids": []
},
{
"liability_candidate_type": "actio_related",
"related_bo_ids": [
"bh28"
],
"related_evidence_indexes": [
"E-024"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B4:001",
"linked_structure_ids": []
},
{
"liability_candidate_type": "actio_related",
"related_bo_ids": [
"bh29"
],
"related_evidence_indexes": [
"E-014"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B4:004",
"linked_structure_ids": []
},
{
"liability_candidate_type": "actio_related",
"related_bo_ids": [
"bh30"
],
"related_evidence_indexes": [
"E-004"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B4:003",
"linked_structure_ids": []
},
{
"liability_candidate_type": "actio_related",
"related_bo_ids": [
"bh31"
],
"related_evidence_indexes": [
"E-003",
"E-010"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B4:005",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh32"
],
"related_evidence_indexes": [
"E-013"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:002",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh33"
],
"related_evidence_indexes": [
"E-001",
"E-002"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:003",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh34"
],
"related_evidence_indexes": [
"E-027"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:009",
"linked_structure_ids": []
},
{
"liability_candidate_type": "actio_related",
"related_bo_ids": [
"bh35"
],
"related_evidence_indexes": [
"E-008",
"E-010"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:004",
"linked_structure_ids": []
},
{
"liability_candidate_type": "secured_debt",
"related_bo_ids": [
"bh36"
],
"related_evidence_indexes": [
"E-011",
"E-019"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:007",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh37"
],
"related_evidence_indexes": [
"E-028"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:010",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh38"
],
"related_evidence_indexes": [
"E-010"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:006",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh39"
],
"related_evidence_indexes": [
"E-009"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:005",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh40"
],
"related_evidence_indexes": [
"E-030"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:012",
"linked_structure_ids": []
},
{
"liability_candidate_type": "money_claim",
"related_bo_ids": [
"bh41"
],
"related_evidence_indexes": [
"E-029"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:011",
"linked_structure_ids": []
},
{
"liability_candidate_type": "registry_invalidity",
"related_bo_ids": [
"bh42"
],
"related_evidence_indexes": [
"E-012"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:008",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh43"
],
"related_evidence_indexes": [
"E-013",
"E-014",
"E-015",
"E-016"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:001",
"linked_structure_ids": []
},
{
"liability_candidate_type": "secured_debt",
"related_bo_ids": [
"bh44"
],
"related_evidence_indexes": [
"E-011"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:013",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh45"
],
"related_evidence_indexes": [
"E-006"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:014",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh46"
],
"related_evidence_indexes": [
"E-018",
"E-022"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:015",
"linked_structure_ids": []
},
{
"liability_candidate_type": "money_claim",
"related_bo_ids": [
"bh47"
],
"related_evidence_indexes": [
"E-010"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:017",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh48"
],
"related_evidence_indexes": [
"E-011"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:018",
"linked_structure_ids": []
},
{
"liability_candidate_type": "succession_related",
"related_bo_ids": [
"bh49"
],
"related_evidence_indexes": [
"E-009"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:016",
"linked_structure_ids": []
},
{
"liability_candidate_type": "registry_invalidity",
"related_bo_ids": [
"bh50"
],
"related_evidence_indexes": [
"E-012"
],
"party_roles": [],
"claim_group_id": null,
"liability_group_id": "B5:019",
"linked_structure_ids": []
}
]
}
@@ -0,0 +1,152 @@
{
"primary_goal": "강용원 및 양정숙의 5개 분쟁군별 채권 실현, 부동산 소유·점유 권리 확인, 점유 해소 및 임대차 관계의 적법성 확인을 위한 소 제기",
"constraints": [
"오국한에 대한 금전대여금 청구 소송 제기 불가"
],
"summary_key_incidents": [
"강용원의 인테리어 자재대금 청구와 오민한의 인수 책임 여부",
"성수동 대지 경매 이후 이문호·박성희의 소유·점유 권리 분쟁",
"신림동 상가에 대한 오국한의 사해행위 및 오민한 명의 등기 분쟁",
"망 강호연 소유 평택시 빌라 유치권 소멸 및 인도 청구",
"양정숙의 흑석동 상가 임차권 적법성 및 윤건우의 매매계약 해제 분쟁"
],
"key_facts": [
"강용원-김선웅 간 2억 원 자재 매매 및 오민한의 사업 인수",
"성수동 대지 경매 및 이문호-대한은행 근저당권 설정",
"오국한의 신림동 상가 사해행위성 사촌 오민한 명의 이전",
"망 강호연 소유 평택시 빌라 박광윤 유치권 행사",
"양정숙의 흑석동 상가 인도 및 사업자등록과 윤건우의 매매해제 통지"
],
"claim_type_candidates": ["금전", "물건인도", "확인", "형성"],
"parties": {
"plaintiffs": [
{ "name": "강용원", "type": "자연인" },
{ "name": "양정숙", "type": "자연인" }
],
"defendants": [
{ "name": "오민한", "type": "자연인", "asset_status": "사업승계인, 사해행위 수익자 후보" },
{ "name": "이문호", "type": "자연인", "asset_status": "성수동 대지 소유자" },
{ "name": "주식회사 대한은행", "type": "법인", "asset_status": "성수동 대지 근저당권자" },
{ "name": "박성희", "type": "자연인", "asset_status": "성수동 대지/건물 점유자" },
{ "name": "박광윤", "type": "자연인", "asset_status": "평택시 빌라 유치권자" },
{ "name": "윤건우", "type": "자연인", "asset_status": "흑석동 상가 매도인" }
],
"third_parties": [
{ "name": "오국한", "relationship": "채무자" },
{ "name": "김선웅", "relationship": "원채무자" }
]
},
"issue_clusters": [
{
"cluster_id": "IC-01",
"cluster_label": "인테리어 자재대금",
"candidate_plaintiffs": ["강용원"],
"candidate_defendants_or_counterparties": ["오민한"],
"desired_relief_keywords": ["금전"],
"domain_profiles": {
"monetary_claim_profile": {
"underlying_claim_type": "물품대금",
"principal_debtor_candidates": ["김선웅"],
"successor_or_secondary_liability_candidates": ["오민한"],
"requires_money_claim_timeline": true
}
}
},
{
"cluster_id": "IC-02",
"cluster_label": "성수동 대지/건물",
"candidate_plaintiffs": ["강용원"],
"candidate_defendants_or_counterparties": ["이문호", "주식회사 대한은행", "박성희"],
"desired_relief_keywords": ["확인", "명도", "철거"],
"domain_profiles": {
"secured_property_dispute_profile": {
"auction_or_registry_invalidity_expected": true
}
}
},
{
"cluster_id": "IC-03",
"cluster_label": "신림동 상가 사해행위",
"candidate_plaintiffs": ["강용원"],
"candidate_defendants_or_counterparties": ["오민한"],
"desired_relief_keywords": ["금전", "형성"],
"domain_profiles": {
"actio_property_transfer_profile": {
"debtor": "오국한",
"beneficiary": "오민한",
"fraudulent_act_asset": "신림동 상가",
"fraudulent_act_type": "소유권이전등기"
}
}
},
{
"cluster_id": "IC-04",
"cluster_label": "평택시 빌라 유치권",
"candidate_plaintiffs": ["강용원", "양정숙"],
"preferred_plaintiffs_for_complaint": [],
"succession_resolution_needed": true,
"candidate_defendants_or_counterparties": ["박광윤"],
"desired_relief_keywords": ["확인", "명도", "금전"],
"domain_profiles": {
"possession_lien_succession_profile": {
"succession_resolution_needed": true,
"possession_basis_asserted": "유치권"
}
}
},
{
"cluster_id": "IC-05",
"cluster_label": "흑석동 상가 임대차",
"candidate_plaintiffs": ["양정숙"],
"candidate_defendants_or_counterparties": ["윤건우"],
"desired_relief_keywords": ["확인"],
"domain_profiles": {
"possession_lien_succession_profile": {
"possession_basis_asserted": "임대차"
}
}
}
],
"plaintiff_capacity_matrix": [
{
"cluster_id": "IC-04",
"plaintiff_name": "강용원",
"capacity_basis": "상속인",
"source_basis_text": "망 강호연의 아버지",
"certainty": "provisional"
},
{
"cluster_id": "IC-04",
"plaintiff_name": "양정숙",
"capacity_basis": "상속인",
"source_basis_text": "망 강호연의 배우자",
"certainty": "provisional"
}
],
"current_control_map_4axis": [
{
"object": "성수동 대지/건물",
"cluster_id": "IC-02",
"current_right_holder_candidate": "이문호",
"current_possessor": "박성희",
"certainty": "final"
},
{
"object": "평택시 빌라",
"cluster_id": "IC-04",
"current_possessor": "박광윤",
"certainty": "final"
},
{
"object": "흑석동 상가",
"cluster_id": "IC-05",
"current_possessor": "양정숙",
"current_user": "양정숙",
"certainty": "final"
}
],
"standing_watchpoints": [
"평택시 빌라 관련 망 강호연의 상속인 확정 및 승계 resolution 필요",
"성수동 대지 경매 공신력 주장과 이문호 소유권 취득 적법성 재검토"
]
}
@@ -0,0 +1,144 @@
{
"evidence_index_proposed": "E-001",
"title": "가정법원심판_강호연",
"doc_type": "판결/결정",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 1
},
"property_cluster_id": null,
"doc_semantic_flags": [
"succession_doc",
"status_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-001-01",
"event_or_state": "event",
"event_kind": "상속포기",
"event_subkind": "succession_renunciation_filing",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "강형수와 강지수가 망 강호연의 재산상속을 포기하는 신고를 함.",
"source_evidence_index_proposed": "E-001",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"강형수",
"강지수"
],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": [
"강호연"
]
},
"object_spec": "재산상속 포기 신고",
"fraction_ref": null,
"amount": null,
"event_date": "2024-09-11",
"event_end_date": null,
"time_text": "2024. 9. 11.",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"상속포기",
"신고"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "주문",
"excerpt": "청구인들이 피상속인 망 강호연의 재산상속을 포기하는 2024. 9. 11. 자 신고",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": {
"deceased_candidate": "강호연",
"spouse_candidates": [],
"lineal_ascendant_candidates": [],
"lineal_descendant_candidates": [],
"renunciant_candidates": [
"강형수",
"강지수"
]
},
"legal_effect_candidate": null,
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event_상속포기_강형수_강지수_망강호연_2024-09-11",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-001-02",
"event_or_state": "event",
"event_kind": "판결/결정",
"event_subkind": "succession_renunciation_acceptance",
"action_type_candidate": "소송행위(litigation acts)",
"action_summary": "서울가정법원이 강형수와 강지수의 상속포기 신고를 수리하는 심판을 내림.",
"source_evidence_index_proposed": "E-001",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"서울가정법원"
],
"counterparty_candidates": [
"강형수",
"강지수"
],
"beneficiary_candidates": [],
"third_party_candidates": [
"강호연"
]
},
"object_spec": "상속포기 신고 수리",
"fraction_ref": null,
"amount": null,
"event_date": "2024-09-20",
"event_end_date": null,
"time_text": "2024. 9. 20.",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"심판",
"상속포기",
"수리"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "주문",
"excerpt": "청구인들이 피상속인 망 강호연의 재산상속을 포기하는 2024. 9. 11. 자 신고는 이를 수리한다.",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": {
"deceased_candidate": "강호연",
"spouse_candidates": [],
"lineal_ascendant_candidates": [],
"lineal_descendant_candidates": [],
"renunciant_candidates": [
"강형수",
"강지수"
]
},
"legal_effect_candidate": null,
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event_판결/결정_서울가정법원_망강호연_상속포기수리_2024-09-20",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,85 @@
{
"evidence_index_proposed": "E-002",
"title": "가족관계증명서 [폐쇄]",
"doc_type": "공문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 2
},
"property_cluster_id": null,
"doc_semantic_flags": [
"status_doc",
"succession_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-002-01",
"event_or_state": "event",
"event_kind": "상속개시",
"event_subkind": null,
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "망 강호연의 사망으로 인한 상속개시",
"source_evidence_index_proposed": "E-002",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"강호연"
],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": [
"강용원",
"양정숙",
"강형수",
"강지수"
]
},
"object_spec": null,
"fraction_ref": null,
"amount": null,
"event_date": "2024-08-10",
"event_end_date": null,
"time_text": "2024-08-10",
"time_precision": "exact",
"location": null,
"legal_keywords": [],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "본인 강호연 사망",
"excerpt": "강호연(姜鎬然) 사망",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": {
"deceased_candidate": "강호연",
"spouse_candidates": [
"양정숙"
],
"lineal_ascendant_candidates": [
"강용원"
],
"lineal_descendant_candidates": [
"강형수",
"강지수"
],
"renunciant_candidates": []
},
"legal_effect_candidate": null,
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event|상속개시|강호연|2024-08-10",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,135 @@
{
"evidence_index_proposed": "E-003",
"title": "각서 및 금전소비대차계약서",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 3
},
"property_cluster_id": null,
"doc_semantic_flags": [
"claim_doc",
"defense_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-003-01",
"event_or_state": "event",
"event_kind": "기타",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "오국한이 오민한의 자금으로 신림동 상가를 매수하여 명의신탁했음을 확인하는 각서 작성",
"source_evidence_index_proposed": "E-003",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["오국한"],
"counterparty_candidates": [],
"beneficiary_candidates": ["오민한"],
"third_party_candidates": ["이경주"]
},
"object_spec": "신림동 상가 명의신탁",
"fraction_ref": null,
"amount": "40,000,000원",
"event_date": "2015-09-17",
"event_end_date": null,
"time_text": "2015년 9월 17일",
"time_precision": "exact",
"location": null,
"legal_keywords": ["명의신탁", "각서"],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "각서 1항",
"excerpt": "신림동 상가는 명의만 오국한으로 되어 있을 뿐, 오민한 소유임을 확인",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "명의신탁 확인",
"related_claim_type": "사해행위취소 대상",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": {
"candidate_role_tags": ["사해행위목적물후보"]
},
"identity_signature": "event-기타-오국한-오민한-신림동상가명의신탁-2015-09-17",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-003-02",
"event_or_state": "event",
"event_kind": "채권발생",
"event_subkind": "underlying_claim_arising",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "오국한이 오민한으로부터 1,000만 원을 차용하는 금전소비대차계약 체결",
"source_evidence_index_proposed": "E-003",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["오국한"],
"counterparty_candidates": ["오민한"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "대여금 채무",
"fraction_ref": null,
"amount": "10,000,000원",
"event_date": "2022-07-18",
"event_end_date": null,
"time_text": "2022. 7. 18.",
"time_precision": "exact",
"location": null,
"legal_keywords": ["금전소비대차", "대여", "차용"],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "금전소비대차계약서",
"excerpt": "오국한은 오민한으로부터 1,000만 원을 차용",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "채권발생",
"related_claim_type": "대여금 채권",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": {
"candidate_role_tags": ["원고채권후보"]
},
"identity_signature": "event-채권발생-오국한-오민한-대여금채무-2022-07-18",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,74 @@
{
"evidence_index_proposed": "E-004",
"title": "감정평가서",
"doc_type": "기타",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 4
},
"property_cluster_id": null,
"doc_semantic_flags": [
"valuation_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-004-01",
"event_or_state": "state",
"event_kind": "가치평가",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "신림로 상가의 2022년~현재 시가 평가",
"source_evidence_index_proposed": "E-004",
"object_spec": "신림로 상가",
"event_date": null,
"time_precision": "range",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "신림로 상가 감정평가 표",
"excerpt": "신림로 상가 시가 평가",
"directness": "직접"
}
],
"current_state_candidate": {
"state_summary": "신림로 상가 시가 평가 내역",
"state_as_of": "2024-09-13",
"is_ongoing": true
},
"identity_signature": "state|가치평가|신림로 상가|2024-09-13",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-004-02",
"event_or_state": "state",
"event_kind": "가치평가",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "포천시 임야의 2022년~현재 시가 평가",
"source_evidence_index_proposed": "E-004",
"object_spec": "포천시 임야",
"event_date": null,
"time_precision": "range",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "포천시 임야 감정평가 표",
"excerpt": "포천시 임야 시가 평가",
"directness": "직접"
}
],
"current_state_candidate": {
"state_summary": "포천시 임야 시가 평가 내역",
"state_as_of": "2024-09-13",
"is_ongoing": true
},
"identity_signature": "state|가치평가|포천시 임야|2024-09-13",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,78 @@
{
"evidence_index_proposed": "E-005",
"title": "감정평가 의견서",
"doc_type": "공문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 5
},
"property_cluster_id": null,
"doc_semantic_flags": [
"valuation_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-005-01",
"event_or_state": "event",
"event_kind": "가치평가",
"event_subkind": null,
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "대상 토지(성수동 256 대)에 대한 2024년도 차임 시세 감정 결과 회신",
"source_evidence_index_proposed": "E-005",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["감정평가법인 광나루"],
"counterparty_candidates": ["강용원"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "성수동 대지 차임 시세",
"fraction_ref": null,
"amount": null,
"event_date": "2024-12-29",
"event_end_date": null,
"time_text": "2024년 12월 29일",
"time_precision": "exact",
"location": "서울 성동구 성수동 256",
"legal_keywords": ["감정평가", "차임 시세"],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "차임 시세 확인",
"excerpt": "지상에 건물이 있는 경우, 없는 경우에 따른 보증금별 월 차임",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "가치평가",
"related_claim_type": null,
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": {
"candidate_role_tags": ["현재사용수익후보"]
},
"identity_signature": "event|가치평가|감정평가법인광나루|강용원|성수동대지차임시세|2024-12-29",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,220 @@
{
"evidence_index_proposed": "E-006",
"title": "계약서",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 6
},
"property_cluster_id": null,
"doc_semantic_flags": ["mixed_contract_doc"],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-006-01",
"event_or_state": "event",
"event_kind": "임대차",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "성수동 대지 임대차 계약 체결",
"source_evidence_index_proposed": "E-006",
"participants": {
"actor_candidates": ["이문호"],
"counterparty_candidates": ["박성희"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "성수동 대지",
"event_date": "2024-11-20",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "1",
"excerpt": "임대차기간 계약일부터 2년으로 정하여 임대하기로 하고",
"directness": "직접"
}
],
"identity_signature": "event임대차이문호박성희성수동대지2024-11-20",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-006-02",
"event_or_state": "event",
"event_kind": "기타",
"event_subkind": "대가수수",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "임대차보증금 지급",
"source_evidence_index_proposed": "E-006",
"participants": {
"actor_candidates": ["박성희"],
"counterparty_candidates": ["이문호"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "임대차보증금 3억 원",
"amount": "300,000,000원",
"event_date": "2024-11-20",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "1",
"excerpt": "계약 당일 임대차보증금을 지급받음",
"directness": "직접"
}
],
"identity_signature": "event기타박성희이문호임대차보증금3억2024-11-20",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-006-03",
"event_or_state": "event",
"event_kind": "인도",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "성수동 대지 인도",
"source_evidence_index_proposed": "E-006",
"participants": {
"actor_candidates": ["이문호"],
"counterparty_candidates": ["박성희"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "성수동 대지",
"event_date": "2024-11-20",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "1",
"excerpt": "을에게 현상대로 인도한다",
"directness": "직접"
}
],
"identity_signature": "event인도이문호박성희성수동대지2024-11-20",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-006-04",
"event_or_state": "event",
"event_kind": "처분",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "성수동 건물 매매 계약 체결",
"source_evidence_index_proposed": "E-006",
"participants": {
"actor_candidates": ["이문호"],
"counterparty_candidates": ["박성희"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "성수동 건물",
"event_date": "2024-11-20",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "2",
"excerpt": "상가를 대금 2억 원에 매도하기로 하고",
"directness": "직접"
}
],
"identity_signature": "event처분이문호박성희성수동건물2024-11-20",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-006-05",
"event_or_state": "event",
"event_kind": "기타",
"event_subkind": "대가수수",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "매매대금 지급",
"source_evidence_index_proposed": "E-006",
"participants": {
"actor_candidates": ["박성희"],
"counterparty_candidates": ["이문호"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "매매대금 2억 원",
"amount": "200,000,000원",
"event_date": "2024-11-20",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "2",
"excerpt": "계약 당일 매매대금을 전액 지급받음",
"directness": "직접"
}
],
"identity_signature": "event기타박성희이문호매매대금2억2024-11-20",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-006-06",
"event_or_state": "event",
"event_kind": "인도",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "성수동 건물 인도",
"source_evidence_index_proposed": "E-006",
"participants": {
"actor_candidates": ["이문호"],
"counterparty_candidates": ["박성희"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "성수동 건물",
"event_date": "2024-11-20",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "2",
"excerpt": "동시에 을에게 현상대로 인도한다",
"directness": "직접"
}
],
"identity_signature": "event인도이문호박성희성수동건물2024-11-20",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-006-07",
"event_or_state": "state",
"event_kind": "점유",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "성수동 대지 및 건물 관리·사용권 귀속",
"source_evidence_index_proposed": "E-006",
"participants": {
"actor_candidates": [],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"current_state_candidate": {
"state_summary": "박성희의 대지 및 건물 관리·사용 상태",
"state_as_of": "2024-11-20",
"state_start_date": "2024-11-20",
"is_ongoing": true,
"current_possessor_candidates": ["박성희"],
"current_user_candidates": ["박성희"],
"current_benefit_holder_candidates": ["박성희"],
"current_right_holder_candidates": []
},
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "4",
"excerpt": "을은 자신의 책임하에 상가와 대지를 관리·사용하고",
"directness": "직접"
}
],
"identity_signature": "state점유박성희성수동대지및건물2024-11-20",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,146 @@
{
"evidence_index_proposed": "E-007",
"title": "공사도급계약서",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 7
},
"property_cluster_id": null,
"doc_semantic_flags": [
"claim_doc",
"schedule_doc",
"relief_object_reference_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-007-01",
"event_or_state": "event",
"event_kind": "기타",
"event_subkind": "contract_formation",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "경기 평택시 서정3길 123 건물 신축 공사도급계약 체결",
"source_evidence_index_proposed": "E-007",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"김일동"
],
"counterparty_candidates": [
"박광윤"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "평택시 서정3길 123 건물 신축공사",
"fraction_ref": null,
"amount": "1,000,000,000원",
"event_date": "2021-05-01",
"event_end_date": null,
"time_text": "2021. 5. 1.",
"time_precision": "exact",
"location": "경기 평택시 서정3길 123",
"legal_keywords": [
"공사도급계약",
"신축공사"
],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "공사기간",
"excerpt": "2021. 5. 1. ~ 2021. 11. 10.",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "contract_formation",
"related_claim_type": "공사대금채권",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event+기타+김일동+박광윤+평택시건물신축공사+2021-05-01",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-007-02",
"event_or_state": "event",
"event_kind": "변제",
"event_subkind": "payment_consideration",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "공사대금 중 중도금 4억 원 지급 및 수령",
"source_evidence_index_proposed": "E-007",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"김일동"
],
"counterparty_candidates": [
"박광윤"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "평택시 서정3길 123 건물 신축공사 중도금",
"fraction_ref": null,
"amount": "400,000,000원",
"event_date": "2021-08-30",
"event_end_date": null,
"time_text": "2021. 8. 30.",
"time_precision": "exact",
"location": "경기 평택시 서정3길 123",
"legal_keywords": [
"중도금",
"영수증"
],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "공사대금",
"excerpt": "중도금 4억 원은 2021. 8. 30. 기성고율 70% 달성 확인 시 지급한다.",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "payment_consideration",
"related_claim_type": "공사대금채권",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event+변제+김일동+박광윤+평택시건물신축공사중도금4억+2021-08-30",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,49 @@
{
"evidence_index_proposed": "E-008",
"title": "내용증명",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 8
},
"zero_event_reason": null,
"event_candidates": [
{
"candidate_id_proposed": "EVT-008-01",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": "demand_notice_dispatch",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "강용원이 오민한에게 사해행위취소 및 소유권 반환을 요구하는 내용증명 발송",
"source_evidence_index_proposed": "E-008",
"participants": {
"actor_candidates": ["강용원"],
"counterparty_candidates": ["오민한"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "신림동 상가 소유권 반환 및 배상",
"event_date": "2024-09-15",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "우체국 증명",
"excerpt": "2024. 9. 15. 내용증명우편물로 발송",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "사해행위취소 및 반환 청구",
"review_flags": ["사해행위취소 검토"]
},
"identity_signature": "event통지강용원오민한신림동상가반환요구2024-09-15",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,227 @@
{
"evidence_index_proposed": "E-009",
"title": "내용증명",
"doc_type": "기타",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 9
},
"property_cluster_id": null,
"doc_semantic_flags": [
"notice_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-009-01",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": "해제/해지의사표시",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "윤건우가 양정숙에게 임대차계약 해지 및 상가 인도 통지",
"source_evidence_index_proposed": "E-009",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"윤건우"
],
"counterparty_candidates": [
"양정숙"
],
"beneficiary_candidates": [],
"third_party_candidates": [
"이수인"
]
},
"object_spec": "흑석동 상가 임대차계약",
"fraction_ref": null,
"amount": null,
"event_date": "2024-11-29",
"event_end_date": null,
"time_text": "2024-11-29",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"임대차계약 해지",
"명도"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "본문",
"excerpt": "따라서 이 서면을 통해 임대차계약을 해지하오니",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "임대차계약 해지 통지",
"related_claim_type": "임대차",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [
"5-라"
],
"actio_relevance_candidates": null,
"identity_signature": "event통지윤건우양정숙흑석동상가2024-11-29",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-009-02",
"event_or_state": "event",
"event_kind": "도달",
"event_subkind": null,
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "내용증명 도달",
"source_evidence_index_proposed": "E-009",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"윤건우"
],
"counterparty_candidates": [
"양정숙"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "내용증명",
"fraction_ref": null,
"amount": null,
"event_date": "2024-11-30",
"event_end_date": null,
"time_text": "2024-11-30",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"도달"
],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "우편물배달증명서",
"excerpt": "배달연월일 2024년11월30일",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "통지 도달",
"related_claim_type": "임대차",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [
"5-라"
],
"actio_relevance_candidates": null,
"identity_signature": "event도달윤건우양정숙내용증명2024-11-30",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-009-03",
"event_or_state": "state",
"event_kind": "항변",
"event_subkind": "책임부인",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "소유자의 임대차 책임 부인 및 차임 연체 주장",
"source_evidence_index_proposed": "E-009",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"윤건우"
],
"counterparty_candidates": [
"양정숙"
],
"beneficiary_candidates": [],
"third_party_candidates": [
"이수인"
]
},
"object_spec": "임대차 책임",
"fraction_ref": null,
"amount": null,
"event_date": null,
"event_end_date": null,
"time_text": null,
"time_precision": "unknown",
"location": null,
"legal_keywords": [
"책임부인",
"차임연체"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "본문",
"excerpt": "매매계약이 해제된 마당에 제가 이수인이 체결한 임대차계약에 대해서 책임을 질 하등의 이유가 없습니다.",
"directness": "직접"
}
],
"current_state_candidate": {
"state_summary": "소유자의 임대차 책임 부인 및 연체 주장",
"state_as_of": "2024-11-29",
"state_start_date": null,
"state_end_date_candidate": null,
"superseded_by_candidate_id": null,
"is_ongoing": true,
"current_possessor_candidates": [],
"current_user_candidates": [],
"current_benefit_holder_candidates": [],
"current_right_holder_candidates": [],
"possession_legal_cause_asserted": "미상",
"possession_legal_cause_asserted_by": []
},
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "임대차 책임 부인 주장",
"related_claim_type": "임대차",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [
"5-라"
],
"actio_relevance_candidates": null,
"identity_signature": "state항변윤건우양정숙임대차책임",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,154 @@
{
"evidence_index_proposed": "E-010",
"title": "내용증명에 대한 답신",
"doc_type": "통신기록",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 10
},
"property_cluster_id": null,
"doc_semantic_flags": [
"response_doc",
"notice_doc",
"admission_doc",
"defense_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-010-01",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": "demand_notice_arrival",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "오민한이 강용원의 이행최고서를 2024. 9. 20. 수령함",
"source_evidence_index_proposed": "E-010",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"강용원"
],
"counterparty_candidates": [
"오민한"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "이행최고서",
"fraction_ref": null,
"amount": null,
"event_date": "2024-09-20",
"event_end_date": null,
"time_text": "2024. 9. 20.",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"이행최고서"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "제1항",
"excerpt": "귀하가 보낸 이행최고서는 2024. 9. 20. 잘 받아 보았습니다.",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "notice_arrival",
"related_claim_type": "인테리어 자재대금",
"review_flags": []
},
"identity_signature": "event|통지|강용원|오민한|이행최고서|2024-09-20",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-010-02",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": "demand_notice_dispatch",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "오민한이 강용원에게 답신 내용증명을 2024. 9. 30. 발송함",
"source_evidence_index_proposed": "E-010",
"participants": {
"actor_candidates": [
"오민한"
],
"counterparty_candidates": [
"강용원"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "내용증명",
"event_date": "2024-09-30",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "발송증명",
"excerpt": "2024. 9. 30. 내용증명우편물로 발송하였음을 증명함",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "notice_dispatch",
"related_claim_type": "인테리어 자재대금",
"review_flags": []
},
"identity_signature": "event|통지|오민한|강용원|내용증명|2024-09-30",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-010-03",
"event_or_state": "event",
"event_kind": "항변",
"event_subkind": "defense_assertion_setoff",
"action_type_candidate": "소송행위(litigation acts)",
"action_summary": "오민한이 자신의 5,000만 원 채권으로 강용원의 채권을 상계하겠다고 주장함",
"source_evidence_index_proposed": "E-010",
"participants": {
"actor_candidates": [
"오민한"
],
"counterparty_candidates": [
"강용원"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "5,000만 원 채권",
"amount": "50,000,000원",
"legal_keywords": [
"상계"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "제6항",
"excerpt": "본인의 채권 합계금 5,000만 원으로 귀하의 채권을 소멸시키겠습니다.",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "defense_assertion",
"related_claim_type": "인테리어 자재대금",
"review_flags": [
"requires_rebuttal_in_stage2"
]
},
"defense_candidate": {
"defense_type": "setoff",
"assertion_summary": "본인 채권 5,000만 원으로 상계하겠음",
"requires_rebuttal_in_stage2": true
},
"identity_signature": "event|항변|오민한|강용원|50000000원|null",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,124 @@
{
"evidence_index_proposed": "E-011",
"title": "답변서",
"doc_type": "기타",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 11
},
"property_cluster_id": null,
"doc_semantic_flags": [
"response_doc",
"status_doc",
"defense_doc",
"notice_receipt_admission_doc",
"lien_assertion_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-011-01",
"event_or_state": "event",
"event_kind": "도달",
"event_subkind": "demand_notice_arrival",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "2024. 8. 29. 자 유치권소멸청구 통지서 수령",
"source_evidence_index_proposed": "E-011",
"participants": {
"actor_candidates": ["박광윤"],
"counterparty_candidates": ["강용원", "양정숙"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "유치권소멸청구 통지서",
"event_date": "2024-09-01",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "1번 항목",
"excerpt": "귀하들이 보낸 2024. 8. 29. 자 통지서는 2024. 9. 1. 잘 받아 보았습니다.",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "notice_receipt",
"review_flags": ["receipt_admitted"]
},
"identity_signature": "event|도달|박광윤|강용원양정숙|유치권소멸청구통지서|2024-09-01",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-011-02",
"event_or_state": "state",
"event_kind": "점유",
"event_subkind": "ongoing_physical_possession",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "서정빌라 101호에 대한 유치권 행사 및 거주",
"source_evidence_index_proposed": "E-011",
"participants": {
"actor_candidates": ["박광윤"],
"counterparty_candidates": ["강용원", "양정숙"],
"beneficiary_candidates": [],
"third_party_candidates": ["김일동"]
},
"object_spec": "서정빌라 101호",
"current_state_candidate": {
"state_summary": "현재까지 유치권 행사 중이며 가족과 함께 거주",
"state_as_of": "2024-10-31",
"is_ongoing": true,
"current_possessor_candidates": ["박광윤"],
"current_user_candidates": ["박광윤"],
"possession_legal_cause_asserted": "유치권행사중",
"possession_legal_cause_asserted_by": ["박광윤"]
},
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "2번 항목",
"excerpt": "현재까지 서정빌라 101호에 관한 유치권을 행사 중입니다.",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "lien_assertion"
},
"identity_signature": "state|점유|박광윤|강용원양정숙|서정빌라101호|2024-10-31",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-011-03",
"event_or_state": "state",
"event_kind": "항변",
"event_subkind": "defense_assertion_benefit_applied_to_secured_claim",
"action_type_candidate": "소송행위(litigation acts)",
"action_summary": "과거 임대료 및 거주 수익을 채무에 충당 주장",
"source_evidence_index_proposed": "E-011",
"participants": {
"actor_candidates": ["박광윤"],
"counterparty_candidates": ["강용원", "양정숙"]
},
"object_spec": "공사대금 채권",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "4번 항목",
"excerpt": "위 차임이나 저와 제 가족이 서정빌라 101호에 거주하는 기간의 차임을 공제하더라도 여전히 3억 원 가까운 채무가 남아 있고",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "defense_assertion",
"review_flags": ["requires_rebuttal_in_stage2"]
},
"identity_signature": "state|항변|박광윤|강용원양정숙|공사대금채권|2024-10-31",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,156 @@
{
"evidence_index_proposed": "E-012",
"title": "등기말소 신청에 대한 답신",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 12
},
"property_cluster_id": null,
"doc_semantic_flags": [
"notice_doc",
"response_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-012-01",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": "통지",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "주식회사 대한은행이 강용원의 성수동 대지 근저당권 말소 신청을 거부하는 통지를 발송함",
"source_evidence_index_proposed": "E-012",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"주식회사 대한은행"
],
"counterparty_candidates": [
"강용원"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "성수동 대지 근저당권 말소 신청 거부 통지",
"fraction_ref": null,
"amount": null,
"event_date": "2024-12-22",
"event_end_date": null,
"time_text": "2024-12-22",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"등기말소 신청",
"거부",
"답신"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "본사는 소관 지점을 통해 귀하가 2024. 11. 20. 자로 제출한 [등기말소 신청서]를 검토한 결과, 아래와 같이 답신하고자 합니다.",
"excerpt": "등기말소 신청에 대한 답신",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "통지",
"related_claim_type": null,
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event+통지+주식회사 대한은행+강용원+성수동 대지 근저당권 말소 신청 거부 통지+2024-12-22",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-012-02",
"event_or_state": "event",
"event_kind": "항변",
"event_subkind": "defense_assertion_subsequent_owner_no_extinction_right",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "주식회사 대한은행이 경매 절차의 적법성과 경매의 공신력(민사집행법 제267조)을 주장하며 근저당권 말소 불가 통지",
"source_evidence_index_proposed": "E-012",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"주식회사 대한은행"
],
"counterparty_candidates": [
"강용원"
],
"beneficiary_candidates": [],
"third_party_candidates": [
"경매법원"
]
},
"object_spec": "경매의 공신력 주장",
"fraction_ref": null,
"amount": null,
"event_date": "2024-12-22",
"event_end_date": null,
"time_text": "2024-12-22",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"민사집행법 제267조",
"경매의 공신력",
"경매절차"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "민사집행법 제267조는 경매의 공신력을 인정하는 규정을 두고 있는 것입니다.",
"excerpt": "경매의 공신력 주장",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "항변",
"related_claim_type": "근저당권 말소",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [
"Stage 2 claim description"
],
"review_flags": [
"Stage 2 claim description"
]
},
"defense_candidate": {
"defense_type": "소유권 방어",
"requires_rebuttal_in_stage2": true
},
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event+항변+주식회사 대한은행+강용원+경매 공신력 주장+2024-12-22",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,181 @@
{
"evidence_index_proposed": "E-013",
"title": "등기사항전부증명서(말소사항 포함)-토지",
"doc_type": "공문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 13
},
"property_cluster_id": "성수동_토지",
"doc_semantic_flags": [
"registry_doc",
"multi_event_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": ["성수동_토지"],
"event_candidates": [
{
"candidate_id_proposed": "EVT-013-01",
"event_or_state": "event",
"event_kind": "소유권이전",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "강석우 사망으로 인한 정유심, 강용원 지분 상속",
"source_evidence_index_proposed": "E-013",
"participants": {
"actor_candidates": ["정유심", "강용원"],
"third_party_candidates": ["강석우"]
},
"object_spec": "성수동 대지 5/3 및 5/2 지분",
"fraction_ref": "3/5, 2/5",
"event_date": "2022-11-08",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구 순위번호 3",
"excerpt": "상속",
"directness": "직접"
}
],
"identity_signature": "event|소유권이전|정유심,강용원|강석우|성수동대지지분|2022-11-08",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-013-02",
"event_or_state": "event",
"event_kind": "증여",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "정유심의 성수동 대지 3/5 지분 강용원에게 증여",
"source_evidence_index_proposed": "E-013",
"participants": {
"actor_candidates": ["정유심"],
"beneficiary_candidates": ["강용원"]
},
"object_spec": "성수동 대지 3/5 지분",
"fraction_ref": "3/5",
"event_date": "2023-04-06",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구 순위번호 4",
"excerpt": "증여",
"directness": "직접"
}
],
"identity_signature": "event|증여|정유심|강용원|성수동대지3/5지분|2023-04-06",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-013-03",
"event_or_state": "event",
"event_kind": "경매개시",
"event_subkind": "auction_application_after_extinguishment",
"action_type_candidate": "소송행위(litigation acts)",
"action_summary": "오민환의 담보권실행을 위한 경매개시결정",
"source_evidence_index_proposed": "E-013",
"participants": {
"actor_candidates": ["오민환"],
"third_party_candidates": ["법원"]
},
"object_spec": "성수동 대지",
"event_date": "2024-07-21",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구 순위번호 5",
"excerpt": "담보권실행을위한경매개시결정",
"directness": "직접"
}
],
"identity_signature": "event|경매개시|오민환|법원|성수동대지|2024-07-21",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-013-04",
"event_or_state": "event",
"event_kind": "경매매각",
"event_subkind": "auction_sale_and_registry_transfer",
"action_type_candidate": "소송행위(litigation acts)",
"action_summary": "경매로 인한 이문호의 소유권 취득",
"source_evidence_index_proposed": "E-013",
"participants": {
"actor_candidates": ["이문호"],
"third_party_candidates": ["법원"]
},
"object_spec": "성수동 대지",
"event_date": "2024-10-05",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구 순위번호 6",
"excerpt": "담보권실행을위한경매로인한매각",
"directness": "직접"
}
],
"identity_signature": "event|경매매각|이문호|법원|성수동대지|2024-10-05",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-013-05",
"event_or_state": "event",
"event_kind": "담보말소",
"event_subkind": "mortgage_extinguishment_by_fraction",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "경매로 인한 오민환의 기존 근저당권 말소",
"source_evidence_index_proposed": "E-013",
"participants": {
"counterparty_candidates": ["오민환"]
},
"object_spec": "기존 근저당권",
"event_date": "2024-10-05",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "을구 순위번호 3",
"excerpt": "근저당권설정등기말소",
"directness": "직접"
}
],
"identity_signature": "event|담보말소|미상|오민환|기존근저당권|2024-10-05",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-013-06",
"event_or_state": "event",
"event_kind": "담보설정",
"event_subkind": "secured_debt_creation",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "주식회사 대한은행의 근저당권 설정",
"source_evidence_index_proposed": "E-013",
"participants": {
"actor_candidates": ["주식회사 대한은행"],
"counterparty_candidates": ["이문호"]
},
"object_spec": "성수동 대지",
"amount": "520,000,000원",
"event_date": "2024-10-05",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "을구 순위번호 4",
"excerpt": "근저당권설정",
"directness": "직접"
}
],
"identity_signature": "event|담보설정|주식회사대한은행|이문호|성수동대지/520000000원|2024-10-05",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,198 @@
{
"evidence_index_proposed": "E-014",
"title": "등기사항전부증명서 (말소사항 포함) -건물",
"doc_type": "공문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 14
},
"property_cluster_id": null,
"doc_semantic_flags": [
"registry_doc",
"multi_event_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-014-01",
"event_or_state": "state",
"event_kind": "소유권이전",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "이경주 소유권보존",
"source_evidence_index_proposed": "E-014",
"participants": {
"actor_candidates": ["이경주"],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "서울특별시 관악구 신림로 115 건물",
"event_date": "2006-05-08",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구 순위번호 1",
"excerpt": "소유권보존 이경주",
"directness": "직접"
}
],
"identity_signature": "state|소유권이전|이경주|null|서울특별시 관악구 신림로 115 건물|2006-05-08",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-014-02",
"event_or_state": "event",
"event_kind": "소유권이전",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "오국환 소유권이전(매매)",
"source_evidence_index_proposed": "E-014",
"participants": {
"actor_candidates": ["이경주"],
"counterparty_candidates": ["오국환"],
"beneficiary_candidates": ["오국환"],
"third_party_candidates": []
},
"object_spec": "서울특별시 관악구 신림로 115 건물",
"amount": "40,000,000원",
"event_date": "2015-09-17",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구 순위번호 2",
"excerpt": "매매 오국환",
"directness": "직접"
}
],
"identity_signature": "event|소유권이전|이경주|오국환|서울특별시 관악구 신림로 115 건물|2015-09-17",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-014-03",
"event_or_state": "event",
"event_kind": "소유권이전",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "오민한 소유권이전(매매)",
"source_evidence_index_proposed": "E-014",
"participants": {
"actor_candidates": ["오국환"],
"counterparty_candidates": ["오민한"],
"beneficiary_candidates": ["오민한"],
"third_party_candidates": []
},
"object_spec": "서울특별시 관악구 신림로 115 건물",
"amount": "150,000,000원",
"event_date": "2023-03-17",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구 순위번호 3",
"excerpt": "매매 오민한",
"directness": "직접"
}
],
"actio_relevance_candidates": {
"candidate_role_tags": ["사해행위목적물후보"]
},
"identity_signature": "event|소유권이전|오국환|오민한|서울특별시 관악구 신림로 115 건물|2023-03-17",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-014-04",
"event_or_state": "event",
"event_kind": "담보설정",
"event_subkind": "secured_debt_creation",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "나임오 근저당권 설정",
"source_evidence_index_proposed": "E-014",
"participants": {
"actor_candidates": ["오국환"],
"counterparty_candidates": ["나임오"],
"beneficiary_candidates": ["나임오"],
"third_party_candidates": []
},
"object_spec": "서울특별시 관악구 신림로 115 건물",
"amount": "50,000,000원",
"event_date": "2021-08-01",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "을구 순위번호 1",
"excerpt": "근저당권설정 나임오",
"directness": "직접"
}
],
"identity_signature": "event|담보설정|오국환|나임오|서울특별시 관악구 신림로 115 건물|2021-08-01",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-014-05",
"event_or_state": "event",
"event_kind": "담보설정",
"event_subkind": "secured_debt_creation",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "강용일 근저당권 설정",
"source_evidence_index_proposed": "E-014",
"participants": {
"actor_candidates": ["오국환"],
"counterparty_candidates": ["강용일"],
"beneficiary_candidates": ["강용일"],
"third_party_candidates": []
},
"object_spec": "서울특별시 관악구 신림로 115 건물",
"amount": "150,000,000원",
"event_date": "2022-04-18",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "을구 순위번호 2",
"excerpt": "근저당권설정 강용일",
"directness": "직접"
}
],
"identity_signature": "event|담보설정|오국환|강용일|서울특별시 관악구 신림로 115 건물|2022-04-18",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-014-06",
"event_or_state": "event",
"event_kind": "담보말소",
"event_subkind": "mortgage_extinguishment_by_fraction",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "2번 근저당권 말소",
"source_evidence_index_proposed": "E-014",
"participants": {
"actor_candidates": [],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "2번 근저당권",
"event_date": "2024-10-17",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "을구 순위번호 3",
"excerpt": "2번근저당권 설정등기말소",
"directness": "직접"
}
],
"identity_signature": "event|담보말소|null|null|2번 근저당권|2024-10-17",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,168 @@
{
"evidence_index_proposed": "E-015",
"title": "등기사항전부증명서(말소사항 포함)-집합건물",
"doc_type": "공문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 15
},
"property_cluster_id": null,
"doc_semantic_flags": [
"registry_doc",
"multi_event_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-015-01",
"event_or_state": "event",
"event_kind": "소유권이전",
"event_subkind": "소유권보존",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "소유권보존등기(김일동)",
"source_evidence_index_proposed": "E-015",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["김일동"],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "평택시 서정3길 123 서정빌라 101호",
"fraction_ref": null,
"amount": null,
"event_date": "2021-12-10",
"event_end_date": null,
"time_text": "2021년12월10일",
"time_precision": "exact",
"location": "경기도 평택시 서정3길 123",
"legal_keywords": ["소유권보존"],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구1",
"excerpt": "소유권보존",
"directness": "직접"
}
],
"identity_signature": "event|소유권이전|김일동|없음|서정빌라 101호|2021-12-10",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-015-02",
"event_or_state": "event",
"event_kind": "소유권이전",
"event_subkind": "매매",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "매매로 인한 소유권이전(정남이)",
"source_evidence_index_proposed": "E-015",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["정남이"],
"counterparty_candidates": ["김일동"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "평택시 서정3길 123 서정빌라 101호",
"fraction_ref": null,
"amount": null,
"event_date": "2021-12-30",
"event_end_date": null,
"time_text": "2021년12월30일",
"time_precision": "exact",
"location": "경기도 평택시 서정3길 123",
"legal_keywords": ["소유권이전", "매매"],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구2",
"excerpt": "소유권이전",
"directness": "직접"
}
],
"identity_signature": "event|소유권이전|정남이|김일동|서정빌라 101호|2021-12-30",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-015-03",
"event_or_state": "event",
"event_kind": "가압류/압류",
"event_subkind": "가압류",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "가압류 설정(김동국)",
"source_evidence_index_proposed": "E-015",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["김동국"],
"counterparty_candidates": ["정남이"],
"beneficiary_candidates": [],
"third_party_candidates": ["수원지방법원 평택지원"]
},
"object_spec": "평택시 서정3길 123 서정빌라 101호",
"fraction_ref": null,
"amount": "14,000,000원",
"event_date": "2022-09-01",
"event_end_date": null,
"time_text": "2022년9월1일",
"time_precision": "exact",
"location": "경기도 평택시 서정3길 123",
"legal_keywords": ["가압류"],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구3",
"excerpt": "가압류",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "가압류",
"related_claim_type": "금전채권",
"review_flags": ["가압류_말소"]
},
"identity_signature": "event|가압류/압류|김동국|정남이|14,000,000원|2022-09-01",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-015-04",
"event_or_state": "event",
"event_kind": "소유권이전",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "소유권이전(강호연)",
"source_evidence_index_proposed": "E-015",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["강호연"],
"counterparty_candidates": ["정남이"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "평택시 서정3길 123 서정빌라 101호",
"fraction_ref": null,
"amount": null,
"event_date": "2022-10-01",
"event_end_date": null,
"time_text": "2022년10월1일",
"time_precision": "exact",
"location": "경기도 평택시 서정3길 123",
"legal_keywords": ["소유권이전"],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "갑구4",
"excerpt": "소유권이전",
"directness": "직접"
}
],
"identity_signature": "event|소유권이전|강호연|정남이|서정빌라 101호|2022-10-01",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,22 @@
{
"evidence_index_proposed": "E-016",
"title": "별지 목록",
"doc_type": "공문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 16
},
"property_cluster_id": null,
"doc_semantic_flags": [
"schedule_doc",
"relief_object_reference_doc"
],
"zero_event_reason": "REFERENCE_ONLY_DOC",
"affected_asset_cluster_ids": [],
"event_candidates": [],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,138 @@
{
"evidence_index_proposed": "E-017",
"title": "부동산 매매계약서",
"doc_type": "공문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 17
},
"property_cluster_id": null,
"doc_semantic_flags": [
"claim_doc",
"mixed_contract_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-017-01",
"event_or_state": "event",
"event_kind": "처분",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "흑석동 상가에 대한 매매계약 체결",
"source_evidence_index_proposed": "E-017",
"participants": {
"actor_candidates": ["윤건우"],
"counterparty_candidates": ["이수인"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "흑석동 상가(201호)",
"amount": "1,000,000,000원",
"event_date": "2023-10-01",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "계약내용",
"excerpt": "매매대금: 10억 원(1,000,000,000원)",
"directness": "직접"
}
],
"identity_signature": "event|처분|윤건우|이수인|흑석동상가|2023-10-01",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-017-02",
"event_or_state": "event",
"event_kind": "기타",
"event_subkind": "대가수수",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "계약금 2억 원 지급",
"source_evidence_index_proposed": "E-017",
"participants": {
"actor_candidates": ["이수인"],
"counterparty_candidates": ["윤건우"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "계약금",
"amount": "200,000,000원",
"event_date": "2023-10-01",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "계약내용",
"excerpt": "계 약 금: 2억 원(200,000,000원) 계약 당일 지급",
"directness": "직접"
}
],
"identity_signature": "event|기타|이수인|윤건우|계약금|2023-10-01",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-017-03",
"event_or_state": "event",
"event_kind": "기타",
"event_subkind": "대가수수",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "중도금 5억 원 지급",
"source_evidence_index_proposed": "E-017",
"participants": {
"actor_candidates": ["이수인"],
"counterparty_candidates": ["윤건우"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "중도금",
"amount": "500,000,000원",
"event_date": "2024-01-01",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "계약내용",
"excerpt": "중 도 금: 5억 원(500,000,000원) 2024. 1. 1. 지급",
"directness": "직접"
}
],
"identity_signature": "event|기타|이수인|윤건우|중도금|2024-01-01",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-017-04",
"event_or_state": "event",
"event_kind": "인도",
"event_subkind": null,
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "흑석동 상가 인도",
"source_evidence_index_proposed": "E-017",
"participants": {
"actor_candidates": ["윤건우"],
"counterparty_candidates": ["이수인"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "흑석동 상가(201호)",
"event_date": "2024-01-01",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "특약사항",
"excerpt": "매도인은 매수인으로부터 중도금을 지급받은 날 매수인에게 위 부동산을 인도한다.",
"directness": "직접"
}
],
"identity_signature": "event|인도|윤건우|이수인|흑석동상가|2024-01-01",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,85 @@
{
"evidence_index_proposed": "E-018",
"title": "사업자등록증",
"doc_type": "공문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 18
},
"property_cluster_id": null,
"doc_semantic_flags": [
"status_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-018-01",
"event_or_state": "state",
"event_kind": "사업자등록",
"event_subkind": null,
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "양정숙의 맛나식당 사업자등록 및 영업 개시",
"source_evidence_index_proposed": "E-018",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"양정숙"
],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": [
"동작 세무서장"
]
},
"object_spec": "맛나식당",
"fraction_ref": null,
"amount": null,
"event_date": "2024-02-01",
"event_end_date": null,
"time_text": "2024년 2월 1일",
"time_precision": "exact",
"location": "서울 동작구 흑석로 80, 201호",
"legal_keywords": [],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "개업 연월일",
"excerpt": "2024년 2월 1일",
"directness": "직접"
}
],
"current_state_candidate": {
"state_summary": "맛나식당 운영 중",
"state_as_of": "현재",
"state_start_date": "2024-02-01",
"state_end_date_candidate": null,
"superseded_by_candidate_id": null,
"is_ongoing": true,
"current_possessor_candidates": [],
"current_user_candidates": [
"양정숙"
],
"current_benefit_holder_candidates": [
"양정숙"
],
"current_right_holder_candidates": [],
"possession_legal_cause_asserted": null,
"possession_legal_cause_asserted_by": []
},
"succession_candidate": null,
"legal_effect_candidate": null,
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "state|사업자등록|양정숙|맛나식당|2024-02-01",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,121 @@
{
"evidence_index_proposed": "E-019",
"title": "소멸청구 통지서",
"doc_type": "기타",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 19
},
"property_cluster_id": "해당 주거용 부동산",
"doc_semantic_flags": [
"notice_doc",
"lien_assertion_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-019-01",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": "lien_extinction_notice_dispatch",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "유치권 소멸청구 통지서 발송",
"source_evidence_index_proposed": "E-019",
"participants": {
"actor_candidates": ["강용원", "양정숙"],
"counterparty_candidates": ["박광윤"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "평택시 서정동 서정빌라 101호 유치권 소멸청구",
"event_date": "2024-08-29",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "7",
"excerpt": "발신인들은 이 통지서를 통해 귀하가 행사하는 유치권의 소멸을 청구하오니",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "유치권소멸청구",
"review_flags": ["NOTICE_DISPATCH"]
},
"identity_signature": "event|통지|강용원,양정숙|박광윤|평택시서정빌라101호유치권소멸청구|2024-08-29",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-019-02",
"event_or_state": "state",
"event_kind": "점유",
"event_subkind": "ongoing_physical_possession",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "박광윤의 평택시 빌라 101호 현재 점유 상태",
"source_evidence_index_proposed": "E-019",
"participants": {
"actor_candidates": ["박광윤"],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "평택시 서정동 서정빌라 101호",
"current_state_candidate": {
"state_summary": "평택시 빌라 101호 현재 거주 및 점유 중",
"state_as_of": "2024-08-29",
"is_ongoing": true,
"current_possessor_candidates": ["박광윤"],
"possession_legal_cause_asserted": "유치권행사중"
},
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "3",
"excerpt": "서정빌라 101호를 점거하고, 직접 거주까지 해 오셨습니다.",
"directness": "직접"
}
],
"identity_signature": "state|점유|박광윤||평택시서정빌라101호|2024-08-29",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-019-03",
"event_or_state": "event",
"event_kind": "기타",
"event_subkind": "lien_violation_candidate",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "유치권자 박광윤의 평택시 빌라 임의 임대 행위",
"source_evidence_index_proposed": "E-019",
"participants": {
"actor_candidates": ["박광윤"],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "평택시 서정동 서정빌라 101호 임대",
"event_date": "2022-02-01",
"event_end_date": "2022-07-31",
"time_precision": "range",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "4",
"excerpt": "귀하는 2022년 2월부터 7월까지 6개월간 서정빌라 101호를 인근 공장의 직원 숙소로 임대를 놓아 임대수익도 벌어들였습니다.",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "유치권의무위반",
"review_flags": ["LIEN_VIOLATION"]
},
"identity_signature": "event|기타|박광윤||평택시서정빌라101호임대|2022-02-01",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,190 @@
{
"evidence_index_proposed": "E-020",
"title": "영업양도 계약서",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 20
},
"property_cluster_id": null,
"doc_semantic_flags": [
"business_transfer_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-020-01",
"event_or_state": "event",
"event_kind": "영업양도",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "김선웅과 오민한 사이의 해드림(SUN-DREAM) 영업양도 계약 성립",
"source_evidence_index_proposed": "E-020",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["김선웅"],
"counterparty_candidates": ["오민한"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "해드림(SUN-DREAM) 영업 일체",
"fraction_ref": null,
"amount": null,
"event_date": "2024-07-05",
"event_end_date": null,
"time_text": "2024년 7월 5일",
"time_precision": "exact",
"location": "하남시 감북동 238",
"legal_keywords": ["영업양도", "양도양수"],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "제1조",
"excerpt": "갑은 ... 영업에 필요한 자산 일체를 을에게 양도하고",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "business_transfer_formation",
"related_claim_type": null,
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": ["1-다"],
"actio_relevance_candidates": null,
"identity_signature": "event|영업양도|김선웅|오민한|해드림|2024-07-05",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-020-02",
"event_or_state": "event",
"event_kind": "기타",
"event_subkind": "대가수수",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "영업양도 대가 2억 원 지급 약정",
"source_evidence_index_proposed": "E-020",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["오민한"],
"counterparty_candidates": ["김선웅"],
"beneficiary_candidates": ["김선웅"],
"third_party_candidates": []
},
"object_spec": "영업양도 대금",
"fraction_ref": null,
"amount": "200,000,000원",
"event_date": "2024-07-31",
"event_end_date": null,
"time_text": "2024. 7. 말일까지",
"time_precision": "exact",
"location": null,
"legal_keywords": ["양도대금", "지급"],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "제2조",
"excerpt": "을은 위 양도의 대가로 2024. 7. 말일까지 갑에게 대금 2억 원을 지급한다.",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "payment_obligation",
"related_claim_type": null,
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event|기타|오민한|김선웅|2억|2024-07-31",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-020-03",
"event_or_state": "event",
"event_kind": "영업양도",
"event_subkind": "commercial_successor_liability_candidate",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "영업양도에 따른 고객관계 및 고용관계 승계 약정",
"source_evidence_index_proposed": "E-020",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["오민한"],
"counterparty_candidates": ["김선웅"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "고객관계, 고용관계",
"fraction_ref": null,
"amount": null,
"event_date": "2024-07-05",
"event_end_date": null,
"time_text": "본 계약과 동시에",
"time_precision": "exact",
"location": null,
"legal_keywords": ["승계", "고객관계", "고용관계"],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "제3조",
"excerpt": "을은 ... 고객관계, 고용관계를 승계하고",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "business_succession",
"related_claim_type": null,
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": {
"transferor_name": "김선웅",
"transferee_name": "오민한",
"business_name": "해드림(SUN-DREAM)",
"trade_name_continuation_candidate": true,
"debt_exclusion_clause_candidate": true
},
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event|영업양도|오민한|김선웅|고객고용관계|2024-07-05",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,102 @@
{
"evidence_index_proposed": "E-021",
"title": "이행각서",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 21
},
"property_cluster_id": null,
"doc_semantic_flags": [
"claim_doc",
"status_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-021-01",
"event_or_state": "event",
"event_kind": "채권관리",
"event_subkind": "debt_acknowledgement",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "김선웅이 강용원에게 2021.6.5.자 물품대금 채무를 인정하고 2024.8.말까지 변제하겠다는 내용의 이행각서 작성",
"source_evidence_index_proposed": "E-021",
"participants": {
"actor_candidates": [
"김선웅"
],
"counterparty_candidates": [
"강용원"
],
"beneficiary_candidates": [
"강용원"
],
"third_party_candidates": []
},
"object_spec": "2021.6.5.자 물품대금 채무",
"event_date": "2024-08-05",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "이행각서 내용",
"excerpt": "본인은 2021. 6. 5. 자 인테리어 자재 물품대금 채무를 2024. 8. 말까지 차질 없이 갚겠습니다.",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "debt_acknowledgement",
"acknowledgement_of_debt": true,
"limitation_interruption_candidate": true,
"related_claim_type": "물품대금"
},
"identity_signature": "event|채권관리|김선웅|강용원|2021.6.5.자 물품대금 채무|2024-08-05",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-021-02",
"event_or_state": "event",
"event_kind": "채권관리",
"event_subkind": "new_due_date",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "물품대금 채무의 변제기를 2024.8.31.로 설정",
"source_evidence_index_proposed": "E-021",
"participants": {
"actor_candidates": [
"김선웅"
],
"counterparty_candidates": [
"강용원"
],
"beneficiary_candidates": [
"강용원"
],
"third_party_candidates": []
},
"object_spec": "물품대금 채무 변제기",
"event_date": "2024-08-31",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "이행각서 변제기",
"excerpt": "2024. 8. 말까지 차질 없이 갚겠습니다.",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "new_due_date",
"new_due_date_candidate": "2024-08-31",
"related_claim_type": "물품대금"
},
"identity_signature": "event|채권관리|김선웅|강용원|물품대금 채무 변제기|2024-08-31",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,201 @@
{
"evidence_index_proposed": "E-022",
"title": "임대차계약서",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 22
},
"property_cluster_id": null,
"doc_semantic_flags": [
"mixed_contract_doc",
"claim_doc",
"status_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-022-01",
"event_or_state": "event",
"event_kind": "임대차",
"event_subkind": null,
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "이수인과 양정숙 간 흑석동 상가 임대차계약 체결",
"source_evidence_index_proposed": "E-022",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["이수인"],
"counterparty_candidates": ["양정숙"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "흑석동 상가 201호",
"fraction_ref": null,
"amount": null,
"event_date": "2024-02-01",
"event_end_date": null,
"time_text": "2024. 2. 1.",
"time_precision": "exact",
"location": "서울 동작구 흑석로 80",
"legal_keywords": ["임대차계약", "임대인", "임차인"],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "계약서 전문",
"excerpt": "이수인(임대인)과 양정숙(임차인)은 아래와 같이 임대차계약을 체결함",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": null,
"related_claim_type": null,
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event|임대차|이수인|양정숙|흑석동 상가 201호|2024-02-01",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-022-02",
"event_or_state": "event",
"event_kind": "기타",
"event_subkind": "대가수수",
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "양정숙의 임대차보증금 3억 원 지급",
"source_evidence_index_proposed": "E-022",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["양정숙"],
"counterparty_candidates": ["이수인"],
"beneficiary_candidates": ["이수인"],
"third_party_candidates": []
},
"object_spec": "임대차보증금",
"fraction_ref": null,
"amount": "300,000,000원",
"event_date": "2024-02-01",
"event_end_date": null,
"time_text": "2024. 2. 1.",
"time_precision": "exact",
"location": null,
"legal_keywords": ["보증금", "지급완료"],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "제3조",
"excerpt": "임대차보증금은 임차인이 계약 당일 목적물을 인도받음과 동시에 지급완료하였음",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": null,
"related_claim_type": null,
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event|기타|양정숙|이수인|임대차보증금 300,000,000원|2024-02-01",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-022-03",
"event_or_state": "state",
"event_kind": "점유",
"event_subkind": null,
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "양정숙의 흑석동 상가 점유 및 운영 상태",
"source_evidence_index_proposed": "E-022",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["양정숙"],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "흑석동 상가 201호",
"fraction_ref": null,
"amount": null,
"event_date": "2024-02-01",
"event_end_date": null,
"time_text": "2024. 2. 1.",
"time_precision": "exact",
"location": "서울 동작구 흑석로 80",
"legal_keywords": ["점유", "운영"],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "제3조",
"excerpt": "목적물을 인도받음",
"directness": "직접"
}
],
"current_state_candidate": {
"state_summary": "양정숙의 흑석동 상가 점유 및 운영 상태",
"state_as_of": "현재",
"state_start_date": "2024-02-01",
"state_end_date_candidate": null,
"superseded_by_candidate_id": null,
"is_ongoing": true,
"current_possessor_candidates": ["양정숙"],
"current_user_candidates": ["양정숙"],
"current_benefit_holder_candidates": ["양정숙"],
"current_right_holder_candidates": [],
"possession_legal_cause_asserted": "임대차",
"possession_legal_cause_asserted_by": ["양정숙"]
},
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": null,
"related_claim_type": null,
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": {
"candidate_role_tags": ["현재점유후보", "현재사용수익후보"]
},
"identity_signature": "state|점유|양정숙|이수인|흑석동 상가 201호|현재",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,83 @@
{
"evidence_index_proposed": "E-023",
"title": "임료시세확인서",
"doc_type": "기타",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 23
},
"property_cluster_id": null,
"doc_semantic_flags": [
"valuation_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-023-01",
"event_or_state": "state",
"event_kind": "가치평가",
"event_subkind": null,
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "경기도 평택시 서정빌라의 2022. 10. 기준 월 차임 시세를 보증금 없는 월세 200만 원으로 평가함.",
"source_evidence_index_proposed": "E-023",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"김민식"
],
"counterparty_candidates": [],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "경기도 평택시 서정3길 123(서정동, 서정빌라)",
"fraction_ref": null,
"amount": "월세 200만 원",
"event_date": "2022-10-01",
"event_end_date": null,
"time_text": "2022. 10.경",
"time_precision": "approximate",
"location": null,
"legal_keywords": [],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "월 차임 시세",
"excerpt": "보증금 없이 월세 200만 원",
"directness": "직접"
}
],
"current_state_candidate": {
"state_summary": "2022. 10. 기준 임료 시세 평가",
"state_as_of": "2022-10-01",
"state_start_date": "2022-10-01",
"state_end_date_candidate": null,
"superseded_by_candidate_id": null,
"is_ongoing": false,
"current_possessor_candidates": [],
"current_user_candidates": [],
"current_benefit_holder_candidates": [],
"current_right_holder_candidates": [],
"possession_legal_cause_asserted": null,
"possession_legal_cause_asserted_by": []
},
"succession_candidate": null,
"legal_effect_candidate": null,
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": {
"candidate_role_tags": [
"현재사용수익후보"
]
},
"identity_signature": "state|가치평가|김민식||월세 200만 원|2022-10",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,142 @@
{
"evidence_index_proposed": "E-024",
"title": "차용증",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 24
},
"property_cluster_id": null,
"doc_semantic_flags": [
"claim_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-024-01",
"event_or_state": "event",
"event_kind": "채권발생",
"event_subkind": "underlying_claim_arising",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "강용원이 오국한에게 1억 원을 대여하는 계약 체결",
"source_evidence_index_proposed": "E-024",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"강용원"
],
"counterparty_candidates": [
"오국한"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "1억 원 대여금",
"fraction_ref": null,
"amount": "100,000,000원",
"event_date": "2022-04-18",
"event_end_date": null,
"time_text": "2022. 4. 18.",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"차용"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "차용증",
"excerpt": "오국한은 아래와 같이 금전을 차용합니다. 원 금 : 100,000,000원 변제기 : 2022. 12. 17. 이 자 : 월 1% 2022. 4. 18.",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "underlying_claim_arising",
"related_claim_type": "대여금",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event:채권발생:강용원:오국한:100000000원:2022-04-18",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-024-02",
"event_or_state": "event",
"event_kind": "채권발생",
"event_subkind": "underlying_claim_arising",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "강용원이 오국한에게 1억 원을 추가로 대여하는 계약 체결",
"source_evidence_index_proposed": "E-024",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"강용원"
],
"counterparty_candidates": [
"오국한"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "1억 원 대여금",
"fraction_ref": null,
"amount": "100,000,000원",
"event_date": "2022-05-18",
"event_end_date": null,
"time_text": "2022. 5. 18.",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"차용"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "차용증",
"excerpt": "오국한은 아래와 같이 금전을 차용합니다. 원 금 : 100,000,000원 변제기 : 2023. 3. 17. 이 자 : 월 1% 2022. 5. 18.",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "underlying_claim_arising",
"related_claim_type": "대여금",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event:채권발생:강용원:오국한:100000000원:2022-05-18",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,90 @@
{
"evidence_index_proposed": "E-025",
"title": "차용증",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 25
},
"property_cluster_id": null,
"doc_semantic_flags": [
"claim_doc",
"secured_debt_components"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-025-01",
"event_or_state": "event",
"event_kind": "채권발생",
"event_subkind": "underlying_claim_arising",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "강용원과 오민한 사이의 2억 원 차용 계약 체결 및 차용증 작성",
"source_evidence_index_proposed": "E-025",
"participants": {
"actor_candidates": ["강용원"],
"counterparty_candidates": ["오민한"],
"beneficiary_candidates": ["오민한"],
"third_party_candidates": []
},
"object_spec": "영업자금 2억 원 차용",
"amount": "200,000,000원",
"event_date": "2023-01-06",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "원금 2억 원, 변제기 2024. 1. 5.",
"excerpt": "2023년 1월 6일",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "채권발생",
"related_claim_type": "대여금",
"review_flags": []
},
"identity_signature": "event|채권발생|강용원|오민한|200,000,000원|2023-01-06",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-025-02",
"event_or_state": "event",
"event_kind": "담보설정",
"event_subkind": "secured_debt_creation",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "차용금 채무 담보를 위한 성수동 대지 지분 근저당권 설정 약정",
"source_evidence_index_proposed": "E-025",
"participants": {
"actor_candidates": ["강용원"],
"counterparty_candidates": ["오민한"],
"beneficiary_candidates": ["오민한"],
"third_party_candidates": []
},
"object_spec": "서울 성동구 성수동 256 대 330㎡의 5분의 2 지분",
"event_date": "2023-01-06",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "특약",
"excerpt": "서울 성동구 성수동 256 대 330㎡의 5분의 2 지분에 1순위 근저당권을 설정하기로 함",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "담보설정",
"related_claim_type": "근저당권",
"review_flags": []
},
"identity_signature": "event|담보설정|강용원|오민한|성수동 대지 지분|2023-01-06",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,57 @@
{
"evidence_index_proposed": "E-026",
"title": "차 용 증",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 26
},
"property_cluster_id": "해당 주거용 부동산",
"doc_semantic_flags": ["claim_doc"],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-026-01",
"event_or_state": "event",
"event_kind": "채권발생",
"event_subkind": "secured_debt_creation",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "강용원이 오민한으로부터 영업자금 목적으로 3억 원을 차용함",
"source_evidence_index_proposed": "E-026",
"participants": {
"actor_candidates": ["강용원"],
"counterparty_candidates": ["오민한"]
},
"object_spec": "영업자금 3억 원",
"amount": "300,000,000원",
"event_date": "2023-07-06",
"time_precision": "exact",
"identity_signature": "event채권발생강용원오민한300,000,000원2023-07-06",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-026-02",
"event_or_state": "event",
"event_kind": "담보설정",
"event_subkind": "secured_debt_creation",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "차용금 반환 담보를 위해 성수동 256번지 대지 5/3 지분에 1순위 근저당권 설정 약정",
"source_evidence_index_proposed": "E-026",
"participants": {
"actor_candidates": ["강용원"],
"counterparty_candidates": ["오민한"]
},
"object_spec": "서울 성동구 성수동 256 대 330㎡의 5분의 3 지분",
"event_date": "2023-07-06",
"time_precision": "exact",
"identity_signature": "event담보설정강용원오민한성수동256대지5/3지분2023-07-06",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,84 @@
{
"evidence_index_proposed": "E-027",
"title": "최고 통지서",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 27
},
"property_cluster_id": null,
"doc_semantic_flags": ["claim_doc", "notice_doc"],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-027-01",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": "demand_notice_dispatch",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "강용원이 김선웅에게 물품대금 지급을 최고하는 통지서를 발송함",
"source_evidence_index_proposed": "E-027",
"participants": {
"actor_candidates": ["강용원"],
"counterparty_candidates": ["김선웅"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "인테리어 자재대금 지급 최고",
"event_date": "2024-05-04",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "heading",
"locator_hint": "최고 통지서",
"excerpt": "2024년 5월 4일",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "최고",
"related_claim_type": "물품대금채권"
},
"identity_signature": "event|통지|강용원|김선웅|자재대금최고|2024-05-04",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-027-02",
"event_or_state": "event",
"event_kind": "도달",
"event_subkind": "demand_notice_arrival",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "강용원이 발송한 최고 통지서가 김선웅에게 도달함",
"source_evidence_index_proposed": "E-027",
"participants": {
"actor_candidates": ["강용원"],
"counterparty_candidates": ["김선웅"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "인테리어 자재대금 지급 최고",
"event_date": "2024-05-06",
"time_precision": "exact",
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "우편물 배달 증명서",
"excerpt": "배달연월일 2024년5월6일",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "도달",
"related_claim_type": "물품대금채권"
},
"identity_signature": "event|도달|강용원|김선웅|자재대금최고|2024-05-06",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,69 @@
{
"evidence_index_proposed": "E-028",
"title": "통지서",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 28
},
"property_cluster_id": null,
"doc_semantic_flags": [
"notice_doc",
"response_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-028-01",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": "demand_notice_arrival",
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "오민한이 강용원에게 김선웅의 채무에 대한 책임을 부인하는 내용의 통지서를 발송함.",
"source_evidence_index_proposed": "E-028",
"participants": {
"actor_candidates": [
"오민한"
],
"counterparty_candidates": [
"강용원"
],
"beneficiary_candidates": [],
"third_party_candidates": [
"김선웅"
]
},
"object_spec": "김선웅의 물품대금 채무 관련 책임 부인 통지",
"event_date": "2024-12-27",
"time_precision": "exact",
"legal_keywords": [
"채무불이행",
"소멸시효",
"영업양도"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "본문 전체",
"excerpt": "김선웅씨의 채무를 변제하라는 요구를 받은 오민한입니다.",
"directness": "직접"
}
],
"legal_effect_candidate": {
"effect_type": "defense_assertion",
"related_claim_type": "인테리어 자재대금 채권",
"review_flags": [
"Stage 2 검토 필요"
]
},
"identity_signature": "event|통지|오민한|강용원|김선웅 물품대금 채무 책임 부인|2024-12-27",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,85 @@
{
"evidence_index_proposed": "E-029",
"title": "통지서_이수인_윤건우",
"doc_type": "통신기록",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 29
},
"property_cluster_id": null,
"doc_semantic_flags": [
"notice_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-029-01",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": null,
"action_type_candidate": "준법률행위(quasi-legal acts)",
"action_summary": "흑석동 상가 매매계약에 관하여 이수인이 윤건우에게 매매대금 감액 및 제3자 명의 소유권이전등기를 요청하는 통지",
"source_evidence_index_proposed": "E-029",
"source_fact_candidate": null,
"participants": {
"actor_candidates": [
"이수인"
],
"counterparty_candidates": [
"윤건우"
],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "흑석동 상가 매매계약 조건 변경 요청",
"fraction_ref": null,
"amount": null,
"event_date": "2024-03-30",
"event_end_date": null,
"time_text": "2024. 3. 30.",
"time_precision": "exact",
"location": null,
"legal_keywords": [
"매매대금 감액",
"제3자 명의 소유권이전등기"
],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "본문 2항, 3항",
"excerpt": "매매대금을 10% 정도라도 감액하여 주시고, 다른 사람 이름으로 소유권이전등기를 해 주실 것을 당부드립니다.",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": null,
"related_claim_type": null,
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": [],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [
"5-다"
],
"actio_relevance_candidates": null,
"identity_signature": "event|통지|이수인|윤건우|흑석동상가매매계약조건변경요청|2024-03-30",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,130 @@
{
"evidence_index_proposed": "E-030",
"title": "해제 통지서",
"doc_type": "처분문서",
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 30
},
"property_cluster_id": null,
"doc_semantic_flags": [
"notice_doc"
],
"zero_event_reason": null,
"affected_asset_cluster_ids": [],
"event_candidates": [
{
"candidate_id_proposed": "EVT-030-01",
"event_or_state": "event",
"event_kind": "통지",
"event_subkind": "해제/해지 통지",
"action_type_candidate": "법률행위(legal acts)",
"action_summary": "윤건우가 이수인에게 흑석동 상가 매매계약 해제 통지를 발송함",
"source_evidence_index_proposed": "E-030",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["윤건우"],
"counterparty_candidates": ["이수인"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "흑석동 상가 매매계약 해제",
"fraction_ref": null,
"amount": null,
"event_date": "2024-05-15",
"event_end_date": null,
"time_text": "2024-05-15",
"time_precision": "exact",
"location": null,
"legal_keywords": ["매매계약해제", "내용증명"],
"support_locators": [
{
"locator_type": "paragraph",
"locator_hint": "해제 통지",
"excerpt": "2023. 10. 1. 자 매매계약을 지금 이 통지로써 해제하겠습니다.",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "contract_cancellation",
"related_claim_type": "매매대금반환",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": ["dispatch_date"],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event|통지|윤건우|이수인|흑석동상가매매계약해제|2024-05-15",
"confidence": "high"
},
{
"candidate_id_proposed": "EVT-030-02",
"event_or_state": "event",
"event_kind": "도달",
"event_subkind": null,
"action_type_candidate": "사실행위(factual acts)",
"action_summary": "이수인이 흑석동 상가 매매계약 해제 통지서를 수령함",
"source_evidence_index_proposed": "E-030",
"source_fact_candidate": null,
"participants": {
"actor_candidates": ["이수인"],
"counterparty_candidates": ["윤건우"],
"beneficiary_candidates": [],
"third_party_candidates": []
},
"object_spec": "흑석동 상가 매매계약 해제 통지서",
"fraction_ref": null,
"amount": null,
"event_date": "2024-05-16",
"event_end_date": null,
"time_text": "2024-05-16",
"time_precision": "exact",
"location": null,
"legal_keywords": ["도달"],
"support_locators": [
{
"locator_type": "table_row",
"locator_hint": "배달연월일",
"excerpt": "배달연월일 2024년 5월 16일",
"directness": "직접"
}
],
"current_state_candidate": null,
"succession_candidate": null,
"legal_effect_candidate": {
"effect_type": "cancellation_arrival",
"related_claim_type": "매매대금반환",
"acknowledgement_of_debt": null,
"limitation_interruption_candidate": null,
"new_due_date_candidate": null,
"default_start_candidate": null,
"payment_allocation_candidate": null,
"value_compensation_exception_trigger": null,
"downstream_date_roles": ["arrival_date"],
"required_downstream_roles": [],
"review_flags": []
},
"defense_candidate": null,
"commercial_successor_candidates": null,
"meeting_clause_refs": [],
"actio_relevance_candidates": null,
"identity_signature": "event|도달|이수인|윤건우|흑석동상가매매계약해제통지서|2024-05-16",
"confidence": "high"
}
],
"mapper_meta": {
"mapper_task": "Task_B2_map_events",
"schema_contract_version": "evidence_event_candidate_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,68 @@
{
"evidence_index_proposed": "E-001",
"doc_uid": "DOC-001-가정법원심판_강호연",
"title": "가정법원심판_강호연",
"title_normalized": "가정법원심판_강호연",
"doc_type": "판결/결정",
"key_facts": [
"2024느단52199 상속포기",
"강호연 사망(2024. 8. 10.)",
"상속포기 신고 수리(2024. 9. 11.)"
],
"key_dates": [
"2024. 8. 10.",
"2024. 9. 11.",
"2024. 9. 20."
],
"key_amounts": [],
"key_parties": [
"강형수",
"강지수",
"강호연"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 1
},
"property_cluster_id": null,
"doc_semantic_flags": [
"succession_doc",
"status_doc"
],
"multi_event_registry": null,
"contract_components": [],
"valuation_object": null,
"legal_calculation_object": null,
"legal_calculation_objects": [],
"claim_document_components": [],
"business_transfer_components": [],
"registry_row_components": [],
"secured_debt_components": [],
"valuation_rows": [],
"mixed_contract_payment_semantics": {},
"loan_components": [],
"valuation_matrix": {},
"registry_row_role_map": {},
"defense_assertions": [],
"admission_components": [],
"defense_components": [],
"notice_components": [],
"party_assertion_components": [],
"schedule_items": [],
"registry_object_display": {},
"succession_document_components": {
"decedent": "강호연",
"death_date": "2024-08-10",
"succession_refusers": [
"강형수",
"강지수"
],
"filing_date": "2024-09-11",
"decision_date": "2024-09-20"
},
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,49 @@
{
"evidence_index_proposed": "E-002",
"doc_uid": "DOC-002-가족관계증명서_폐쇄",
"title": "가족관계증명서 [폐쇄]",
"title_normalized": "가족관계증명서 [폐쇄]",
"doc_type": "공문서",
"key_facts": [
"강호연 2024. 8. 10. 사망",
"강용원(부), 양정숙(배우자) 유족 확인"
],
"key_dates": [
"1973-05-19",
"2024-08-10",
"2024-12-27"
],
"key_amounts": [],
"key_parties": [
"강호연",
"강용원",
"양정숙"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 2
},
"doc_semantic_flags": [
"status_doc",
"succession_doc"
],
"succession_document_components": {
"decedent": "강호연",
"date_of_death": "2024-08-10",
"spouse_candidates": [
"양정숙"
],
"lineal_descendant_candidates": [
"강형수",
"강지수"
],
"lineal_ascendant_candidates": [
"강용원"
]
},
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,82 @@
{
"evidence_index_proposed": "E-003",
"doc_uid": "DOC-003-각서_금전대차소비계약서_오국한_오민한",
"title": "각서 및 금전소비대차계약서",
"title_normalized": "각서_및_금전소비대차계약서",
"doc_type": "처분문서",
"key_facts": [
"오국한이 오민한의 자금으로 신림동 상가를 매수하여 명의신탁",
"오국한이 오민한으로부터 1,000만 원을 차용(2022. 7. 18.)",
"오국한의 2023. 7. 17. 변제기 약정"
],
"key_dates": [
"2015-09-17",
"2022-07-18",
"2023-07-17"
],
"key_amounts": [
"40,000,000원",
"10,000,000원"
],
"key_parties": [
"오국한",
"오민한",
"이경주"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 3
},
"doc_semantic_flags": [
"claim_doc",
"defense_doc"
],
"claim_document_components": [
{
"component_kind": "debt_acknowledgement",
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "각서 1항",
"excerpt": "신림동 상가는 명의만 오국한으로 되어 있을 뿐, 오민한 소유임을 확인"
}
},
{
"component_kind": "underlying_claim",
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "금전소비대차계약서",
"excerpt": "오국한은 오민한으로부터 1,000만 원을 차용"
}
}
],
"loan_components": [
{
"loan_component_id": "E-003-LC-01",
"principal_amount": "10,000,000원",
"loan_date": "2022-07-18",
"due_date": "2023-07-17",
"agreed_interest_rate": null,
"agreed_delay_damage_rate": null,
"rate_text": null,
"rate_source_locator": null,
"interest_accrual_start_hint": null,
"collateral_object_hint": null,
"role_in_claim_hint": "오민한의 오국한에 대한 대여금 채권"
}
],
"defense_assertions": [
{
"assertion_kind": "명의신탁 주장",
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "각서 1항",
"excerpt": "신림동 상가는 명의만 오국한으로 되어 있을 뿐, 오민한 소유"
}
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,143 @@
{
"evidence_index_proposed": "E-004",
"doc_uid": "DOC-004-감정평가서",
"title": "감정평가서",
"title_normalized": "감정평가서",
"doc_type": "기타",
"key_facts": [
"신림로 상가 및 포천시 임야 감정평가",
"서울감정평가사사무소 작성",
"2024. 9. 13. 작성"
],
"key_dates": [
"2024. 9. 13."
],
"key_amounts": [],
"key_parties": [
"강용원",
"장수현"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 4
},
"doc_semantic_flags": [
"valuation_doc"
],
"valuation_object": {
"valuation_kind": "market_value",
"target_object": "신림로 상가 및 포천시 임야",
"basis_date_or_period": "2022. 1. 1. ~ 현재",
"value_rows": [
{
"label": "신림로 상가 (2022.1.1~2022.12.31)",
"amount": "2억 3,000만 원",
"unit": "총액"
},
{
"label": "신림로 상가 (2023.1.1~2023.12.31)",
"amount": "2억 4,000만 원",
"unit": "총액"
},
{
"label": "신림로 상가 (2024.1.1~현재)",
"amount": "2억 5,000만 원",
"unit": "총액"
},
{
"label": "포천시 임야 (2022.1.1~2022.12.31)",
"amount": "3,000만 원",
"unit": "총액"
},
{
"label": "포천시 임야 (2023.1.1~2023.12.31)",
"amount": "3,000만 원",
"unit": "총액"
},
{
"label": "포천시 임야 (2024.1.1~현재)",
"amount": "3,500만 원",
"unit": "총액"
}
]
},
"valuation_rows": [
{
"label": "신림로 상가 2022",
"amount": "2억 3,000만 원",
"unit": "총액",
"legal_use_case": "가액배상 기준"
},
{
"label": "신림로 상가 2023",
"amount": "2억 4,000만 원",
"unit": "총액",
"legal_use_case": "가액배상 기준"
},
{
"label": "신림로 상가 2024",
"amount": "2억 5,000만 원",
"unit": "총액",
"legal_use_case": "가액배상 기준"
},
{
"label": "포천시 임야 2022",
"amount": "3,000만 원",
"unit": "총액",
"legal_use_case": "가액배상 기준"
},
{
"label": "포천시 임야 2023",
"amount": "3,000만 원",
"unit": "총액",
"legal_use_case": "가액배상 기준"
},
{
"label": "포천시 임야 2024",
"amount": "3,500만 원",
"unit": "총액",
"legal_use_case": "가액배상 기준"
}
],
"valuation_matrix": {
"신림로_상가": [
{
"period": "2022. 1. 1. ~ 2022. 12. 31.",
"amount": "2억 3,000만 원",
"legal_uses": "가액배상 기준"
},
{
"period": "2023. 1. 1. ~ 2023. 12. 31.",
"amount": "2억 4,000만 원",
"legal_uses": "가액배상 기준"
},
{
"period": "2024. 1. 1. ~ 현재",
"amount": "2억 5,000만 원",
"legal_uses": "가액배상 기준"
}
],
"포천시_임야": [
{
"period": "2022. 1. 1. ~ 2022. 12. 31.",
"amount": "3,000만 원",
"legal_uses": "가액배상 기준"
},
{
"period": "2023. 1. 1. ~ 2023. 12. 31.",
"amount": "3,000만 원",
"legal_uses": "가액배상 기준"
},
{
"period": "2024. 1. 1. ~ 현재",
"amount": "3,500만 원",
"legal_uses": "가액배상 기준"
}
]
},
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,64 @@
{
"evidence_index_proposed": "E-005",
"doc_uid": "DOC-005-감정평가의견서_성수동",
"title": "감정평가 의견서",
"title_normalized": "감정평가 의견서",
"doc_type": "거래기록",
"key_facts": [
"대상 토지: 서울 성동구 성수동 256 대 330㎡",
"2024년도 차임 시세 감정 결과 회신"
],
"key_dates": [
"2024-12-29"
],
"key_amounts": [
"월 250만 원",
"월 400만 원",
"월 350만 원",
"월 500만 원"
],
"key_parties": [
"강용원",
"감정평가법인 광나루",
"이선욱"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 5
},
"doc_semantic_flags": [
"valuation_doc"
],
"valuation_object": {
"valuation_kind": "rent_value",
"target_object": "서울 성동구 성수동 256 대 330㎡",
"basis_date_or_period": "2024년",
"value_rows": [
{
"label": "지상에 건물이 있는 경우, 보증금 3억 원",
"amount": "월 250만 원",
"unit": "월액"
},
{
"label": "지상에 건물이 있는 경우, 보증금 없음",
"amount": "월 400만 원",
"unit": "월액"
},
{
"label": "지상에 건물이 없는 경우, 보증금 3억 원",
"amount": "월 350만 원",
"unit": "월액"
},
{
"label": "지상에 건물이 없는 경우, 보증금 없음",
"amount": "월 500만 원",
"unit": "월액"
}
]
},
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,76 @@
{
"evidence_index_proposed": "E-006",
"doc_uid": "DOC-006-계약서_이문호_박성희",
"title": "계약서",
"title_normalized": "계약서",
"doc_type": "처분문서",
"key_facts": [
"성수동 대지 임대차 계약",
"성수동 건물 매매 계약",
"2024. 11. 20. 체결"
],
"key_dates": [
"2024-11-20"
],
"key_amounts": [
"임대보증금 300,000,000원",
"차임 월 3,000,000원",
"매매대금 200,000,000원"
],
"key_parties": [
"이문호",
"박성희"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 6
},
"doc_semantic_flags": [
"mixed_contract_doc",
"schedule_doc",
"relief_object_reference_doc"
],
"contract_components": [
{
"component_id": "E-006-CC-01",
"component_kind": "lease",
"object_spec": "서울 성동구 성수동 256 대 330㎡",
"amount": "300,000,000원",
"date": "2024-11-20",
"payer_candidates": [
"박성희"
],
"recipient_candidates": [
"이문호"
],
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "1",
"excerpt": "임대목적물인 대지를 보증금 3억 원, 차임 월 300만 원"
}
},
{
"component_id": "E-006-CC-02",
"component_kind": "sale",
"object_spec": "위 지상 경량철골조 샌드위치패널지붕 단층 근린상가 200㎡",
"amount": "200,000,000원",
"date": "2024-11-20",
"payer_candidates": [
"박성희"
],
"recipient_candidates": [
"이문호"
],
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "2",
"excerpt": "상가를 대금 2억 원에 매도하기로 하고"
}
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,67 @@
{
"evidence_index_proposed": "E-007",
"doc_uid": "DOC-007-공사도급계약서",
"title": "공사도급계약서",
"title_normalized": "공사도급계약서",
"doc_type": "처분문서",
"key_facts": [
"평택시 서정3길 123 건물 신축 공사도급계약",
"총 공사대금 10억 원",
"乙 박광윤의 중도금 4억 원 영수증 포함"
],
"key_dates": [
"2021-05-01",
"2021-08-30",
"2021-11-10"
],
"key_amounts": [
"1,000,000,000원",
"300,000,000원",
"400,000,000원"
],
"key_parties": [
"김일동(도급인)",
"박광윤(수급인)"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 7
},
"doc_semantic_flags": [
"claim_doc",
"schedule_doc",
"relief_object_reference_doc"
],
"contract_components": [
{
"component_id": "E-007-CC-01",
"component_kind": "other",
"object_spec": "평택시 서정3길 123 건물 신축공사",
"amount": "1,000,000,000원",
"date": "2021-05-01",
"payer_candidates": [
"김일동"
],
"recipient_candidates": [
"박광윤"
],
"source_locator": {
"locator_type": "table_row",
"locator_hint": "공사대금",
"excerpt": "총 공사금: 10억 원"
}
}
],
"claim_document_components": [
{
"component_kind": "underlying_claim",
"principal_amount": "400,000,000원",
"role_in_claim_hint": "중도금 수령"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,57 @@
{
"evidence_index_proposed": "E-008",
"doc_uid": "DOC-008-내용증명",
"title": "내용증명",
"title_normalized": "내용증명",
"doc_type": "처분문서",
"key_facts": [
"강용원이 오민한에게 채권 관련 최고",
"오국환의 신림동 상가 오민한 명의 이전 인지",
"사해행위취소 검토 및 반환 요청"
],
"key_dates": [
"2024-09-15"
],
"key_amounts": [
"200,000,000원",
"30,000,000원",
"40,000,000원",
"70,000,000원"
],
"key_parties": [
"강용원",
"오민한",
"오국환",
"오칠성",
"나일오"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 8
},
"doc_semantic_flags": [
"notice_doc",
"claim_doc",
"defense_doc"
],
"notice_components": [
{
"notice_id_proposed": "E-008-NT-01",
"notice_type": "기타",
"drafted_date": "2024-09-15",
"dispatch_date": "2024-09-15",
"sender_candidates": [
"강용원"
],
"receiver_candidates": [
"오민한"
],
"legal_effect_candidate_hint": "사해행위취소 및 소유권 반환 요구"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,79 @@
{
"evidence_index_proposed": "E-009",
"doc_uid": "DOC-009-내용증명",
"title": "내용증명",
"title_normalized": "내용증명",
"doc_type": "기타",
"key_facts": [
"윤건우의 흑석동 상가 매매계약 해제 통보",
"임대차계약 해지 및 명도 요구"
],
"key_dates": [
"2024-11-29",
"2024-11-30"
],
"key_amounts": [],
"key_parties": [
"윤건우",
"양정숙"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 9
},
"property_cluster_id": null,
"doc_semantic_flags": [
"notice_doc",
"status_doc"
],
"multi_event_registry": null,
"contract_components": [],
"valuation_object": null,
"legal_calculation_object": null,
"legal_calculation_objects": [],
"claim_document_components": [],
"business_transfer_components": [],
"registry_row_components": [],
"secured_debt_components": [],
"valuation_rows": [],
"mixed_contract_payment_semantics": {},
"loan_components": [],
"valuation_matrix": {},
"registry_row_role_map": {},
"defense_assertions": [],
"admission_components": [],
"defense_components": [],
"notice_components": [
{
"notice_id_proposed": "E-009-NT-01",
"notice_type": "기타",
"drafted_date": "2024-11-29",
"dispatch_date": "2024-11-29",
"arrival_date": "2024-11-30",
"received_date": "2024-11-30",
"legal_effect_date_candidate": "2024-11-30",
"requires_receipt_for_effect": true,
"sender_candidates": [
"윤건우"
],
"receiver_candidates": [
"양정숙"
],
"target_object_hint": "서울 동작구 흑석로 80 상가건물 201호",
"receipt_evidence_refs": [
"우편물배달증명서"
],
"recipient_admission_text": null,
"legal_effect_candidate_hint": "임대차계약 해지 및 상가 인도 요구"
}
],
"party_assertion_components": [],
"schedule_items": [],
"registry_object_display": {},
"succession_document_components": null,
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,85 @@
{
"evidence_index_proposed": "E-010",
"doc_uid": "DOC-010-내용증명에_대한_답신",
"title": "내용증명에 대한 답신",
"title_normalized": "내용증명에 대한 답신",
"doc_type": "통신기록",
"key_facts": [
"오민한의 신림동 상가 사해행위 부인 주장",
"오민한의 5,000만 원 채권 상계 주장",
"2024. 9. 30. 내용증명 우편물 발송"
],
"key_dates": [
"2024. 9. 30.",
"2022. 7. 18."
],
"key_amounts": [
"4,000만 원",
"1,000만 원",
"5,000만 원"
],
"key_parties": [
"오민한",
"강용원"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 10
},
"doc_semantic_flags": [
"response_doc",
"notice_doc",
"admission_doc",
"defense_doc"
],
"admission_components": [
{
"component_kind": "other",
"excerpt": "귀하가 보낸 이행최고서는 2024. 9. 20. 잘 받아 보았습니다."
}
],
"defense_components": [
{
"component_kind": "other",
"assertion": "신림동 상가는 애초부터 본인 소유",
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "제2항"
}
},
{
"component_kind": "other",
"assertion": "사해행위에 해당하지 않음",
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "제3항"
}
},
{
"component_kind": "other",
"assertion": "본인 채권 5,000만 원으로 상계하겠음",
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "제6항"
}
}
],
"notice_components": [
{
"notice_id_proposed": "E-010-NT-01",
"notice_type": "기타",
"dispatch_date": "2024-09-30",
"sender_candidates": [
"오민한"
],
"receiver_candidates": [
"강용원"
]
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,60 @@
{
"evidence_index_proposed": "E-011",
"doc_uid": "DOC-011-답변서_박광윤_to_강용원_양정숙",
"title": "답변서",
"title_normalized": "답변서",
"doc_type": "기타",
"key_facts": [
"박광윤의 서정빌라 101호 유치권 행사 주장",
"건축주 김일동으로부터 공사잔금 3억 원 미지급 주장",
"임대료 및 본인/가족 거주 차임을 채무에 충당 주장"
],
"key_dates": [
"2024-08-29",
"2024-09-01",
"2024-10-31"
],
"key_amounts": [
"300,000,000원",
"2,000,000원"
],
"key_parties": [
"박광윤",
"강용원",
"양정숙",
"김일동"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 11
},
"doc_semantic_flags": [
"response_doc",
"status_doc",
"defense_doc",
"notice_receipt_admission_doc",
"lien_assertion_doc"
],
"admission_components": [
{
"notice_type": "유치권소멸청구통지",
"received_date": "2024-09-01",
"recipient_admission_text": "귀하들이 보낸 2024. 8. 29. 자 통지서는 2024. 9. 1. 잘 받아 보았습니다."
}
],
"defense_components": [
{
"assertion": "공사잔금 미지급으로 인한 유치권 행사",
"basis": "서정빌라 101호 거주 및 유치권"
},
{
"assertion": "기존 수익을 채무에 충당 중",
"basis": "월 200만 원 임대료 및 본인/가족 거주 차임 공제"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,55 @@
{
"evidence_index_proposed": "E-012",
"doc_uid": "DOC-012-등기말소_신청에_대한_답신",
"title": "등기말소 신청에 대한 답신",
"title_normalized": "등기말소 신청에 대한 답신",
"doc_type": "처분문서",
"key_facts": [
"대한은행이 강용원의 근저당권 말소 신청 거부",
"경매절차 하자 없음을 주장",
"민사집행법 제267조에 따른 경매의 공신력 주장"
],
"key_dates": [
"2024-12-22"
],
"key_amounts": [],
"key_parties": [
"강용원",
"주식회사 대한은행"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 12
},
"doc_semantic_flags": [
"notice_doc",
"response_doc"
],
"notice_components": [
{
"notice_id_proposed": "E-012-NT-01",
"notice_type": "기타",
"drafted_date": "2024-12-22",
"dispatch_date": "2024-12-22",
"arrival_date": null,
"received_date": null,
"legal_effect_date_candidate": null,
"requires_receipt_for_effect": null,
"sender_candidates": [
"주식회사 대한은행"
],
"receiver_candidates": [
"강용원"
],
"target_object_hint": "성수동 대지 근저당권",
"receipt_evidence_refs": [],
"recipient_admission_text": null,
"legal_effect_candidate_hint": "등기말소 신청 거부 통지"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,107 @@
{
"evidence_index_proposed": "E-013",
"doc_uid": "DOC-013-등기사항전부증명서_성수동",
"title": "등기사항전부증명서(말소사항 포함)-토지",
"title_normalized": "등기사항전부증명서(말소사항 포함)-토지",
"doc_type": "공문서",
"key_facts": [
"성수동 대지(256)에 관한 등기사항전부증명서",
"2024.10.5. 경매로 인한 매각으로 이문호 소유권 취득",
"2024.10.5. 주식회사 대한은행 근저당권 설정"
],
"key_dates": [
"2022.12.8. (강용원/정유심 공유 지분 등기)",
"2024.10.5. (경매에 의한 소유권이전)",
"2024.10.5. (주식회사 대한은행 근저당권 설정)"
],
"key_amounts": [
"520,000,000원 (대한은행 채권최고액)"
],
"key_parties": [
"강용원",
"정유심",
"이문호",
"오민환",
"주식회사 대한은행"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 13
},
"doc_semantic_flags": [
"registry_doc",
"multi_event_doc"
],
"multi_event_registry": true,
"registry_row_components": [
{
"registry_ref": "REG-013-01",
"section": "갑구",
"row_seq": 1,
"receipt_no": "제1453호",
"event_date": "1997-03-15",
"purpose": "소유권이전",
"right_holder": "박재경"
},
{
"registry_ref": "REG-013-02",
"section": "갑구",
"row_seq": 2,
"receipt_no": "제7026호",
"event_date": "2017-06-30",
"purpose": "소유권이전",
"right_holder": "강석우"
},
{
"registry_ref": "REG-013-03",
"section": "갑구",
"row_seq": 3,
"receipt_no": "제11202호",
"event_date": "2022-11-08",
"purpose": "소유권이전",
"right_holder": "정유심, 강용원"
},
{
"registry_ref": "REG-013-04",
"section": "갑구",
"row_seq": 4,
"receipt_no": "제7202호",
"event_date": "2023-04-06",
"purpose": "증여",
"right_holder": "강용원"
},
{
"registry_ref": "REG-013-05",
"section": "갑구",
"row_seq": 5,
"receipt_no": "제12402호",
"event_date": "2024-07-21",
"purpose": "담보권실행을위한경매개시결정(일괄)",
"right_holder": "오민환"
},
{
"registry_ref": "REG-013-06",
"section": "갑구",
"row_seq": 6,
"receipt_no": "제25797호",
"event_date": "2024-10-05",
"purpose": "담보권실행을 위한 경매로 인한 매각",
"right_holder": "이문호"
},
{
"registry_ref": "REG-013-07",
"section": "을구",
"row_seq": 4,
"receipt_no": "제25799호",
"event_date": "2024-10-05",
"purpose": "근저당권설정",
"right_holder": "주식회사 대한은행",
"secured_debt_amount": "520,000,000원"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,100 @@
{
"evidence_index_proposed": "E-014",
"doc_uid": "DOC-014-등기사항전부증명서_말소사항_포함_건물",
"title": "등기사항전부증명서 (말소사항 포함) -건물",
"title_normalized": "등기사항전부증명서 (말소사항 포함) -건물",
"doc_type": "공문서",
"key_facts": [
"2015.9.17 오국환 소유권이전",
"2023.3.17 오민한 소유권이전(매매)",
"2024.10.17 2번 근저당권 말소"
],
"key_dates": [
"2006-05-08",
"2015-09-17",
"2023-03-17",
"2024-10-17"
],
"key_amounts": [
"40,000,000원",
"150,000,000원",
"50,000,000원"
],
"key_parties": [
"이경주",
"오국환",
"오민한",
"나임오",
"강용일"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 14
},
"doc_semantic_flags": [
"registry_doc",
"multi_event_doc"
],
"multi_event_registry": true,
"registry_row_components": [
{
"registry_ref": "REG-014-01",
"section": "갑구",
"row_seq": 1,
"registry_purpose": "소유권보존",
"receipt_no": "제24759호",
"registry_date": "2006-05-08",
"rights_holder": "이경주"
},
{
"registry_ref": "REG-014-02",
"section": "갑구",
"row_seq": 2,
"registry_purpose": "소유권이전",
"receipt_no": "제56457호",
"registry_date": "2015-09-17",
"rights_holder": "오국환"
},
{
"registry_ref": "REG-014-03",
"section": "갑구",
"row_seq": 3,
"registry_purpose": "소유권이전",
"receipt_no": "제11593호",
"registry_date": "2023-03-17",
"rights_holder": "오민한"
},
{
"registry_ref": "REG-014-04",
"section": "을구",
"row_seq": 4,
"registry_purpose": "근저당권설정",
"receipt_no": "제50099호",
"registry_date": "2021-08-01",
"rights_holder": "나임오"
},
{
"registry_ref": "REG-014-05",
"section": "을구",
"row_seq": 5,
"registry_purpose": "근저당권설정",
"receipt_no": "제26597호",
"registry_date": "2022-04-18",
"rights_holder": "강용일"
},
{
"registry_ref": "REG-014-06",
"section": "을구",
"row_seq": 6,
"registry_purpose": "근저당권설정등기말소",
"receipt_no": "제74586호",
"registry_date": "2024-10-17",
"rights_holder": null
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,88 @@
{
"evidence_index_proposed": "E-015",
"doc_uid": "DOC-015-등기사항전부증명서_말소사항_포함_집합건물",
"title": "등기사항전부증명서(말소사항 포함)-집합건물",
"title_normalized": "등기사항전부증명서_말소사항_포함_집합건물",
"doc_type": "공문서",
"key_facts": [
"경기도 평택시 서정3길 123 서정빌라 101호 등기부",
"2022. 10. 1. 강호연 소유권이전",
"2022. 9. 1. 김동국 가압류(말소)"
],
"key_dates": [
"2021-12-10",
"2021-12-30",
"2022-10-01"
],
"key_amounts": [
"14,000,000원"
],
"key_parties": [
"김일동",
"정남이",
"강호연",
"김동국"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 15
},
"doc_semantic_flags": [
"registry_doc",
"multi_event_doc"
],
"multi_event_registry": true,
"registry_row_components": [
{
"registry_ref": "REG-015-01",
"row_seq": 1,
"kind": "갑구",
"rank": "1",
"purpose": "소유권보존",
"receipt_date": "2021년12월10일",
"receipt_no": "제7233호",
"party_name": "김일동"
},
{
"registry_ref": "REG-015-02",
"row_seq": 2,
"kind": "갑구",
"rank": "2",
"purpose": "소유권이전",
"receipt_date": "2021년12월30일",
"receipt_no": "제7871호",
"cause": "매매",
"party_name": "정남이"
},
{
"registry_ref": "REG-015-03",
"row_seq": 3,
"kind": "갑구",
"rank": "3",
"purpose": "가압류",
"receipt_date": "2022년9월1일",
"receipt_no": "제11593호",
"cause": "수원지방법원 평택지원의 가압류결정(2022카단43434)",
"party_name": "김동국",
"amount": "14,000,000원"
},
{
"registry_ref": "REG-015-04",
"row_seq": 4,
"kind": "갑구",
"rank": "4",
"purpose": "소유권이전",
"receipt_date": "2022년10월1일",
"receipt_no": "제12321호",
"party_name": "강호연"
}
],
"registry_row_role_map": {
"REG-015-03": "release_role_potential"
},
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,56 @@
{
"evidence_index_proposed": "E-016",
"doc_uid": "DOC-016-별지_목록",
"title": "별지 목록",
"title_normalized": "별지 목록",
"doc_type": "공문서",
"key_facts": [
"성수동 대지 및 건물 목록",
"신림동 상가 목록",
"평택시 빌라 및 대지권 목록",
"흑석동 상가 및 대지권 목록"
],
"key_dates": [],
"key_amounts": [],
"key_parties": [],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 16
},
"doc_semantic_flags": [
"schedule_doc",
"relief_object_reference_doc"
],
"schedule_items": [
{
"schedule_ref": "SCH-016-01",
"canonical_label_candidate": "1. 서울 성동구 성수동 256 대 330㎡",
"usable_in_relief": "yes"
},
{
"schedule_ref": "SCH-016-02",
"canonical_label_candidate": "2. 서울 성동구 성수동 256([도로명주소] 서울 성동구 성수로 30) 지상 경량철골조 샌드위치패널지붕 단층 근린상가 200㎡",
"usable_in_relief": "yes"
},
{
"schedule_ref": "SCH-016-03",
"canonical_label_candidate": "3. 서울 관악구 신림동 779([도로명주소] 서울 관악구 신림로 115) 지상 철근콘크리트조 콘크리트지붕 단층 근린상가 100㎡",
"usable_in_relief": "yes"
},
{
"schedule_ref": "SCH-016-04",
"canonical_label_candidate": "4. (1동의 건물의 표시) 평택시 서정3길 123 지상 철근콘크리트조 슬래브지붕 3층 건물",
"usable_in_relief": "yes"
},
{
"schedule_ref": "SCH-016-05",
"canonical_label_candidate": "5. (1동의 건물의 표시) 서울 동작구 흑석로 80 지상 철근콘크리트조 슬래브지붕 3층 건물",
"usable_in_relief": "yes"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,95 @@
{
"evidence_index_proposed": "E-017",
"doc_uid": "DOC-017-부동산_매매계약서",
"title": "부동산 매매계약서",
"title_normalized": "부동산 매매계약서",
"doc_type": "처분문서",
"key_facts": [
"흑석동 상가 매매계약(2023.10.1.)",
"매매대금 10억 원",
"윤건우(매도인), 이수인(매수인)"
],
"key_dates": [
"2023-10-01",
"2024-01-01",
"2024-05-01"
],
"key_amounts": [
"1,000,000,000원",
"200,000,000원",
"500,000,000원",
"300,000,000원"
],
"key_parties": [
"윤건우",
"이수인",
"양재혁"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 17
},
"doc_semantic_flags": [
"claim_doc",
"mixed_contract_doc"
],
"contract_components": [
{
"component_id": "E-017-CC-01",
"component_kind": "sale",
"object_spec": "흑석동 상가(201호)",
"amount": "1,000,000,000원",
"date": "2023-10-01",
"payer_candidates": [
"이수인"
],
"recipient_candidates": [
"윤건우"
],
"source_locator": {
"locator_type": "table_row",
"locator_hint": "계약내용",
"excerpt": "매매대금 10억 원"
}
},
{
"component_id": "E-017-CC-02",
"component_kind": "delivery",
"object_spec": "흑석동 상가(201호)",
"possession_recipient_candidates": [
"이수인"
],
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "특약사항",
"excerpt": "중도금을 지급받은 날 매수인에게 위 부동산을 인도한다."
}
}
],
"legal_calculation_object": {
"slot_id": "E-017-LCO-01",
"slot_kind": "sale",
"source_locator": {
"locator_type": "table_row",
"locator_hint": "계약내용",
"excerpt": "부동산 매매계약서"
},
"transaction_type": "매매",
"transaction_date": "2023-10-01",
"sale_price": "1,000,000,000원",
"consideration_breakdown": [
"계약금 2억",
"중도금 5억",
"잔금 3억"
],
"parties": [
"윤건우",
"이수인"
]
},
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,33 @@
{
"evidence_index_proposed": "E-018",
"doc_uid": "DOC-018-사_업_자_등_록_증",
"title": "사업자등록증",
"title_normalized": "사업자등록증",
"doc_type": "공문서",
"key_facts": [
"양정숙 명의 맛나식당 사업자등록",
"개업일 2024년 2월 1일",
"사업장소재지 서울 동작구 흑석로 80, 201호"
],
"key_dates": [
"2024-02-01",
"2024-02-02"
],
"key_amounts": [],
"key_parties": [
"양정숙",
"동작 세무서장"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 18
},
"doc_semantic_flags": [
"status_doc"
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,79 @@
{
"evidence_index_proposed": "E-019",
"doc_uid": "DOC-019-소멸청구_통지서",
"title": "소멸청구 통지서",
"title_normalized": "소멸청구 통지서",
"doc_type": "기타",
"key_facts": [
"유치권 소멸청구 통지",
"평택시 빌라 인도 요구",
"사용수익 반환 요구"
],
"key_dates": [
"2024-08-29"
],
"key_amounts": [],
"key_parties": [
"강용원",
"양정숙",
"박광윤"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 19
},
"property_cluster_id": "해당 주거용 부동산",
"doc_semantic_flags": [
"notice_doc",
"lien_assertion_doc"
],
"multi_event_registry": null,
"contract_components": [],
"valuation_object": null,
"legal_calculation_object": null,
"legal_calculation_objects": [],
"claim_document_components": [],
"business_transfer_components": [],
"registry_row_components": [],
"secured_debt_components": [],
"valuation_rows": [],
"mixed_contract_payment_semantics": {},
"loan_components": [],
"valuation_matrix": {},
"registry_row_role_map": {},
"defense_assertions": [],
"admission_components": [],
"defense_components": [],
"notice_components": [
{
"notice_id_proposed": "E-019-NT-01",
"notice_type": "유치권소멸청구통지",
"drafted_date": "2024-08-29",
"dispatch_date": "2024-08-29",
"arrival_date": null,
"received_date": null,
"legal_effect_date_candidate": null,
"requires_receipt_for_effect": true,
"sender_candidates": [
"강용원",
"양정숙"
],
"receiver_candidates": [
"박광윤"
],
"target_object_hint": "평택시 서정3길 123, 101호(서정동, 서정빌라)",
"receipt_evidence_refs": [],
"recipient_admission_text": null,
"legal_effect_candidate_hint": null
}
],
"party_assertion_components": [],
"schedule_items": [],
"registry_object_display": {},
"succession_document_components": null,
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,45 @@
{
"evidence_index_proposed": "E-020",
"doc_uid": "DOC-020-영업양도계약서_김선웅_오민한",
"title": "영업양도 계약서",
"title_normalized": "영업양도 계약서",
"doc_type": "처분문서",
"key_facts": [
"김선웅이 오민한에게 해드림 영업을 양도함",
"계약일 2024. 7. 5.",
"양도대금 2억 원"
],
"key_dates": [
"2024. 7. 5."
],
"key_amounts": [
"200,000,000원"
],
"key_parties": [
"김선웅",
"오민한"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 20
},
"doc_semantic_flags": [
"business_transfer_doc"
],
"business_transfer_components": [
{
"business_name": "해드림(SUN-DREAM)",
"transferor_candidates": ["김선웅"],
"transferee_candidates": ["오민한"],
"business_assets_transferred": ["임차권", "설비", "비품", "자재", "공구"],
"trade_name_continuation_clause": "제4조: 을은 상호를 계속 사용할 수 있음",
"customer_or_employee_succession_clause": "제3조: 고객관계, 고용관계 승계",
"pre_transfer_debt_exclusion_clause": "제5조: 을은 계약일 전 발생 채무 책임지지 아니함"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,64 @@
{
"evidence_index_proposed": "E-021",
"doc_uid": "DOC-021-이행각서",
"title": "이행각서",
"title_normalized": "이행각서",
"doc_type": "처분문서",
"key_facts": [
"김선웅이 강용원에게 인테리어 자재 물품대금 채무 변제 약속",
"2021. 6. 5. 자 물품대금 채무",
"2024. 8. 말까지 변제 약속"
],
"key_dates": [
"2021-06-05",
"2024-08-05",
"2024-08-31"
],
"key_amounts": [],
"key_parties": [
"김선웅",
"강용원"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 21
},
"property_cluster_id": null,
"doc_semantic_flags": [
"claim_doc",
"status_doc"
],
"multi_event_registry": null,
"contract_components": [],
"valuation_object": null,
"legal_calculation_object": null,
"legal_calculation_objects": [],
"claim_document_components": [
{
"component_kind": "debt_acknowledgement",
"drafted_date": "2024-08-05",
"new_due_date": "2024-08-31"
}
],
"business_transfer_components": [],
"registry_row_components": [],
"secured_debt_components": [],
"valuation_rows": [],
"mixed_contract_payment_semantics": {},
"loan_components": [],
"valuation_matrix": {},
"registry_row_role_map": {},
"defense_assertions": [],
"admission_components": [],
"defense_components": [],
"notice_components": [],
"party_assertion_components": [],
"schedule_items": [],
"registry_object_display": {},
"succession_document_components": null,
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,57 @@
{
"evidence_index_proposed": "E-022",
"doc_uid": "DOC-022-임대차계약서_이수인_양정숙",
"title": "임대차계약서",
"title_normalized": "임대차계약서",
"doc_type": "처분문서",
"key_facts": [
"이수인(임대인)과 양정숙(임차인) 간 흑석동 상가 임대차계약 체결",
"2024. 2. 1. 계약 체결 및 보증금 지급 완료",
"보증금 3억 원, 월 차임 500만 원"
],
"key_dates": [
"2024-02-01"
],
"key_amounts": [
"300,000,000원",
"5,000,000원"
],
"key_parties": [
"이수인",
"양정숙"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 22
},
"doc_semantic_flags": [
"mixed_contract_doc",
"claim_doc",
"status_doc"
],
"contract_components": [
{
"component_id": "E-022-CC-01",
"component_kind": "lease",
"object_spec": "흑석동 상가 201호",
"amount": "300,000,000원",
"date": "2024-02-01",
"payer_candidates": [
"양정숙"
],
"recipient_candidates": [
"이수인"
],
"source_locator": {
"locator_type": "paragraph",
"locator_hint": "제1조, 제3조",
"excerpt": "흑석동 상가 201호, 보증금 3억"
}
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,47 @@
{
"evidence_index_proposed": "E-023",
"doc_uid": "DOC-023-임료시세확인서",
"title": "임료시세확인서",
"title_normalized": "임료시세확인서",
"doc_type": "기타",
"key_facts": [
"평택시 서정빌라 월 차임 시세 확인",
"보증금 없는 월세 200만 원",
"기준일 2022. 10.경"
],
"key_dates": [
"2022. 10.경",
"2024. 12. 23."
],
"key_amounts": [
"월세 200만 원"
],
"key_parties": [
"김민식"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 23
},
"doc_semantic_flags": [
"valuation_doc",
"supporting_reference_doc"
],
"valuation_object": {
"valuation_kind": "rent_value",
"target_object": "경기도 평택시 서정3길 123(서정동, 서정빌라)",
"basis_date_or_period": "2022. 10.경",
"value_rows": [
{
"label": "보증금 없이",
"amount": "월세 200만 원",
"unit": "월액"
}
]
},
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,84 @@
{
"evidence_index_proposed": "E-024",
"doc_uid": "DOC-024-차용증",
"title": "차용증",
"title_normalized": "차용증",
"doc_type": "처분문서",
"key_facts": ["2022. 4. 18.자 1억 원 차용증", "2022. 5. 18.자 1억 원 차용증"],
"key_dates": ["2022-04-18", "2022-05-18", "2022-12-17", "2023-03-17"],
"key_amounts": ["100,000,000원"],
"key_parties": ["강용원", "오국한"],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 24
},
"property_cluster_id": null,
"doc_semantic_flags": ["claim_doc"],
"multi_event_registry": null,
"contract_components": [],
"valuation_object": null,
"legal_calculation_object": null,
"legal_calculation_objects": [],
"claim_document_components": [
{
"component_kind": "underlying_claim",
"principal_amount": "100,000,000원",
"loan_date": "2022-04-18",
"due_date": "2022-12-17"
},
{
"component_kind": "underlying_claim",
"principal_amount": "100,000,000원",
"loan_date": "2022-05-18",
"due_date": "2023-03-17"
}
],
"business_transfer_components": [],
"registry_row_components": [],
"secured_debt_components": [],
"valuation_rows": [],
"mixed_contract_payment_semantics": {},
"loan_components": [
{
"loan_component_id": "E-024-LC-01",
"principal_amount": "100,000,000원",
"loan_date": "2022-04-18",
"due_date": "2022-12-17",
"agreed_interest_rate": "월 1%",
"agreed_delay_damage_rate": null,
"rate_text": "월 1%",
"rate_source_locator": null,
"interest_accrual_start_hint": null,
"collateral_object_hint": null,
"role_in_claim_hint": null
},
{
"loan_component_id": "E-024-LC-02",
"principal_amount": "100,000,000원",
"loan_date": "2022-05-18",
"due_date": "2023-03-17",
"agreed_interest_rate": "월 1%",
"agreed_delay_damage_rate": null,
"rate_text": "월 1%",
"rate_source_locator": null,
"interest_accrual_start_hint": null,
"collateral_object_hint": null,
"role_in_claim_hint": null
}
],
"valuation_matrix": {},
"registry_row_role_map": {},
"defense_assertions": [],
"admission_components": [],
"defense_components": [],
"notice_components": [],
"party_assertion_components": [],
"schedule_items": [],
"registry_object_display": {},
"succession_document_components": null,
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,50 @@
{
"evidence_index_proposed": "E-025",
"doc_uid": "DOC-025-차용증",
"title": "차용증",
"title_normalized": "차용증",
"doc_type": "처분문서",
"key_facts": [
"강용원이 오민한에게 2억 원을 차용함",
"2024. 1. 5. 변제기",
"성수동 대지 5분의 2 지분에 1순위 근저당권 설정 약정"
],
"key_dates": [
"2023-01-06"
],
"key_amounts": [
"200,000,000원"
],
"key_parties": [
"오민한",
"강용원"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 25
},
"doc_semantic_flags": [
"claim_doc",
"secured_debt_components"
],
"claim_document_components": [
{
"component_kind": "underlying_claim",
"principal_amount": "200,000,000원",
"due_date": "2024-01-05",
"agreed_interest_rate": "연 10%",
"rate_text": "연 10%"
}
],
"secured_debt_components": [
{
"collateral_object_hint": "서울 성동구 성수동 256 대 330㎡의 5분의 2 지분",
"due_date": "2024-01-05"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,52 @@
{
"evidence_index_proposed": "E-026",
"doc_uid": "DOC-026-차용증",
"title": "차 용 증",
"title_normalized": "차 용 증",
"doc_type": "처분문서",
"key_facts": [
"강용원의 오민한에 대한 300,000,000원 차용",
"서울 성동구 성수동 256 대 330㎡ 5/3 지분 근저당권 설정 약정"
],
"key_dates": [
"2023. 7. 6.",
"2024. 7. 5."
],
"key_amounts": [
"300,000,000원"
],
"key_parties": [
"강용원",
"오민한"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 26
},
"property_cluster_id": "해당 주거용 부동산",
"doc_semantic_flags": [
"claim_doc"
],
"loan_components": [
{
"loan_component_id": "E-026-LC-01",
"principal_amount": "300,000,000원",
"loan_date": "2023-07-06",
"due_date": "2024-07-05",
"agreed_interest_rate": "연 15%",
"collateral_object_hint": "서울 성동구 성수동 256 대 330㎡의 5분의 3 지분",
"role_in_claim_hint": "차용"
}
],
"secured_debt_components": [
{
"due_date": "2024-07-05",
"agreed_interest_rate": "연 15%"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,62 @@
{
"evidence_index_proposed": "E-027",
"doc_uid": "DOC-027-최고_통지서",
"title": "최고 통지서",
"title_normalized": "최고 통지서",
"doc_type": "처분문서",
"key_facts": [
"2021. 6. 5. 강용원이 김선웅에게 2억 원 상당 인테리어 자재 납품",
"2024. 5. 4. 강용원이 김선웅에게 대금 지급 최고 통지서 발송",
"2024. 5. 6. 김선웅에게 최고 통지서 도달"
],
"key_dates": [
"2021-06-05",
"2024-05-04",
"2024-05-06"
],
"key_amounts": [
"200,000,000원"
],
"key_parties": [
"강용원",
"김선웅"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 27
},
"doc_semantic_flags": [
"claim_doc",
"notice_doc"
],
"claim_document_components": [
{
"component_kind": "demand_notice",
"dispatch_date": "2024-05-04",
"arrival_date": "2024-05-06"
}
],
"notice_components": [
{
"notice_id_proposed": "E-027-NT-01",
"notice_type": "최고",
"dispatch_date": "2024-05-04",
"arrival_date": "2024-05-06",
"received_date": "2024-05-06",
"sender_candidates": [
"강용원"
],
"receiver_candidates": [
"김선웅"
],
"receipt_evidence_refs": [
"우편물 배달 증명서"
]
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,52 @@
{
"evidence_index_proposed": "E-028",
"doc_uid": "DOC-028-통지서",
"title": "통지서",
"title_normalized": "통지서",
"doc_type": "처분문서",
"key_facts": [
"오민한의 김선웅 채무 책임 부인",
"오민한의 채무 시효 소멸 주장",
"오민한의 채무 인수 당시 책임 배제 약정 주장"
],
"key_dates": [
"2024-12-27"
],
"key_amounts": [],
"key_parties": [
"오민한",
"강용원",
"김선웅"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 28
},
"doc_semantic_flags": [
"notice_doc",
"response_doc"
],
"notice_components": [
{
"notice_id_proposed": "E-028-NT-01",
"notice_type": "기타",
"dispatch_date": "2024-12-27",
"sender_candidates": [
"오민한"
],
"receiver_candidates": [
"강용원"
]
}
],
"defense_assertions": [
"김선웅의 채무 인수 당시 책임 배제 약정 존재",
"물품대금 채무 시효 소멸",
"본인에게 채무 책임 없음"
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,44 @@
{
"evidence_index_proposed": "E-029",
"doc_uid": "DOC-029-통지서_이수인_윤건우",
"title": "통지서_이수인_윤건우",
"title_normalized": "통지서 이수인 윤건우",
"doc_type": "통신기록",
"key_facts": [
"이수인이 윤건우에게 흑석동 상가 매매계약 관련 매매대금 감액 및 제3자 명의 등기 요청"
],
"key_dates": [
"2024-03-30"
],
"key_amounts": [],
"key_parties": [
"이수인",
"윤건우"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 29
},
"doc_semantic_flags": [
"notice_doc"
],
"notice_components": [
{
"notice_id_proposed": "E-029-NT-01",
"notice_type": "기타",
"dispatch_date": "2024-03-30",
"sender_candidates": [
"이수인"
],
"receiver_candidates": [
"윤건우"
],
"target_object_hint": "흑석동 상가"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,50 @@
{
"evidence_index_proposed": "E-030",
"doc_uid": "DOC-030-해제_통지서",
"title": "해제 통지서",
"title_normalized": "해제 통지서",
"doc_type": "처분문서",
"key_facts": [
"2023.10.1. 흑석동 상가 매매계약 체결",
"2024.5.15. 윤건우가 이수인에게 매매계약 해제 통지",
"2024.5.16. 해제 통지서 수령"
],
"key_dates": [
"2023-10-01",
"2024-05-15",
"2024-05-16"
],
"key_parties": [
"윤건우",
"이수인"
],
"source_pointer": {
"source": "evidence_all.json",
"ordinal": 30
},
"doc_semantic_flags": [
"notice_doc",
"response_doc"
],
"notice_components": [
{
"notice_id_proposed": "E-030-NT-01",
"notice_type": "해제통지",
"dispatch_date": "2024-05-15",
"arrival_date": "2024-05-16",
"sender_candidates": [
"윤건우"
],
"receiver_candidates": [
"이수인"
],
"target_object_hint": "흑석동 상가",
"legal_effect_date_candidate": "2024-05-16"
}
],
"mapper_meta": {
"mapper_task": "Task_B1_map_doc",
"schema_contract_version": "evidence_indexed_part.v4",
"self_isolation_attested": true
}
}
@@ -0,0 +1,58 @@
{
"source_file": "가정법원심판_강호연.json",
"content": [
{
"type": "text",
"content": "서 울 가 정 법 원"
},
{
"type": "text",
"content": "심 판"
},
{
"type": "table",
"grid": [
[
"사 건",
"2024느단52199 상속포기"
],
[
"청 구 인",
"1. 강형수\n2. 강지수\n청구인들 주소 서울 관악구 봉천3길 12, 301호\n (성현동, 성현연립)\n청구인들 등록기준지 경기 평택군 송탄읍 서정리 111\n청구인들 소송대리인 변호사 김수현, 최진혁"
],
[
"피 상 속 인",
"망 강호연\n2024. 8. 10. 사망\n최후주소 서울 관악구 봉천3길 12, 301호(성현동, 성현연립)\n등록기준지 경기 평택군 송탄읍 서정리 111"
]
]
},
{
"type": "text",
"content": "주 문"
},
{
"type": "text",
"content": "청구인들이 피상속인 망 강호연의 재산상속을 포기하는 2024. 9. 11. 자 신고는 이를 수리한다."
},
{
"type": "text",
"content": "이 유"
},
{
"type": "text",
"content": "이 사건 청구는 이유 있으므로 주문과 같이 심판한다."
},
{
"type": "text",
"content": "2024. 9. 20.\n\n사법보좌관 이승희"
},
{
"type": "text",
"content": "정본입니다.\n2024. 10. 8.\n법원주사 최지현"
},
{
"type": "text",
"content": "서울가\n정법원\n주사인"
}
]
}
@@ -0,0 +1,114 @@
{
"source_file": "가족관계증명서_강호연.json",
"content": [
{
"type": "text",
"content": "가족관계증명서 [폐쇄]"
},
{
"type": "table",
"grid": [
[
"등록기준지",
"경기도 평택군 송탄읍 서정리 111"
]
]
},
{
"type": "table",
"grid": [
[
"구 분",
"성 명",
"출생연월일",
"주민등록번호",
"성별",
"본"
],
[
"본 인",
"강호연(姜鎬然) 사망",
"1973년 5월 19일",
"730519-1******",
"남",
"晉州"
]
]
},
{
"type": "text",
"content": "가 족 사 항"
},
{
"type": "table",
"grid": [
[
"구 분",
"성 명",
"출생연월일",
"주민등록번호",
"성별",
"본"
],
[
"부",
"강용원(姜容元)",
"1947년 12월 11일",
"471211-1******",
"남",
"晉州"
],
[
"모",
"김순자(金順子) 사망",
"1949년 8월 10일",
"490810-2******",
"여",
"全州"
]
]
},
{
"type": "table",
"grid": [
[
"배우자",
"양정숙(梁晶淑)",
"1974년 11월 21일",
"741121-2******",
"여",
"濟州"
]
]
},
{
"type": "table",
"grid": [
[
"자녀",
"강형수(姜亨壽)",
"2000년 3월 18일",
"000318-3******",
"남",
"晉州"
],
[
"자녀",
"강지수(姜智壽)",
"2002년 11월 30일",
"021130-4******",
"여",
"晉州"
]
]
},
{
"type": "text",
"content": "위 가족관계증명서는 가족관계등록부의 기록사항과 틀림없음을 증명합니다."
},
{
"type": "text",
"content": "서기 2024년 12월 27일\n서울특별시 관악구청장 서울특\n별시관\n악구청\n장의인"
}
]
}
@@ -0,0 +1,37 @@
{
"source_file": "각서_금전대차소비계약서_오국한_오민환.json",
"content": [
{
"type": "text",
"content": "각 서"
},
{
"type": "text",
"content": "1. 각서인 오국한은 오민한의 요청으로 매수자금 4,000만 원을 받아 서울 관악구 신림동 779 지상 단층 근린상가를 이경주로부터 매수하여 각서인 명의로 등기를 마쳤습니다. 따라서 위 신림동 상가는 명의만 오국한으로 되어 있을 뿐, 오민한(540607-1******) 소유임을 확인합니다.\n2. 향후 본인은 어떠한 경우에도 이경주에게 실제 매수인이 오민한임을 밝히지 않을 것이고, 추후 신림동 상가에 대한 소유권 등 어떠한 권리도 주장하지 않을 것임을 약속합니다.\n3. 만일 본인이 위 약속을 어길 시 어떠한 민형사상 처벌도 감수할 것임을 분명하게 약속합니다."
},
{
"type": "text",
"content": "2015년 9월 17일"
},
{
"type": "text",
"content": "각서인 오 국 한 (470415-1******) (인)吳漢\n菊"
},
{
"type": "text",
"content": "금전소비대차계약서"
},
{
"type": "text",
"content": "오국한은 오민한으로부터 아래와 같이 1,000만 원을 차용하고, 변제기일까지 이를 틀림없이 지급하겠습니다.\n원 금 : 10,000,000원\n변제기 : 2023. 7. 17."
},
{
"type": "text",
"content": "2022. 7. 18."
},
{
"type": "text",
"content": "대여인 : 오민한 (540607-1******) (인)吳民\n印\n차용인 : 오국한 (470415-1******) (인)吳漢\n菊"
}
]
}

Some files were not shown because too many files have changed in this diff Show More