Согласованность сущностей в длинном тексте: имена, варианты названий, даты и атрибуты

В длинной экспертной статье одна и та же компания может сначала называться полным юридическим именем, затем брендом, потом сокращением, а через несколько экранов — «платформой». Руководитель в начале материала указан как генеральный директор, в кейсе — как основатель, а в финальной таблице его должность уже выглядит иначе. Продукт версии 4.2 незаметно превращается в продукт вообще, а цифра «работает в 18 странах» остаётся без даты и со временем начинает восприниматься как вечный атрибут компании.

Отдельно каждая фраза может выглядеть правдоподобно. Проблема появляется на уровне всего документа: читатель перестаёт понимать, говорим ли мы всё ещё об одном объекте, не смешали ли компанию с продуктом, актуален ли атрибут и относится ли дата к тому же состоянию сущности.

Поэтому согласованность сущностей — не косметическая вычитка названий. Это редакторская проверка, которая удерживает идентичность людей, компаний, продуктов, документов и показателей на протяжении всего материала.

Сущность — это объект, а не просто повторяющееся слово

Для практической работы под сущностью удобно понимать конкретный объект, о котором текст сообщает факты:

• компания;
• человек;
• продукт;
• сервис;
• организация;
• исследование;
• стандарт;
• документ;
• мероприятие;
• показатель, если у него есть устойчивое определение.

Главная ошибка — считать, что одинаковые слова автоматически обозначают один объект, а разные названия — разные объекты.

Например, в тексте могут встретиться:

«Компания Альфа»
«Альфа»
«АО „Альфа“»
«группа „Альфа“»

Иногда это четыре формы одного названия. Иногда юридическое лицо, бренд и группа компаний — разные сущности. Редактор не должен решать это по звучанию.

Сначала установите, что именно является объектом утверждения

Возьмём фразу:

«Альфа запустила новую систему управления складами».

Что здесь такое «Альфа»?

• юридическое лицо;
• группа компаний;
• бренд;
• название продукта;
• команда внутри компании.

Пока объект не установлен, нельзя уверенно добавлять к нему другие атрибуты: год основания, выручку, число сотрудников или географию работы. Эти сведения могут относиться к разным уровням одной корпоративной структуры.

Поэтому перед редактурой полезно задать простой вопрос:

Какой конкретный объект должен оставаться неизменным за этим названием по всему тексту?

Полное имя и короткое имя лучше определить один раз

Длинный текст становится тяжелее, если при каждом упоминании повторять полное официальное название. Но сокращение должно быть введено понятно.

Рабочая схема:

первое упоминание:
полное или наиболее понятное имя + сокращение, если оно действительно понадобится

дальше:
одна выбранная короткая форма

Например:

«Национальный исследовательский центр прикладных систем (НИЦПС) опубликовал отчёт. Далее НИЦПС сравнивает…»

Если сокращение встречается только один раз, вводить его обычно нет смысла. Microsoft в руководстве по стилю также рекомендует не создавать лишние сокращения и, если сокращение необходимо, сначала объяснить полную форму. GOV.UK придерживается похожего принципа: при первом упоминании раскрыть сокращение, а дальше использовать его последовательно.

На mktlg.ru отдельно разобрано, как вводить сложный термин, объяснять его границы и затем не менять смысл по ходу статьи. Для названий сущностей действует похожая логика: после введения формы читатель не должен заново разгадывать, что именно имеется в виду.

Не создавайте новые сокращения только ради разнообразия

В художественном тексте повтор названия иногда хочется убрать. В экспертном материале постоянная смена обозначений может ухудшить точность.

Слабая последовательность:

АО «ТехСистема»
→ ТС
→ компания
→ разработчик
→ вендор
→ группа
→ производитель

Часть слов здесь может описывать роль, а не имя. Если в материале участвуют ещё два разработчика и несколько компаний, местоименная и ролевая замена быстро становится двусмысленной.

