How Kav works: one engine behind every channel
From a message arriving to an answer on screen, the same fourteen checks run every time — never a guess the model made alone.
A language model, on its own, only knows how to write text — it has no idea what anyone's balance is. Kav's answer to that isn't a bigger prompt; it's a fixed sequence of checks that runs on every single turn, on every channel, whether the question is "what's my balance" or "how do I open a ticket."
The path from a message to an answer
Fourteen checks run between a signed request arriving and an answer reaching the screen — eleven of them can stop the answer outright. Identity and language are read from the session token, never from anything typed in the message. The text is screened for instructions hiding inside it before anything else happens. A routing table, not a line of code, decides whether this turn's phrasing should pin a specific capability instead of falling back to search. The model is then handed a toolbox built fresh for this one conversation — only what this organization installed, only what this resident is currently entitled to reach — and it chooses a tool; it never writes the answer directly from what it already believes.
One capability, three separate layers
A capability like "what's my balance" or "book me an appointment" is stored as three layers, not one. Its semantics — what it's for, when to use it, when not to — are identical for every organization. Its contract — the typed input and output shape — is identical too; every prompt, rule and screen is written against that shape and nothing else. Only its implementation — which connector, which system, how the response maps back — belongs to a specific organization. That split is why installing a new capability is a database row, never a new deployment.
The model never writes the number
Every amount, date, identifier and status a resident reads comes from a display template fed by the capability's own typed output — the model picks the template and writes the words around it, but it never types the figure itself. Before anything reaches the screen, it also has to survive a grounding check (does the retrieved source actually say this), a confidence floor (a hybrid search — exact-match and semantic, merged and re-ranked — that answers "I don't know" rather than guess when nothing scores high enough), and one shared disclosure boundary that redacts by data-sensitivity class regardless of which capability produced the field.
Why a refusal always has a name
Missing eligibility, an unverified identity, a number the model tried to invent, a sentence the retrieved passages don't actually support — each is its own named gate, not one generic failure. That's deliberate: a refusal a team can count, label and fix is worth more than an answer that's technically confident and occasionally wrong. Every capability call, every gate that closed and every model cost is written to one auditable record, visible in the Studio rather than buried in a log file only an engineer can read.