> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mathfi.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Use cases and evidence
> What MathFi.ai has been benchmarked on: credit, insurance fraud, clinical risk and signal integrity, against tuned XGBoost, LightGBM, CatBoost, Random Forest and Logistic Regression.
MathFi.ai works on any labelled, tabular data. It earns its place on the **rare, high-cost
decision**: the case that matters most and is hardest to catch.
Seven public datasets have been benchmarked against five widely deployed methods, each on an
identical 80/20 split, so differences reflect modelling capability rather than partitioning. Results
are reported on the **minority class**, because that is where the value sits.
Across the seven, MathFi.ai takes the highest minority-class F1 in six, and the highest or
joint-highest recall in all seven.
## The seven decisions
Each row is a specific, costly decision, with MathFi.ai's minority-class result.
| Use case | The decision | F1 % | Recall % |
| -------------------------- | --------------------------------------------- | ----- | -------- |
| **Credit approval** | Is this applicant a good or bad credit risk? | 88.50 | 90.91 |
| **Consumer default** | Will this borrower default? | 63.60 | 70.00 |
| **Warranty claim fraud** | Route this claim to an investigator? | 75.74 | 96.24 |
| **Stroke screening** | Prioritise this person for preventative care? | 27.04 | 66.00 |
| **Radar signal integrity** | Trust or discard this sensor reading? | 97.44 | 95.00 |
| **Cardiac disease** | Does this patient have heart disease? | 84.20 | 81.70 |
| **Clinical mortality** | Escalate this heart-failure patient? | 71.11 | 84.21 |
Full tables, every competitor score, the datasets and the methodology are on the
[benchmarks page](https://mathfi.ai/benchmarks/).
### What the numbers show
**Recall is the consistent signature.** In every domain tested, MathFi.ai surfaces more of the rare,
high-value cases than any competing method. On stroke screening it finds 66% of the people who go on
to have one, against 26 to 34% for the gradient-boosting methods. On clinical mortality it reaches
84.21% recall, nearly sixteen points clear of the field.
**Accuracy is the number to distrust.** On stroke, CatBoost posts the highest accuracy in that table
at 90.02% while catching 26% of at-risk patients. It is an accurate model and a useless screening
tool. MathFi.ai accepts 82.58% accuracy precisely because it is doing the job asked of it.
**Where it trails, it trails deliberately.** On warranty fraud, MathFi.ai reaches 96.24% recall
against 81.95% for the gradient-boosting methods, but those methods lead on F1 (82.26% against
75.74%) and precision (82.58% against 62.44%). That configuration is recall-dominant: it catches
nearly all the fraud and flags more legitimate claims to do so. Whether that is the right operating
point depends on what a missed fraud costs you relative to a false accusation.
**You choose the operating point.** On cardiac disease the same data produces a precision-tuned
model (F1 84.20%, precision 87.01%) and a recall-tuned one (recall 91.46%, over seven points clear
of the best competitor). That is the candidates table in
[Model Crucible](/products/model-crucible) doing its job: the trade is yours to make, not the
library's.
The radar dataset is not natively tabular. Its 34 features are derived from raw high-frequency
signal returns. That is the pattern for any non-tabular source: encode it as numeric features and
it is in scope.
## Worked end to end
The consumer-default row above, developed in full: the files, both products, the settings, the
candidate models and the numbers from a real run.
That walkthrough is a separate run from the benchmark, so its figures differ slightly. Refinement
results vary run to run, which the page says plainly.
## Does your problem look like these?
Three questions.
**Is the expensive answer rare?** Fraud that clears, machines that fail, claims that should have
been challenged. If your positive class is a small fraction of your rows, ordinary methods are
already struggling, whatever their accuracy score says.
**Is it tabular and labelled?** Rows and columns, with a known outcome per row. Data that does not
start out tabular still counts if you can encode it that way: signals, images and text all work
once they are expressed as features in a CSV.
**Does a wrong answer cost real money?** Both kinds. A missed case and a false alarm are both
expensive, usually by different amounts. That asymmetry is exactly what the candidates table lets
you trade against.
If all three are yes, this is the right tool. If your classes are balanced and your current model
already performs, the gain will be smaller.
## By industry
Transaction and application fraud, credit and default risk, anti-money-laundering alert triage,
collections propensity.
Benchmarked on credit approval and consumer default. Fraud and credit datasets are imbalanced by
nature and change as the people committing fraud adapt. Refine first: application data
accumulates columns nobody has pruned in years. Then run the Crucible and choose the candidate
whose recall matches your appetite for false declines.
Worked example: [German Credit](/use-cases/german-credit).
Claims fraud, underwriting risk, lapse and renewal prediction, subrogation identification.
Benchmarked on warranty claim fraud, where the recall-dominant profile is what most fraud
operations want behind a human review queue. Claims data is wide and much of it is recorded
after the fact, so Feature Refinery is doing two jobs here: finding the signal, and surfacing
columns that only exist because the outcome was already known.
Diagnostic and clinical-outcome prediction, patient risk stratification, screening.
Three of the seven benchmarks are clinical: stroke screening, cardiac disease and mortality
risk. Two things matter here beyond accuracy: recall on the rare condition, and being able to
explain a decision. Every model is deterministic and every prediction records the version it ran
against, so a result can be replayed exactly.
Signal integrity, anomaly screening, sensor trust.
Benchmarked on radar returns, where MathFi.ai is the only method to reach perfect minority-class
precision without paying for it in recall.
Equipment failure and predictive maintenance, quality and defect detection, process anomalies.
Failures are rare by design. A line with two or three failures a month gives a model almost
nothing to learn from, and a model that predicts "no failure" scores 99% while being useless.
This is the case MathFi.ai is built for.
Customer churn, propensity and next best action, returns abuse, late-delivery and disruption
risk.
Customer and operational tables are the widest data most businesses hold, and the least pruned.
Refinement usually removes a large share of the columns and the model gets better for it.
## Which product do I need?
Use it when you are not certain which columns matter, when the data is wide or untidy, or when
nobody has looked at the feature set in a while. Which is most of the time.
Use it when your feature set is settled, when your target is multi-class, or when you are
benchmarking against a model you already run.
Running both is the normal path. Refinement removes the columns that hurt and measures the target
the cleaned data can reach, and that target is what the Crucible needs to produce a model worth
having.
## What this is not
Honest boundaries, so you do not spend a week finding them yourself.
* **Not raw media.** The input is a CSV. Images, signals and text are in scope once encoded as
features, but the platform does not do that encoding for you.
* **Not unsupervised.** You need labels.
## Not yet
A limitation rather than a boundary, and worth knowing the difference.
* **Multi-class through Feature Refinery.** Refinement takes binary targets today. Multi-class
refinement is a capability we plan to add. In the meantime a multi-class dataset goes straight to
[Model Crucible](/products/model-crucible), which handles it.