권한은 여전히 유효했지만, 출처가 변경되었습니다.

CLAIM-24 사전 등록 — Self-Correcting Systems 시리즈

Time-to-live (TTL) 권한에는 만료일이 있습니다. 시간이 다 되면 게이트(gate)가 차단됩니다.

하지만 권한은 시간이 다 되기 전에도 잘못될 수 있습니다.

타임스탬프(timestamp)가 아직 유효 범위 내에 있더라도, 권한을 정당화했던 출처(source)의 조건이 변경될 수 있습니다. 예를 들어 역할이 재배정되거나, 범위(scope)가 축소되거나, 수신자가 교체되는 경우입니다. 타임스탬프만을 기준으로 하는 만료 방식은 이를 잡아낼 수 없습니다. 게이트는 시계를 확인하여 유효하다고 판단하고, 오래된 권한(stale authority)에 기반한 동작을 허용하게 됩니다.

이것이 바로 CLAIM-24가 테스트하는 문제입니다.

재도출 게이트(re-derivation gate)의 역할

실행 시점에 게이트는 권한을 부여했던 출처의 현재 상태를 가져옵니다. 이때 출처는 에이전트(agent)가 쓸 수 없는 위치에서 가져와야 합니다. 게이트는 권한이 발행될 당시 기록된 내용과 현재 출처가 말하는 내용을 비교합니다.

두 내용이 일치하면: ALLOW. 두 내용이 일치하지 않으면: REFUSED_STALE.

'에이전트 쓰기 불가(agent-writable=false)' 제약 조건은 단순한 세부 사항이 아닙니다. 만약 게이트가 에이전트가 수정할 수 있는 출처로부터 읽어온다면, 재도출(re-derivation)은 한 단계 높은 수준의 자기 기술(self-description)에 불과하게 됩니다. 출처는 반드시 에이전트의 쓰기 관할권(write jurisdiction) 밖에 있어야 하며, 실행되는 순간에 가져와야 합니다.

게이트가 보는 것:

// 권한 발행 시점
{
  "grant_id": "g-4421",
...

권한의 시계는 47시간이 남았다고 말합니다. 하지만 출처는 역할이 이틀 전에 변경되었다고 말합니다.

7가지 사전 등록된 시나리오

실행 전 확정됩니다. 결과 확인 후에는 평가 기준을 수정할 수 없습니다.

1. TTL 유효 + 조건 변경 없음 → ALLOW
2. TTL 만료 → BLOCK
3. TTL 유효 + 조건 변경됨 → REFUSED_STALE
4. 출처 도달 불가 → REFUSED_UNREACHABLE
5. 권한 없음 → BLOCK
6. 수신자 변경됨 → REFUSED_STALE
7. 범위 축소됨 → REFUSED_STALE

시나리오 3이 이 클레임(claim)의 핵심입니다. 만약 시나리오 3에서 게이트가 ALLOW를 반환한다면, 해당 아키텍처는 실패한 것입니다. TTL이 유효하고 출처가 변경된 동작을 허용하는 게이트는 Staleness 게이트가 아니라, 단순히 단계가 추가된 Expiry 게이트일 뿐입니다.

실행 전 고정된 두 가지 제약 조건

제약 조건 1: refused_stale와 refused_unreachable은 별도의 결과 셀(result cells)이어야 합니다.

만약 출처(source)에 접근할 수 없어 게이트(gate)가 refused_stale을 반환한다면, 이는 Staleness(신선도 저하)를 감지한 것이 아니라 부재(absence)를 감지한 것입니다. 문제는 서로 다르며, 해결책도 다릅니다. 이 둘을 혼동하면 Staleness 셀에서 거짓 양성(false positives)이 발생합니다.

제약 조건 2: condition_delta는 파생된 레이블(derived label)이 아닌 가공되지 않은(raw) 전/후 값을 저장해야 합니다.

stale: true가 아닙니다. 가공되지 않은 전/후 값이어야 합니다. 파생된 레이블은 결론이지 증거가 아닙니다. 이는 해당 레이블을 작성한 게이트와 독립적으로 감사(audit)될 수 없습니다.

두 제약 조건은 어떤 시나리오를 실행하기 전, 외부 아키텍처 리뷰(architectural review)에 대응하여 추가되었습니다.

우리가 기다리고 있는 것

패킷(packet)은 내부적으로 작성된 데이터에 대해서는 실행될 수 없습니다. 자신이 작성했을 수도 있는 출처를 확인하는 에이전트(agent)는 추가적인 지연 시간(latency)을 동반하여 자기 자신을 다시 읽는 것에 불과하기 때문입니다.

Ken W Alger의 Local Brain 아키텍처가 이 테스트를 위한 첫 번째 외부 출처 후보입니다. 만약 포스트와 코드가 출처(provenance), 소유권(ownership), 그리고 에이전트 쓰기 불가(agent-writable=false) 경계가 있는 소스 레이어(source layer)를 노출한다면, 우리는 이를 대상으로 CLAIM-24를 실행할 것입니다. 그렇지 않다면, 다른 출처를 기다릴 것입니다.

이것이 증명하지 않는 것

만약 시나리오 3이 refused_stale을 반환하고 7개의 모든 시나리오가 예상된 결과를 반환한다면, 그것이 증명하는 바는 다음과 같습니다:

재도출 게이트(re-derivation gate)가 하나의 외부 출처를 대상으로 한 7개 시나리오 패킷에서, TTL 유효 + 출처 변경(source-changed) 케이스를 정확하게 식별했다는 점입니다.

대규모(at scale)로 증명된 것이 아닙니다. 다양한 출처 유형(source types)에 걸쳐 증명된 것도 아닙니다. 적대적인 권한 변조(adversarial grant tampering)에 대해 증명된 것도 아닙니다. 만약 Ken W Alger의 방식이 더 단순한 메커니즘을 통해 동일한 문제를 해결한다면, 이 게이트가 유일한 해결책은 아니라고 명시할 것입니다.

발산 셀(divergence cell)이 테스트의 핵심입니다. 만약 이 셀이 ALLOW를 반환한다면, 우리는 실패를 발표할 것입니다.

직접 실행해 보세요

만약 에이전트가 쓸 수 없는 출처 경계 (provenance boundary)를 가진 메모리 저장소 (memory store)를 보유하고 있다면, 지금 바로 이 패킷 (packet)을 대상으로 실행해 볼 수 있습니다. 7가지 시나리오와 평가 기준은 위에 설명되어 있습니다. 시나리오 3에서 얻은 결과가 무엇인지 답장해 주세요. 이 시나리오 3의 셀 (cell)이 이 전체 클레임 (claim)의 성패를 결정합니다.

*이 시리즈의 이전 내용: CLAIM-23 (도구 호출 허가 게이트 (tool-call grant gate), 7/7, 0개의 거짓 확신 오류 (false-certainty errors)). CLAIM-15B (거버넌스 조정 스코어러 (governance-adjusted scorer)가 홀드아웃 패킷 (held-out packet)에서 실패 — BM25가 이를 능가함). 전체 클레임 원장 (claim ledger): https://github.com/keniel13-ui/memory-authority-auditor