diff --git a/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.7/Analysis_Stage_1_Codex_v1.md b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.7/Analysis_Stage_1_Codex_v1.md new file mode 100644 index 00000000..f4a01cfa --- /dev/null +++ b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.7/Analysis_Stage_1_Codex_v1.md @@ -0,0 +1,1337 @@ +# Analysis of whole Tasks in Stage 1 + +## 문서 범위와 전체 구조 + +이 문서는 `Stage_1_Part_1_Codex_v3.yml`부터 `Stage_1_Part_4_Codex_v3.yml`까지를 실제 실행 순서대로 분석한 문서이다. Stage 1의 법률적 목적은 의뢰인의 진술과 증거 문서를 바로 법적 결론으로 치환하는 것이 아니라, 출처가 추적되는 사실ㆍ행위ㆍ법률효과 후보를 단계적으로 정규화하여 Stage 2가 청구원인, 항변, 당사자 적격, 법률효과를 안전하게 판단할 수 있는 증거 기반을 만드는 데 있다. + +전체 설계는 다음 네 층으로 구성된다. + +1. Part 1은 의뢰인 목표와 증거별 문서ㆍ사건 후보를 추출하고 품질 게이트를 통과시킨다. +2. Part 2는 추출 결과를 법률행위 및 상태 단위의 `BO`로 편성하고, 전문 영역별 신호를 생성한다. +3. Part 3은 BO와 신호 사이의 관계를 법률효과 구조 및 역색인으로 조직한다. +4. Part 4는 BO마다 하나의 보존 가능한 사실 레코드를 생성하여 `Fact_Ledger_base.json`으로 봉인한다. + +```text +client_meeting.md + evidence_all.json + Juristic_Act.md + | + v ++--------------------------------------------------------------+ +| Part 1: 의뢰 목적ㆍ증거 문서ㆍ사건 후보 추출 및 품질 게이트 | ++--------------------------------------------------------------+ + | client_goal.json + | evidence_indexed.json + | evidence_event_candidates.json + | Part 1 quality/review handoff + v ++--------------------------------------------------------------+ +| Part 2: 영역별 BO seed 생성ㆍ예외 판정ㆍ최종 BO 및 신호 생성| ++--------------------------------------------------------------+ + | BO.json + | actio_case_signals.json + | case_liability_signals.json + | legal_effect_signals.json + v ++--------------------------------------------------------------+ +| Part 3: 법률효과 구조 seedㆍ예외 판정ㆍ구조 그래프 인덱싱 | ++--------------------------------------------------------------+ + | legal_effect_structures.json + v ++--------------------------------------------------------------+ +| Part 4: BO 보존형 Fact Ledger 생성ㆍ예외 판정ㆍ최종 봉인 | ++--------------------------------------------------------------+ + | + v +Fact_Ledger_base.json + writer report + review/drafting gates +``` + +이 구조의 핵심은 결정 가능한 병합ㆍ검증ㆍID 부여ㆍ정렬ㆍ직렬화는 Python이 담당하고, 문서 의미 해석이나 서로 양립할 수 없는 후보 중 하나를 선택해야 하는 경우에만 LLM을 사용한다는 점이다. 또한 Part 2부터 Part 4까지 최종 산출물은 각각 하나의 Python writer만 작성한다. 이 단일 writer 원칙은 LLM의 자유로운 파일 수정으로 인한 ID 손실, 중복, 출처 단절을 방지한다. + +--- + +## Section 1: Analysis of Stage 1 -- Part 1 + +### 1.1 Ultimate Goal of Part 1 + +Part 1의 궁극적 목표는 원시 입력인 `client_meeting.md`와 `evidence_all.json`을 두 종류의 신뢰 가능한 사실 기반으로 변환하는 것이다. + +- 첫째, 의뢰인이 누구를 상대로 어떤 구제를 원하는지, 당사자 적격과 승계ㆍ지분ㆍ점유ㆍ담보ㆍ사해행위 쟁점이 무엇인지 `client_goal.json`에 구조화한다. +- 둘째, 모든 증거 항목을 빠짐없이 `evidence_indexed.json`에 정규화하고, 각 증거가 지지하는 사건ㆍ상태 후보를 `evidence_event_candidates.json`에 생성한다. +- 셋째, 증거 ID와 사건 후보의 보존, 출처 참조, 날짜ㆍ금액ㆍ당사자ㆍ자산 키의 구조적 정합성을 품질 게이트로 검증한다. +- 넷째, 자동 진행 가능한 결과와 변호사 검토가 필요한 결과를 분리하여 Part 2가 불확실성을 숨기지 않고 이어받도록 한다. + +법률적으로 Part 1은 증거의 내용과 의뢰인의 법적 목표를 분리해서 기록하는 단계이다. 의뢰인의 주장은 증거로 확정된 사실이 아니며, 증거 문서의 문언도 곧바로 법률효과의 확정을 의미하지 않는다. 따라서 Part 1은 중립적인 사건 후보와 검토 힌트를 만들되, 최종 법률판단을 하지 않는다. + +### 1.2 Detailed Workflow and DAG + +```text +client_meeting.md --> +----------------------------+ + | Task_A_client_goal | + | 의뢰 목적 독립 구조화 | + +-------------+--------------+ + | + +--> client_goal.json + +evidence_all.json + | + v ++---------------------------------------+ +| Task_Evidence_shard_planner | +| E-### 단위 shardㆍfan-out 계획 생성 | ++-------------------+-------------------+ + | + +--> evidence_shards/E-001.json + +--> evidence_shards/E-002.json + +--> ... + | + v ++---------------------------------------+ +| Task_B1_map_doc_* | +| 문서별 증거 index 후보 생성 | ++-------------------+-------------------+ + | matching ordinal edge + v ++---------------------------------------+ +| Task_B2_map_events_* | +| 문서별 사건ㆍ상태 후보 생성 | ++-------------------+-------------------+ + | + +------------------------------+ + | +all B1 parts | all B2 parts + | | + v | ++---------------------------------------+ | +| Task_B1_gate_merge_deterministic | | +| 증거 보존ㆍ정렬ㆍprecheck | | ++-------------------+-------------------+ | + | | + +--------------+---------------+ + v + +---------------------------------------+ + | Task_B2_gate_merge_deterministic | + | 사건 보존ㆍ중복검사ㆍexception pack | + +------------------+--------------------+ + | + +---------------+----------------+ + | | + | exception_count > 0 | exception_count = 0 + v | + +----------------------------------------+ | + | Task_B1B2_gate_llm_adjudicator_* | | + | conditional fan-out, 0..N packs | | + +--------------------+-------------------+ | + | | + +------------+-----------+ + v + +---------------------------------------+ + | Task_B12_gate_audit_finalizer | + | B1/B2 최종 gate 판정 | + +------------------+--------------------+ + | + v + +---------------------------------------+ + | Task_B2_SHA256_soft_gate_ | + | handoff_writer | + | digestㆍreview routing 봉인 | + +---------------------------------------+ +``` + +`Task_A_client_goal`은 증거 shard 경로와 병렬로 실행되는 독립 작업이다. 나머지 경로는 증거 보존을 위한 주 경로이다. B1과 B2 mapper는 동일한 ordinal을 사용하며, B2는 대응하는 B1 문서 분석을 입력으로 받아 사건 후보를 생성한다. 모든 B1ㆍB2 결과가 모인 뒤에만 결정적 병합을 수행한다. LLM adjudicator는 exception pack이 실제로 존재할 때만 동적 fan-out으로 실행한다. + +### 1.3 IO Structure of Part 1 + +#### 1.3.1 IN files + +| 파일 | 소비 작업 | 역할 | +|---|---|---| +| `client_meeting.md` | Task A, B1, B2 | 의뢰인의 목표, 진술, 당사자ㆍ청구ㆍ쟁점 맥락을 제공하는 원천이다 | +| `evidence_all.json` | shard planner | 전체 증거 문서 집합이며 보존 검사의 기준 universe이다 | + +Part 1은 개별 증거를 직접 병렬 처리하지 않고 먼저 `evidence_shards/E-###.json`으로 분할한다. 각 shard는 하나의 원 증거 ordinal과 대응하며, 이후 파일명ㆍproposed IDㆍfinal ID의 기준이 된다. + +#### 1.3.2 OUT files + +| 구분 | 파일 | 생성 작업 | downstream 의미 | +|---|---|---|---| +| 최종 | `client_goal.json` | Task A | 의뢰 목적, 당사자 적격, 청구ㆍ항변ㆍ승계ㆍ지분 쟁점의 구조화 결과이다 | +| 중간 | `evidence_shard_plan.json` | shard planner | 기대 ordinal, evidence ID, fan-out, barrier, stale-part 정책을 고정한다 | +| 중간 | `evidence_shards/E-###.json` | shard planner | B1 mapper가 읽는 단일 증거 shard이다 | +| 중간 | `evidence_indexed_parts/E-###.json` | B1 mapper | 문서별 정규화 후보이다 | +| 중간 | `evidence_event_candidate_parts/E-###.json` | B2 mapper | 문서별 사건ㆍ상태 후보이다 | +| 최종 | `evidence_indexed.json` | B1 deterministic merge | 전체 증거 문서의 정규화 index이다 | +| 중간 | `finalized_evidence_id_manifest.json` | B1 deterministic merge | 기대 ID와 최종 ID의 집합 보존 및 digest를 기록한다 | +| 중간 | `quality_gates/B1_gate_precheck.json` | B1 deterministic merge | parseㆍordinalㆍIDㆍ출처 이상을 LLM 이전에 검출한다 | +| 최종 | `evidence_event_candidates.json` | B2 deterministic merge | 전체 사건ㆍ상태 후보 집합이다 | +| 중간 | `quality_gates/B2_gate_precheck.json` | B2 deterministic merge | 사건 후보의 보존ㆍ중복ㆍ참조ㆍ불변식 검사 결과이다 | +| 중간 | `quality_gates/B12_exception_pack.json` | B2 deterministic merge | LLM 판단이 필요한 국소 예외만 포함한다 | +| 중간 | `quality_gates/stage1_part1_gate_adjudication_parts/PACK-###.json` | gate LLM adjudicator | 예외별 판정 결과이다 | +| 최종 | `quality_gates/B1_evidence_indexed_gate.json` | audit finalizer | B1 최종 품질ㆍ진행 가능 여부를 기록한다 | +| 최종 | `quality_gates/B2_event_candidates_gate.json` | audit finalizer | B2 최종 품질ㆍ진행 가능 여부를 기록한다 | +| 최종 | `quality_gates/stage1_part1_soft_gate_handoff.json` | handoff writer | SHA-256, review queue, 자동 진행 정책을 Part 2에 전달한다 | + +### 1.4 Description of Each Sub-task + +#### 1.4.1 `Task_A_client_goal` + +- **실행 유형과 모델:** LLM, Google `gemini-3.1-flash-lite`이다. +- **목표:** 의뢰인의 사실 진술과 원하는 구제를 법률 쟁점 단위로 구조화하되, 증거로 확정되지 않은 내용을 확정 사실처럼 취급하지 않는 것이다. +- **수행 방법:** `client_meeting.md`를 읽고 주요 목표, 제약, 사건 개요, 당사자ㆍ별칭, 청구유형 후보, issue cluster, 원고 적격, 현재 지배ㆍ점유 상태, 승계ㆍ지분ㆍ담보ㆍ사해행위ㆍ항변 검토 힌트를 생성한다. `issue_clusters`는 이후 BO가 어떤 법률영역으로 라우팅될지를 예고하지만, 법률효과를 확정하지 않는다. +- **IO 정렬:** `client_meeting.md` 한 파일을 읽어 `client_goal.json` 한 파일을 생성한다. 이 경로는 증거 mapper와 독립적이며, Part 1 종료 후 Part 2 이후의 의뢰 목적 해석에 사용할 수 있다. + +#### 1.4.2 `Task_Evidence_shard_planner` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** `evidence_all.json`의 모든 증거를 하나도 빠뜨리지 않고 안정적인 ordinal 단위로 분할하는 것이다. +- **수행 방법:** 입력 배열을 검증하고 각 항목에 `E-###` ordinal을 부여한다. 기대 ordinal과 evidence ID 집합, shard 수, mapper fan-out, matching edge, barrier, stale part 처리 정책을 기록한다. 기존 실행에서 남은 stale part가 현재 계획에 섞이지 않도록 유효 shard universe를 고정한다. +- **IO 정렬:** `evidence_all.json`을 읽고 `evidence_shard_plan.json`과 `evidence_shards/E-###.json`을 쓴다. stdout의 `dynamic_fanout`이 B1 mapper 인스턴스를 생성한다. + +#### 1.4.3 `Task_B1_map_doc_*` + +- **실행 유형과 모델:** shard별 LLM fan-out, Google `gemini-3.1-flash-lite`이다. +- **목표:** 한 증거 문서를 문서 단위의 중립적이고 구조화된 evidence index 후보로 변환하는 것이다. +- **수행 방법:** 배정된 shard와 의뢰인 면담을 읽고 문서 제목ㆍ유형ㆍ당사자ㆍ날짜ㆍ금액ㆍ출처 포인터를 추출한다. 계약, 대여금, 변제, 등기행, 담보채무, 감정가, 영업양도, 승계, 통지, 점유, 지분 등 문서에 실제 존재하는 named component만 채운다. 문서에 없는 법률효과를 추론해서 만들지 않으며, 출처 locator와 원 evidence ordinal을 보존한다. +- **IO 정렬:** `evidence_shards/E-###.json`과 `client_meeting.md`를 읽고 동일 ordinal의 `evidence_indexed_parts/E-###.json`을 생성한다. 이 파일은 대응 B2 mapper와 B1 merge가 함께 소비한다. + +#### 1.4.4 `Task_B2_map_events_*` + +- **실행 유형과 모델:** shard별 LLM fan-out, Google `gemini-3.1-flash-lite`이다. +- **목표:** 문서가 증명하거나 주장하는 복수의 사건ㆍ상태를 최소 원자 단위 후보로 분리하는 것이다. +- **수행 방법:** 배정된 원 증거 shard와 동일 ordinal의 B1 결과를 함께 읽는다. 계약 체결, 채권 발생, 변제기, 지급, 독촉ㆍ도달, 승인, 근저당 설정ㆍ말소, 소유권 이전, 지분별 담보 효력, 점유 개시ㆍ종료, 통지, 상속ㆍ승계 등 시간 순서를 갖는 사건을 각각 분리한다. 하나의 문서에 여러 사건이 있으면 여러 후보를 만들며, 실제 사건이 없으면 `zero_event_reason`을 명시한다. +- **IO 정렬:** B1 part가 완료된 같은 ordinal에서만 시작한다. `evidence_event_candidate_parts/E-###.json`은 이후 B2 merge의 입력이 된다. + +#### 1.4.5 `Task_B1_gate_merge_deterministic` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** 모든 B1 part를 원 증거 universe와 대조하여 증거 보존을 보장하고 하나의 최종 index로 병합하는 것이다. +- **수행 방법:** shard plan의 기대 ordinal과 실제 part 파일을 비교한다. 누락ㆍ중복ㆍ예상 밖 ordinalㆍparse 실패ㆍstale partㆍ잘못된 source pointer를 검출한다. 유효 part를 ordinal 순서로 정렬하고 최종 evidence ID를 고정한다. ID 집합의 SHA-256을 계산하며, 결정적으로 판단할 수 없는 의미 문제는 review candidate로만 분리한다. +- **IO 정렬:** 모든 B1 part와 shard plan을 읽어 `evidence_indexed.json`, `finalized_evidence_id_manifest.json`, `B1_gate_precheck.json`을 쓴다. B2 merge는 이 세 산출물이 존재해야 시작한다. + +#### 1.4.6 `Task_B2_gate_merge_deterministic` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** 모든 B2 part를 병합하면서 사건 후보 수와 출처 참조를 보존하고, LLM이 볼 필요가 있는 예외만 국소화하는 것이다. +- **수행 방법:** 기대 ordinal과 B2 part를 대조하고, 각 문서가 `event_candidates` 또는 `zero_event_reason` 중 하나를 갖는지 검사한다. 사건 ID, source evidence ID, 날짜ㆍ금액ㆍ자산ㆍ지분 키, 중복 signature, candidate conservation을 검증한다. 형식 오류나 보존 실패는 hard finding으로 처리하고, 의미상 양립 불가능한 후보만 exception으로 포장한다. +- **IO 정렬:** B1 최종 indexㆍmanifestㆍprecheck와 모든 B2 part를 읽어 `evidence_event_candidates.json`, `B2_gate_precheck.json`, `B12_exception_pack.json`을 쓴다. exception pack 수가 0이면 LLM 경로를 건너뛴다. + +#### 1.4.7 `Task_B1B2_gate_llm_adjudicator_*` + +- **실행 유형과 모델:** exception pack별 조건부 LLM fan-out, Google `gemini-3.1-flash-lite`이다. +- **목표:** Python 규칙만으로 판정할 수 없는 제한된 B1ㆍB2 품질 예외를 판단하는 것이다. +- **수행 방법:** 전체 증거를 다시 읽지 않고 배정된 pack만 읽는다. 각 예외에 대해 닫힌 decision enum, severity, candidate use policy, review instruction, 간결한 근거를 반환한다. 출처가 없는 사실을 추가하거나 원본 산출물을 직접 수정하지 않는다. +- **IO 정렬:** `PACK-###` 하나를 읽어 같은 pack ID의 adjudication part 하나를 쓴다. 결과는 audit finalizer만 소비한다. + +#### 1.4.8 `Task_B12_gate_audit_finalizer` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** precheck와 모든 예외 판정을 완전성 있게 결합하여 B1ㆍB2의 최종 진행 상태를 봉인하는 것이다. +- **수행 방법:** expected exception ID와 adjudication decision ID가 정확히 일치하는지 검사한다. hard failure, warning, review required를 분리하고 rerun target, Stage 2 risk note, downstream progression 정책을 계산한다. LLM이 누락한 예외가 있거나 coverage가 불완전하면 통과시키지 않는다. +- **IO 정렬:** 두 precheck, exception pack, adjudication parts를 읽어 B1 및 B2 최종 gate 파일을 각각 쓴다. + +#### 1.4.9 `Task_B2_SHA256_soft_gate_handoff_writer` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** Part 2가 Part 1 결과의 동일성과 검토 상태를 검증할 수 있는 최소 handoff surface를 생성하는 것이다. +- **수행 방법:** `evidence_indexed.json`과 `evidence_event_candidates.json` 및 두 gate 파일의 SHA-256을 계산한다. 자동 진행 가능 여부, hard/review 요약, review item의 source routing, 변호사 workflow queue를 작성한다. 이 파일은 증거 내용을 복제하지 않고 참조와 digest만 제공한다. +- **IO 정렬:** Part 1의 최종 증거ㆍ사건ㆍgate 파일을 읽어 `stage1_part1_soft_gate_handoff.json`을 쓴다. + +### 1.5 JSON Formats of Part 1 Outputs + +#### 1.5.1 `client_goal.json` + +대표 구조는 다음과 같다. + +```json +{ + "primary_goal": "string", + "constraints": ["string"], + "summary_key_incidents": ["string"], + "key_facts": ["string"], + "claim_type_candidates": ["string"], + "parties": { + "plaintiffs": [], + "defendants": [], + "third_parties": [] + }, + "aliases": [], + "defendant_target_matrix": [], + "issue_clusters": [ + { + "issue_cluster_id": "string", + "issue_label": "string", + "candidate_plaintiffs": [], + "candidate_counterparties": [], + "candidate_legal_entitlements": [], + "client_requested_relief": [], + "domain_profiles": {}, + "legal_sustainability_watchpoints": [] + } + ], + "plaintiff_capacity_matrix": [], + "current_control_map": [], + "current_control_map_4axis": [], + "standing_watchpoints": [] +} +``` + +`issue_clusters` 내부에는 monetary claim, secured property, actio, possessionㆍlienㆍsuccession 등 영역별 profile과 successorㆍfractionㆍleaseㆍpreserved claimㆍvalue compensationㆍdefense hint가 포함될 수 있다. 이 값은 쟁점 탐색용이지 확정 법률판단이 아니다. + +#### 1.5.2 `evidence_shard_plan.json` + +```json +{ + "schema_version": "evidence_shard_plan.v1", + "source": "evidence_all.json", + "source_count": 0, + "expected_ordinals": [], + "expected_evidence_ids": [], + "ordinal_policy": {}, + "shards": [], + "dynamic_fanout": [], + "fanout_meta": {}, + "streaming_edges": [], + "barriers": [], + "stale_part_policy": {}, + "planner_status": "READY|BLOCKED", + "mapper_execution_allowed": true, + "blocked_reason": null +} +``` + +#### 1.5.3 B1 mapper part와 `evidence_indexed.json` + +B1 part는 `evidence_indexed_part.v4` 계약을 사용한다. 핵심 필드는 다음과 같다. + +```json +{ + "schema_version": "evidence_indexed_part.v4", + "evidence_index_proposed": "E-001", + "doc_uid": "string", + "title": "string", + "title_normalized": "string", + "doc_type": "string", + "key_facts": [], + "key_dates": [], + "key_amounts": [], + "key_parties": [], + "source_pointer": {}, + "property_cluster_id": null, + "doc_semantic_flags": [], + "contract_components": {}, + "claim_document_components": {}, + "registry_row_components": [], + "secured_debt_components": {}, + "valuation_rows": [], + "loan_components": {}, + "succession_components": {}, + "notice_components": {}, + "mapper_meta": {} +} +``` + +최종 파일은 wrapper를 단순화한 다음 형식이다. + +```json +{ + "schema_contract_version": "evidence_indexed.v3", + "items": [] +} +``` + +각 `items` 원소에는 mapper part의 정규화 필드가 유지된다. 문서 성격에 따라 valuation matrix, registry row role map, defenseㆍadmissionㆍparty assertion, payment schedule, registry object display, business transfer, mixed contract payment semantics 같은 component가 추가된다. + +#### 1.5.4 B2 mapper part와 `evidence_event_candidates.json` + +```json +{ + "schema_version": "evidence_event_candidate_part.v4", + "evidence_index_proposed": "E-001", + "title": "string", + "doc_type": "string", + "source_pointer": {}, + "property_cluster_id": null, + "zero_event_reason": null, + "affected_asset_cluster_ids": [], + "event_candidates": [ + { + "event_id_proposed": "string", + "event_or_state": "event|state", + "event_kind": "string", + "event_subkind": "string", + "action_type": "string", + "action_summary": "string", + "source_evidence_index_proposed": "E-001", + "source_fact_candidate": "string", + "participants": [], + "object_ref": null, + "fraction_id": null, + "amount": null, + "date": null, + "date_end": null, + "time_precision": "string", + "support_locators": [], + "current_state_hints": {}, + "legal_effect_hints": {}, + "identity_signature": "string", + "confidence": "high|medium|low" + } + ] +} +``` + +최종 파일은 다음 형식을 사용한다. + +```json +{ + "schema_version": "evidence_event_candidates.v1", + "items": [] +} +``` + +한 문서별로 `event_candidates`가 비어 있다면 `zero_event_reason`이 반드시 존재해야 한다. 이는 문서 소실과 정상적인 무사건 문서를 구분하는 보존 불변식이다. + +#### 1.5.5 Gate와 handoff JSON + +`finalized_evidence_id_manifest.v1`은 기대ㆍ최종ㆍ누락ㆍ예상 밖 ID와 ID-set SHA를 기록한다. `B1_gate_precheck.v1`과 `B2_gate_precheck.v1`은 ordinal 집합, parse failure, hard finding, review candidate, 보존 count, 개별 check와 metric을 기록한다. + +예외 판정 파일은 다음 공통 골격을 사용한다. + +```json +{ + "schema_version": "stage1_part1_gate_adjudication_part.v1", + "pack_id": "PACK-001", + "status": "READY|READY_WITH_REVIEW|FAILED", + "decisions": [ + { + "exception_id": "string", + "exception_type": "string", + "decision": "closed enum", + "severity": "string", + "source_refs": {}, + "candidate_use_policy": "string", + "review_instruction": "string", + "concise_basis": "string" + } + ] +} +``` + +최종 B1ㆍB2 gate는 각각 `B1_quality_gate.v4`, `B2_quality_gate.v4`를 사용하고 다음 정보를 보유한다. + +- `checks`, `overall_severity`, `block_reasons`, `warning_reasons` +- `hard_findings`, `review_findings`, `rerun_targets` +- `stage2_risk_notes`, `review_summary`, `handoff_summary` +- `downstream_progression`, `auto_progression_allowed` + +최종 soft handoff는 다음 골격을 사용한다. + +```json +{ + "schema_version": "stage1_part1_soft_gate_handoff.v1", + "source_stage": "stage1_part1", + "source_files": {}, + "handoff_status": "READY|READY_WITH_REVIEW|BLOCKED", + "auto_progression_allowed": true, + "hard_summary": {}, + "review_summary": {}, + "sha256_digest_guard": {}, + "review_items": [], + "routing_index": {}, + "lawyer_workflow_queues": {} +} +``` + +--- + +## Section 2: Analysis of Stage 1 -- Part 2 + +### 2.1 Ultimate Goal of Part 2 + +Part 2의 궁극적 목표는 Part 1의 문서ㆍ사건 후보를 민사소송 분석에 사용할 수 있는 법률행위ㆍ사실상태 단위의 `BO`로 편성하고, 특수 법률영역의 downstream 분석에 필요한 세 종류의 signal을 만드는 것이다. + +`BO`는 법률효과를 확정한 판결문형 결론이 아니다. 각 행은 하나의 event 또는 state 후보와 그 출처, 법률 키워드, 전문 영역 payload, downstream 연결 힌트를 담는 중간 객체이다. Part 2는 대여금ㆍ변제ㆍ승계, 담보ㆍ등기, 토지사용ㆍ가치평가, 사해행위, 상속ㆍ통지ㆍ유치권ㆍ자산 aliasㆍ항변을 서로 다른 domain worker에 배정한다. 이후 Python reducer가 중복과 충돌을 통제하고, 진정한 교차영역 예외만 LLM에 보낸다. + +법률적으로 이 단계는 동일한 증거가 여러 법률요건과 관련되는 상황을 보존하는 것이 중요하다. 예컨대 지급 사실은 대여금 채무의 소멸, 담보채무 잔액, 사해행위 피보전채권액에 동시에 영향을 줄 수 있다. 그러므로 near-duplicate를 성급히 하나로 합치지 않고, 출처와 domain role을 유지한 상태로 최종 BO를 작성한다. + +### 2.2 Detailed Workflow and DAG + +```text +Part 1 artifacts + Juristic_Act.md + | + v ++--------------------------------------------------+ +| Task_C_BO_A0_context_domain_slice_compiler | +| 공통 contextㆍsource universeㆍ5 domain slice | ++------------------------+-------------------------+ + | + +---------+-------+-------+---------+ + | | | | + v v v v + [B1 Money/ [B2 Secured/ [B3 Land/ [B4 Actio] + Successor] Registry] Valuation] + | | | | + | | +-------+ | + | | | | + | | | +---------+ + | | | | + | | | | [B5 Succession/ + | | | | Notice/Lien/...] + | | | | | + +---------+-------+-------+-------------+ + | + v ++--------------------------------------------------+ +| Task_C_BO_R0_seed_reducer_exception_planner | +| 결정적 mergeㆍreview queueㆍtrue exception pack | ++------------------------+-------------------------+ + | + +------------+----------------+ + | | + | exception_count > 0 | exception_count = 0 + v | ++-----------------------------------------+ | +| Task_C_BO_R1_exception_adjudicator_* | | +| conditional fan-out, 0..N packs | | ++---------------------+-------------------+ | + | | + +-------------+--------------+ + v ++--------------------------------------------------+ +| Task_C_BO_F0_final_bo_gate_writer | +| fingerprintㆍcoverageㆍsource membershipㆍBO write| ++------------------------+-------------------------+ + | + v ++--------------------------------------------------+ +| Task_C_BO_S0_signal_bundle_writer | +| actioㆍliabilityㆍlegal-effect signal 파생 | ++--------------------------------------------------+ +``` + +### 2.3 IO Structure of Part 2 + +#### 2.3.1 IN files + +| 파일 | 필수 여부 | 역할 | +|---|---:|---| +| `client_meeting.md` | 필수 | 면담 문구와 의뢰 목적의 source clause를 제공한다 | +| `evidence_indexed.json` | 필수 | 문서 authority와 named component를 제공한다 | +| `evidence_event_candidates.json` | 필수 | BO 후보가 될 사건ㆍ상태 universe를 제공한다 | +| `Default_Agent/Juristic_Act.md` | 필수 | 허용되는 법률행위 taxonomy와 용어 기준을 제공한다 | +| `quality_gates/stage1_part1_soft_gate_handoff.json` | 조건부 sidecar | Part 1 review item, digest, 자동 진행 상태를 전달한다 | + +Part 2는 `evidence_all.json`을 재독해하지 않는다. A0가 Part 1의 정규화 산출물만을 source universe로 편성하므로, 입력 범위가 명시적으로 제한된다. + +#### 2.3.2 OUT files + +| 구분 | 파일 | 생성 작업 | 역할 | +|---|---|---|---| +| 중간 | `stage1_tmp/task_c_bo/stage_a_context.json` | A0 | 공통 clauseㆍeventㆍevidenceㆍtaxonomyㆍhazard context이다 | +| 중간 | `stage1_tmp/task_c_bo/source_universe_manifest.json` | A0 | 입력 digest와 전역 ID universe를 봉인한다 | +| 중간 | `stage1_tmp/task_c_bo/domain_slices/*.json` | A0 | 5개 worker가 읽는 최소 domain context이다 | +| 중간 | `stage1_tmp/task_c_bo_stage_b_domain_seed_outputs/{domain}.json` | B1~B5 | 영역별 BO seed와 review queue이다 | +| 중간 | `stage1_tmp/task_c_bo/postb_seed_ledger.json` | R0 | 5개 delta를 정규화ㆍ병합한 seed ledger이다 | +| 중간 | `quality_gates/stage1_part2_review_handoff.json` | R0 | 자동 병합하지 않은 법률 검토 항목이다 | +| 중간 | `quality_gates/stage1_part2_exception_pack.json` | R0 | 교차영역 선택이 필요한 true exception이다 | +| 중간 | `quality_gates/stage1_part2_adjudication_parts/PACK-###.json` | R1 | exception별 닫힌 판정이다 | +| 중간 | `stage1_tmp/task_c_bo/postb_compiled_bo_bundle.json` | F0 | 최종 BO write 직전의 검증된 bundle이다 | +| 최종 | `BO.json` | F0 | eventㆍstate 기반 법률 분석 객체 배열이다 | +| 최종 | `quality_gates/stage1_part2_bo_gate.json` | F0 | 보존ㆍcoverageㆍreview 상태이다 | +| 최종 | `actio_case_signals.json` | S0 | 사해행위 구조 seed 신호이다 | +| 최종 | `case_liability_signals.json` | S0 | 책임주체ㆍ책임범위 연결 신호이다 | +| 최종 | `legal_effect_signals.json` | S0 | BO별 법률효과 구조 routing 신호이다 | + +### 2.4 Description of Each Sub-task + +#### 2.4.1 `Task_C_BO_A0_context_domain_slice_compiler` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** 모든 domain LLM이 전체 원문을 반복해서 읽지 않도록 공통 source universe와 각 영역의 최소 slice를 만드는 것이다. +- **수행 방법:** 면담 문구를 clause map으로, 사건 후보를 event map으로, 증거 index를 authority map으로, `Juristic_Act.md`를 taxonomy map으로 변환한다. 입력 digest와 run fingerprint를 계산한다. 각 사건ㆍ증거ㆍ면담 문구를 5개 domain에 결정적으로 routing하고, 애매한 항목은 shared 또는 ambiguous로 표시한다. Part 1 review handoff가 있으면 관련 review item을 slice에 포함한다. +- **IO 정렬:** 4개 필수 입력과 선택적 handoff를 읽어 context, source universe manifest, 5개 domain slice를 쓴다. B1~B5는 각자 배정된 slice만 읽는다. + +#### 2.4.2 `Task_C_BO_Stage_B_B1_Money_Successor` + +- **실행 유형과 모델:** LLM, Google `gemini-3.5-flash`이다. +- **목표:** 금전채권의 발생ㆍ변제기ㆍ독촉ㆍ지급ㆍ승인ㆍ소멸과 영업양수인 등 상사 승계 책임 후보를 BO seed로 만드는 것이다. +- **수행 방법:** money/successor slice에 존재하는 source만 사용한다. 약정이율과 약정 지연손해금률, 채권 원인, payment history, demandㆍnotice hint, admission hint, successor liability hint를 named payload에 보존한다. 사실이 불명확한 경우 값을 창조하지 않고 review queue에 올린다. +- **IO 정렬:** `domain_slices/b1_money_successor.json`을 읽어 해당 domain delta 하나를 쓴다. R0가 이 delta를 다른 영역 결과와 병합한다. + +#### 2.4.3 `Task_C_BO_Stage_B_B2_Secured_Registry` + +- **실행 유형과 모델:** LLM, Google `gemini-3.1-pro-preview`이다. +- **목표:** 피담보채무, 담보권 설정ㆍ변경ㆍ소멸, 등기행의 원인ㆍ순위ㆍ말소, 경매ㆍ배당, 지분별 효력 후보를 구조화하는 것이다. +- **수행 방법:** secured/registry slice를 읽고 채무와 담보를 분리한 뒤 참조 키로 연결한다. registry row, asset/fraction ID, mortgage settingㆍextinguishment by fraction, payment allocation, auction step, dividend, derivative invalidity를 source-backed seed로 만든다. 등기 기재와 실체법상 효력은 동일하지 않으므로 확정 효력 대신 후보와 review를 보존한다. +- **IO 정렬:** B2 domain slice에서 B2 delta로 이어지고 R0가 교차영역 채권ㆍ자산 참조를 검증한다. + +#### 2.4.4 `Task_C_BO_Stage_B_B3_Land_Valuation` + +- **실행 유형과 모델:** LLM, Google `gemini-3.5-flash`이다. +- **목표:** 토지ㆍ건물의 점유와 사용이익, 인도ㆍ점유 시점, 가치평가 자료, 미등기 건물, 책임 중첩 후보를 구조화하는 것이다. +- **수행 방법:** 자산과 지분을 식별하고 valuation objectㆍrowㆍmatrix를 source와 함께 보존한다. 점유 사실과 점유의 법률상 원인 후보를 구분하고, 사용이익 기간ㆍ단가ㆍ면적 등 계산 입력을 기록한다. 계산 가능한 값과 법적 판단이 필요한 값을 구분한다. +- **IO 정렬:** B3 domain slice에서 B3 delta로 이어진다. valuation과 land-use seed는 B4 actio 및 B5 possession 결과와 R0에서 연결될 수 있다. + +#### 2.4.5 `Task_C_BO_Stage_B_B4_Actio` + +- **실행 유형과 모델:** LLM, Google `gemini-3.1-pro-preview`이다. +- **목표:** 사해행위취소의 피보전채권, 사해행위, 채무자의 책임재산, 수익자ㆍ전득자, 담보부담, 가액배상 상한을 계산 가능한 후보 구조로 만드는 것이다. +- **수행 방법:** preserved claim bundle, fraudulent transfer event, encumbrance timeline, valuation matrix, actio balance sheet, remedy mode, value compensation cap, defenseㆍrebuttal seed를 생성한다. 사해성ㆍ악의 등 최종 법리 결론은 확정하지 않고 근거와 불확실성을 함께 둔다. +- **IO 정렬:** B4 domain slice에서 B4 delta로 이어진다. 최종 S0 signal writer는 이 B4 결과와 최종 BO를 대조하여 `actio_case_signals.json`을 생성한다. + +#### 2.4.6 `Task_C_BO_Stage_B_B5_Succession_Notice_Lien_Asset_Defense` + +- **실행 유형과 모델:** LLM, Google `gemini-3.1-pro-preview`이다. +- **목표:** 상속ㆍ일반승계ㆍ특정승계, 통지 lifecycle, 유치권, 점유, 자산 alias, 항변을 하나의 보조 domain에서 구조화하는 것이다. +- **수행 방법:** succession resolution, general/asset-specific succession, senderㆍdispatchㆍarrivalㆍreceived evidence, lien ID와 secured claimㆍpossession event 골격, possession state와 legal-cause 후보, asset alias, 동시이행ㆍ상계ㆍ변제 항변을 추출한다. 유치권 성립ㆍ소멸이나 통지의 법적 효력처럼 법리 적용이 필요한 값은 확정하지 않고 review 또는 legal-theory-required 상태로 보존한다. +- **IO 정렬:** B5 domain slice에서 B5 delta로 이어진다. B1의 successor, B2의 assetㆍfraction, B3의 possession과 중복될 수 있으므로 R0가 출처 동일성 및 교차영역 충돌을 처리한다. + +#### 2.4.7 `Task_C_BO_R0_seed_reducer_exception_planner` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** 5개 domain delta를 하나의 seed ledger로 결합하면서 불필요한 LLM 판정을 최소화하는 것이다. +- **수행 방법:** run fingerprint, slice digest, source universe membership, schema를 검증한다. 완전히 같은 실체 후보는 provenance union으로 병합하고, 유사하지만 법적 역할이 다른 후보는 별도로 유지한다. 단순 누락ㆍ형식 문제ㆍ검토 필요 항목은 review handoff로 보내며, 하나의 값을 반드시 선택해야 하는 진정한 교차영역 충돌만 exception pack에 넣는다. pack count와 크기 예산도 결정적으로 제한한다. +- **IO 정렬:** A0 manifest와 5개 delta를 읽어 seed ledger, review handoff, exception pack을 쓴다. exception pack이 비어 있으면 R1 fan-out 없이 F0로 진행한다. + +#### 2.4.8 `Task_C_BO_R1_exception_adjudicator_*` + +- **실행 유형과 모델:** pack별 조건부 LLM fan-out, Google `gemini-3.1-flash-lite`이다. +- **목표:** R0가 명시적으로 분리한 교차영역 예외만 최소 추론으로 판정하는 것이다. +- **수행 방법:** 후보를 유지ㆍ병합ㆍ분할ㆍ삭제하거나 특정 값ㆍ링크를 선택할지를 닫힌 decision enum으로 반환한다. 전체 BO나 증거 파일을 읽지 않으며, pack에 없는 사실과 후보를 만들지 않는다. 불충분한 경우 `BLOCK_REVIEW`를 사용한다. +- **IO 정렬:** 각 exception pack은 같은 pack ID의 adjudication part 하나로 변환된다. F0가 expected exception ID와 decision coverage를 검사한다. + +#### 2.4.9 `Task_C_BO_F0_final_bo_gate_writer` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** 모든 판정을 적용해 BO ID, 출처, 구조 필드를 고정하고 `BO.json`을 쓰는 유일한 writer가 되는 것이다. +- **수행 방법:** A0 fingerprint와 source universe, seed ledger, exception pack, adjudication coverage를 검증한다. 허용된 decision만 적용하고 출처 membership이 없는 candidate를 거부한다. BO ID를 결정적으로 부여하고 정렬하며, compiled bundle과 quality gate를 함께 생성한다. +- **IO 정렬:** R0와 R1 결과를 읽어 compiled BO bundle, `BO.json`, Part 2 BO gate를 쓴다. S0는 이 최종 BO만 신뢰한다. + +#### 2.4.10 `Task_C_BO_S0_signal_bundle_writer` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** 최종 BO를 변경하지 않고 downstream용 세 signal view를 파생하는 것이다. +- **수행 방법:** final BO, BO gate, source manifest, seed ledger, B4 actio seed를 읽고 BO ID 기반의 사해행위ㆍ책임ㆍ법률효과 routing 신호를 생성한다. signal은 독립 사실을 창조하는 파일이 아니라 BO와 전문 구조 사이의 참조 layer이다. +- **IO 정렬:** F0 완료 후 실행하여 세 signal JSON을 동시에 쓴다. Part 3과 Part 4가 이를 입력으로 사용한다. + +### 2.5 JSON Formats of Part 2 Outputs + +#### 2.5.1 A0 context, domain slice, source universe + +`stage_a_context.json`은 다음 개념 구조를 사용한다. + +```json +{ + "schema_version": "task_c_bo_stage_a_context.v1", + "status": "READY|BLOCKED", + "run_fingerprint": "sha256", + "allowed_inputs": [], + "input_digests": {}, + "meeting_clause_map": {"schema_version": "meeting_clause_map.v1"}, + "event_candidate_map": {"schema_version": "event_candidate_map.v2"}, + "evidence_authority_map": {"schema_version": "evidence_authority_map.v2"}, + "juristic_act_taxonomy_map": {"schema_version": "juristic_act_taxonomy_map.v1"}, + "global_hazard_seed": {"schema_version": "global_hazard_seed.v1"}, + "part1_review_guard": {}, + "worker_contract": {} +} +``` + +각 domain slice는 다음 골격을 사용한다. + +```json +{ + "schema_version": "task_c_bo_stage_b_domain_slice.v1", + "router_status": "READY|READY_WITH_REVIEW|BLOCKED", + "domain_id": "B1|B2|B3|B4|B5", + "domain_label": "string", + "allowed_bo_types": [], + "run_fingerprint": "sha256", + "slice_digest_sha256": "sha256", + "source_universe": {}, + "selected_meeting_clauses": [], + "selected_event_candidates": [], + "selected_evidence_items": [], + "taxonomy_subset": {}, + "hazard_subset": {}, + "part1_review_items": [], + "shared_or_ambiguous_items": [], + "routing_audit": {}, + "worker_contract": {} +} +``` + +`source_universe_manifest.json`은 `task_c_bo_source_universe_manifest.v1`이며 입력 digest, 전역 meeting/event/evidence ID, domain별 ID와 count, slice hash를 보존한다. + +#### 2.5.2 Domain BO seed delta + +5개 worker는 공통 envelope를 사용한다. + +```json +{ + "stage_b_domain_bo_seed_delta": { + "schema_version": "task_c_bo_stage_b_domain_bo_seed_delta.v1", + "domain_id": "B1|B2|B3|B4|B5", + "status": "READY|READY_WITH_REVIEW|FAILED", + "run_fingerprint": "sha256", + "slice_digest_sha256": "sha256", + "bo_seed_candidates": [ + { + "candidate_ref": "B1:001", + "BOType": "event|state", + "ActionType": "string", + "Action": "neutral source-backed draft", + "source_evidence_indexes": [], + "provenance": { + "event_candidate_refs": [], + "meeting_clause_refs": [], + "evidence_refs": [] + }, + "extensions": { + "domain_payload": { + "domain_legal_effect_tag": "string" + } + } + } + ], + "domain_review_queue": [ + { + "review_id": "string", + "severity": "string", + "issue_type": "string", + "candidate_refs": [], + "source_refs": {}, + "downstream_owner": "string" + } + ] + } +} +``` + +후보에는 필요에 따라 `JuristicAct`, `Legal_Keywords`, `core_field_base`, `amount`, `downstream_seed_refs`가 추가된다. domain별 named payload는 money claim, registryㆍsecured debt, valuationㆍpossession, actio balance sheet, successionㆍnoticeㆍlienㆍasset aliasㆍdefense 정보를 보존한다. + +#### 2.5.3 R0ㆍR1ㆍF0 중간 포맷 + +- `postb_seed_ledger.json`: `task_c_bo_postb_seed_ledger.v2`이다. 정규화된 candidate, provenance union, reviewㆍconflict index, source coverage를 담는다. +- `stage1_part2_review_handoff.json`: `stage1_part2_review_handoff.v1`이다. 자동 판정하지 않은 검토 항목과 downstream owner를 담는다. +- `stage1_part2_exception_pack.json`: `stage1_part2_exception_pack.v1`이다. expected exception ID, pack, candidate context, budget gate를 담는다. +- R1 output: `stage1_part2_adjudication_part.v1`이다. + +```json +{ + "schema_version": "stage1_part2_adjudication_part.v1", + "status": "READY|READY_WITH_REVIEW|FAILED", + "pack_id": "PACK-001", + "exception_type": "string", + "decisions": [ + { + "exception_id": "string", + "decision": "KEEP_SEPARATE|MERGE_PROVENANCE_UNION|SPLIT|DROP_UNSUPPORTED|SELECT_VALUE|SELECT_LINK|NO_LINK|BLOCK_REVIEW", + "candidate_refs": [], + "selected_value": null, + "selected_link": null, + "reason_code": "string" + } + ] +} +``` + +F0의 compiled bundle은 `task_c_bo_postb_compiled_bo_bundle.v1`, gate는 `stage1_part2_bo_gate.v1`, stdout report는 `stage1_part2_bo_write_report.v1`을 사용한다. + +#### 2.5.4 `BO.json` + +`BO.json`은 wrapper 없는 배열이다. 각 행의 대표 구조는 다음과 같다. + +```json +[ + { + "BO_ID": "BO-0001", + "id": "BO-0001", + "BOType": "event|state", + "ActionType": "string", + "JuristicAct": "string|null", + "Action": "string", + "Reason": "string|null", + "PriorAct": [], + "ReasonRefs": [], + "Legal_Keywords": [], + "core_field_base": {}, + "amount": null, + "EvidenceTitles": [], + "Evidence": [], + "source_evidence_indexes": [], + "provenance": {}, + "downstream_seed_refs": [], + "extensions": { + "domain_payload": {} + } + } +] +``` + +`BO_ID`는 이후 Part 3 구조와 Part 4 fact row의 기준 foreign key이다. `source_evidence_indexes`와 `provenance`는 법률효과 후보가 어느 증거와 사건 후보에서 비롯되었는지 역추적하는 핵심 필드이다. + +#### 2.5.5 Three signal files + +```json +{ + "schema_version": "actio_case_signals.v1", + "actio_case_signals": [] +} +``` + +```json +{ + "schema_version": "case_liability_signals.v1", + "case_liability_signals": [] +} +``` + +```json +{ + "schema_version": "legal_effect_signals.v1", + "bo_legal_effect_routes": [] +} +``` + +세 signal은 BO ID, 관련 claim/liability/actio group, 후보 structure type, source evidence, review 상태를 참조한다. signal 자체가 BO보다 우월한 사실 source가 되는 것은 아니며, Part 3ㆍPart 4의 routing과 link 후보를 제공한다. + +--- + +## Section 3: Analysis of Stage 1 -- Part 3 + +### 3.1 Ultimate Goal of Part 3 + +Part 3의 궁극적 목표는 `BO.json`의 개별 eventㆍstate를 법률효과 분석에 필요한 구조 단위로 묶고, BOㆍ쟁점ㆍ자산ㆍ증거ㆍ구조유형 사이의 다방향 인덱스를 생성하는 것이다. + +하나의 BO가 복수의 법률효과 구조와 관련될 수 있고, 하나의 구조도 여러 BO와 증거를 가질 수 있다. 따라서 Part 3은 BO를 성급히 하나의 법률유형으로 환원하지 않는다. hard key가 충분하면 결정적으로 cluster를 만들고, 복수 routing이 합리적이면 그대로 보존한다. 오직 downstream 구조를 만들기 위해 하나의 선택이 불가피하고 source만으로 결정할 수 없는 경우에만 LES2 LLM 예외 판정을 사용한다. + +대표 구조유형은 다음과 같다. + +- `money_claim` +- `commercial_successor` +- `secured_debt` +- `registry_invalidity` +- `land_use_gain` +- `valuation` +- `fraudulent_transfer` +- `preserved_claim` +- `succession_notice_lien_asset_defense` +- `general_legal_effect` + +### 3.2 Detailed Workflow and DAG + +```text +BO.json + evidence_indexed.json + three signal files + | + v ++------------------------------------------------+ +| Task_LES0_input_pack_compiler | +| source mapㆍaliasㆍBO candidate record 압축 | ++-----------------------+------------------------+ + | + v ++------------------------------------------------+ +| Task_LES1_deterministic_structure_seed_builder | +| hard-key clusterㆍseedㆍreviewㆍexception pack | ++-----------------------+------------------------+ + | + +-----------+----------------+ + | | + | exception_count > 0 | exception_count = 0 + v | ++------------------------------------------------+ | +| Task_LES2_exception_adjudicator_* | | +| compact micro-pack의 불가피한 선택만 판정 | | ++-----------------------+------------------------+ | + | | + +------------+--------------+ + v ++------------------------------------------------+ +| Task_LES3_final_structure_index_writer | +| exact coverageㆍfingerprintㆍ역색인 봉인 | ++-----------------------+------------------------+ + | + v + legal_effect_structures.json +``` + +LES2는 항상 실행되는 작업이 아니다. LES1이 exception을 0개 생성하면 동적 fan-out도 0개이며 LES3가 seed를 그대로 검증해 최종 파일을 쓴다. 이는 다중 후보를 보존할 수 있는 상황까지 LLM에 보내지 않기 위한 설계이다. + +### 3.3 IO Structure of Part 3 + +#### 3.3.1 IN files + +| 파일 | 역할 | +|---|---| +| `BO.json` | 모든 구조 seed의 기준 BO universe이다 | +| `evidence_indexed.json` | BO가 참조하는 증거 authority와 자산 alias 근거이다 | +| `actio_case_signals.json` | 사해행위ㆍ피보전채권 구조 연결 seed이다 | +| `case_liability_signals.json` | 책임주체ㆍ책임그룹 구조 연결 seed이다 | +| `legal_effect_signals.json` | BO별 candidate structure type과 routing seed이다 | + +Part 3은 원시 면담과 원 증거를 다시 읽지 않는다. Part 1과 Part 2가 봉인한 ID와 source reference를 통해서만 구조를 만든다. + +#### 3.3.2 OUT files + +| 구분 | 파일 | 생성 작업 | 역할 | +|---|---|---|---| +| 중간 | `stage1_tmp/legal_effect_structure_input_pack.json` | LES0 | compact sourceㆍcandidateㆍalias map이다 | +| 중간 | `stage1_tmp/legal_effect_structure_seed_bundle.json` | LES1 | 결정적 structure seed와 cluster map이다 | +| 중간 | `stage1_tmp/legal_effect_structure_exception_pack.json` | LES1 | 진정한 구조 선택 예외와 micro-pack이다 | +| 중간 | `stage1_tmp/legal_effect_structure_adjudication_parts/PACK-###.json` | LES2 | 예외별 닫힌 판정이다 | +| 최종 | `legal_effect_structures.json` | LES3 | 구조 배열, 역색인, quality gate이다 | + +각 Python task는 stdout manifest도 생성한다. LES0는 `stage1_legal_structure_input_manifest.v2`, LES1은 `stage1_legal_structure_les1_manifest.v2`, LES3는 `stage1_legal_effect_structures_writer.v2`를 사용한다. 이 manifest는 파일 경로, count, hash, fingerprint, fan-out 상태를 연결한다. + +### 3.4 Description of Each Sub-task + +#### 3.4.1 `Task_LES0_input_pack_compiler` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** Part 3에 필요한 정보만 BO 중심으로 압축하여 이후 task가 원본 전체를 반복해서 읽지 않도록 하는 것이다. +- **수행 방법:** 입력 파일의 digest와 count를 계산하고, 증거를 evidence index 기준 authority map으로 만든다. BO마다 source evidence, signal route, claimㆍliabilityㆍactio group, candidate structure type, domain payload, review 상태를 하나의 candidate record로 모은다. 자산 alias를 source-backed reference로 정규화한다. 존재하지 않는 BOㆍevidence reference는 input review item으로 격리한다. +- **IO 정렬:** 5개 입력 파일을 읽어 `legal_effect_structure_input_pack.json` 한 파일을 쓴다. 이후 LES1은 이 pack과 LES0 manifest 외의 원본을 읽지 않는다. + +#### 3.4.2 `Task_LES1_deterministic_structure_seed_builder` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** 가능한 모든 structure clustering과 routing을 규칙으로 처리하고, LLM이 판단할 예외를 극소화하는 것이다. +- **수행 방법:** candidate structure type을 canonical type으로 정규화한다. issue cluster는 claim group, liability group, theory graph reference, linked structure reference 등 hard key 우선순위로 만든다. asset cluster도 명시적 asset IDㆍregistry refㆍalias 근거가 있을 때만 결합한다. legal-effect role과 evidence index를 seed에 연결한다. +- **예외 분리 원칙:** 다중 구조나 다중 자산을 보존할 수 있으면 exception이 아니다. 명시된 basis code가 존재하고, downstream에 하나의 비가역적 선택이 필요하며, 보존ㆍdefer가 금지되고, compact context만으로 판정 가능한 경우에만 exception이 된다. 허용 exception type은 `ambiguous_issue_cluster`, `ambiguous_asset_cluster`, `ambiguous_candidate_structure_type` 세 가지이다. +- **micro-pack 제한:** pack당 목표 3건, 최대 4건, 최대 12KB, 전체 최대 8 pack, 후보값 최대 8개로 제한한다. +- **IO 정렬:** input pack을 읽어 seed bundle과 exception pack을 쓴다. manifest의 `dynamic_fanout`이 LES2 인스턴스 수를 결정한다. + +#### 3.4.3 `Task_LES2_exception_adjudicator_*` + +- **실행 유형과 모델:** pack별 조건부 LLM fan-out, Google `gemini-3.1-flash-lite`이다. +- **목표:** LES1 규칙으로 해결할 수 없고 구조 완성을 위해 선택이 불가피한 예외만 판정하는 것이다. +- **수행 방법:** 배정된 micro-pack 외의 파일을 읽지 않는다. issue cluster 예외는 기존 hard key 사용ㆍmulti-issue 보존ㆍ분리ㆍ검토 차단 중 하나를 선택한다. asset 예외는 동일ㆍ별도ㆍmulti-asset bundleㆍ검토 차단 중 하나를 선택한다. structure type 예외는 대표 유형 선택ㆍmulti-routing 보존ㆍseed 분리ㆍ검토 차단 중 하나를 선택한다. 새로운 BOㆍ증거ㆍ자산ㆍ구조 근거를 만들 수 없다. +- **IO 정렬:** `PACK-###`을 읽어 동일 pack ID의 adjudication part를 쓴다. LES3가 input exception ID와 decision ID의 정확한 일치를 검증한다. + +#### 3.4.4 `Task_LES3_final_structure_index_writer` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** seed와 예외 판정을 적용하여 하나의 최종 법률효과 구조 파일과 완전한 역색인을 쓰는 것이다. +- **수행 방법:** seed bundleㆍexception packㆍadjudication part의 fingerprint와 hash를 검증한다. expected exception coverage가 100%인지 확인하고 허용 decision만 적용한다. BOㆍ증거ㆍissueㆍasset reference의 universe membership을 검사한다. 최종 structure ID와 정렬을 결정적으로 고정하고, BOㆍissueㆍassetㆍevidenceㆍtype별 index를 생성한다. 미해결 항목은 삭제하지 않고 `review_queue`와 `review_required`로 보존한다. +- **IO 정렬:** 모든 LES1ㆍLES2 결과를 읽어 `legal_effect_structures.json`을 쓰는 유일한 writer이다. 이 파일은 Part 4의 필수 입력이다. + +### 3.5 JSON Formats of Part 3 Outputs + +#### 3.5.1 LES0 input pack + +```json +{ + "schema_version": "stage1_legal_structure_input_pack.v2", + "status": "READY|READY_WITH_REVIEW|BLOCKED", + "run_fingerprint": "sha256", + "input_digests": {}, + "input_counts": {}, + "evidence_authority_by_index": {}, + "asset_alias_by_ref": {}, + "candidate_records_by_bo_id": {}, + "input_review_items": [] +} +``` + +`candidate_records_by_bo_id`는 BO의 source evidence, structure type 후보, claimㆍliabilityㆍactio group, asset refs, signal hints, legal roles, upstream review를 한곳에 모은다. 이는 원본 파일의 전체 문장을 복제하는 컨테이너가 아니라 구조 생성에 필요한 compact projection이다. + +#### 3.5.2 LES1 seed bundle과 exception pack + +```json +{ + "schema_version": "stage1_legal_structure_seed_bundle.v2", + "status": "READY|READY_WITH_REVIEW|BLOCKED", + "run_fingerprint": "sha256", + "source_input_pack_ref": "stage1_tmp/legal_effect_structure_input_pack.json", + "source_input_pack_sha256": "sha256", + "structure_seed_items": [], + "issue_cluster_seed_map": {}, + "asset_cluster_seed_map": {}, + "evidence_index_seed": {}, + "deterministic_reviews": [], + "exception_pack_ref": "stage1_tmp/legal_effect_structure_exception_pack.json", + "exception_pack_sha256": "sha256", + "expected_exception_ids": [] +} +``` + +```json +{ + "schema_version": "stage1_legal_structure_exception_pack.v2", + "status": "NO_EXCEPTION|READY|BLOCKED", + "run_fingerprint": "sha256", + "expected_exception_ids": [], + "exceptions": [], + "reviews": [], + "pack_count": 0, + "packs": [] +} +``` + +#### 3.5.3 LES2 adjudication part + +```json +{ + "schema_version": "stage1_legal_structure_adjudication_part.v2", + "status": "READY|READY_WITH_REVIEW|FAILED", + "pack_id": "PACK-001", + "run_fingerprint": "sha256", + "exception_type": "ambiguous_issue_cluster|ambiguous_asset_cluster|ambiguous_candidate_structure_type", + "input_exception_ids": [], + "decisions": [ + { + "exception_id": "string", + "decision": "closed enum", + "selected_candidate_refs": [], + "reason_code": "string", + "review_required": false + } + ], + "coverage": {} +} +``` + +허용 decision은 exception type마다 다르며 다음처럼 제한된다. + +| 예외 유형 | 허용 decision | +|---|---| +| issue cluster | `USE_EXISTING_HARD_KEY`, `PRESERVE_MULTI_ISSUE`, `SPLIT_ISSUE_CLUSTER`, `BLOCK_REVIEW` | +| asset cluster | `SAME_CLUSTER`, `SEPARATE_CLUSTER`, `MULTI_ASSET_BUNDLE`, `BLOCK_REVIEW` | +| structure type | `SELECT_REPRESENTATIVE_TYPE`, `PRESERVE_MULTI_ROUTING`, `SPLIT_STRUCTURE_SEED`, `BLOCK_REVIEW` | + +#### 3.5.4 `legal_effect_structures.json` + +```json +{ + "schema_version": "stage1_legal_effect_structures.v1", + "status": "READY|READY_WITH_REVIEW", + "legal_effect_structures": [ + { + "structure_id": "LES-0001", + "candidate_structure_type": "string", + "candidate_structure_types": [], + "structure_label": "string", + "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": false, + "routing_audit": {} + } + ], + "structure_index": { + "by_bo_id": {}, + "by_issue_cluster_id": {}, + "by_asset_cluster_id": {}, + "by_evidence_index": {}, + "by_candidate_structure_type": {} + }, + "quality_gate": { + "bo_coverage": {}, + "evidence_coverage": {}, + "exception_coverage": {}, + "run_fingerprint_gate": {}, + "review_summary": {}, + "review_queue": [] + } +} +``` + +구조 한 건은 법률상 확정된 청구원인이 아니라 관련 BO를 묶은 분석 단위이다. `candidate_structure_types`와 `review_required`가 존재하는 이유는 복수 법리 가능성을 데이터 손실 없이 Stage 2에 전달하기 위함이다. + +--- + +## Section 4: Analysis of Stage 1 -- Part 4 + +### 4.1 Ultimate Goal of Part 4 + +Part 4의 궁극적 목표는 Part 2의 모든 BO를 하나도 빠뜨리지 않고, BO당 정확히 하나의 표준화된 사실 레코드로 투영하여 `Fact_Ledger_base.json`을 생성하는 것이다. 이 ledger는 향후 청구원인 구성과 입증계획의 기초가 되므로 다음 원칙을 지켜야 한다. + +- 사실, 법률효과 후보, 계산 객체, review 상태를 구분한다. +- 모든 fact는 하나의 `source_bo_id`를 가지며 BO universe와 1:1 보존된다. +- 증거ㆍ구조ㆍclaimㆍactio 참조는 실제 upstream universe에 존재해야 한다. +- 증거 신빙성 점수와 IDㆍ정렬은 결정적으로 계산한다. +- 점유 사실과 법률상 원인, 통지 수령, 유치권 소멸 후 상태 같은 위험 영역은 review/drafting gate로 봉인한다. +- LLM은 source-backed scalar 또는 projection이 서로 충돌해 하나를 선택해야 할 때만 개입한다. + +법률적으로 Fact Ledger는 판사의 사실인정이나 변호사의 최종 법률평가를 대신하지 않는다. 증거에 의해 지지되는 사실 후보, 파생 사실, 법률효과 role, 검토 필요성을 동시에 보존하는 Stage 1의 최종 사실 표준화 계층이다. + +### 4.2 Detailed Workflow and DAG + +```text +BO.json + legal_effect_structures.json + + evidence_indexed.json + three signal files + | + v ++------------------------------------------------+ +| Task_FL0_fact_source_pack_compiler | +| BOㆍstructureㆍsignalㆍevidence universe 압축 | ++-----------------------+------------------------+ + | + v ++------------------------------------------------+ +| Task_FL1_deterministic_fact_ledger_ | +| candidate_builder | +| BO당 1 rowㆍ점수ㆍgateㆍexception micro-pack | ++-----------------------+------------------------+ + | + +-----------+----------------+ + | | + | exception_count > 0 | exception_count = 0 + v | ++------------------------------------------------+ | +| Task_FL2_fact_exception_adjudicator_* | | +| 허용 scalar/projection 충돌만 판정 | | ++-----------------------+------------------------+ | + | | + +------------+--------------+ + v ++------------------------------------------------+ +| Task_FL3_final_fact_ledger_gate_and_writer | +| conservationㆍreferenceㆍdomain gate 봉인 | ++-----------------------+------------------------+ + | + v + Fact_Ledger_base.json + fact_ledger_writer_report.json +``` + +### 4.3 IO Structure of Part 4 + +#### 4.3.1 IN files + +| 파일 | 역할 | +|---|---| +| `BO.json` | fact row의 1:1 source universe이다 | +| `legal_effect_structures.json` | BO별 구조, 법률효과 role, issueㆍasset 연결을 제공한다 | +| `actio_case_signals.json` | 사해행위 및 피보전채권 관련 roleㆍgroup hint를 제공한다 | +| `case_liability_signals.json` | 책임주체와 liability group hint를 제공한다 | +| `legal_effect_signals.json` | BO별 downstream module과 legal-effect routing hint를 제공한다 | +| `evidence_indexed.json` | evidence authority, 제목, credibility 계산 근거를 제공한다 | + +Part 4는 `client_goal.json`, `evidence_all.json`, `evidence_event_candidates.json`을 직접 읽지 않는다. 이 정보가 필요한 경우 BOㆍstructureㆍsignalㆍevidence index에 보존된 reference를 통해 접근한다. + +#### 4.3.2 OUT files + +| 구분 | 파일 | 생성 작업 | 역할 | +|---|---|---|---| +| 중간 | `stage1_tmp/fact_ledger/fact_source_pack.json` | FL0 | BO별 compact source projection이다 | +| 중간 | `stage1_tmp/fact_ledger/Fact_Ledger_base_candidate.json` | FL1 | BO당 하나의 27-field candidate row이다 | +| 중간 | `stage1_tmp/fact_ledger/fact_exception_manifest.json` | FL1 | exception universe, review, micro-pack index이다 | +| 중간 | `stage1_tmp/fact_ledger/fact_exception_input_parts/PACK-###.json` | FL1 | FL2가 읽는 compact input이다 | +| 중간 | `stage1_tmp/fact_ledger/fact_exception_adjudication_parts/PACK-###.json` | FL2 | 허용된 patch 또는 block 판정이다 | +| 최종 | `Fact_Ledger_base.json` | FL3 | BO 보존형 사실 ledger 배열이다 | +| 최종 | `stage1_tmp/fact_ledger/fact_ledger_writer_report.json` | FL3 | 보존ㆍ참조ㆍ예외ㆍdomainㆍdrafting gate 보고서이다 | + +### 4.4 Description of Each Sub-task + +#### 4.4.1 `Task_FL0_fact_source_pack_compiler` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** 최종 fact row 생성에 필요한 upstream 정보를 BO ID 중심으로 압축하고 참조 universe를 봉인하는 것이다. +- **수행 방법:** 입력 digest와 run fingerprint를 계산한다. BO를 `bo_by_id`, 구조를 `structure_by_id`, BO별 구조를 `structure_refs_by_bo_id`, signal을 `signal_hints_by_bo_id`, 증거를 `evidence_authority_by_index`로 정규화한다. LES review와 Part 2 review를 `upstream_review_by_bo_id`로 상속한다. 존재 가능한 BOㆍstructureㆍevidenceㆍgroup ID를 `reference_universe`에 기록한다. +- **IO 정렬:** 6개 최종 upstream 파일을 읽어 `fact_source_pack.json`을 쓴다. FL1은 원본 6개 파일을 다시 읽지 않고 이 pack만 소비한다. + +#### 4.4.2 `Task_FL1_deterministic_fact_ledger_candidate_builder` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** 모든 BO에 대해 정확히 하나의 27-field fact candidate를 만들고, LLM 판단이 필요한 충돌만 micro-pack으로 분리하는 것이다. +- **수행 방법:** BO ID 순서에 따라 fact ID를 결정적으로 부여한다. BO의 Action, date, parties, object, amount, evidence, legal role, linked structure, downstream seed를 27개 필드로 투영한다. 직접 fact가 부족하되 source-backed derivation이 가능하면 `derived_fact`와 `derivation_basis`를 채운다. evidence score는 규칙으로 계산한다. LES review와 possessionㆍlegal cause, notice receipt, lien after notice 등 domain gate를 row warning 또는 drafting gate로 상속한다. +- **예외 분리 원칙:** 단순 빈 값, 다중 구조, 검토 필요 상태는 LLM exception이 아니다. source가 지지하는 두 scalarㆍ계산ㆍ자산ㆍ구조 role projection이 서로 양립할 수 없고 하나의 최종 row 필드를 선택해야 할 때만 exception으로 만든다. 허용 유형은 `conflicting_fact_projection`, `conflicting_calculation_projection`, `conflicting_asset_projection`, `conflicting_structure_role_projection`이다. +- **micro-pack 제한:** pack당 목표 3건, 최대 4건, item 최대 12KB, pack 최대 25KB, 전체 최대 8 pack이다. +- **IO 정렬:** source pack을 읽어 candidate bundle, exception manifest, pack별 input part를 쓴다. manifest의 fan-out이 FL2 인스턴스 수를 결정한다. + +#### 4.4.3 `Task_FL2_fact_exception_adjudicator_*` + +- **실행 유형과 모델:** pack별 조건부 LLM fan-out, Google `gemini-3.1-flash-lite`이다. +- **목표:** 허용된 fact field의 source-backed 후보 충돌만 최소 범위에서 판정하는 것이다. +- **수행 방법:** `KEEP_AS_IS`, `PATCH`, `BLOCK_REVIEW` 중 하나를 선택한다. `PATCH`인 경우 FL1이 제공한 허용 field와 candidate value 중 하나만 사용할 수 있다. 새로운 factㆍBOㆍevidenceㆍstructure ID를 만들거나 자유 문장으로 원 row 전체를 다시 쓸 수 없다. 근거가 부족하면 `BLOCK_REVIEW`로 보존한다. +- **IO 정렬:** input pack 하나를 adjudication part 하나로 변환한다. FL3가 input exception과 decision coverage 및 patch whitelist를 검사한다. + +#### 4.4.4 `Task_FL3_final_fact_ledger_gate_and_writer` + +- **실행 유형:** Python 결정적 작업이다. +- **목표:** candidate와 예외 판정을 안전하게 적용하고 `Fact_Ledger_base.json`을 작성하는 유일한 writer가 되는 것이다. +- **수행 방법:** source pack, candidate bundle, exception manifest, inputㆍoutput pack의 hash와 fingerprint가 일치하는지 검사한다. expected exception, input exception, decision ID의 완전한 집합 일치를 강제한다. patch field와 값이 whitelist 및 source candidate 안에 있는지 검증한다. BO ID 집합과 fact의 `source_bo_id` 집합이 정확히 일치하는지 확인한다. structureㆍevidenceㆍclaimㆍactio reference membership, LES review 상속, blocked review를 검사한다. +- **법률 안전 게이트:** 점유 사실과 법률상 원인 후보가 모순되는지 검사하고, 통지의 `received_date` 또는 수령 증거가 없는데 도달을 전제로 최종 drafting하려는 경우를 제한한다. 유치권 소멸 통지 후 상태가 확정되지 않은 경우도 review/drafting gate에 남긴다. 이 게이트는 법률적 결론을 자동 확정하지 않고, 결론을 내리기 위한 필수 사실이 없는 상태에서 downstream drafting이 진행되는 것을 차단한다. +- **IO 정렬:** FL0ㆍFL1ㆍFL2 산출물을 읽어 최종 ledger와 writer report를 쓴다. 이후 Stage 2는 writer report의 block/review 상태를 ledger와 함께 확인해야 한다. + +### 4.5 JSON Formats of Part 4 Outputs + +#### 4.5.1 FL0 source pack + +```json +{ + "schema_version": "stage1_fact_source_pack.v3", + "status": "READY|READY_WITH_REVIEW|BLOCKED", + "run_fingerprint": "sha256", + "input_manifest": {}, + "bo_by_id": {}, + "structure_by_id": {}, + "structure_refs_by_bo_id": {}, + "signal_hints_by_bo_id": {}, + "evidence_authority_by_index": {}, + "upstream_review_by_bo_id": {}, + "reference_universe": {}, + "source_integrity": {}, + "source_counts": {} +} +``` + +#### 4.5.2 FL1 candidate bundle과 exception manifest + +```json +{ + "schema_version": "stage1_fact_ledger_candidate_bundle.v2", + "status": "READY|READY_WITH_REVIEW|BLOCKED", + "run_fingerprint": "sha256", + "source_pack_ref": "stage1_tmp/fact_ledger/fact_source_pack.json", + "source_pack_sha256": "sha256", + "candidate_items": [], + "exception_manifest_ref": "stage1_tmp/fact_ledger/fact_exception_manifest.json", + "exception_manifest_sha256": "sha256", + "expected_exception_ids": [], + "compile_gate": { + "bo_conservation": {}, + "schema_validation": {}, + "reference_validation": {} + } +} +``` + +```json +{ + "schema_version": "stage1_fact_exception_manifest.v2", + "status": "NO_EXCEPTION|READY|BLOCKED", + "run_fingerprint": "sha256", + "expected_exception_ids": [], + "exception_count": 0, + "deterministic_reviews": [], + "pack_count": 0, + "packs": [] +} +``` + +각 input part는 `stage1_fact_exception_input_part.v2`이며 pack ID, fingerprint, exception type, 허용 field, 후보값, source refs만 담는다. + +#### 4.5.3 FL2 adjudication part + +```json +{ + "schema_version": "stage1_fact_exception_adjudication_part.v2", + "status": "READY|READY_WITH_REVIEW|FAILED", + "pack_id": "PACK-001", + "run_fingerprint": "sha256", + "exception_type": "string", + "input_exception_ids": [], + "decisions": [ + { + "exception_id": "string", + "decision": "KEEP_AS_IS|PATCH|BLOCK_REVIEW", + "patch": { + "field": "allowed field|null", + "value": null + }, + "reason_code": "string", + "source_refs": [] + } + ], + "coverage": {} +} +``` + +#### 4.5.4 `Fact_Ledger_base.json` + +최종 파일은 wrapper 없는 배열이며 각 row는 정확히 다음 27개 필드를 사용한다. + +```json +[ + { + "fact_id": "F-0001", + "source_bo_id": "BO-0001", + "type": "string", + "date": null, + "parties": [], + "object_spec": {}, + "amount": null, + "action": "string", + "evidence_refs": [], + "credibility": {}, + "legal_centrality": "string", + "proof_strength": "string", + "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": false, + "derivation_basis": [], + "legal_calculation_object": null + } +] +``` + +필드별 의미는 다음과 같다. + +| 필드군 | 필드 | 의미 | +|---|---|---| +| 식별ㆍ기초사실 | `fact_id`, `source_bo_id`, `type`, `date`, `parties`, `object_spec`, `amount`, `action` | BO에서 보존된 사건ㆍ상태의 기본 표현이다 | +| 입증 | `evidence_refs`, `credibility`, `legal_centrality`, `proof_strength` | 출처와 입증 강도의 구조화 값이다 | +| 법률효과 연결 | `legal_effect_roles`, `claim_chain_ref`, `linked_structures` | Part 3 구조와 청구 사슬의 참조이다 | +| 누락 방지 | `must_not_drop_in_claim_types`, `must_consider` | 특정 청구유형에서 반드시 검토할 사실을 표시한다 | +| 영역 상태 | `state_context`, `money_claim_effect`, `commercial_successor_effect` | 점유ㆍ통지ㆍ채권ㆍ승계 등 영역별 상태 후보이다 | +| 사해행위 | `actio_roles`, `linked_actio_structures` | 피보전채권ㆍ처분행위ㆍ수익자 등 역할 연결이다 | +| downstream | `downstream_module_candidates`, `skeleton_validation_codes` | Stage 2 module routing과 검증 코드이다 | +| 파생ㆍ계산 | `derived_fact`, `derivation_basis`, `legal_calculation_object` | 직접 기재 사실과 파생ㆍ계산 결과를 구분한다 | + +#### 4.5.5 Writer report + +`fact_ledger_writer_report.json`은 `stage1_fact_ledger_writer_report.v2`를 사용한다. + +```json +{ + "schema_version": "stage1_fact_ledger_writer_report.v2", + "status": "READY|READY_WITH_REVIEW|BLOCKED", + "run_fingerprint": "sha256", + "conservation_gate": {}, + "exception_gate": {}, + "reference_gate": {}, + "upstream_les_review_gate": {}, + "blocked_review_items": [], + "row_warnings": [], + "possession_conflict_gate": {}, + "drafting_gates": {}, + "gate_review_code_summary": {}, + "evidence_score_change_summary": {} +} +``` + +이 report는 부수적인 로그가 아니라 최종 ledger의 사용 가능 범위를 정하는 계약이다. `Fact_Ledger_base.json`이 생성되었더라도 report가 `BLOCKED`이거나 특정 drafting gate가 닫혀 있으면 Stage 2가 해당 법률결론이나 최종 서면을 확정해서는 안 된다. + +--- + +## Stage 1 최종 handoff의 해석 + +네 Part가 모두 완료되면 Stage 1은 다음 핵심 파일군을 형성한다. + +| 계층 | 핵심 산출물 | downstream 역할 | +|---|---|---| +| 의뢰 목적 | `client_goal.json` | 청구 방향, 당사자ㆍ구제ㆍ쟁점 탐색 기준이다 | +| 증거ㆍ사건 | `evidence_indexed.json`, `evidence_event_candidates.json` | 문서 authority와 시간순 사건 후보의 원천이다 | +| 법률행위ㆍ신호 | `BO.json`, 3 signal JSON | 법률영역별 event/state와 연결 seed이다 | +| 법률효과 구조 | `legal_effect_structures.json` | BOㆍ쟁점ㆍ자산ㆍ증거 사이의 구조 및 역색인이다 | +| 사실 ledger | `Fact_Ledger_base.json` | Stage 2가 소비할 BO 보존형 표준 사실 집합이다 | +| 안전성 sidecar | Part별 gateㆍreviewㆍwriter report | 자동 진행, 변호사 검토, drafting 제한 상태이다 | + +이 파일들은 서로 대체 관계가 아니라 보완 관계이다. `client_goal.json`은 의뢰인의 목표를, `evidence_indexed.json`은 문서 내용을, `BO.json`은 사건ㆍ상태의 법률 분석 단위를, `legal_effect_structures.json`은 관계 구조를, `Fact_Ledger_base.json`은 최종 사실 ledger를 담당한다. Stage 2는 최종 ledger만 단독으로 읽기보다 필요한 원천과 구조 파일 및 quality sidecar를 함께 읽어야 출처 추적성과 법률적 불확실성을 온전히 유지할 수 있다.