We already have a chatbot. What would change?
Probably not your chatbot. Qriton KB is self-contained, with its own retrieval and its own governance, so most teams point it at the narrow slice of questions they would actually have to defend and leave the rest where it is. Nothing about your current setup has to change to trial it: no account, no install, nothing to connect.
Which AI models can it use? OpenAI, Anthropic, open source?
The answer generator is replaceable. A deployment can explicitly configure OpenAI or Azure OpenAI, run a local open-weight model such as Qwen on its own hardware, or use extractive mode with no generative model. Extractive mode quotes the source passage rather than paraphrasing it. Embeddings are likewise configurable as local sentence-transformers or OpenAI. This public demo uses the OpenAI integration for answer generation; do not submit confidential information. Anthropic is not a built-in provider today and we would rather say so than imply otherwise; the generator is a single interface, so adding one is small work.
Can we connect it to our own systems and pull knowledge in automatically?
Yes. Documents arrive through a connector: a local directory, a network share, or a blob manifest for object storage. Watch mode polls on an interval and re-ingests changes on its own, and re-indexing is incremental, so only new or changed sections are re-embedded. Everything the interface does is also a plain HTTP API on the same service, including asking a question, triggering and checking an ingest, submitting a correction, fetching an authorized receipt by hash, verifying it against the deployment's audit log, and reading metrics. Integration is ordinary HTTP against your own host.
Can different teams be limited to different parts of the knowledge base?
Straight answer: not by user or group yet. Today the boundary is the deployment. Each instance carries its own corpus and its own audit chain, so the normal pattern for genuinely separate audiences is a separate instance, which also keeps their records separate. The retrieval layer already accepts a source restriction, and answers are already scoped to a subset of documents when a question calls for it, so that is the hook per-group access would be built on. What does not exist is the account and group model to attach it to. If per-group access is a requirement rather than a nice-to-have, say so early in a pilot: it is a real piece of work, not a config flag.
Can we test and tune how well it performs?
Yes, and you should before trusting it. There is a scorecard you can run locally against your own corpus, the answerability threshold is an explicit release setting to calibrate against that versioned test set, and live metrics are exposed. On an audit-enabled deployment, answered and refused exchanges can also be reviewed after the fact instead of relying only on a benchmark; retained records follow that deployment's policy.
Where does our data go?
Qriton KB supports fully local deployment. External model providers are optional and explicitly configured. This public demo uses the OpenAI integration for answer generation; do not submit confidential information. A local open-weight answer generator such as Qwen, or extractive mode, keeps answer generation inside the deployment. It does not by itself make the whole deployment local: connectors, embeddings, verification and other model roles, plus network controls, must be configured and reviewed too.
How accurate is it?
We do not claim a blanket accuracy advantage over baseline RAG. Evaluate answer quality on your own corpus and test set. Qriton KB's differentiation is the governed correction path, refusal policy, citations, and audit record.
What happens when it doesn't know something?
It refuses, and shows you the nearest sections it considered instead of guessing. No supporting source, no answer.
How does its knowledge stay current, and do you retrain the model?
Changing governed knowledge does not require retraining. Documents and managed corrections remain separate from the foundation model, and the answer generator is replaceable. With the HLM5 explicit-slot adapter, eligible short facts can be installed as named slots over a frozen foundation; other deployments use the managed correction source. Active corrections can be removed, while retained audit history follows the customer's retention policy.
Who can actually change what it knows?
A permitted user can propose a correction with evidence. Only a named reviewer can approve that correction. Approval is distinct from application and live promotion. An accepted managed-source operation is recorded and can be rolled back; other administrative mutations depend on the deployment's configured controls.
Do we need to sign up or create an account to try it?
The public integration demo accepts non-confidential test questions without an account. Receipt and audit-log access on a confidential deployment is controlled by that deployment.
Is this legal advice?
No. It's informational and cited to source, not a substitute for legal counsel.
How long does it take to get running?
Ingestion is automated: point it at your documents and it indexes them and there's no model-training step, which is what a fine-tuned approach would require. A specific timeline for your own document set is part of the pilot conversation.
What does it cost?
It depends on deployment scope and provider choice. Local Qwen answer generation or extractive mode avoids hosted answer-generation calls; other configured model roles and connectors determine whether the deployment as a whole is local. An explicitly configured external provider has its own usage cost. Request a private pilot and we'll work it out together.