Finding the component group
Macro-F1 balances performance across component groups. Higher is better; 1 is a perfect score.
The AI models outperform the free text classifier on this sample. The comparison model ran on fewer cases.
Field Return Triage · independent project
A returned part can pass the standard test and still have a fault. I built a tool that finds failure clues in the complaint, checks the exact words behind them, and suggests what a technician could test next.
Uses public vehicle complaints as stand-ins for return reports. The suggested tests are examples to adapt to a lab.
The AI suggests. Code checks. People decide. No result closes, scraps or returns a part.
The complaint-to-card pipeline, verbatim quote checks, safety rules, similar-case search, a configurable test rulebook, and a reproducible evaluation.
Choose a recorded case. Compare the original words with the suggested test, then try the review controls.
Recorded examples, not live AI. These controls make no requests and save no decisions.
The results describe this evaluation sample. They do not establish performance on real returned parts.
Macro-F1 balances performance across component groups. Higher is better; 1 is a perfect score.
The AI models outperform the free text classifier on this sample. The comparison model ran on fewer cases.
Primary model plus hard rules, compared with the coded crash, fire and injury fields.
The evaluation deliberately oversamples safety cases. High recall comes with many extra cases for a person to read.
Brackets show 95% bootstrap confidence intervals: the uncertainty around each estimate. “Unclear” counts as wrong for component-group scoring. The comparison model stopped early at the budget cap, so these are not equal-size model trials.
The page does not pick a model. The project locks its choices to a versioned evaluation card, with a pinned source commit.
A separate rule watches weekly complaint counts. The useful question is whether its alerts precede recalls more often than random weeks do.
| Week starting | Complaints | Event |
|---|
This is a measured portfolio project. It has no production queue, authentication or validated deployment in a returns lab.
The same committed data that renders this page, including the example cards and uncertainty intervals.
Which returned parts need a closer look, and which test should run first? The flow keeps the original complaint attached to every suggestion.
Read the complaint for symptoms, conditions and safety indications. Return a quote for each clue.
Drop any clue whose quote does not appear in the original complaint.
Safety goes to priority 1 with human review. Unclear cases go to human reading.
Find similar past cases. Map the checked clues to tests, inspections and questions.
Accept the suggestion or change it with a reason. The real pipeline logs this feedback.
The Python command-line pipeline replays committed model responses. Its tests run with network access blocked. New text requires an explicitly configured model run and budget.
make page
make facts
make testThe component taxonomy and test rulebook are configurable. A lab would supply its own parts, complaint records and actual tests. The code still checks quotes, enforces safety rules and requires a person’s decision.
The separate trend path uses weekly counts and a statistical spike rule, without calling an AI model.
The recorded evidence could not be loaded. Reload this page to try again. The project explanation and static example remain available above.