모델이 개념 페이지를 작성하기 전에 미등록 사실을 차단하는 방법

개념 페이지가 정확성을 유지하려면 모델이 산문을 작성하기 전에 인간의 주장 등록(claim register)이 존재해야 합니다. 모델은 승인된 주장을 연결할 수는 있지만, 행동, 한계 또는 지원 사실을 임의로 만들어낼 수는 없습니다. 이 등록부가 유일한 진실의 원천으로 남아 있는 동안, 초안 페이지는 단지 설명 계층(explanation layer) 역할을 수행합니다. 작은 검사기(checker)가 위험 표시자(risk marker), 잘못된 인용(bad citation) 또는 추가 제목이 해당 등록부를 벗어날 때 페이지를 실패 처리해야 합니다.

개념 페이지가 참조 페이지보다 더 빨리 변하는 이유

참조 페이지는 이미 별도의 검토 게이트를 거친 서명, 스키마 및 캡처된 명령(captured commands)과 비교하여 확인할 수 있습니다. 반면, 개념 페이지에는 그러한 기준점(anchor)이 부족하기 때문에 모델은 소유자가 검토하지 않은 그럴듯한 아키텍처로 공백을 채웁니다. 독자들은 이후에 매끄러운 산문을 증거로 취급하며, 심지어 근본적인 시스템이 설명된 경로를 결코 구현하지 않았더라도 말입니다. 문제는 스타일적인 것이 아니라, 나중에 페이지들이 복사해 가는 소유되지 않은 사실적 주장(unowned factual claim)이기 때문입니다.

효용성 있는 대응책은 모델에게 문서를 작성하는 것을 전면적으로 금지하기보다는 더 좁은 범위여야 합니다. 팀들은 여전히 읽기 쉬운 전환, 청중 설정(audience framing), 그리고 소유자가 이미 결정한 행동에 대한 짧은 설명이 필요합니다. 그러한 문장들은 각 사실적 절(factual clause)이 인간이 이미 수락한 주소를 가리킬 때만 안전합니다. 이러한 포인터가 없으면, 검토는 새로운 식별자들을 확인하는 것이 아니라 전체 페이지를 다시 읽어보는 작업이 됩니다.

초안 작성이 시작되기 전에 인간이 소유해야 할 것들

인간 소유자는 페이지 옆에 주장 등록부를 게시하고, 모델은 제안으로 받는 대신 그 파일을 입력으로 받습니다. 각 주장은 식별자(identifier), 하나의 진술(statement), 출처 경로(source path), 종류(kind) 및 검토가 질의할 수 있는 상태(status)를 가집니다. 진술은 인용하기에 충분히 짧고, 산문이 두 번째 숨겨진 사실을 필요로 하지 않을 만큼 충분히 광범위해야 합니다. 상태 값은 '활성(active)', '폐기됨(retired)', '초안(draft)'으로 제한되며, 초안 주장은 공개 페이지에서 차단됩니다.

같은 소유자가 초안 작성 모델이 스스로 확장하는 경향이 있는 세 개의 보조 목록도 동결합니다. 개요(outline)는 페이지가 사용할 수 있는 제목들을 순서대로 나열하며, 추가 섹션은 허용되지 않습니다. 금지 목록(forbidden list)은 등록소에 포함되어 있지 않은 보장, 할당량 또는 지원 약속을 암시하는 단어들을 명시합니다. 비목표 노트(non-goal note)는 절차, 변경 로그 및 문제 해결 단계가 다른 소유된 아티팩트에 존재한다고 명시합니다.

숫자, 기간, 버전 범위 및 고객에게 보이는 제한 사항은 모델의 산문 내부가 아닌 클레임 진술(claim statements) 내부에 유지됩니다. 검토자가 열어볼 수 있는 출처 경로(source path)를 갖지 못한 클레임은 등록소에 포함되지 않습니다. 이미 등록소에 없는 제품 이름은 비교 조항(comparison clause)에만 나타나더라도 새로운 클레임으로 처리됩니다.

모델이 작성할 수 있는 것, 그리고 그것뿐

