1. Техническое описание протокола
Назначение. BrandCore - структурированный markdown-файл, выполняющий функцию единого источника правды (SSOT) о компании при генерации контента через LLM. Прикладывается целиком к любой задаче генерации в качестве системного контекста.
Структура. 16 разделов + операционная карточка. Ключевые:
0 - Паспорт компании, иерархия приоритетов при конфликте инструкций, навигатор по разделам
1 - Юридические данные, лицензии, IP, заявления о свойствах (claims), классификация данных
2–5 - Миссия, бизнес-модель, аудитория, продуктовый каталог
6–7 - E-E-A-T, авторство, голос бренда, терминология
8–12 - Методологии, визуальная идентичность, контент-архитектура, техника, SEO/GEO
13–15 - Защита от подмены инструкций, чек-лист качества, формат отчёта
Механизмы контроля данных:
- Шкала статусов достоверности - 4 значения: подтверждено / черновик / устарело / в архиве. Только "подтверждено" разрешено использовать в публичном материале.
- Разделение полей и записей. Поле (раздел 1.1, 9.1) - уникальная единица, заполняется один раз. Запись (claims, факты, метрики, продукты, лицензии - разделы 1.4, 3.3, 3.5, 5.1.1) - повторяемая единица со стабильным ID (
claim.01, fact.02).- Источник + точный фрагмент - обязательная пара колонок для любого факта, разделены: источник (документ/URL/"прямой ответ пользователя"), фрагмент (конкретное место, не общая ссылка).
- BLOCKING-разделы - список обязательных для генерации разделов, читается из самого файла (операционная карточка + чек-лист раздела 14), не хранится отдельной копией.
- Служебный отчёт - после каждой генерации модель выводит отдельным блоком (не в публикуемый текст): использованные ID фактов/claims, конфликты, причину остановки при блокировке.
Ограничения по конструкции: не проверяет фактологию автоматически, не заменяет юридическое согласование, не гарантирует поведение модели без явного system-prompt слоя (см. примеры ниже).
2. Примеры использования в одном чате
Пример 1 - карточка товара
Шаг 1. Новый чат → прикрепить
BRANDCORE.md.Шаг 2. Стартовый промпт:
Работай строго по правилам приложенного файла BRANDCORE.md.
Используй только записи со статусом "подтверждено" из разделов 1.4
(заявления о свойствах), 5.1.1 (продукты), 7 (голос бренда).
Если для карточки нужен факт, которого нет в файле со статусом
"подтверждено" - не придумывай, оставь плейсхолдер и укажи, чего
не хватает. После текста карточки выведи отдельным блоком
"СЛУЖЕБНЫЙ ОТЧЁТ": какие ID claims и продуктов использованы.
Подтверди, что прочитал файл, и жди задание.
Шаг 3. Рабочий промпт:
Напиши карточку товара для product.03 (термобельё LOLLO, размер 98–104).
Канал: сайт, карточка каталога. Аудитория: родители детей 4–6 лет.
Объём: 400–500 слов. Обязательно используй claim.02 и claim.05,
если их статус "подтверждено" для этого продукта.
Модель достаёт характеристики из 5.1.1, разрешённые формулировки из 1.4, тон из 7.1–7.2, и не может вставить заявление, не привязанное к product.03 по правилу дифференциации источника (раздел 6.4 BrandCore).
---
Пример 2 - статья в блог с проверкой на дубли
Стартовый промпт (тот же чат, что и выше, или новый с тем же файлом):
Работай по BRANDCORE.md. Перед структурой статьи сверься с реестром
существующих материалов (раздел 10.5) - если он заполнен, проверь,
не дублирует ли новая тема уже существующий материал (правило 10.3).
Если реестр не заполнен или неполон - явно скажи об этом, не делай
вид, что дублей нет.
1. Файл прикладывается один раз на чат - не нужно копировать его в каждое сообщение.
2. Стартовый промпт всегда фиксирует: (а) какие статусы допустимы к использованию, (б) требование служебного отчёта, (в) канал-специфичные ограничения (реклама/карточка/статья имеют разные правила по разделу 6.4).
3. Рабочий промпт - обычное творческое задание, но с явной привязкой к ID записей (claim.NN, product.NN, fact.NN), а не к абстрактному "в нашем фирменном стиле".
#DrMax