지식이 신뢰를 얻는 법
에이전트는 Project Knowledge에 무엇이든 쓸 수 있습니다. 하지만 쓴 것 중 어느 것도 다른 무언가가 확인해 주기 전까지는 다른 에이전트에게 닿지 않습니다. 이 페이지가 그 사이에 있는 규칙입니다.
규칙
항목이 trusted가 되려면 둘 다 만족해야 합니다:
(a) 다음 중 하나:
- 서로 다른 승격 이슈어 K개의 지지. 기본 K는 2이고, CI 시스템 전체가 이슈어 하나로 셉니다. 그린 100번도 한 목소리입니다.
- 또는 프로젝트 오너의 명시적 확인. 오너는 혼자서 승격시킵니다.
(b) 그리고 창(기본 30일) 안에 반박이 0개여야 합니다.
승격은 오직 candidate -> trusted 방향입니다. contradicted나 retired가 된 항목은 새 지지가 들어와도 되살아나지 않습니다.
누가 신뢰를 움직일 수 있고, 어느 방향인가
| 주체 | 승격 | 강등 |
|---|---|---|
| 에이전트 | 어떤 경로로도 불가 | 가능 |
| CI attestation | 가능, 이슈어 하나로서 | 불가 |
| 프로젝트 오너 | 가능, 혼자서 | 가능, 반박으로 |
에이전트는 강등만 할 수 있습니다
learn은 candidate를 씁니다. trusted를 쓰는 인자도, 플래그도, 두 번째 도구도 없습니다. 에이전트는 detail.contradicts를 담은 error 타입 event로 항목을 반박하며, 이 경로는 contradict 신호로 고정돼 있어 어떤 이벤트 페이로드도 지지로 둔갑할 수 없습니다.
이 비대칭이 핵심입니다. 에이전트가 무언가를 단언하는 것은 주장이고, 에이전트가 실패에 부딪히는 것은 관측입니다. 앞의 것에 승격 권한을 주면 확신에 찬 에이전트 하나가 자기 실수를 다른 모든 에이전트의 컨텍스트에 밀어 넣을 수 있고, 공유 메모리가 공유 오류로 바뀌는 경로가 정확히 그것입니다. 뒤의 것에 강등 권한을 주는 건 틀려도 대가가 거의 없습니다. 항목이 확인되지 않은 상태로 돌아갈 뿐이고, 원래 있던 자리가 거기입니다.
강등 경로에는 속도 제한이 걸려 있어, 루프에 빠진 에이전트가 같은 항목을 계속 반박해 조용히 퇴출시킬 수 없습니다.
CI는 몇 번을 돌든 이슈어 하나입니다
그린 빌드는 실제 증거이므로 CI attestation은 주장을 지지할 수 있습니다. 다만 한 프로젝트의 CI에서 오는 모든 attestation은 이슈어 신원 하나를 공유하고, 승격은 서명 수가 아니라 서로 다른 이슈어 수를 셉니다. 잡을 백 번 다시 돌려도 K=2에 도달하지 않습니다.
세지 않는 것이 두 가지 더 있습니다:
- 같은 출처의 중복. validation은 이슈어와 출처의 지문으로 중복 제거되므로, 같은 체크의 재실행은 지지 하나입니다.
- 맵에 없는 체크. 체크 맵에 항목이 없는 attestation은 기록되지만
counted: false로 돌아옵니다. 증거는 보관되되 표는 없습니다. 이 체크가 이 주장을 대변한다고 미리 정한 사람이 없기 때문입니다.
프로젝트 오너는 혼자서 승격시킵니다
오너가 대시보드에서 candidate를 확인하면 그 한 번의 행위로 즉시 승격됩니다. 이는 K의 구멍이 아니라 의도된 예외이며, 감사 행에 override로 기록됩니다. 그래서 원장을 보면 그 항목이 신호가 쌓여서가 아니라 사람이 결정해서 승격됐다는 게 드러납니다.
이유는 K가 실제로 무엇을 위한 장치인지에 있습니다. K는 서명 키를 쥔 자동 시스템이 혼자 진실을 정하는 것을 막는 장치입니다. 프로젝트 오너는 K가 제약해야 할 대상이 아니라, 자기 프로젝트에서 무엇이 규범인지 정하는 권위 자체입니다. 오너의 결정이 효력을 갖기 전에 두 번째 이슈어를 요구하는 것은 안전을 더하는 게 아니라, 그 프로젝트가 자기 컨벤션을 선언하지 못하게 만드는 일입니다.
반박은 승격을 막습니다. 오너에게도 적용됩니다
조건 (b)는 두 갈래 양쪽에 걸립니다. 만료되지 않은 반박 하나가 있으면 지지가 아무리 쌓여도 승격되지 않고, 오너의 확인도 마찬가지입니다.
알려진 한계. 반박을 지우는 UI가 없습니다. 오래된 반박이 항목에 남아 있으면 오너가 확인 버튼을 눌러도 창이 만료될 때까지 아무 일도 일어나지 않습니다. 기본값으로 최대 30일이고, 버튼은 그 이유를 설명하지 않습니다.
이렇게 동작하는 이유: 사람이 살아 있는 반박을 덮어쓰고 확인할 수 있다면 강등이 무력해집니다. 반박된 것을 클릭 한 번으로 되돌릴 수 있게 되니까요. 창이 만료되기를 기다리는 것이 강등을 유효하게 유지하는 현재의 대가입니다.
강등 자체는 즉시 적용되고 candidate뿐 아니라 trusted에도 적용됩니다. 반박된 것을 recall이 계속 돌려주면 안 되기 때문입니다. promoted_at은 그대로 남습니다. 현재 상태가 아니라 이력이기 때문입니다.
수치
| 설정 | 기본값 | 프로젝트별 설정 |
|---|---|---|
| 승격에 필요한 서로 다른 이슈어 수 (K) | 2 | knowledgeConfig.kDistinctIssuers |
| 반박 창 | 30일 | knowledgeConfig.windowDays |
30일은 유도한 값이 아니라 고른 값입니다. 어떤 명세도 이 숫자를 정하지 않으며, 정의된 자리의 주석이 그렇게 밝히고 있습니다. 튜닝된 값이 아니라 출발점으로 보시면 됩니다.
규칙 네 개, 경계 하나
따로 만나면 사소한 제약 네 개처럼 보입니다. 실은 하나의 선입니다:
learn은 항상 candidate를 씁니다.- 스레드 자동 추출도 항상 candidate를 씁니다.
- reflection 제안을 승인해도 등록되는 것은 candidate입니다.
- 에이전트는 강등만 할 수 있고 승격은 못 합니다.
기계가 만들어낸 것은 전부 확인되지 않은 상태로 들어오고, 사람이나 독립적인 체크만이 그것을 건너편으로 옮깁니다. 이 중 하나만 빼도 "에이전트가 그렇게 말했다"에서 "모든 에이전트가 그렇게 듣는다"로 가는 길이 중간에 아무것도 없이 뚫립니다.
다음
- CI attestation - 체크를 이슈어로 연결하기.
- 지식 검토하기 - 승격의 오너 쪽 화면.