How it's different
Expert-level answers without the expert price, and checkable.
Plenty of products explain data, and plenty shrink AI models. HeartCut is the only one we found that pairs expert-level findings with evidence checked automatically before the small model learns from it.
The landscape
Each kind of tool has half of the answer
Surveyed in September and October 2026. The products named in each row are a sample of that kind of tool.
| Kind of tool | Expert explanations* | Cheap enough for everything | Numbers checked at the source | Reads data as numbers | Across domains |
|---|---|---|---|---|---|
| Data-warehouse AI assistantsDatabricks Genie, Snowflake Cortex Analyst, Tableau Pulse | Yes | Per query | No | As text | Yes |
| Template report writers (NLG)Arria, Yseop, Automated Insights | No reasoning | Yes | Built in | Rules read it | Yes |
| Distillation platformsOpenPipe, distil labs, Bedrock and Agent Bricks | Yes | Yes | A model judges | As text | Yes |
| Open-source pipelinesdistilabel, NeMo Curator, OpenTSLM | Build it yourself | Yes | Filters only | Sometimes | Yes |
| Industry-specific productsAugury, Uptake, Siemens Senseye | Scores only | Yes | No explanation | Yes | One industry |
| HeartCutA small trained model behind an automatic check | Yes | Yes | Resolved | As a tensor | Yes |
* Deeper analysis like "the desk's VaR rose on its own position, not the market", not just a score or a flag.
Distillation platforms and HeartCut both learn from a teacher model. HeartCut pulls ahead in the third and fourth columns: it checks the teacher's numbers against the source data before the small model learns from them, and the small model reads the record as numbers, not as text.
Because only answers whose evidence checks out reach the training set, the small model never learns from the teacher's invented or misquoted numbers. HeartCut raises the floor; the teacher still sets the ceiling.
Expert answers, paid per question
They call a leading AI model each time someone asks, about any question, and stay tied to the data warehouse. Nobody runs them for every machine every hour, nothing checks a number in a sentence against its source, and nothing ships to a machine, a vehicle, or a bedside. HeartCut makes the opposite trade: a fixed set of questions in exchange for a cost low enough to run constantly, next to the data.
Accurate because it never reasons
Templates say what the data says because a rule wrote each sentence. No template produces deeper analysis like "the 41 mmHg dip came during the line re-zero, so ignore it": knowing that a re-zero distorts the reading comes from domain knowledge, not from the data. HeartCut uses rule-based answers to help train the small model and never as the finished product.
Learned from live usage, ranked by a judge
Most learn from logs of production traffic, so the small model learns whatever users happened to ask. Another AI model judges the results, which ranks answers and does not block any. Nothing checks a number in the teacher's answer against a source record before it becomes training material. HeartCut starts from the same teacher-and-student idea and adds that check.
An alert, not an explanation
They deliver detections, anomaly scores, and lists of the sensors involved. The sentence a technician acts on is left to the technician. Their output can serve as training labels for a HeartCut model, so the two are as much partners as competitors.
What the model reads
Everyone else reads your data as text
Nearly every product above turns the record into text for a prompt, whatever the data was: a time series, a network, a schedule. The model spends effort recovering the structure that the text conversion threw away before it starts to reason.
Text to text
Decimals become strings of several tokens. Most of a table's length goes to separators and repeated headers. A preamble explains what the model is looking at, and all of it is read before the first word of the answer.
Record to text
The HeartCut student reads the record as an array of numbers (a tensor): measurements scaled with a fitted encoding, positions such as time kept in their own units, and categories looked up in a frozen table. The input is shorter, carries no preamble, and keeps its structure.
A worked example
One turbine unit, read both ways
A turbine unit logs 21 sensor readings every operating cycle. Below is one row of that log, first as a language model reads it and then as the HeartCut student reads it. The row is trimmed to four sensors to fit.
As text 20 tokens
A table row is split into tokens, the small pieces a language model reads one at a time. Each box below is one token, using a tokenizer that splits numbers into groups of up to three digits.
Five numbers cost 20 tokens, or about 4 tokens per number.
As a tensor 1 position
The student receives the cycle as one position, with each reading shifted and scaled by that sensor's usual value and spread.
The same five numbers take one position. Here the cycle number is the position, and the four sensor readings are its contents.
| Record (21 sensors) | As text | As a tensor |
|---|---|---|
| A short window: 34 cycles | ~3,000 tokens | 34 positions |
| An example window: 60 cycles | ~5,300 tokens | 60 positions |
| A long history: 340 cycles | ~30,000 tokens | 340 positions |
A full row holds a cycle number and 21 readings, which is 22 numbers at about 4 tokens each: roughly 88 tokens per cycle as text, against one position as a tensor. The short window and the long history are sized to match the 3,000-token and 30,000-token records in the cost chart. An API call also carries an instruction preamble, which the cost estimates put at 20,000 tokens. The student's input has none. Exact counts vary by tokenizer, but the gap stays large.
The technical details
Nine pieces, found together nowhere else
An automatic gate
Citation and logic checks decide what becomes training data. Evidence is checked by looking it up, never by asking another model.
Records as tensors
The numeric version of each record comes from the same source as the teacher's text version, so the student reads the record's structure directly.
A fitted tokenizer
By default, the student's vocabulary is built from the validated answers instead of borrowed from a general-purpose model.
A declared question bank
Questions are drawn from a set you declare up front, never from logs of live traffic.
Style as a setting
One student can answer in any voice or level of detail, switchable at answer time.
Paired prompts
Every replaceable stage comes with a full prompt and a compact one, so swapping in a small local model is a routine step.
A model cascade
One frozen vocabulary supports a mid-size helper model, the student, and tiny one-question specialists.
A rule-checker, not a reward model
Optional extra tuning on the student's own answers uses the same automatic gate as a hard rule. Preferences only shape answers that already pass it.
An extendable framework
Installable add-on packs supply new record types, measurements, calculations, and detectors, or replace built-in ones. A team can keep a private pack for its own domain.
Alongside a data platform
Keep the platform you have
A build needs three things: somewhere the data already lives, a model to teach from, and somewhere to run the finished model. Your data platform can supply all three, so nothing has to move.
HeartCut installs as a local software kit. Its settings are plain files in a git repository, and it keeps its own working data in SQLite or in an SQL database you already run. It does not replace your governance tools. Its build report records where every record came from and which models were built.
Three connection points
- A warehouse as the source of records. Your own code reads the records from a table, and HeartCut never looks inside it.
- A platform-hosted model as the teacher. A hosted endpoint is one more entry in the model configuration.
- Platform hosting for the finished model. A student served from a managed endpoint keeps the cost and speed benefits and gives up running on-site.
Where HeartCut stops
When an API call is still the right answer
HeartCut pays off when answers are needed constantly from a stable question bank whose coverage is settled, or when the analysis has to happen somewhere an API cannot reach. Otherwise, use the API.
Low volume
A few thousand answers a month does not justify a build. The API's per-answer pricing suits that volume.
The questions are open-ended
If the question bank does not cover what people ask, a cheaper answer to the wrong question is worth nothing. Settling that takes judgment, and it comes before cost.
The questions keep changing
Every change to the question bank means retraining, while changing a prompt for an API costs nothing. Until the bank settles, flexibility is worth more than the cost gap.
The teacher still costs money
HeartCut turns a recurring per-answer bill into an occasional, bounded one. Building the training examples still uses the teacher, and every rebuild uses it again.
Cheap APIs close part of the gap
Even against short records, batched and cached, at the cheapest providers, HeartCut stays roughly 30× cheaper. At constant volume that is a large saving; at low volume it hardly matters.
A shrunken general model may be enough
On a rack server where an answer can take tens of seconds, a compressed general-purpose model can be the cheaper choice. Its numbers are still unchecked.
Questions
What about the question nobody thought to ask?
The FAQ answers the hardest objections one at a time, and names the limits that remain.