예측보다 먼저,
검증 가능한 과정을.

Persona Lab 공개 실험 방법론

공개 방법 revision: v2-r3 · 원본 대조일: 2026-09-27 · 문서 성격: 재현·검토용 공개 설명(비공개 계약 전문의 대체본 아님)

이 문서는 다른 AI·연구자·실행기가 Persona Lab의 실험을 같은 규칙으로 이해하고, 실행 계획을 검토하며, 결과 주장의 범위를 판별할 수 있도록 만든 공개용 방법론이다. 개인 대화 원문, 참여자 이름, 개별 예측, 정답, 내부 실행 기록, 운영 페르소나 전문은 포함하지 않는다. 전체 계약 원문과 원장은 비공개 정본으로 유지한다.

핵심 질문: “그럴듯한 인물 설명을 만들었는가?”가 아니라, 과거에 관측 가능한 정보만으로 다음 반응을 예측하는 규칙이 새 사례에서 더 잘 작동하며 기존에 맞던 사례를 망가뜨리지 않는가?

이 문서에서 설계됨은 계약에 정의되었다는 뜻, 구현됨은 코드가 해당 제약을 집행한다는 뜻, 실행됨은 실제 run 기록이 있다는 뜻이다. 초안 정책은 실제 run의 첫 정답 공개 전에 구체 값과 hash를 동결해야 한다. 세 상태는 서로 대체하지 않는다.

목차

1. 목적·단위·인과 대비
2. 현재 구현과 미구현의 경계
3. 시간·노출·자료 분할
4. P0 시점 적격성과 구성요소
5. CP-01 결정적 맥락 정책
6. Focus·Anchor·Probe 개발 패널
7. 공통 입력과 예측 출력
8. C0–C4 국소 후보
9. SCREEN-02와 전체 개발 평가
10. 사례별 수정 효과·회귀·선택
11. 예측 봉인 → 정답 공개 → 평가
12. 점수·통계·증거 상태
13. 반복·중단·장기 검증·최종 평가
14. 10단계 실행 파이프라인
15. 기록 스키마의 의미
16. 실행 전 동결 체크리스트
17. 결과를 읽을 때의 금지된 해석

1. 목적·단위·인과 대비

최적화 대상은 사람의 본질이나 속마음이 아니라 다음 형태의 조건부 예측 규칙 집합이다.

상황 X + 관측 가능한 관계 상태 Y → 예상 반응 Z

관계 상태가 직접 관측되지 않은 추정이라면 가설로 표시한다. 일시적 감정이나 단일 실패를 영구 특성으로 승격하지 않는다. 각 규칙은 최소한 rule_id, 구성요소, 적용 조건, 예상 반응, 근거 사례 ID, 반례·예외, 적용 시점, revision/hash, 검증 상태를 갖는다. 규칙 수나 prompt token 수가 늘었다는 사실은 개선 증거가 아니다.

동일 사례의 기본 대비는 다음과 같다.

같은 사례에서 T와 C는 바이트 단위로 같아야 하고, 메시지 role·순서·구분자, 모델, 설정, 출력 예산도 동일해야 한다. persona 조건에만 더 좋은 일반 지시를 넣거나 P 때문에 C가 추가로 잘리게 해서는 안 된다. 공통 지시를 바꾸면 특정 후보 편집이 아니라 새 protocol revision이다.

2. 현재 구현과 미구현의 경계

따라서 “원장이 순서를 거부한다”는 것은 구현된 보장이고, “모델이 정답을 사전에 보지 않았다”는 것은 별도의 노출 감사가 필요한 주장이다. 해시와 봉인 시각만으로 미열람을 증명하지 않는다.

3. 시간·노출·자료 분할

모든 입력·프로필 근거·사례에는 서로 다른 세 시각을 구분한다.

• event time: 실제 사건이나 발화가 일어난 시각
• available at: 시스템이 그 자료를 입수해 사용할 수 있게 된 시각
• exposed at: 모델·후보 생성기·평가 선택 과정에 노출된 시각

공개된 과거 pilot이나 개발에 사용된 사례를 다시 봉인해 unseen이라고 부르지 않는다. 공개 pilot 전체를 개발에 사용했다면 그보다 과거인 사례는, 별도의 미래 누출 없는 격리 실행이 입증되지 않는 한 clean prequential이 아니라 historical_replay다. 현재 수집한 과거 자료로 과거 시점 prompt를 재구성한 경우도 당시 실제 가용성을 입증하지 못하면 동일하게 표시한다.

