Methodology
How PaxExact handles co-insurance and business income
PaxExact's co-insurance and business-income calculations check readiness first, then let a professional accept the result or override it with a reason.
·
In short
PaxExact's commercial-property calculations — co-insurance and business income — check whether the required inputs exist before computing anything, and refuse to guess when they don't. Once computed, a figure is either accepted as-is or overridden with a documented reason by a professional; the original calculation is always preserved alongside any override. Co-insurance is in beta, released in September 2026; business income is coming soon, with no screen in the app.
- A co-insurance or business-income calculation runs only after a readiness check confirms the required inputs exist; a missing input is reported explicitly, never defaulted.
- A co-insurance determination reports whether the coverage is compliant with its coinsurance condition or penalized, following one documented, versioned formula.
- A professional can accept a computed figure as reportable or override it with a different figure and a written reason; the computed figure is preserved either way.
- Business income calculations are entered by the professional as inputs and computed by the platform, with the same accept/override discipline.
- Commercial-coverage co-insurance is in beta, released to production in September 2026. The business-income calculation is coming soon: the platform computes it, but there is no screen for it in the application and it is not in the case report.
Readiness before calculation
Before PaxExact computes a co-insurance figure, it can answer a narrower, prior question: is this coverage even ready for a determination? That check looks at whatever is currently on record — the value at risk, the amount of insurance carried, the coinsurance percentage, any documented waiver — and reports one of two states: the coverage is ready for a determination now, or it is not, with every missing or inconsistent fact named and where it should come from.
This is a genuinely separate answer from just attempting the calculation and seeing whether it fails. A calculation request can also supply some of those same facts directly at the time it is run — a stated value at risk, for instance — so a coverage that is not yet 'ready' on the record can still produce a valid determination when the missing fact is supplied with the request. Readiness describes the record as it stands, not every possible request.
The reason readiness is exposed as its own answer, rather than left implicit in whether a calculation succeeds, is that 'what does this file still need' is a question an operator needs to answer before attempting anything — not just after a failed attempt. Reporting NEEDS_INPUT as a first-class state, with every missing fact named and where it belongs, turns that into something a person can act on directly, rather than something inferred from an error message.
The co-insurance formula, worked as a standard example
Co-insurance is a standard commercial-property provision: a policyholder who insures a property for less than a required percentage of its value shares proportionally in any loss. PaxExact computes it with one fixed, versioned sequence, so the same inputs always produce the same, reconstructable output:
Standard coinsurance sequence (illustrative figures)
Compliant, penalized, and why interpretation is separate from arithmetic
A determination reports whether the amount of insurance carried meets the coinsurance requirement (compliant) or falls short of it (penalized, with the ratio that produced the shortfall). The arithmetic that produces that answer is fixed and versioned; anything that is instead a judgment call about how a specific policy's terms should be read — for instance, whether an endorsement suspends the coinsurance condition altogether — is recorded as a separate, explicit interpretation, entered by a person and carried alongside the calculation rather than silently baked into it.
Every step of the calculation is reported, not just the final figure, so a reviewer can recompute it by hand against the same documented sequence. This is deliberate: commercial-property forms vary across carriers, and a calculator that quietly encoded one carrier's reading of the deductible or the limit would be wrong for the next claim and impossible to audit. PaxExact's v1 formula applies the deductible before capping at the coverage limit, states that ordering plainly, and leaves any different ordering to a future, separately versioned formula rather than a silent variant.
Money inputs are validated to the cent and rejected — not silently rounded — if they carry more precision than that; a figure outside the recordable range is also refused with a reason rather than allowed to fail later downstream. The same coverage, the same loss, and the same formula version always produce the same recorded snapshot, whether the loss figure was written as '100000' or '100000.00' — the calculation treats those as one identical input, not two.
Accept or override — never a silent rewrite
A computed figure does not become the reportable answer on its own. A professional either accepts the calculated figure as the one to report, or records a different reportable figure with a written reason. Whichever path is taken, the original calculated figure is preserved and reported alongside it — an override never substitutes for the underlying arithmetic; it sits next to it.
The same accept/override discipline applies to business-income calculations, which follow their own worksheet: inputs — expected and actual revenue, expenses that continue regardless of the loss, expenses avoided because of it, extra expense reasonably incurred to reduce the loss, and any recovery already realized — are entered by the professional, and PaxExact computes the resulting figure. Accepting or overriding that figure is recorded the same way, with the computed result always visible.
Both calculations also treat a stale snapshot as something that cannot simply be adopted later. If the facts a calculation was based on move after it was computed — a coverage term is edited, or an underlying figure changes — the snapshot is reported as superseded by that staleness rather than silently left available to accept as though nothing had changed. A person who wants to report against current facts recomputes; a person looking back at a determination made while it was current can still see it, but sees plainly that the facts have since moved.
What's real today
Commercial coverage records, the co-insurance readiness check, calculation, and accept/override actions are in beta and were released to production in September 2026. The business-income calculation is coming soon: its inputs, computation and accept/override record exist in the platform, but there is no screen for it in the application yet, it is not included in the case report, and the loss period is entered by hand with no period-of-restoration logic. For co-insurance, beta means the underlying behavior — readiness checks, one documented formula, and the accept/override discipline described here — is real and in use, while the scope and output are still being refined; expect rough edges rather than a finished, unchanging surface.
Sources
Where this comes from
Related