Context
When rules stop working
ML is not needed where a task is formalizable. It appears where rules are impossible to write — because there are too many factors, they change, or some are hidden.
Tax rate calculation
THEN rate = 37%
ELSE rate = 22%
→ Logic is complete and stable. ML is overkill here.
Fraud transaction detector
THEN fraud?
...but wealthy clients spend more
IF new country
THEN fraud?
...but people go on business trips
IF night AND amount > $5k AND...
...thousands of combos, still misses
→ Rules won't scale. Fraudsters adapt faster.
Customer churn prediction
THEN churn?
...but seasonal gaps exist
IF support complaints
THEN churn?
...or that's just an active user
Real churn cause
...is not in any single feature
→ You cannot describe in rules what is itself non-linear.
01 / Foundation
Two ways to create logic
The entire difference between classical programming and ML is where the rules come from. Click the tabs to compare the two approaches.
02 / Mechanics
What happens inside a model
A model does not "understand" meaning or seek truth. It works with features — numerical representations of data — and looks for stable patterns.
Features are the model's "eyes"
Instead of abstract concepts, the model sees only numbers. Better features = better predictions.
User
Age, purchase frequency, geography, session time, click history
Image
Pixel values, brightness, contrast, CNN-layer vectors
Text
Word frequencies, TF-IDF, embeddings, sentiment, sentence length
Transaction
Amount, time, device, geolocation, payment pattern
Sensor / IoT
Temperature, vibration, current, pressure — time series
Proxy features
Indirect signals — when you can't measure directly (intelligence, risk, loyalty)
Why ML almost never works with "real" features
In real business tasks, what you want to predict is almost never directly measurable. So the model is built on proxies — indirect features that correlate with it. This is one of the key insights separating surface-level ML understanding from practical expertise.
Zip code and age are strong predictors, but unfair. The model will reproduce systemic bias if the data contains it.
Silence from a customer can mean loyalty, not churn. No support contacts is a good sign. Feature interpretation is non-obvious.
A business trip looks like fraud: new country, night, unusual amount. The model sees the pattern but not the context — see our AxisCorePay case.
How a model learns: the training loop
The "magic" of ML is not magic. It is mathematical optimization with a concrete mechanism.
The output is always a probability
An ML model does not say "this is fraud." It outputs a number — a probability. But even that is not a decision: you need a decision threshold, and the business sets it, not the model. There is no universally "correct" threshold.
Below — three distinct concepts in one simulator: features you control; weights the training found; and the threshold that defines the business decision.
Fraud caught
False blocks
03 / Critical
Where ML learns the wrong thing
The most dangerous property of ML: a model can perform perfectly on training data and make completely nonsensical predictions in the real world. This is covered in depth in our Production ML failure modes guide.
Classic example: wolf or husky?
Researchers trained a model to distinguish wolves from huskies. Accuracy was high. But when they investigated — the model had learned something completely different.
We assumed the model was learning anatomical features of the animals.
In the training data, wolves were photographed on snow, huskies on grass. The model learned the background, not the animals.
Other dangerous correlations
Expensive watch → premium purchases
The model learns: "expensive watch = premium buyer." There is a correlation, but if you remove the watch — the signal disappears. It is a correlate, not a cause.
Sunny weather → sales growth
Summer data shows higher sales. The model may "learn" weather as a predictor — when the real cause is seasonality.
Gender as proxy for profession
If historical data shows certain roles held predominantly by men — the model will reinforce that pattern in future predictions.
Zip code as proxy for risk
Credit models may deny people from "bad" neighborhoods — even if the individual is creditworthy.
The cost of different errors varies by business
ML always makes two types of errors. Crucially, you cannot minimize both simultaneously. You must choose which error is more expensive — and that is a business decision, not a technical one.
04 / In practice
How an ML project is structured
A real ML project is not "train a model." It is an iterative engineering process with seven stages, each of which can become a failure point. See also: why ML systems fail in production.
Problem framing
What exactly is being predicted? How is success measured? How does it connect to business metrics?
⚠ Most common failure pointData collection and audit
Is there a signal in the data at all? How representative is it? Is there any leakage of future information into the past?
Feature engineering
What does the model "see"? The right features deliver more impact than complex algorithms.
💡 More critical than algorithm choiceModel training
Architecture selection, hyperparameter tuning, regularization. An iterative experimental process.
Evaluation and validation
Metrics on the held-out set. Error analysis. Bias and fairness checks.
Integration into product
API, latency, fallback logic, A/B testing. 70% of effort often goes here.
⚠ Frequently underestimated at the startMonitoring and maintenance
Models degrade. The world changes. Data drift, concept drift, user behavior shifts. ML is a process, not a product.
Where ML projects most often break
05 / For decision-makers
What every stakeholder needs to understand
Seven things that separate a successful ML project from an expensive experiment. These apply equally to Applied AI and trading systems.
ML does not guarantee an outcome
It is not a deterministic system. It is a hypothesis tested on data. There is always a risk that the data contains no signal.
Data matters more than the model
Poor data yields poor results — regardless of algorithm complexity. Garbage in, garbage out.
Features matter more than the algorithm
In most tasks, good feature engineering delivers more impact than switching to a more complex model.
The output is a probability
ML says "83% chance of fraud," not "this is fraud." You need to manage thresholds and risks.
ML ≠ neural networks
Gradient boosting, decision trees, linear models — often faster, cheaper, and more interpretable.
Monitoring is mandatory
Models degrade. The world changes. ML is a process, not a one-shot solution. Quality control after deployment is required.
Optimize for the right thing
A model optimizes what you ask it to. Make sure the ML metric aligns with the business goal — this is often non-obvious.
Signs of a successful project
Clear business metric · quality data · iterative approach · integration into processes · post-deployment monitoring
06 / Diagnosis
Is ML right for your use case?
Before talking about models and algorithms — answer four questions. If even one answer is "no," an ML project is likely premature.
Ready to evaluate your ML opportunity?
We run a short audit to determine whether your use case has the signal, data, and business conditions for a successful ML project — and what the realistic timeline and outcome look like.
Let's talk →