Test us on a project you already built
Send a finished project and the RFI log it generated. Flikt.AI reviews the plan set as it stood before construction, and you check the findings against the RFIs your team actually wrote.
Every plan review tool claims it catches things. The claim is hard to test on a live project, because you cannot know what you avoided.
On a finished project you can. The RFI log is a written record of what the drawings failed to answer, priced and dated by the people who had to resolve it. So run the review backwards: give Flikt.AI the set your team bid, and compare what comes back against what your team actually asked for in the field.
Two things, and one of them is easy to get wrong
Why it has to be the old set
Later revisions were issued in response to the RFIs. If you send the current set, the architect has already fixed most of what the RFIs were about — so the review finds a thin set of conflicts, and the comparison measures nothing except that the corrections worked.
The plan set and the RFI log have to come from the same moment in the project’s history. Find the date of the earliest RFIs and pick the revision that predates them. If you are not sure which revision that is, send what you have and say so — the drawing index and the revision clouds usually settle it.
What comes back, and what it proves
A normal Flikt.AI report on that set. Nothing about it is special because it is a backtest — what you do with it is the point.
Walk your log against the findings
Some RFIs will have a finding sitting on the same sheets, describing the same gap, written before anyone broke ground. Some will not — a field condition, a submittal question, an owner change, or something the review missed.
Why both halves matterSorting your log into those groups tells you where document review actually helps on your kind of work, which is a more useful answer than a single score.
We will not hand you a percentage
That number is a property of your project and your set, not of the software. A set with complete specifications and a full discipline list gives the review far more to work with than a partial upload does.
What it does proveDirection and specificity. The findings are on your sheets, in your project’s language, and you already know which of them turned into money. That is a harder test than any demo, which is exactly why it is worth running.
Frequently asked questions
What is a plan review backtest?
Running an automated plan review against the drawing set of a project that has already been built, then comparing the findings to the RFI log that project generated. The RFI log is an independent, written record of what the drawings failed to answer, so it works as a check on the review.
Why does the plan set have to be the bid-time revision?
Because later revisions were issued to answer the RFIs. Reviewing a corrected set asks the system to find defects that are no longer in the documents, so it returns a thin report and the comparison measures nothing. The set and the log have to come from the same moment in the project’s revision history.
What if some RFIs have no matching finding?
Expected, and worth looking at closely. Some RFIs come from field conditions, submittal questions, or owner changes, and were never answerable from the drawings. Others are real misses. Sorting your log into those groups tells you more about where document review helps than any summary statistic would.
Do you need the specifications too?
Yes, if you have them. A large share of findings come from a drawing contradicting a spec section, so a drawings-only upload cannot surface them. Send the whole set you issued, including addenda.
Will you publish the results?
Not without your permission, and not with your project identified. Everything published on this site is either anonymized or shared with the customer’s agreement.
Put a finished project in front of it
Tell us roughly how large the set is and we will take it from there. If you would rather start with a live set, the first preview is free.