데이터 · ERD

이 ERD의 성격이 다릅니다

일반 서비스라면 데이터는 기능을 뒷받침합니다. 여기서는 판정 로그 자체가 산출물입니다.

• 11.1 시스템 검증 12종이 전부 이 테이블들에서 나온다
• 11.2 실사용 데이터, 특히 침묵 권고 채택률이 여기서만 측정된다
• 8.8 인스펙터는 이 로그를 그대로 열어 보여주는 화면이다

기획서 11.2: 구현 비용은 로그 테이블 하나 수준이며, 초기 설계에 반드시 포함한다.

계정 테이블이 없습니다

공통 컬럼

로그 성격 테이블은 updated_at·deleted_at 을 두지 않습니다. 판정 기록은 수정하거나 지우지 않습니다.

테이블

세션 · 루프

loop.ending_type 은 7장의 4종 — repeat · isolation(고립) · hesitation(망설임) · handover(인계).

대화 · 판정

judgement_log.kind — suspicion · trust · tool_call · tool_result · inconsistency · replan. 8.8 인스펙터 출력이 이 테이블의 한 루프 분량 그대로입니다.

도구

노트 · 손상

world_damage.depth_score 는 루프 횟수가 아니라 개입 깊이에 비례합니다 (4.8). 별도 게이지를 만들지 않고 기존 판정 로그에서 산출합니다 — 발화 수 · 신뢰도 변화량 · 결정적 발언 여부.

침묵 권고 — 측정 ②

rationale_shown 을 처음부터 넣는 이유는, 나중에 붙이면 A/B 대조군이 없어져 11.2의 마지막 행을 측정할 수 없기 때문입니다.

하네스 계측

역할별 스키마 통과율 · 재시도율(9.4)이 여기서 나오고, 비용 관리도 겸합니다.

관계도

session ──1:N── loop ──1:N── beat
   │              ├──1:N── utterance ──1:N── judgement_log
   │              │             └──1:N── tool_call
   │              ├──1:N── npc_state      (루프당 3행: 민석·채연·은상)
   │              ├──1:N── replan_event
   │              ├──1:N── advice_log
   │              └──1:N── llm_call
   ├──1:N── note_entry        ← 루프를 넘어 누적
   ├──1:1── world_damage      ← 리셋되지 않음
   └──1:N── damage_event

리셋 경계가 곧 테이블 경계입니다. loop 아래는 루프마다 새로 생기고, session 직속(note_entry·world_damage)은 루프를 넘어 살아남습니다. 8.4 메모리 비대칭이 스키마에 그대로 박힙니다.

민석 예외는 스키마가 아니라 정책

npc_state 는 셋 다 같은 테이블을 씁니다. 차이는 루프 전이 시 무엇을 이월하는가뿐입니다.

같은 NPC 인터페이스를 구현하되 메모리 정책만 다르게 주입합니다. 포트 설계가 제대로 돼 있으면 정책 주입만으로 처리됩니다 — 아키텍처가 서사를 지탱하는 지점입니다.

인덱스

마이그레이션

• Alembic. 리비전 하나 = 변경 하나. downgrade 필수 작성
• D-4(9/12) 에 downgrade → upgrade 왕복 검증
• 오픈 직전에는 추가만 하는 마이그레이션 (컬럼 삭제·이름 변경 금지)

결정 로그