ENGINE 13

SFS-E13-WRC · INSURANCE CLAIMS · REV 2026-07-22 · PRODUCTION

PRODUCTION = runnable end-to-end, CI-backed, full test suite passing. All data fictional and seeded.

Warranty Reimbursement

The pool is finite

A builder buys a warranty policy at the start of a project, then spends years claiming against it a few thousand dollars at a time. Each claim is trivially small; the policy behind them is not, and it is finite. This engine reads the artifacts the programme emits and runs twenty-two deterministic controls over them: are the policy terms internally consistent and is the pool intact, does each claim sit inside its policy period and its own quarterly window, is there a real warranty cost behind every claimed dollar, did the unit close before the defect, and is the money going to the insured entity. It never files, never pays and never writes to a source artifact.

The failure mode here is accumulation. Any one claim is obviously fine, and nobody reviewing a single claim can see the running total or the boundary it is about to cross. A quarter still foots with an uncovered claim inside it. The engine ships one planted defect per registered control, so the benchmark is a command rather than a claim.

Run it Book a consultation

Architecture

functional block stack · static overview

Select a layer

Six control families run in registry order over each claim file. The first proves the others had something to read.

Key specifications

at a glance

10,299¹

Tests

the collected checks that pin this engine's behavior

22²

Controls

independent rules run over every claim file

6³

Families

groups of controls, each answering one question

25⁴

Claim files

one clean baseline plus one planted defect per control

5⁵

Artifacts read

policy, submission, claims history, cost ledger, closed units

0⁶

Tolerance

one cent past the coverage limit is a failure

What it does for you

plain terms

A warranty policy is bought once and drawn down for years in amounts too small to attract review. That combination is what makes the programme go wrong. The pool is finite, but no individual claim is anywhere near the limit, so the running total is the only place the breach is visible and nothing in a claim form shows it. The coverage limit itself descends from two derivations nobody re-examines after the policy is bound, so an error at inception rescales everything measured against it afterwards. And every claim sits at three boundaries at once -- its quarter, the policy period, and the close of escrow of the home it belongs to -- of which only the first is obvious from the document being reviewed. A claim dated outside the policy still lets its quarter foot perfectly. A defect claimed before the home was sold looks identical to one claimed after. These are not judgment calls; they are date comparisons and a running sum, which is what a deterministic control does better than a reviewer approving a $640 cabinet repair.

The seeded demo runs every control over every claim file⁷. The CLI generates 25 fictional claim files -- one clean baseline and one carrying each planted defect -- then runs all 22 controls over each. The clean file returns PASS with no flags; every defect file returns REVIEW or FAIL and names the control it tripped along with the reason that control exists.

A claim inside its quarter, outside the policy⁸. A test dates a claim one day past the policy end while leaving its quarterly window wide enough to contain it. The policy-period control fires and the quarterly subtotal control stays silent -- demonstrating why the two checks are deliberately separate rather than merged.

The pool is exact at its boundary⁹. Cumulative reimbursement equal to the coverage limit to the cent passes; one cent more fails. A companion test asserts the exhausted pool is flagged for review rather than failed, because spending it precisely is valid and somebody still needs to know.

Functional block diagram

engineering · each block links to its source

Plain terms

Seeded Claim Files. fictional claim files enter the control registry
Structural Precondition. is the claim file complete enough to read
Policy and Pool. is the coverage limit real, and is there any left
Claims and Periods. does each claim sit inside the right window
Cost Behind the Claim. was the money actually spent, on a covered thing
Coverage Begins at Close. had the home been sold before the defect
Remittance. is the money approved and correctly directed
Warranty Cost Ledger. the job-cost transactions each claim is checked against
Verdict and Findings. every finding, with the reason it exists, ends at a person

Engineering

Seeded Claim Files. generate_corpus writes one clean baseline plus one planted defect per registered control, 25 files in total. Only construction cost, the two policy rates and the repair events are stated; premium, coverage limit, policy end, every subtotal, the cumulative total and the cost ledger are derived.
Structural Precondition. Two controls. Fails a file missing any of the five artifact types, so no downstream rule can hold vacuously.
Policy and Pool. Six controls re-deriving premium, coverage limit and policy term, then holding cumulative claims inside the pool.
Claims and Periods. Six controls: subtotals foot, subtotals sum to cumulative, the request matches this quarter, and two separate date boundaries plus cross-quarter duplicate detection.
Cost Behind the Claim. Three controls tracing each claim to a warranty-coded job cost transaction of the same amount.
Coverage Begins at Close. Two controls: the unit must have a recorded close of escrow, and the claim must be dated on or after it.
Remittance. Three controls over the insured entity, wire completeness and approval.
Warranty Cost Ledger. Warranty costs at the designated cost codes. A cost outside them is not a warranty cost whatever its description says.
Verdict and Findings. Findings roll up per claim file: any FAIL is FAIL, FLAGs without FAILs are REVIEW, clean is PASS. The CLI exit code is the verdict, so a pipeline can gate on it. Reports carry no timestamps or absolute paths, which is what makes the committed report diffable.

