diff --git a/src/ru/drafts/03-Раздел II. Обратная совместимость/03.md b/src/ru/drafts/03-Раздел II. Обратная совместимость/03.md
index e8ae82e..821a1cd 100644
--- a/src/ru/drafts/03-Раздел II. Обратная совместимость/03.md	
+++ b/src/ru/drafts/03-Раздел II. Обратная совместимость/03.md	
@@ -6,7 +6,7 @@
 
 Первый важный момент, на который стоит обратить внимание: мы говорим именно о вариантах реализации _продуктовой логики_. Не о _вариантах реализации сущности_: изменения в API вносятся прежде всего для того, чтобы можно было сделать что-то, не предусмотренное изначальным дизайном — что-то полезное. Заниматься реимплементацией интерфейсов просто так ваши потребители не будут.
 
-Это соображение вносит определённые ограничения, которые позволяют нам не заниматься варьированием интерфейсов вслепую (в конце концов, вариантов таких вариантов бесконечное количество, и предусматривать их все — сизифов труд): нам нужно понять в первую очередь _зачем_ нужны те или иные изменения, и отсюда мы уже поймём _как_ их следует внести.
+Это соображение вносит определённые ограничения, которые позволяют нам не заниматься варьированием интерфейсов вслепую (в конце концов, таких вариантов бесконечное количество, и предусматривать их все — сизифов труд): нам нужно понять в первую очередь _зачем_ нужны те или иные изменения, и отсюда мы уже поймём _как_ их следует внести.
 
 Второй важный момент состоит в том, что многие решения, допускающие эту вариативность, _уже заложены_ в дизайне API. Какие-то из них (например, вопрос определения готовности) мы осветили в предыдущих главах подробнее, а какие-то дали без комментариев — настало время объяснить, почему эти решения были приняты.
 
@@ -58,7 +58,7 @@ POST /v1/recipes
 ]
 ```
 
-И здесь возникает первый большой вопрос — а что делать с `default_volume`? С одной стороны, это объективная величина, выраженная в стандартизированных единицах измерения, и она используется для запуска программы на исполнение. С другой стороны, для таких стран, как США, мы будем обязаны указать не объём в виде «300 мл», а в виде «10 унций». Мы можем предложить одно из двух решений:
+И здесь возникает первый большой вопрос — а что делать с `default_volume`? С одной стороны, это объективная величина, выраженная в стандартизированных единицах измерения, и она используется для запуска программы на исполнение. С другой стороны, для таких стран, как США, мы будем обязаны указать объём не в виде «300 мл», а в виде «10 унций». Мы можем предложить одно из двух решений:
 
   * либо партнёр указывает только числовой объём, а числовые представления мы сделаем сами;
   * либо партнёр указывает и объём, и все его локализованные представления.
@@ -71,7 +71,7 @@ POST /v1/recipes
 
 Эта проблема разворачивается и в другую сторону — UI (наш или партнера) обязательно будет развиваться, в нём будут появляться новые элементы (картинка для кофе, его пищевая ценность, информация об аллергенах и так далее). `product_properties` со временем превратится в свалку из большого количества необязательных полей, и выяснить, задание каких из них приведёт к каким эффектам в каком приложении можно будет только методом проб и ошибок.
 
-Проблемы, с которыми мы столкнулись — это проблемы *сильной связности*. Каждый раз, предлагая интерфейс, подобный вышеприведённому, мы фактически описываем имплементацию одной сущности (рецепта) через имплементации других (визуального макета, правил локализации). Этот подход противоречит самой проектирования API «сверху вниз», поскольку **низкоуровневые сущности не должны определять высокоуровневые**. Как бы парадоксально это ни звучало, обратное утверждение тоже верно: высокоуровневые сущности тоже не должны определять низкоуровневые. Это попросту не их ответственность. 
+Проблемы, с которыми мы столкнулись — это проблемы *сильной связности*. Каждый раз, предлагая интерфейс, подобный вышеприведённому, мы фактически описываем имплементацию одной сущности (рецепта) через имплементации других (визуального макета, правил локализации). Этот подход противоречит самому принципу проектирования API «сверху вниз», поскольку **низкоуровневые сущности не должны определять высокоуровневые**. Как бы парадоксально это ни звучало, обратное утверждение тоже верно: высокоуровневые сущности тоже не должны определять низкоуровневые. Это попросту не их ответственность. 
 
 #### Правило контекстов
 
@@ -191,4 +191,4 @@ POST /v1/recipes/custom
 }
 ```
 
-Заметим, что в таком формате мы сразу закладываем важное допущение: различные партнёры могут иметь как полностью изолированные неймспейсы, так и разделять их. Более того, мы можем ввести специальные неймспейсы типа "common", которые позволят публиковать новые рецепты для всех. (Это, кстати говоря, хорошо ещё и тем, что такое API мы сможем использовать для организации нашей собственной панели управления контентом.)
\ No newline at end of file
+Заметим, что в таком формате мы сразу закладываем важное допущение: различные партнёры могут иметь как полностью изолированные неймспейсы, так и разделять их. Более того, мы можем ввести специальные неймспейсы типа "common", которые позволят публиковать новые рецепты для всех. (Это, кстати говоря, хорошо ещё и тем, что такое API мы сможем использовать для организации нашей собственной панели управления контентом.)