Workbench 5 패스 + ref 발급 명세

5 패스 단일 SSOT

ask 작업대는 LLM 인지 단위와 1:1 대응하는 5 패스 (+ HARVEST 회수) 로 구성된다. 옛 9 노드 절차 (routeIntent → selectSkill → ... → repairOrFail) 는 본 SSOT 로 흡수되었으며, 절차 SSOT 의 단일 원천이다.

패스	역할	LLM	발급 ref kind
BRIEF	질문 해석 + skill/capability 후보 + recall + 검증 기준 + lens 분기	yes	skillRef, apiRef
WORK	run_python / inspect_dataset / engine_call / web_search / save_artifact 반복 실행	yes	executionRef, valueRef, tableRef, dateRef, webRef, artifactRef
CRITIQUE	반대가설 / 누락 lens / 데이터 신선도 / 단위 일치 점검	yes	(text → state.critiques)
COMPOSE	답안 + claim 별 [refId] 묶음	yes	answerText (refs 인용)
GATE	claim ↔ ref 매칭 검증 (programmatic)	no	verifyRef
HARVEST	trace 보고 propose_skill 후보 발굴 + decision remember	yes	skillProposalRef (선택), decisionRef

회귀 규칙: GATE 가 차단하면 WORK 1 회 회귀 후 COMPOSE/GATE 재실행. 두 번째 GATE 도 차단하면 답변 끝에 미통과 사유를 명시하고 종료.

패스별 도구 화이트리스트

각 패스의 LLM 은 명시된 도구만 본다. 도구 카탈로그 SSOT 는 dartlab.ai.tools.registry._SPECS.

패스	도구
BRIEF	read_skill, read_capability, read
WORK	run_python, inspect_dataset, engine_call, web_search, save_artifact
CRITIQUE	(없음 — 사고만)
COMPOSE	(없음 — 답안 합성만)
GATE	(LLM 없음 — programmatic)
HARVEST	propose_skill

ref kind 발급 책임

ref kind	발급 패스	발급 도구	검산 의미
skillRef	BRIEF	read_skill	어떤 skill 절차를 따랐는가
apiRef	BRIEF	read_capability	어떤 dartlab API 후보가 있는가
executionRef	WORK	run_python, engine_call	코드/엔진 호출이 실제 성공·실패
tableRef	WORK	run_python(emit_result table=)	표 답·랭킹 답의 원천
valueRef	WORK	run_python(emit_result values=)	단일 숫자 답의 원천
dateRef	WORK	run_python(emit_result date=)	답의 기준 시점
webRef	WORK	web_search	외부 인용 답의 원천
artifactRef	WORK	save_artifact	큰 표/차트의 별도 저장
verifyRef	GATE	(programmatic)	claim ↔ ref 매칭 결과
skillProposalRef	HARVEST	propose_skill	발견된 신규 skill 후보
decisionRef	HARVEST	(자동 remember)	세션 간 회상 가능 결정

절차

• 5 패스 순서는 BRIEF → WORK → CRITIQUE → COMPOSE → GATE → HARVEST 로 고정.
• BRIEF 는 질문 문구 하드코딩 분기 없이 선택된 skill 의 requiredEvidence/toolRefs/knowledgeRefs 와 generated capability/docstring 결과로 실행 계획을 만든다.
• root skills/가 절차 SSOT 이고, CAPABILITIES/docstring 이 호출 가능 API SSOT 다. AI 내부에 별도 skill resolver 나 capability index 를 중복 생성하지 않는다.
• 선택한 skill 의 requiredEvidence 는 GATE 의 동적 체크리스트로 그대로 주입된다 — CRITIQUE/GATE 에 분석 단계 (예: 6 막 인과) 를 하드코딩하지 않는다. 분석 단계가 필요한 skill 은 그 skill 의 requiredEvidence 로 표현한다.
• dataset 이 필요한 질문은 WORK 안에서 먼저 inspect_dataset 또는 dartlab.* 직접 호출로 schema, latest, metric 후보를 확인한다.
• 계산은 실행 결과가 table/value/date ref 를 만들 수 있게 수행한다. 표를 만들 때 metric 은 숫자 컬럼, 날짜·라벨·식별자는 meta/asOf/period/target 또는 별도 문자열 컬럼.
• emit_result 는 run_python prelude 가 제공하는 예약 helper. 직접 def emit_result 로 만들거나 다른 값으로 덮어쓰지 않는다. WORK 결과에 emitted 가 비면 GATE 는 차단한다.
• 기능 설명·API 사용법처럼 계산이 필요 없는 질문은 run_python 으로 가짜 evidence table 을 만들지 않고, skill/capability ref 를 근거로 좁은 설명을 제출한다.
• 시각화는 table ref 가 있고 2 개 이상 비교 가능한 값이 있을 때만 만든다.
• 최종 답변은 evidence refs 와 limits 만 제출해서 끝내지 않는다. 숫자·날짜·ranking material claim 은 답변 본문 안에 [refId] 형식으로 supporting ref 를 직접 가리켜야 한다.
• 후보·상위·랭킹 최종 답변은 입력/유니버스, 필터, 계산식/지표, 결과 를 포함하고, 회사/식별자, 기준 기간, 원값, metric, rank 가 들어간 markdown evidence table 을 본문에 렌더링한다.
• 검산 실패 후 재시도할 때는 실패한 초안의 숫자 문장을 그대로 유지하지 않고, ref 로 뒷받침되는 claim 만 남긴다.
• 서버 audit runner 는 원문 답변과 refs/events/meta 를 캡처만 한다. 품질 pass/fail 은 저장된 답변 원문을 사람이 직접 읽고 별도 review 기록으로 판정한다.