Lyotic · 기반 원칙

표현 계약 (EBSRC)

독립적으로 권위가 확립된 업무 상태를, 사람이 이해하고 개입할 수 있는 제한된 표현으로 변환합니다. 출력은 임의의 HTML이 아니라 Representation Plan입니다.

계약을 제한하는 세 가지 조건

이러한 후속 연구를 반영해 우리가 좁힌 연구 중심은 EBSRC, Evidence-Bound Supervisory Representation Contract다. 이는 독립적으로 권위가 확립된 위임 업무 상태를, 제한된 사람용 감독 표현으로 결정론적으로 변환하는 계약을 의미한다. 여기서 감독은 사용자가 모든 작업을 직접 감시한다는 뜻이 아니다. 업무를 맡긴 사람이 현재 상태를 이해하고, 중요한 순간에 개입하고, 개입 결과를 확인할 수 있다는 뜻이다.

"독립적으로 권위가 확립된 상태"라는 말도 정확하게 해석해야 한다. 에이전트가 자신의 답변에 "검증됨"이라고 적었다고 해서 검증된 입력이 되는 것은 아니다. 어떤 시스템이 어떤 사실에 대해 권위를 갖는지, 어떤 기록이 관찰되었는지, 어떤 승인 주체가 어떤 범위를 허용했는지가 애플리케이션의 계약에 의해 확립되어야 한다. 그렇다고 권위 있는 데이터가 현실을 완벽하게 반영한다는 뜻도 아니다. Lyotic은 출처의 권위, 정보의 정확성, 최신성, 해석의 적합성을 별개로 다룬다.

결정론적 변환은 모든 화면이 같은 모양이어야 한다는 뜻이 아니다. 같은 업무 상태, 같은 역할, 같은 정책 버전, 같은 표현 조건이 들어왔을 때 사실의 의미와 행동의 허용 범위가 임의로 달라져서는 안 된다는 뜻이다. 색상이나 레이아웃은 허용된 범위에서 달라질 수 있다. 그러나 모델이 바뀌었다는 이유로 미확정 결과가 완료로 바뀌거나, 읽기만 가능한 작업에 실행 버튼이 생겨서는 안 된다. 중요한 상태와 행동의 의미는 문장 생성의 우연성 밖에 놓여야 한다.

입력과 출력

이 계약의 입력에는 Work Case와 그 revision, 관련 Work Object, 현재 역할과 권한, Observation과 Evidence, 미해결 Claim, 제안된 행동, 영향 범위, 실행 기록, 검증 결과, 사용자가 현재 보고 있는 표현, 접근성 요구가 포함된다. 출력은 자유로운 HTML이 아니라 Representation Plan이다. Representation Plan은 무엇을 중심 객체로 보여줄지, 어떤 정보를 반드시 노출할지, 어떤 관계를 설명할지, 어떤 행동을 제공할지, 어떤 완료 표현을 금지할지, 다음 전환의 조건은 무엇인지를 결정한다. 렌더러는 그 계획을 실제 인터페이스로 표현한다.

EBSRCInput {
  case, objects, role, sources, observations, claims, interpretations,
  proposals, alternatives, decision, executions, verifications, preconditions,
  adapters, control, policy,
  view:   { mode, request },                 // what the person is looking at, and what they asked for
  access: { reducedMotion, screenReader, zoom, pointer }
}

RepresentationPlan {
  caseId, caseRevision, policyVersion, resolverVersion,
  mode, systemMode, work, focus,
  mustShow, relations, controls, forbidden,
  attention: { level, reason }, transitions, reason, announce
}

전환 이유도 기록합니다

Representation Resolver의 출력은 디자인 선택의 기록이기도 하다. 왜 이 Case가 Compact 상태에서 Compare 상태로 바뀌었는지, 왜 Authorization이 필요한지, 왜 완료 표현 대신 Recovery를 보여주는지 추적할 수 있어야 한다. 이 이유는 사람이 읽을 수 있는 짧은 설명으로도 표현될 수 있다. "새로운 기록이 도착했습니다"보다 "비교 중인 수량의 기준이 달라 매핑 검토가 필요합니다"가 해당 전환의 의미를 더 잘 설명한다. 표현 변화의 이유가 실제 상태 변화와 연결되어 있어야 한다.

표현을 선택하는 기준

Consequence-Proportional Disclosure는 위험이 높을수록 카드를 크게 만들라는 뜻이 아니다. 판단에 필요한 정보가 충분히 드러나야 한다는 뜻이다. 영향을 받는 객체, 유지되는 객체, 변경 범위, 회복 가능성, 외부 통지 여부, 대안, 검증 조건이 필요한 경우에는 이를 제공한다. 반대로 범위가 작고 되돌릴 수 있으며 위임된 권한 안에 있는 작업에 과도한 승인 절차를 붙이면, 중요한 순간의 주의까지 소모하게 된다.

Human judgment point는 에이전트가 막연히 자신 없다고 느끼는 순간만을 뜻하지 않는다. 새로운 해석이 행동의 의미를 바꾸거나, 해결되지 않은 증거 충돌이 남거나, 위임 범위를 넘거나, 되돌릴 수 없는 영향이 시작되거나, 복구에 사업적 판단이 필요한 순간이다. Lyotic은 이러한 조건을 표현으로 드러내야 한다. 사용자가 판단해야 하는 대상은 "AI를 믿겠습니까"가 아니라, 명시된 근거와 결과를 가진 구체적인 선택이어야 한다.

모델의 제안도 계약 안에서

따라서 Lyotic의 핵심은 "모델이 적절한 컴포넌트를 골라준다"는 기능보다 더 구체적이다. 현재 상태에서 허용되는 표현의 범위를 먼저 정하고, 그 안에서 필요한 표현을 선택하며, 그 표현이 근거와 권한의 의미를 보존하는지 검사한다. 모델은 해석과 제안을 도울 수 있지만, 그 제안은 검증 가능한 구조로 넘어와야 한다. 모델이 생성한 설명문이 계약을 우회해 성공이나 권한을 선언할 수 있어서는 안 된다.

입력이 달라도 같은 경계

입력은 타이핑에 한정되지 않는다. 스캔, 파일 첨부, 레코드 선택, 직접 수정, 외부 이벤트, 승인, 연결 복구, 다른 사람의 작업 인계가 모두 상태 변화를 만들 수 있다. Lyotic의 Resolver는 입력 방식 자체보다 그 이벤트가 업무 의미에 어떤 변화를 만들었는지를 본다. 같은 의미의 변경이라면 자연어 요청이든 직접 조작이든 동일한 정책과 검증 경계를 통과해야 한다.

사람과 에이전트의 읽기 방식

사람에게 보여주는 단계적 공개와 에이전트가 읽는 구조 사이에도 계약이 필요하다. 사람에게는 비교 세부 정보가 접혀 있어도, 현재 미해결 Claim이 있고 근거를 열어볼 수 있다는 사실은 의미 구조에서 사라지지 않아야 한다. 그러나 이것이 숨겨진 민감 정보를 DOM에 모두 넣어두라는 뜻은 아니다. 역할별 접근 권한을 유지하면서 현재 표현과 그 뒤의 업무 구조를 연결해야 한다. 사람과 에이전트에게 픽셀 단위로 같은 화면을 강제하기보다, 각각의 허용된 관찰 방식에서 모순 없는 의미를 제공하는 것이 목표다.