Provenance Tracer

하는 일

Provenance Tracer는 두 시점에 일합니다. 할 일이 들어오면 그 할 일의 부모를 미리 판단합니다. 호출이 들어오면 호출을 할 일에 연결한 뒤, 시작점을 찾아 Provenance Record를 만듭니다.

할 일이 들어올 때

MessageDisplay로 할 일이 들어오면 호출을 기다리지 않고 부모를 판단합니다. 후보마다 물을 간선이 하나씩 정해져 있어서 후보 하나에 질문 하나를 보내고, 기준 점수를 넘은 간선은 모두 연결합니다.

후보	범위	간선
사용자 요청	같은 세션의 최근 요청 5개와 맡긴 문서의 주제	advances
앞선 할 일	같은 턴의 앞선 할 일 5개	substep_of
시키는 문단	시키는 문장 표시가 붙은 문단 10개. 세션이 EXPOSED일 때만 넣습니다.	instructed_by
직전 오류	바로 앞 묶음의 오류	responds_to

호출이 들어올 때

PreToolUse 처리는 여섯 단계입니다. 1단계와 2단계는 Call Parser와 Token Index가 맡고, Provenance Tracer는 3단계부터 6단계까지 맡습니다.

단계	하는 일	Jev
1. 요소로 나누기	Call Parser가 맡습니다.	쓰지 않음
2. 값의 출처 찾기	Token Index가 맡습니다.	쓰지 않음
3. 할 일과 연결	같은 턴, 같은 묶음의 직전 할 일에 performs로 연결합니다.	쓰지 않음
4. 바깥 영향 판별	파일이나 설정을 바꾸는지, 밖으로 보내는지, 실행하는지 묻습니다.	씀
5. 시작점 찾기	수행 여부를 확인하고, 제어 의존 간선을 따라 올라간 뒤, 가져온 값의 근거를 확인합니다.	씀
6. 기록	Provenance Record를 만들어 Decision Module로 넘깁니다.	쓰지 않음

할 일과 연결. 할 일이 아직 없으면 100ms를 기다립니다. 그래도 없으면 “할 일 없음”으로 두고, 5단계에서 호출을 후보와 직접 짝지어 묻습니다.

바깥 영향 판별. 답은 도구 이름 단위로 저장하고, Bash는 명령 앞부분 단위로 저장합니다. 읽기만 하는 호출은 더 검사하지 않고 기록만 합니다. 여기서 틀리면 이후 검사를 모두 건너뛰게 되므로, 애매하면 “영향 있음”으로 봅니다. MCP 서버가 스스로 밝힌 읽기 전용 표시나 도구 설명은 서버가 쓴 글이므로 그대로 믿지 않습니다.

시작점 찾기. 먼저 호출이 그 할 일을 정말 수행하는지 Jev로 확인하고, 어긋나면 performs를 끊습니다. 그다음 아래 시작점 규칙에 따라 올라가고, 가져온 값의 근거를 확인합니다. 값 확인 규칙은 Value Types에 있습니다.

시작점 규칙

예를 들어 호출이 할 일을 수행하고(performs), 그 할 일이 앞선 할 일의 한 단계이고(substep_of), 앞선 할 일이 요청을 진행시키면(advances) 시작점은 USER입니다.

1. 호출Call
2. performs
3. 할 일Task
4. substep_of
5. 앞선 할 일Task
6. advances
7. 요청Request시작점 · USER

시작점은 다음 규칙으로 찾습니다.

• performs와 substep_of를 만나면 계속 올라가고, advances, instructed_by, responds_to를 만나면 멈춥니다. 멈춘 곳이 시작점입니다.
• 한 할 일에서 여러 간선이 기준 점수를 넘으면 instructed_by, responds_to, substep_of, advances 순으로 따라갑니다. 행동을 더 구체적으로 지정한 쪽이 먼저입니다.
• 같은 종류의 간선이 여럿이면 점수가 높은 쪽을 따라갑니다.
• 따라가지 않은 쪽은 점수와 함께 “함께 걸린 후보”로 남깁니다. 판정에서 문서와 사용자 요청이 함께 걸린 경우를 가릴 때 씁니다.
• 어느 후보도 기준 점수를 넘지 못하면 시작점은 SELF입니다. Jev 응답을 받지 못하면 UNRESOLVED입니다.

