Тендеры и лиды
Информация
Материал будет полезен владельцам цифровых продуктов и руководителям проектов, у которых один факт одновременно живёт на сайте, в базе знаний, презентациях и ответах ИИ. Ниже — модель из семи слоёв, минимальная карточка данных и план двухнедельного пилота, помогающие не выдавать план за работающий продукт.
У физического пространства есть свойства, которых нет у презентации. Гость приехал или не приехал. Корпус введён в эксплуатацию или только обсуждается. Команда приняла новый регламент или продолжает работать по старому. У сайта и ИИ другая природа: они способны бесконечно воспроизводить однажды записанную формулировку.
Так возникает тихое расхождение. Например, в типовой ситуации архитектор уже изменил проект, но на лендинге остаётся прежний рендер. Или пилот завершён, а в базе он всё ещё называется «в разработке». Бывает и обратное: подробное техническое задание незаметно превращается в описание якобы готового продукта. Чем убедительнее дизайн и свободнее говорит ИИ, тем труднее посетителю заметить подмену.
В нашем случае отправной точкой стал действующий 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.
Заполнить заявку
13731 тендер
проведено за восемь лет работы нашего сайта.
Общий индекс всех документов выглядит быстрым решением. На практике он смешивает публичные факты, договоры, личные сообщения, устаревшие презентации и планы. Модель получает много контекста, но не получает права решать, какой источник сильнее.
Безопаснее создать реестр разрешённых источников. Для каждого указываются:
область применения;
уровень доступа;
статус документа;
дата последней проверки;
владелец;
допустимые сценарии использования;
срок хранения или дата ревью.
Ответ 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.
