Your firm's knowledge, governed from day one

Upload PDFs, Word documents, and structured text. NuBench indexes every chunk using pgvector HNSW — the same database that stores your conversations, inside your AWS account.

No external vector database. No data leaving your deployment boundary. Every document chunk is encrypted at rest with your CMK, stored in Aurora PostgreSQL alongside all other firm data, and queryable via cosine-similarity search. Retrieval augments the conversation context automatically — no manual paste required.

A knowledge base created at a higher hierarchy node — Division, Department, Team — is automatically visible to all nodes below it.

Your firm's global DLP policy sits at the Organisation level; every team can use it. A practice group's proprietary playbook sits at the Practice level; only that practice sees it. You never grant access manually — the hierarchy does it. Lower nodes cannot see knowledge bases above them unless explicitly granted, and they cannot create KBs that claim higher-scope classification than their own node.

Knowledge Base chunks carry a classification tier. PHI chunks only surface in PHI-classified conversations. General chunks never contaminate a RESTRICTED session.

Classification is assigned at KB creation and cannot be downgraded after PHI or PII content has been ingested. The retrieval step runs inside the governance pipeline — after classification is confirmed, before model dispatch — so no out-of-policy document ever reaches a model call.

When you're in a conversation, relevant KB chunks surface without you asking — the platform retrieves based on semantic similarity to your prompt.

Retrieval is always-on for knowledge-enabled conversations (step 8d of the governance pipeline). You can also chat directly with a knowledge base via the dedicated KB chat surface, which streams an answer grounded entirely in your documents. Citations link back to source chunks.

Every document is virus-scanned (ClamAV) before any chunk is stored. Malware-positive documents are quarantined and never indexed.

Ingestion goes through a dedicated nb-knowledge service, not directly into the database from the browser. Administrators control which hierarchy nodes can create or manage KBs. KB actions — create, update, delete, re-embed — are logged to the audit trail with the acting user's identity and the KB's classification at the time of the action.

When your embedding model is upgraded, administrators can trigger a re-embed job from the Admin Console without downtime.

Re-embed runs asynchronously — the KB remains queryable on the old index while the new one builds. The Admin Console shows progress per KB and alerts when chunks are stale. Stale-chunk warnings surface before re-embed is triggered, so you know which KBs are affected.