Build a knowledge base your AI assistant actually uses

Turn documents and records into a searchable knowledge base your AI assistant actually cites — with answers filtered by each person’s permissions.

By the end of this guide you will have a knowledge base running in AxisIQ: two or three collections of your own documents, the record types worth searching switched on, and answers coming back by meaning — in the Knowledge Base app and through Ask Axis — filtered on every result against the rights of whoever asked. Retrieving your own material and answering from it is what retrieval-augmented generation (RAG) means in practice; here it is configuration, not a project. Set aside half an hour, plus the time it takes to find the documents.

The order matters more than the effort. The usual way this goes wrong is in the first five minutes: one collection called Documents, everything tipped into it, and a month later the only two ways to share it are with everyone or with nobody.

What you need before you start

Nothing to configure for the search itself. Searching by meaning needs a model that converts your text into embeddings, and on hosted AxisIQ that is already set up. If it is ever unavailable, the Knowledge Base states so plainly — it will not quietly downgrade itself to word matching and keep the same name.

Material that is worth searching. Written procedures, policies, product specifications, supplier agreements, the onboarding pack, the notes somebody keeps because there was nowhere else to put them. If an answer exists only in one person's head, indexing cannot reach it — that is a writing job, and it comes first.

A rough answer to "who should be able to find this". You need it in step one, and getting it wrong is the only mistake here that is annoying to undo.

Step 1 — Split your collections by audience, not by topic

A collection is a named set of documents, and access is granted collection by collection. That single fact should decide your structure: the grant is what you maintain for years.

The test is simple: two documents that would be given to the same group of people belong in the same collection; if they would not, they belong apart. Topic is a weaker organiser than audience — you can always find a document about warranties, but you cannot easily pull warranties back out of a collection you have already opened to the whole company.

A structure that holds up for an operations team:

• Ops SOPs — picking, packing, returns, dispatch. Warehouse and operations.
• Finance policies — credit terms, approval limits, write-off rules. Finance and directors.
• Product specs — sizing, materials, care instructions. Everyone, including sales.
• Onboarding — everything a new joiner asks in week one. Everyone.

Step 2 — Create the collection and upload into it

Open the Knowledge Base app, go to Documents, and create your first collection with the name you settled on above, then upload into it. A document belongs to the collection you put it in, so choose before you upload rather than tidying afterwards.

Two habits worth forming early: upload the version that is currently true rather than the one with the most edits, and keep to material that will still be accurate next month.

Step 3 — Turn on indexing for the right record types

Documents are only half of what a business knows. The rest has already been typed in: the paragraph on a supplier account, the description that says what a product actually is, the reason attached to a returned order.

Record indexing is a toggle per object type, in the same app. Whoever manages the knowledge base enables a type, and from then on those records turn up in results beside your uploaded files. Edit one of those records and it is re-indexed on its own, so results track the data as it stands today, not as it stood when someone last exported it.

Turn on the types that carry prose — customers, suppliers, products, jobs, anything with a notes or description field people genuinely write in. Leave off the ones that are columns of numbers and identifiers: stock movements, ledger lines, payment rows. A row of amounts and dates gives a question nothing to match against; indexing it only adds noise. Operations explains where object types come from.

Step 4 — Search in sentences, not keywords

Go to Search and ask the way you would ask a colleague: "what happens when a pallet arrives short", not "pallet short damage policy".

This habit takes the longest to form, and it is the entire point of the tool. Semantic search matches the meaning of your question against the meaning of the material, so the returns procedure comes back even when it never contains the word you typed.

You choose which of the three scopes to search:

• Platform — the product documentation for AxisIQ itself, searchable by everyone in your workspace. Ask "how do I add a field" and the answer arrives beside your own material, so setup questions need no second tab.
• Organisation — your collections and your indexed record types.
• Personal — your own notes, visible to you alone.

Personal scope is worth using from day one, for the notes you keep for yourself: what the supplier said on the call, the workaround for the machine that jams. Nobody else can retrieve it — personal scope is gated by ownership and nothing else.

Step 5 — Ask Axis, grounded in what you indexed

There is nothing to connect. Ask Axis can search the knowledge base as one of its tools, so once material is indexed the assistant draws on your documents and records rather than on what a model picked up elsewhere.

Test it with a question you would normally shout across the office; if the reply does not reflect your own material, the material is usually missing rather than the retrieval broken.

Nothing loosens because the asking happens through an assistant. It retrieves as you — your permissions, your results — so a colleague putting the identical question to it can legitimately get a different answer.

How permission works here, and what it does not decide for you

Indexing happens once, across the organisation. Seeing is decided at the moment you ask, on every individual result, against your own rights. Three gates, applied per hit:

• Documents are gated by the grants on their collection.
• Record snippets need your permission to read that record, and any field you are masked from is removed from the text before it comes back.
• Personal notes are gated by ownership, and nothing else opens them.

The practical effect: search returns only what you were already entitled to open, and that holds however large the pile gets.

What it will not do is judge sensitivity for you. Nothing reads a document and concludes it is confidential; the grants on its collection are the whole decision, which is why step one is about audience. Before you upload something you would not want circulated, check who can search that collection. Permissions covers how those grants are written and reviewed.

Where semantic search is the wrong tool

Semantic search complements record search; it does not replace it, and pushing it into the wrong job is how people conclude it "does not work".

Exact identifiers and filters belong to record search. INV-2026-0184, every unpaid order above ₹50,000 from last month, all customers in one city — those are exact questions with exact answers, and record search and filters answer them precisely where meaning-matching would only approximate.

The rule of thumb: if you know which record you want, use record search; if you know what you want to understand, use the knowledge base. "Which invoices are still open for this customer" is a record question. "How do we decide someone's credit limit" is a knowledge question.

Keeping it useful after the first week

• Replace superseded documents instead of adding a second version beside them. Two documents that contradict each other put retrieval in the position of refereeing, and it will not.
• Records look after themselves — they re-index on change.
• Revisit collection grants whenever someone changes role. That is the review that matters; the documents are less likely to drift than the audience is.
• If a search returns nothing useful, resist adding more files. Usually nothing written down answers the question, and the fix is a paragraph someone owes the team.

Setup in sequence — workspace, object types, imports, permissions — is in the getting started guide; the feature's full behaviour is on the Knowledge Base page.

FAQ

How do I build an internal knowledge base that our AI assistant will actually use? Create a collection, upload your documents into it, and turn on indexing for the record types that carry prose — Ask Axis then grounds its answers in that material. Retrieval runs with the asker's own permissions, so there is no second access list to maintain.

What do I need to set up RAG over our business documents? Material worth indexing — the embedding model is already set up on hosted AxisIQ. After that it is collections, uploads and a per-type toggle for records — no pipeline to build, and records re-index themselves after an edit.

Can a search result show someone a document they are not allowed to open? No. Permission is checked result by result while the search runs, so a collection you have no query grant on contributes nothing to what you see — not the text, not the file name.

Should we index record types as well as documents? Index the ones people write sentences into — customers, suppliers, products, jobs — and leave out the ones that are only numbers and identifiers. It is a toggle per object type, set by whoever manages the knowledge base and off until turned on; indexed records still pass your read permission and field masking.

How many collections should we create? As many as you have distinct audiences, and no more. Access is granted per collection, so one per group of people who should see the same material keeps the grants short; a single catch-all forces an all-or-nothing decision the first time something confidential arrives.