Не нужно избегать любого повтора. В B2B-тексте точное повторение имени иногда лучше стилистического разнообразия.

Вариант названия нужно отличать от новой сущности

У организации могут быть:

• официальное юридическое название;
• бренд;
• сокращённое название;
• прежнее название;
• название на другом языке;
• название конкретного подразделения.

Google в описании разметки организаций отдельно различает name, alternateName и legalName. Это техническая модель, но редакционно она хорошо показывает сам принцип: узнаваемое название, вариант названия и официальное юридическое имя могут быть связаны с одной организацией, но это не одно и то же поле.

В тексте поэтому лучше не писать:

«Компания сменила название с юридического на бренд»

если на самом деле юридическое лицо не переименовывалось, а редакция просто перешла с официальной формы на короткую.

Переименование требует временной границы

Если организация или продукт действительно изменили название, старое и новое имя нельзя смешивать как одновременные.

Понятная схема:

до даты X → старое название
с даты X → новое название

В историческом фрагменте старое название может быть корректным:

«В 2022 году компания работала под названием N. В 2024 году бренд был переименован в M».

После этого в текущем описании лучше использовать M, а не чередовать обе формы без причины.

Если неизвестно, что именно поменялось — бренд, юридическое лицо или отдельный продукт, — это нужно перепроверить, а не объединять автоматически.

Компания, продукт и технология — три разных объекта

Одна из самых частых ошибок в технических и B2B-материалах — перенос свойства между уровнями.

Например:

Компания:
ООО «Сигма»

Продукт:
платформа SigmaFlow

Технология:
модуль прогнозирования спроса

Некорректно:

«SigmaFlow была основана в 2018 году».

если в 2018 году была основана компания, а продукт появился позже.

Так же нельзя без проверки переносить:

• число сотрудников компании на продукт;
• географию продаж группы компаний на одно юридическое лицо;
• сертификат продукта на всю организацию;
• результат одного модуля на всю платформу;
• дату основания компании на бренд.

Сущности связаны, но их атрибуты не взаимозаменяемы.

Роль человека тоже является атрибутом с датой

В экспертной статье человек часто появляется вместе с должностью:

«Ирина Петрова, директор по продукту компании X…»

Через год эта формулировка может стать исторической. Если статья рассказывает о событии 2023 года, должность на тот момент может быть важнее сегодняшней. Если материал описывает текущую команду, наоборот, нужна актуальная роль.

Поэтому полезно хранить связку:

человек
→ должность
→ организация
→ период, к которому относится должность

Вместо безусловного:

«Ирина Петрова — директор по продукту X»

для исторического контекста иногда точнее:

«На момент запуска проекта в 2023 году Ирина Петрова занимала должность директора по продукту X».

Первое упоминание человека должно однозначно его идентифицировать

GOV.UK рекомендует при первом упоминании человека использовать полное имя, а затем при необходимости переходить к более короткой форме. Для длинного экспертного текста это хороший базовый принцип.

Если в статье несколько людей с одинаковой фамилией, одной фамилии дальше может быть недостаточно. Тогда лучше повторять имя или роль.

Не стоит менять:

Александр Смирнов
→ Александр
→ Смирнов
→ эксперт
→ руководитель
→ представитель компании

если из соседнего контекста не очевидно, что все обозначения относятся к одному человеку.

Не объединяйте разных людей из-за совпадения имени

Одинаковые имя и фамилия не являются достаточным основанием считать два упоминания одной персоной.

Для проверки полезны:

• организация;
• должность;
• страница профиля;
• авторские публикации;
• период;
• связанный проект.

Google в рекомендациях к разметке автора предлагает использовать отдельный URL автора и при необходимости sameAs, чтобы точнее различать людей. Для редактора вывод проще: если идентичность не подтверждена, не объединять упоминания только по имени.

Атрибут должен быть привязан к состоянию сущности

Некоторые характеристики почти не меняются:

• год основания;
• место рождения человека;
• автор документа;
• дата первой публикации.

Другие меняются регулярно:

