Lyotic · 기반 원칙

의미 모델

업무, 대상, 관찰, 주장, 권한, 효과를 각각의 책임을 가진 객체로 구분합니다. 하나의 AI 메시지로 합치면 의존 관계와 미해결 의무를 잃을 수 있습니다.

업무의 단위는 Work Case입니다

이 구조의 기반은 Work Case, Work Object, Context Snapshot의 구분이다. Work Case는 지속되는 하나의 업무다. 목표, 범위, 책임자, 생명주기, 결정 이력, 실행 이력, 증거 관계, 미해결 질문을 가진다. Work Object는 그 업무가 다루는 대상이다. 상품, 주문, 송장, 문서, 저장소, Pull Request 같은 도메인 객체가 여기에 해당한다. 하나의 Work Case는 여러 Work Object를 포함할 수 있다. Context Snapshot은 특정 시점에 특정 사람이나 에이전트가 볼 수 있도록 선택된 관련 정보의 투영이다. Snapshot이 작아지거나 세션이 사라져도 Work Case의 이력까지 사라져서는 안 된다.

Work Case의 정체성을 유지한다는 것은 처음 정한 목표를 영원히 고정한다는 뜻은 아니다. 목표와 범위는 바뀔 수 있다. 다만 무엇이 언제 왜 바뀌었는지가 기록되고, 그 변경으로 기존 결정과 승인이 계속 유효한지 다시 판단할 수 있어야 한다. 완전히 다른 업무로 전환되면 기존 Case를 억지로 재사용하기보다 새로운 Case와의 관계를 명시하는 편이 맞을 수 있다. 보존의 대상은 ID 문자열 자체보다 업무의 연속성과 변경 이력이다.

열여덟 가지 객체

객체의미
WorkCase목표·범위·담당자·revision을 가진 지속되는 업무
WorkObject각 시스템에서 서로 다르게 표현되는 업무 대상
ContextSnapshot특정 시점과 역할에 허용된 업무의 투영
Source관찰의 출처와 어떤 사실에 권위가 있는지
Observation특정 시점에 출처가 보고한 필드·값·최신성
Evidence관찰과 주장 사이의 지지·반박·불충분 관계
Claim인식 상태와 근거를 가진 검토 가능한 명제
Interpretation전제와 불확실성에 따른 의미 해석
Recommendation근거와 대안을 갖춘 다음 행동의 추천
Decision누가 어떤 기준으로 무엇을 선택하고 한계를 수용했는지
ProposedAction대상·변경·보존·위험·버전을 가진 아직 미실행인 변경 의도
Authorization누가 어떤 버전·범위·조건을 허용했는지
Execution대상별로 실제 수행한 작업
Effect실행 이후 관찰된 변화
Verification기대 조건과 관찰 결과의 범위 있는 비교
Recovery불확실성 이후 재조정·재시도·보상·전달 경로
OpenLoop담당자와 의존 관계가 있는 미해결 질문·의무
Handoff다음 담당자가 이어받을 업무 상태 묶음

Observation은 특정 출처에서 특정 시점에 무엇이 관찰되었는지를 나타낸다. ERP 응답에 5,400이라는 수치가 있었다는 것은 Observation이다. 그 수치가 현재 판매 가능한 재고라는 결론은 별도의 Claim이다. Source는 관찰의 출처를 나타내고, Evidence는 특정 Claim을 지지하거나 반박하는 자료의 역할을 한다. 같은 API 응답이 한 Claim을 지지하면서 다른 Claim에는 불충분할 수 있다. Evidence는 파일이나 링크의 존재 자체가 아니라, 주장과의 관계를 가진다.

Claim은 검토 가능한 명제다. "이 네 레코드는 동일한 물리적 품목과 관련된다"와 "이 네 숫자는 직접 비교 가능한 동일한 수량 개념이다"는 서로 다른 Claim이다. 앞의 주장이 참이어도 뒤의 주장은 거짓일 수 있다. Interpretation은 관찰과 Claim에 의미를 부여한 해석이며, Recommendation은 앞으로 무엇을 할지에 관한 제안이다. Decision은 가능한 대안 중 실제로 선택한 판단이다. 이 구분이 있어야 어떤 부분을 사람이 수정했을 때 무엇이 무효화되는지 알 수 있다.

Decision에는 선택된 대안뿐 아니라 판단 기준, 결정 주체, 사용한 근거, 감수한 한계가 연결되어야 한다. 이 기록은 에이전트의 내부 사고 과정을 노출하는 것이 아니다. 제품 차원에서 책임 있게 남겨야 하는 결정의 근거다. 나중에 모델이 그럴듯한 이유를 새로 작성한 것과 당시 실제로 기록된 결정 이유도 구분해야 한다. 이유를 생성할 수 있다는 사실은 그 이유가 실제 결정을 지배했다는 증거가 아니다.

Proposed Action은 아직 실행되지 않은 변경 의도다. Authorization은 그 행동을 누가 어떤 범위와 조건에서 허용했는지 나타낸다. Execution은 실제 수행된 개별 작업이며, Effect는 그 작업 이후 관찰된 변화다. Verification은 사전에 정한 기대 결과와 실제 관찰 결과를 비교하는 작업이다. Recovery는 실패나 불확실성 이후의 정리 절차이고, Open Loop는 아직 해결되지 않은 질문이나 의무이며, Handoff는 업무를 다른 참여자에게 넘길 때 필요한 상태 묶음이다. 이 객체들은 하나의 "AI 메시지" 안으로 사라져서는 안 된다.

같음 대신 관계의 종류

Work Object의 관계도 단순한 동일성으로 환원하면 안 된다. 두 이름이 같은 상품의 별칭일 수도 있지만, 같은 부품을 사용하는 서로 다른 상품일 수도 있다. 한 상자와 낱개 열 개처럼 단위 변환이 필요한 관계일 수도 있다. Lyotic은 "같다"는 하나의 표시 대신 alias, packaging relationship, shared component, inventory pool 같은 도메인 관계를 표현할 수 있어야 한다. 잘못된 동일성 주장은 이후의 모든 비교와 자동화에 영향을 주기 때문이다.

의존 관계에 따른 재평가

이 객체들 사이에는 의존 관계가 필요하다. Claim은 Evidence에 의존하고, Decision은 특정 Claim과 기준에 의존하며, Action은 Decision과 Authorization에 의존한다. 새로운 관찰로 중요한 Claim이 흔들리면 그 Claim을 바탕으로 한 Recommendation과 아직 실행되지 않은 Action도 다시 평가해야 한다. 그렇다고 모든 변화가 모든 결정을 무효화하는 것은 아니다. 글꼴 변경이나 무관한 필드 수정 때문에 승인 전체를 다시 받게 해서는 안 된다. 어떤 의존성이 실제 의미와 권한을 바꾸는지 구분하는 것이 필요하다.

보존에도 범위가 있습니다

Work Case의 지속성은 무제한 저장을 의미하지 않는다. 개인 정보와 민감한 자료에는 접근과 보존 범위가 필요하고, 역할에 따라 다른 Snapshot을 제공해야 한다. 특정 증거가 삭제되거나 접근 불가능해졌다면 그 자료에 의존하던 현재 주장도 다시 평가해야 한다. 과거에 검증했다는 기록과 지금 그 근거를 재확인할 수 있다는 상태는 구분된다. 지속되는 업무의 의미를 보존하면서도 데이터 접근과 보존 의무를 지켜야 한다.