Most AI assistants you have used in the last two years operate at roughly the same level of context: they read your last message, maybe a few messages above it, and search the open web or a generic knowledge base for an answer. That is a perfectly reasonable shape for a tool that has to be everything to everyone. It is the wrong shape for compliance work, where the question "does our document control process satisfy clause 7.5.3?" cannot be answered by anyone who does not already know what your document control process is, what clause 7.5.3 says in your standard's translation, and how the two have been mapped to each other in your QMS.
The new PEDCO AuditPro Copilot is built around a different assumption. Before it answers a question, it already knows your QMS. It knows the shape of your process landscape, the names you use for your top-level processes, the documents you treat as authoritative, the standards you audit against, the level of maturity you have achieved against each clause, and the way your team writes about its own work. It does not learn this every time you open a chat. It learned it during ingestion, it refreshes itself when your repository changes, and it carries that understanding into every conversation as the starting point.
This post explains what that means in practice: what the QMS profile is, how the knowledge graph backs the answers, how the Copilot adapts to the vocabulary of your organisation, and why the result is a class of recommendations that you cannot get from a generic chatbot pointed at the same document corpus.
What is the QMS profile?
When you connect a repository to PEDCO AuditPro, we do not just index its documents. We read them, we cluster them, and we build a graph of the entities they reference: processes, sub-processes, roles, controlled documents, control points, evidence types, and the relationships between them. From that graph, we derive a structured artefact we call the QMS profile.
The QMS profile is not a marketing summary. It is a machine-readable description of your quality system as it actually exists in the corpus. It captures, among other things, the top-level processes the organisation operates by, the sub-processes that compose them, the documents that govern each one, the responsibilities assigned to specific roles, and the vocabulary your organisation uses to talk about its own work. Two customers in the same industry, audited against the same standard, can produce two very different QMS profiles, and that is a feature, not a bug: their quality systems are different, and the Copilot needs to respect that difference.
The profile is regenerated automatically when the underlying knowledge graph changes — when documents are added, removed, or significantly revised. It is also surfaced in the UI so that a quality manager can read it, validate it, and override pieces of it. That manual override layer matters: there will always be a small number of facts about your QMS that are true but not yet documented, and a quality manager should be able to tell the Copilot about them without waiting for the next ingestion pass.
Why the profile changes the way the Copilot reasons
The Copilot uses the QMS profile in three distinct ways during a conversation.
First, it uses the profile as prior context. Before the Copilot reads your question, it has already read a compact summary of your QMS. That means questions like "is this covered by our document control process?" can be answered without the Copilot having to first search for what your document control process is — it already has a structured pointer to it. The same is true for "what does our risk management policy say about supplier qualification?" or "which of our SOPs apply to design verification?" — those are not retrieval questions, they are lookups against a structured profile.
Second, it uses the profile to disambiguate language. Different organisations use different terms for the same compliance concept. One customer calls it a "CAPA"; another calls it a "deviation report"; a third uses "non-conformity correction file". When you ask the Copilot a question that uses one of these terms, it does not silently treat your phrase as a generic English string and search for it. It resolves your phrase against the vocabulary in the profile, identifies the canonical concept in your QMS, and reasons in that concept's terms. This is the difference between a search that "kind of works" and an answer that lands.
Third, it uses the profile as a shape constraint when generating recommendations. If you ask the Copilot for suggestions on how to close a gap, the suggestions it proposes are bounded by the actual structure of your QMS. It will not propose creating a new top-level process when an existing sub-process is the right home. It will not propose a control type your organisation does not use. It will not propose a role that does not exist in your responsibility model. The result is recommendations that read like they came from someone who has already worked inside your QMS, because, structurally, they did.
The knowledge graph behind every answer
The QMS profile is the abstraction layer. Underneath it sits the knowledge graph that we build during ingestion. The graph is constructed using GraphRAG — Microsoft's open implementation of a graph-based retrieval-augmented generation pipeline — combined with our own hybrid search infrastructure. We chose this combination for a specific reason: pure vector search is great for "find me passages similar to this query", and pure keyword search is great for "find me passages that contain this exact phrase", but compliance questions almost always live at the intersection.
A question like "what evidence do we have that our purchasing controls are working?" is not really a semantic similarity problem, because "purchasing controls" is a precise term whose meaning you do not want re-interpreted. It is also not really a keyword problem, because the relevant evidence may use the words "supplier evaluation records" or "vendor approval logs" without ever saying "purchasing controls". And it is not really a flat retrieval problem at all: the right answer involves walking from purchasing controls (the policy) to the SOPs that implement them, to the records those SOPs generate, to the audit findings against those records.
The knowledge graph is what makes that walk possible. We extract entities (documents, processes, roles, control points, terms) and relationships (governs, implements, references, supersedes, is-evidence-for) from every document in the corpus. We cluster related entities into communities, generate summaries at multiple levels of abstraction, and store everything in a structure that the Copilot's tools can query directly. When you ask a question, the Copilot does not just look for similar text — it traverses the graph to assemble the right neighbourhood of evidence, then reads that neighbourhood end-to-end before responding.
A practical consequence of this is that the Copilot's answers cite the graph nodes they came from, not just the document chunks. You will see references like "your Design Control SOP (DEV-PRO-014) and the linked Design Review Records template" — the link between the SOP and the template is a graph edge, not a coincidence of search results.
Speaking the language of your QMS
A subtle but important property of the new Copilot is linguistic. It does not translate your QMS into a generic compliance vocabulary before reasoning about it; it reasons in your vocabulary, and only switches to standard-aligned terminology when it is actively helping you map your QMS to a clause.
This sounds like a small thing. In practice, it is the difference between an assistant that feels native and one that always feels slightly foreign. If your organisation calls its top-level process map a "Business Process Architecture", the Copilot calls it that too. If you say "the BPA", the Copilot understands. If your roles are called "Process Owner" rather than "Process Manager", every recommendation it generates uses the right title. If your CAPA system is called something else entirely, the Copilot will not silently rename it in its responses.
We chose this approach because mismatched vocabulary is one of the most common reasons quality managers stop trusting AI assistants. When an assistant uses generic terms, the user reads every answer through a translation layer, and the cost of that translation accumulates over a conversation. By the third or fourth answer, the user is mentally exhausted from re-mapping and starts double-checking everything. By making the Copilot speak the language of the QMS natively, we eliminate that translation layer.
The vocabulary used by the Copilot is drawn from the actual corpus during profile generation, with light normalisation for spelling variants and obvious typos. It is not curated by hand. This makes it scalable across customers and resilient to the fact that no two QMSs ever use exactly the same terms.
Deeply context-relevant recommendations
The most common feature request we have heard since the Copilot launched is "give me better recommendations". What people mean by that, when you press, is rarely "give me more creative ideas". It is "give me recommendations that I can actually act on tomorrow".
A recommendation is actionable when three things are true: it names a concrete artefact that exists in the QMS or could plausibly be created within it, it cites the specific evidence that drove the recommendation, and it is sized to the user's actual scope of authority. Generic AI assistants struggle on all three. They will recommend creating a "documented procedure" without naming where it would fit. They will cite "industry best practice" instead of the specific paragraph in the user's own corpus. And they will propose enterprise-wide initiatives in response to questions about one team's process.
The context-aware Copilot gets these right by construction. When it generates a recommendation, it pulls the concrete document hierarchy from the profile, so it can suggest "extend SOP DEV-PRO-014 section 3.2" rather than "create a new procedure". It pulls the evidence from the knowledge graph, so it can name the specific records, paragraphs, or audit findings that motivated the recommendation. And it pulls the scope from the conversation context — including, in the audit reports area, the specific clause or sub-process the user is looking at — so it does not propose a corporate-wide restructure when the user is reviewing a single requirement.
Recommendations also carry an explicit justification and an explicit impact. The justification is the chain of evidence; the impact is what the recommendation is expected to change about the compliance posture. Both are required, both are surfaced in the UI, and both are exportable into the audit report. The intent is that a quality manager reading a recommendation should never have to ask "why is the Copilot telling me this?" — the answer is already on the page.
How it shows up in the product
The context-aware Copilot lives where the previous Copilot lived: in the right-hand pane of the PEDCO AuditPro app, available from any page. From the user's point of view, you do not have to do anything different to get the new behaviour — when your repository has a QMS profile, the Copilot uses it automatically. When you select a repository from the source picker, the Copilot focuses on that repository's profile and graph. When you are inside an audit report, the Copilot picks up the current clause and sub-process as additional context and threads them into the conversation.
For embedded use cases, the same context-aware engine powers the QMS Companion — our embeddable widget that lets you expose a process-library chat experience to employees who do not have PEDCO AuditPro accounts, suppliers being onboarded, intranet portals, or your own product surfaces. The companion sees the same QMS profile and the same knowledge graph as the in-app Copilot, but its scope is narrower (single library, no tool calls, no write actions). It is the same conviction in a smaller container: the assistant should already know your QMS before it answers.
What this changes for our customers
The headline change is one of trust. A quality manager who has used the old Copilot will notice that the new one rarely asks them to clarify which process they are talking about, because it already knows. A reviewer working through an audit will notice that the recommendations cite specific documents and clauses, not generic best practices. A new hire onboarding to the QMS will notice that the Copilot speaks the same language as the SOPs they are reading, which makes the SOPs themselves easier to understand.
The headline change for us, internally, is one of architecture. The context-aware Copilot is not a prompt-engineering trick; it is a different runtime. The QMS profile, the knowledge graph, the vocabulary resolution, and the recommendation shaping are all first-class components of the system. Each can be improved independently, each is observable, and each gets better as more data flows through it. We expect the next year of Copilot improvements to be driven not by larger models but by deeper context — and the foundations to do that work are now in place.
If you have a QMS that the Copilot does not yet speak fluently, that is the bug we want to hear about. Reach out, tell us what term it got wrong, and we will use it to make the next answer better.