AnankeLabs는 KAIROS의 절차적 위상 생성에서 운영체제와 실행 환경마다 달랐던 사인(sine) 계산을 하나의 소프트웨어 구현으로 통일했다. 검증한 유한 코퍼스와 런타임 조합에서는 네 환경의 결과가 비트 단위로 일치했지만, 임의의 하드웨어와 입력 전반을 보장하는 결과는 아니다.

IEEE-754는 덧셈·뺄셈·곱셈·나눗셈·제곱근의 반올림을 규정하지만, 사인 같은 초월함수의 결과까지 모든 수학 라이브러리에서 같게 만들지는 않는다. AnankeLabs가 4,465만 1,520개 좌표 튜플을 비교했을 때 Linux의 glibc와 WebAssembly 구현은 sin(angle)의 최하위 비트에서 3.104% 차이를 보였다. 해시값 차이가 실제 위상 결정으로 이어진 사례는 관측되지 않았지만, 제작진은 그 가능성이 0은 아니라고 계산했다.

KAIROS는 시간과 위치, 시드로 만든 해시를 사용해 이동 경로의 차단 여부와 구조물의 질량 등을 정한다. 따라서 같은 시드로 만든 위상이 런타임마다 달라지면, 이후 계산도 서로 다른 환경을 바탕으로 진행될 수 있다.

AnankeLabs는 WebAssembly에서 이미 쓰던 libm 0.2.16의 사인 구현을 기준으로 삼았다. Rust 네이티브 빌드는 고정 버전 libm::sin(angle)을 사용하도록 바꾸고, TypeScript 검증기에는 같은 사인 계산을 직접 옮겼다. 이에 따라 네이티브 Linux의 glibc와 JavaScript의 Math.sin에 기대던 경로를 제거했다. libm이나 컴파일러 도구체인, 빌드 프로필이 바뀌면 다시 적격성 검증을 해야 한다.

검증 코퍼스는 V1~V5로 구성됐다. V1~V3은 총 140,967,353개 튜플을 다뤘으며, 경계값 사례와 이동 마스크도 별도 층으로 검사했다. 네이티브 x86_64·aarch64, WebAssembly, TypeScript 검증기는 이 범위에서 중간 계산과 위상 결정 모두 비트 차이 없이 일치했다. 다만 이는 정해진 코퍼스와 런타임 조합에 대한 결과이지, 모든 입력이나 검증하지 않은 하드웨어에 대한 보편적 보장은 아니다.

성능 영향은 실행 환경에 따라 달랐다. 네이티브에서 일반적인 작은 각도 입력은 기존 대비 1.003~1.043배의 시간이 걸렸고, 큰 각도 경로는 aarch64에서 1.04~1.71배였다. 큰 각도 작업 열 개는 사전에 정한 1.10배 기준을 넘었으며, 내부 검토에서 비트 일치성을 위한 명시적 예외로 받아들였다. WebAssembly는 패키지별 최적화 설정을 조정한 뒤 측정한 작업에서 기존 대비 스칼라 1.006배, 배치 0.975배, 마스크 생성 0.976배의 시간이 걸렸다. 배치와 마스크 생성은 기존보다 각각 2.5%, 2.4% 빨랐다.

기존 구현 간 차이를 바탕으로 추정한 위상 결정의 예상 뒤집힘 확률은 평가당 약 2.1×10⁻¹³이다. 이 추정은 해시값이 임계값 주변에 균일하게 분포한다고 가정하며, 해당 가정을 검증하지 않았으므로 보장은 아니다. 관련 작업은 1부와 3부로 이어진다. 참고 자료로 1부: 도메인 대수와 종료 우선순위, 3부: 도달 가능성 캐시와 나노초 벤치마킹, 자율 시스템 신뢰를 위한 릴리스 엔지니어링을 제시했다.