diff --git a/README.md b/README.md
index 436616f296194b8f225683f98ae4a64bac1c87f6..28e4af76fa0281e22169f26074819259f455732d 100644
--- a/README.md
+++ b/README.md
@@ -2,11 +2,7 @@
 
 ...and this package makes it easier for you.
 
-# The story
-
-You should not be able to inherit from object which was not explicitly designed to be extended (`final` by default). [1](https://matthiasnoback.nl/2018/09/final-classes-by-default-why/), [2](http://whiley.org/2011/12/06/final-should-be-default-for-classes-in-java/) You get much better object encapsulation, you know exactly how you object behaves.
-
-In 3/2022 I have found a similar pattern that breaks object-encapsulation. The feature is **implicit support for object serialization**. Let's say we have an object:
+# The storyv
 
 ```php
 class UserId { 
@@ -41,7 +37,13 @@ There is no public change of behaviour. There is no way outer observer should be
 
 Boom! 🔥 Application hard crashed for every user that has been logged-in on _session deserialization_. That is because implicit serialization made public interface from a private property.
 
-This magic behaviour is [an explosive mine 💥](https://en.wikipedia.org/wiki/Explosive_mine), that you cannot easily spot from the surface or even in code-review. You have to inspect whole code life-cycle including code history.
+### Summary
+
+Implicit serialization support is [an explosive mine 💥](https://en.wikipedia.org/wiki/Explosive_mine), that you cannot easily be spot from the surface or even in code-review. You have to inspect whole object life-cycle including code history. Almost impossible to spot.
+
+This is very similar to disabling inheritance support from object which was not explicitly designed to be extended – `final` by default. You can find good reasoning at [1](https://matthiasnoback.nl/2018/09/final-classes-by-default-why/), [2](http://whiley.org/2011/12/06/final-should-be-default-for-classes-in-java/).
+
+**TL;DR:** You get much better object encapsulation, you know exactly how you object behaves.
 
 # The solution