From the moment a question arrives to the moment an answer appears on screen, a fixed sequence of checkpoints runs every time — never a guess the model made on its own.
No account needed — this is Kav's own assistant, answering from what Kav publishes.
What happens to one question
Fourteen checkpoints run between a question and an answer — from a signed request to a metered, disclosure-gated reply. These six carry the most weight.
Identity is resolved — never supplied
Which organization, which language and who is asking come from the signed session and its token, never from a field in the message itself. A capability that needs an identity has no input for one — there is no code path where an id arrives from the caller and is trusted.
The model gets a toolbox built for this turn
A working set is assembled from your capability table for this turn alone, under a fixed token budget. A capability the customer hasn't yet cleared isn't hidden — it's compiled in, and calling it triggers the sign-in and resumes the identical call, rather than returning data it shouldn't.
One layer does all the work
The capability checks entitlement, calls your system through a connector, and maps the response onto a typed structure. Nothing above this layer — the assistant, a flow, a rule, the portal — ever reaches your system directly. If an identity value ever arrives as an argument, that isn't treated as bad input — the compiler already stripped such fields at every nesting depth, so its presence is logged as a suspected injection, not quietly accepted.
A template writes the numbers, a gate checks the rest
Amounts, dates, ids and statuses reach the screen through a display template fed by that typed output. A separate gate blocks any sentence that isn't grounded in what the capability actually returned — the model never authors a number.
One gate decides what you're allowed to see
Before anything leaves, every outbound field passes one disclosure boundary — installed by the type itself, not by a resolver author remembering to add a check — that redacts or withholds by the data's sensitivity class and by who's asking. A field left unclassified resolves to the strictest handling, never the loosest.
Every call, every gate, every cost — a row
Each capability call, each gate that closed, and each model cost is written as a countable record — visible in the Studio, not buried in a log file. A refusal has a name; a name can be counted, alerted on, and fixed.
Identity is resolved — never supplied
The model gets a toolbox built for this turn
One layer does all the work
A template writes the numbers, a gate checks the rest
Fourteen checkpoints run between a signed request and a reply on screen. Eleven of them can stop the answer outright — this is the whole path, not just the highlights.
1
Message arrivesWidget, Telegram or WhatsApp — signed and channel-identified
2
Organization & languageResolved from the token, never from the client
3
Injection screeningInstruction-shaped text in the message is neutralized
4
Distress & mode gatesDistress, personal data or a third party — each opens its own path
5
Routed by directiveA table row decides precedence — never an if-statement in code
6
This turn's tool spaceOnly the capabilities this person is allowed, right now
The tool loop — repeats until the answer is grounded
7
Model picks a toolIt chooses what to ask — never the answer itself
8
Capability layerArgument checks, identity, entitlement, a call to your system, typed mapping
9
Knowledge & rulesHybrid search and reranking, or a compiled rule engine for a decision
10
Render templateEvery number, date, id and status passes through a template — never the model
11
Output gatesGrounding, a confidence floor, an invented number, an id with no source — each one blocks
12
Disclosure gateRedaction by sensitivity class — one checkpoint every output crosses
13
On screenDelivered live, with a source label and a timestamp
14
Audit logEvery capability call, every closed gate, every cost — recorded
Answer pathEnforcement pointLogged· Every failed gate closes: no data, no answer.
One capability, three faces — only one of them is yours
A capability — "what's my balance", "book me a slot", "open a request" — is stored as three separate layers. That separation is the whole difference between one product and a rewrite for every organization that installs it.
Semantic — what the model reads
A summary, when to use it, when not to, disambiguation and synonyms in every language. Identical for every organization.
Contract — the input and output
A typed schema. Every prompt, rule, flow diagram and portal screen is written against this and nothing else. Identical for every organization.
Execution — the link to your systems
Which connector, which operation, how the request is built and the response is mapped. This is the only layer that's yours.
Swap your billing vendor, and only Execution changes. The prompts, the rules, the flow diagrams and the tests stay exactly as they are.
How a language model touches a real system
A model on its own can only write text — it doesn't know anyone's balance. To act, it needs tools: a list of operations it may request, each with a name, a description and a typed input form. The open standard for that handshake is MCP, the Model Context Protocol. The gap it doesn't close: a conventional tool server is code — its tools are written in a file, built and shipped. A new tool means a new release.
A conventional tool server
A fixed tool list, written in code
The same tools for every user
A new tool means a new release
No real notion of "which organization"
The model receives the raw response
Kav's capability layer
Built fresh every turn from your capability table
Assurance and entitlement checked on every call
A new tool is a published row, live immediately
Every binding is organization-scoped, enforced by the database itself
The response is mapped, templated and gated before anyone reads it
Kav builds the toolbox. The model only ever chooses from it.
The customerWhat they're allowed to see
→
KavBuilds the toolbox
→
The modelChooses only from it
Two ways Kav decides, one set of guardrails
A question either needs something found, or something decided. Both run through the same fail-closed discipline.
Finding an answer: hybrid search, then proof
A per-organization glossary expands your own vocabulary across languages before anything is searched. A word-matching search and a meaning-based search run side by side, merged into one ranking with no hand-tuned weights per question; where you switch it on, a dedicated reranking model then reorders — never adds or drops — the result against the actual question. The confidence score carries its own reason: too little coverage, nothing on topic, or nothing published in this language — and below the bar Kav says so and offers a person, rather than guessing politely. Every sentence that does ship is checked against the passages it came from, and every digit must appear in them character for character.
Deciding an answer: a compiled rule engine
A rule answers one named question at one declared decision point — never a trigger. It's stored as a typed table your team edits directly, not code, compiled to run in memory with the cheapest fact checked first. A rule returns a decision; it never sends anything itself.
Every refusal has a name
A missing entitlement, an unverified identity, a number the model tried to write itself, a sentence not grounded in what was retrieved — each is a distinct, named gate, not one general "something went wrong." A condition that can't be evaluated never matches, and nothing in the platform fails open.
Finding an answer: hybrid search, then proof
Deciding an answer: a compiled rule engine
Every refusal has a name
Kav.Knowledge · Kav.Rules
Not "search." Six stages.
A vector search alone misses exact wording. A keyword search alone misses meaning. A grounded answer takes both, merged, reranked and checked — not one lookup against one index.
01
Term expansion
A per-organization glossary maps abbreviations, local terms and multilingual synonyms to each other, so a question worded one way still finds a passage worded another.
02
Hybrid search
Two searches run in parallel: exact-word matching and meaning-based vector search. Each one catches what the other misses.
03
Rank fusion
Reciprocal Rank Fusion merges both result lists into one ranking, without hand-tuning weights for every kind of question.
04
Reranking
A dedicated ranking model reads the question against every retrieved passage and reorders them by actual relevance, not just search score.
05
Confidence gate
If confidence is still too low after all of that, Kav does not answer. It says it couldn't find a reliable source and offers a handoff instead of a guess.
06
Grounding check
The drafted answer is checked against the passages that were actually retrieved. A sentence the source doesn't support doesn't ship.
And nothing reaches a customer unreviewed: every knowledge article carries an owner, a version and a last-verified date — and flips to "needs review" the moment its source changes.
Seven layers, and why each exists
None of this is a policy someone has to remember. Each layer is enforced by mechanism — most of them by an architecture test that fails the build the moment they're bent.
Isolation in the database — every organization-owned table carries a tenant column, an application filter, and a Postgres row-security policy. The filter is convenience; the policy is enforcement, and services connect as a role that cannot bypass it.
Five assurance levels — anonymous, channel-verified, identified, entitlement-proved, strong. Every capability declares its floor; a binding may raise it, never lower it.
Seven sensitivity classes — public to special-category, in strict order, each deciding retention, model visibility, transcript storage and export in one compiled table. An unclassified field resolves to the strictest class, not the loosest.
One disclosure gate — installed per type by the schema itself, so a field added next year is covered by default. An exemption is written in visible prose, not a silent skip.
Permissions per operation — dotted and specific. Tokens carry roles and scopes only; a screen you lack permission for closes and names exactly what you'd need.
A key vault per organization — every secret sealed under its own key, wrapped by a root key held outside the database, reachable only through an unwrap-only interface. Custody of keys and authorship of capabilities are separate roles.
An audit ledger nobody can edit — every staff view of personal data, and every refused one, is a record with an actor and a purpose. The ledger refuses updates and deletes, enforced again at the database itself.
Above all seven: staff and customers are two populations, with separate clients, separate policies and separate stores. A staff console cannot authenticate a customer, and a customer cannot reach a staff screen.
Enforced by mechanism, not memory
Above all seven layers sit four rules that override everything else in this codebase — the ones every other decision here traces back to.
Nothing above the capability layer touches your systems directly.
Identity is never something the model or the caller supplies.
This is the entire install for the website widget — paste it once, before your page's closing tag, and never touch it again.
The tag never changes — Which version runs, in which language, in which colors, in which corner of the screen — all decided server-side from the widget key, not from anything on your page.
You never touch your HTML again — A branding change, a new module, a new language — published from the Studio, live immediately. No redeploy, no ticket to whoever owns the website.
Isolated from your site — The widget runs inside a closed shadow root, so your site's CSS can't break it and it can't break your site — confirmed against a deliberately hostile test page with a global reset and a nine-digit z-index.
The same mechanism that answers a property-tax question can answer a billing question, a policy question or an account question — the difference is which rows are in the database, not which code runs.
