Reliant.ai

We built Reliant.ai around a problem that felt surprisingly simple:

Warranty systems are very good at counting problems, but not always at understanding them.

A technician might describe the same issue as:

“clunking over speed bumps”
“metallic thud from the front-left wheel”
“strut rebound popping”

At the same time, those claims can end up under completely different failure codes.

If you only look at the codes, the individual numbers might never look serious enough to trigger an alert.

We wanted to see if we could solve that.

The Idea

Reliant.ai is a reliability intelligence platform that finds emerging vehicle defects hidden inside warranty claims.

Instead of relying only on the structured failure code, Reliant.ai looks at what technicians actually wrote in their narratives. It extracts the important details, understands similarities between differently worded claims, and groups related claims into emerging defect patterns.

From there, it looks at how those patterns are changing over time and asks questions like:

Is this defect suddenly becoming more common?
Are different failure codes actually describing the same problem?
Is the increase statistically significant?
Which vehicles or plants are affected?
Would traditional monitoring have caught this?
How much earlier did the semantic signal appear?

The result is an investigation workflow rather than just another dashboard.

How It Works

The system takes raw warranty claims and runs them through the following pipeline:

Claim ingestion → NLP extraction → semantic embeddings → unsupervised clustering → cross-code analysis → statistical emergence → alert scoring → investigation → defect memory

1. Understand the Technician Narrative

We use domain-grounded NLP to extract important information from technician narratives, including:

Components
Symptoms
Operating conditions
Failure characteristics

This allows Reliant.ai to move beyond the structured failure code and understand what the technician is actually describing.

2. Compare Claims by Meaning

Semantic embeddings allow differently worded complaints to be compared based on meaning rather than exact keywords.

For example:

“clunking over speed bumps”

and

“heavy metallic thud from the front-left corner”

can be recognized as potentially related even though they use very different words.

3. Discover Emerging Patterns

We use HDBSCAN for unsupervised clustering.

Unlike approaches that require us to specify the number of clusters beforehand, HDBSCAN discovers naturally occurring groups of semantically similar claims while allowing unrelated claims to remain separate.

4. Measure Statistical Emergence

Once a meaningful pattern is discovered, Reliant.ai analyzes how that pattern changes over time.

We calculate measures such as:

Baseline volume
Recent volume
Growth rate
Z-score
CUSUM
Alert score

For example, our standardized emergence measure can be expressed as:

$$ Z = \frac{x - \mu}{\sigma + \epsilon} $$

where (x) is the recent claim volume, (\mu) is the historical baseline, (\sigma) is the historical standard deviation, and (\epsilon) prevents division by zero.

Growth is calculated as:

$$ Growth = \frac{Recent - Baseline}{Baseline} \times 100 $$

5. Detect Taxonomy Fragmentation

Reliant.ai also checks whether semantically related claims are fragmented across different structured failure codes.

A single underlying defect might appear as:

OTHER

RIDE QUALITY

SUSPENSION

STEERING

ELECTRICAL-NFF

Traditional monitoring may treat these as separate problems.

Reliant.ai asks whether they are actually one emerging reliability signal.

6. Investigate the Evidence

The engineer can drill down from an alert into:

Individual warranty claims
Technician narratives
Failure codes
Timeline of emergence
Affected vehicles
Plants
Statistical evidence
Supporting pattern information

This makes the system an investigation workflow, rather than simply an alert generator.

What Inspired Us

The main insight behind Reliant.ai was that real-world failures don't always fit neatly into predefined categories.

A database might say:

OTHER

while another claim says:

RIDE QUALITY

and another says:

SUSPENSION

But the technician narratives could all be describing the same physical failure.

That made us wonder:

What if we stopped asking which code the claim belongs to and started asking what problem the claim is actually describing?

That question became Reliant.ai.

Building the Product

We wanted to build more than a model or a proof-of-concept notebook, so we built the entire workflow around it.

The product includes:

Data ingestion pipeline
Backend analytical engine
Domain-grounded NLP extraction
Semantic embeddings
HDBSCAN clustering
Statistical emergence analysis
Cross-code fragmentation analysis
Alert scoring
Web-based investigation console
Baseline comparison
Claims explorer
Persistent defect-memory system

One of the biggest things we focused on was making the results explainable.

If Reliant.ai raises a critical alert, an engineer should be able to understand where it came from instead of simply seeing a score like 95.8.

They can trace the signal back to the claims that created it, see the different failure codes involved, view the timeline of emergence, and inspect the statistical evidence behind the alert.

What We Learned

Probably our biggest lesson was that semantic similarity is harder than it sounds.

Technicians don't use a fixed vocabulary.

One person might say:

“front-left suspension knocking”

while another says:

“heavy thud from the driver's front corner”

Both can describe the same underlying issue.

Our first clustering implementation actually exposed this problem. The canonical 35-claim defect was being split into several smaller clusters because of differences in wording.

We had to improve our domain vocabulary, normalize the extracted failure signatures, fix extraction edge cases, and tune the clustering layer so that legitimate variations could still be recognized as one pattern.

Speed Was Another Challenge

Our initial implementation used a local LLM sequentially for individual claims.

With hundreds of claims, that made the pipeline take around 14 minutes.

We redesigned the batch extraction process using a high-speed deterministic NLP engine, bringing the full pipeline down to under one second on our test workload.

That was a huge improvement, but we didn't want speed at the cost of accuracy.

After refining the extraction and clustering pipeline, our 400-claim canonical test recovered all 35 related defect claims as one semantic cluster, achieving:

100% Precision
100% Recall
100% F1

in our evaluation.

The Challenges

The hardest part was making sure we weren't accidentally building a system that only worked for our demo.

It would have been easy to hardcode the expected defect, the number of claims, or the final score.

Instead, we built the pipeline so that those values are calculated from the actual input data.

We also added:

Regression tests
Canonical recovery testing
Unseen-defect testing
Pipeline validation

The unseen-defect test was particularly important because it checks whether Reliant.ai can discover a different defect rather than simply recognizing the original demonstration pattern.

Another challenge was getting the interface right.

We didn't want Reliant.ai to feel like a generic AI dashboard.

The goal was to create something an engineer could actually use to investigate a reliability problem — from the first signal all the way down to the individual warranty claim.

What's Next

Right now, Reliant.ai focuses on warranty claims, but the same idea could extend much further.

In the future, we could combine warranty narratives with:

Repair orders
Diagnostic information
Parts replacements
Customer feedback
Vehicle telemetry
Manufacturing data

The bigger vision is to help reliability teams move from reactive reporting to proactive detection.

Instead of waiting until a defect becomes large enough to show up in a traditional report, Reliant.ai looks for the weak signals hiding across the data.