Sanctum SSOT Storage Policy 향상 보고서

보고서 목적

이 보고서는 Sanctum LLM 운영에서 어떤 지식이 진짜 원본인지, 어떤 지식이 탐색 또는 파생 계층인지 구분하기 위한 의사결정 문서다. 원본 sanctum-ssot-storage-policy.md는 contracts/, repo Markdown, Notion, RAG, Graphify, Derived Knowledge의 권위 차이를 정리했다. 이 보고서는 그 결론을 실제 서비스 작업자 운영 규칙으로 변환한다.

핵심 결론

Sanctum의 SSOT는 사람이 읽고 리뷰하며 diff로 검증할 수 있는 canonical 문서와 코드/계약 소스에 있어야 한다. Graphify graph, RAG DB, 임베딩, 자동 요약, LLM 분석 결과는 SSOT가 아니라 파생 인덱스 또는 Derived Knowledge다.

contracts/는 서비스 간 계약의 canonical SSOT다.
root 및 service AGENTS.md는 worker 실행 규칙과 작업 경계의 canonical 운영 SSOT다.
service llm-context/는 worker가 반복적으로 읽는 실행 문맥이다.
Notion은 human-facing product/system/runbook 포털로 유지하되 worker write boundary의 직접 권위가 되면 안 된다.
Graphify는 navigation/context-router이며 SSOT나 write authorization engine이 아니다.
RAG는 evidence retrieval cache이며 canonical source를 대신하지 않는다.
Derived Knowledge는 conclusion, reasoning, confidence, validation state, stale condition, source link를 포함해야 한다.

원본 문서의 주요 내용

Sanctum 지식 계층은 canonical SSOT, Derived Knowledge, retrieval/navigation layer로 나뉜다. Canonical SSOT에는 contracts/, root/service AGENTS.md, service llm-context/, 사람 중심 Notion portal이 포함된다. Derived Knowledge는 wallet-api 요청이 kms-api, hd-manager, MPC 계층을 거치는 방식 같은 유용한 요약이지만 원본은 아니다. RAG는 근거 후보를 찾고 Graphify는 관련 파일과 서비스 관계를 찾지만 무엇이 사실인지 또는 어디를 쓸 수 있는지 결정해서는 안 된다.

Sanctum 적용 해석

Sanctum에서는 계약과 실행 문맥이 섞이면 위험하다. wallet-api worker가 kms-api 응답 schema를 service-local 문서에 복제해 두면 이후 contracts/가 바뀌어도 낡은 복제본을 기준으로 구현을 수정할 수 있다. 따라서 service llm-context/contracts.md는 계약 내용을 복사하지 않고 canonical contracts/ 경로, 사용 위치, handoff owner, 검증 조건만 기록해야 한다.

kms-api는 key management와 signing boundary를 다룰 가능성이 높으므로 Notion 설명, RAG 검색 결과, Graphify edge만으로 key behavior를 바꾸면 안 된다. 반드시 canonical contract와 service owner review 또는 root/e2e handoff가 필요하다.

hd-manager는 wallet derivation과 downstream MPC 흐름의 중간 경계다. Flow 요약도 원본은 아니며 실제 계약은 contracts/, 실제 실행 경계는 AGENTS.md, 실제 검증은 service test와 e2e test가 판단한다. Rust MPC 계층의 protocol behavior는 canonical protocol contract와 e2e 검증을 요구해야 한다.

운영 판단

지식 유형	Canonical 위치	파생/보조 위치	운영 규칙
서비스 간 계약	`contracts/`	Graphify edges, RAG chunks, service contract map	복제 금지, 변경 시 proposal/handoff
worker 실행 규칙	root/service `AGENTS.md`	onboarding 요약	runtime allowlist와 diff guard로 집행
서비스 실행 문맥	service `llm-context/`	Derived service summary	실제 명령/경로는 repo 검증 후 확정
human overview	Notion 및 필요한 repo mirror	RAG index	worker-critical 내용은 repo-local로 제공
flow/e2e 판단	root/e2e docs와 tests	Graphify route, flow summary	cross-service 변경은 root/e2e agent 담당
분석 결론	Derived Knowledge store	RAG index	confidence/stale/source 필수

핵심은 원본을 사람이 리뷰 가능한 곳에 두고, 자동화 도구는 원본을 찾는 데만 쓰는 것이다.

리스크와 가드레일

Notion-only SSOT 위험: worker-critical 정책은 repo Markdown으로 mirror해야 한다.
Repo-only SSOT 위험: product/operation owner가 문서를 유지하지 않을 수 있으므로 Notion은 사람용 상위 포털로 유지한다.
Contract duplication 위험: service contracts.md는 복제본이 아니라 pointer 문서여야 한다.
RAG truth 위험: retrieval score는 truth score가 아니다. 최종 판단 전 canonical file direct read가 필요하다.
Graphify authority 위험: Graphify drift가 write boundary를 잘못 확장할 수 있다.
Codex App workspace 위험: workspace 분리는 risk reduction일 뿐 hard write boundary가 아니다.
Derived summary laundering 위험: 재요약 과정에서 source와 confidence가 사라질 수 있다.

실행 체크리스트

contracts/를 contract-only canonical 영역으로 선언한다.
root/service AGENTS.md에 write/read/propose-only 경계를 명시한다.
각 service에 llm-context/service.md, commands.md, test-scope.md, e2e-role.md, contracts.md, dependency-stubs.md를 둔다.
service contracts.md에는 canonical contract path와 사용 위치만 기록한다.
Derived Knowledge에는 confidence, validation state, stale condition, source link를 포함한다.
Graphify/RAG 문서에 SSOT 아님을 명시한다.
discord-codex-bot runtime에서 write allowlist와 diff guard를 적용한다.
contract 변경은 service worker 직접 수정이 아니라 proposal 또는 root/e2e handoff로 시작한다.