자료의 역할은 다음처럼 분리한다.

• dev_archive: 공개된 모든 개발 사례의 보존소. 진단과 회귀 감사에 쓰되 unseen으로 재사용하지 않는다.
• selection_panel: 한 iteration 안에서 후보들을 비교하는 동결 패널. iteration이 다르면 패널 점수를 직접 시간순 성능 향상으로 비교하지 않는다.
• prospective block: prompt·정책을 먼저 고정한 뒤 새 정답을 순차 공개하는 일반 6사례 블록.
• validation track: 최대 1개만 활성화하는 장기 동결 후보 대 reference 추적.
• final test: 개발·track에 쓰지 않은 별도 시간구간의 1회성 봉인 평가.

각 prospective/prequential 블록은 사례마다 세 조건을 서로 격리해 생성한다: context-only 기준 T+C, 직전 선택 규칙 T+P_(t-1)_snapshot+C, 현재 후보 규칙 T+P_t_snapshot+C. 세 조건의 구조화 예측을 모두 정답 공개 전에 봉인하며, 첫 블록처럼 직전 규칙이 없으면 해당 조건을 not_applicable로 기록한다. 공개된 블록은 다음 iteration의 dev 자료로 재사용할 수 있지만 최초 prequential 점수는 불변이다. 공개 뒤 과거 후보를 다시 돌린 결과는 training fit일 뿐 원 점수를 대체하거나 unseen 누적에 들어가지 않는다.

원 계약 메타데이터의 목표 20배치·240사례와 장기 정책의 “일반 prospective block 6사례”는 동시에 존재한다. 현재 공개 설계만으로 둘의 정확한 배정 관계를 추정하지 않으며, 실제 실행 전에 allocation manifest에서 확정해야 한다.

최종 배정 전 PURGE-01은 scene과 source message ID/행 범위를 비교하고 dev 경계 직전 scene 하나를 embargo로 표시한다. final 입력이 dev input/target과 겹치면 final_boundary_purge로 배정 전에 제외한다. 30분 경계가 진행 중인 한 사건을 인위적으로 가른다면 사전 규칙으로 event_cluster를 묶어 경계를 가로지르는 cluster 전체를 제외한다. 판단 절차·담당자·시간 범위를 사전 확정하지 못하면 final allocation은 blocked다. 제외는 원문 삭제가 아니다.

4. P0 시점 적격성과 구성요소

P0는 한 문자열이 아니라 다음 세 요소의 동결 조합이다.

1. 고정 P0_schema
2. 동결 P0_evidence_master
3. 결정적 snapshot renderer

P0_snapshot(case_cutoff)에는 event time과 available at이 모두 cutoff 이전임이 검증된 항목만 포함한다. 노출·가용 시각이 불명확하면 clean 적격으로 취급하지 않는다. 사례마다 snapshot hash가 다른 것은 정상이며, case ID별 hash와 포함/제외 항목·사유를 기록한다. 최종 평가에서 P0 master를 최신 지식으로 보강해서는 안 된다. 미래 정답을 본 뒤 만든 규칙은 근거 날짜만 과거로 필터링해도 clean이 아니다. 적격 근거가 없다면 조용히 빈 P0를 만들지 않고 seed construction blocked로 보고한다.

현재 운영에 쓰는 최신 정보용 P_deployment는 historical 평가용 P0와 분리한다. P의 내부 구성은 다음과 같다.

구성요소별 전문·hash와 조합 순서를 보존한다. REFINE/RELAX는 rule ID를 유지하고 revision을 올린다. DROP된 ID는 재사용하지 않으며, ADD는 새 ID, SPLIT/MERGE는 새 ID와 predecessor ID를 남긴다.

5. CP-01 결정적 맥락 정책

CP-01은 persona 규칙과 분리된 입력 맥락 실험축이며 현재 정식 protocol에서는 설계 초안이다. 외부 smoke의 char_proxy/v0는 CP-01 구현 완료 증거가 아니다. 최초 정식 실행 전에 tokenizer 이름·revision, 렌더 형식, policy hash를 manifest에 동결해야 한다.

