← Docs hub

Experience Catalog, Evidence, and Bounded Replan

핵심 질문
복합명령을 잘게 나누는 수준을 넘어, 기기가 목표를 유지하고 관찰 결과를 바탕으로 다음 방법을 스스로 찾게 하려면 무엇이 필요한가?

이 문서는 Experience Goal을 명령 확장기가 아니라 목표-효과-증거 기반의 제한된 문제 해결 loop로 정의한다. LLM이 임의 기능을 발명하는 구조가 아니다. Planner가 의미와 순서를 구성하고, Capability Catalog가 가능한 수단을 제한하며, TaskManager와 DeviceAgent callback이 실제 결과를 증명한다.

사용자 목표
  -> canonical desired effects
  -> catalog provider 선택
  -> typed action / dependency 계획
  -> TaskManager 실행
  -> terminal evidence 관찰
  -> 달성: 완료
  -> 미달: 미방문 provider 또는 복구 방법을 budget 안에서 재계획
  -> 수단 소진·정책 차단: 사용자 질문 또는 안전 종료

1. 이번 안정화에서 바뀐 경계

1.1 Effect는 자유 문자열이 아니다

Goal grounding과 temporal review가 반환할 수 있는 effect ID는 현재 turn에 제공한 카탈로그 후보로 제한된다. 자연어로 설명해야 하는 미지원 결과는 별도 unsupported_terminal_outcomes에 둔다.

이 분리는 다음 오류를 막는다.

• LLM이 그럴듯한 effect ID를 새로 만들어 실행 가능하다고 오인
• 이미 지원되는 action을 effect 이름이 다르다는 이유로 차단
• 완료 증거가 없는 device step을 goal 달성으로 계산

1.2 명시된 복합명령은 Experience가 지우지 않는다

사용자가 지정한 action instance와 순서는 기존 Planner 계약이 소유한다. Experience는 각 action에 canonical effect와 terminal evidence를 결속하지만, 최소 effect cover를 만든다는 이유로 원래 action을 삭제하거나 재배열하지 않는다.

사용자: 바이탈사인을 열고 밝기를 2단계, 볼륨을 3단계로 바꿔줘

보존되는 action order
  1. vital_signs.start
  2. screen_brightness.level 2
  3. sound_setting.level 3

1.3 현재 상태는 guard이지 자동 실행 step이 아니다

배터리가 충분하면 ...의 현재 배터리 값은 조건 판정 근거다. Planner가 별도 조회가 필요하다고 판단한 경우가 아니라면 battery_status.check라는 실행 step으로 승격하지 않는다. 이 구분이 없으면 조건 확인이 원래 action 앞에 삽입되고 순서 검증과 비용이 불필요하게 증가한다.

1.4 Terminal semantics의 권위는 Catalog에 있다

바이탈사인 start의 성공 기준은 “화면을 열었다”가 아니라 사용자가 완료 또는 취소해 app.sessionEnded가 관찰되는 것이다. temporal LLM은 시간 관계를 판단할 수 있지만, 카탈로그가 명시한 이 terminal semantics를 문구 차이만으로 미지원 처리할 수 없다.

1.5 조건 가드는 실패 시 한 번만 구조적으로 복구한다

조건 predicate는 현재 값에서 문자열을 복사하지 않는다. LLM은 허용된 state path와 operator schema 안에서 조건을 grounding한다. 첫 응답이 schema를 만족하지 않으면 현재 상태값을 다시 주입하지 않고, 이전 조건과 validation feedback만 전달해 한 번 더 복구한다. 두 번째도 실패하면 실행하지 않는다.

의미 판단 -> condition schema 검증
  -> valid: typed condition으로 컴파일
  -> invalid: 오류 필드만 제공해 1회 복구
  -> invalid again: fail-closed

1.6 조건이 거짓이면 초기 dispatch도 생성하지 않는다

이전에는 실행기가 조건 불충족을 blocked로 판정한 뒤에도 cloud-resumable request builder가 원래 step을 다시 device request로 만들 수 있었다. 이제 route result가 blocked, failed, needs_user_input, waiting_user, cancelled인 step ID는 초기 dispatch 후보에서 제외한다. 조건 판정과 실제 dispatch가 동일한 상태 권위를 사용한다.

2. 스스로 답을 찾는 loop

2.1 Observe

Supervisor는 raw sensor sample마다 LLM을 호출하지 않는다. 다음처럼 목표 판정에 의미가 있는 event만 축약해 읽는다.

