diff --git a/analysis/#01 — When Arithmetic Cannot Be Trusted/readme.md b/analysis/#01 — When Arithmetic Cannot Be Trusted/readme.md
new file mode 100644
index 0000000..3919cdc
--- /dev/null
+++ b/analysis/#01 — When Arithmetic Cannot Be Trusted/readme.md	
@@ -0,0 +1,270 @@
+# Analysis #01 — When Arithmetic Cannot Be Trusted
+
+## 1. The Problem
+
+Look at this code:
+
+```cpp
+int a;
+int b;
+int c;
+
+// ...
+
+if (a + b > c)
+```
+
+It looks simple.
+
+You have probably written this many times.
+
+Most people will say:
+“Nothing is wrong.”
+
+But something is wrong.
+
+---
+
+## 2. The Hidden Assumption
+
+This code assumes:
+
+> `a + b` always works correctly.
+
+In real systems, this is not always true.
+
+---
+
+## 3. What Can Go Wrong
+
+In C/C++:
+
+- `int` has limits  
+- `a + b` can overflow  
+- signed overflow is undefined  
+
+This means:
+
+> The result of `a + b` can be wrong.  
+> And the `if` will use that wrong value.
+
+At this point, many people think:
+“I just need a bigger type.”
+
+But that is not the real problem.
+
+---
+
+## 4. Why Simple Fixes Do Not Help
+
+Common ideas:
+
+- “Use `long`”  
+- “Rewrite as `a > c - b`”  
+
+These do not solve the problem.
+
+> They only move the problem somewhere else.
+
+---
+
+## 5. The Real Problem
+
+This is not about math.
+
+This is about **data you cannot trust**.
+
+- input values can be wrong  
+- result can be invalid  
+- invalid result must not be used  
+
+In interviews, data is always clean.
+
+In real systems, it is not.
+
+Sensors fail.  
+Signals disappear.  
+Values go outside limits.
+
+And then simple code becomes dangerous.
+
+---
+
+## 🧪 A Real-World Example
+
+During testing of a prototype vehicle, the system did not start.
+
+The team checked signals and wiring.  
+There was no response from the transmission.
+
+They thought:
+something is wrong with the signal.
+
+Later they found the real reason:
+
+> There was no transmission.  
+> It was still on the shelf.
+
+It sounds obvious now.
+
+But at that moment, everyone believed the system was complete.
+
+---
+
+## 💡 Lesson
+
+Before you debug logic or data, check your assumptions.
+
+> Maybe the system is not what you think it is.
+
+---
+
+## ⚠️ Do Not Fix It With Math
+
+> Math does not fix broken data.  
+> It only hides the problem.
+
+When something looks wrong:
+
+- do not rewrite the formula  
+- do not try to “make it work”  
+- do not hide the issue  
+
+> Do not fix logic with math.  
+> Report the problem.
+
+---
+
+## 6. Why This Code Is Rare in Real Systems
+
+In real-time and embedded systems:
+
+- calculations are done before conditions  
+- conditions use prepared values  
+- time is limited  
+- input ranges are defined  
+
+So this:
+
+```cpp
+if (a + b > c)
+```
+
+is already suspicious.
+
+---
+
+## 7. What Real Systems Do
+
+Real systems ask:
+
+> “Can I trust this result?”
+
+If not, they do not use it.
+
+---
+
+### Typical behavior
+
+If `a + b`:
+
+- overflows  
+- or gives a value outside limits  
+
+then:
+
+1. Drop it  
+Do not use the result.
+
+2. Mark it as invalid  
+- invalid  
+- not plausible  
+- bad frame (for example CAN)
+
+3. Report it  
+- error counter  
+- diagnostics  
+
+4. Continue working  
+Wait for valid data.
+
+---
+
+## 8. Example
+
+```cpp
+auto result = safe_add(a, b);
+
+if (result.invalid)
+{
+    publish_invalid();
+    error_counter++;
+    return;
+}
+
+if (result.value > c)
+{
+    update_state();
+}
+```
+
+---
+
+## 9. Key Idea
+
+> Do not trust bad data.  
+> Do not use bad results.
+
+---
+
+## 10. Final Answer
+
+What is wrong with:
+
+```cpp
+if (a + b > c)
+```
+
+Answer:
+
+> It assumes the calculation is always correct.  
+> In real systems, it is not.
+
+---
+
+## 11. Find Problems Before Runtime
+
+Handling errors at runtime is not enough.
+
+We must also find problems before release.
+
+---
+
+### In testing we:
+
+- test near limits (INT_MAX, INT_MIN)  
+- send invalid data  
+- use fuzz testing  
+- replay real logs (for example CAN)
+
+---
+
+### We want to know:
+
+- Where can overflow happen?  
+- What inputs cause it?  
+- Does the system drop invalid data?  
+- Does bad data go further?  
+
+---
+
+## 12. Final Thought
+
+> The system must survive bad data.  
+> The tools must find it.
+
+Computers do not work with perfect numbers.
+
+Real engineering is not about perfect formulas.
+
+It is about systems that work even when data is not perfect.