How often are verifications in fact not done properly, or not explicitly enough? In my experience, too often. And it shows: stakeholders still tend to distrust whether the design or the execution is truly under control when it comes to demonstrating that requirements are met.
Sometimes that is because the requirements were not written down well. I wrote about that in "The risk is in the requirements". But there is a second reason that is just as real: designing and executing parties know they comply, but it cannot be read explicitly from their documents.
That is where REF helps. It takes away the administrative burden, and for the party responsible for delivering the verifications it does two things: it supports the verification itself, and it shows clearly where something is still missing. That makes it a practical way to get to verifications that are both faster and better. It is easy for clients, and easy for contractors.
Clients can also use REF as an audit tool. They can scan incoming documents that are submitted for review or acceptance, and see where low verification scores point to risks. A low score does not automatically mean a requirement has not been met. It means it cannot be demonstrated from the document in front of you.
Every requirement eventually needs to go through the same scrutiny: has this actually been met? Answering it is more like document detective work than engineering. Test reports, inspection records, calculation sheets and design documents are scattered across folders and hold hundreds of pages each. Finding evidence for a requirement is long investigative work, at each project phase, with real repercussions if not done accurately.
Even if the evidence exists in documentation, finding it and judging sufficiency across thousands of requirements by hand does not scale.
REF takes a different approach.
01 | What REF does
The Requirements Evidence Finder uses artificial intelligence to complete a requirements verification autonomously, or with an engineer in the loop. For each requirement it locates candidate evidence points, evaluates the strength of the match and provides a score which indicates how certain the evidence is.
REF also assesses claims across documents. It detects contradictions between solutions or statements in the documents it finds.
REF runs phase-aware verifications: it rates evidence at a project’s design phase differently from delivery phases, where evidence must be measured and observed according to predefined metrics and standards.
02 | A score, not a verdict
REF surfaces the evidence, the strength of the link and how certain it is. It wraps its review in a score and an explanation, and leaves the final call to you. Any weak matches get flagged with observations for further investigation by an engineer. Strong links are reported for audit purposes, and you confirm the results when you export.
The engineer-approved register carries real weight. All documents are reviewed, the strongest evidence is put forward, issues are clearly reported and even pass scores are logged, with a source and explanation.
03 | What you get back
For each requirement, REF returns:
- The evidence and its source document, with an explanation of the claim, also in the case of a gap or contradiction
- A match strength and certainty score
- Score explanations and gap analyses in case of issues
- A phase-adjusted sufficiency indicator
- Items flagged for human review where the evidence is ambiguous or absent
The output feeds directly into your verification register, with every link traceable back to its source.
04 | What stops slipping through
Whilst REF saves time, it is not the main point. The volume of documents and evidence in verification processes means small issues fall through the cracks. REF catches what would otherwise slip through. It finds the evidence, checks it in context and reports. You still decide what counts as sufficient, work through the ambiguous cases, and carry the responsibility for the register that goes to the client.
05 | Part of a broader workflow
In the Basewise platform, REF sits at the end of the chain. DRE extracts requirements from source files and RQA checks their quality. Verifying against requirements that are already well-formed helps REF deliver better matches.
Curious what REF finds in your own project documentation? Book a demo and we will show you.
