PaxExact's human approval gate, explained

PaxExact is built around one non-negotiable checkpoint: nothing advances to a priced, reportable estimate without an explicit approval step by a licensed professional. This is not a workflow suggestion or a best-practice recommendation in a manual — it is enforced at the API layer. An unapproved scope item is structurally excluded from totals and from any exported case file, regardless of whether it already has a price attached.

The practical effect is that a proposal — whether it came from a template, an estimator's own entry, or an AI-assisted observation — can sit in the system fully formed, priced, and ready, and still contribute nothing to the estimate a carrier or client will see until a person takes the approval action on it.

This is a deliberate design choice, not an incidental one. An estimating platform that lets scope, quantity, or price advance automatically is making a claim about the property that no one has actually verified. PaxExact's contract instead treats 'approved' as a fact about a specific person's decision at a specific point in time — something that can be pointed to, not inferred from the mere presence of a plausible-looking number.

Every quantity on a line item carries two related pieces of state. quantity_state describes the quantity's currency: CURRENT (up to date), SUGGESTED (proposed but not yet acted on), or STALE (the facts behind it have moved since it was set). review_state describes what a human has done with it: approved, suggested (awaiting a decision), or stale.

Each quantity also records proposed_by — whether a person entered it or the system proposed it. That distinction matters downstream: a system-proposed quantity is exactly the kind of figure the approval gate exists to catch before it silently becomes part of a reportable number.

Reporting quantity_state and review_state as separate fields, rather than collapsing them into a single status, is deliberate: a quantity can be CURRENT (nothing about the underlying facts has moved) while still being unreviewed, and a quantity can be STALE while still showing the review decision that was made before it went stale. Keeping the two separate lets a reader answer 'is this still true' and 'has a person signed off on it' as two different questions, because they often have different answers.

Anything PaxExact's AI-assisted analysis proposes — a damage observation, a suggested quantity — is exactly that: a proposal. It carries proposed_by: ai and a review_state that is not approved. It does not count toward a total, a report, or any downstream calculation until a professional explicitly accepts it. There is no path by which an AI proposal advances on its own; acceptance is always a distinct, human action.

This is the same fail-safe principle that governs PaxExact's evidence pipeline more broadly: the system proposes, and only a person's explicit action turns a proposal into something that counts.

Acceptance and rejection are both explicit, recorded actions — accepting a proposal is not the default outcome of leaving it alone. A proposal that sits unreviewed stays a proposal indefinitely; it does not age into an approved state on its own, and it does not silently expire into being treated as rejected either. Someone has to look at it.

A line item's underlying facts — its measurement, its evidence, its pricing basis — can change after the line was last reviewed. When that happens, the line is marked stale, and PaxExact refuses to let it be edited silently: an attempt to write to a stale line returns a 409 response rather than accepting the edit against facts that are no longer current. The reviewer has to look at what changed and re-approve, rather than an edit quietly landing on top of outdated context.

This protects the meaning of 'approved.' An approval recorded against one set of facts should not be allowed to silently keep governing a line whose facts have since moved — the 409 forces a fresh look instead.

In practice, a line goes stale when something it depends on changes after it was last reviewed — a measurement is corrected, a piece of evidence is superseded, or a pricing basis moves. Rather than letting that change ride along invisibly under an old approval, PaxExact surfaces it as a blocked write, so the person who re-approves the line is necessarily looking at the current facts, not the ones that were true when it was first reviewed.

Estimates are not edited in place indefinitely; they carry revisions, and each line item's review state is tracked within that history rather than collapsed into a single before/after snapshot. A supplement or a revised scope does not inherit approval from a prior version by default — the review state travels with the specific line and its specific facts.

This matters for anyone reconstructing why an estimate looks the way it does later — an insurer's audit, a dispute, or simply an adjuster returning to a file weeks later. Because review state is per-line and per-revision rather than a single overall flag, it is possible to see exactly which lines were approved when, rather than only knowing that 'the estimate' was approved at some point in its history.

Approval is performed by a licensed professional within the customer's own organization — the person with authority over that estimate, not PaxExact staff and not an automated process acting on the customer's behalf. PaxExact assembles and links the evidence, proposes where it can, and computes what it is asked to compute; the decision to advance a scope item into a priced, reportable estimate belongs to that professional, every time.