• должность;
• число сотрудников;
• число клиентов;
• выручка;
• география присутствия;
• тариф;
• версия продукта;
• число поддерживаемых интеграций;
• статус сертификата.

Чем изменчивее атрибут, тем важнее рядом с ним период.

Фраза:

«Платформа поддерживает 120 интеграций»

без даты может быть понятна в новостной заметке, но в постоянно обновляемой статье быстро теряет временной контекст.

Точнее:

«По данным документации, проверенной в августе 2026 года, платформа поддерживает 120 интеграций».

Дата не делает утверждение автоматически достоверным, но показывает состояние, к которому относится число.

Не превращайте текущий атрибут в вечный факт

Особенно опасны формулировки:

компания работает в 18 странах
у сервиса 2 млн пользователей
в штате 850 сотрудников
продукт интегрируется с 75 системами

Такие сведения часто копируются между абзацами, таблицами, карточками и выводами. Через несколько обновлений одна версия меняется, а остальные остаются прежними.

Поэтому изменяемый атрибут лучше рассматривать как запись:

сущность
+ атрибут
+ значение
+ дата или период
+ источник

Это не обязательно показывать читателю в виде служебной таблицы. Но редактору такая структура помогает увидеть, что «850 сотрудников» — не вечное свойство компании.

Дата события и дата публикации — не одно и то же

В одном абзаце могут соседствовать несколько дат:

• дата события;
• дата публикации источника;
• дата обновления статьи;
• период, за который приведены данные;
• дата получения комментария.

Если они не подписаны, читатель может связать число не с тем моментом.

Например:

«В отчёте от 12 марта 2026 года компания сообщила о 400 клиентах».

Это ещё не говорит, что 400 клиентов было именно 12 марта. Возможно, отчёт описывает состояние на 31 декабря 2025 года.

Редактору нужно различить:

опубликовано: 12 марта 2026
данные относятся к: 31 декабря 2025

И уже после этого строить предложение.

Формат дат должен быть единым

Смешение:

08.09.26
8 сентября 2026
September 8, 2026
2026-09-08

может быть оправдано, если одна дата показывается человеку, а другая используется в машинном формате. Но внутри одного редакционного слоя лучше выбрать единое правило.

GOV.UK рекомендует последовательно писать даты в понятном полном формате, а для машиночитаемых данных государственный стандарт Великобритании опирается на ISO 8601. В статье важна не конкретная британская форма, а сама дисциплина: формат не должен случайно меняться от блока к блоку.

Версия продукта — часть имени или отдельный атрибут?

Ответ зависит от продукта.

Иногда:

Product 4
Product 5

— это разные поколения с разными возможностями.

Иногда версия просто указывает состояние одного продукта:

платформа X, версия 4.2

Перед редактурой нужно решить, что именно сравнивает и описывает материал.

Нельзя в одном разделе писать:

«Версия 4.2 не поддерживает функцию A»

а в выводе сокращать это до:

«Платформа X не поддерживает функцию A».

Ограничение версии потерялось, а утверждение стало сильнее.

Таблица особенно быстро раскрывает несогласованность

В основном тексте небольшое расхождение легко пропустить. В сравнительной таблице оно становится заметнее.

Объект	В тексте	В таблице	Что проверить
Компания	«Группа Альфа»	«ООО Альфа»	Один ли это уровень организации
Продукт	Версия 4.2	Без версии	Не расширился ли вывод на весь продукт
Человек	Директор по продукту	Основатель	Обе ли роли верны и на какой период
Клиенты	400 на конец 2025 года	460	Разные даты или ошибка

Если материал содержит большое сравнение, сначала нужно убедиться, что строки действительно относятся к тем же объектам и периодам. На mktlg.ru уже есть отдельный разбор о том, как сравнивать объекты по одинаковым критериям и в сопоставимых условиях. Проверка сущностей идёт ещё раньше: нельзя корректно сравнить то, что редакция неправильно отождествила.