• terminal evidence 도착 또는 누락
• FAILED, BLOCKED, TIMEOUT, NEEDS_USER_INPUT
• 조건 분기를 결정하는 typed step output
• 사용자 취소·수정·새 목표
• context freshness 또는 policy가 계획 유효성에 영향을 주는 변경

2.2 Decide

결정 후보는 catalog와 budget으로 제한된다.

continue | wait | ask_user | retry_local | replan | complete | cancel

정상 QUEUED, RUNNING, PROGRESS는 telemetry만 갱신한다. Cloud replan은 성공 증거가 부족하거나 다음 수단을 고르는 의미 판단이 필요할 때만 허용한다.

2.3 Act

Planner가 선택할 수 있는 것은 Capability Catalog에 선언된 capability, operation, argument, provider뿐이다. typed action으로 컴파일되지 않거나 terminal evidence가 없는 device action은 fail-closed 된다.

2.4 Verify and Replan

관찰 결과가 목표를 만족하지 않으면 이미 시도한 provider와 후보를 state에 남긴다. 재계획은 미방문 후보를 우선하고, 같은 실패를 무한 반복하지 않는다.

station probe negative
  -> 현재 후보를 attempted로 기록
  -> 등록 공간 중 미방문 후보 선택
  -> 이동 -> 다시 probe
  -> positive면 returnToStation
  -> 후보 또는 replan budget 소진 시 사용자 안내 후 종료

현재 기본 decision budget은 최대 3회 수준으로 제한하며, 정상 event에는 소비하지 않는다. 카탈로그 밖 capability, 허용되지 않은 result field, budget을 넘는 replan은 거부한다.

2.5 MR6의 탐색 도구도 같은 loop에 편입한다

MR6 현재 소스에는 60개 TaskManager method, 11개 executor 객체, 14개 Planning Context bundle이 있다. 그중 아래 네 도구는 “스스로 답을 찾는 과정”의 기반이다.

Planner는 “스테이션”이라는 단어를 보고 정해진 매크로를 실행하지 않는다. 목표에 필요한 효과와 현재 증거를 비교해 catalog provider를 선택한다. 예를 들어 현재 위치에서 도킹 증거가 없으면 미방문 후보로 이동하거나 회전 후 다시 관찰할 수 있다. 반대로 후보가 소진되거나 신뢰도가 낮으면 임의 좌표를 만들지 않고 사용자 확인으로 전환한다.

goal: station located and safely reachable
  -> current station/location context 검토
  -> passive docking probe
  -> negative: unvisited candidate 선택
  -> move or stationary rotate
  -> semantic/docking evidence 재관찰
  -> positive: return provider 실행
  -> exhausted/unsafe: ask_user 또는 safe stop

이 네 도구는 MR6 코드·공개 인벤토리 정합 테스트까지 통과했다. 다만 platform-signed APK에서 실제 이동·회전·관찰·복귀가 한 trace로 끝나는 physical E2E는 별도 승인 항목이다. 상세 원장은 DeviceAgent Agentic I/O Coverage Matrix를 기준으로 한다.

3. LLM과 결정론 영역

이 구조는 룰 기반 발화 매칭과 다르다. 문장별 if문은 없고, 의미 판단 결과가 실행 가능한 계약으로 내려갈 수 있는지를 일반화된 schema와 state machine이 검증한다.

4. 2026-08-09 검증 결과

4.1 코드 회귀

• 영향 범위 집중 회귀: 385 passed, 21 subtests passed
• 백엔드 전체 회귀: 1,003 passed, 49 skipped, 285 subtests passed
• adaptive replan 핵심: 6 passed
• 검증 항목: 미방문 후보 선택, result-dependent resume, budget exhaustion, invented capability 거부, incomplete terminal evidence false success 방지

4.2 60문항 live-policy 기준선

Artifact: a2a_planner_taskmanager_non_motion_60_20260809-r21-live-policy.json

r21은 request error가 0이고, r19 대비 호출 수 5.36%, 평균 token 11.16%, 평균 latency 7.89%를 줄이면서 조건부 실패 2건을 회복했다. 60문항 안에 기존 7개 live effect 시나리오도 포함되어 모두 통과했다.

이 batch는 실제 Gemini와 live/full 정책, Planner, catalog compiler, TaskManager request 계약을 사용한다. 다만 runner의 live_enabled=false이므로 60건을 물리 기기에서 연속 실행한 결과로 해석하면 안 된다.

