From photo to line item: PaxExact's record model

Many estimating workflows describe damage as a single narrative: a paragraph of scope, followed by a list of line items that are asserted to follow from it, without any structural connection between the two. PaxExact instead treats a photo, a damage observation, a measurement, and a line item as four distinct kinds of record, each with its own identity, linked to the ones around it rather than folded into a shared description.

The reason for the separation is traceability. If a line item is just a row in a spreadsheet, the only way to check it is to trust whoever wrote it. If a line item is a record that links to the observation that justified it, which in turn links to the measurement and the photo behind it, then a reviewer — or an AI system checking the estimate later — can walk that chain and verify the claim against the actual evidence, rather than against a description of it.

This also means the four record types can each evolve independently without breaking the others. A measurement can be recomputed, a photo can be re-analyzed, or an observation can be corrected, and because each is its own record with its own links, the effect of that change is visible at exactly the point in the chain where it happened — rather than requiring the whole scope narrative to be rewritten and re-checked from scratch.

The chain runs in one direction, evidence to conclusion. A photo is captured and attached to a specific room or damage area on the claim. A damage observation — a discrete, specific claim about what the photo shows — is recorded and linked to that photo. A line item in the scope is linked to the observation (and, where relevant, to a measurement) that supports it. Finally, a price is attached to the line item, carrying its own provenance as described in PaxExact's pricing methodology.

Nothing skips a link in that chain by design. A line item that exists without any linked evidence is visibly different from one that traces back to a photo — the record model makes the difference checkable rather than a matter of the writer's word.

That checkability is the point of building the chain as data rather than as prose. A written estimate narrative can describe a repair and imply it was observed; a linked record either has a photo behind it or it does not, and that fact is queryable rather than asserted. For a carrier, a public adjuster, or an AI system verifying a claim later, the difference between 'this was described' and 'this can be traced to a specific photo' is exactly the distinction the record model is built to preserve.

Evidence-linked scope records — the data model and the links themselves — are live in production, along with photo capture attached to specific rooms and damage records, and server-computed measurement with an accept/reject review step. These are the load-bearing pieces of the record model, and they are in real use today.

AI-assisted damage observations from photos are in beta: an uploaded photo can be analyzed into a proposed observation, always tied to that specific photo. Being in beta means the scope and output of that analysis are still changing, and rough edges are expected — but the underlying behavior (a proposal, tied to evidence, requiring acceptance) is the same behavior that will remain once it graduates out of beta.

Turning an accepted observation into suggested line items is also in beta. The quantity comes from the observation's own extent, and each suggested line keeps its link to the observation and the photo behind it. The scope is limited — specific repair operations are suggested for water damage to walls, ceilings, floors and baseboards, and smoke, soot or mold damage to walls, ceilings and floors (water damage to a floor does not include replacing the floor covering); other observations become a line with no code or price unless exactly one code fits — and no suggested line counts toward a total until a professional approves it.

PaxExact's AI-assisted analysis is built to fail safely rather than to always produce an answer. If there is no photo to analyze, there is no proposal — the system does not substitute a generic or inferred observation when it has nothing to look at. A proposal is always anchored to a specific piece of evidence; it is never a guess presented as if it were grounded in something the system actually examined.

This is the same principle that runs through PaxExact's approval gate: a proposal is a claim that still needs a person to accept it, and the system's role stops at proposing, never at asserting.

The record model is also what makes a defensible case-file export possible later: a case file that carries evidence, scope, and pricing together is only as trustworthy as the links between them, and those links have to exist from the moment a photo is captured, not be reconstructed afterward from a narrative. Building the chain into the record model from the start, rather than adding traceability as a reporting feature bolted on at the end, is why a PaxExact estimate can be checked against its own evidence rather than merely read.

It also means the parts of this chain that are still maturing — AI-proposed observations and suggested line items, both in beta — inherit the same traceability requirement as the parts that are already live. A suggested line item carries the same photo-to-observation link this page describes; it changes who drafts the line item, not whether the evidence behind it can be checked or who approves it.