Jev library/Dishwasher warranty reliability

An example model for the Jev library: turning technicians' free-text service notes into a failure model, a warranty reserve, a spare-parts plan and a design decision.

Live Jev calls require the Analytica Enterprise edition or better with a Jev API key. However, the model also runs in any Analytica edition without an API key using cached Jev responses, which includes the warrantee model. Analytica 7.2 or better recommended.

To run the model you need two files: Dishwasher warranty reliability.ana and Jev library.ana, in the same folder. See Downloads for these and the data files.

The story

Larkspur Appliance Company is a mid-sized appliance maker. In January 2024 it launched the QuietClean 24, a built-in dishwasher sold through kitchen retailers and installed by local contractors. Every unit carries a two-year parts-and-labor warranty. When something goes wrong, the owner calls Larkspur, an authorized technician visits, and the technician files a short note with the warranty claim.

By 1 October 2026, about 3,100 QuietClean 24s are in kitchens, and technicians have made 477 warranty service calls. The notes read like this:

Cust reports DW not draining, standing water in tub. Filter clean, sump clear. Drain pump hums but impeller does not turn. Replaced drain pump DP-220. Tested good.

Homeowner reports water standing in the bottom. Filter completely clogged with food debris and labels. Cleaned filter, showed customer how to clean monthly. No parts used.

Customer reports E4 code on first use. Installed today. Garbage disposal knockout plug was never removed by installer. Knocked out plug, cleared.

E4 code. Repl pump.

All four start with the same complaint: the dishwasher won't drain. Only the first is a failed drain pump. The second is a dirty filter, the third an installation mistake, and the fourth doesn't say which of the dishwasher's two pumps was replaced.

Larkspur's reliability engineer has been asked three questions:

Warranty reserve. How much should Larkspur set aside for warranty costs over the next 12 months?
Spare parts. How many of each part should the parts depot stock for the next quarter, so technicians rarely wait for one?
The drain pump. A supplier offers an upgraded drain pump for $8.50 more per unit. Its accelerated life tests suggest it fails about half as often. Should new production switch?

The structured data (install dates, service dates) shows when units needed service, but not why. The why is in the notes, and nobody has time to read and code 477 of them by hand every quarter. This model uses Jev to read them.

Larkspur, the QuietClean 24 and all the data are fictional. See "How the data was made" below.

Using the model

Download the model and the library (see Downloads) into the same folder, and open the model.
The top diagram shows the story, the Jev answers choice, the modules, and the key results:
- Warranty cost, next 12 months and Warranty reserve (90th percentile)
- Spare parts to stock
- Upgrade savings per 1000 units, Probability the upgrade pays off and Break-even price of the upgrade
Click a result and press the Result button. For uncertain results, try the Probability density and Statistics views.

Saved answers or live calls

Jev answers chooses where Jev's reading of the notes comes from:

