Regulatory Checks

The Regulatory Checks page is the InnoQualis EQMS compliance command center. It pulls together every regulator change that the platform is monitoring on your behalf, runs each change through an AI gap analysis against your live documents, and surfaces the findings here so quality teams can decide what to do — without leaving the page.

Who uses it

Role	Access	Typical action
Admin (Quality Manager / Quality Lead)	Full	Reviews findings, approves change requests, configures the standards registry.
QA_Team	Full	Triages new findings, opens change requests, drafts new document versions.
Auditor	Read-only	Inspects findings + actions taken (audit-trail context).
User	No access	The page requires the `compliance.read` permission, which is not granted by default to the User role.

The page is reachable from the left sidebar under the Quality group as Regulatory Checks. Direct URL: /regulatory-checks.

What you see

The page has three sections stacked vertically:

1. Dashboard cards

Five summary cards across the top:

Compliance Score — percentage of tracked findings that are already closed out (accepted or resolved). Colour-coded green / amber / red. Until at least one finding is tracked the card shows — with “No findings tracked yet” rather than a score.
New Updates — total regulator changes visible to your tenant. This counts both your own monitored feeds and the platform-wide feeds (see below), so it always matches the Regulatory updates list underneath it.
Pending Findings — open impacts awaiting a QA decision.
Resolved This Month — findings closed in the current calendar month.
Avg Response Time — average days from when a finding was raised to when it was closed.

Below the cards, a Source monitoring badge summarises the health of your tenant’s regulator feed polling: a green pill when every source’s last poll succeeded, amber if any source has gone stale (no successful poll for more than twice its check interval), and red if a source’s last poll failed outright or the polling scheduler itself is stopped. Hover the badge for a breakdown (ok / needs attention / pending first check). The badge is silent (renders nothing) rather than showing an error if the status itself fails to load — a monitoring widget failing shouldn’t look like a monitoring alarm.

2. Regulatory updates

The regulator changes the AI Compliance Officer is watching, newest first. Each row shows the change’s title, its severity, its workflow status, and when the regulator published it.

Where these come from. Two kinds of feed produce them:

Your own feeds — the regulators you selected during signup, plus any added later from the Standards & Regulations admin tab.
Platform feeds — a shared set (EMA, MHRA, and EUR-Lex today, plus EMA/ICH news and the UK/EU catalogue watches: ICH Quality Guidelines, EudraLex Volume 4, EU Harmonised Standards (MDR), UK Designated Standards, PIC/S Publications, and CEN and CENELEC news) that InnoQualis polls centrally on behalf of every tenant. Their rows are labelled Platform feed. They are read-only: you can read and assess them, but you cannot pause or reconfigure a feed that every tenant shares. To change polling behaviour for your own tenant, add your own feed with its own URL instead.

The signup wizard’s regulator picker and the Standards & Regulations tab intentionally do not offer FDA — InnoQualis is not currently selling into the US market, so FDA is not part of the platform’s regulatory catalogue. If your organisation needs FDA coverage, contact support.

Run assessment. Each row carries a Run assessment button that maps that regulator change onto your controlled documents on demand, rather than waiting for the next scheduled poll. It requires the compliance.regulatory_review permission; viewers with only compliance.read see the list without the button.

The assessment runs in the background, so the button first reports queued, then running. The page follows the run and tells you how it ended:

Assessment complete — N findings added to the list below. The run finished and created findings. They appear in the findings table without a reload.
Assessment complete — no impacts found across N documents. The run checked every document it matched and genuinely found nothing to flag. This wording appears only for a run that both finished and assessed everything it matched.
Assessment incomplete. The run returned, but did not check every matched document — the AI service was unavailable, some documents errored, the run hit its token budget, or nothing could be matched to compare against. Any findings shown are real but the list is not complete, and this is not a “no impacts” result. Run it again.
Assessment failed. The run stopped before it finished, with a short reason (an AI service that could not be reached, a timeout, or data that was not ready). No findings were recorded — this is not a “nothing found” result, and you should run it again.
Assessment queued, but its progress can’t be tracked right now. The run was accepted but the page could not read its status. Reload the page to see any findings it produced.

