Liti-agent-Development/0. YAML_Updated/actio_pauliana_info_priority.md

# actio_pauliana_calc_v3 필드별 정보 우선순위 표

## 전제

이 표는 `actio_pauliana_calc_v3.json`의 **실제 입력값을 채우는 데 의미가 있는 데이터 필드군**을 대상으로, `BO.json`과 `client_meeting.md` 중 어느 쪽이 더 직접적으로 도움이 되는지를 분류한 것이다.

분류 기준은 다음과 같다.

- **BO 우선**: 구조화된 사건행위, 날짜, 당사자 역할, 증거 인덱스 연결이 이미 정리되어 있어 v3 필드에 바로 매핑하기 쉬운 경우
- **client_meeting 우선**: 실질 거래유형, 관계 맥락, 시가의 대략적 배경, 수익자/전득자/특수관계 구조 등 회의록 해석이 더 직접적인 경우
- **둘 다 필요**: BO의 구조화와 client meeting의 맥락 보강을 함께 써야 안전하게 채울 수 있는 경우

## 유의

- `template_name`, `schema_version`, `jurisdiction`, `language`, `currency`, `purpose`, `design_principles`, `source_of_truth`, `validation`의 규칙 텍스트처럼 **정적 스키마/설명용 필드**는 비교대상에서 제외하였다.
- `runtime_inputs.close_of_arguments_date`, `judgment_finality_date`, `proceeding_stages.current_stage` 같은 **소송 진행 관리 필드**는 BO나 client meeting보다는 소송진행 정보와 후속 문서에서 채워지는 경우가 많으므로, 아래 표에서는 보조적으로만 언급하였다.
- `registration_date`, `registry_office`, `registry_receipt_no`, `claim_actual_performance_amount`, `claim_interest_rate`, `claim_default_rate` 등은 `client_meeting.md`를 단독 근거로 삼을 수 없는 필드다. 따라서 이들 필드가 표에서 `client_meeting 우선`으로 분류되는 일은 원칙적으로 없다.

## 필드별 3분류 표

