Connected systems
Assure reads the audit trails of the site's lab systems and checks its Azure setup. It runs inside the customer's own Azure subscription, so no audit-trail data ever reaches Arithmia. It does not replace the eQMS: confirmed issues and the monthly evidence go into the site's own eQMS.
- Empower and Chromeleon (CDS)
- LIMS, MES, eBR (next)
- rosters, maintenance records
- confirmed flag → deviation draft
- monthly evidence pack
- file export when no connector
Sources
read-only; Assure never changes a source system| System | Type | Connection | Last event | Events | Open flags | In this demo |
|---|
Destination
- eQMS
- The site's existing eQMS, for example Veeva Vault QMS or MasterControl. The demo writes a deviation draft as a file; a live connector is a later build.
- Sends
- A deviation draft for each confirmed flag, with the events attached; the monthly evidence pack as a controlled record
- Approvals
- QA reviews and approves in the eQMS, under the site's own procedures and signatures
Azure deployment
Azure is not just where the review screen lives. The whole platform is installed from the Azure Marketplace into the customer's own subscription: ingestion, rules, AI models, review workspace and evidence ledger all run there. Arithmia ships signed software and never receives, stores or processes customer data.
What runs where
dashed border: inside the customer's Azure subscriptionCustomer site
1 · Ingest and store
2 · Check
3 · Review and prove
From install to first review
From the Azure Marketplace as a managed application in the customer's subscription. Their IT approves its permissions.
Arithmia's pipeline runs inside the customer's Azure Machine Learning workspace on their own history. QA validates and locks each model there.
New software, rules and base models arrive as signed releases. The customer's change control approves each one.
Screen share, or just-in-time access the customer grants for a fixed time. Every session is logged in their tenant.
A private offer on the Marketplace, billed on their Azure invoice. Eligible spend can count towards their Azure commitment.
Who holds what
| What | Where it lives | Held by |
|---|---|---|
| Audit trails, context, flags, decisions, evidence ledger | Customer's Azure subscription | Customer |
| Models in use (locked weights), training and test data | Customer's Azure Machine Learning workspace | Customer |
| Confirmed issues and the monthly evidence pack | Customer's eQMS | Customer |
| Software, rule library, training pipeline, base models on synthetic data | Arithmia's build environment and signed release registry | Arithmia |
| Billing figures (sites, events counted) | Azure Marketplace metering | Microsoft, reported to Arithmia |
One-week kit trial
- Day 0
- Install the trial package in the customer's own subscription, from a private Marketplace preview or the same Bicep package.
- Day 1
- Load one month of exported audit trails. Nothing leaves their subscription.
- Days 2–5
- Review the flags together by screen share. Specialists see what the customer chooses to show.
- Day 7
- Delete the install, or keep it for the paid service. The week's Azure running costs are the customer's.
Learning across sites (year two)
PlannedSites that opt in improve the base models together without sharing any data. Each trains locally in its own subscription; only clipped, noised and securely aggregated model updates leave, and a round runs only with three or more sites. Arithmia tests the combined base model and ships it back as a normal signed release. Each site's QA then validates its own fine-tuned version before a reviewer sees any score from it. Three sites are simulated in this demo's data, which is the starting point for that work.
Rule sources
Assure reviews each event the way an experienced reviewer would: against the site's rules, the approved records that explain activity, and who was allowed to do what. Sources the demo does not have yet are marked.
Cleared automatically
edits in analyses that were not flagged, each explained by a record| Cleared because | Events | Example from the data |
|---|
Rule library
versioned; a rule change is a controlled change with re-run tests| ID | Rule | Requirement (indicative) | Weight | Analyses hit |
|---|
SOP checklists
PlannedWhen a new SOP version is approved in the eQMS, Assure will read it automatically and draft one check per SOP step. QA approves the checklist once before it runs. Generative AI only drafts text for a person to approve; it never scores, clears or decides. This is not built in the demo: the rules above are the starting library.
Data input
Audit-trail exports are pulled read-only from the site's systems into the customer's own Azure subscription. Each source is parsed to one common event model, and every event keeps the hash of its original line. Nothing is changed in the source system.
Try an export
read in your browser; nothing is uploadedLoaded for this demo
synthetic exports from three simulated sites| File | What it is | Rows | Size | SHA-256 of the file |
|---|
Checks on load
By site
| Site | System | Events | From | To | Analysts |
|---|
Common event model
every source is mapped to the same record, so rules and models work across systems| Source column | Common event model field | Example |
|---|
First five events
What was read, by action
AI model (M1)
M1 learns what is normal for each site from that site's own history and scores every analysis for how unusual it is. It never decides: it ranks, explains and hands to a person. It runs next to the rules, never instead of them.
Model card
Demo model, not validated- Intended use
- Rank analyses of the SEC-HPLC aggregate result that are unusual for this site, so a reviewer looks at them first. A person decides.
- Method
- Isolation forest (300 trees) over 18 features of each analysis. Chosen because it needs no labelled violations.
- Trained on
- Each site's own audit-trail history, unsupervised. In a customer install this runs in their Azure Machine Learning workspace.
- Output
- A score as a percentile of the site's own history, and the top three factors behind it in plain words, from fixed templates.
- Locked
- Weights and settings are fixed and versioned. Retraining is a change: new version, revalidation, QA approval.
- Not used for
- Automatic decisions, clearing events, or anything without human review.
- Validation
- Not yet done. The build plan includes intended use, held-out test data and acceptance criteria agreed with the customer's QA.
By site
| Site | Analyses | Threshold | AI flags | AI only |
|---|
What M1 catches on its own
| Seeded case | Cases | M1 alone |
|---|
The rules cover what M1 misses. The T4 cases need a second layer.
Score distribution
analyses by percentile, log scaleWhat drives the score
average effect among the top 1%The 18 features
| Feature | What it measures |
|---|
Federated model
Sites that opt in improve a shared model together without sharing any data. Each site trains in its own Azure subscription and only clipped, noised model updates leave. This screen runs the whole process in simulation on the three sites in the demo data, with the labelled cases as the training signal.
Sites in the federation
opt-in, in writing; a round needs at least threeTraining rounds
| Round | Site A | Site B | Site C | Sent to Arithmia |
|---|
Size of each site's update before clipping. Arithmia receives only the noised sum, never one site's update.
Results
| Approach | What it needs | What leaves the site | Ranking quality (AUC) | Seeded cases in the top 2% |
|---|
What is shared, and what never is
| Never leaves a site | Leaves a site, protected |
|---|---|
| Audit-trail events, users, values, results | Model updates (changes to weights), clipped and noised |
| Context records: SOPs, change controls, rosters | Counts needed to weight each site's update |
| Flags, decisions, evidence | Health figures: training loss, drift, data volume |
After the rounds
Audit-trail review
Rules catch known data-integrity patterns; a model trained on each site's own history flags unusual analyses no rule covers. Every flag shows its reasons and the records checked. A reviewer decides and signs; a confirmed issue becomes a deviation draft for the eQMS.
Flags
Model health
demo model v0.4 · measured on synthetic seeded cases| Seeded case | Cases | Rules alone | AI alone | Together |
|---|
eQMS-first flow
Reviewers stay in the eQMS they already use. Assure works in the background: it raises one review task per batch of flags with the evidence attached, reads the decisions signed there, and learns from them. The eQMS on the left is a generic example, not a real product.
Set up the hand-off
Connection and mapping
What Assure sent
about eight fields, not the whole formSynced back to Assure
read-only: Assure never edits the eQMS recordWhy this shape
- One place to work
- Review, decision and electronic signature all happen in the eQMS, which is already validated and already holds the site's signatures. Assure keeps a hash-chained copy of what it sent and what came back.
- No flood of records
- One task per batch, not one deviation per AI flag. A deviation is created only when the reviewer confirms.
- Deep evidence
- The task carries a short summary and an attachment. A link opens the full timeline and context in a read-only Assure page with single sign-on, for the cases that need it.
- Learning
- Each signed decision comes back as a label for the next validated model version. Retraining stays a controlled change.
- Fallback
- With no connector, Assure still works: the task arrives as a document and decisions come back by file. Assure's own review screen remains for sites with no usable eQMS, and for the one-week trial.
Cloud controls
Twelve automated checks against the customer's Azure subscription. Each run is hashed, chained to the one before and written to a store nobody can edit or delete. Results here are simulated; the live checks come from Azure Policy and Defender for Cloud.
| ID | Check | Annex 11 | Part 11 | GDPR | Status | Action |
|---|
Evidence log
Evidence pack
Assembled from the evidence log and sent to the eQMS as one record. QA reviews and approves it there; Assure only produces it.
Contents
Send to eQMS
What it saves
QA time is the saving you can count; regulatory risk is usually why sites buy. Change the figures to match the site. They are illustrative until measured in a pilot.
QA review time
illustrative assumptions · replace with pilot measurementsFind it before the inspector does
Data integrity is a frequent cause of regulator findings. Checking every entry, with the evidence attached, lets the site show a working review process.
Faster batch release
Where audit-trail review sits in the release path, cutting it from hours to minutes can shorten release. The effect depends on the site; measure it in the pilot.
Nothing leaves your cloud
Because Assure runs in the customer's own Azure subscription, the supplier audit is about software quality, not about hosting customer data.
Mock-up for discussion. All sites, people, systems and events are synthetic. Flags, reasons and model figures are produced by the demo rules and model from synthetic audit trails; Azure installation, controls and the eQMS hand-off are simulated. Clause references are indicative and must be verified against EU GMP Annex 11, 21 CFR Part 11 and the UK GDPR before external use. Decisions are kept only in this browser.