---
title: "Governed Knowledge Assistant — doc-QA under KYE™ authority · KYE Protocol™"
description: "A reference showing how a third-party document-QA / RAG knowledge assistant is governed by KYE Protocol™ at the execution boundary: every retrieval and answer flows through admit, decide, pin, evidence, and replay-proof — provable from public keys alone."
url: https://kyeprotocol.com/governed-knowledge-assistant/
lang: en
source: "KYE Protocol"
---

> A reference showing how a third-party document-QA / RAG knowledge assistant is governed by KYE Protocol™ at the execution boundary: every retrieval and answer flows through admit, decide, pin, evidence, and replay-proof — provable from public keys alone.

KYE™ Governed Knowledge Assistant™

# Govern the knowledge assistant, not just the answer.

The KYE™ Governed Knowledge Assistant™ is the drop-in governance onramp for any document-QA / RAG assistant. A knowledge assistant retrieves passages and answers a question; KYE Protocol™ governs the act around it: it admits the retrieval, decides whether the assistant _may_ answer, and proves the basis it answered from. Every reply seals into a signed evidence chain you can verify from public keys.

Walk the flow Verify it yourself The honest boundary

**The honest scope:** KYE Protocol™ governs whether the assistant's answer or downstream action may proceed and proves the basis it relied on; it does not judge whether the content is factually true. Truth of content is the assistant author's responsibility and the human reader's judgement.

1 · What this governs

## The assistant answers. The protocol governs the answer as an act.

KYE Protocol™ binds the assistant to a purpose, checks admissibility, and proves the cited basis.

The kind of assistant this governs is a document-QA or retrieval-augmented system: a clinician asks about dosing, an analyst asks about a filing, and the assistant pulls passages from an approved corpus and replies with citations. Products in this category sit close to high-stakes decisions, so the question is not only "is the answer good?" but "was the assistant allowed to answer, and can the basis be replayed?"

KYE Protocol™ answers the second question. It binds the assistant to a purpose and scope, decides admissibility at the boundary, pins each retrieval call, packs the cited sources as evidence, and seals a replay-proof. The result is an act a regulator can re-derive, not a log they must trust.

2 · The end-to-end flow

## A clinician asks a question — five governed steps.

Worked example: a clinician asks the assistant for anticoagulation dosing guidance in renal impairment. Each step below is a real envelope, validated against its existing protocol schema. No new schema was minted for this reference.

1. **Admit.** The retrieval call crosses the MCP gateway. Only the allow-listed retriever is admitted.
2. **Decide.** A [Purpose-Permission](https://kyeprotocol.com/mcp/) verdict answers whether this assistant may retrieve, as a per-check reason list.
3. **Pin.** The call is pinned by tool id, version, and input and output hashes.
4. **Evidence.** An [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) binds the decision and each cited source as a signed signal.
5. **Replay-proof.** A signed proof asserts the decision re-runs to the same result.

The full six-envelope sequence ships as canonical fixtures under `public/examples/governed-knowledge-assistant/` — binding, admissibility, retrieval pin, evidence pack, replay-proof, and the completion ledger.

3 · The envelopes

## Six existing schemas, assembled into one chain.

Each envelope validates against the protocol schema it reuses. No new schema was minted.

- **Governance binding** — the assistant declares purpose, read-only scope, and its single retriever.
- **Admissibility decision** — twelve per-check verdicts answer whether retrieval is allowed.
- **Tool-call pin** — the retrieval call, fixed by version and input and output hashes.
- **Evidence pack** — cited guideline and formulary passages as signed signals.
- **Replay-proof** — the decision re-runs to a byte-equal result.
- **Completion ledger** — the actual file reads and tool call, checked against the declared scope.

4 · The honest boundary

## What the protocol does not do.

KYE Protocol™ governs the authority to answer; it never claims to judge the answer.

KYE Protocol™ does not build a retriever, index a corpus, or rank passages. It does not decide whether an answer is medically or factually correct — truth of content is the assistant author's responsibility and the human reader's judgement.

What the protocol governs is narrower and provable: whether the assistant may answer or act, and the cited basis it answered from, captured as admissible evidence. A retrieval-quality signal can feed the decision; it does not replace it.

5 · Verify it yourself

## Provable from public keys alone.

Every signed envelope in the chain verifies against the published key set at `trust/self-audit-jwks.json` — the same Ed25519 verification surface the protocol uses to audit itself. No credentials, no vendor portal: parse the JSON, canonicalise the payload, and check the signature. The [self-audit](https://kyeprotocol.com/trust-self-audit/) page walks the verifier step by step.

Drop-in onramp

## Wrap your RAG answer in a dozen lines.

Keep your retriever and your model. Add KYE Protocol™ at the answer boundary.

Ask `decide()` whether the answer may proceed and under whose authority, then seal the cited basis as an [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) — verifiable from public keys alone. The free tier runs client-side. The canonical snippets are `kye:snippet:govern-rag-ts` and `kye:snippet:govern-rag-py`.

```
// TypeScript — npm install @kye/sdk
import { KyeClient } from "@kye/sdk";

const kye = new KyeClient({ apiKey: process.env.KYE_API_KEY });

// Your RAG pipeline stays as-is; KYE™ governs the answer as an act.
export async function answer(question: string, principal: string) {
  const sources = await retrieve(question);
  const decision = await kye.decide({
    purpose: "knowledge.assistant.answer",
    principal,
    inputs: { question, source_ids: sources.map((s) => s.id) },
  });
  if (decision.effect !== "permit") return decision.refusal;

  const draft = await generate(question, sources);
  await kye.evidence.pack(decision.context_seal, { answer: draft, sources });
  return draft;
}
```

Python parity ships as `kye:snippet:govern-rag-py` via `pip install kye-sdk`. KYE Protocol™ never sees your corpus or your model output beyond the `source_ids` you pass it — it governs whether the answer may proceed, not whether it is true (§63 / §31).

## Govern every answer your assistant gives.

The Governed Knowledge Assistant is a governance projection of [KYE Protocol™](https://kyeprotocol.com/). It reuses [Governed Prompts](https://kyeprotocol.com/governed-prompts/), the [KYE Protocol™ MCP Server](https://kyeprotocol.com/mcp/), and the [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) — no new engine.

[KYE Protocol™ MCP Server](https://kyeprotocol.com/mcp/) [Evidence Pack™](https://kyeprotocol.com/evidence-pack/)