Understanding the order a review works in explains almost everything about what it finds.
Pirros reviews your drawing set. When something on a sheet is ambiguous or incomplete, it goes and looks at the model, the specification, and the reference documents to work out whether there is a real problem.
The drawing set is the subject. Everything else is supporting evidence.
Why this order
Your drawing set is the deliverable. It is what gets issued, what gets built from, and what you are liable for. Your model is a working artifact on the way to producing it.
That distinction matters because models are never perfect, and they are not supposed to be. People override visibility, fudge geometry that will never be printed, leave things in place that are not part of the design, and work in ways that are perfectly reasonable for producing drawings but would look like errors if you audited the model on its own terms.
A review that flagged all of that would bury the problems that actually matter.
What this means in practice
"Will Pirros find what's wrong in my model?"
The Project Review reviews your drawing set, and consults the model to resolve questions the drawings raise. The Model performance piece of the project will check the health of your Revit model and identify areas that could be changed to improve performance of the file itself.
A worked example. Suppose a dimension string is missing from a plan, and the question is whether a clearance meets an accessibility requirement. The drawing alone cannot answer it. So the review goes to the model, measures the condition geometrically, and tells you whether there is a code problem — citing both the drawing and what it found in the model.
That is the model doing its job: resolving an uncertainty in the set. What the review will not do is tell you that someone used a visibility override, or that a family is misnamed, or that the model contains geometry nobody will ever see.
If model quality is what you care about
Those questions are real, and Pirros answers them — just in a different place. Model Performance looks at the model itself: warnings grouped by type and count, and the Revit element ID behind each one so you can go and fix it.
If you are a BIM manager and model hygiene is your job, Model Performance is your surface and Project Review is your team's. They are designed to be used by different people for different reasons.
How this differs from PDF-based checkers
Most automated review tools read the exported PDF set and nothing else. Some also read the specification. Very few have access to the model at all.
The practical difference is what happens when the drawings are ambiguous. A PDF-only tool has to either guess or stay silent. Pirros can go and check — against the model, the spec, and the consultant drawings you loaded — and come back with an answer and its reasoning.
Every issue shows you that reasoning, including which sheets, schedules, and documents it consulted along the way. See Anatomy of an issue.
Frequently Asked Questions
Q: Will a review find errors in my model?
A: Not as a standalone audit of the model. It reviews your drawing set and consults the model to resolve what the drawings leave uncertain. If you want the model examined on its own terms — warnings, problem elements, model hygiene — that is Model Performance.
Q: Why not just review the model directly?
A: Because a model in production contains a great deal that is deliberately imperfect — overrides, working geometry, things that will never print. Flagging all of it would bury the findings that matter. The drawing set is what you issue and what you are liable for, so that is what gets reviewed.
Q: Can it run without a model at all?
A: It is possible to review a PDF drawing set with no model. Treat it as a last resort — without the model there is no way to resolve anything the drawings leave ambiguous, and the review is meaningfully weaker. See Add a model: Forma-linked vs. local upload.
Q: How do I know what it looked at for a given issue?
A: Open the issue and read Mira's thoughts. It records which sheets were opened, which schedules were consulted, and which specification sections were read — and the references are links, so you can go and look at them yourself.
Q: What happens if the drawings and the model disagree?
A: That is exactly the kind of thing the review is looking for. A discrepancy between what is drawn and what is modelled is surfaced as an issue, with the reasoning showing both sides of it.
Q: Does it read our specification?
A: Yes, when the specification is loaded as a project reference and the spec is what governs the question. A common example: the drawings show tile on an exterior wall, and the review finds that the spec only covers interior tile installation — so nobody has told the contractor how to install it outside.