Knowledge systems that answer and cite their sources.
Ask a question, get a grounded answer with the source attached, drawn from the manuals, policies, wikis and tickets your company already has. The same retrieval pipeline powers site search, support tooling and internal assistants, with your permissions respected.
Reply within four business hours (typical) · Permissions-aware by design
In one answer
PixelCrayons builds knowledge systems: ask a question in plain language, get an answer drawn from your own documents, with the source attached. The system finds the relevant passages in your documentation first, then writes the answer from them; the industry calls this retrieval-augmented generation, or RAG. It only shows people what they are already cleared to see, and we test it against real questions before launch. Pilots run direct or white-label.
A knowledge system isn't a chat window. It's the retrieval layer underneath. We build the pipeline once, over your documents, and expose it wherever questions actually get asked: site search that returns answers instead of links, a lookup inside your helpdesk so agents stop hunting through folders, and internal assistants in Slack or your intranet. If a customer-facing chat surface is the goal, that's our chatbot service, running on this same layer.
The architecture
02
Citations by design
Every answer names the documents it came from (clause, page or ticket), so a human can verify it in one click instead of taking the model's word. When retrieval comes back empty or contradictory, the system says so rather than improvising. No source, no answer: that rule is enforced in the pipeline, not requested in a prompt.
Every answer
03
Permissions-aware retrieval
The pipeline inherits your existing access model (SSO groups, folder permissions, workspace boundaries), so retrieval simply never touches documents a user isn't cleared to see. The board pack doesn't surface to a contractor because a query was phrased cleverly; it was never in their index. Access decisions are logged, and every query is auditable after the fact.
Every build
04
Evaluation before launch
Before anyone relies on it, the system runs against an evaluation set built from questions your team actually asks, measuring whether the right documents are retrieved, whether answers stay grounded in them, and whether the must-refuse cases refuse. You see the scores and sign off on launch. The suite re-runs whenever the documents change, so quality is measured, not assumed.
Before launch
05
Documentation that stays current
Documentation changes weekly; a knowledge system that indexed it once is stale by month two. Scheduled re-indexing picks up changes to your sources on a timetable you set, flag documents that contradict each other, and surface the gaps people keep asking about. That gap list is a documentation roadmap in itself. At handover your team gets the runbook. Your materials remain yours. Bespoke deliverable rights, licences and handover are agreed before work starts.
At handover
Where answer quality is actually decided
Almost nothing that goes wrong here is the model’s fault.
An internal assistant is a pipeline with a model near the end of it. When the answers are vague, stale or quietly wrong, the cause is usually three or four stages upstream, which is why “try a better model” so rarely changes anything.
Ingest: runs on a schedule
01
Sources
The documents, tickets, policies and wiki pages that count as the truth.
What breaks here
Nobody owns the corpus, so it silently goes stale and the assistant confidently answers from last year’s policy.
02
Chunking
Documents are split into passages small enough to retrieve and large enough to mean something.
What breaks here
A split in the wrong place separates a number from its heading or a step from its warning. The passage is still retrievable. It is just no longer true on its own.
03
Permissions
Each passage carries the access rules of the document it came from.
What breaks here
Applied after retrieval instead of during it. The answer looks filtered while the model has already read what it should not have.
The index
The only thing the assistant can see. Nothing outside it can be answered from, and everything inside it can be, which makes the index the security boundary, not the prompt.
Query: runs per question
04
Retrieve
The question is matched against the index, inside the asker’s own permissions.
What breaks here
Retrieval tuned only for similarity returns four passages that all say roughly the same near-miss, and none that answer the question.
05
Ground
The model is given the retrieved passages and instructed to answer only from them.
What breaks here
No rule for the empty case. Asked something the corpus does not cover, the model answers anyway: the single failure that destroys trust in an internal tool.
06
Cite
The answer links back to the passages it came from, so a reader can check it in one click.
What breaks here
Citations that point at a whole 40-page document. Technically sourced, practically unverifiable.
Ask any vendor where permissions are enforced. If the answer is “we filter the results”, the model has already read the document it was not allowed to read.
Illustrative pipeline: stages are ours, not a vendor reference architecture
The pilot
From scattered documents to cited answers.
01
Days 1 to 3
Documents & question audit
We map where your knowledge actually lives, audit its structure and permissions, and collect the real questions the system must answer: the seed of the evaluation set.
02
Week 1
Pilot scoped & priced
A written scope lands: the sources in bounds, the surfaces served, the permission rules and a demo date. You approve the itemised price before code ships.
03
Pilot
Working pilot, your documents
You're querying a working pilot built over your own documentation: answering with citations, refusing without sources, respecting your permissions.
04
Weeks 3 to 6
Evaluate, permission, launch
The pilot runs against the evaluation set, permission edges are tested deliberately, ingestion goes on a schedule and your team learns the runbook. Then it opens to real users.
Inside Prism
Your engagement, week to week, in one workspace.
Where the engagement includes it, your AI build runs in a Prism workspace you log into: requests, approvals, the task list and the weekly review, with each decision and its expected result written down.
The eval scorecard, before the pilot goes near a customer.
What you receive in month one
AI work is reported against an evaluation set built before any model is chosen. In the first month you receive the task definition with the inputs and acceptable outputs written down, the eval set of real cases with expected answers, and the scorecard showing accuracy, refusal behaviour and cost per run. The go/no-go checklist names what must hold before the pilot touches live traffic.
01Task definition: inputs, acceptable outputs, and the cases the system must decline
02Eval set: real cases with expected answers, reviewed by your team
03Scorecard: accuracy, refusal behaviour, latency and cost per run
04Go/no-go checklist: the thresholds the pilot must meet before launch
05Failure log: each wrong answer, its cause, and the fix applied
Put a conversation on top of an AI-powered knowledge base and it is a chatbot. Feed its retrieval into a workflow and it is automation. Start wherever the pain is, or start at the hub.
Each one says where it applies and links to its full terms.
Response and start times
We typically respond within four business hours. Eligible engagements can typically start within two to three business days after scope, payment and required access are confirmed.
Business hours are Monday to Friday, 9:00 am to 6:00 pm IST, excluding published company holidays. Typical expectations, not guaranteed service levels.
Every delivery is reviewed before release by QA, your Project or Account Manager and a senior delivery lead, and you then review it against the acceptance criteria agreed at the start. Our specialists use AI to support delivery, with people responsible for reviewing the work. Applicable development work includes 30 days of corrective maintenance after production launch.
Who owns the ad accounts, the data and the work?
Your materials, data and accounts remain yours, and we prefer to work in advertising and analytics accounts you own, with access delegated to our team. Agreed ownership rights in bespoke deliverables transfer under the engagement terms and applicable payment; third-party software and assets keep their licences. We do not withhold customer-owned data or accounts over a payment dispute.
What if we want to stop?
Cancellation, notice and any renewal terms are written into your proposal or statement of work before you accept it. If an engagement ends early, we hand over completed, paid-for work and list any unfinished work separately. For an eligible specialist trial, you can stop within the trial window and pay nothing for eligible trial hours.
How will we know what you are doing?
Before work starts we agree how often you get updates, what the reports cover and who sends them. You know who coordinates your engagement, who owns the work and how to escalate an issue. For hourly and retainer work, time is recorded in Workstatus, so you can see the time records behind your invoice.
Retrieval-augmented generation keeps your knowledge in your documents and teaches the system to look things up. A query retrieves the relevant passages, and the model answers only from what was retrieved, citing it. Fine-tuning (baking your data into the model's weights) is the wrong tool for facts: it's expensive to update, impossible to cite, can't respect per-user permissions, and confidently blends what it half-remembers. With retrieval, updating the system means updating a document; removing access means removing a document from someone's index. Where fine-tuning tone or format earns its keep, the discovery document will say so.
A chatbot is a surface; a knowledge system is the machinery underneath. Our chatbot service ships a conversation, typically customer-facing, on a support or sales queue, with escalation rules and helpdesk integration. This service builds the retrieval layer itself, and chat is only one of the places it shows up. The same pipeline can power site search that answers instead of listing links, a lookup panel inside your agents' helpdesk, and internal assistants for HR, finance or engineering questions. If what you need is a support chatbot, start there. It stands on this layer anyway. If several teams keep asking questions of the same sprawling documentation, start here and add surfaces as they earn their keep.
Any system with a language model in it can, and no vendor can promise zero. What a well-built knowledge system changes is the failure mode: answers are generated only from retrieved passages of your own documentation, every answer carries its citations so a human can check it in seconds, and when retrieval comes back empty or the sources disagree, the system says exactly that instead of guessing. Before launch it runs against an evaluation set built from your team's real questions (grounding and refusal cases included), and you see the scores before sign-off. After launch, every query and answer is logged. Honest answer: not zero errors, but rare, visible, checkable ones.
Access control is designed into retrieval, not bolted onto the interface. The pipeline inherits your existing model (SSO groups, drive and folder permissions, workspace boundaries), so a query only ever searches the documents that user could already open. Confidential material isn't filtered out of an answer at the last moment; it was never retrieved. Every query is logged and auditable, work runs under NDA as standard, and where you need it the whole system deploys inside your own cloud so nothing leaves your infrastructure. We also use enterprise API terms under which providers don't train on your data. Retention, residency and access rules are agreed in the scope document before anything is indexed.
Usually yes, and the audit will say where not. Messy-but-real documentation (dated policies, overlapping wikis, tickets that contradict the manual) is the normal starting point. Part of the build is triage: which sources are authoritative, which are stale, and which contradict each other (the system flags these rather than averaging them). What retrieval cannot fix is knowledge that was never written down. Where the audit finds those gaps, you get a prioritised list of the questions people actually ask that no document answers, which tends to be the most useful documentation roadmap a team has ever received. We'd rather scope a smaller set of documents that answers well than a sprawling one that answers plausibly.
It depends on the documentation, the permission model and the surfaces served, which is why we don't quote from a rate card. Every engagement opens with a scoped pilot: one body of documentation, one surface, your own questions as the evaluation set, priced as a small, defined build. The proposal you receive itemises what ships, including sources indexed, permission rules enforced, evaluation included, and what handover looks like. Extending to more sources or surfaces is priced per step, only after the pilot has proved itself on your own questions.
Something we build over your own documents and hand over. One retrieval pipeline serves site search, a lookup inside your helpdesk and internal assistants, with your existing permissions respected. At handover your team gets the runbook. Your materials remain yours. Bespoke deliverable rights, licences and handover are agreed before work starts.
Scope a pilot: one body of documentation, one surface, a working knowledge system with citations on every answer, your permissions respected, and evaluation before anyone relies on it.
