Модель документации продукта¶
У каждого публичного продукта или услуги DETai есть собственный документационный узел. Он отвечает и человеку, и агенту на четыре разных вопроса: что это, как этим пользоваться, почему это допустимо и как это устроено.
Обязательные представления¶
| Представление | Главный вопрос | Типичное содержание |
|---|---|---|
| Product overview / Charter | Что это за продукт и для кого он существует? | назначение, аудитория, owner, lifecycle, value proposition, status |
| Пользовательская документация | Как получить результат? | начало работы, сценарии, инструкции, FAQ, ограничения, поддержка |
| Trust и ответственное использование | Когда и как продукт допустимо применять? | intended/excluded use, данные, privacy, oversight, risks, claims, release status |
| Техническая документация | Как продукт устроен и интегрируется? | архитектура, API, конфигурация, deployment, observability, runbooks |
| Offer и Evidence | Что именно предлагается и чем подтверждено? | доступ, price/terms, пилоты, metrics, evidence, ограничения обещаний |
Мысли, R&D-инициативы и внутренние версии v0.x не обязаны создавать этот комплект. Product Candidate может начать с одной страницы, которая постепенно становится каноническим продуктовым узлом к публичному выпуску.
Правило размещения¶
Каноническая документация живёт рядом с owning system:
- цифровой продукт Platform DETai — в его продуктовой ветке;
- образовательная программа — в образовательном контуре институционального слоя;
- психотерапевтическая услуга — в контуре практики и супервизии;
- общая capability — рядом с технологической или knowledge-инфраструктурой.
Каталог продуктов не копирует эти страницы, а собирает связи и сравнимые статусы. Product–Market System владеет общими требованиями к Product Object, ценностному предложению, offer и lifecycle, но не присваивает себе локальную документацию продукта.
Минимальный маршрут пользователя¶
Запрос вида «как пользоваться Психологией в цитатах?» должен приводить прямо к пользовательскому руководству продукта, а не к бизнес-модели DETai. На обзорной странице продукта должны быть видны:
- короткое обещание результата;
- кнопка или ссылка «Начать»;
- пошаговые сценарии;
- ограничения и ответственное использование;
- поддержка и обратная связь;
- статус версии и дата актуальности.
Основной публичный ответ раскрывает пользовательскую ценность: кому помогает продукт, в какой ситуации и какой результат становится возможен. Экосистемная значимость хранится в каноническом узле и добавляется на сайт только тогда, когда помогает внешнему человеку понять происхождение или отличительную роль продукта.
Смысловой каркас публичной страницы¶
Публичная страница продукта может собираться из трёх смысловых слоёв. Это не жёсткий визуальный шаблон: секции можно объединять, переименовывать или менять местами, если пользователь и агент по-прежнему находят ответы без восстановления скрытой логики.
| Слой | На какой вопрос отвечает | Типичное содержание | Кто удерживает смысл |
|---|---|---|---|
| Пользовательская ценность | Зачем продукт нужен человеку? | ценностная формулировка, естественные GEO-вопросы с видимыми ответами, сценарии пользы | владелец продукта и Product–Market; Brand & Communications переводит утверждённый смысл в язык канала |
| Получение результата и доступ | Как человек получает ценность сейчас? | текущая доступность, вход в продукт, пользовательские сценарии, демонстрация результата, уровни доступа, offer и CTA | владелец продукта и U.L.I. подтверждают реальные возможности; Product–Market удерживает доступ и offer; владелец сайта воплощает их публично |
| Ответственность, экосистемное место и границы | Кто удерживает продукт, зачем он нужен DETai и в каких пределах допустим? | значимость для экосистемы, ответственные роли, Trust и Legal, правила и политики, связь с канонической документацией | владелец продукта, Management Layer и применимые Trust, Legal или профессиональные роли; Brand & Communications собирает публичную проекцию |
Одна визуальная секция сайта может объединять результаты нескольких доменов. Такое объединение не передаёт владельцу сайта или Management Layer право самостоятельно менять продуктовую ценность, технический статус, Trust-границы или Legal-условия. Management Layer координирует эстафету и проверяет согласованность представлений.
Маршрут агента¶
Агент должен уметь пройти от каталога к Product Object, затем к пользовательскому сценарию, Trust-гейту, evidence и технической реализации. Связи фиксируются стабильными document IDs и relation types, а не только положением страницы в меню.
Связанные представления продукта¶
Канонический узел продукта должен явно связывать минимум четыре представления:
- проект и owning repository;
- публичную версию или runtime;
- страницу продукта на основном сайте;
- источник эксплуатационных и продуктовых показателей.
Для этого используются существующие links.document_links, links.external_links, стабильный descriptive.id и видимый раздел «Связанные представления» в продуктовой странице. Отдельный параллельный реестр соответствий не создаётся.
Если конкретное представление отсутствует, это отмечается явно: например, public page: not created или metrics source: not connected. Так агент отличает неприменимую связь от забытой синхронизации.
Интерфейс синхронизации¶
Этот документ определяет, какие продуктовые представления должны существовать, но не оркестрирует их обновление. Сквозной процесс принадлежит Management Layer и описан в разделе «Management-оркестрация зависимых представлений» карты источников истины.
Product–Market подтверждает изменившуюся ценностную формулировку и показатели. Brand & Communications и владельцы конкретных каналов обновляют сайт, GEO/SEO, каталог и другие публичные проекции. Management Layer определяет затронутых владельцев и закрывает событие синхронизации.
Контракт для GEO-вопросов¶
Канонический узел хранит ценностную формулировку и два смысловых вопроса:
- кому и в какой ситуации помогает продукт;
- какой результат становится возможен и благодаря какому существенному свойству.
Страница сайта может показать их как два FAQ-вопроса, объединить в один естественный вопрос или распределить между заголовком и видимым ответом. Важно сохранить обе стороны ценности, а не точную грамматическую форму шаблона.
Граница публичности¶
Публичные инструкции, ограничения и claims находятся в Knowledge Substrate или на сайте продукта. Секреты, персональные данные, уязвимости, договорные оригиналы и эксплуатационные ключи остаются в соответствующих закрытых источниках истины.