Case study
A provincial electric utility in Manitoba with roughly 1,200 field and office staff needed straight answers from two decades of procedures, bulletins and agreements. We built a retrieval copilot that cites every source and honours existing access rights.
Named only with client approval Figures marked are illustrative Reply within one business day
Copilot · fine-tuned on your data
Live0.94
F1 score
86ms
Inference
12k/d
Requests
OlDevs built a retrieval based knowledge copilot for a provincial electric utility in Manitoba with roughly 1,200 field and office staff.Operating procedures, safety bulletins and collective agreement clauses were chunked and indexed in PostgreSQL with pgvector, and answers are generated by a large language model running inside the utility's own tenancy, so no content leaves their boundary. Every response cites the source document, section and revision date, and links straight to it. Permissions are read from existing Microsoft Entra ID groups at query time, and the first department was live in 6 wk.
Key facts
The challenge
Operating procedures, safety bulletins and collective agreement clauses lived across SharePoint, a document management system and two decades of PDFs, so answering a straightforward question often meant asking a colleague who had been there long enough to remember. Crews in the field gave up and phoned the control centre instead. Anything an assistant said had to be traceable to the document it came from, and staff could only ever see the documents their role already permitted.
The same procedure could exist in SharePoint, in the document management system and as a scanned PDF from an earlier decade. Nobody could tell at a glance which copy was current, so answers depended on which repository a person happened to search first.
Finding a clause usually meant asking a long serving colleague who remembered where it lived. That works until the colleague is on shift, on leave or retired, and it left newer staff dependent on people rather than on documents they could open themselves.
Field crews with a procedure question gave up on searching and phoned the control centre instead. Every call pulled someone there into a document hunt, and the answer given was verbal, unrecorded and impossible to check afterwards.
An assistant that produced fluent text without a citation was unusable in a safety setting, and one that surfaced restricted material to the wrong role was worse. Traceability and permission had to be properties of the system, not warnings in a footer.
What we built
OlDevs built a retrieval system over the utility's own document set, chunked and indexed in PostgreSQL with pgvector, with answers generated by a large language model inside the utility's own tenancy so no content left their boundary. Every response cites the source document, section and revision date, and links straight to it. Permissions are read from existing Microsoft Entra ID groups at query time, so the copilot retrieves only what the person asking is already cleared to open.
Content from SharePoint, the document management system and the PDF archive is parsed, split into passages that keep their section headings, and indexed in PostgreSQL with pgvector. Revisions are ingested as new versions rather than overwriting what came before.
Each response carries the source document name, the section it came from and the revision date, with a link that opens the original. A reader can check the passage an answer rests on instead of taking the wording on trust.
Group membership is read from Microsoft Entra ID on every query and applied as a filter before retrieval runs, so a person sees only material their role already permits. No second permissions model was created that could drift from the first.
The web interface was built to WCAG 2.2 AA, with keyboard access, readable contrast and text that scales, and tested component by component. Someone using a screen reader gets the same answer and the same citation as anyone else.
Process
Document and access audit
We mapped where procedures, bulletins and agreement clauses actually lived, which copies were current, and how existing Entra ID groups already described who could open what.
Retrieval prototype on real content
A first index over one department's documents let us test chunking, retrieval quality and citation formatting against questions staff genuinely ask, rather than against sample data.
Weekly demos with operations staff
Every week we showed working software to the people who would use it, and the questions they brought back set the next week's work on retrieval tuning and answer formatting.
Permission enforcement and review
Group filtering was wired in, then tested role by role with the utility's security team, including cases where a person's access changes between one query and the next.
Department by department rollout
The first department went live in 6 wk, then further groups were added as their content was ingested, with usage and unanswered questions reviewed at each step.
Stack
Retrieval and data
Language models
Identity and permissions
Application
Delivery and operations
6 wk
To first department live
−63%
Time spent locating policy answers
+41%
Weekly active internal users
Outcomes
Rather than waiting for the whole archive, one department's content was ingested and put in front of real users in 6 wk, which set the pattern for every group that followed.
Staff reported a fall in time spent locating policy answers, recorded as −63% Time spent locating policy answers, because the answer and its source arrive together.
Weekly active internal users grew, recorded as +41% Weekly active internal users, as departments were added and staff found the citations trustworthy enough to rely on.
Crews who once phoned the control centre for a procedure question now search the documents themselves, and they can see which bulletin the answer came from.
In their words
Our crews stopped phoning the control centre for procedure questions, and when the copilot answers they can see exactly which bulletin it came from.
Manager of operational readiness, provincial electric utility
Energy and utilities
FAQ
No. The index and the language model both run inside the utility's own cloud tenancy, so documents and questions stay within their boundary. Nothing is sent to a third party service for training or inference, and the ingestion pipeline reads from systems the client already controls.
Every response cites the document, the section and the revision date it came from, with a link that opens the original so a person can read the passage the answer rests on. Retrieval runs only over the utility's own document set, so an answer can always be checked against the source rather than taken on trust.
Group membership is read from Microsoft Entra ID at query time and applied before retrieval runs, so restricted material is never a candidate for an answer given to an uncleared person. Because it reads existing groups, access changes take effect without a separate permissions list to maintain.
Revisions are ingested as new versions rather than replacing what came before, and the revision date appears in every citation. That means an answer states which version it is based on, and superseded content can be excluded from retrieval while remaining available for reference and audit.
In this engagement the first department was live in 6 wk and the full build ran 5 months. You see a working demo every week from the start, so scope and quality are visible throughout rather than at the end. Request a quote and we will scope it against your own content.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.