Asset-Based vs. Job-Based: Why Fire Compliance Software Needs a Different Data Model
A fire extinguisher hangs on a wall in a stairwell for years. It gets a monthly visual check, an annual maintenance visit, and a hydrostatic test every five or twelve years depending on the type. Each one gets performed by whoever happens to be on the route that month, often for a different employer than the one before. None of that work is really “a job.” It’s the ongoing life of one specific, physical thing.
Most software wasn’t built to see it that way.
Key Takeaways
- Generic field service software is built around a job. A ticket opens, gets worked, and closes. Fire and life safety compliance work is built around an asset with its own permanent, recurring history.
- NFPA standards attach different inspection cadences to different equipment types (some quarterly, some annual, some measured in decades) — a data model needs to track that per asset, not per visit.
- When compliance work is forced into a job-shaped system, inspection history fragments across tickets and technicians, and “when was this specific extinguisher last checked?” becomes a hard question to answer.
- An asset-based model makes the asset the permanent record, with jobs (inspections, repairs) as entries in its timeline. Not the other way around.
What “Job-Based” Software Actually Optimizes For
The US field service management (FSM) software market was worth an estimated $3.1 billion in 2026, growing at a 7.7% compound annual rate since 2021 (IBISWorld). The large majority of that software, the platforms built for HVAC repair, plumbing dispatch, and general contracting, is architected around a simple, sensible unit of work: the job. A customer calls, a ticket opens, a technician is dispatched, the work gets done, the ticket closes. The system’s job is to move that ticket through its lifecycle efficiently.
That model works well when each job is mostly self-contained. A one-off furnace repair doesn’t need to know much about what happened to the furnace three visits ago, three technicians back. The job is the record.
Why Compliance Work Doesn’t Fit a Job-Shaped Box
Fire and life safety inspection work is a different kind of business, even though it often gets sold the same kind of software. A single commercial building might have dozens of portable extinguishers, water-based suppression piping, a fire alarm panel, and a bank of fire doors. Each is governed by its own NFPA standard, on its own inspection clock:
| Asset type | Governing standard | Example cadence |
|---|---|---|
| Portable fire extinguishers | NFPA 10 | Monthly visual check, annual maintenance |
| Water-based suppression (sprinklers, standpipes) | NFPA 25 | Cadence varies by component: solenoid monitoring devices tested quarterly, dry-pipe/preaction valves given an annual internal inspection |
| Fire alarm & detection systems | NFPA 72 | Periodic testing per device type and system configuration |
| Fire doors & opening protectives | NFPA 80 | Annual inspection and testing in most adopting jurisdictions |
| Dwelling-unit sprinklers at 50 years in service | NFPA 25 | Replace with fast-response heads, or sample-test |
That last row is the clearest illustration of the problem: NFPA 25’s 2026 edition requires sprinklers that have been in a dwelling unit for 50 years to be replaced or sample-tested (QRFS; Chesapeake Sprinkler Company). That’s a single asset carrying a 50-year clock that has to be tracked from the day it’s installed, not a recurring job.
Vendors who build specifically for this industry say the mismatch is a real, recurring complaint. ServiceTrade, a field service platform built for commercial fire and life safety contractors, writes that most software platforms “don’t support the full scope of commercial fire and life safety operations,” because systems built for construction or general service work get adapted for inspection-first, recurring compliance workflows rather than designed for them (ServiceTrade). Uptick, a fire inspection compliance platform, makes a sharper version of the same point about generic FSM tools: they lack “built-in NFPA and AHJ forms for compliance” and have “limited deficiency tracking and reporting” because they treat fire safety work “as simple service calls rather than recurring compliance obligations tied to specific equipment” (Uptick).
The Asset Is the Record, Not the Ticket
The practical difference shows up in what the system treats as permanent. NFPA 25 requires inspection, testing, and maintenance records to be retained for at least one year past the next scheduled ITM event of that type (QRFS). That means the retention clock is defined relative to a future event on that specific piece of equipment, not relative to when any given job or ticket closes. The standard itself assumes the asset is the thing with a timeline, not the visit.
In an asset-based model, that’s exactly how the data is structured: every extinguisher, sprinkler head, panel, or door is its own record, with every inspection, defect, and repair logged against it permanently. A job — a technician’s visit on a Tuesday — is an entry in that asset’s history, not the container the history lives inside. When the next inspection comes due, it’s scheduled against the asset’s own cadence, not against whatever ticket happens to be open.
What Breaks When You Force Compliance Into a Job-Based System
The failure mode is usually invisible until someone needs the history. A defect gets logged during a job, a repair gets scheduled as a separate job, and by the time it’s completed, the connection between “this defect” and “this specific asset’s ongoing record” depends on someone manually cross-referencing ticket numbers. Multiply that across a few hundred assets and a few years of technician turnover, and answering “when was this specific extinguisher last serviced, and what was found?” turns into a records-archaeology exercise instead of a lookup.
Chronic under-inspection shows up at scale even outside the US. An analysis of over 100,000 fire door inspections by the UK’s Fire Door Inspection Scheme found 75% failed to meet the required standard, with excessive door or frame gaps as the leading cause (IFSEC Global; Guild of Architectural Ironmongers). That’s UK data under a different code (BS 8214), not a US NFPA 80 compliance rate. But it makes a point that generalizes: opening protectives are an asset class that’s easy to lose track of when no system treats each door as a permanent, individually tracked record.
NFPA’s own research on fire sprinklers found they operated in 92% of structure fires large enough to activate them between 2017 and 2021, and were effective at controlling the fire in 97% of those incidents when they did (NFPA, “U.S. Experience with Sprinklers”). Equipment performs when it’s kept in the condition the standard assumes, which depends on inspection history being tracked against the right asset, not scattered across closed tickets.
What an Asset-Based Data Model Looks Like in Practice
Concretely, the model needs a few things a job-based system doesn’t prioritize:
- A permanent record per physical asset — not per work order — that every inspection, test, defect, and repair attaches to for the life of the equipment.
- Cadence tied to the asset type and its governing standard, so a quarterly-tested device and a 50-year-clock sprinkler head are each scheduled correctly without a human remembering which rule applies to which item.
- Defect-to-repair traceability that follows the asset, so a failed inspection and the repair that resolves it are linked to the same equipment record, not just to each other’s ticket numbers.
- Multi-site, multi-asset reporting that can answer “show me every non-compliant device across all our sites” — a query that’s straightforward against asset records and painful against a pile of historical tickets.
This is the specific gap Quri is built to close: an asset-based, AI-powered inspection and compliance platform for fire and life safety trade businesses, built around the individual asset and its compliance standard rather than adapted from a generic job-based CRM. You can read more about why we built it this way.
Job-based systems are the right tool for a series of independent, self-contained visits. Recurring, standards-driven compliance work is different: a population of physical assets, each with its own history and its own clock. The software should be built around the asset, not the visit.