모델은 클레임 진술을 반복하고 고정 토큰에 식별자(identifier)를 첨부하는 안내 문장(orientation sentences)을 작성할 수 있습니다. 전환이 새로운 동작을 도입하지 않을 때 두 인용된 클레임 사이에 전환(transition)을 추가할 수 있습니다. 모델은 비유가 위험 표시기(risk marker)나 금지 단어를 포함하지 않는 경우에만 짧은 유추(analogy)를 작성할 수 있습니다. 검사기가 수사적 의도(rhetorical intent)를 점수화하지 않기 때문에, 독자들은 여전히 명시적인 비유 레이블을 봐야 합니다.

모델은 제목을 추가하거나, 개요 순서를 재배열하거나, 상태가 활성(active)이 아닌 클레임들을 인용할 수 없습니다. 예제(Examples), 요청 본문(request bodies) 및 예상 출력(expected outputs)은 여전히 인간 소유이기 때문에 그대로 유지됩니다. 유창한 예제는 여전히 동작 클레임(behavior claim)입니다. 모델은 등록소에 이미 나열된 식별자를 통해서만 예제를 참조할 수 있습니다. 예제 파일에 포함되어 있지 않은 샘플 값, 상태 코드 또는 필드 이름을 임의로 만들 수 없습니다.

해당 분리는 초안 페이지가 두 번째 경쟁 사양서가 되는 것을 막으면서도 설명을 읽기 쉽게 유지합니다. 아래 매트릭스는 이 페이지 유형의 작동 규칙이며, 체커는 가장 오른쪽 열만 구현합니다. 'Human must own'으로 표시된 행은 모델이 채울 수 있는 빈칸이 아니라 프롬프트의 입력값입니다. 한 행과 유창한 초안 사이에 충돌이 발생하면, 해당 행을 수정하는 것이 아니라 초안 자체를 거부함으로써 해결됩니다.

| 요소 | 인간 소유 필수 | 모델 초안 가능 | 펜스 결과 |
| :--- | :--- | :--- |
| 주장 진술 및 출처 | 예 | 활성 ID와 함께 인용하기 | 알 수 없는 ID 실패 |
| ... |

측정된 벤치마크가 아닌 제안된 펜스

아래 체커를 저장소 스크립트로 저장하고, 이것을 측정된 제품이 아니라 제안된 필터로 취급하십시오. 첫 번째 펜스를 위해 다섯 가지 실패 클래스만으로 충분합니다: 잘못된 인용(bad citations), 사용되지 않은 주장(unused claims), 추가 제목(extra headings), 거부 목록 히트(deny-list hits), 그리고 출처가 없는 위험 표시자(uncited risk markers). 위험 표시자는 숫자, 버전 형태의 토큰, 또는 must, always, never와 같은 양식어(modal)입니다. 두 서브커맨드를 실행하기 전에 펜스에 사용할 동일한 인터프리터에 PyYAML을 설치하십시오.

python3 -m pip install --user PyYAML

