Built on LotWarden's platform, validated the same way, and every record signed.
EQAWarden reuses LotWarden's security platform unchanged where it can: the network guard, the hash-chained audit log, the request guards and the sealed store. On top of it sits a review record designed to be reproduced years later, three reports written for an assessor, and change control that names the version of every part.
The controls IT already approved for LotWarden.
The ten-minute checklist on the LotWarden security page applies to EQAWarden as well; the modules are the same files.
Network guard
Loads before anything else and wraps the socket layer. Only loopback is permitted; every blocked attempt is written to a network audit log with a timestamp. No AI, no cloud, no web fonts, no CDN: the fonts ship in the folder.
Request guards
Every request must carry the local host header, which defeats DNS rebinding. Every write is refused unless it comes from the page itself, and a refusal is audited. Downloads are confined to the exports folder by resolved path.
Hash-chained audit
Imports, mappings, settings, link switches, exports and sign-offs are appended with the Windows user, the timestamp and a SHA-256 chain value over the record before. The chain is verified on every start and its state is shown in the banner.
One running copy
A second copy on the same PC is refused, so two people cannot write to one store at once.
Preview before write
Nothing is stored until a person has seen it and confirmed it. Re-imports archive what they replace; nothing is ever deleted.
Plain-English house rules
Sentence case, Australian spelling, dates as day, month, year, no em dashes on screen or in reports, and every refusal says what to do next. Fictional data is always marked DEMO or TEST.
Laboratory data encrypted at rest, with the key beside the app.
Results, IQC, events, lots, reviews, mappings, layouts, APS rows and settings are collections of sealed JSON, encrypted with AES-256-GCM under a key file kept beside the program. The key never enters the source repository. Writes are atomic, and a replaced document is archived rather than overwritten.
Back up the folder and keep the key with it: without the key the sealed data cannot be read, which is the point.
The audit logs, so they can be checked without the key.
The audit log and the network audit log are plain, tab-delimited text with their chain values in the open. An assessor can verify the chain with nothing but the file. The status page reports the number of records and whether the chain is intact, and names the record where it breaks if it ever does.
The human record, designed to be reproduced years later.
A review is scoped to one analyte on one instrument for one survey. It records what the reviewer decided, what the engine suggested at the time, and enough to show the same assessment again.
| Scope | Programme, cycle, survey, analyte and instrument |
|---|---|
| Assessment digest | A SHA-256 of the engine output the reviewer saw, with the engine and knowledge versions that produced it. An assessment is computed as at its survey, using results up to and including that survey only, so it can be recomputed and compared |
| Suggested and recorded | The outcome EQAWarden suggested and the outcome the reviewer recorded, side by side. They are allowed to differ, and the difference is part of the record |
| Cause, conclusion, actions | The cause the reviewer chose, a free-text conclusion, the actions taken, and a QMS reference for the nonconformity where one was raised |
| Status | Open while an investigation is under way, closed with the sign-off. Every change is appended to the record's own history with who and when |
| Signature | Initials and role, validated before anything is written, and the sign-off appended to the hash-chained audit log |
The reviewer previews the record exactly as it will be written before signing. Nothing is stored on preview.
Three reports, each written in three forms that say the same thing.
Each report is built once as a plain report object and written as a workbook, a printable page or a Word document. Every export needs initials, is written to the exports folder only, carries its SHA-256, and is audited.
Survey record
Every result with its expected result, target source, group size, difference, APS, APS score and assessment; the outcomes by analyte with the reviewer's outcome, cause, conclusion, actions and QMS reference; survey findings, findings by analyte, suggested actions, interpretation and the method groups.
Cycle summary
Performance by analyte and instrument over the cycle: results scored, within, warning and outside, mean and largest APS score, the most serious suggested outcome, beside the series statistics to date. Results outside the APS with their reviews, trend flags, and a chart.
NATA evidence pack
For a date range: within-APS percentage, results outside and how many were reviewed, surveys fully reviewed, reviews open and closed, median days from report to review, corrective actions. Registers of surveys, reviews and corrective actions, EQA by lot, and the audit trail's integrity.
Forms. The workbook puts the record block first and one sheet per table, with coloured headers, filters, frozen panes and print titles, real Excel dates and numbers as numbers. The printable page is a single self-contained file that fetches nothing from anywhere. The Word document is landscape A4. A report built from demo data says DEMO on every form.
Seven versioned sections, and a rule for what a version bump means.
Every copy identifies its release, the version of each section and the commit it was built from, in the footer and in every audit record. Until a release baseline is recorded, every copy says UNRELEASED where it identifies itself.
| Importers | Reading EQA results, Unity Real Time exports and lot files: formats, header synonyms, layouts taught once, and mapping to analytes, instruments and products |
|---|---|
| Engine | Statistics, scoring against the APS, pattern detection, lot and IQC linkage, interpretation, suggested outcomes and the review routes |
| Knowledge | The rules, causes, analytes, programmes, units, APS defaults and references the interpretation draws on |
| LotWarden link | Lots in use read from LotWarden, and EQA outcomes per lot offered back to it, on this computer only |
| Records | The sealed record store, canonical records and their checks, workbooks and printable views |
| Security | Offline guard, host, origin and path guards, write confinement, hash-chained audit logs, laboratory data sealed on the drive, and one running copy |
| Interface | The page, the application shell and its routes, build identification, bundled fonts and the build recipe |
A section's major version is bumped when it can give a different result or record for the same input, and its evidence is re-verified before deployment. The minor version covers wording, speed and crash fixes with unchanged results. A new release number is set before any bumped section is deployed, and each section's files are fingerprinted at the baseline.
Fictional fixtures, golden scenarios, a dossier per release.
A fictional year of RCPAQAP-style results for about 25 analytes, Unity IQC exports and a LotWarden lots export are generated with injected scenarios and their expected findings and top causes. The regression runs the imports, the engine, the interpretation, the link, the security guards, the audit chain, the exports and the page routes end to end.
Separate suites cover the platform, every statistics primitive against reference values, the knowledge cross-references, the engine, the importers, the interface, the reports, the myQAP report reader and the cross-analyte signatures. The release check re-runs them all, checks the section fingerprints and writes the validation dossier.
What the fixtures are built to catch.
- A reagent-lot step with concordant IQC
- Calibration with a proportional bias
- A sample swap, a unit error and a decimal error
- A reconstitution error across analytes
- A one-off random error with stable IQC
- Drift within the APS
- A small peer group, and a method-dependent analyte with an all-method target
- An analyte-specific handling pitfall, and a clean analyte with no flags
61 of 101 parameters are EQAWarden's own choices. The laboratory signs them off.
Before EQAWarden's suggestions are used in real review records, the chemical pathologist or delegated senior scientist reviews one document generated from the knowledge files as they stand.
Thresholds
Every parameter that did not come from RCPAQAP, ISO 13528, Westgard or another named source, with its value and its reason, to mark Agree or to change.
Cause weights
The points each finding gives each cause, so the laboratory can see and adjust why one cause ranks above another.
APS rows to confirm
The default APS rows that could not be verified against a current RCPAQAP publication, each to be confirmed or replaced.
The pack ends with a sign-off table: reviewer, initials, date, changes asked for and a QMS reference. A change is made in the knowledge files, bumps the Knowledge section version, and the pack is regenerated so it always matches what runs.
One folder on a Windows PC. Nothing installed, nothing written elsewhere.
- EQAWarden.exethe program; the page opens in your browser
- data\the sealed store: results, IQC, lots, reviews, mappings · sealed
- imports\what was read, kept for the record
- exports\survey records, cycle summaries, evidence packs, EQA by lot
- eqawarden.keythe key to the sealed store; back it up with the folder
- audit.logevery action, hash-chained, readable
- network_audit.logevery blocked connection attempt
- Unzip and run. Keep the console window open while you use it; close it to stop. Every green build publishes a Windows zip, named by its commit.
- Local address only. The page is served at 127.0.0.1:5760 and answers no other host. LotWarden sits beside it on 5759.
- Try it before you trust it. Add ?demo to the address to see every view on fictional data without storing anything, or load the fictional demo year into a second copy.
- Evaluation copies now. EQAWarden is completing validation for its first release. An evaluation copy runs the demo year today and your own reports the day the laboratory signs off the review pack.
Questions your quality manager or IT team want answered first?
Ask them before the walkthrough. Every answer comes with the file, the check or the log line that proves it.