Enterprise Dashboard
You decide who reaches which sources, and the same boundary holds through every tool. Role-based access, governed scopes and SSO in one place, deployed in your cloud tenant or air-gapped on your own hardware.
- Add and remove members
- Create knowledgeBases
- Set retention
- Export the audit log
Full scope, and the only role that can change anyone else’s.
- Ask across scoped sources
- Run packaged apps
- Upload to a knowledgeBase
Does the work. Cannot see commercial material or change who has access.
- Read an answer and its citations
- Open the audit trail for one matter
Sees the basis for a finding and nothing else. This is the role that makes an outside review safe to grant.
The tool was never the hard part.
Three things decide whether a knowledge platform reaches the people who need it, and none of them are about the answers.
The security review is where the pilot goes to wait.
A questionnaire arrives, and the honest answers to half of it are on a page nobody has written. The engineers who wanted the tool now wait on a document instead of using it.
Everyone can see everything, or nobody can see anything.
Access ends up all-or-nothing because per-team scoping was too much work to maintain. Commercial terms sit in the same pool as the field manual, and the fix is to lock the pool.
You can show the policy. You cannot show it held.
An auditor does not want the permissions matrix. They want an instance: this person asked for that, and here is what the system did about it.
Four things you control, and can prove you controlled.
Each one is set once, against the source, and enforced across Chat, viewXpert, Agentic Apps and tutorXpert. No tool is looser because it was set up later.
Which sources each role reaches
Set per knowledgeBase, down to a single document, and enforced everywhere.
Who gets in, and how
Single sign-on, users and organisations administered in one place.
What was asked, and what happened
Every question logged with who asked it, what was in scope, and the answer.
Where it runs
Your cloud tenant, or air-gapped on your own hardware.
Governance you can show an auditor.
Every question logged with who asked it, what was in scope, and what happened, including the ones that were refused.
A refusal is the part you can actually evidence.
Everyone will show you a permissions matrix. It is a promise about what would happen.
The interesting rows are the refusals
A request turned down because a role did not reach it, with a name and a time against it, is a control. A policy nobody ever tested is a document about a control.
The boundary belongs to the source
Access is decided against the knowledgeBase, so the same person meets the same boundary through Chat, an app or a tutor. No tool is looser because it was set up later.
Changing deployment does not restart the review
Cloud tenant or air-gapped on your own hardware, the governance model is the same. What your security team approved is not invalidated by where it ends up running.
Certifications, subprocessors and the Trust Center are on Security, the page to forward to a security team. Scope is set per knowledgeBase; what a person reaches it through is the Hub.
One Hub. Every governed tool.
The same roles and the same approved sources govern every tool on the platform.
Agentic Apps
Workflow automation: turn a request you repeat into a finished, cited deliverable.
Explore →All of it behind one launcher. See The Hub →
Straight answers.
Where does it run?
Cloud tenant or fully air-gapped on your own hardware, records never leave the building. The deployment model is scoped separately.
What can we hand our security team?
The Trust Center, which is public and lists the controls and the policies rather than describing them, plus SOC 2 Type II and ISO 27001. Your documents stay in your own tenant and we do not train models on them. If the review needs something the Trust Center does not cover, ask on the walkthrough rather than waiting on a document.
How do access and governance work?
Set who sees what, lock answers to approved sources, and keep an auditable trail. Role-based access and approved-source scoping apply across every tool on the platform.
How is this scoped for a team our size?
Two things carry most of it: the deployment, because a cloud tenant and air-gapped on your own hardware are different propositions, and how many people need access. Roles and approved-source scoping apply across every tool either way, so the scoping conversation is about deployment and headcount rather than which features are switched on. We are updating our pricing and will publish the new structure shortly; a walkthrough gets you current figures against both.
Scope a governed deployment for your team.
Thirty minutes, your own documents, every answer cited to its source.