Тендеры и лиды
Информация
Материал будет полезен владельцам цифровых продуктов и руководителям проектов, у которых один факт одновременно живёт на сайте, в базе знаний, презентациях и ответах ИИ. Ниже — модель из семи слоёв, минимальная карточка данных и план двухнедельного пилота, помогающие не выдавать план за работающий продукт.
У физического пространства есть свойства, которых нет у презентации. Гость приехал или не приехал. Корпус введён в эксплуатацию или только обсуждается. Команда приняла новый регламент или продолжает работать по старому. У сайта и ИИ другая природа: они способны бесконечно воспроизводить однажды записанную формулировку.
Так возникает тихое расхождение. Например, в типовой ситуации архитектор уже изменил проект, но на лендинге остаётся прежний рендер. Или пилот завершён, а в базе он всё ещё называется «в разработке». Бывает и обратное: подробное техническое задание незаметно превращается в описание якобы готового продукта. Чем убедительнее дизайн и свободнее говорит ИИ, тем труднее посетителю заметить подмену.
В нашем случае отправной точкой стал действующий Narayana Center в Сочи. Вокруг реального объекта постепенно появились самостоятельные публичные маршруты: работа с пространствами, обучение, медиа, цифровые инструменты и другие инициативы. На живой карте Narayana они показаны с разными статусами, а личный сайт основателя выполняет роль публичного офиса. Это важное разделение: карта помогает понять систему, но сама по себе не доказывает операционную готовность каждого элемента.
Главный вывод из практики прост: сначала нужно спроектировать не «экосистему экранов», а цепочку достоверности.
В этой статье я предлагаю модель из семи слоёв. Их можно реализовать в Obsidian, Notion, Git, CMS, таблице или собственной системе — выбор инструмента вторичен.
Это объект, люди и процессы: номерной фонд, мероприятие, договорённость, стройка, меню, регламент, обращение гостя, работа команды. Здесь возникает факт.
Цифровая система не должна считать фактом намерение. Фраза «хотим открыть направление» относится к плану; «страница опубликована» — к цифровому результату; «услуга оказана реальному клиенту» — к операционному результату. Это три разных события.
Каждому значимому изменению нужен след: утверждённый документ, публичный URL, запись решения, результат теста, акт, фотография с понятным происхождением, строка подтверждённой таблицы. Доказательство должно отвечать на четыре вопроса:
что именно произошло;
когда;
для какого объекта или направления;
кто имеет право подтвердить результат.
Доказательство не обязано быть публичным. Но публичное утверждение должно вести к разрешённой версии доказательства или хотя бы к ответственному владельцу факта.
Канонический узел хранит текущее решение, а не весь шум вокруг него. Его задача — показать название, статус, источники, дату проверки, владельца и ограничения. История изменений сохраняется отдельно и не подменяет текущую версию.
Именно здесь устраняется конфликт между старым ТЗ и новым фактом. Если ранняя схема описывает целевую платформу, а публично работает только отдельный сайт, каноническая запись обязана говорить: «сайт действует; единый кабинет — в развитии». Иначе план начинает маскироваться под продукт.
Карта нужна не ради красивой оргструктуры. Она отвечает на три управленческих вопроса:
Что это за самостоятельная сущность?
Как она связана с другими?
Куда человек должен перейти дальше?
Карточка на карте — маршрут, а не доказательство существования бизнеса. Поэтому число карточек, страниц и доменов нельзя использовать как число запущенных компаний или продуктов.
Сайт — разрешённая проекция канонических данных для внешней аудитории. Он объясняет смысл простым языком, но не меняет статус сущности самостоятельно. Если редактору приходится вручную исправлять один и тот же факт на пяти страницах, архитектура уже создаёт расхождения.
ИИ помогает найти источник, сопоставить версии, подготовить черновик и показать противоречия. Он не повышает статус документа и не получает право принимать внешнее обязательство. NIST AI RMF рассматривает управление ИИ как полный цикл govern, map, measure и manage; принципы OECD отдельно подчёркивают прозрачность, надёжность и ответственность.
Реальные вопросы гостей, ошибки сотрудников, статистика переходов, замечания редакторов и результаты тестов возвращаются в каноническую запись. Без этого сайт остаётся витриной, а база — архивом.
В итоге получается не линейная публикация, а контур:
физическое событие
→ доказательство
→ каноническая запись
→ карта и сайт
→ разрешённый AI-поиск
→ действие человека
→ обратная связь в реальный процесс
Для первого пилота не нужна сложная онтология. Достаточно одной структурированной карточки:
id: center-001
name: Название направления
status: active
status_reason: "Услуга доступна; ответственный и рабочий маршрут подтверждены"
public_summary: "Что реально доступно человеку сейчас"
canonical_url: "https://example.com/"
evidence:
- type: public_page
url: "https://example.com/service"
verified_at: "2026-08-27"
owner_role: "руководитель направления"
last_verified_at: "2026-08-27"
next_review_at: "2026-09-27"
allowed_for_publication: true
allowed_for_ai: true
human_review_required: true
known_limitations:
- "не обещать функции, которых нет в текущем интерфейсе"
В боевой системе лучше хранить идентификатор владельца, а не его личные контакты. Публичное описание и внутренние заметки должны быть разными полями и иметь разные права доступа.
Стандарт W3C PROV-O предлагает формальную модель происхождения данных через сущности, действия и ответственных агентов. Для небольшой команды не обязательно сразу внедрять RDF: достаточно перенять принцип — результат должен быть связан с тем, из чего, кем и в каком процессе он получен.
Статусы должны менять поведение сайта и ИИ, а не служить декоративными ярлыками. Для первого пилота можно начать с шести:
active / действует. Есть доступный процесс, владелец и подтверждение. Публично можно говорить, что доступно сейчас, для кого и на каких условиях.
pilot / пилот. Идёт ограниченный реальный тест. Публично указываются цель пилота, границы и критерии решения.
launching / запускается. Ведётся подготовка к открытию с назначенными действиями. Публично описывается то, что готовится, без изображения как завершённого.
development / в развитии. Сущность проектируется или создаётся. Публично раскрываются целевая польза, текущий этап и ограничения.
planned / план. Есть намерение, но нет подтверждённого запуска. Публично можно объяснить, зачем идея рассматривается и что ещё нужно проверить.
paused / приостановлено. Работа остановлена до нового решения. Публично указываются причина остановки и условие пересмотра.
Архив — не ещё один публичный статус, а режим хранения истории. Если сущность закрыта, сайт должен либо честно показывать завершение, либо перенаправлять на актуальный маршрут без сохранения старого обещания.
У каждого статуса должны быть входные критерии. Например, active нельзя выставить только потому, что готов лендинг. Нужны хотя бы владелец процесса, доступный путь для пользователя, инструкция обработки обращения и доказательство успешного прохождения полного сценария.
Распространённая архитектурная ошибка — копировать тексты из базы в CMS вручную. Через месяц появляются несколько «правильных» версий.
Лучше разделить два слоя:
контентный контракт: структурированные факты, статусы, URL и ограничения;
представление: заголовок, композиция, иллюстрации и адаптация под аудиторию.
Один и тот же контракт может формировать карточку на карте, блок личного сайта, страницу направления и контекст для ИИ. При этом тексты не обязаны быть одинаковыми: одинаковыми остаются только проверяемые поля.
На сборке сайта полезно автоматически проверять:
у каждой публичной карточки есть статус и дата проверки;
active имеет рабочий канонический URL;
нет двух сущностей с одним идентификатором;
внутренние поля не попали в публичный JSON;
ссылки отвечают ожидаемым статусом;
одна страница не называет проект действующим, если контракт говорит pilot;
многоязычные версии ведут на соответствующий маршрут и не меняют смысл статуса;
sitemap содержит канонические страницы, а не все технические копии.
Google определяет canonical как представительную версию среди похожих URL и рекомендует согласовывать канонические сигналы — редиректы, rel="canonical" и sitemap. Это не только SEO-вопрос: единый публичный адрес помогает команде понимать, какую страницу считать действующей. Официальное описание механизма есть в Google Search Central.
Есть задача на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR? Создайте тендер и выберите подходящего исполнителя из откликов.
Заполнить заявку
13842 тендера
проведено за восемь лет работы нашего сайта.
Общий индекс всех документов выглядит быстрым решением. На практике он смешивает публичные факты, договоры, личные сообщения, устаревшие презентации и планы. Модель получает много контекста, но не получает права решать, какой источник сильнее.
Безопаснее создать реестр разрешённых источников. Для каждого указываются:
область применения;
уровень доступа;
статус документа;
дата последней проверки;
владелец;
допустимые сценарии использования;
срок хранения или дата ревью.
Ответ AI-помощника также должен быть структурирован:
{
"answer": "Краткий ответ",
"status": "development",
"sources": ["https://example.com/canonical-page"],
"source_verified_at": "2026-08-27",
"uncertainty": "Не подтверждена дата публичного запуска",
"requires_human_review": true
}
Если разрешённого источника нет, корректный результат — «не подтверждено», а не правдоподобное продолжение. Если два канонических источника противоречат друг другу, система должна остановить публикацию и создать задачу владельцу факта.
Human gate особенно нужен перед:
публикацией от имени основателя или компании;
финансовым, юридическим или медицинским утверждением;
отправкой сообщения внешнему человеку;
изменением статуса направления;
раскрытием персональных или конфиденциальных данных;
действием, которое сложно отменить.
ИИ может подготовить разницу между версиями, список источников и черновик. Решение о внешнем обещании остаётся у человека с соответствующей ролью.
Рассмотрим нейтральный пример: пилот сервиса завершён, и команда считает его готовым к постоянной работе.
Событие. Владелец процесса фиксирует завершение пилота.
Пакет доказательств. Сохраняются результаты, ограничения, ответственный и рабочий пользовательский маршрут.
Проверка критериев. Команда сверяет Definition of Done для active.
Решение. Уполномоченный человек меняет статус и записывает причину.
Обновление канона. Меняются публичное описание, дата проверки и ограничения.
Сборка. Сайт автоматически обновляет карточки и проходит тесты ссылок, статусов и утечек.
Переиндексация AI. В разрешённый индекс входит новая версия; предыдущая остаётся в истории, но исключается из текущих ответов.
Контрольный вопрос. Человек задаёт помощнику типовой и провокационный вопросы: «что работает сейчас?» и «какие функции гарантированы?»
Наблюдение. Через установленный срок команда проверяет реальные обращения и ошибки.
Если любой шаг невозможно подтвердить, статус остаётся прежним. Красивый экран не закрывает отсутствие операционного процесса.
При развитии публичной карты особенно полезными оказались пять анти-паттернов.
1. Страница равна продукту. Запущенный домен подтверждает только наличие страницы. Он не доказывает команду, сервис и повторяемый результат.
2. Процент цифровой готовности равен готовности бизнеса. Интерфейс может быть собран на 90%, а договоры, операционная модель или поддержка — нет. Поэтому процент должен явно называться готовностью цифрового контура и не заменять статус направления.
3. Старое ТЗ сильнее нового факта. Подробный документ производит впечатление авторитетности. Но опубликованный и проверенный текущий маршрут приоритетнее раннего замысла; ТЗ сохраняется как история и цель.
4. ИИ знает всё, что лежит в базе. Модель находит текст, но не получает полномочий подтвердить его истинность. Без происхождения, статуса и даты поиск только ускоряет ошибку.
5. Основатель отвечает за всё лично. Публичная роль основателя создаёт доверие, но операционные направления должны иметь собственных владельцев, правила и границы. Иначе цифровая экосистема масштабирует зависимость от одного человека.
Проекту нужен не только маршрут запуска, но и легальный способ остановиться. Заранее определите триггеры:
польза не подтверждена;
стоимость полной проверки выше эффекта;
источник данных ненадёжен;
права доступа нельзя сузить;
команда не понимает, кто принимает результат;
публичный текст требует обещания, которое нельзя доказать.
В таком случае зрелым результатом будет paused, сужение задачи или отказ от ИИ. «Мы остановили сценарий после теста» — более ценное знание, чем бесконечный статус «почти готово».
Не начинайте со всей компании. Выберите один повторяющийся внешний вопрос — например, «какие услуги доступны сейчас?».
Найдите все версии ответа: сайт, презентации, документы, письма. Не удаляйте противоречия. Зафиксируйте их.
Назначьте владельца, статус, публичное описание, источники, ограничения и дату ревью. Утвердите словарь статусов.
Соберите одну страницу или карточку из структурированных полей. Добавьте проверки URL, статуса и запрета внутренних полей.
Подключите только разрешённые источники. Ответ должен содержать статус, ссылку, дату и неопределённость. Автоматическую отправку отключите.
Проверьте обычные, устаревшие и конфликтные формулировки. Обязательные случаи: отсутствие источника, архивный документ, два разных статуса, просьба раскрыть внутренние данные.
Дайте сценарий будущему пользователю. Измерьте не скорость генерации, а полный цикл: поиск, проверку, исправления и итоговое решение.
Выберите один из четырёх исходов: масштабировать, сузить, доработать или остановить. Обновите каноническую запись и дату следующего ревью.
Перед запуском задайте 12 вопросов:
Есть ли один канонический источник текущего статуса?
Видно ли происхождение каждого внешнего утверждения?
Разделены ли действующее, пилот, развитие и план?
Есть ли владелец факта и дата следующей проверки?
Может ли сайт получить статус из общего контракта, а не из копии текста?
Исключены ли закрытые поля из публичной сборки?
Получает ли ИИ только разрешённые источники?
Возвращает ли он ссылку, дату и неопределённость?
Умеет ли он сказать «не подтверждено»?
Останавливаются ли чувствительные действия перед решением человека?
Есть ли тесты на устаревший и конфликтный источник?
Можно ли отключить один сценарий, не ломая весь контур?
Если на несколько критичных вопросов ответ «нет», сначала стоит закрыть эти пробелы и только затем масштабировать систему.
Полная цифровая модель живого объекта требует постоянного обновления: реальность меняется быстрее любой зафиксированной версии. Практическая цель скромнее и полезнее — сделать расхождение видимым и управляемым.
Карта даёт человеку навигацию. База знаний хранит происхождение и статус. Сайт переводит разрешённые факты в понятный маршрут. ИИ помогает найти и сопоставить, но не присваивает себе право подтверждать. Человек принимает решение и возвращает результат в реальный процесс.
Так цифровая экосистема перестаёт быть коллекцией страниц. Она становится дисциплиной, в которой каждое публичное обещание можно проследить до факта, ответственного и даты проверки.
Вениамин Ткачук — предприниматель, основатель действующего Narayana Center в Сочи и инициатор Narayana · Sattva Business Ecosystem.
