주문 서비스가 주문을 출고할지 검토를 위해 보류할지 결정하는 호출자 제공 규칙을 받아야 한다고 해 봐요. 주문 금액과 신원 확인 결과 같은 입력을 규칙에 명시적으로 전달해요. 규칙은 선택한 행동과 이유를 담은 결정 데이터를 반환하게 해요. 호스트는 어떤 작업을 수행할지 정하기 전에 그 결과를 살펴볼 수 있어요.
이 가상의 연동에서 출고 결정이 반환됐다고 실제로 주문이 출고됐다는 뜻은 아니에요. 호스트가 알 수 없는 행동을 거부하거나, 뒤이어 권한을 검사하거나, 다른 주문을 갱신할 수도 있어요. 입력과 반환 데이터를 기록하면 문제가 된 결정이 어디서 나왔는지 좁히는 데 도움이 돼요. 실제 행동을 확인하려면 호스트를 따로 관찰해야 해요.
평가기는 규칙 인터페이스만큼 중요해요. Lispex 1.21의 기본 소스 평가는 신뢰하는 코드를 프로세스 안에서 실행해요. 제공된 소스를 신뢰하고 실행 한계가 필요하지 않을 때는 타당한 선택이에요. 임의의 호출자 소스에 자원 한계를 보장하는 방식은 아니에요.
Native embed와 embed full은 import 없는 WASM과 매번 새 인스턴스를 사용하는 서로 다른 제한형 평가기예요. 자원 보장을 말하려면 어느 평가기의 어떤 프로필이 그 보장을 제공하는지 밝혀야 해요. 준비와 평가도 선택한 프로필에 따라 별도로 집계해야 해요. 평가에만 명시된 한계로 모든 준비 작업까지 설명할 수는 없어요.
이 서비스라면 평가기, 프로필, 명시적 입력, 반환된 결정을 함께 기록하고, 관찰한 호스트 동작은 별도로 연결하겠어요. 규칙의 계산을 살펴볼 수 있게 유지하면서도 출력만으로 집행을 입증했다고 보지 않게 돼요.