• 같은 대화방 또는 DM 안에서 원문 시간순을 보존한다. 인접 메시지 사이가 30분 초과면 scene 경계이고, 같은 시각이면 원문 행 순서를 사용한다.
• target 직전까지 같은 scene의 모든 메시지를 선택한다. 이전 scene 보충 수는 N=0이다. 다른 방, 미래 메시지, 자동 요약·추론은 넣지 않는다.
• 화자·시각·본문을 포함한 동일 렌더링의 예산은 X=4096 tokens다. 넘으면 가장 오래된 메시지부터 완전한 메시지 단위로 제거한다.
• 마지막 메시지 하나도 예산에 들어가지 않으면 임의 발췌하지 않고 context_overflow로 제외한다. 입력이 비면 empty_context로 기록한다.
• 멀티라인은 한 메시지로 보존한다. 미디어·통화는 원문 표시만 제공하며 보이지 않는 내용을 추정하지 않는다.
• source hash, scene/target ID, 선택·제거 메시지 ID/행, 실제 token 수, tokenizer revision, policy hash, input hash를 기록한다.
• 같은 사례의 모든 비교 조건에 바이트 동일 C를 제공한다.

persona 후보를 비교하는 iteration에서 CP를 함께 바꾸지 않는다. CP 비교는 동일하게 동결한 prompt를 쓰는 별도 run이다. N, X, scene 경계를 바꾸면 새 policy ID를 발급한다. 정답 공개 뒤 맥락 부족이 드러나도 해당 사례를 사후 삭제하지 않고 context_sufficiency와 missing reason(scene_boundary, token_truncation, cross_scene_reference, cross_room_reference, media_content_unavailable, other)을 사후 진단으로 기록한다.

6. Focus·Anchor·Probe 개발 패널

세 역할은 모두 이미 공개된 개발 자료이며 독립 검증 자료가 아니다.

PANEL-01은 설계 초안이며 서로 겹치지 않는 Focus 6 + Anchor 6 + Probe 6, 총 18사례를 제안한다. 후보 생성 전에 실제 run의 panel ID/hash, case ID, 선정 이유, 대화 유형, 과거 selection 노출 횟수를 동결한다. 같은 자격군에서는 누적 노출이 적은 순, 이어 iteration hash 순으로 고른다. 역할 부족분을 다른 역할로 조용히 채우거나 중복하지 않는다. 부족하면 descriptive_only로 기록하고 자동 선택을 중지한다.

관측 가능한 다중 태그는 information_question, joke, scheduling, emotion_expression, boundary_setting, conflict, affection, other이며, 불확실하면 unknown이다. target 이전 입력으로만 부여하고 내면 성격을 추정한 태그나 공개 뒤 actual intent를 섞지 않는다. 역할별·유형별 유효 n과 점수를 전체 점수와 함께 보고한다.

7. 공통 입력과 예측 출력

primary target은 다음 텍스트 메시지 하나다. secondary burst는 같은 화자의 연속 텍스트이며 타 화자·시스템·미디어·60초 초과 간격에서 끝난다. answer_predicted는 top-1 메시지 배열이고 첫 메시지가 primary 평가 대상이다. 미디어 target은 별도 task type으로 남기며 성적이 낮다고 사후 삭제하지 않는다.

주행동은 표면의 첫 단어가 아니라 답변 대상에 수행한 핵심 행위다. 수락처럼 시작해도 결론이 거절이면 refuse, 나중에 하겠다는 것은 defer, 대안 제시는 propose다. 동등한 행위가 해소되지 않을 때만 ambiguous를 쓴다. relational move는 이번 메시지에서 관측되는 관계 조절이지 내면 호감도의 순서척도가 아니다.

선언(declared_*)과 실제 생성 첫 문장에서 조건명·선언·정답을 가리고 다시 분류한 값(generated_message_inferred_*)을 분리한다. 실제 답변도 별도로 분류한다. 생성 문장과 선언이 다르면 self-consistency 오류이며, 선언 정확도로 생성 문장의 주점수를 대체하지 않는다.

