diff --git a/dwh-modeling/DataVault.md b/dwh-modeling/DataVault.md
index 5e42d8f..342f033 100644
--- a/dwh-modeling/DataVault.md
+++ b/dwh-modeling/DataVault.md
@@ -11,6 +11,7 @@
 7. [Как это живёт в пайплайне загрузки](#7-как-это-живёт-в-пайплайне-загрузки)
 8. [Плюсы и минусы Data Vault](#8-плюсы-и-минусы-data-vault)
 9. [Когда DV стоит использовать, а когда нет](#9-когда-dv-стоит-использовать-а-когда-нет)
+10. [Шпаргалка для собеседования](#10-шпаргалка-для-собеседования)
 
 ---
 
@@ -150,6 +151,8 @@ CREATE TABLE hub_customer (
 );
 ```
 
+Конкретные типы данных (`BYTEA`, длины `VARCHAR`, детали `hashdiff`) и реализации хэш‑ключей можно не запоминать: на старте важнее понять саму идею — у сущностей есть стабильные ключи, а все изменения атрибутов мы записываем отдельными версиями в сателлитах.
+
 ### 3.2. Link — связи между сущностями
 
 **Link** описывает факт связи, например:
@@ -213,6 +216,8 @@ CREATE TABLE sat_customer_info (
 
 ## 4. Типы сателлитов в DV 2.0
 
+> Если вы только знакомитесь с DV, этот раздел можно прочитать по диагонали: для собеседования важно скорее знать, что такие роли бывают, чем разбираться во всех нюансах.
+
 В DV 2.0 появилось разделение по «ролям» сателлитов. Главное, что стоит знать:
 
 * **Descriptive Satellites** — обычные атрибуты (имя, адрес, тариф) с историей.
@@ -281,6 +286,8 @@ Business Vault (BV) — следующий слой над Raw DV:
 
 #### 5.2.1. PIT-таблицы (Point-in-Time)
 
+> Раздел для любопытных: PIT-таблицы — уже продвинутая тема, на первом знакомстве с DV её можно смело пропустить и вернуться позже.
+
 PIT (Point-in-Time) решает очень конкретную боль:
 
 > «Покажи, как объект выглядел **на дату X**, но так, чтобы запрос был простым».
@@ -341,6 +348,8 @@ JOIN sat_customer_info info
 
 #### 5.2.2. Bridge-таблицы
 
+> Тоже продвинутый приём: Bridge-таблицы чаще нужны в боевых хранилищах, чем на первых собеседованиях.
+
 Bridge-таблицы отвечают на другой вопрос:
 
 > «Какие объекты **в итоге** связаны между собой через длинную цепочку Links?»
@@ -416,6 +425,8 @@ Bridge — это **не обязательный элемент DV**, а инс
 
 #### 5.2.3. Business-правила и derived-таблицы
 
+> Этот раздел полезен, чтобы увидеть, как DV помогает «прятать» повторяющуюся бизнес-логику, но для базового понимания Data Vault его можно оставить «на потом».
+
 В BV логично размещать бизнес-логику, которая:
 
 * повторяется во многих отчётах;
@@ -628,3 +639,14 @@ DV не отменяет STG/ODS/DM — он скорее **раскладыва
 > `stg → ods → dds (3NF/простая Звезда с SCD2) → dm (Звезда)`
 
 А DV оставить как следующий шаг, когда появятся реальные боли, которые он решает.
+
+## 10. Шпаргалка для собеседования
+
+Если нужно быстро объяснить, что такое Data Vault:
+
+- Data Vault — это модель хранилища, которая разделяет идентичность (Hubs), связи (Links) и атрибуты с историей (Satellites), чтобы проще переживать изменения источников.
+- В DV есть три типа таблиц: `Hub` (бизнес-ключи сущностей), `Link` (связи между сущностями) и `Satellite` (атрибуты и их история).
+- Raw Vault — слой, где данные складываются «как есть» в виде Hub/Link/Sat, Business Vault — слой с бизнес-правилами, PIT/Bridge и подготовленными представлениями для витрин.
+- История в DV хранится «из коробки»: каждое изменение атрибутов — новая строка в сателлите, прошлые значения не затираются.
+- DV хорошо подходит, когда много источников, они часто меняются и важен аудит; для маленького, простого DWH обычно хватает 3NF/Звезды.
+- Для собеседования важно уметь связать всё вместе: объяснить Hub/Link/Satellite, отличия Raw и Business Vault и то, что хэш-ключи и независимые сателлиты позволяют грузить разные сущности параллельно, не ломая историю и аудит.