Start with a number that quietly reframes who your documentation is actually for. In 2025, AI-driven readership of docs published on GitBook grew more than 500% and now accounts for roughly 41% of all readers. For a lot of internal knowledge bases, the single biggest consumer is no longer a person with a browser tab open. It's a retrieval system feeding a model.
That model has no way to squint at a page and think "this looks out of date."
It fetches whatever matches the query. Gartner has a name for what tends to come back. One writeup of their 2025 Market Guide for Enterprise AI Search calls it ROT content, redundant, obsolete, and trivial. When a RAG pipeline pulls ROT into the prompt, the answer it produces is confident, well-written, and wrong. People notice when that happens. In Anthropic's study of 81,000 Claude users, unreliability was the single most-cited concern, named by 27% of respondents, most of whom had run into it firsthand.
So here's the question we kept failing to answer for our own customers. When an AI assistant gives someone an answer drawn from your internal knowledge, can you say whether that source was safe to use at all? Fresh enough, reviewed, owned, cleared for this audience? For most teams the honest answer is no. We could tell you a document was fresh. We could not tell you whether a support bot should be allowed to quote it to a paying customer in a public chat.
That gap is the reason the Trust Engine exists. We shipped the first version of it in production two weeks ago, and it changes what Rasepi is for.
What we got wrong the first time
When we started, we built freshness scoring and thought that was the product. Documents get a score, stale ones bubble up, teams review them. Clean, measurable, easy to demo.
I was wrong about that, and it took a while to admit it.
Freshness is one signal. A document can be edited yesterday and still be wrong for a customer-facing answer. A document can be a year old and still be the most trusted thing you have. A page that is perfectly fine for an internal engineer to read can be the worst possible source for an autonomous agent about to change a customer's configuration. A freshness score has no opinion about any of that. It just tells you when someone last touched the file, which is roughly as useful as judging a contract by the date on the envelope.
The thing companies actually need to know is narrower and harder. Can this specific piece of knowledge be used right now, by this actor, for this purpose?
Trust is a decision, not a score
So the Trust Engine doesn't produce a number and walk away. It makes a decision, and it tells you why.
Every evaluation returns one of four outcomes: ALLOW, WARN, BLOCK, or ESCALATE. Each comes with a reason and the evidence behind it. The reason is a stable code, not prose we generate on the fly, so you can build logic on top of it.
The decision combines signals that a scanner never looks at together:
- Freshness: last reviewed, review expiry, whether a linked source changed after approval.
- Ownership: does the document have an owner, and is that owner still on the team.
- Provenance: was it written by a human, by AI, reviewed by anyone, linked to a real source.
- Policy: is it cleared for internal use, customer-facing use, AI retrieval, public publishing.
- Sensitivity: does it contain personal data, secrets, unreleased product information, regulated content.
- Context: who is asking, human or machine, internal or external, reading or acting.
The interesting part is that the same document gets different answers depending on the context. An expired OAuth migration guide might come back WARN for an internal engineer reading it, and BLOCK for a public support bot, because the linked API reference changed after the last review and customer-facing answers need fresh approval. Same source. Different actor, different channel, different decision.
(That contextual piece is the part I underestimated for the longest time. I kept trying to make trust a property of the document. It isn't. It's a property of the document plus who wants it and what they're about to do with it.)
Guard the knowledge before it reaches the model
Most AI safety tooling sits at the end of the pipeline. The model writes an answer, then something checks the answer for toxicity, leaked secrets, or policy violations. That work matters. It's also too late for the failure mode that actually burns enterprises.
The dangerous answer is usually well-written and confident and grounded in a real document. The document is just stale, unreviewed, or no longer approved for the audience it's being shown to. The model didn't hallucinate. It faithfully reproduced a source that should never have been in the prompt.
So the Trust Engine works one step earlier. In a RAG pipeline, your retriever finds its candidate documents as it always has, and then it asks Rasepi which of them are safe for this use case before any of them reach the model:
POST /api/trust/filter-sources
Blocked sources never enter the context. Warned sources can come with a required citation or disclaimer. The model only ever sees knowledge that was cleared for the actor and channel doing the asking. You don't have to proxy your LLM calls, route your traffic through us, or rebuild your stack to get this. The gate is an API call your existing retriever makes.
This is the line we keep coming back to internally: guard the knowledge before it enters the prompt, not the answer after the model already wrote it.
You don't have to move your docs
The objection I hear most from larger teams is reasonable. They have years of content in Confluence or Notion, and they are not going to migrate it to try a trust layer. They shouldn't have to.
The Trust Engine runs as a sidecar. It connects to the tools you already use, catalogs what's there, computes trust metadata on top, and exposes the same decisions through the same API. For a large Confluence tenant, it can index broadly with cheap metadata first and only deeply process the documents you actually route through AI. Keep your docs. Add trust.
That mode is the one most companies will start with, and I'm fine with that. The wedge is not "replace your knowledge base." The wedge is "you already have AI reading your knowledge base, and right now nothing decides what it's allowed to read."
Every decision leaves a record
The next thing serious buyers ask for, once they understand what the engine does, is proof. If a support bot gives a customer a wrong answer, can you reconstruct why that source was ever allowed into the prompt?
Every decision the Trust Engine makes is written to a provenance ledger. Actor, action, timestamp, the sources considered, which were allowed and which were blocked, the trust state at the time, the source versions. So the question stops being "who knows why the bot said that" and becomes a query. Who or what relied on which knowledge, and why was it allowed.
For anyone carrying compliance weight, that record is most of the value on its own.
Where this is going
The Trust Engine is live, the API is documented, and internal RAG gating is behind a flag while we tune it with the first design partners. The connectors for external tools are the next thing we're hardening, because the sidecar story is what brings in the teams that can't migrate.
If you're putting an AI assistant on top of your own content and you can't yet say whether a given source was safe for it to use, that's the gap worth closing first. You can try it, or send me the failure mode you're worried about and I'll tell you honestly whether we handle it yet.