Согласованность важна и между текстом и структурированными данными

Если сайт использует структурированные данные, они не должны рассказывать другую историю, чем видимая статья.

Например:

• в статье автор — Анна Петрова, а в разметке указано другое имя;
• видимая дата обновления одна, dateModified — другая;
• название организации в тексте не совпадает с её основной формой в разметке;
• страница автора ведёт на одного человека, а sameAs — на другого.

Google рекомендует передавать в разметке автора, который действительно указан на странице, и использовать author.url или sameAs для дополнительной идентификации. Для организаций поддерживаются отдельные поля для основного, альтернативного и юридического названий.

Это не повод добавлять разметку ради самой разметки. Сначала должна быть согласована информация для человека, и только затем техническое представление этой же сущности.

Редакторский словарь нужен не только для терминов

Словарь проекта часто понимают как перечень профессиональных слов:

как пишем «он-премис»
как расшифровываем API
какое название используем для функции

Но для длинных B2B-материалов полезно добавить туда сущности.

Минимальная карточка:

Поле	Что фиксируем
Основное имя	Форма, которую используем в тексте
Полное имя	Официальное или расширенное название, если нужно
Допустимые варианты	Сокращение, бренд, прежнее название
Тип	Компания, продукт, человек, документ и т. д.
Связанные сущности	Например, продукт принадлежит компании
Изменяемые атрибуты	Должность, версия, география, показатели
Дата проверки	Когда данные подтверждались
Источник	Где подтверждена форма имени или атрибут

На главной mktlg.ru редакционный подход прямо связывает качественную работу с правилами, шаблонами и словарём команды. Для статьи о сущностях этот словарь становится не только языковым, но и фактическим инструментом.

Интервью с экспертом нужно переводить в устойчивую систему названий

В устной речи специалист легко говорит:

новый модуль
движок
платформа
наша система
ядро
четвёртая версия

и сам понимает, где речь об одном продукте, а где о разных компонентах.

Читателю этого внутреннего контекста не хватает.

Поэтому после интервью редактору полезно отдельно уточнить:

• какое официальное название у продукта;
• какие короткие формы допустимы;
• какие внутренние названия нельзя выносить наружу;
• где заканчивается продукт и начинается модуль;
• какие версии существенно различаются;
• какие названия уже устарели.

Эта работа естественно продолжает процесс работы редактора с техническими экспертами: эксперт поставляет фактуру, а редактор переводит её из внутренней речи команды в устойчивый внешний текст.

Не исправляйте спорное имя «по здравому смыслу»

Если два источника называют компанию по-разному, возможны разные причины:

• один использует бренд, другой юридическое имя;
• источник старый и содержит прежнее название;
• речь идёт о разных компаниях группы;
• перевод отличается;
• один документ ошибается.

Редактор не должен автоматически выбрать более знакомую форму и заменить все остальные.

Сначала нужно установить отношение между названиями. Если установить его нельзя, неопределённость лучше сохранить.

Разные источники могут быть правы одновременно, если описывают разные даты

Допустим:

источник A:
650 сотрудников

источник B:
820 сотрудников

Это не обязательно противоречие. Один документ может описывать конец 2024 года, другой — середину 2026-го.

Поэтому для изменяемого атрибута сравниваются не только значения:

сущность
+ один и тот же атрибут
+ определение
+ дата
+ источник

Без даты редактор рискует «исправить» исторически верную цифру на текущую и разрушить хронологию материала.

Не обновляйте один атрибут изолированно от связанных мест

Например, в начале статьи:

«Сервис работает в 12 странах».

После обновления редактор меняет число на 18. Но дальше остаются:

• таблица с 12 странами;
• подпись под графиком;
• вывод «география ограничена 12 рынками»;
• карточка компании;
• метаописание.

Поэтому изменение атрибута требует поиска всех зависимых упоминаний.

Тема повторной проверки дат, источников и фактов подробно вынесена в отдельный материал T9; здесь важен более узкий принцип: если меняется свойство сущности, нужно найти все места, где именно эта сущность используется с этим свойством.