확률을 쓰는 기본 모드는 primary 9범주, relational 5범주의 전체 분포다. 모든 키, 유한한 [0,1] 값, 합 1±1e-6을 요구하고 잘못된 값을 조용히 정규화하지 않는다. argmax 동률은 사전 enum 순서로 결정한다. 제약상 top-1 confidence만 쓴다면 calibration_mode=top1_only를 run 전에 모든 조건에 동일하게 고정한다.

8. C0–C4 국소 후보

한 iteration은 C0를 포함해 최대 5개 후보를 만든다. 개수를 채우려고 근거 없는 편집을 만들지 않는다.

기본적으로 후보 하나는 규칙 하나에 연산 하나(ADD, REFINE, RELAX, DROP, SPLIT, MERGE)만 적용한다. SPLIT/MERGE는 여러 단위를 건드리는 예외라 관련 ID 전체를 남긴다. 구조적 before/after diff가 선언한 연산과 다르면 수정하거나 제외한다.

통짜 prompt 재작성은 기본 후보가 아니다. 유사 국소 수정 3개가 사전 기준상 차이를 못 만들어 diagnose gate에 도달하고, 구조 문제 가설·변경 범위·비교 예산을 별도 run에 사전 등록했을 때만 허용한다. rewrite 결과를 특정 규칙 하나의 효과로 귀속하지 않는다.

9. SCREEN-02와 전체 개발 평가

SCREEN-02는 현재 설계된 초기 정책이다. 실제 run에서는 canonical hash 구현과 정책 hash를 첫 공개 전에 동결해야 한다. 성능이 낮아 보이는 후보를 빨리 버리는 successive-halving 기법이 아니라 형식·유효성·신규 파손을 찾는 보수적 안전 필터다.

1. 후보 생성 전에 Focus·Anchor·Probe 각 역할에서 아래 canonical JSON의 SHA-256 hex 오름차순 첫 1개를 고른다(최대 3개).

   [protocol_id, iteration_id, role, case_id]

   JSON은 UTF-8, ensure_ascii=false, 공백 없는 comma/colon separator, 고정 배열 순서를 사용한다. hash가 같으면 case ID 오름차순이다.

2. 후보 가설, 수정 rule ID, 허용 연산, 구조 diff, 출력 schema를 검사한다.

3. 새 hard 오류나 사전 정의된 core 신규 파손이 확인되면 탈락시킨다. malformed 출력은 모델 행동 오답이 아니라 protocol failure로 따로 기록한다.

4. cheap 평균이 낮거나 Focus 하나를 못 고쳤다는 이유만으로 탈락시키지 않는다. 효능 기반 조기 탈락을 추가하려면 남은 사례에서 가능한 최대 개선을 고려한 결정적 상한 규칙을 별도 사전 등록해야 한다.

5. 통과한 모든 후보와 parent/C0를 동일한 전체 18사례 패널에서 평가한다. 모든 편집 후보가 탈락하면 C0를 유지한다.

동일 input/prompt/model/settings/seed의 screening 결과는 full dev에 재사용하되 중복 집계하지 않는다. 설정이 다르면 합치지 않는다. 미평가 값은 0이 아니라 null/not_evaluated이며, 부분 평가 후보는 full-dev Pareto 선택에 넣지 않는다. 사례·호출·입출력 token·elapsed time·cache 재사용·탈락 사유·실제 신규 평가 수를 남긴다. 비용 절감은 실제 측정 뒤에만 주장한다.

10. 사례별 수정 효과·회귀·선택

모든 case × field에서 parent와 child의 원값을 보존하고 다음 전이를 계산한다.

• 범주형 primary: wrong→correct = newly_fixed, correct→wrong = newly_broken, 그 외 unchanged_correct/unchanged_wrong.
• 0/0.5/1 적합도: <1→1과 1→<1을 fixed/broken으로, 0↔︎0.5 등은 partial_gain/partial_loss로 기록한다.
• 비교 불가 null은 not_comparable이며 0점으로 바꾸지 않는다.
• 길이·메시지 수는 child_error − parent_error를 보존하며 임의 정답 문턱을 만들지 않는다.

회귀 심각도는 별도 축이다.