| actio_pauliana_calc_v3 필드(군) | 우선순위 | 이유 | 실무 메모 |
|---|---|---|---|
| `case_metadata.matter_id` / `claim_group_id` / `claim_id` / `working_title` | BO 우선 | 두 문서 중에서는 BO가 사건 단위 구조화와 연결성이 더 높다. | 실제 1차 소스는 claim file/시스템 식별자이다. |
| `case_metadata.review_status` / `overall_confidence` | BO 우선 | 회의록보다 구조화 문서와 결합될 때 정리하기 쉽다. | 실제로는 별도 검토 상태 필드다. |
| `canonical_case_facts.fraudulent_act_date` | BO 우선 | BO는 행위별 `BehaviorTime`이 구조화되어 있어 바로 매핑 가능하다. | 회의록은 chronology 보조에 유용하지만 직접 매핑성은 BO가 높다. |
| `canonical_case_facts.asset_identity.asset_id` | 둘 다 필요 | BO는 행위별 객체를 구조화하지만, 회의록은 별칭·축약표현을 실제 자산으로 해석하는 데 강하다. | 동일/유사 자산이 여러 개 있을 때 회의록 보강이 중요하다. |
| `canonical_case_facts.asset_identity.property_label_for_schedule` | 둘 다 필요 | BO의 객체 구조와 회의록의 자산 설명을 결합해야 소장 문안용 라벨이 안정된다. | 등기부/증거 제목과의 정합성 점검 필요. |
| `canonical_case_facts.asset_identity.transaction_type` | client_meeting 우선 | 형식상 매매라도 실질상 대물변제·채무갈음인지 해석하는 데 회의록이 더 직접적이다. | 다만 최종 확정은 증거문서와의 일치가 필요하다. |
| `canonical_case_facts.asset_identity.transaction_date` | BO 우선 | BO의 행위일자는 구조화되어 있어 곧바로 사용 가능하다. | 회의록은 chronology cross-check 용도. |
| `canonical_case_facts.asset_identity.registration_date` | BO 우선 | 두 문서 중 회의록은 단독 근거 금지이고, BO가 상대적으로 downstream 연결성이 높다. | 실제 1차 소스는 evidence/evidence_indexed다. |
| `canonical_case_facts.asset_identity.registry_office` / `registry_receipt_no` / `registry_recorded_transfer_date` | BO 우선 | client meeting은 단독 근거 금지, BO는 사건행위 단위로 매핑 포인트를 준다. | 실제 값은 등기부 기반으로 채워야 한다. |
| `canonical_case_facts.remedy_gatekeeping.selected_remedy_mode` | 둘 다 필요 | BO는 처분행위·후행행위를 구조화하고, 회의록은 왜 원물반환이 곤란한지 맥락을 제공한다. | 가액배상/말소등기 분기 판단은 둘을 함께 봐야 안정된다. |
| `canonical_case_facts.remedy_gatekeeping.is_value_compensation_exception_triggered` | 둘 다 필요 | BO만으로는 예외사유의 법적 평가가 부족하고, 회의록만으로는 구조가 약하다. | 전득자 선의, 담보권 사후 소멸, 경매·배당 사정은 회의록 보강이 유용하다. |
| `canonical_case_facts.remedy_gatekeeping.exception_reason_tags` | client_meeting 우선 | 관계, 악의 정황, 현물회복 곤란성의 narrative는 회의록이 더 풍부하다. | 단, 최종 태그 확정은 BO/evidence와의 합치 필요. |
| `market_value_policy` 전반 | client_meeting 우선 | 시가의 대략적 범위와 실무상 보수적 접근의 맥락은 회의록이 더 직접적이다. | 최종 가치정책은 감정/객관자료로 보정해야 한다. |
| `market_value_fields.market_value_at_act` | client_meeting 우선 | 회의록이 자산별 시가를 사건 맥락과 함께 제시하는 경우가 많다. | 직접 증거가 있으면 그것이 우선한다. |
| `market_value_fields.market_value_close_candidates[]` | client_meeting 우선 | 회의록이 “현재까지 시가” 같은 거친 후보를 줄 수 있다. | 다만 최종 입력으로는 감정/객관자료가 추가되어야 한다. |
| `market_value_fields.market_value_close_candidates[].candidate_amount` | client_meeting 우선 | rough candidate는 회의록에서 시작되기 쉽다. | 그대로 final 값으로 쓰기에는 부족하다. |
| `market_value_fields.market_value_close_candidates[].valuation_date` / `basis_type` / `evidence_refs` / `distance_to_close_days` | 둘 다 필요 | BO는 구조적 연결점을 주고, 회의록은 대략의 시간 맥락을 준다. | 실제 값은 감정자료, 공시자료 등 추가 문서가 필요하다. |
| `market_value_fields.property_value_at_close_of_arguments.final_close_selected` | 둘 다 필요 | BO로 자산 범위를 정하고 회의록으로 대략 시가를 이해하지만, 둘 중 어느 하나만으로는 부족하다. | 실무상 별도 감정/보정 전에는 확정 곤란. |
| `market_value_fields.provisional_value_compensation_base.selected_value` | 둘 다 필요 | 소장 단계 잠정 특정액은 BO의 구조와 회의록의 시가·부담승계 맥락을 함께 써야 산정이 쉽다. | filing 단계에서 가장 현실적으로 둘을 함께 쓴다. |
| `encumbrance_inputs.secured_claims_existing_at_fraudulent_act[]` | 둘 다 필요 | BO는 개별 변제·담보 관련 행위를 구조화하고, 회의록은 어떤 채무가 매매대금 갈음 항목인지 맥락을 제공한다. | 실제 scalar는 evidence/evidence_all로 보정 필요. |
| `encumbrance_inputs.secured_claims_existing_at_fraudulent_act[].holder` / `kind` / `rank` | BO 우선 | 구조화된 행위와 연계가 BO 쪽이 더 쉽다. | rank 등은 등기부/evidence에서 확정해야 한다. |
| `encumbrance_inputs.secured_claims_existing_at_fraudulent_act[].actual_secured_debt_at_act` | 둘 다 필요 | BO는 사건행위와 지급사실을 제공하고, 회의록은 그 지급이 어떤 담보채무를 의미하는지 풀어 준다. | 정확 금액은 증거문서가 우선한다. |
| `encumbrance_inputs.secured_claims_still_existing_at_close[]` | BO 우선 | client meeting은 변론종결시 존속부담을 잘 주지 못하고, BO가 chronology 연결에는 더 유리하다. | 그래도 최종적으로는 후속 잔액증명/말소 여부 자료가 필요하다. |
| `encumbrance_inputs.secured_claims_still_existing_at_close[].released_date` / `released_by_beneficiary` | BO 우선 | 담보권 소멸·변제 행위는 BO가 구조화하기 좋다. | 회의록은 경위 설명 보조. |
| `encumbrance_inputs.lease_deposit_deductibility.*` | 둘 다 필요 | 회의록은 임대차의 배경과 금액을 설명하고, BO는 사건행위와 자산 연결을 돕는다. | 점유·전입·확정일자는 별도 증거가 핵심이다. |
| `encumbrance_inputs.lease_deposit_deductibility.tenant_name` / `lease_deposit_amount` | client_meeting 우선 | 회의록이 임차보증금 구조를 더 직접적으로 서술하는 경우가 많다. | 단독 확정은 증거문서와 함께 해야 한다. |
| `encumbrance_inputs.lease_deposit_deductibility.selected_deductibility` | 둘 다 필요 | 공제 여부는 BO의 구조와 회의록의 맥락을 함께 봐야 판단이 가능하다. | 최종 결론은 임대차 증거와 우선순위 검토가 필요하다. |
| `encumbrance_inputs.non_deductible_attachment_claims[]` | BO 우선 | 가압류·변제 행위를 사건 단위로 분리해 두는 데 BO가 유리하다. | 회의록은 왜 비공제인지 narrative 보강용이다. |
| `encumbrance_inputs.non_deductible_attachment_claims[].holder` / `claim_amount` / `proof_doc` | BO 우선 | 구조화된 연결과 evidence index 매핑이 BO가 더 직접적이다. | 실제 금액 확정은 evidence/evidence_all 우선. |
| `common_collateral_value.asset_level_table` | 둘 다 필요 | BO는 자산별 행위 묶음을 제공하고, 회의록은 각 자산의 시가·부담 구조를 설명한다. | 계산 결과는 파생필드다. |
| `common_collateral_value.selected_for_relief` | 둘 다 필요 | 원시값은 둘을 함께 써서 구성되므로 최종 선택도 둘 다 의존적이다. | final stage에서는 추가 증거가 더 중요하다. |
| `beneficiary_gain.components.nominal_transfer_value` | BO 우선 | BO의 처분행위 자체가 nominal transfer value의 앵커 역할을 한다. | 회의록은 대가구성 해석 보조. |
| `beneficiary_gain.components.assumed_debt_amount` | 둘 다 필요 | BO는 개별 채무 변제/인수 행위를 나누고, 회의록은 그것이 매매대금 갈음인지 설명한다. | 박수용/김수철 관련 사건에서 특히 둘 다 중요하다. |
| `beneficiary_gain.components.beneficiary_preexisting_claim_amount` | 둘 다 필요 | BO는 기존 대여·채권 행위를 포착하기 쉽고, 회의록은 그 채권이 수익자와 어떤 관계인지 설명한다. | 존재 자체와 금액은 추가 증거로 재확인 필요. |
| `beneficiary_gain.components.released_encumbrance_amount` | BO 우선 | 담보해지·변제행위는 BO가 직접적인 구조를 준다. | 회의록은 해지 경위 보조. |
| `beneficiary_gain.components.other_positive_component` / `other_negative_component` | client_meeting 우선 | 구조화되지 않은 사정, 특수관계, 변칙 대가구성은 회의록에서 먼저 드러나는 경우가 많다. | 다만 final 산입 전에는 증거 정리 필요. |
| `beneficiary_gain.scenario_table` | 둘 다 필요 | BO가 행위별 후보를, 회의록이 실질 수익 구조를 제공한다. | 시나리오 분기 설계에서 둘 다 유용하다. |
| `beneficiary_gain.selected_for_relief` | 둘 다 필요 | 최종 수익자 이익 선택은 구조화와 맥락 해석이 모두 필요하다. | calculation 단계의 파생필드다. |
| `plaintiffs[].plaintiff_name` / `claim_type` | BO 우선 | BO는 채권행위를 주체별로 이미 구조화한다. | 회의록은 사건배경 보강용. |
| `plaintiffs[].plaintiff_claim_snapshot.claim_type` | BO 우선 | 원대출/보증/구상금/배당회수 등 사건행위 구분은 BO가 직접적이다. | 회의록은 chain 설명 보조. |
| `plaintiffs[].plaintiff_claim_snapshot.principal_existing_at_fraudulent_act` | BO 우선 | 대출·보증·대위변제 등 원행위의 구조화는 BO가 우수하다. | 정확 수치는 evidence 기반 보정 필요. |
| `plaintiffs[].plaintiff_claim_snapshot.secured_portion_at_fraudulent_act` / `unsecured_portion_at_fraudulent_act` | 둘 다 필요 | BO는 담보설정/배당/변제 chronology를 주고, 회의록은 실질 담보구조를 풀어 준다. | 계산은 별도 증거와 함께 해야 한다. |
| `plaintiffs[].plaintiff_claim_snapshot.contractual_interest_rate` / `default_interest_rate` | BO 우선 | 회의록 단독 근거 금지 필드이고, BO가 관련 약정행위 구조에 더 가깝다. | 실제 수치는 evidence/evidence_all이 우선한다. |
| `plaintiffs[].plaintiff_claim_snapshot.interest_start_date` | BO 우선 | 채권발생·만기·연체·대위변제 시점의 구조화는 BO가 더 직접적이다. | 회의록은 chronology 보조. |
| `plaintiffs[].plaintiff_claim_snapshot.amount_as_of_close_of_arguments` | BO 우선 | 둘 중에서는 BO가 더 낫지만, 실제로는 후속 잔액자료가 핵심이다. | BO나 회의록만으로는 보통 불충분하다. |
| `plaintiffs[].interest_engine.segment_table` | BO 우선 | segment 구간 설정은 사건행위의 날짜 구조화가 핵심이므로 BO가 우선한다. | 수치 입력은 evidence/evidence_all이 필수다. |
| `plaintiffs[].preserved_claim_principal` | BO 우선 | 구조화된 원채권/구상채권 행위가 선행되어야 한다. | 회의록은 보조 설명용. |
| `plaintiffs[].preserved_claim_interest_until_close` | BO 우선 | segment 구성과 chronology는 BO가 우선이다. | 최종 계산에는 추가 수치자료 필요. |
| `plaintiffs[].preserved_claim_total` | BO 우선 | 원금·이자 파생의 기반이 BO 측 구조다. | 회의록만으로는 부족하다. |
| `plaintiffs[].recovery_cap` | 둘 다 필요 | 공동담보가액, 수익자 이익, 피보전채권 총액 모두가 결합되는 파생값이다. | BO와 회의록을 함께 보되, 최종값은 추가 증거가 좌우한다. |
| `drafting_workflow.filing_stage_policy` | 둘 다 필요 | filing 단계 잠정 특정액은 BO의 구조와 회의록의 시가·맥락을 함께 활용하는 것이 실무상 자연스럽다. | 절차정책 필드다. |
| `drafting_workflow.amendment_policy` | client_meeting 우선 | 어떤 부분이 소송 중 보정될 가능성이 큰지 파악하는 데 회의록의 맥락이 더 직접적이다. | 실제 amendment trigger는 후속 증거가 정한다. |
| `drafting_workflow.relief_text_blocks` | 둘 다 필요 | BO는 날짜·행위·당사자 특정성에, 회의록은 문안의 실질 서사에 기여한다. | 최종 문안은 claim file와 규칙문서도 함께 봐야 한다. |
| `output_blocks.relief_summary` | 둘 다 필요 | 특정성과 서사성 모두 필요하다. | BO는 skeleton, 회의록은 context. |
| `output_blocks.cause_summary` | 둘 다 필요 | 원고 측 사건 narrative는 회의록이, 일시·행위·객체 특정은 BO가 강하다. | 둘 중 하나만으로는 거칠어지기 쉽다. |
| `output_blocks.internal_reasoning_notes.direct_evidence_fact_ids` | BO 우선 | evidence index와 사건행위의 직접 연결은 BO가 가장 유리하다. | 실제 fact/evidence layer와 병행 확인 필요. |
| `output_blocks.internal_reasoning_notes.missing_inputs` | 둘 다 필요 | BO로 구조 누락을, 회의록으로 맥락 누락을 더 잘 발견한다. | 검토메모 성격이 강하다. |
| `output_blocks.internal_reasoning_notes.next_required_actions` | 둘 다 필요 | 어떤 문서를 더 확보해야 하는지 판단할 때 BO와 회의록이 서로 다른 공백을 보여 준다. | 실무 검토용 필드다. |