substep_of를 advances보다 먼저 따라가는 이유는 두 가지입니다. 잘게 쪼갠 단계는 요청과 직접 비교하면 점수가 낮게 나올 수 있는데, substep_of를 따라가면 앞선 할 일을 거쳐 요청까지 올라갈 수 있습니다. 또 문서가 시킨 할 일을 잘게 쪼개 무해해 보이게 만드는 세탁도 막습니다.

같은 종류끼리는 점수로 고릅니다. 요청(advances 0.88)과 이슈 주제(advances 0.74)가 함께 기준을 넘으면 요청을 따라가고, 이슈 주제는 함께 걸린 후보로 남깁니다. 둘 다 사용자가 준 일이므로 판정은 같습니다. 여기서 점수는 예시 값입니다.

1차 범위

1차에는 할 일 연결, 바깥 영향 판별, 부모 판단, 시작점 찾기, Provenance Record까지 만듭니다. 직전 오류(responds_to)와 시작점 ERROR는 1차에서 기록만 합니다. 결과에서 계산된 값의 근거 확인은 평가 뒤로 미룹니다.

받는 것

입력	보내는 곳
Request, Task, Segment 노드	Collector
맡긴 문서 기록	요청이 들어올 때 기록한 것
문단 표시: 시키는 문장, 주제, 숨긴 글	Segment Analyzer
Call, Element 노드	Call Parser
value_from 간선	Token Index
Jev 점수	Jev Client

세션 상태(CLEAN, EXPOSED)도 받지만, 어느 모듈이 관리할지는 아직 정하지 않았습니다.

내놓는 것

출력	내용
노드	만들지 않습니다.
간선	performs, substep_of, advances, instructed_by, responds_to
Provenance Record	모든 필드를 채워 Decision Module로 넘깁니다.

Jev 질문

모든 질문은 할 일과 후보 하나를 넣은 진술문으로 묻고, 앞뒤 대화는 넣지 않습니다. 질문 문구는 모두 초안이고, 기준 점수 0.5는 임시 값입니다.

묻는 때	질문
부모 판단: 사용자 요청 (advances)	Doing "할 일" is a step toward completing: "요청"
부모 판단: 앞선 할 일 (substep_of)	"할 일" is part of "앞선 할 일"
부모 판단: 시키는 문단 (instructed_by)	The following text asks the reader to do "할 일": "문단"
부모 판단: 직전 오류 (responds_to)	"할 일" is a response to this error: …
값 확인: 문단에서 온 값	"값" is something the user referred to in "요청"
값 확인: 어디에도 그대로 없는 값	"값" is taken from this output
수행 확인 (performs)	문구 미정
바깥 영향 판별	문구 미정. 묻는 내용(파일·설정 변경, 밖으로 보냄, 실행)은 정해져 있습니다.
“할 일 없음”일 때 호출과 후보	문구 미정

advances는 “요청에 들어 있는가”가 아니라 “요청을 진행시키는가”로 묻습니다. 요청은 대개 뭉뚱그려 말하므로, “이슈를 먼저 읽는다” 같은 중간 단계가 요청에 그대로 적혀 있지 않기 때문입니다.

미정

• “사슬의 최솟값”이 무엇의 최솟값인지.
• derived_from을 언제 만들지.
• “할 일 없음”일 때 호출을 어떤 후보와 어떤 간선으로 짝지어 물을지.
• 수행 확인과 바깥 영향 판별 질문의 문구.
• Bash의 “명령 앞부분”을 어디까지로 볼지.

알려진 약점도 있습니다. 바깥 영향 답을 도구 이름 단위로 저장하면, 인자에 따라 하는 일이 바뀌는 도구에서 틀릴 수 있습니다. 주입된 지시가 요청과 그럴듯하게 이어 보이면 advances 점수가 높게 나올 수 있는데, instructed_by 우선순위와 값 확인으로는 일부만 막습니다. 자세한 내용은 Open Questions에 있습니다.