• hard_newly_broken: 실제 accept↔︎refuse 반대 예측, 실제 explicit_boundary를 생성 approach로 바꾼 오류, 또는 사전 반대행동표의 신규 오류.
• existing_hard: parent에도 이미 있던 같은 치명 오류. 신규 veto는 아니지만 반드시 보고한다.
• soft_newly_broken: hard가 아닌 relational/context/style 적합도 1→0.5 등의 신규 파손.
• 최초 정책은 core hard 신규 파손 허용 0이다. 평균 상승이 veto를 우회하지 않는다.

동일한 비교 가능 사례 집합에서 높은 primary 정확도·relational/context/style 적합도, 낮은 길이·메시지 수 오차 방향으로 Pareto dominated 후보를 제거한다. null로 공통 집합이 성립하지 않으면 선택을 보류한다.

통과 후보는 primary_action → relational adequacy → context → style → length → segmentation 순으로 보되 indifference band를 적용한다. 18사례 패널에서 primary 정확도 차이 ε=1/18, ordinal 평균 차이 ε=0.5/18 안은 다음 축으로 넘긴다. 유효 분모가 18이 아니면 이 기준을 재해석하지 않고 자동 선택을 보류한다. 길이·분절의 raw-error band가 미등록이면 그 축으로 순위를 정하지 않는다. 이는 통계적 동등성 판정이 아니다.

비추이적 pairwise 토너먼트를 피하고, 각 축의 최고값과 band 안 후보를 모두 다음 축으로 넘긴다. 끝까지 동률이면 짧은 prompt → 적은 active rule 수 → C0 순이다. composite는 참고값이며 gate를 우회하지 않는다. 선택된 P_t 하나만 deployment 후보이고, 동일 패널의 non-dominated 후보 최대 3개는 prompt/hash/edit lineage와 함께 research archive의 active shadow로 남길 수 있다. 서로 다른 패널의 점수를 전역 Pareto 비교하지 않는다.

11. 예측 봉인 → 정답 공개 → 평가

원장의 상태 전이는 다음 순서를 강제한다.

draft → frozen → sealed → revealed → evaluated

1. draft: run config, 조건 목록, prompt 전문, 사례 맥락을 저장한다.
2. frozen: 모든 선언 조건에 정확히 하나의 prompt가 있고 사례가 하나 이상일 때 config·prompt·case·protocol hash를 묶어 동결한다. 이후 prompt와 case를 변경할 수 없다.
3. sealed: 모든 case × condition의 canonical prediction JSON이 저장되어야 한다. 일부 조건만 봉인한 상태에서는 정답 공개로 넘어갈 수 없다.
4. revealed: sealed 이후에만 실제 label을 넣을 수 있고 공개된 label은 불변이다. 모든 사례가 공개되어야 평가 단계로 간다.
5. evaluated: 공개 뒤에만 case × condition 평가를 저장하며 전부 채워져야 완료 상태가 된다.

전문과 canonical JSON SHA-256, 실제 UTC 전이 시각을 보존한다. 과거 시각을 추정해 채우지 않는다. 이 상태 기계는 순서와 불변성을 보장하지만, 입력 생성기가 정답을 다른 경로로 미리 보지 않았다는 사실까지 보장하지는 않는다. 그 주장은 별도의 노출·격리 감사가 필요하다.

12. 점수·통계·증거 상태

주점수와 보조점수

주 endpoint는 생성된 첫 메시지를 blind 분류한 primary_action과 실제 첫 메시지의 primary_action exact-match다. 선언 자체의 적중과 선언/생성 self-consistency는 진단값이다. 실제 label이 ambiguous/null이면 주 exact-match 분모에서 제외하고 이유와 유효 n을 공개한다. 예측만 ambiguous이고 실제가 명확하면 오답이다.

보조 지표는 relational category exact-match, relational/context/style adequacy 0/0.5/1, secondary function, affective mode, 글자 수·메시지 수 오차, calibration이다. 글자 수는 정규화하지 않은 Unicode code point(본문 줄바꿈 포함, 인공 구분자 제외)이며 first message와 burst를 분리한다.

relative_char_error = |predicted_chars - actual_chars| / max(actual_chars, 1)
generated_relative_char_error도 동일
multiclass_brier = Σ_k (p_k - 1[y=k])²    # 비정규화 합, 범위 0–2
top1_binary_brier = (declared_confidence - declared_category_correct)²

