A Common Language for Data: An Open Letter to the Industry
A Common Language for Data
An open letter to Restorers, Insurance Carriers, Third Party Administrators, and Technology Partners
It's 2 a.m., and a pipe has burst in a second-floor bathroom. The property owner calls their insurance carrier. The carrier calls a Third Party Administrator (TPA). The TPA calls a restoration contractor. By the time a crew is on-site, the same basic facts (who's affected, where the property is, what happened) have already been typed into three or four different systems, by three or four different people, none of whom can see what the others entered.
That's not a hypothetical. It's Tuesday, for nearly every loss moving through this industry. Multiply it across the volume of claims filed every day, and the pattern comes into focus: the same core facts, re-keyed manually, one platform at a time. It's slow, it's error-prone, and it breaks down further because there's no shared vocabulary: what one platform calls a “Job,” another calls a “Project” or a “Claim.”
That isn't unwillingness. It's a chicken-and-egg problem: many platforms have held off building integrations because there's no consistent standard to build toward, and no standard has emerged because there haven't been enough integrations to demand one. This effort is meant to break that cycle.
Why Data Standards Matter
A standard only works if everyone gains something from it.
For the property owner. Your worst day shouldn't require you to repeat yourself. When the same facts move automatically instead of being re-collected by every vendor, drying starts sooner, consent is clearer, and a repair is less likely to become a rebuild.
For restoration companies. Every hour spent re-keying data is unbilled overhead, and it falls hardest on independent and regional contractors. A shared vocabulary makes a restorer's data portable and turns documentation disputes into non-issues when both sides read from the same source of truth.
For technology partners. Every platform today maintains bespoke, one-off integrations that age badly and break when a partner changes a field. A published standard turns integration into a product feature, freeing engineering capacity for the tools, including AI and analytics, that actually differentiate a platform.
For insurance carriers. Cycle time drives indemnity spend, and every hour lost to re-keying sits on the loss-adjustment side of the ledger. Standardized data also makes vendor performance measurable and gives carriers a defensible, consistent position on PII as privacy regulation expands.
The RIA Emerging Technology Task Force has spent the past several months developing a Data Dictionary and companion PII framework: a shared vocabulary for the data restoration platforms, carriers, TPAs, and vendors already exchange every day. Version 1 is intentionally narrow: it standardizes First Notice of Loss (FNOL), the minimum data needed to open a job and route it cleanly into any restoration platform, and establishes a common definition of what is, and isn't, considered PII.
This is not a mandate, and it isn't owned by any single software company. It's built by the industry, for the industry, so a loss reported by a carrier reads the same way on a contractor's screen.
We're asking the organizations that move this industry forward to stand behind it.
If your organization builds, integrates with, or relies on restoration data (as a software platform, an insurance carrier, a TPA, or a vendor), we're asking you to review the Data Dictionary and PII Companion Guide and add your name as a supporter. This is the moment for the restoration industry to align around a shared standard before fragmentation makes that alignment harder. The organizations that move first will shape what comes next.
The RIA is working toward a future where the most critical claim data reaches the people repairing the property the moment they need it. Restoration is changing. Let's make sure the data keeps up.
Sincerely,
The RIA Emerging Technology Task Force
ADD YOUR ORGANIZATION'S SUPPORT