ReserveEstimatorGKR

What it is

ReserveEstimatorGKR sets the reserve a carrier carries on a claim, by head. It replaced the last two unrebuilt tools in the FNOL pipeline, AutoDamageEstimatorGKR and WCBenefitsCalculatorGKR, under a single rewrite directive . It is built LOB-agnostic against seeded specs; the harness was rewired with AutoDamageEstimatorGKR removed entirely, and six acceptance cases pass across FL and NY Auto and NY and TX WC . It is step 8 in the Trace Contract Program lineup .

One engine, two record sets

Vehicle valuation and statutory WC benefit schedules look unrelated and are one engine plus two record sets. The consolidation test that found this is the one the manual teaches: to find the real boundary between two tools, ask what remains in code once every rule, table and threshold has moved to records. The converse also applied. What looked like one tool, WC benefits, is two questions, a statutory entitlement and a carried reserve; entitlement went to CompensabilityAnalyzerGKR and the reserve stayed here .

Nothing is estimated

Every money head is one of: stated, computed from stated inputs, pending (rate and limit only), excluded, or indeterminate . A rental stated as a daily rate with a day limit is pending; rate times limit is never computed, and an adapter that recomputed a rental total was reverted by ruling twice. A stated value and a valued value are different facts and never share a field: what the insured says the vehicle is worth is a party statement with a span, what a valuation vendor returns is a valuation, and only the second can drive a settlement basis.

Zero and unknown are different statements, and in a financial figure the difference is a misstated balance sheet. A head with an unresolvable basis is indeterminate; the total reports both what resolved and what did not. The field is resolved_reserve, not total_reserve. The primary head carries a materiality flag, and an unresolved primary head forces a provisional posture rather than passing a low number to the authority gate. A reserve rendering $0 beside 0 percent completeness tells an adjuster the claim is worth nothing; "not established, 0 of 5 heads resolved" says what is true.

Reserves are carried gross. Netting an anticipated subrogation recovery into the reserve understates the exposure the carrier must hold, which is a financial-statement consequence rather than a claims one. Reserve and recovery are shown separately on every output.

Repair cost held against an open total loss question is the current best estimate, not a floor, because a total loss settlement is frequently below the repair estimate; the head is partial and can move in either direction. Contingency is not a head: a buffer over exposures is not an exposure, it double counts under a carrier overlay, and a percentage computed on resolved heads shrinks exactly as uncertainty grows. It belongs in the aggregation rule, which states what it does not compensate for.

Fallbacks and dead inputs

Fallback tables are the purest form of the wrong number that looks authoritative. The Auto tool would produce a complete reserve from platform constants during a database outage with nothing in the output to say so. A fallback that activates on infrastructure failure is not resilience; failing closed is. A dead input is worse than a missing one: liability_percentage and jurisdiction_state were accepted and silently ignored, so the interface promised a comparative-fault adjustment and a state-specific total loss threshold that never happened.

When a defect is fixed, sweep its class. The WC tool's state-maximum work was exemplary (no cross-state default, data_gaps, rate_verified, state_cap_unknown) while the same file still defaulted waiting period, retroactive period, maximum duration and the statutory rate percentage across all states. Data gaps are a routing decision, not a footnote; raising them to the top level so a recipe can branch is the pattern to generalise. Effective dating resolves by event date, not newest record: reading max_weekly_2026 ahead of 2025 regardless of injury date gives an older claim a rate that did not exist when it happened.

Records and curation status

Curation status propagates down the dependency chain. Three valuation tables sat active with no curator, no verified_on and no source authority while the spec depending on them was approved, which inverts the relationship. Active is the platform's claim that a record was curated and regressed; a record that was neither is approved with a fixture note. Status is an assertion about provenance, not a deployment flag.

The WC reserve methodology chunk turned out to be stale. The right answer was neither citing it as live nor dropping the reference: name what it contains, that it is stale, and declare the tables platform judgment pending re-curation. A structure recorded as unknown is a gap, not a note; reading a table nobody has opened is how the coverage analyzer ended up with triggers naming facts that did not exist.

A refusal must be specific

An indeterminate looks identical whether the parameter is missing or the lookup is broken, which has already cost the program a review round. One jurisdiction is seeded properly and both branches exercised. NY resolving while TX names the missing parameter, the state and what would resolve it is the multi-state path working, and a more valuable demonstration than a second seeded state.

Open items

A $45/day rental rate still sits in a platform table when rental reimbursement is a policy limit. A threshold_value against threshold_pct naming mismatch is papered over by a comment. The valuation tables await re-curation with a named curator and source authority.