A plain-language guide to the mechanisms, principles, technical terms, honest limitations and continuous improvement behind two products built on one idea: never trust an AI answer you cannot check.
Modern AI models are extraordinarily capable and confidently wrong often enough that you cannot take their word for anything important. Most AI products deal with this by asking you to trust them anyway. These two products take the opposite route:
The rule both products live by: every answer must carry its own proof, and every failure must be visible. If the system cannot prove something, it says so, out loud, in the report, instead of guessing.
In AssuranceLens that means every claim of a compliance problem must quote the exact words from your own document as evidence, and that quote is mechanically checked to really exist. In Genesis it means maths is done by a real calculator rather than the model's mental arithmetic, generated code is compiled and run before being shown to you, and research answers carry citations to real sources.
Analogy. A good junior colleague does not just say "the contract looks fine". They say "clause 4.2 covers termination, here is the sentence, on page 12, and here are the three clauses I could not find an answer for". Both products are built to behave like that junior colleague, never like a confident stranger.
Before a clinical trial can run, its sponsor must show that a whole set of documents (the protocol, the informed consent form, the investigator brochure, the statistical analysis plan and more) satisfies several hundred regulatory requirements drawn from international rulebooks: ICH GCP E6(R3), the EU Clinical Trials Regulation, and US FDA regulations.
Today that check is done by hand, by people who are scarce and expensive, and it is redone every time a document changes. It changes a lot: 76% of trial protocols need at least one substantial amendment, at a median direct cost of roughly $141,000 in Phase II and $535,000 in Phase III per amendment. Many amendments are avoidable, and the avoidable ones are largely documentation errors: the dosing changed in the protocol but nobody updated the consent form; the sample size changed in the synopsis but not in the statistical plan.
This lands hardest on publicly funded research. The UK has 50 registered university Clinical Trials Units carrying the same legal duties as a pharmaceutical giant, with a fraction of the staff. For them, money lost to avoidable rework is grant money not spent on treating patients.
Analogy. Imagine an exam with 866 questions, where the "answers" are scattered across a 300-page stack of documents, the pass mark is 100%, and the exam is re-sat every time anyone edits any page. AssuranceLens is the marker that checks all 866 questions every time, shows its working for each one, and lists the questions it could not mark.
How an analysis works, step by step
The AssuranceLens pipeline. Documents are read once; each requirement is then checked as its own small, provable task.
Read the documents once. Your uploaded files are converted to text, page by page. Pages that cannot be read (scans, images) are detected and reported rather than silently skipped; more on this under limitations.
Open the rulebook. Instead of asking an AI "is this compliant?" in one giant question, AssuranceLens holds a curated index of 866 individual regulatory requirements, each one extracted from the official legal texts with its source recorded. Machine extraction found 995 candidates; ungrounded ones are excluded and a curation review is part of the quality process.
Keep only the rules that apply. A requirement about paediatric consent does not apply to an adult-only study. The filter works from your study profile and the document types you uploaded. Everything excluded is counted and the reason recorded, so exclusions are visible, never silent.
Check each requirement as its own small task. For every applicable requirement the AI is asked one narrow question: is this requirement met, partially met, missing, or not applicable in these documents? It must answer from a fixed menu (no rambling) and must include a word-for-word quote from your document as evidence.
Verify the evidence mechanically. Software (not another AI, not a human) checks that every quoted passage genuinely appears in your document. An AI that invents a quote is caught automatically. A "met" verdict whose quote cannot be found is downgraded to "disputed" for a human to adjudicate.
Attack every claimed violation. Before you ever see a finding of non-compliance, a second AI pass plays devil's advocate: its only job is to search the same documents for counter-evidence proving the finding wrong. Findings that survive are stronger. Findings that are refuted are not deleted; they ship downgraded with the counter-evidence attached, so the reviewer sees the self-correction.
A human decides. Every finding goes to a human reviewer, and the system blocks export of any report that has not been human-reviewed. The AI proposes; a person disposes.
Account for everything. The final coverage report is an accounting ledger: requirements indexed, applicable, evaluated, met, partial, missing, unanswered, and excluded with reasons, including "no document of the required type was uploaded". Every number can be opened up to the individual requirement and its evidence.
Under the hood. Each check is a "tool-forced" AI call: the model must reply through a rigid form whose verdict field only accepts four values, so category drift across a long run is impossible. All the checks share one large cached reading of your documents (see "prompt caching" in the glossary), which is why checking 866 requirements does not cost 866 full document readings. Long runs checkpoint their progress and can resume after an interruption without re-paying for completed work.
The design principles
1. Fail-visible. The most dangerous failure of an AI checker is silence: something it could not do, absorbed into a reassuring summary. AssuranceLens is built so its own gaps become findings in the report:
A requirement the AI failed to answer becomes a "needs manual review" finding.
A required document that was never uploaded becomes a finding.
A "met" verdict whose evidence cannot be located becomes a "disputed" finding.
A page that could not be read becomes a finding, and verdicts that depended on it are downgraded.
2. Verdicts, not vibes. Every requirement gets exactly one of: MetPartialMissingNot applicable plus two system states: Disputed (counter-evidence found, human adjudicates) and Needs manual review (the system could not decide). Because the vocabulary is closed, results are comparable across runs, models and documents.
3. Evidence or it did not happen. A compliance claim without a quote is worthless in an audit. Every verdict carries a verbatim excerpt and a citation to the specific regulatory clause it was judged against, and the excerpt is mechanically verified. This is also what makes the AI's errors measurable: an invented quote is a caught, counted event, not an undetectable lie.
4. Humans stay in charge. The EU AI Act asks for transparency and human oversight; AssuranceLens implements both structurally. Every finding records which AI model produced it, and the export gate physically prevents an unreviewed report from leaving the system.
5. Measure, then believe. The team's own history enforces this one. An earlier version used a popular technique called RAG (fetching only the "relevant" snippets of a document for the AI to read). It was built properly, measured properly, and found to make both cost and quality worse for this task, so it was removed and the failure written up. The current architecture exists because the measurement was believed over the fashion.
Honest limitations
Scanned pages and pictures are invisible to the current analyzer. The system reads the text layer of documents. A page that is a photograph of a page (a scan, a signed form, a figure, a graph) has no text layer. Until mid-2026 this was a silent blind spot; now it is detected: unreadable pages are reported per document, and any "missing" verdict that might be explained by an unreadable page is routed to manual review instead of being asserted. Teaching the system to actually read images (vision AI) is designed and scheduled, and it carries a genuinely unsolved research question: the word-for-word evidence check has no obvious equivalent for a picture.
The scanned-page problem. The fix is honesty first: detect the blindness and route around it, then teach the system to see.
No published accuracy numbers yet. AssuranceLens does not yet publish "we catch X% of planted errors". Rather than quote an unmeasured number, the team built a defect-planting pipeline (178 test documents with known, catalogued errors across 6 error types) and is extending it to clinical documents with a pilot partner adjudicating the ground truth. The benchmark comes before the boast.
The rulebook needs ongoing curation. The 866 live requirements were machine-extracted and bulk-approved; an automated triage flagged a large minority for human review. A wrong rule poisons every analysis that touches it, so curation is treated as the crown jewels, not a chore.
The AI can still be wrong, which is why it never gets the last word. Every structural safeguard (evidence checks, devil's advocate, closed vocabulary) reduces error; none eliminates it. That is why human review is mandatory and unremovable, and why the output is decision support for a professional, not legal or regulatory advice.
How it keeps getting better
Reviewer decisions feed two engines: a benchmark that measures accuracy, and a governed memory of approved lessons.
The benchmark. Documents with deliberately planted, catalogued defects are run through the system, and recall (how many planted defects were caught), precision (how many findings were real) and evidence groundedness are scored. Because the defects are planted, the right answer is known, so the system can be proven wrong, which is the only way it can be trusted when it is right.
Review memory (designed, built after the codefest). When reviewers accept, reject or correct findings, the lessons are distilled into short caution statements. Three deliberate safety rules govern them:
Born specific, promoted by evidence. A lesson learned on one device or study type starts life applying only there. A human promotes it to a wider scope only after it recurs. This stops one situation's wisdom quietly becoming every situation's error.
Approved by a person, always. Nothing enters memory automatically. Every lesson is proposed, and only the founder (for now) can approve, promote or retire it.
Memory can raise scrutiny; it can never suppress a finding or supply evidence. A remembered caution can tell the system "check this area extra carefully". It can never say "skip that check" or stand in for a real quote, because a memory with veto power would be a back door for hiding real violations.
Version gap analysis (the road ahead). When a regulation itself changes (as ICH E6 did, becoming legally binding in the UK in April 2026), every active trial's documents must be re-checked. The planned capability compares the old and new rulebook clause by clause, works out which requirements changed, and re-checks only the affected documents against only the changed requirements: a scoped delta instead of re-reading everything.
Product 2Genesis: a private AI that verifies itself
Genesis is a different animal: a personal AI workstation that runs entirely on your own computer. No cloud account, no API key, no document or question ever leaving your machine. It exists for the growing set of people and organisations who want serious AI help but cannot, or will not, send their material to someone else's server.
Genesis routes each request to the engine that can prove its answer, instead of letting one model wing everything.
The mechanisms, in plain terms
A router, not a know-it-all. When you ask something, Genesis first classifies it. A maths or logic problem goes to the exact solver. A coding task goes to the verified engineer. A factual question goes to cited research. Everything else takes the general reasoning path. Each engine proves its work in the way its subject demands.
Maths by calculator, not by vibes. Language models make arithmetic slips. Genesis has the model set up the problem, then hands it to a real symbolic maths and logic solver that computes the answer exactly.
Code that ran before you saw it. The coding engine writes a program, then compiles it and runs its self-tests against the real toolchain, iterating on the actual compiler errors. It can generate several independent attempts and keep the one that actually passes.
Research with receipts. Research answers come from live sources (including open-access academic databases with about 250 million works) and carry inline citations, with every source recorded in a provenance log you can inspect.
Effort tiers. You choose fast, balanced, deep or expert. Higher tiers add drafting, self-checking and cross-checking passes. Genesis also grades its own confidence and suggests escalating when it is unsure.
It learns from you, without retraining. Corrections you give are saved and recalled when a similar question appears later. It also builds a profile of its own strengths and weaknesses from its track record and injects warnings into its own prompts ("known weakness here, double-check").
A written constitution. Enduring principles are injected into every answer: unconditional honesty, weighing all sides, evidence over assertion, stating uncertainty, asking a clarifying question rather than answering a guessed one, and pushing back when you are wrong instead of flattering you.
Guardrails. System files are blocked, secrets and personal data are stopped at the network boundary by an egress guard, web access is allow-listed and audited, and risky actions require your approval.
Genesis's honest limitations
A local model is not a frontier model. Genesis runs open AI models on your hardware. They are genuinely capable and improving fast, but the largest cloud models still reason better. Genesis compensates with structure (solvers, verification, citations) rather than pretending the gap away, and its verification layers are exactly the features that matter most when the underlying model is weaker.
Your hardware is the ceiling. Speed and model size depend on your machine's memory and graphics card. Genesis measures your hardware and tells you what is realistic rather than letting you discover it by freezing.
Confidence grades are self-assessments. The meta-cognition gate (the model grading its own answer) is a useful signal, not an oracle; that is why the design treats it as a trigger for escalation and human attention, never as proof.
The bigger pictureHow the two relate, and the NVIDIA Codefest
AssuranceLens and Genesis share a design philosophy and a builder, not a codebase. One is a multi-user regulated-industry product with audit trails and billing; the other is a single-user private workstation. Keeping them separate is deliberate: each stays simple enough to reason about.
They intersect in one place that matters. AssuranceLens today does its AI thinking through a hosted cloud service, which is the right way to start but the wrong place to finish, because its target customers (NHS trusts, university trials units) are often prohibited from sending trial documents to any external service. Genesis proves the other way is real: serious AI work on machines you control, with nothing leaving the building.
The NVIDIA Open Models Codefest (September-October 2026) is where the two threads meet. The project: port the AssuranceLens checking engine onto NVIDIA's open Nemotron models running on dedicated graphics hardware, publish the first open benchmark for regulatory-document AI (including where the open model loses), and produce a deployment package a trials unit could run entirely inside its own infrastructure. Genesis contributes as evidence that the team ships open-model software, as the local test environment for the early porting work, and, after the event, as the first external tool allowed to call AssuranceLens. Nothing agent-like goes inside the checking engine itself: its guarantee of complete coverage depends on checking every requirement, every time, with no AI deciding what to skip.
Under the hood. The port's central engineering question is cache economics. AssuranceLens holds one long reading of your documents constant across hundreds of small checks; on a hosted service that reuse is rented ("prompt caching"), on self-hosted hardware it is owned (reusing the model's internal working state, its KV cache). Whether that reuse can be made to pay on real GPUs, at what batch size and model precision, decides whether an NHS-deployable version is economically viable. A regulation change makes the question sharper still: re-checking a whole portfolio at once is exactly the bursty, parallel workload that owned hardware absorbs and per-token pricing punishes.
WalkthroughTutorial: a day with AssuranceLens
Create a project and describe the study in a short profile: phase, design, regions. This drives the applicability filter.
Upload the document set. Each file is labelled with its type (protocol, consent form, statistical plan...). The system suggests a type from the filename; you confirm. If a required type is absent, the analysis will say so as a finding, not a footnote.
Run the analysis. A full run makes hundreds of small AI checks and can take a while; it reports progress, checkpoints as it goes, and resumes if interrupted. A cheaper batch mode trades speed for roughly half the cost.
Read the coverage report first. Before any findings, look at the ledger: how many requirements applied, how many were evaluated, what was excluded and why, and whether any pages could not be read. This is the "did we actually check what we think we checked" view.
Work the findings. Findings arrive grouped (near-duplicate requirements from overlapping rulebooks are clustered so you decide each real obligation once) and categorised: missing content, incomplete content, misaligned information, outdated references, ambiguous language, administrative gaps, disputed, needs manual review. Each carries its quote, its clause citation and a suggested fix. Accept, reject or correct each one; disputed findings show you both sides' evidence.
Review, then export. Once a human has reviewed, the report can be exported for the trial master file, carrying the model attribution and review record an auditor expects.
When documents change, upload the new versions and re-run; the comparator can also diff two document versions directly, listing differences, contradictions and content present in only one version.
ReferenceGlossary of technical terms
AI model / LLM (large language model)
A computer program trained on enormous amounts of text to predict language. It can draft, summarise and reason impressively, and can also be confidently wrong, which is why everything here is built around checking it.
Token
The small chunks (roughly word-pieces) that models read and write. AI usage is priced per token, which is why "how often do we re-read the documents" is a cost question.
Inference
Running a trained model to get answers (as opposed to training one). AssuranceLens is inference-only: it trains nothing.
Prompt caching
Re-using a model's reading of unchanged text across many requests instead of paying to re-read it every time. AssuranceLens's cost model depends on reading your documents once and asking hundreds of small questions against that one reading.
KV cache
The model's internal working memory of what it has read. On self-hosted hardware you control this directly; "prefix KV-cache reuse" is the self-hosted equivalent of prompt caching.
Clause / clause index
One individual checkable requirement extracted from a regulation ("records must be retained for 25 years"), and the curated catalogue of 866 of them that drives every analysis.
Verdict
The one-word outcome of checking one clause against your documents: met, partial, missing, or not applicable.
Grounding / grounded evidence
An AI quote that has been mechanically confirmed to exist word-for-word in the source document. Ungrounded evidence is treated as suspect, never as proof.
Adversarial verification (the devil's advocate pass)
A second AI pass whose only goal is to disprove the first pass's findings by hunting for counter-evidence. Surviving findings are stronger; refuted ones are shown to the reviewer with both sides attached.
Coverage ledger
The accounting of an analysis: indexed, applicable, evaluated, each verdict count, and every exclusion with its reason. The anti-hand-waving device.
Fail-visible
The design rule that anything the system could not do must appear in the report as a reviewable item rather than disappearing into a summary.
RAG (retrieval-augmented generation)
Fetching only "relevant" snippets for the AI to read instead of whole documents. Popular, often useful, and measurably wrong for this product: it was built, measured, found to regress cost and quality, and removed.
Fine-tuning
Additional training that changes a model's weights. Distinct from the review memory, which changes what the system is told, not what the model is. AssuranceLens currently does neither training nor fine-tuning.
Open model vs hosted API
A hosted API is AI as a service: powerful, but your data travels to it. An open model's weights can be downloaded and run on hardware you control, so data never leaves. For much of the public sector only the second is deployable.
GPU
The graphics processor that does AI's heavy lifting. Owning GPUs turns AI from a metered utility into a fixed-cost capability, which changes what workloads are affordable.
NVIDIA Nemotron / NIM / TensorRT-LLM / Ollama
Respectively: NVIDIA's family of open AI models; NVIDIA's packaged way of serving models with a standard interface; NVIDIA's toolkit for making models run fast on their GPUs; and a popular tool for running open models on ordinary local machines (what Genesis uses today).
Quantisation
Shrinking a model's numerical precision so it runs faster and fits smaller hardware, at some cost to quality. How much quality, for this workload, is a thing to measure, not assume.
MCP (Model Context Protocol)
A standard way for AI systems to offer each other tools. The planned direction: other AI systems may call AssuranceLens as a tool; no external AI ever steers the checking engine from inside.
FDA Product Code / EMDN
Two public classification systems for medical devices (a US one with 7,084 codes and an EU one with about 8,500 hierarchical entries) that the future device-analysis features will use to select the right standards for the right device type.
Seeded-defect benchmark
Test documents with known, deliberately planted errors, used to measure how many the system catches and how often it cries wolf. Because the answer key is known, the score is real.