In this article:
- What is the Data Quality section?
- Alert Types
- Examples of Alerts
- What should you do about each alert?
- Tips for using Data Quality Every Day
What is the Data Quality section?
The Data Quality section is a built-in check on your scope, showing you exactly what Encircle's scoping engine could and couldn't confirm from your job file. Rather than silently guessing or leaving gaps unexplained, it documents anything it had to assume, flag, or double-check while generating your scope — so you can see, at a glance, whether your file is ready to move forward.
Reviewing this section as you go — not just at the end of the job — is one of the best ways to make sure your file, scope, and eventual estimate can hold up to scrutiny.
You can view Data Quality as its own dedicated section, separate from the scope itself. In the Web App, click the eye icon to open the Data Quality panel.
In the Mobile App, click the Data Quality section at the top of the scope.
Alert Types
Every item in the Data Quality section falls into one of three categories:
Critical: Missing data that directly affects how your scope was generated. This is specifically tied to missing measurements or missing photos. Critical alerts mean part of your scope may be incomplete or inaccurate until the underlying data is added.
Warning: Data that was present in your file but couldn't be fully verified during scope creation. Warnings are a prompt to go back into the project and double-check something yourself.
Information: Straightforward decisions the engine made while building your scope. These aren't problems — they're transparency, so you know exactly what assumption was made and why.
Examples of Alerts
Critical
- A room has no photos at all, even though it's marked as affected.
- A room is missing measurements, so its dimensions — and any quantities based on them — can't be confirmed.
Warning
- A room only has one or two photos on file, which may not be enough to fully support the damage described.
- A note is too brief, lacking in detail, or generic to support what's being scoped in that room. For example, a note with only a title like "water damage" or "see above".
- Your photos and your notes disagree — for example, a note describes laminate flooring, but the photos show tile.
- The floor plan's total square footage and the sum of your individual room measurements don't line up.
Information
- Standard dimensions or a standard 8-foot ceiling height were applied because measured dimensions weren't available.
- A room from your floor plan was matched to a technician-documented room by name, dimensions, or description rather than a direct ID match.
- A technician's documented judgment call differed from a standard IICRC recommendation, and the engine logged both the deviation and the reasoning.
What should you do about each alert?
Critical alerts should be resolved before you rely on the scope. Go back into the project, add the missing photos or measurements, and regenerate the scope. Until these are cleared, treat the affected areas of your scope as incomplete.
Warning alerts need a human double-check. Open the flagged room or item, confirm which version of the information is correct (or add the photo, note, or clarification that's missing), and update the file if needed. Warnings won't necessarily break your scope, but they're exactly the kind of gap a carrier's reviewer will notice.
Information alerts don't require action. They're there so you understand what the engine did and why — useful context if you're ever asked to explain how a number in your scope was reached, but nothing you need to fix.
The goal is a file with as few Critical and Warning alerts as possible before you move from scope to estimate — not because Data Quality is the last checkpoint, but because catching these gaps while you're still able to act on them is what makes the resulting scope and estimate defensible in the first place.
Tips for using Data Quality Every Day
You don't have to be actively scoping the job to get value out of this section. Running Scope just to pull a fresh Data Quality read is one of the simplest habits a crew can build. Think of it as a daily gut check on your documentation, separate from whatever else Scope is doing for you that day.
Run it daily, even if you don't need a scope yet. On the morning of day two, before the crew heads back out, run a scope and see what's missing from the file so far; no floor plan yet, a room with no photos, a source that hasn't been identified. Share that list with the technicians heading to site that day so they know exactly what to grab.
Make it the last thing before anyone leaves the site. On the final day of the job, whoever is wrapping up — crew lead, PM, whoever's physically there — should run Scope one more time before packing up equipment. If Critical or Warning items are still showing, that's the signal to stay and close the gap, not to head out. Once everyone's left the property, going back for a missing photo or reading isn't realistic.
Treat it as a running to-do list, not a one-time check. Unlike a static checklist that doesn't flex from job to job, Data Quality only shows you what's actually missing from this file, updated every time you run it. An admin or PM who isn't even on-site can run Scope mid-job, pull the Data Quality section, and tell the crew exactly what still needs to be collected before the last day.
Don't send anything to Xactimate while issues are still showing. A scope pushed to Xactimate with open Critical or Warning alerts isn't ready to represent as a defensible final estimate. Go back into the file, add the two or three things are missing, and get Data Quality clean first.
If there's a legitimate reason behind a flagged item, document it — don't just leave it open. Sometimes a flag reflects a real, defensible judgment call rather than a mistake. For example, downgrading a water category because lab results came back clean when the standard recommendation would call for a higher category. Note that reasoning directly in the file. Data Quality logs deviations like this along with your justification, so it reads as a documented professional decision instead of an unexplained gap.
Consider making it a friendly competition. Some teams have turned this into a bit of a game — technicians comparing who finished a job with zero Data Quality issues, or who closed theirs out fastest. However you frame it internally, the habit is the same: treat a clean Data Quality section as a point of pride, because it's a direct reflection of how defensible your file is.
Teams that build this into their daily routine tend to see it pay off in the numbers; noticeably more photos and notes on file per job, and far fewer gaps for a carrier to flag or push back on.
Updated