The first time you run PEDCO AuditPro against a freshly-connected repository, the platform is making its best guess at almost everything. It is guessing which files are controlled procedures and which are leftovers from a forgotten project. It is guessing which folder of records is operationally relevant and which is archived noise. It is guessing the shape of your QMS, the names of your top-level processes, and the vocabulary your team uses to talk about its work. The guesses are educated — they are informed by years of seeing what real QMSs look like, by hybrid retrieval, by classifiers trained on quality-management documents — but they are guesses.
The second time you run PEDCO AuditPro against the same repository, the platform should be making fewer guesses. By the fifth audit cycle, almost none. By the tenth, the platform should feel less like a tool you are configuring and more like a colleague who has been working alongside you the whole time.
That is not a vague promise. It is a concrete property of how PEDCO AuditPro is built, and it is anchored in four specific places in the app where the platform listens to you and remembers what it hears. This post walks through each of them, what it looks like on screen, what gets stored, and what changes the next time you run a sync, regenerate a profile, or kick off a fresh audit.
Where the learning happens
The four places where PEDCO AuditPro accumulates understanding of your QMS are:
- Document classifications — what each file in your repository actually is.
- Exclusion rules — durable filters you apply to whole classes of documents.
- The QMS profile — a structured description of your quality system, auto-generated and manually corrected.
- Audit-report overrides and pinned key documents — corrections to a published audit that feed forward into the next one.
Each one is a separate surface in the product. Each one persists. Each one is consumed by a specific downstream stage. Together they form a closed loop in which the platform proposes, you correct, and the corrections shape what the platform proposes next.
1. Document classifications — what every file actually is
When you open a repository's detail page and switch to the Classifications tab, you see one row per document in your corpus. Each row carries two AI-generated labels: a document type (qms_core, template_form, external_reference, project_artifact, training_material, or other) and a relevance rating (high, medium, low). Each row also carries a confidence score and, when the classifier was uncertain, a Needs review flag.
You can override either label on any document. The override is a first-class field on the document's classification record (userOverride), separate from the AI's original guess. The UI shows you both: the AI-generated label and your override, side-by-side, so you can see what you corrected and what you left alone. The override is durable across re-syncs and re-ingestions. When new files arrive and existing ones are re-evaluated, your overrides stick. The "effective" classification — the one used downstream — is the override when set, the AI's label otherwise.
What this changes downstream is significant. The knowledge graph is built from the documents that are classified as authoritative QMS content (qms_core and similar), weighted by relevance. Documents classified as training_material, external_reference, or other are indexed but treated as supporting material, not as a source of process definitions. Documents classified as project_artifact are kept in the repository for traceability but are not used to define what the QMS requires.
If the classifier originally tagged your "Risk Management SOP" as template_form because the file happened to look like one, your override turns it back into qms_core — and from that point forward, the SOP is treated as authoritative everywhere in the platform: in audits, in Copilot answers, in the QMS profile. You corrected one row, and the correction propagates.
The reverse is also true. If a vendor brochure that the classifier thought was a qms_core document is in fact marketing fluff, you reclassify it as external_reference. From that point on, it stops contributing to your audit evidence and stops influencing the Copilot's understanding of your process. The brochure stays in the repository — we never delete your files — but it stops being treated as something it isn't.
The reason this works as a learning loop, rather than a one-shot data-entry task, is the Needs review flag. When the classifier is uncertain — confidence below a threshold — the row is flagged. You can filter the table to just those rows, work through them, and either accept the AI's guess or correct it. The platform draws your attention to the cases where your input has the most leverage. You do not need to audit every classification; you need to audit the ones the platform itself is not sure about.
2. Exclusion rules — durable filters over whole classes
Some learning is not per-document — it is per-pattern. "We never want training materials in our audits" is not a hundred individual overrides; it is one rule. The Exclusion rules panel on the repository detail page lets you express exactly those rules and have them apply across the entire corpus, present and future.
A rule has a type, a value, and an optional path constraint. You can exclude by category (e.g. exclude all external_reference documents), by document type, by relevance (e.g. exclude all low-relevance documents from audit evidence), or by path (e.g. exclude anything under /archive/). The panel shows you a live count of how many documents the rule would affect ("dry-run count") before you commit it, so you can see the scope of the action you are about to take.
Once committed, the rule applies on every subsequent ingestion. A new file that lands in /archive/ next month will be filtered automatically. A new training slide deck that lands under Training/ will be skipped. The rule is durable, transparent, and editable: you can see all your rules in one place, and removing a rule restores the documents it was filtering.
This is the difference between teaching the platform once and teaching it many times. Classifications are how you correct individual misjudgements. Exclusion rules are how you express a policy.
3. The QMS profile — structured, auto-generated, manually correctable
The repository detail page has a QMS Profile tab. This is where the platform's understanding of your quality system lives as a single structured artefact. The tab shows two side-by-side blocks: the auto-generated profile, derived from the knowledge graph, and the manual override, which is yours to edit.
The auto-generated block is regenerated by a worker pass — you can see its generation status (pending, done, error) and the timestamp of the last successful generation. Under the hood, the profile is composed from communities and entities in your knowledge graph: top-level processes, sub-processes, roles, key documents, the vocabulary your organisation uses. It is the structured form of "what PEDCO AuditPro thinks your QMS looks like".
The manual-override block is a plain-text field that you maintain. Whatever you write there is layered on top of the auto-generated content and used downstream as the effective profile. There is no schema you have to learn — you describe your QMS in your own words, and the platform reads your description as authoritative.
This is the most important learning surface in the platform, because the profile is what the Copilot, the audit engine, and the QMS Companion read before they say anything. When the Copilot answers a question, it has the profile in its system prompt. When the audit engine evaluates a criterion, the profile is part of its context. When the QMS Companion answers a process question for a supplier or an employee, the profile is the lens it reads through.
The Regenerate button is here, too. If your corpus has changed materially — new SOPs, a major restructure, a folder reorganisation — clicking Regenerate runs a new pass against the latest knowledge graph and produces an updated auto-generated profile. Your manual override is preserved; the platform never overwrites your words with its own.
A subtle but important detail: the QMS profile is the artefact that turns PEDCO AuditPro from "a tool that reads documents" into "a tool that understands a quality system". A document is a string of words. A profile is a structured statement that the document control process is owned by Quality Assurance, that it governs SOPs DEV-PRO-001 through DEV-PRO-072, that those SOPs are reviewed annually, and that the records of that review live in a SharePoint folder called "Annual Reviews". That structured statement is the difference between an assistant that searches your documents and an assistant that knows your QMS.
4. Audit-report overrides and pinned key documents — corrections that feed forward
The fourth surface is in the audit report itself. When you review an audit and disagree with what the engine produced, you can override it. The override system covers:
- The numeric rating for a requirement
- The rating explanation — the prose justification the engine wrote
- Per-attribute ratings and explanations for the attributes of a requirement
- Recommendations added or removed by the reviewer
- Key documents — added (pinned) or removed from the engine's selection
Each override is stored as an AuditReportUserOverride record, scoped to a single requirement, and merged into the report at read time. The audit report you see in the UI is always the engine's output overlaid with your published overrides. You can see which fields are overridden, and you can revert them.
What makes this surface a learning loop rather than a one-off correction is the propagation path. When you trigger a new audit job against the same repository — for example, the next audit cycle, or a re-audit after a sync — the platform reads your published overrides and uses them to shape the new job.
The most consequential propagation is for pinned key documents. If you pinned a document on a requirement because the engine missed it, the platform force-includes that document in the retrieval pool for the same requirement in the next audit. The engine does not have to rediscover it; you told it the document is relevant, and it is now part of the evidence base. This is exactly what a human reviewer would expect: a correction made on one audit should make the next audit better, not the same.
The same forwards-feeding logic applies to other override types in increasingly direct ways: overrides on ratings and explanations are surfaced to the engine as priors when evaluating the next version, so the engine knows that a human reviewer previously came to a particular conclusion and can either confirm or explicitly disagree. The point is not to lock in the past — it is to ensure the platform does not keep making the same mistakes you have already corrected.
What ties the four surfaces together
These four surfaces are not independent features that happened to ship together. They are four points on the same loop:
- Sync and ingest — the platform reads new documents and classifies them. Your existing classification overrides and exclusion rules are applied. Documents flow into the knowledge graph filtered by what you have already taught the platform.
- Profile generation — the platform builds a structured QMS profile from the (filtered) graph. Your manual profile override is layered on top.
- Audit — the platform runs an audit using the profile and the graph. Your previous overrides and pinned key documents are honoured in the retrieval and rating stages.
- Review — you read the audit, override what is wrong, pin what is missing.
Each loop iteration sharpens the inputs to the next one. The classifications get more accurate as you correct them. The exclusion rules get more comprehensive as you spot patterns. The QMS profile converges toward your actual quality system. The audits draw on a cleaner, better-curated evidence base. By the time you have run two or three audit cycles, the platform's understanding of your QMS is no longer a guess at all — it is a recorded, structured, durable understanding that you have shaped at every step.
What we deliberately did not do
Two non-decisions are worth flagging, because they shape the trust story.
We did not build a black-box learning system. Nothing about how PEDCO AuditPro learns happens silently in the background where you cannot see it. Every classification override, every exclusion rule, every line of the QMS profile, every audit override is visible on screen. If you want to know what the platform has learned about your QMS, you can read it.
We did not train tenant-specific models. There is no per-customer fine-tuning loop in which your data flows into a model and changes its weights. Your overrides shape the prompts and the retrieval, not the model — a deliberate trade-off in favour of transparency and data-residency. Your data never leaves the boundary of your tenant.
Why this matters
Compliance work is one of the few domains where the cost of re-explaining yourself every time is enormous. Every consultant you bring in, every new auditor, every new tool — they all start by asking you to explain your QMS again. That repetition is one of the biggest reasons quality teams burn out and one of the biggest reasons compliance feels like a tax rather than a discipline.
The premise of PEDCO AuditPro is that the system you use day in and day out should not be one more thing you have to keep re-explaining. It should remember what you taught it last time, respect the corrections you made last month, and treat your manual profile override as the authoritative description of what your QMS is. It should never present you with a "needs review" classification that you have already reviewed twice, and it should never propose key documents you have already explicitly removed.
The four surfaces in this post are how that premise is implemented today. They are not the end of the story, but they are the foundation. Every override you make, every rule you write, every profile edit you commit, is a piece of your QMS the platform now knows. If you have not yet taken a tour through the Classifications, Exclusion Rules, and QMS Profile tabs of your repository — or the override controls inside your audit reports — that tour is the highest-leverage thing you can do this week.