가능하면 조건명·선언·정답을 가린 두 평가자가 동결 부분집합을 독립 채점한다. 원점수·불일치·합의·유효 n을 보존하고 범주는 raw agreement/kappa, 적합도는 사전 가중 kappa를 쓴다. 계산 불가면 NA; 같은 모델의 반복 채점은 독립 인간 평가가 아니다.

소표본 통계

• 6사례 한 배치는 provisional이다. 한 배치나 임의 SE 문턱으로 확정 개선을 선언하지 않는다.
• 같은 동결 후보와 reference에 대해 미공개 paired 사례 18개와 30개가 운영 checkpoint다. 표본 수 도달은 검정력·유의성·상태 승격을 자동 보장하지 않는다.
• field별 paired difference는 candidate minus reference다. raw error는 child minus reference이므로 음수가 개선이다. null은 paired 제외 사유와 유효 n을 보고한다.
• 장면 ID를 첫 신규 공개 전에 cluster로 동결하고, paired cluster bootstrap percentile 95% CI를 10,000회, seed 20260921로 계산한다. 같은 scene 관측은 함께 재표집한다.
• cluster가 1개 이하면 CI를 만들지 않고 insufficient_clusters로 남긴다. 적은 cluster나 퇴화된 차이는 지나치게 좁은 CI를 만들 수 있다.
• 18/30 checkpoint CI는 반복 확인·최대 5후보 선택·다중 field 때문에 탐색적이다. CI가 0을 넘는 것만으로 확증하지 않는다.

후보 평가 상태는 dev_only, provisional, supported_on_frozen_unseen_set, inconclusive, rejected다. supported도 특정 동결 자료에서의 제한적 근거일 뿐 성격의 진실, 다른 상황 일반화, 인과적 귀속, 통계적 확증을 뜻하지 않는다. 규칙 자체의 상태(hypothesis, provisional, supported, contradicted, retired)와 후보 평가 상태를 섞지 않는다.

13. 반복·중단·장기 검증·최종 평가

• 유사 국소 수정 3개가 사전 기준상 차이를 못 만들면 문구를 더 붙이는 일을 멈추고 원인을 재진단한다. 맥락 부족이 원인이면 persona를 바꾸지 않고 CP 실험으로 분리한다.
• 연속 3–5개 새 블록에서 persona 이득이 없으면 headroom 부족, 부실 seed/최적화, 평가 잡음, 낮은 검정력을 경쟁 가설로 검토한다. no-gain은 headroom 부재의 증명이 아니다.
• STABILITY-01 초안은 공개 패널에서 역할별 hash 첫 1개(총 3/18)에 대해 C0와 선택 후보를 같은 설정으로 각 2회 추가 생성한다. 재생성은 별도 audit ID/replicate index로 남기며 최초 top-1을 덮어쓰거나 best-of로 선택하지 않는다.
• 장기 validation track은 동시에 최대 1개다. 시작 checkpoint는 iteration 5/10/15로 사전 고정하고, 적격 후보가 없거나 기존 track이 활성화되어 있으면 건너뛴 사유를 기록한다. track은 18/30 유효 pair에서 탐색 보고하고 30개 또는 사전 자료 종료점에서 닫는다.
• final test는 prompt 구조·rubric·사례별 gate·선택 규칙을 고정한 뒤 한 번만 공개한다. 최소 세 조건은 T+C, T+Original P0_snapshot+C, T+Final P*_snapshot+C다. 세 조건의 CP·모델·예산은 같고 모두 정답 전에 봉인한다.
• 최종 보고는 P*−P0와 P*−baseline을 각각 제시한다. final 결과를 보고 다시 튜닝했다면 그 평가는 더 이상 final이 아니다.
• 최종 두 contrast의 다중 비교·표본·순차검정 계획은 실행 전에 동결해야 한다. 현재는 확증 설계가 확보되었다고 주장하지 않는다.

14. 10단계 실행 파이프라인

