Why We Built CheckMate
Evidence Before Assumptions
We did not build CheckMate because institutions needed more paperwork. They already have plenty. We built it because paperwork can exist without answering the question that matters. Does the evidence actually hold together?
At Alle’s ClinX, we spend a lot of time thinking about chemistry. But institutional hygiene is not only a chemistry problem. It is also a records problem, a procurement problem and, ultimately, a decision problem.
A product can arrive with a label, an SDS, a TDS, a COA, an invoice and a purchase order—and still leave basic questions unanswered. Do those documents refer to the same product? Does the batch on the COA match the batch received? Is a certification claim independently verifiable? Did the supplier submit what the specification actually required? Is what arrived the same material that was approved?
Those questions sound simple. In practice, they are scattered across people, PDFs, inboxes and physical packs. CheckMate began with a decision to make that evidence easier to see.
The problem was not missing documents. It was missing coherence.
Most procurement systems are good at proving that a file exists. That is not the same as proving that the file belongs to the product in front of you.
A supplier may submit a professional-looking SDS. A COA may contain laboratory values. A brochure may state a standard or performance claim. Stores may receive a batch with a matching product name. Every individual element can look reasonable while the combined record is still inconsistent.
The manufacturer name can change between documents. The COA can omit the received batch. A five-litre product can become a different SKU at delivery. A certificate can be genuine but irrelevant to the actual product or manufacturing site. A performance claim can be repeated everywhere without the underlying evidence being part of the review.
That distinction became the foundation of CheckMate. Presence is not consistency, consistency is not verification, and verification is not laboratory proof.
Present means the information exists. Consistent means the records agree. Verified means an authoritative or first-party source confirms it. Tested means the relevant physical or laboratory property has actually been measured. CheckMate should never blur those four levels.
Why we did not build a “fake product detector”
It would have been easy to market CheckMate that way. It would also have been irresponsible.
A photo cannot establish the full chemistry inside a bottle. A missing batch number does not prove counterfeiting. A different label revision may be legitimate. A supplier’s document can look unusual and still be authentic. Software should not turn uncertainty into accusation simply because a decisive answer looks better on screen.
So CheckMate uses narrower language. It can say that evidence is missing, internally consistent, independently unverified or conflicting. It can identify a mismatch. It can show the exact field that triggered review. Where a trusted public or first-party source is available, it can move from consistency toward verification.
That is a less dramatic product promise. We believe it is a more useful one.
Four tools, mapped to the way products actually move
We deliberately avoided one giant compliance dashboard. CheckMate is organised around four moments in the lifecycle of a product — understanding it, reconciling its documents, evaluating a supplier submission and checking what finally arrives.
Establish the basic product record across identity, manufacturer, batch, dates, quantity, safety information and claims that still need evidence.
Compare label, SDS, TDS, COA, PO and related records to determine whether they describe one coherent product.
Compare requirements with supplier evidence and distinguish supported items from claims, omissions and contradictions.
Compare the approved record with the received material before the product is accepted into use.
Product Check
The first CheckMate workflow is intentionally basic. Before asking whether something is compliant, genuine or suitable, we need to know what the evidence actually identifies.
Product Check extracts the product name, manufacturer, batch information, dates, quantity, safety information and notable claims from the material supplied. It then shows what is present and what still needs attention.
If the batch is missing, that is a traceability gap. If the label carries a strong efficacy claim but the supporting report is not part of the evidence set, that is a verification gap. If a certification is claimed but has not been checked against an authoritative source, the interface should say exactly that.
The goal is not to replace QA. It is to make the first review disciplined enough that QA starts with a clearer record.
Document Match
Document Match is the workflow that most directly reflects the problem that led us here. People usually review files one by one. CheckMate reviews the relationships between them.
Obvious equivalents should not become noise. “5 L” and “5000 mL” should reconcile. Minor differences in company suffix formatting should not create a false alarm. But a different manufacturer, product code, batch or specification revision should remain visible.
We are not trying to make documents look consistent. We are trying to make inconsistency difficult to miss.
That difference matters. A useful verification system should reduce clerical noise without smoothing away the very conflicts a human reviewer needs to see.
Procurement Review
Procurement requirements rarely arrive in the same structure as supplier submissions. A specification may ask for an SDS, a particular pack size, manufacturer authorisation, test evidence or conformity with a stated standard. The supplier may answer those requirements across several PDFs and statements.
Procurement Review turns that into an evidence matrix. An item can be supported, claim-only, missing or contradicted. We care about that distinction because a statement in a brochure is not the same thing as independent verification, and the word “authorisation” appearing inside “authorisation not supplied” must never count as evidence that the requirement was met.
This is not the glamorous part of AI. It is repetitive comparison work. That is precisely why software can be useful here.
Delivery Match
A procurement decision creates a reference record. Receiving should test the delivery against that record, not start the evaluation again from scratch.
Delivery Match compares the approved manufacturer, product, SKU, pack and specification against the received label, batch and supporting documents. Hard identity conflicts should be obvious. Softer gaps should be separated from them.
That also means resisting false positives. If an optional field is absent on both sides, CheckMate should not manufacture a problem. If the product and SKU match but a document revision needs review, the result should communicate that nuance rather than collapse everything into pass or fail.
Good verification software should be careful in both directions. It should surface real conflicts without training users to ignore constant false alarms.
The reason matters more than the score
We have deliberately kept CheckMate away from the familiar pattern of a large confidence score in the middle of the screen. A number can look precise even when the reasoning behind it is weak.
If CheckMate flags a manufacturer conflict, the user should see both manufacturer values. If it says a claim remains unverified, the exact claim should be visible. If Delivery Match recommends a hold, the field responsible for the hold should be explicit.
That is what “explainable” means to us in this context. Not a paragraph generated after the fact, but a result whose evidence can be inspected directly.
Decision → reason → evidence. A user should be able to move from the conclusion to the exact source of that conclusion without trusting CheckMate simply because CheckMate said so.
CheckMate has to work beyond Alle’s ClinX
We think this is essential to the product’s credibility. A hospital, hotel, school, factory or housekeeping contractor should be able to use the same review framework whether the product comes from Alle’s ClinX, a multinational supplier or a smaller regional manufacturer.
The evidence level will differ. With an Alle’s ClinX product, CheckMate can eventually connect first-party SKU, batch and specification records. With a third-party product, it may only be able to establish internal consistency, verify a public record where one exists, or clearly mark what remains unverified.
That does not make the tool less useful. It makes the confidence level more honest.
The boundaries are part of the product
CheckMate cannot determine full chemical composition from a label photo. It cannot replace microbiological efficacy testing. It cannot authenticate a certificate solely because the PDF looks professional. It cannot certify regulatory compliance on behalf of an authority, and it should not replace qualified human review where that review is required.
We would rather make those boundaries visible than quietly imply capabilities that are not there.
The more consequential the decision, the more important it becomes to know which layer of evidence you are using — document presence, document consistency, external verification or actual physical testing.
What comes next
The first version of CheckMate is intentionally practical. It consists of Product Check, Document Match, Procurement Review and Delivery Match.
The next improvements are similarly unglamorous and valuable. They include stronger OCR for scanned records, precise page-level source citations, authoritative licence and certification lookups where reliable public sources are available, and optional first-party manufacturer data for stronger batch-level verification.
Over time, we also see CheckMate becoming an evidence trail of what was submitted, what was approved, what arrived, what was questioned, what was corrected and what was finally released. That would make supplier reviews, complaints and audits easier to reconstruct without turning the system into another heavy enterprise platform.
The principle, however, should not change. We do not want CheckMate to make the decision for the user. We want it to make the evidence clearer before the user makes the decision.
That is also how we think about ClinXAI more broadly. Build narrow tools around real work, let software handle repetitive comparison, keep the reasoning visible, and leave responsibility where it belongs—with the person making the decision.
Explore CheckMate and ClinXAI
- CheckMate — evidence verification tools
- Product Check — establish product identity and evidence
- Document Match — compare product records across documents
- Procurement Review — compare requirements with supplier evidence
- Delivery Match — compare approved and received material
- ClinXAI — the Alle’s ClinX intelligence layer
See what the evidence actually says.
Use CheckMate to establish the product record, reconcile documents, review supplier evidence and compare approved material with what arrives.