That distinction is deliberate and load-bearing: “no impacts found” is a statement you may rely on when evidencing that a regulator change was reviewed, so the page shows it only for a run that completed and covered everything it matched. Anything less says so plainly instead of quietly looking like a clean result.

Running an assessment again on the same update is safe: results already produced for a document are not duplicated.

Every finished run is written to the audit trail against the regulatory update — assess_completed, assess_incomplete or assess_failed — so a run that ended while nobody had the page open is still discoverable afterwards, and a completed assessment can be evidenced positively rather than inferred from the absence of an error.

If the list is empty, the page says which situation you are in, because the fix differs:

No regulatory feeds are being monitored yet — nothing is being watched at all, so there is nothing for the AI Compliance Officer to read. Admins get a link to the Standards & Regulations tab; everyone else is told to ask an administrator.
No regulator changes published yet — feeds are active and healthy, the regulators simply have not published anything since the last poll. This is a normal state and needs no action. The count here is of active feeds only; a paused feed is not being monitored and is not counted.
No regulator changes to show — the page could not establish which feeds are monitored (the request failed or is still in flight), so it does not guess. Refresh; if it persists, contact your administrator.

3. Findings table

A filterable, sortable, paginated list of findings. Each row shows the affected document, the impact type, a short gap description, the severity (critical / major / minor), the AI confidence score, and the current status.

Available filters:

Severity — critical, major, minor, or all.
Status — pending, accepted, rejected, deferred, resolved, or all.
Standard gating — actionable, pending purchase, not applicable, or all.
Min confidence — slide the threshold to hide low-confidence AI findings.

Page size: 10 / 25 / 50 / 100. The default is 50; the platform hard-caps a single request at 200.

Analyse a document

The Officer scans on a schedule. Analyse a document is the same capability on demand — use it when you want a document checked now, typically before sending a draft for approval.

On the left sidebar, select Regulatory Checks.
Scroll to the Analyse a document panel.
In the Document field, start typing a title or document number, then pick the document from the list. Only documents in your own organisation appear.
Under Analysis type, select one of:
- Compliance check
- Quality review
- Risk assessment
Select Analyse document.
The result appears below the button, with a risk estimate, a summary, findings, and recommendations.

The analysis is saved to the document. Open the document and select its Regulatory tab to read it again — every analysis is listed there, newest first, showing which AI model produced it and which document version it ran against.

Running an analysis requires the compliance.regulatory_review permission (QA_Team and Admin by default). Reading saved analyses requires compliance.read, so Auditors can review what was run. Each run is written to the document’s audit trail.

If a document has no readable text, the analysis is refused rather than run against nothing. Uploaded files must be text or PDF; for other formats, put the content in the in-app editor first.

Drill into a finding

Click any row (or its Expand button) to open the split-layout detail:

Left column — the affected document content with highlights. Yellow marks identify non-compliant text, red marks identify missing content, green marks identify suggested additions. Click a highlight to scroll the gap analysis to that range.
Right column — the gap analysis: the regulatory reference (standard + clause), a plain-language gap explanation, a current → suggested diff, an effort estimate badge, and four action buttons.

If the underlying document is a binary file (PDF, Office) rather than rich-text, the left column shows a download link instead of the highlighted preview. The gap analysis still applies — the highlighting overlay for binary files will land in a follow-up release.

Four ways to act on a finding

The right column always exposes four action buttons. They write to the audit trail under the user’s identity, so the chain of evidence for the decision is preserved.

Action	What happens	When to use
Create Change Request	Files a Change Control pre-populated with the AI gap analysis, links the affected document, and flips the impact to `accepted`.	The change is non-trivial and benefits from the formal Change Control workflow (impact assessment, approvals, training).
Create New Version	Cuts a new draft `DocumentVersion` with the suggested wording applied at each highlighted range. The draft enters the normal approval workflow before becoming effective.	The change is small, the suggested wording is correct as-is, and a Change Control feels heavy.
Reject	Closes the finding as not applicable. A rejection reason is required (21 CFR Part 11 needs a written justification on every decline).	The AI’s reading is wrong, or the finding does not apply to this document.
Defer	Postpones the decision. A reason is optional.	The finding is valid but the team needs more time (e.g. waiting on a related change).