## 압축 결론

### 1. BO 우선인 필드군

다음 성격의 필드는 대체로 **BO 우선**이다.

- 사해행위일, 행위일자, 당사자 역할, 대상 객체 등 **행위 단위의 구조화 사실**
- 원고 채권 snapshot의 뼈대, 이자 segment의 기간 구분, 지급·배당·변제 등 **chronology 기반 계산필드**
- 가압류·변제·담보해지처럼 **개별 사건행위가 직접 대응되는 필드**

즉, **v3의 skeleton을 세우는 입력원**은 BO가 더 낫다.

### 2. client_meeting 우선인 필드군

다음 성격의 필드는 대체로 **client_meeting 우선**이다.

- 형식상 매매인지 실질상 대물변제인지 같은 **실질 거래유형 해석**
- 개략 시가, 특수관계, 악의 정황, 수익자 이익의 비정형 요소 등 **맥락·서사 중심 필드**
- 소송 중 어떤 부분이 다툼이 될지, 어떤 부분을 감정·보정할지에 관한 **전략적 보강 포인트**

즉, **v3의 interpretation layer를 보강하는 입력원**은 client meeting이 더 낫다.

### 3. 둘 다 필요한 필드군

다음 성격의 필드는 대체로 **둘 다 필요**하다.

- `asset_id`, `property_label_for_schedule`, `selected_remedy_mode`, `assumed_debt_amount`, `common_collateral_value`, `beneficiary_gain`, `recovery_cap`, `relief_summary`, `cause_summary`
- 다시 말해 **구조화된 skeleton과 서사적·실질적 맥락이 동시에 필요한 파생필드**

실무적으로는 다음 원칙이 가장 안정적이다.

> **BO.json으로 기본 뼈대를 세우고, client_meeting.md로 실질 관계·시가 배경·특수관계·예외사유·거래의 실질을 보강한다.**