API key가 없는 shim에서 실행된 r14와 공통 device context가 누락된 임시 subset은 정상 기준선에서 제외했다. 동일한 context 계약과 요청 경로를 사용한 결과만 비교했다.

4.3 Live 정책 7개 시나리오

Artifact: a2a_planner_taskmanager_live_effect7_20260809-r2.json

대표 범위는 현재 상태 조건, 나이트·프라이버시, 바이탈사인+설정, 매너+음소거, 스캐닝 청정+풍량+센서다. 이 batch는 live/full 정책과 plan compilation을 검증하지만 live_enabled=false이므로 7건 모두를 물리 기기에서 연속 실행한 증거로 해석하면 안 된다.

오류가 있던 바이탈사인+밝기+볼륨 사례는 다음과 같이 개선됐다.

4.4 실기기 읽기 전용 E2E

기기 MWPA1M10KRDWA0425Z00423에서 다음 발화를 상태 변경 없이 검증했다.

현재 청정 기능이 켜져 있는지 확인하고 지금 공기질도 알려줘

관찰된 경로는 다음과 같다.

On-device text input
  -> Cloud Planner: air quality observation
  -> Device TaskManager: getAirCleanerOperation
  -> callback: STARTED -> COMPLETED
  -> Cloud DEF result composition
  -> "현재 청정 기능은 작동 중이며, 공기질은 좋습니다."

Planner가 만든 device request가 TaskManager에 도달하고 terminal callback으로 workflow를 재개한 사실까지 확인했다. 이동, 모드 변경, 바이탈사인처럼 부작용이 있는 full-live 반복 승인을 대체하지는 않는다.

live shim 재기동 뒤 같은 목표를 다시 검증하는 과정에서, 초기 Cloud observation의 effect evidence는 달성됐지만 durable plan_state.step_results에 결과가 보존되지 않아 후속 DEF가 청정 상태만 말하는 결함을 발견했다. 특정 공기질 문구를 보정하지 않고, 모든 초기 route 결과를 step_id와 output_key에 영속화하도록 범용 수정했다.

수정 후 발화와 결과는 다음과 같다.

현재 청정 기능이 켜져 있는지 확인하고 지금 공기질도 알려줘

Cloud observation -> air_quality_observed
Device TaskManager -> getAirCleanerOperation STARTED -> COMPLETED
Durable input_from -> 두 step 결과를 DEF에 전달
Goal status -> completed
Final response -> "현재 공기질은 좋으며, 고정 청정 기능은 작동 중입니다."

최종 workflow에는 experience_action_1, experience_action_2, experience_action_1_response가 모두 completed로 기록됐고, 두 desired effect가 모두 achieved 상태였다. 이 검증은 실행 완료뿐 아니라 사용자 목표 전체가 최종 응답에 보존되는지까지 확인한 live acceptance다.

4.5 Prompt payload와 비용 경계

전체 effect catalog를 그대로 넣지 않고, effect 48개와 동의가 필요한 policy 2개, skill provider 3개만 compact excerpt로 제공한다. 기본 JSON 직렬화 기준 4,875자다. 정상 진행 event에는 Supervisor LLM을 호출하지 않고, terminal evidence 누락·실패·조건 분기·사용자 목표 변경처럼 의미 결정이 필요한 순간에만 호출한다.

5. Live 승인 경계

현재는 정책·계약 기준 Go, 제품 전체 full-live 기준 Conditional Go다.

남은 승인 항목:

1. 바이탈사인 완료와 사용자 취소 callback을 실기기에서 반복 검증한다.
2. privacy/security처럼 음성·모드 상태를 바꾸는 기능은 rollback까지 한 묶음으로 검증한다.
3. 이동·탐색은 실제 arrival와 negative observation을 포함해 반복한다.
4. 60문항과 전체 pytest 기준선은 통과했으며, 이후 catalog 변경마다 같은 gate를 유지한다.
5. p95 latency와 per-turn token budget을 별도 운영 gate로 둔다.

따라서 “스스로 답을 찾는다”는 표현은 카탈로그에 근거한 수단 선택, 실제 증거 확인, 제한된 대안 탐색을 뜻한다. safety policy를 우회하거나 무제한으로 action을 발명하는 자율 실행을 뜻하지 않는다.

목표에 따라 이동·회전·관찰 수단을 새로 조합하는 시나리오와 현재 readiness는 Experience Goal-Directed Creative Motion Scenarios에서 구체적으로 본다.