Saved answers (the default) uses answers recorded when the model was built. It needs no API key, costs nothing, and gives the results described here.
Live Jev calls sends all 477 notes to Jev again. This needs a Vercel AI Gateway API key in the JEV_API_KEY environment variable (see Jev library#Setup). It takes a minute or two and costs about two cents. Jev's answers can vary slightly from run to run, so results will be close to the saved ones but not identical.

Live calls matter when you change the questions. For example, you might edit a cause's description in Cause description, or add a cause, and want to see how Jev's classification changes.

What the model finds

The numbers below come from the saved answers. Results with uncertainty are from Monte Carlo simulation with 1,000 samples, so they vary slightly between runs.

Reading the notes

Jev classified all 477 notes for about $0.02. An engineer had reviewed a random sample of 60 calls in detail, and Jev's most likely cause matches the engineer's on 59 of the 60 (Checking Jev's answers module). On average, Jev put 97% of its probability on the cause the engineer found.

The one disagreement is instructive: the note "E4 code. Repl pump." Jev can't tell from that which pump was replaced, so it splits its probability between Drain pump and Circulation pump rather than guessing. The model keeps that split. A note like this counts as part of a drain-pump failure and part of a circulation-pump failure, which is the honest summary of what the note says.

Failure rates by age

Failure rates (calls per 1,000 units per year, from Calls per 1000 units per year) show three patterns that matter for planning:

Cause	First 3 months	3–12 months	1–2 years	Pattern
Installation error	~140	~4	~1	Almost all in the first weeks
Control board	~46	~7	~6	"Infant mortality": early electronic failures
Drain pump	~2	~13	~66	Wear-out: rising sharply in the second year

The drain pump is the story. It barely fails at first, but in the second year it is the biggest single cause of calls. The fleet is young: only units installed before October 2025 have reached their second year. So drain-pump calls will keep climbing as more of the fleet ages, even if nothing else changes. A forecast built from one overall failure rate would miss that, which is why the model estimates a rate for each age band.

Each rate is uncertain, because it is estimated from a limited number of calls, and the model treats it as uncertain (a Gamma distribution). The second-year rates are the most uncertain, since the least fleet time has been observed at that age.

Warranty reserve

Over the next 12 months the model forecasts about 350 warranty calls and an expected warranty cost of about $86,000, with a 90% probability interval of roughly $74,000–$98,000. A reserve at the 90th percentile is about $96,000.

The largest costs are drain pumps (about $18,000), door seals (about $18,000, mostly water-damage claims from leaks) and installation errors (about $15,000). The installation costs suggest something worth raising with Larkspur's installer network, whatever the reserve decision.

Spare parts for next quarter

Spare parts to stock gives, for each part, enough to cover the next quarter's demand with 95% probability. Demand counts only calls where Jev judged a part was needed; dirty filters and installation errors use no parts. The drain pump needs the deepest stock, about 32 units, followed by the control board at about 13. Change Parts service level to see the trade-off between stock and the risk of a technician waiting for a part.

The drain-pump upgrade

With the current pump, a new unit can expect about 0.077 drain-pump failures during its two-year warranty. If the upgraded pump halves that, Larkspur saves about $6.60 per unit in warranty costs, less than the $8.50 the upgrade costs. Upgrade savings per 1000 units averages about −$1,900, and the upgrade pays off with only about 13% probability.

Break-even price of the upgrade is about $6.60. That gives the engineer a constructive answer: not at $8.50, but worth revisiting if the supplier can get close to $6.60, or if second-year failure rates keep rising as more data arrives.

Why not just search for "drain"?

The Checking Jev's answers module compares Jev with the obvious shortcut: count the notes that mention "drain". That finds 165 "drain" calls, compared with Jev's 100 drain-pump failures. The keyword sweeps in dirty filters, kinked or plugged drain hoses, and every note that says the unit "drained and filled normally" after a repair. Fed into the same upgrade calculation, the keyword count makes the upgrade look worth about +$400 per 1000 units: the wrong decision, for a reason no one would see in a summary table.

A caution about rare events

Jev rarely says "impossible". It gives nearly every call a small probability, 2–3%, of having caused water damage to the home. Summed over hundreds of calls, those small probabilities add up to about 31 water-damage calls. Yet only 17 notes clearly describe damage: those where Jev's probability exceeds 0.5. For common events, summing probabilities is the right way to count. For a rare event like water damage, a small "background" probability on every call can swamp the real cases.

The model therefore counts water damage as calls whose probability exceeds 0.5, chosen by Count water damage by in the Forecasts and decisions module. Switch it to Sum of probabilities to see the difference: the warranty reserve rises by about $25,000, and the drain-pump upgrade starts to look attractive. That is another wrong conclusion, this time from phantom claims. The general lesson: check Jev's answers against reviewed cases, and pay particular attention to rare outcomes.

How the model works

Module	What it does
Service call data	Two data tables, each imported from a CSV file: units installed per month, and the 477 calls (serial number, install and service dates, the technician's note, and the engineer's finding for reviewed calls).
Reading the notes with Jev	Asks Jev four questions about each note and collects the answers as Analytica arrays.
Failure rates	Counts calls by cause and age band, using Jev's probabilities, and divides by the fleet's unit-years in each band to give uncertain failure rates.
Forecasts and decisions	Projects fleet exposure forward, then computes the warranty cost forecast, spare-parts demand and the pump-upgrade comparison.
Checking Jev's answers	Compares Jev with the engineer's review and with a keyword count, and shows the two ways of counting water damage.

The questions Jev answers

Note_questions asks four questions about each call. Jev sees the product name, the days since installation, and the note.

Question	Jev type	Answer used for
What was the root cause? (11 options, each with a description)	Choice	Failure counts and rates by cause
Did the repair need a replacement part (installed or ordered)?	Noul (yes/no)	Spare-parts demand
How severe was the problem for the household? (minor / degraded / unusable)	Score	Shown for each call; not used in the costs
Does the note report water damage to the home?	Noul (yes/no)	Water-damage claim costs

The cause question tells Jev to classify by what the technician found, not the symptom the customer reported. That instruction is what separates a failed drain pump from a clogged filter. The cause options and their descriptions live in an editable table, Cause description, rather than inside the expression.

Counting with probabilities

Rather than taking Jev's top answer for each note, Calls by cause adds up Jev's probabilities. A note that is 60% drain pump and 40% circulation pump adds 0.6 to one count and 0.4 to the other. Summed over many notes, this gives an unbiased count when the probabilities are calibrated, and it doesn't throw away what Jev knows about ambiguous notes.

From counts to rates

A rate is a count divided by exposure. Unit-years observed totals how long the fleet has spent in each age band, from the installation dates and the analysis date. Given n calls and E unit-years, the rate's uncertainty is Gamma(n + 0.5, 1/E), the Bayesian posterior for a Poisson rate. Forecasts multiply these rates by the fleet's projected unit-years over the next year or quarter, including the planned 115 new installations a month, and draw Poisson counts.

Adapting it to your own data

To use this structure on real service records, import your own data into the two tables in Service call data: installations by month, and for each call the install date, service date and note. Then revise Cause description, Cost per call and Part number for your product. Before you trust the results:

Review a random sample of notes yourself, and compare in Checking Jev's answers. Fifty to a hundred is usually enough to find systematic misreadings.
Watch rare outcomes, as described above.
Keep Live Jev calls for when you change the questions. Each live evaluation of the whole batch is billed.

For a few thousand notes, the cost of reading them with Jev is still under a dollar. To refresh a large batch only occasionally, save the answers, as this model does, rather than calling Jev every time the model is recomputed.

How the data was made

The data is synthetic. A script (Dishwasher example data/make_service_calls.py) simulates the fleet. It starts from installations each month, and gives each cause its own failure rate by age band: the drain pump wears out, control boards fail early, and installation errors appear in the first weeks. Each simulated call gets a technician-style note, made from varied templates with abbreviations and inconsistent style. About 15% of the notes are deliberately terse, such as "Pump bad - replaced."

Because the data was simulated, the true cause of every call is known, which allows a check that a real company couldn't make. The true causes are kept in a separate file, answer_key.csv, so the data the model reads, service_calls.csv and installs_by_month.csv, holds only what real service records would hold. Jev's most likely cause was right on 98.5% of all 477 calls. Every miss was a terse note that doesn't say which pump failed. Its total drain-pump count, 100.5, was close to the true 104.

Downloads

File	What it is
Dishwasher warranty reliability.ana	The model. It contains all the data and Jev's saved answers, so it runs on its own with the library.
Jev library.ana	The Jev library. The model links to it, so it must be in the same folder.
service_calls.csv	The 477 service calls: serial number, install and service dates, the technician's note, and the engineer's finding for reviewed calls.
installs_by_month.csv	Units installed each month.
answer_key.csv	The simulated true cause, part need, impact and water damage of every call. The model doesn't use it; it is for checking Jev.
saved_jev_answers.csv	Jev's answers for each call, as embedded in the model.
saved_jev_raw.json	The full Jev responses for all 477 calls (1.4 MB).
export_jev_answers.txt	The Analytica expressions that saved the two files above from a live run.
make_service_calls.py	The Python script that generated the data (see How the data was made).
build_model.py	The Python script that wrote the first version of the model, which was then edited in Analytica. Don't rerun it on the current model.

Only the first two files are needed to run the model. The others are for re-importing the data, regenerating it, or checking Jev's answers yourself. To keep everything together, use this folder layout:

Dishwasher warranty reliability.ana
Jev library.ana
Dishwasher example data\
    service_calls.csv
    installs_by_month.csv
    answer_key.csv
    saved_jev_answers.csv
    saved_jev_raw.json
    export_jev_answers.txt
    make_service_calls.py
    build_model.py

When you download, save each file under the name shown in the File column. Your browser may suggest a name with underscores in place of spaces, such as Jev_library.ana; rename it, because the model looks for Jev library.ana. The wiki doesn't accept .py files, so the two scripts are stored as .txt files: save them with the .py names shown.