Instruction set

every public command

Command	Operation	Output	Exit	Artifacts
`python run.py`	generate the seeded fictional corpus, run all twenty-two controls, write both reports	per-file verdicts and every actionable finding, then the overall verdict	2 for the bundled corpus, which carries one planted defect per control by design	warranty_report.md, warranty_report.json, samples/
`python -m warranty_engine samples`	analyze an existing folder of claim files without regenerating it	per-file verdicts and findings	0 PASS / 1 REVIEW / 2 FAIL / 3 usage	none unless --json or --md is passed
`python -m warranty_engine samples --generate --quiet`	regenerate the corpus and print only the overall verdict	a single verdict line	0 PASS / 1 REVIEW / 2 FAIL / 3 usage	samples/
`python -m pytest`	run the full test suite for this engine	10299 passed	0 when every test passes	none

Benchmarks

measured demo results

Measure	Result
Engine tests¹⁰	10,299 tests collected live collection from the engine directory
Registered controls¹¹	22 controls counted from the registry, not from documentation
Planted defects¹²	24 defect files every registered control has at least one file that trips it
Control coverage¹³	100 percent of controls with a planted defect no control ships without a file demonstrating it firing

Control characteristics

engineering

Plain terms

The engine has no write path and therefore no autonomy to gate. It produces findings; a person decides.

Engineering

Deterministic envelope. seeded fictional inputs, read-only operation, offline default mode.

Demo gate. FAIL on the bundled corpus, by design -- it carries one planted defect per registered control

Severity	Verdict	Action
No findings above PASS	PASS	send the mechanically clean submission to the documented manual review
One or more FLAG, no FAIL	REVIEW	a human resolves each flag; a nearly exhausted pool and incomplete wire details both land here
One or more FAIL	FAIL	the submission does not go to the insurer until the failing control is cleared

Read-only: claim files are parsed and never written back, so the engine cannot introduce the defect it reports.
Integer cents throughout, compared with exact equality; there is no tolerance band anywhere in the registry.
A value that should be integer cents but is not produces an AMOUNT_INVALID finding contained to the one row it was read on, rather than being coerced.
Deterministic and byte-stable: same inputs produce the same findings in the same order, with no timestamps or absolute paths in any output.
Absent evidence is never a passing control; an unreadable policy period fails the claims that needed it rather than skipping quietly.

Operating limits

what it refuses to do

The engine never files a claim, pays one, or writes to a source artifact. It reports and stops.¹⁴
It reads the five artifacts the programme keeps. It does not connect to an insurer, a bank or a job-cost system.¹⁵
It checks that a claim traces to a warranty-coded cost, not that the repair was necessary or reasonably priced. That judgment is a reviewer's.¹⁶
Whether a defect is covered under the policy's terms is a coverage question the engine does not answer. It checks dates, codes, amounts and totals.¹⁷
All shipped data is fictional. The corpus demonstrates the controls; it is not a record of any real policy, insurer, unit or claim.¹⁸

See it run

brand animation

Warranty Claims diagram: a left-to-right derivation chain reading construction cost, premium, coverage limit; below it a meter showing claimed to date against coverage left; below that three cards each reading every claim must be inside the policy period, inside its own quarter, and after close of escrow; and a row of the six control families with their counts. — The Warranty Reimbursement engine tile states the two things a claim programme has to hold at once: a coverage limit derived from cost and premium, and a finite pool draining against it.

Integration

how to run it

Distribution: public repository, MIT license.

python run.py

python -m pytest

Source on GitHub Engine README All tests, by engine Run in Codespaces

Substantiation

1python -m pytest --collect-only -q -o addopts= (warranty-reimbursement-automation/)
2len(warranty_engine.engine.REGISTRY)
3distinct rule-id prefixes in warranty_engine.engine.REGISTRY
4samples/*.json after python run.py
5len(warranty_engine.model.DOC_TYPES)
6warranty_engine/tests/test_control_semantics.py
7python run.py (warranty-reimbursement-automation/); output re-run on demand
8warranty_engine/tests/test_control_semantics.py::test_claim_one_day_past_policy_end_fails
9warranty_engine/tests/test_control_semantics.py::test_cumulative_exactly_at_the_limit_passes
10python -m pytest --collect-only -q -o addopts= (warranty-reimbursement-automation/)
11len(warranty_engine.engine.REGISTRY)
12len(warranty_engine.generate.DEFECTS)
13warranty_engine/tests/test_planted_defects.py::test_every_registered_rule_has_a_planted_defect
14warranty-reimbursement-automation/README.md and warranty_engine/tests/test_readonly_and_determinism.py
15warranty_engine/model.py DOC_TYPES
16warranty_engine/engine.py cost_claim_traces_to_ledger
17warranty_engine/engine.py clm_claim_inside_policy_period
18warranty_engine/generate.py

Show us where the hours go.

One conversation: you describe the work that consumes your team's month; we tell you plainly what this engine can take over, what it can't, and what a scoped first phase would cost. Your people keep approval authority.

Book a free consultation