외부 응답은 바이트로 들어와요. 그때는 애플리케이션이 특정 변형이라고 부를 근거가 아직 없어요. 가상의 클라이언트에서는 먼저 텍스트 디코딩과 JSON 파싱을 하고, 각각의 실패 경로를 처리해요. 파싱한 값은 그다음 검증 단계에 unknown으로 들어가야 해요.
지원하는 응답이 문자열 배열 items를 갖는 ready 태그이거나, 문자열 message를 갖는 failed 태그라고 해 봐요. 런타임 검사는 값이 객체인지, 태그가 알려진 것인지, 해당 페이로드가 필요한 모양인지를 확인해야 해요. ready는 있지만 items가 없는 객체는 불완전해요. waiting이 있는 객체의 태그는 이 계약 밖에 있어요. 타입 단언으로 원하는 유니온의 이름을 붙여도 어느 쪽도 유효해지지 않아요.
검사가 성공한 뒤에는 디코더가 판별 유니온을 반환할 수 있어요. 그러면 ready인지 검사하는 분기에서 값의 타입이 좁혀져 애플리케이션이 항목을 사용할 수 있어요. never를 이용한 완전성 검사는 선언한 모델에서 처리하지 않은 변형을 드러내는 데 도움이 돼요. 유지보수에는 유용하지만 응답 바이트를 검사하는 작업은 아니에요.
거부한 입력을 다룰 정책도 필요해요. 디코딩 실패를 알릴 수도 있고, 알 수 없는 응답을 의도적으로 별도 변형으로 모델링할 수도 있어요. 조용히 허용된 유니온으로 캐스팅하면 그 결정을 건너뛰게 돼요. 런타임 근거는 타입이 붙은 값을 만드는 곳 가까이에 두고, 각 처리기의 계산은 따로 검토하겠어요. 분기를 빠짐없이 다뤘다고 그 분기가 올바른 답을 낸다는 뜻은 아니에요.