Both Create Change Request and Create New Version are idempotent — calling them twice on the same impact returns the existing record instead of creating a duplicate.

When a finding references a standard your tenant has not yet activated (purchased), an amber Standard Gating banner appears above the gap analysis, and the Create Change Request / Create New Version buttons are disabled. The banner links directly to the Standards & Regulations admin tab where an Admin can activate the missing version. Reject and Defer remain enabled so you can still close out a gated finding if it’s not applicable to your operation.

Permissions reference

The page requires compliance.read. Without that permission the user is redirected back to the dashboard.

To act on findings, the user additionally needs:

compliance.regulatory_review to use Run assessment
change_control.create to use Create Change Request
documents.update to use Create New Version

These are the same permissions used elsewhere in the platform — the regulatory page does not introduce new permission strings.

Historical backfill (operations only — no in-app control)

By default, every platform feed is capture-forward: a feed’s row list starts filling from the moment InnoQualis activates it, not from the regulator’s full history. A tenant that onboarded recently sees a shorter Regulatory updates list purely because of when the platform started watching, not because a feed has been quiet.

backend/scripts/backfill_regulatory_history.py is an operator-run command-line tool (there is no button for this in the app) that pages further back into a source’s own history and ingests it through the same validation and de-duplication path as the hourly poll — so re-running it is always safe and never creates duplicate rows. It supports the ICH, MHRA, FDA, and EMA platform feeds; EUR-Lex is included but capped at whatever its live feed currently holds (its predefined feeds aren’t independently paginated) — a deeper EUR-Lex history is tracked as follow-up work (see docs/gaps.md GAP-515). FDA’s extractor is reachable and tested, but has nothing to persist into today: FDA is not part of the platform’s regulatory catalogue (self-service selection is retired — see docs/gaps.md GAP-530), so a real FDA backfill run reports the source as missing rather than writing anything.

What it deliberately does not do, even when an operator runs it:

It does not run an AI gap analysis, send a notification, or queue anything for embedding — backfilled rows appear in the Regulatory updates list exactly like any other row, but nothing about their arrival triggers the usual “new update” side effects. Assess them the normal way, on demand, via Run assessment.
It does not add a new regulator feed or change which feeds your tenant sees — it only fills in more history for feeds that are already active.
It is dry-run by default in this platform’s operational process: an operator first confirms which sources are reachable and roughly how far back they go before writing anything.

If you notice a platform feed’s history suddenly extends further back than before, that is this tool having been run on your behalf — nothing on your end needs to change.

Resumable, scheduled, and self-limiting (GAP-531)

The backfill is not a single giant run. Each invocation — whether an operator’s manual CLI call or the hourly scheduled job — processes a bounded slice of one source (--budget-items, default 200; --budget-seconds, default 300) and then stops, saving exactly where it left off. A per-source checkpoint (position, oldest date reached, and whether the source is fully caught up) lives on the feed’s own configuration row, so nothing is re-fetched that a previous run already reached.

A feed is marked fully caught up — and skipped entirely on every later run, at zero request cost — once one of three things happens: paging reaches the requested start date, the source’s history runs out, or several pages in a row turn up nothing new (everything on them was already captured). An operator forces a feed to start over from scratch with --restart.

Once turned on (REGULATORY_BACKFILL_ENABLED, off by default — an operator opts in), the platform runs this automatically once an hour for every feed that supports it and isn’t yet fully caught up, using the same bounded-slice, rate-limit-friendly approach as a manual run (REGULATORY_BACKFILL_SINCE sets how far back it should go, defaulting to 2020-01-01). It never runs at the same moment as the hourly “check for new updates” poll for the same feed — they share a short-lived hand-off so one always waits for the other.

Standards & Regulations (admin) — activate the standards your tenant should be checked against.
Change Control — what happens after Create Change Request.
Document Control / Versioning — what happens after Create New Version.