Самодостаточный фрагмент должен заново называть сущность, если контекст потерялся

В длинной статье читатель может попасть сразу к середине — из поиска, по якорной ссылке или через цитату.

Слабый фрагмент:

«Она была переименована в 2025 году и после этого увеличила число интеграций».

Без предыдущего абзаца непонятно, кто такая «она».

Лучше:

«Платформа X была переименована в 2025 году; после переименования число заявленных интеграций увеличилось…»

Не нужно повторять полное определение в каждом абзаце. Но ключевая сущность должна быть названа там, где без соседнего контекста возникает двусмысленность.

Это напрямую связано с принципом самодостаточного ответа в длинной статье: локальный фрагмент должен сохранять достаточный контекст, а не зависеть от местоимения, смысл которого осталось несколькими экранами выше.

Местоимения — частый источник потери сущности

В абзаце:

«Компания X приобрела сервис Y у группы Z. Она планирует расширить присутствие в Азии».

Кто именно «она»?

• компания X;
• группа Z;
• команда сервиса Y.

Лучше повторить имя:

«После сделки компания X планирует расширить присутствие в Азии».

Небольшой повтор дешевле смысловой ошибки.

Числа тоже должны иметь владельца

В сложном материале цифры нередко «отрываются» от сущности:

«В 2025 году показатель составил 47%, а в 2026-м вырос до 53%».

Какой показатель? Для какого продукта? На какой выборке?

Чем дальше читатель от исходного определения, тем полезнее вернуть владельца числа:

«Доля заказов, обработанных модулем X, выросла с 47% в 2025 году до 53% в первой половине 2026 года».

Так в одном предложении связаны сущность, атрибут, значения и периоды.

Не используйте одно название для двух разных уровней

Если компания и продукт называются похоже, редактору стоит заранее установить формы.

Например:

компания → «Компания X»
продукт → «платформа X Cloud»
модуль → «модуль X Analytics»

После этого нельзя сокращать все три объекта до «X», если контекст допускает несколько трактовок.

Это особенно важно в:

• сравнительных таблицах;
• кейсовых материалах;
• интервью;
• описаниях экосистем;
• материалах о слияниях и партнёрствах.

Сущность должна сохраняться между заголовком, текстом и подписью

Проверяйте не только абзацы.

Расхождения могут появиться между:

• заголовком статьи;
• подзаголовками;
• основным текстом;
• таблицами;
• подписями к иллюстрациям;
• сносками;
• блоками с цитатами;
• метаописанием;
• структурированными данными.

Если в H2 написано «данные группы компаний», а таблица показывает только одно юридическое лицо, заголовок расширяет объект. Если подпись к графику говорит о «пользователях платформы», а источник считает зарегистрированные аккаунты всей экосистемы, сущность и атрибут снова разошлись.

Практическая карта сущностей перед длинной статьёй

Для материала с большим количеством компаний, людей и продуктов достаточно небольшой рабочей таблицы:

ID	Основное имя	Тип	Допустимые варианты	Важные атрибуты	Период
E1	Компания X	Организация	Бренд X	география, сотрудники	по датам источников
E2	Платформа X Cloud	Продукт	X Cloud	версия, интеграции	текущее состояние
E3	Ирина Петрова	Человек	Петрова	должность	на дату события

Это служебный инструмент, а не часть публикации. Его задача — не дать редактору незаметно склеить E1 и E2 или перенести атрибут E1 на E3.

Если сущностей мало, отдельная таблица не обязательна

Не нужно превращать каждую статью в базу данных.

Для текста о двух продуктах достаточно короткой заметки:

как называем продукт A
как называем продукт B
какие версии сравниваем
какой период данных
какие сокращения допустимы

Чем сложнее материал, тем формальнее может быть контроль. Инструмент должен соответствовать риску ошибки.

Проверка по поиску внутри документа работает лучше чтения «на глаз»