#!/usr/bin/env python3
"""제안된 주장 펜스. 실행되지 않은 예시이며, 측정된 실행이 아닙니다.
주장의 내용을 왜곡하는 인용된 문장을 감지하지 못합니다.
...

다섯 단계의 워크플로우

순서대로 단계를 따르고, 모델 세션에서 수동으로 산문을 패치하기보다는 단계가 실패할 때 멈추십시오. 아래 명령어들은 측정된 실행 기록이 아니라 제안된 로컬 워크플로우를 설명합니다. 각 샘플 경로를 이미 사용하는 실제 문서화 도구 체인의 저장소 레이아웃으로 대체하십시오.

1. 주장 레지스터 고정하기

개념 페이지를 작성하기 전에 미등록 사실을 차단하는 방법

클레임 등록 파일(claim register file)을 생성하고, 본문(prose)과 동일한 풀 리퀘스트(pull request)에서 모든 진술 변경 사항을 검토해야 합니다. 각 파일당 하나의 페이지 식별자(page identifier)를 유지하여 초안이 인접한 개념의 클레임을 가져다 쓰지 못하게 해야 합니다. 검토 날짜는 모델이 임의로 업데이트할 수 있는 문장이 아니라 데이터로 기록합니다. 샘플 날짜와 소스 경로를 팀이 이 검토를 완료했다는 증거가 아닌, 일러스트레이션으로 취급해야 합니다.

page_id: concept.session-lifecycle
owner: docs-platform
reviewed_on: 2026-10-12
...

2. 개요를 유일한 제목 출처로 고정하기 (Freeze the outline as the only heading source)

작성자에게 개요에서 제목을 복사하도록 요청하고, 다른 어떤 제목 레벨도 거부하도록 해야 합니다. 제목은 범위에 대한 클레임이므로, 추가적인 제목은 검토가 승인하지 않은 소유되지 않은 주제입니다. 이 규칙을 등록 파일 옆에 위치한 프롬프트 파일에 저장하고, 모든 실행 시 두 파일을 함께 전달해야 합니다. 등록 파일을 export 하위 명령어(subcommand)로 전달하고, 생성된 프롬프트를 검토를 위해 등록 파일 옆에 보관합니다.

python3 scripts/claim_fence.py export \
  docs/claims/session-lifecycle.yaml \
  /tmp/concept-prompt.md

이 내보내기 도구(exporter)는 검토를 계속해야 하며, 개요, 활성 클레임 진술, 그리고 금지된 단어들을 출력합니다. 등록 파일이 너무 빈약하여 게시할 수 없을 때 모델에게 누락된 클레임을 지어내라고 요구하지 않습니다. 빈약한 등록 파일이란 페이지가 준비되지 않았다는 의미이지, 모델이 그것을 완성해야 한다는 의미는 아닙니다.

3. 등록 파일만으로 설명 레이어 초안 작성하기 (Draft the explanation layer from the register alone)

내보낸 프롬프트를 초안 작성 모델(drafting model)에 보내고, 모든 사실적 문장이 등록 파일의 클레임 토큰을 포함하도록 요구해야 합니다. 모델에게 고정된 제목을 사용하고 마크다운만 반환하며, 필요한 클레임이 없을 경우 TODO를 남기도록 지시합니다. 생산 로그(production logs), 고객 이름 또는 미출판 제한 사항을 그 초안 작성 프롬프트에 절대 붙여넣지 않습니다.

## What a session is

A session record는 로그인 성공 후에만 기록됩니다 {{claim:session.created_on_login}}.
...

샘플은 의도적으로 평범하게 유지되는데, 색상이나 강조가 실제 검토 대상이 아니기 때문이다. 실제 검토 대상은 각 사실적 문장이 정확히 하나의 활성 주장(active claim)에 깔끔하게 매핑되는지 여부이다. 만약 모델이 토큰 없이 의심스러운 문장을 반환한다면, 톤 검토를 시작하기 전에 체커가 해당 파일을 거부해야 한다. TODO는 인간 소유자에게 보내는 정지 신호이며, 두 번째 비지정된 검토 기회를 의미하는 초대장이 아니다.

4. 누구나 편집하기 전에 방어벽(fence) 실행하기

전체 초안에 대해 check 하위 명령어를 실행하고, 0이 아닌 종료 코드는 톤 문제가 아니라 차단된 검토로 간주해야 한다. 사용되지 않은 활성 주장 또한 실패를 의미하는데, 이는 누락된 주장이 소유자가 이미 설명하겠다고 약속한 행동을 숨기기 때문이다. 금지 단어는 비유(analogies) 내부에서도 실패한다. 독자들은 보증 주변에 붙은 라벨을 거의 알아차리지 못하기 때문이다. 다음 부정 검사는 제안된 테스트이며, 올바른 방어벽은 인용되지 않은 숫자와 사용되지 않은 주장에 대해 0이 아닌 종료 코드를 반환한다.

python3 scripts/claim_fence.py check \
  docs/claims/session-lifecycle.yaml \
  docs/drafts/session-lifecycle.md

printf '## What a session is\n\nSessions last 30 minutes.\n' > /tmp/bad-concept.md
python3 scripts/claim_fence.py check \
  docs/claims/session-lifecycle.yaml \
...

5. 주장 식별자(claim identifier)별로 diff를 검토한 후, 산문 수락하기

등록된 diff와 초안 diff가 하나의 검토 보기에서 보이도록 풀 리퀘스트(pull request)를 연다. 인용된 식별자가 안정적으로 유지되고 체커가 녹색불일 때만 문구 변경을 수락한다. 만약 문장에 새로운 사실이 필요하다면, 주장을 추가하고 출처를 명시하며, 단락을 재생성하기 전에 인간의 검토를 받아야 한다. 모델이 산문을 편집하는 것과 같은 차례에 등록 파일(register file)을 편집하도록 두지 마라.

무료 초안 작성 및 서버 배포가 적합한 곳

펜스(fence)는 평범한 Python 코드이므로 어려운 부분은 레지스터 검토를 산문 통과와 분리하는 것입니다. 공개합니다: 이 문서는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다. MonkeyCode의 무료 모델을 사용하면 설명 계층을 초안 작성할 수 있으며, 무료 서버는 깨끗한 체크아웃에서 검사기(checker)를 실행합니다. 그러면 검토자들이 스크립트를 담고 있는 노트북에 의존하는 대신 하나의 명령어를 공유할 수 있습니다.

이 두 가지 옵션은 가용성 주장일 뿐이며, 이 페이지는 모델 이름, 할당량, 하드웨어 또는 각 옵션이 얼마나 오래 유지되는지에 대해 명시하지 않습니다. 호스팅된 실행이 불편하다면, 동일한 스크립트는 여전히 저장소에 속하며 로컬 인터프리터에서 통과해야 합니다. 이미 주장 레지스터가 존재한다면, 새로운 로컬 설정 없이도 이 분할을 시도하기에 충분합니다.

눈에 띄게 유지되어야 할 제한 사항들

검사기는 의미를 이해하지 못하며, 인용된 문장은 여전히 그것이 명명하는 주장을 왜곡할 수 있습니다. 인간은 여전히 각 인용된 문장을 그 진술 및 출처 경로와 대조하여 읽어야 합니다. 패턴 목록은 일반적인 팀이나 이름 없는 통합과 같은 부드러운 발명을 놓치므로, 소유자는 자신의 도메인에 대한 의심스러운 목록을 확장해야 합니다. 샘플 날짜, 경로 및 진술은 관찰이 아니라 예시입니다.

헤딩 잠금(Heading locks)은 모델이 일반적인 설명 단락 안에 절차를 밀반입하는 것을 막지 못합니다. 페이지가 명령어를 필요로 한다면, 이 레지스터를 확장하기보다는 소유된 명령어 매트릭스를 가리키십시오. 폐기된 주장(Retired claims)은 그것들을 폐기하는 변경 사항과 함께 초안에서 제거되어야 하며, 그렇지 않으면 사용되지 않은 주장에 대한 규칙이 독자의 기록과 일치하지 않을 것입니다. 법률, 보안 또는 청구 언어를 포함하는 페이지는 이 펜스를 유일한 제어 수단으로 의존해서는 안 됩니다.

누가 이 분할을 건너뛰어야 하는가

등록 주체(owner)를 지정하고 소스 경로를 열 수 있는 사람이 아직 없는 경우 워크플로우 단계를 건너뛰세요. 모델은 해당 주체를 임명할 수 없으며, 녹색 체크 표시가 누락된 인간의 검토를 대체할 수는 없습니다. 이미 산문(prose)을 추출된 시그니처에 연결하는 API 참조의 경우에도 이 단계를 건너뛰세요. 왜냐하면 두 번째 등록 과정은 생성기(generator)와 달라지기 때문입니다. 페이지가 사실적 주장이 없는 서사(narrative)인 경우에는도 건너뛰는 것이 좋습니다. 그 이유는 펜스(fence, 검증 장치)가 거짓된 정밀성을 암시하는 토큰만 추가할 것이기 때문입니다.

개념 페이지를 지원 답변이나 릴리스 노트에 복사하여 붙여넣을 때, 그리고 이러한 복사본이 검토 과정 사이에 행동을 계속해서 지어내는 경우 분리(split) 기능을 사용하세요. 그러면 등록 과정은 공유 인용 계층(shared citation layer)이 되고, 모델은 두 번째 설계자라기보다는 연결의 초안 작성자로 남게 됩니다. 체크 장치는 버전 관리 시스템에 보관하고, 다른 모든 테스트를 검토하는 방식과 동일하게 그 패턴을 검토하세요. 해당 패턴을 확장하는 것은 diff에서 지적할 수 있는 거짓된 승인(false acceptance)이 있은 후에만 하세요.