1. 자료·노출 감사 — 사건·입수·노출 시각, scene, 기존 공개 자료를 구분하고 dev/track/final을 배정한다.
2. 시점별 P0 — schema·evidence master·renderer를 동결하고 사례별 적격 snapshot과 포함/제외 감사를 만든다.
3. 실행 설정 동결 — T/C/P, 모델·예산·rubric·panel·purge·재시도 정책과 모든 hash를 고정한다.
4. 오류 분석·패널 — 오류 cluster와 원인 가설을 만들고 Focus/Anchor/Probe 패널을 동결한다.
5. 국소 후보 생성 — C0–C4, 영구 rule ID, revision, 연산, 구조 diff를 만든다.
6. 선별·회귀 검사 — SCREEN-02 → 동일 full panel → 사례별 edit effect → hard/soft gate → Pareto·indifference 선택을 수행한다.
7. 예측 고정 — 모든 case×condition의 구조화 예측 전문과 hash를 정답 전에 저장한다.
8. 정답 공개 — 예정된 모든 예측이 sealed된 뒤에만 실제 답변을 공개한다.
9. 채점·수정 효과 — blind 생성 분류 기반 주점수, 보조 rubric, fixed/broken/partial, 비용·불일치를 기록한다.
10. 반복·최종 검증 — 공개 block을 dev로 편입하되 원 prequential 점수는 보존하고, frozen track과 별도 final을 분리한다.

15. 기록 스키마의 의미

CSV는 canonical 전문을 대체하지 않고 색인·분석·감사 연결층이다. JSON 배열·객체는 유효 JSON으로 저장한다. 미실행 수치는 빈 값+상태/사유, 실제 측정된 0만 숫자 0, null과 빈 배열은 서로 다른 의미로 취급한다. 옛 intent/distance 혼합 열은 legacy이며 새 r3 행에 자동 변환하지 않는다.

입력 C 전문, task instruction T 전문, 사례별 P snapshot 전문, canonical 요청 전체, 예측 JSON 전문을 각각 보존하고 hash로 연결한다. baseline은 P가 없으므로 빈 값을 명시한다. persona 조건의 prompt hash와 snapshot hash는 일치해야 한다. 같은 candidate prompt hash와 사례별 snapshot hash를 혼동하지 않는다.

16. 실행 전 동결 체크리스트

• protocol ID/revision과 T/schema/render hash
• P0 schema/master/renderer 및 사례별 temporal eligibility·exposure 감사
• CP tokenizer/revision, 30분 scene 규칙, 4096-token 렌더, overflow/empty 처리
• primary/relational 경계 사례집과 평가자·blinding·rubric
• Focus/Anchor/Probe 자격·quota·panel hash와 부족 시 중단 규칙
• SCREEN-02 canonical hash 구현과 hard 반대행동표
• indifference/raw-error band, Pareto 유효 분모, tie-break
• 모델·settings·seed 지원 여부·예산·retry·cache 정책
• block/track/final allocation, PURGE-01, endpoint·다중 비교 계획
• 합성 자료에서 T/C byte parity, P0 미래 누출, 출력 schema, cache/노출 중복, seal→reveal 순서 검증

이 항목이 동결되지 않은 실제 숫자는 빈 값과 미실행 사유로 남긴다. 숫자 0을 “아직 안 함”의 뜻으로 사용하지 않는다.

17. 결과를 읽을 때의 금지된 해석

• 개발 패널 선택을 generalization 또는 개별 편집의 인과 효과 입증으로 부르지 않는다.
• 공개된 과거 사례 재실행을 unseen 또는 clean prequential로 부르지 않는다.
• 봉인 순서·hash를 모델 사전 미노출 증명으로 과장하지 않는다.
• Focus 개선으로 Anchor 파손이나 치명적 반대 행동을 숨기지 않는다.
• null/미평가를 0점으로 바꾸거나 실제 0과 혼동하지 않는다.
• 여러 P_t, 서로 다른 panel, 다른 CP/model/rubric 결과를 한 고정 prompt의 누적 개선처럼 합치지 않는다.
• 글자 수·말투 유사성으로 수락/거절 같은 주행동 오류를 상쇄하지 않는다.
• 규칙 수·prompt 길이·작은 표본·탐색적 CI만으로 “성능 향상 확정”을 선언하지 않는다.
• 실험 규칙을 운영 인물 프로필에 자동 덮어쓰지 않는다.
• 별도 하네스·경량 평가의 결과를 정식 20배치·final evidence로 합산하지 않는다.

정식 실험 완료를 주장하려면 후보 생성·비교, 선택 근거, 공개 전 모든 조건 예측, 실제 공개, 채점, 원본·전문·hash 보존 증거가 모두 있어야 한다.