После смысловой редактуры полезно пройти сущности отдельно.

Например, для компании найти:

полное название
короткое название
старое название
сокращение
название бренда

и посмотреть все вхождения подряд.

Затем отдельно найти:

должность ключевого эксперта
версию продукта
число клиентов
географию
дату запуска

Так быстрее обнаруживаются расхождения, которые при обычном последовательном чтении разделены десятью экранами.

Это хорошо дополняет общий чек-лист редактуры сложного B2B-материала, где уже требуется проверять названия продуктов, компаний, даты, цифры и факты. Здесь та же проверка становится связной: мы ищем не отдельную опечатку, а все утверждения об одном объекте.

Порядок проверки перед публикацией

1. Выпишите ключевые сущности. Люди, компании, продукты, документы, исследования.
2. Определите основное имя каждой. Какая форма будет использоваться после первого упоминания.
3. Зафиксируйте допустимые варианты. Сокращения, бренды, прежние названия.
4. Разделите связанные объекты. Компания ≠ продукт ≠ модуль ≠ юридическое лицо.
5. Найдите изменяемые атрибуты. Должность, версия, количество, география, статус.
6. Привяжите атрибуты к датам. Особенно если материал исторический или обновляемый.
7. Проверьте все вхождения поиском. Текст, таблицы, подписи и выводы.
8. Сверьте источники. Не переносится ли значение из одного объекта на другой.
9. Проверьте технические представления. Если есть структурированные данные, они не должны расходиться с видимой страницей.
10. Уберите двусмысленные местоимения. Повторите имя там, где это возвращает ясность.

Типичные ошибки

Ошибка	Что происходит	Как исправить
Бренд и юридическое лицо считаются одним и тем же без проверки	Атрибуты переносятся между разными объектами	Отдельно определить уровни организации
У сущности постоянно меняется название	Читатель думает, что появились новые объекты	Зафиксировать основную и допустимые формы
Старая и новая должность смешаны	Исторический факт выглядит текущим	Привязать роль к периоду
Текущая цифра используется как вечный атрибут	Материал быстро устаревает	Добавить дату или период
Ограничение версии исчезает в выводе	Утверждение расширяется на весь продукт	Сохранять версию во всех зависимых выводах
Одинаковое имя автоматически объединяет людей	Сведения одного человека приписываются другому	Проверить роль, организацию, профиль и период
Обновляется одно число, но не таблица и вывод	Внутри статьи появляются две версии факта	Искать все зависимые упоминания
Структурированные данные расходятся с текстом	Машинное описание сообщает другую сущность или дату	Сверить разметку с видимой информацией

Итог

Согласованность сущностей в длинном тексте начинается с простого правила: один объект должен оставаться тем же объектом во всех местах статьи.

Для этого редактор определяет основное имя и допустимые варианты, не смешивает компанию с продуктом, связывает изменяемые атрибуты с датами, проверяет роли людей на нужный период и не переносит свойства между связанными, но разными сущностями.

Практически полезна связка:

сущность
→ основное имя
→ допустимые варианты
→ атрибут
→ значение
→ период
→ источник

Она не должна появляться перед читателем как служебная база. Но именно такая логика помогает сделать длинный экспертный материал внутренне непротиворечивым.

Если по ходу редактуры невозможно уверенно понять, одно ли это юридическое лицо, тот ли человек или к какой версии продукта относится факт, правильное действие — не «причесать» формулировку, а остановиться и уточнить сущность. Сначала идентичность объекта, потом стиль.

Источники

• Microsoft Writing Style Guide — правила использования сокращений.
• Microsoft Writing Style Guide — правила представления дат и времени.
• Google Search Central — структурированные данные Article: автор, URL автора, даты публикации и изменения.
• Google Search Central — структурированные данные Organization: name, alternateName, legalName и sameAs.
• Schema.org — свойство alternateName для альтернативного названия сущности.
• GOV.UK — стандарт представления дат и времени в машинных данных.