papers/kai/sections/02-interface.tex

\section{The interface}
\label{sec:interface}

A request holds a state (text or JSON), between 1 and 100 questions and,
optionally, a policy. A question is one of three types:
\begin{itemize}[leftmargin=1.5em]
  \item a \emph{choice} over two or more labels, answered by a probability for
    each label;
  \item a \emph{yes/no} question, answered by the probability of yes;
  \item a \emph{score} over one or more ordered levels, answered by a
    probability for each level and its expected level.
\end{itemize}
Every answer is a distribution over the declared answers and nothing else, so
it is read without parsing and compared without a judge. Unknown keys,
repeated keys and malformed questions are refused with the path of the fault.
Appendix~\ref{app:wire} shows a request of each kind.

\paragraph{Policy.} A request may carry a policy instead of leaving the
decision to the model. Under the harm policy each course of an action names
the people it would harm, either stated by the caller or read by Kai as typed
answers to registered questions (what lies on the path, and how many people).
Nio takes the course that harms fewest, keeps the default course on a tie, and
escalates to a person when any count is unknown, inexact or read below the
policy's confidence floor of 0.9. A yes/no answer the policy governs is set by
the rule, never by the model, and whatever acts on a verdict passes one gate
that refuses any action the verdict does not take. A verdict is advice to a
person or to a system that checks it again; Kai's decisions are not used to
actuate physical systems.

\paragraph{Serving.} Kai runs on CPUs in full precision. Two CPU families, an
arm64 host and an x86-64 host, give the same answers to $2\times10^{-5}$ on
every probability and the same policy outcome on every request measured
(Section~\ref{sec:serving}), so an answer read in evaluation is the answer
production serves. A request is answered the same way whatever else is
queued.