Explore

Описание Агента

Описание функционирования Проводника

Ниже — как может быть устроено функционирование ИИ‑Проводника (от миссии до ежедневной работы), чтобы проводить человека по персональной траектории развития (PTR) от случайного до проактивного ученика и при этом самообучаться.

⁠

0) Картина целиком — «миссия → петли управления»

Цель: ускорить переход между ступенями «Ученик»: случайный → практикующий → систематический → дисциплинированный → проактивный.

Главная идея работы: Проводник ведёт несколько вложенных петель:

Слот (25–50 мин) — исполнение конкретного метода (помидоро + обязательный отдых).

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

Неделя — выбор одного главного ограничения по траектории + «типовой вызов недели».

Месяц/квартал — смена ступени, пересборка привычек/ритмов, корректировка стратегий персонализации.

Во всех петлях действует одна и та же цепочка: Воспринять → Спланировать (с учётом ограничений) → Персонализировать → Исполнить → Замерить → Обучиться → Обновить политику.

⁠

1) Архитектура в действии (кто и что делает)

Мозг (ядро + Эво) — оркестратор: применяет Методы, управляет Памятью, решает, когда и что делает каждый Узкий ИИ‑агент.

Узкие ИИ‑агенты — «инструменты» под функции: Методист (подбор методов), Планировщик ограничений, Персонализатор и дозирование, Оператор слотов, Телеметрист, Аудитор приёмки, Аналитик, Мотиватор/коуч, Интегратор экзокортекса.

Память — общая шина знаний + локальные памяти агентов; CDH (цифровой двойник человека) — профиль, состояния (энергия/фокус), ритмы, навыки, роли/ступени, проекты, окружение, история Work/метрик; Библиотека материалов — курируемые курсы/методики/примеры, размеченные по ролям, ступеням, сложности и когнитивной нагрузке.

⁠

2) Модель состояния (CDH) — на чём строится персонализация

В CDH хранятся и обновляются:

Роли и текущая ступень «Ученик», чек‑листы ступеней, «зелёные ворота» (готовность к следующему шагу).

Ресурсы (время/энергия/внимание) на окна «день/неделя» — Проводник планирует внутри бюджетов, а не поверх.

Ритмы (сон/работа/перерывы), окна доступности, предпочтения форматов (текст/аудио/видео/практика).

Профиль привычек (что уже автоматизировано, а что требует усилий), окружение и состояние экзокортекса.

PFI — индекс соответствия персонализации: попадает ли доза/сложность в «окно» пользователя.

⁠

3) Операционные петли (что происходит на каждом горизонте)

3.1 Слот (25–50 мин)

Гейтинг: есть ли «зелёный» по роли и ресурсы в CDH.

Исполнение метода (например, «медленное чтение с заметками»).

Запись Work: начало/конец, что сделано, какой артефакт создан.

Обязательный отдых (микродосуг) и быстрая самооценка состояния (энергия/фокус).

3.2 День

Восприятие: короткий чек‑ин (самочувствие, фокус), синхронизация календаря/экзокортекса → обновление CDH.

План‑на‑день: 2–4 слота под одно узкое место; персонализатор задаёт дозу/сложность/формат/примеры.

Вечерняя ретроспектива: план‑факт, мини‑выводы; обновление PFI.

3.3 Неделя

Выбор главного ограничения (ToC): «что сдерживает переход на следующую ступень» (например, «нет ежедневной фиксации Work»).

Типовой вызов недели — один эксперимент для встраивания новой практики (например, «ежедневная фиксация двух заметок из чтения»).

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

Ретро и приёмка сервисов (человеческих/ИИ): что обещали → что реально дали (по Work и SLO).

3.4 Месяц/квартал

Смена ступени (если пройдены «ворота»): новые чек‑листы, повышение сложности и автономности.

Пересборка привычек, ритмов, окружения; обновление весов в формуле Reward и правил персонализации.

A/B‑результаты: что работало у этого человека и у схожих профилей.

⁠

4) Конвейер решений — от восприятия до исполнения

Восприятие и фокус (E2.1.1) Сбор сигналов → фильтрация шума → постановка фокуса (день/неделя).

Планировщик ограничений (E2.1.2) Вычисляет узкое место по траектории, учитывая бюджеты время/энергия/внимание из CDH, делает what‑if симуляции.

Каталог методов (E2.1.3) Отбирает методы под роль/ступень, с пометками сложности, когнитивной нагрузки, уровня формальности (F), области применимости (G).

Персонализация и дозирование (E2.1.6) Собирает RecSpec: конкретные задания на сегодня/неделю — сколько, какой сложности, в каком формате, с какими примерами. Цель — PFI близко к 1.0.

Операционный конвейер (E2.1.4) Превращает RecSpec в слоты, следит за перерывами, пишет Work/продукты, обновляет CDH и план‑факт.

Сбор показателей (E2.1.5) Сводит систематичность, инвестированное время, выпуск продуктов, состояние, прогресс по ступеням, PFI → отдаёт в Reward.

⁠

5) Измерение, награда и самообучение

Метрики (CSLC). У каждой — характеристика, шкала, окно и способ свода (Γ). Примеры недельных: Систематичность (доля дней с ≥1 слотом), PFI (среднее по дням), План→факт по времени, Выпуск продуктов, Микропаузы соблюдены.

Reward. Внутренний сигнал пользы для обучения Проводника (не для пользователя). Скелет формулы на неделю: Reward = 0.35·Систематичность + 0.25·Выпуск + 0.20·PFI + 0.10·План→факт + 0.10·Прогресс по воротам, с корректировкой по Assurance (низкий R по источникам снижает вес).

Петля эволюции (E2.2.2). Проводник генерирует гипотезы (NQD), запускает безопасные эксперименты (A/B вариантов дозирования/форматов/примеров), ведёт E/E‑LOG (explore↔exploit), пересчитывает веса в Reward и правила персонализации.

Приёмка сервисов (E2.2.1). Любой сервис (в т.ч. «человеческий») принимается только по Work и SLO. Вклад принятого сервиса учитывается в аналитике и может повышать его приоритет.

⁠

6) Переходы между ступенями «Ученик» (ворота и сигналы)

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

Случайный → Практикующий. ≥4 слота/неделю 2 недели подряд; ≥2 рабочих продукта/неделю; PFI ≥ 0.6.

Практикующий → Систематический. ≥5 дней из 7 с ≥1 слотом 3 недели; план→факт ≥0.8; ежедневная фиксация Work.

Систематический → Дисциплинированный. ≥2 слота/день ≥5 дней, без пропусков перерывов; устойчивый выпуск; чтение+заметки ежедневно.

Дисциплинированный → Проактивный. Самостоятельное инициирование и дробление задач; запуск «типовых вызовов» без напоминаний; PFI устойчиво 0.8+; рост агентности (см. ниже).

Автоматизация смены ступени: Gatekeeper проверяет критерии → меняет ступень в CDH → Планировщик повышает сложность/дозу и автономность.

⁠

7) Как Проводник меняет стиль жизни (не «штурм», а системная перестройка)

Микро‑привычки и эшелонированный досуг. После каждого слота — обязательный короткий отдых; на неделе — «лесенка» досуга (короткий/средний/длинный).

Смена окружения. Мягкие интервенции: очистка ленты/подписок, организация рабочего места, «якоря» для чтения/письма.

Экзокортекс. Настройка внешней памяти (папки, теги, быстрый вход в конвейер заметка→черновик→заготовка).

Ритуалы. Старт дня, старт слота, завершение дня, недельное ревью — одинаковые, простые и проверяемые по Work.

⁠

8) Взаимодействие с человеком (этика и согласие)

Инициативные запросы идут только при ожидаемом выигрыше выше порога, с cool‑down и видимыми причинами («узкое место Х; ожидаем +Δ систематичности»).

Fair‑персонализация: верхние/нижние границы дозы и сложности; человек может оверрайдить (вручную скорректировать) план; Проводник объясняет, почему предлагает изменение.

Понятный «выход»: в любой момент можно поставить на паузу, изменить частоты, удалить данные не‑критичной важности (с учётом зависимостей).

⁠

9) Роли узких ИИ‑агентов (типичный набор для MVP)

Методист. Подбор методов и типовых вызовов по ролям/ступеням (с учётом F/G/нагрузки).

Планировщик ограничений. Находит «бутылочное горлышко», считает бюджеты по CDH, выпускает недельный WorkPlan.

Персонализатор/дозирование. Выдаёт RecSpec (сложность/доза/формат/примеры).

Оператор слотов. Таймеры, перерывы, фиксация Work/продуктов.

Телеметрист. Сбор метрик, расчёт PFI.

Аудитор приёмки. Сверка Work с SLO, решения по сервисам.

Аналитик. Атрибуция вклада в Reward; подсказки для планировщика.

Мотиватор/коуч. Вежливые «недопины» на основе CDH (без давления, по окнам доступности).

Интегратор экзокортекса. Подключение заметочников/календарей/репозиториев.

⁠

10) Пример «как это ощущается» для стажёра (первые 2 недели)

День 0 (онбординг). Короткая анкета, подключение календаря/заметок, сбор базовой недели ритмов. Формируются цели и первичная ступень «Случайный». Неделя 1. Узкое место — отсутствие ежедневной фиксации. Вызов недели: «1 слот/день 5 дней; 1 заметка/день; 2×10‑мин перерыва». Материалы — минимальной сложности из Библиотеки + 1 практический пример «под проект». Неделя 2. Если PFI ≥0.6 и систематичность ≥0.7 — добавляется второй слот 2 раза за неделю, вводится короткое письмо‑мышление (черновик 100–150 слов). Начинается A/B по формату (аудио vs текст).

⁠

11) Самообучение Проводника — безопасно и прозрачно

Где исследует. В дозировании, выборе формата, последовательности методов, паразитов окружения, конвейере чтение→письмо.

Как ограничен. Любой эксперимент помечен, идёт с порогами риска: не меняет «обязательные» перерывы, не превышает бюджеты, не ломает приватность.

Как учится. NQD‑оценка гипотез → запуск малых тестов → сравнение по Reward и метрикам → обновление весов/правил → DRR‑запись «почему».

⁠

12) Минимальный «Definition of Done» для MVP

Петли: день и неделя полностью замкнуты (план → исполнение → метрики → ретро → корректировка).

PFI: рассчитывается ежедневно, используется в персонализации.

Work: каждый слот оставляет артефакт (заметка/черновик/заготовка).

Ворота ступеней: автоматические проверки, прозрачные объяснения перехода/неперехода.

Приёмка сервисов: только по Work и SLO.

Этика: согласия/отзыв, cool‑down, объяснимость инициатив.

⁠

Коротко: почему это работает

Одно узкое место за окно (неделя) → концентрированный прогресс.

Персонализация по CDH (доза/сложность/формат/примеры) → меньше срывов, выше PFI.

Измеримость и приёмка по Work → реальный, наблюдаемый рост.

Самообучение под контролем (Assurance/Reward/DRR) → система эволюционирует, не ломая человека.

Если хотите, сформирую шаблон операционных экранов (день/неделя) и паспорта: метрики, метод, материал — чтобы сразу начать наполнять конкретикой под ваш контент.

Структура описания Мозга

Основная терминология

Базовые сущности

ИИ‑Проводник — целостный ИИ‑агент, миссия которого — проводить человека по Траектории развития, помогая строить успешные системы.

Мозг — центральная управляющая подсистема ИИ‑Проводника (ядро рассуждения и оркестрации), применяющая Методы, управляющая Памятью (Общей и Локальными) и оркестрирующая Узких ИИ‑агентов.

Узкий ИИ‑агент — специализированный агент (инструмент) под отдельную функцию (например, методист, навигатор, оценщик, мотиватор, консультант и т.п.); часть ИИ‑Проводника, имеет Локальную память и Сервисы с SLO/SLA.

Общая память ИИ‑агента (шина знаний) — единое хранилище Эпистем, артефактов (Work/WorkPlan/DRR/Метрики), UTS, данных CDH и индексов Библиотеки материалов; источник для RAG.

Локальная память Узкого ИИ‑агента — прикладное хранилище конкретного Узкого ИИ‑агента; синхронизируется с Общей памятью.

Экзокортекс — внешняя память пользователя (инструменты/архивы), учитываемая ИИ‑Проводником при воздействии.

Цифровой двойник человека (CDH) — динамическая модель пользователя в Общей памяти: профиль, состояния (энергия/настроение/фокус), ритмы, предпочтения, навыки, проекты/роли/ступени, окружение, связи с Экзокортексом и история Work/метрик. Используется для диагностики, персонализации, выбора методов и симуляций what‑if.

Библиотека материалов — курируемый фонд: руководства/курсы, методические материалы, мета‑мета‑модели, каталог проблем ЦА и типовых вызовов; связана с UTS, Каталогом методов, ролями/ступенями и персональными профилями CDH.

Знание, контекст и термины

Эпистема — единица знания (понятие, теория, правило, модель) в памяти; имеет источники, версию и TTL.

Единый терминологический слой (UTS) — глоссарий/таблицы соответствий терминов с карточками и статусами.

Контекст (Bounded Context) — локальная рамка смысла с инвариантами.

Мост контекстов (Bridge) — явное сопоставление понятий между Контекстами; CL (Congruence Loss) — измерение потери смысла при переносе.

Роли и процессы

Роль — контекстная функция участника (в т.ч. Человек:Поставщик сервиса).

Ролевое состояние (RSG) — жизненный цикл роли (Prepared/Ready/…).

«Зелёные ворота» — допуск к шагу Метода только при требуемом состоянии роли.

Траектория развития — маршрут ролей (Ученик → Интеллектуал → Профессионал → Исследователь) со Ступенями квалификации.

Ступени квалификации — уровни зрелости внутри роли (напр., для «Ученик»: случайный → практикующий → систематический → дисциплинированный → проактивный).

Персональная траектория развития (PTR) — индивидуальная последовательность шагов, Методов и заданий, вычисляемая на основе CDH; включает дозирование (объём/время), адаптивную сложность (уровень материала), уникализацию примеров и подбор форматов.

Работа и измерения

Метод / Описание метода — абстрактный способ действия / его спецификация.

План работ (WorkPlan) — намерение и календарь действий с бюджетами времени и ожидаемыми Рабочими продуктами (с учётом PTR и CDH).

Факт работы (Work) — протокол реально выполненных действий с тайм‑штампами и привязкой к Методу/Плану.

Рабочий продукт — наблюдаемый артефакт результата.

Показатели развития — измеримые характеристики прогресса.

CSLC (Characteristic / Scale / Level / Coordinate) — контракт задания метрики: Characteristic — что измеряем (напр., «Систематичность»), Scale — шкала и способ подсчёта (доля дней с ≥1 слотом), Level — значение (напр., 0.71), Coordinate — окно/привязка во времени (day/week/month, даты начала/конца).

Индекс соответствия персонализации (PFI) — метрика попадания сложности/дозы в «окно» пользователя (из CDH): ∈[0..1].

Доверие, награда и эволюция

Доверие и доказательства (Assurance) — дисциплина обоснования утверждений; включает якорение к свидетельствам (Evidence Anchoring), оценку F–G–R и контроль свежести.

F–G–R — тройка атрибутов качества знания/утверждения: F (Formality — Формальность) — уровень формальности от F0 (спонтанное наблюдение) до F9 (строгое формальное доказательство/код), G (Generality / ClaimScope — Область применимости) — контекст/условия, где верно утверждение, R (Reliability — Надёжность) — степень уверенности [0..1], зависящая от свидетельств и их свежести. Пример: F2 (практическая методика), G=«Траектория:Интеллектуал, неделя», R=0.78.

Награда Мозга (Reward/Value) — внутренний сигнал полезности для обучения и прогресса самого Мозга; агрегируется из Показателей развития, учитывает метки Assurance и защищена от переоптимизации (см. Proxy‑Audit/Goodhart).

Петля эволюции — цикл Run → Observe → Refine → Deploy (запуск, наблюдение, уточнение, развёртывание изменений).

Творческий абдуктивный контур — генерация гипотез; отбор через NQD и политика Explore↔Exploit.

NQD (Novelty / Quality / Diversity) — тройка критериев для отбора гипотез/идей: новизна, ожидаемое качество, диверсификация (обычно нормированные оценки 0..1).

Explore↔Exploit‑политика — правило баланса между исследованием новых стратегий и эксплуатацией уже работающих; ведётся логом решений (E/E‑LOG).

Планировщик ограничений — механизм ToC: выбор узкого места и минимального набора интервенций.

Сервисы и контракты

Способность (Capability) — потенциальная возможность исполнения (набор приёмов/ресурсов).

Сервис — внешнее обещание результата (в т. ч. «человеческий» сервис).

SLO/SLA — критерии качества сервиса (SLO) и соглашение об уровне сервиса (SLA).

Приёмка сервиса — решение по факту наблюдаемой работы (только по Work, не по обещанию).

Service Acceptance Binding — принцип: оценка сервиса по соответствию SLO на основе фактов Work в заданном окне времени.

Перенос смысла, свежесть и прокси

CL (Congruence Loss) — доля потери смысла при переносе понятий между контекстами (0..1). Например, CL=0.2 — перенос приемлем, CL≥0.5 — нужен пересмотр/адаптация.

TTL (Time‑to‑Live) — срок актуальности знания/артефакта; по истечении требуется ревизия (пересчёт Assurance/обновление).

Proxy‑метрика — косвенная метрика, которая может стать целью вместо реального результата.

Goodhart (Закон Гудхарта) — «когда метрика становится целью, она перестаёт быть хорошей метрикой».

Proxy‑Audit — политика выявления/ограничения злоупотреблений прокси‑метриками (весовые штрафы, пороги, ручная ревизия).

Политики LLM и данные

RAG — извлечение фактов из Общей памяти/UTS/Work/CDH/Библиотеки перед генерацией; must‑cite.

PII‑redaction — защита персональных данных.

SOP‑5 — минимальный регламент исполнения Метода: Trigger — что запускает действие, Decide — как выбирается альтернатива/решение, Act — что выполняется, Record — что фиксируется (Work/DRR/Метрики), Feedback — куда уходит обратная связь (Assurance/Reward/соседние модули).

Cool‑down — пауза между инициативными запросами к человеку.

⁠

Управление решениями и документирование

Журнал причин решений (DRR) — машиночитаемые записи о решениях/изменениях: альтернативах, свидетельствах, ожидаемом эффекте на Reward и рисках.

План‑факт — сопоставление планируемого (WorkPlan) и фактического (Work) исполнения за окно (день/неделя/месяц).

I. ЯДРО (Core) — «зачем/что/где и по каким правилам»

Блок 1.1 — Миссия

Модуль C1.1.1. Цели и намерение — миссия, Траектория развития; принципы персонализации (PTR): какие цели, ограничители и этика адаптации (доза/сложность/формат/уникализация примеров, окна времени).

Модуль C1.1.2. Самоописание ИИ‑Проводника — зона ответственности/не‑цели, аудитории, условия применения (в т.ч. требования к данным CDH и согласиям).

Модуль C1.1.3. Архитектура ИИ‑Проводника — состав (Мозг + Узкие ИИ‑агенты), шина знаний, встраивание CDH и Библиотеки материалов в контуры планирования/исполнения/аналитики.

Блок 1.2 — Знаниевая инфраструктура

Модуль C1.2.1. Контекст и рамки смысла — Контексты и Мосты (с CL) для переноса смысла.

Модуль C1.2.2. Целевые объекты воздействия — модель «человек/проекты/окружение/Экзокортекс/Роли/Ступени»; связи с профилями CDH.

Модуль C1.2.3. Архитектура общей памяти ИИ‑агента — шина знаний (Эпистемы, Work/WorkPlan/DRR/Метрики, UTS, CDH, индексы Библиотеки); права/TTL/синхронизация с Локальными памятями.

Модуль C1.2.4. Единый терминологический слой (UTS) — глоссарий и соответствия.

Модуль C1.2.5. Архитектура цифрового двойника человека (CDH) — схема данных, источники обновления (включая Work и опросы состояния), приватность/TTL; API симуляций what‑if для планировщика и персонализации.

Модуль C1.2.6. Библиотека материалов и учебных траекторий — фонд курсов/методичек/мета‑мета‑моделей/проблем ЦА; разметка по ролям, Ступеням, уровням сложности и когнитивной нагрузке; связи с Каталогом методов.

Блок 1.3 — Оценка и ограничения

Модуль C1.3.1. Доверие и доказательства (Assurance) — Evidence Anchoring, F–G–R, свежесть/CL; проверка качества персонализации (источники CDH и Библиотеки).

Модуль C1.3.2. Награда Мозга (Reward/Value) — агрегирует Показатели развития и PFI (индекс соответствия персонализации); управляет Explore↔Exploit; анти‑Goodhart/Proxy‑Audit.

Модуль C1.3.3. Нормы и защитные рамки — этика/приватность, Lexical Firewall, Notational Independence, Unidirectional Dependency, Bias‑Audit; политики fair‑персонализации и лимиты дозирования.

Блок 1.4 — Границы, роли и измеримость

Модуль C1.4.1. Роли и «Зелёные ворота» (RSG Gatekeeper) — допуск Методов с учётом состояния роли и готовности по CDH (энергия/фокус/время).

Модуль C1.4.2. Измерения и публикация изменений — CSLC; отчёты; агрегаты по CDH без PII; публикация PFI.

Модуль C1.4.3. Интерфейсы и сервисные контракты — Capability↔Service, SLO/SLA, приёмка по Work; контракты доступа к данным CDH/Библиотеки.

Модуль C1.4.4. Политика взаимодействия и согласия — триггеры инициативных запросов (узкое место/ожидаемый выигрыш), каналы, cool‑down, согласия/отзыв.

Модуль C1.4.5. Политика персонализации и дозирования — норматив PTR: правила изменения объёма/сложности/часов/примеров; предельные пороги, частота пересмотра, «человек‑в‑контуре» и ручные оверрайды.

⁠

II. ЭВО (Evo) — «как делаем, наблюдаем, учимся и перестраиваемся»

Блок 2.1 — Внешние действия для воздействия на целевые объекты (по траектории и узким местам)

Модуль E2.1.1. Восприятие и наведение внимания — сбор наблюдений о человеке/среде/Мозге; обновление CDH (фокус, состояния, окна доступности); постановка фокуса на день/неделю/месяц.

Модуль E2.1.2. Планировщик ограничений — выбор узкого места по Траектории; симуляции what‑if на CDH; формирование WorkPlan с адаптивным дозированием (бюджеты времени/сложность/форматы/уникальные примеры) и ожидаемыми Рабочими продуктами.

Модуль E2.1.3. Методический каталог переходов по ролям — выдаёт Методы/типовые вызовы по ролям/Ступеням; ссылается на Библиотеку материалов (варианты по сложности/нагрузке) и на профили CDH.

Модуль E2.1.4. Операционный конвейер работ и учёт времени — исполняет Методы в слотах (помидоро + обязательные перерывы), фиксирует Work и Рабочие продукты; синхронно записывает факт и состояние в CDH; ведёт план‑факт.

Модуль E2.1.5. Сбор показателей развития — агрегирует метрики недели/месяца (систематичность, время, выпуск, продуктивное состояние, работоспособность Экзокортекса, окружение, прогресс по Траектории, PFI) и передаёт их в Reward; обновляет сводные поля CDH.

Модуль E2.1.6. Персонализация и дозирование (Recommendation & Sequencing) — на базе CDH и Библиотеки подбирает индивидуальные задания/материалы, определяет сложность/дозу/уникализацию примеров, последовательность и формат (текст/аудио/видео/практика); выдаёт спецификацию задания в WorkPlan.

Блок 2.2 — Внутренние действия (саморегуляция и обучение Мозга)

Модуль E2.2.1. Рефлексия и приёмка сервиса — ретроспектива по Work; приёмка Сервисов Узких ИИ‑агентов/человеческих Сервисов по SLO; запись результатов и корректировок PTR/CDH.

Модуль E2.2.2. Самообучение и творчество — Петля эволюции и творческий абдуктивный контур; A/B‑тесты стратегий персонализации (доза/сложность/форматы/примеры); тюнинг правил E2.1.6.

Модуль E2.2.3. Аналитика показателей развития — атрибуция вклада Методов/материалов/персонализационных решений в метрики и Reward; отчёты и предложения для E2.1.2/E2.1.6.

Блок 2.3 — Память и Узкие ИИ‑агенты

Модуль E2.3.1. Операционное ведение общей памяти, CDH и Мостов контекстов — нормализация/индексация Эпистем, Work/DRR/Метрик; хранение/версионирование CDH; построение Мостов (CL) и контроль TTL.

Модуль E2.3.2. Конструктор Узких ИИ‑агентов и Сервисов — онбординг/настройка Узких ИИ‑агентов (методист, навигатор, оценщик, мотиватор, консультант и др.); маршрутизация по Capability; права доступа к CDH/Библиотеке; связь с приёмкой (E2.2.1).

Модуль E2.3.3. Синхронизация локальных памятей Узких ИИ‑агентов — двусторонний синк Локальных памятей с Общей памятью; разрешение конфликтов/версий; соблюдение TTL, приватности CDH и согласованности UTS.

Что такое модуль (в этой архитектуре)

Модуль — это минимальная единица ответственности и изменения в Мозге ИИ‑Проводника. Формально: это System‑in‑Role, который исполняет Метод над Эпистемами и/или Сервисами, в заданном Контексте, с чётким интерфейсом, измерениями и петлёй обучения.

Формула: Модуль = {Назначение → Роли («Зелёные ворота») → Контекст → Метод → Входы/Выходы → Интерфейсы/Сервисы → Память → Метрики (CSLC) → Связки с Assurance/Reward → DRR/Эволюция}.

⁠

Роль модуля в Мозге ИИ‑Проводника

В Ядре модуль задаёт правила и инварианты: миссию, Контексты (Bounded Context), Архитектуру общей памяти ИИ‑агента, Доверие и доказательства (Assurance), Награду Мозга (Reward), Роли и «Зелёные ворота», измеримость (CSLC), интерфейсы и сервисные контракты.

В Эво модуль действует и учится: воспринимает, планирует через «бутылочное горлышко», исполняет и учитывает Факт работы (Work), собирает Показатели развития, проводит приёмку сервисов (по Work), рефлексирует и обновляет себя через DRR.

⁠

Мини‑структура модуля (MVP содержание)

Назначение и связь с миссией — какую часть траектории (Ученик → Интеллектуал → Профессионал → Исследователь) и каких целей поддерживает.

Роли и «Зелёные ворота» (RSG) — кто и в каком состоянии может запускать модуль.

Контекст (Bounded Context) и Мосты контекстов (Bridge/CL) — где действует смысл, с какими потерями переносим.

Метод (SOP‑5) — Trigger → Decide → Act → Record → Feedback.

Входы/Выходы — что берём (Эпистемы, WorkPlan, Показатели), что отдаём (Work, Рабочие продукты, Метрики, DRR).

Интерфейсы/Сервисы — что модуль умеет (Capability), какие внешние/человеческие/агентные Сервисы использует (SLO/SLA) и как принимаем их по Work.

Память — что кладём в Общую память ИИ‑агента и, при необходимости, в Локальную память Узкого ИИ‑агента; привязка к UTS.

Метрики (CSLC) — 2–5 ключевых Показателей развития (окна: день/неделя/месяц).

Assurance ↔ Reward — минимум источников/уровней F–G–R и какие метрики идут в Награду Мозга.

DRR/Эволюция — что записываем при изменениях и как модуль себя улучшает.

⁠

Жизненный цикл работы модуля (одно прохождение)

Trigger (событие/условие из Контекста).

Проверка «Зелёных ворот» (допуски RSG/согласие человека).

RAG‑доступ к памяти (Общая память ИИ‑агента, UTS, релевантные Work/Эпистемы).

Решение (правило/эвристика; если нужно — запрос к человеку/Сервису).

Действие (исполнение Метода; если внешнее — сервисный вызов).

Фиксация (Факт работы (Work), Рабочий продукт, DRR).

Измерение (обновление Показателей развития).

Обратная связь (Assurance/Reward; возможная корректировка политики).

Эволюция (по DRR — уточнение метода/порогов/интерфейсов).

⁠

Почему именно модульное описание — лучший способ описать ИИ‑Проводника

Аудит и доверие. Разведение План работ (WorkPlan) и Факт работы (Work), обязательные ссылки на Эпистемы/источники (Assurance) — исключают «магические» решения и галлюцинации.

Управляемая эволюция. Каждый модуль — самостоятельная единица улучшения (DRR): можно менять тактики, не ломая остальное.

Композиция и масштабирование. Появился новый Узкий ИИ‑агент или метод — подключаем через Сервис и принимаем по Work без переписывания ядра.

Согласованность смысла. Контексты и UTS предотвращают «разъезд» терминов и ошибок переноса.

Совместимость с ограничениями LLM. Модуль локализует контекст → меньше токенов, чёткие форматы, must‑cite, детерминизм там, где нужен.

Ценность против прокси. Assurance (правда) отделён от Reward (полезность), а Анти‑Goodhart защищает от «гонки метрик» без результата.

Встроенная теория ограничений. Планирование через «бутылочное горлышко» в Эво заставляет выбирать минимальные интервенции с максимальным вкладом в миссию.

Единая память. Общая память ИИ‑агента + синхронизация с Локальными памятями Узких ИИ‑агентов исключают «знаниевые карманы» и расхождения.

⁠

Что модуль не является

Не «папка с данными» и не «кусок кода».

Не «чёрный ящик без измерений».

Не «сервис‑обещание» без проверяемого Work.

⁠

Итог в одном предложении

Модуль — это «рабочий орган» Мозга ИИ‑Проводника: ограниченный Контекстом и Ролями, исполняющий явный Метод, говорящий через понятные интерфейсы и метрики, проверяемый по Факту работы, и способный самообучаться без потери целостности всей системы.

Шаблон описания каждого модуля

Ниже — упрощённый MVP‑шаблон модуля (1 страница текста + мини‑скелеты данных). Единая терминология: ИИ‑Проводник, Мозг, Узкий ИИ‑агент, Общая память ИИ‑агента, Локальная память Узкого ИИ‑агента, Эпистема, UTS, Контекст (Bounded Context), Мост контекстов (Bridge/CL), Роль, Ролевое состояние (RSG), «Зелёные ворота», Метод, Описание метода, План работ (WorkPlan), Факт работы (Work), Рабочий продукт, Показатели развития, CSLC, Журнал причин решений (DRR), Награда Мозга (Reward).

⁠

🧩 MVP‑шаблон модуля (одна страница)

1) Паспорт

Блок / Модуль: Блок <N.N> · <C|E><N.N.N>

Название: <краткое глагольное> (напр. «Планировщик ограничений»)

Статус/Версия/Владелец: active · v0.1.0 · <роль/контакт>

2) Назначение и связь с миссией (2–3 строки) Как модуль помогает вести человека по траектории ролей и создавать успешные системы.

3) «Зелёные ворота» (RSG‑допуск) Роли и условия запуска (напр. Оператор:Ready, Человек:Согласие=Да).

4) Входы → Выходы (списком, без деталей формата)

Входы: Эпистемы/UTS/Контексты, Планы (WorkPlan), Показатели, Сервисы.

Выходы: Новые Эпистемы/Планы/Рабочие продукты/Факты работы (Work)/DRR/Метрики.

5) Метод (SOP‑5)

Trigger (что запускает) → 2) Decide (правило выбора) →

Act (шаг(и) действия) → 4) Record (что логируем: Work/DRR/Metric) →

Feedback (куда уходят сигналы: Assurance/Reward/другие модули).

6) Интерфейсы и сервисы (MVP)

Сервисы (внешние/человеческие/агентные): <название> · SLO: <критерий> · Приёмка: «по Work».

Узкие ИИ‑агенты: <кто> · Capability: <что умеет> · Владение данными: общая/локальная память.

7) Метрики модуля (CSLC‑минимум) Укажите 2–5 метрик, например: Систематичность, Инвестированное время, Выпуск рабочих продуктов, Прогресс по ролям. Для каждой: Characteristic / Scale / Window (day|week|month), Цель.

8) Обеспечение качества (MVP)

Assurance: минимальные источники, целевой F–G–R (кратко).

Reward: какие метрики модуля идут в Награду Мозга.

LLM‑политика: temperature=0–0.2, max_new_tokens≈400, must_cite=true, RAG=Общая память/UTS/последние Work.

Приватность: PII‑redaction=on.

9) Ошибки и откаты (минимум) Если низкий Assurance → запросить уточнение/отложить. Если сервис не дал Work → повтор через <интервал> или альтернативный маршрут.

10) «Готово к запуску» (DoD‑чек‑лист)

Есть SOP‑5; описаны входы/выходы; 2–5 метрик; 1–2 сервиса с приёмкой по Work;

Заполнены LLM‑параметры; прописан RSG‑допуск; определены журналы (Work/DRR/Metric).

⁠

💾 Мини‑скелеты данных (MVP)

A) План работ (WorkPlan) — mini‑JSON

B) Факт работы (Work) — mini‑JSON

C) DRR (журнал причин решений) — mini‑JSON

D) Метрика (CSLC) — mini‑JSON

E) LLM‑политика (per‑module) — mini‑YAML

⁠

🧠 Памятка по заполнению (MVP)

Пишите максимум на 1 страницу на модуль (без приложений).

Всегда разводите План (WorkPlan) и Факт (Work).

Приёмка сервисов — только по Work.

В Assurance укажите хотя бы один источник и целевой порог R.

В Reward перечислите 2–3 метрики модуля, влияющие на Награду Мозга.

LLM: включайте RAG и минимальные параметры генерации; при сомнении — отвечайте «недостаточно данных» и фиксируйте DRR.

Этот MVP‑шаблон позволяет быстро описать любой модуль структуры и сразу запустить ИИ‑Проводника в базовом режиме с логированием, метриками и самообучающей петлёй.

Узкие ИИ-агенты

Узкие ИИ-агенты

⁠

Полное описание Мозга

Основная терминология

Базовые сущности

Знание, контекст и термины

Эпистема — единица знания (понятие, теория, правило, модель) в памяти; имеет источники, версию и TTL.

Единый терминологический слой (UTS) — глоссарий/таблицы соответствий терминов с карточками и статусами.

Контекст (Bounded Context) — локальная рамка смысла с инвариантами.

Роли и процессы

Роль — контекстная функция участника (в т.ч. Человек:Поставщик сервиса).

Ролевое состояние (RSG) — жизненный цикл роли (Prepared/Ready/…).

«Зелёные ворота» — допуск к шагу Метода только при требуемом состоянии роли.

Работа и измерения

Метод / Описание метода — абстрактный способ действия / его спецификация.

Факт работы (Work) — протокол реально выполненных действий с тайм‑штампами и привязкой к Методу/Плану.

Рабочий продукт — наблюдаемый артефакт результата.

Показатели развития — измеримые характеристики прогресса.

Доверие, награда и эволюция

Петля эволюции — цикл Run → Observe → Refine → Deploy (запуск, наблюдение, уточнение, развёртывание изменений).

Творческий абдуктивный контур — генерация гипотез; отбор через NQD и политика Explore↔Exploit.

Планировщик ограничений — механизм “Теории ограничений“ Голдратта: выбор узкого места и минимального набора интервенций.

Сервисы и контракты

Способность (Capability) — потенциальная возможность исполнения (набор приёмов/ресурсов).

Сервис — внешнее обещание результата (в т. ч. «человеческий» сервис).

SLO/SLA — критерии качества сервиса (SLO) и соглашение об уровне сервиса (SLA).

Приёмка сервиса — решение по факту наблюдаемой работы (только по Work, не по обещанию).

Service Acceptance Binding — принцип: оценка сервиса по соответствию SLO на основе фактов Work в заданном окне времени.

Перенос смысла, свежесть и прокси

Proxy‑метрика — косвенная метрика, которая может стать целью вместо реального результата.

Goodhart (Закон Гудхарта) — «когда метрика становится целью, она перестаёт быть хорошей метрикой».

Политики LLM и данные

RAG — извлечение фактов из Общей памяти/UTS/Work/CDH/Библиотеки перед генерацией; must‑cite.

PII‑redaction — защита персональных данных.

Cool‑down — пауза между инициативными запросами к человеку.

⁠

Управление решениями и документирование

План‑факт — сопоставление планируемого (WorkPlan) и фактического (Work) исполнения за окно (день/неделя/месяц).

Структура описания каждого модуля по унифицированному MVP‑шаблону.

Для каждого модуля использован один и тот же компактный формат:

Назначение. Как модуль вносит вклад в миссию и PTR.

Роли и «Зелёные ворота». Кто запускает и при каких условиях (в т.ч. готовность по CDH/согласие).

Контекст и Мосты. Где действует смысл; нужны ли Bridges и учёт CL.

Метод (SOP‑5, коротко). T/D/A/R/F = Trigger/Decide/Act/Record/Feedback в одну строку.

Входы → Выходы. Основные источники и создаваемые артефакты.

Интерфейсы и Сервисы. API, внешние/человеческие сервисы, приёмка по Work.

Память. Что и где хранится (Общая память, CDH, UTS и др.).

Метрики (CSLC). 2–4 ключевые, с окном.

Assurance ↔ Reward. Что подтверждаем и как влияет на Reward (в т.ч. PFI).

DRR/Эволюция. Когда и что фиксируем/как модуль улучшает себя.

⁠

I. ЯДРО (Core)

Блок 1.1 — Миссия

Модуль C1.1.1. Цели и намерение

Назначение. Формулирует миссию, Траекторию развития и принципы персонализации (PTR): допустимые диапазоны дозы/сложности/форматов.

Роли и «Зелёные ворота». Стратег=Ready; Человек:Согласие=Да.

Контекст и Мосты. Базовый; перенос в новый домен через Bridge с CL‑оценкой.

SOP‑5. T: инициализация/ревизия целей. D: сопоставить цели с CDH/приоритетами. A: зафиксировать миссию/цели/ограничители PTR. R: эпистемы «Миссия/Цели». F: опубликовать карту целей модулям планирования.

Входы → Выходы. Предпочтения и ограничения пользователя → Эпистемы миссии, матрица целей.

Интерфейсы и Сервисы. —

Память. Общая память: раздел «Миссия» с TTL/версиями.

Метрики. Ясность целей (месяц); Согласованность планов с миссией (неделя).

Assurance ↔ Reward. F1, R≥0.70; рост согласованности повышает Reward.

DRR/Эволюция. DRR при изменении целей; квартальная ревизия.

Модуль C1.1.2. Самоописание ИИ‑Проводника

Назначение. Устанавливает «кто мы»: зона ответственности/не‑цели, аудитории, условия применения, требования к согласиям/данным CDH.

Роли и «Зелёные ворота». Архитектор=Ready.

Контекст и Мосты. Базовый; корпоративный/академический — через Bridge.

SOP‑5. T: инициализация/изменение окружения. D: проверка обязательных полей. A: публиковать Self‑Spec. R: эпистема «Самоописание». F: уведомить потребителей.

Входы → Выходы. Миссия/ограничения → Self‑Spec, список не‑целей.

Интерфейсы и Сервисы. Read‑only экспорт.

Память. Общая память: раздел «Self‑Spec».

Метрики. Полнота Self‑Spec (квартал); Конфликты терминов=0 (месяц).

Assurance ↔ Reward. Ссылки на UTS; меньше конфликтов → выше эффективность (косвенно Reward).

DRR/Эволюция. DRR на каждое изменение периметра.

Модуль C1.1.3. Архитектура ИИ‑Проводника

Назначение. Фиксирует состав (Мозг + Узкие ИИ‑агенты), шину знаний, роли CDH и Библиотеки в планировании/исполнении/аналитике.

Роли и «Зелёные ворота». Архитектор=Ready.

Контекст и Мосты. Базовый; интеграции/API описываются отдельными Bridges.

SOP‑5. T: добавление/изменение подсистем. D: топология/зависимости. A: публикация схемы. R: артефакт архитектуры. F: валидация SLO/SLA у потребителей.

Входы → Выходы. Реестр агентов/сервисов → Карта интерфейсов.

Интерфейсы и Сервисы. Реестр интерфейсов/SLO.

Память. Общая память: «Архитектура».

Метрики. Покрытие функций (%) (квартал); Неиспользуемые связи (месяц).

Assurance ↔ Reward. Согласованность с UTS/контекстами; ниже латентность → выше вклад в Reward.

DRR/Эволюция. DRR при каждой смене связи/агента.

Блок 1.2 — Знаниевая инфраструктура

Модуль C1.2.1. Контексты и Мосты

Назначение. Управляет Bounded Contexts и Bridges; измеряет CL; снижает смысловые потери.

Роли и «Зелёные ворота». Методолог=Ready.

Контекст и Мосты. Формирует и публикует.

SOP‑5. T: новый домен/конфликт терминов. D: анализ пересечений. A: создать/обновить Контекст/Bridge. R: эпистемы «Контекст/Bridge». F: оповестить зависимые модули.

Входы → Выходы. UTS, заявки модулей → Описания контекстов/Bridges с CL.

Интерфейсы и Сервисы. —

Память. Карта контекстов в Общей памяти.

Метрики. Конфликты терминов/мес; Средний CL при переносе.

Assurance ↔ Reward. F2, R≥0.80; ниже CL → меньше ошибок → выше Reward.

DRR/Эволюция. DRR при вводе/изменении контекста.

Модуль C1.2.2. Целевые объекты воздействия

Назначение. Модель: человек, проекты/системы, окружение, Экзокортекс, Роли/Ступени; связи с CDH.

Роли и «Зелёные ворота». Методолог=Ready.

Контекст и Мосты. «Инженер личности»; профили орг./личн. — через Bridge.

SOP‑5. T: онбординг/обновление профиля. D: полнота/согласованность. A: актуализировать модель. R: эпистемы объектов. F: открыть доступ планированию.

Входы → Выходы. Анкета/наблюдения → Объектная модель.

Интерфейсы и Сервисы. Read‑API для планировщика.

Память. Общая память; ссылки на CDH.

Метрики. Полнота профиля; Согласованность с UTS.

Assurance ↔ Reward. Источники/Work; точнее таргет → косвенно Reward.

DRR/Эволюция. DRR при изменении схемы/полей.

Модуль C1.2.3. Общая память ИИ‑агента

Назначение. Шина знаний: Эпистемы, Work/WorkPlan/DRR/Метрики, UTS, CDH, индексы Библиотеки; доступ/версии/TTL; синхронизация с Локальными памятями Узких ИИ‑агентов.

Роли и «Зелёные ворота». Хранитель памяти=Ready.

Контекст и Мосты. Память + Bridges к доменным хранилищам.

SOP‑5. T: новое знание/агент. D: политика владения/доступа. A: нормализация/индексация. R: версии/индексы. F: публикация TTL.

Входы → Выходы. Эпистемы/Work/UTS → Нормализованные записи/индексы.

Интерфейсы и Сервисы. API шины знаний; RAG‑эндпоинт.

Память. Собственно Общая память.

Метрики. Время извлечения; Доля устаревших записей.

Assurance ↔ Reward. Полные источники/версии; быстрее RAG → выше Reward.

DRR/Эволюция. DRR на изменение схем/TTL.

Модуль C1.2.4. UTS (Единый терминологический слой)

Назначение. Однозначность терминов и соответствий; карточки терминов.

Роли и «Зелёные ворота». Терминолог=Ready.

Контекст и Мосты. UTS; внешние словари — через Bridges.

SOP‑5. T: новый термин/конфликт. D: поиск в UTS. A: создать/править карточку. R: версия. F: оповестить потребителей.

Входы → Выходы. Заявки модулей → Карточки UTS.

Интерфейсы и Сервисы. Read‑only публикация.

Память. Секция UTS в Общей памяти.

Метрики. Конфликты терминов/мес; Время согласования.

Assurance ↔ Reward. Ссылки на источники; меньше конфликтов → выше эффективность.

DRR/Эволюция. История правок.

Модуль C1.2.5. Архитектура CDH

Назначение. Схема и источники данных CDH; приватность/TTL; API симуляций what‑if для планировщика/персонализации.

Роли и «Зелёные ворота». Хранитель памяти=Ready; Омбудсмен=Ready для приватности.

Контекст и Мосты. Память; интеграции сенсоров — через Bridges.

SOP‑5. T: новый источник/поле. D: оценка польза/риск. A: обновить схему/политику. R: версия/политики. F: уведомление модулей.

Входы → Выходы. Work/опросы/интеграции → Обновлённая схема/эндпоинты.

Интерфейсы и Сервисы. CDH‑API (read/write), what‑if.

Память. Раздел CDH (версии/политики).

Метрики. Покрытие полей CDH; Compl./PII‑инциденты=0.

Assurance ↔ Reward. Достоверность источников CDH ↑ → точнее PTR → Reward.

DRR/Эволюция. DRR на изменения полей/политик.

Модуль C1.2.6. Библиотека материалов и учебных траекторий

Назначение. Курирование контента (курсы/методички/мета‑мета‑модели/проблемы ЦА) с разметкой по ролям/ступеням/сложности/нагрузке; связи с Каталогом методов.

Роли и «Зелёные ворота». Куратор контента=Ready.

Контекст и Мосты. Библиотека; внешние источники — через Bridges (CL/Assurance).

SOP‑5. T: поступление/исчерпание материала. D: оценка качества/уровня. A: индексация/вязка к методам. R: карточка ресурса. F: публикация обновлений.

Входы → Выходы. Материалы/оценки → Индексированные записи/лейблы сложности.

Интерфейсы и Сервисы. Read API для персонализации.

Память. Индекс Библиотеки в Общей памяти.

Метрики. Покрытие ролей/ступеней; Доля материалов с уровнем сложности.

Assurance ↔ Reward. Источники/FG‑метки; релевантность ↑ → PFI ↑ → Reward.

DRR/Эволюция. Правила отбора/устаревания.

Блок 1.3 — Оценка и ограничения

Модуль C1.3.1. Assurance (Доверие и доказательства)

Назначение. Обоснованность выводов: Evidence Anchoring, F–G–R, свежесть, CL.

Роли и «Зелёные ворота». Аналитик качества=Ready.

Контекст и Мосты. Везде; переиспользование доказательств через Bridges.

SOP‑5. T: любой совет/решение. D: хватает ли evidence. A: присвоить F–G–R/CL. R: запись Assurance. F: метка уверенности потребителям.

Входы → Выходы. Эпистемы/Work → Оценки F–G–R/CL.

Интерфейсы и Сервисы. —

Память. Журнал Assurance.

Метрики. Доля рекомендаций с F–G–R; Средний R.

Assurance ↔ Reward. Низкий R снижает вес вклада; разделение правды/полезности.

DRR/Эволюция. Пороги F/G/R и правила старения.

Модуль C1.3.2. Reward/Value (Награда Мозга)

Назначение. Внутренний сигнал полезности; агрегирует метрики и PFI; управляет Explore↔Exploit; Proxy‑Audit.

Роли и «Зелёные ворота». Куратор награды=Ready.

Контекст и Мосты. Базовый.

SOP‑5. T: поступили метрики. D: агрегирование/веса. A: расчёт Reward. R: Reward‑tick. F: сигналы политикам/планировщику.

Входы → Выходы. Метрики/Assurance → Текущее Reward/сигналы E/E.

Интерфейсы и Сервисы. Reward‑API.

Память. История Reward.

Метрики. Стабильность Reward; Доля прокси‑срабатываний.

Assurance ↔ Reward. Вес метрик снижается при низком R.

DRR/Эволюция. Изменение весов/порогов — через DRR.

Модуль C1.3.3. Нормы и guard‑rails

Назначение. Этика/приватность (CDH/материалы), Lexical Firewall, Notational Independence, Unidirectional Dependency, Bias‑Audit; правила fair‑персонализации и лимиты дозирования.

Роли и «Зелёные ворота». Омбудсмен=Ready.

Контекст и Мосты. Везде.

SOP‑5. T: новый риск/сценарий. D: сопоставить с нормами. A: разрешить/запретить/поставить лимиты. R: политика. F: уведомление модулей.

Входы → Выходы. Кейсы/риски → Политики/ограничения.

Интерфейсы и Сервисы. —

Память. Реестр норм.

Метрики. Нарушения=0; Время реакции.

Assurance ↔ Reward. Может блокировать действия; не смешивается с оценкой полезности.

DRR/Эволюция. История изменений политик.

Блок 1.4 — Границы, роли и измеримость

Модуль C1.4.1. RSG Gatekeeper

Назначение. Контроль ролей/состояний и допуск шагов Методов; проверка «готовности по CDH» (энергия/фокус/время).

Роли и «Зелёные ворота». Куратор ролей=Ready.

Контекст и Мосты. Везде.

SOP‑5. T: запрос действия. D: проверить RSG и CDH‑готовность. A: допустить/заблокировать. R: лог допуска. F: объяснение/рекомендация.

Входы → Выходы. Требования метода, CDH‑состояния → Решение допуска.

Интерфейсы и Сервисы. Gatekeeper‑API.

Память. Справочник ролей/RSG.

Метрики. Ошибки допуска; Среднее время проверки.

Assurance ↔ Reward. Корректный допуск снижает отказ/перегруз; косвенно Reward.

DRR/Эволюция. Настройка порогов готовности.

Модуль C1.4.2. Метрики и публикации

Назначение. Контракт CSLC, отчёты, агрегаты по CDH без PII; публикация PFI.

Роли и «Зелёные ворота». Куратор измерений=Ready.

Контекст и Мосты. Везде.

SOP‑5. T: выпуск отчёта/изменение метрик. D: валидация CSLC. A: публикация/архивирование. R: отчёт/сводка. F: уведомление.

Входы → Выходы. Метрики/Work → Отчёты/дашборды.

Интерфейсы и Сервисы. Экспорт отчётов/дашбордов.

Память. Архив метрик/DRR.

Метрики. Доля метрик с валидным CSLC=100%; Время выпуска отчёта.

Assurance ↔ Reward. Гарантирует корректную телеметрию.

DRR/Эволюция. Версионирование схем метрик.

Модуль C1.4.3. Интерфейсы и сервисные контракты

Назначение. Capability↔Service, SLO/SLA, приёмка по Work; контракты доступа к CDH/Библиотеке.

Роли и «Зелёные ворота». Контрактный управляющий=Ready.

Контекст и Мосты. Везде.

SOP‑5. T: новый/изменённый сервис. D: соответствие SLO и доступа. A: опубликовать контракт. R: версия. F: доступ модулям.

Входы → Выходы. Требования модулей → SLO/SLA/политики доступа.

Интерфейсы и Сервисы. Реестр сервисов.

Память. Каталог контрактов.

Метрики. Нарушения SLO; Время приёмки.

Assurance ↔ Reward. Принятые сервисы ↑ надёжность → Reward.

DRR/Эволюция. История контрактов.

Модуль C1.4.4. Политика взаимодействия и согласия

Назначение. Правила инициативных запросов: триггеры, каналы, cool‑down, согласия/отзыв.

Роли и «Зелёные ворота». Политик коммуникаций=Ready; Согласие=Да.

Контекст и Мосты. Везде.

SOP‑5. T: высокая ожидаемая выгода/узкое место. D: частота/канал/ограничители. A: отправить запрос. R: Work «коммуникация». F: обновить частоты по результатам.

Входы → Выходы. Сигналы планировщика/ограничения → Запросы/решения.

Интерфейсы и Сервисы. Каналы уведомлений; приём подтверждений.

Память. Журнал согласий/предпочтений.

Метрики. Доля принятых запросов; Вовлечённость.

Assurance ↔ Reward. Соблюдение этики — предикат; эффективность ↑ → Reward.

DRR/Эволюция. Тюнинг порогов/частот.

Модуль C1.4.5. Политика персонализации и дозирования

Назначение. Норматив PTR: правила изменения объёма/сложности/часов/примеров; предельные пороги; ручные оверрайды.

Роли и «Зелёные ворота». Политик персонализации=Ready; Омбудсмен=Ready для fairness.

Контекст и Мосты. Везде.

SOP‑5. T: обновление данных CDH/метрик. D: пересчитать пороги. A: применить политики. R: версия правил. F: сигнал персонализации.

Входы → Выходы. CDH/метрики/Assurance → Нормы PTR.

Интерфейсы и Сервисы. Политики доступны E2.1.2/E2.1.6.

Память. Раздел «PTR‑политики».

Метрики. PFI (неделя/месяц); Доля перегрузок/недогрузок.

Assurance ↔ Reward. PFI напрямую входит в Reward.

DRR/Эволюция. A/B порогов; журнал правок.

⁠

II. ЭВО (Evo)

Блок 2.1 — Внешние действия

Модуль E2.1.1. Восприятие и фокус

Назначение. Сбор наблюдений; обновление CDH (фокус, состояния, окна доступности); постановка фокуса на день/неделю/месяц.

Роли и «Зелёные ворота». Наблюдатель=Ready.

Контекст и Мосты. Базовый; источники — через Bridges.

SOP‑5. T: старт окна/событие. D: значимость/готовность (CDH). A: задать фокус. R: Work «фокус», заметки. F: сигнал Планировщику.

Входы → Выходы. Календарь/Экзокортекс/CDH → Фокус‑карта.

Интерфейсы и Сервисы. Доступ к источникам (read).

Память. Карта фокуса в Общей памяти.

Метрики. Своевременность обновления; Шум/сигнал.

Assurance ↔ Reward. Источники помечены; точный фокус ↑ план‑факт → Reward.

DRR/Эволюция. Тюнинг правил наведения.

Модуль E2.1.2. Планировщик ограничений

Назначение. Выбор «бутылочного горлышка»; симуляции what‑if на CDH; выпуск WorkPlan с адаптивным дозированием и ожидаемыми продуктами.

Роли и «Зелёные ворота». Стратег=Ready; Gatekeeper OK.

Контекст и Мосты. Контекст траектории; ресурсы — через Bridges.

SOP‑5. T: новая неделя/барьер. D: эффект/стоимость/готовность (CDH). A: выбрать методы/сервисы; собрать WorkPlan. R: WorkPlan. F: в Конвейер и Reward.

Входы → Выходы. Фокус/Целевые объекты/Методы/CDH → WorkPlan.

Интерфейсы и Сервисы. Запросы к сервисам через C1.4.3/4.4.

Память. История WorkPlan.

Метрики. Доля планов с явным ограничением; Покрытие план→факт.

Assurance ↔ Reward. Обоснование выбора (evidence) → выше вес; выполнение плана ↑ Reward.

DRR/Эволюция. Правила выбора/пороги.

Модуль E2.1.3. Каталог методов переходов

Назначение. Выдаёт методы/типовые вызовы по ролям/ступеням; связывает с Библиотекой (уровни сложности/нагрузка) и CDH.

Роли и «Зелёные ворота». Куратор методов=Ready.

Контекст и Мосты. Ролевой; доменные практики — через Bridges.

SOP‑5. T: запрос из планировщика/персонализации. D: релевантность роли/ступени/CDH. A: подбор методов/вызовов. R: ссылка в WorkPlan. F: обновить рейтинг по факту.

Входы → Выходы. Статусы ролей/рез‑ты методов → Подборки.

Интерфейсы и Сервисы. Read‑API.

Память. Каталог методов (версии/эффективность).

Метрики. Эффективность по роли; Частота использования.

Assurance ↔ Reward. Источники методик/результатов; лучшее → больший вес.

DRR/Эволюция. Добавление/деактивация методов.

Модуль E2.1.4. Конвейер работ и учёт времени

Назначение. Исполнение слотов (помидоро + перерывы), фиксация Work и продуктов; запись ключевых изменений в CDH; план‑факт.

Роли и «Зелёные ворота». Оператор=Ready; Человек:Согласие=Да; Gatekeeper OK.

Контекст и Мосты. Операционный.

SOP‑5. T: наступил слот. D: готовность/ресурсы. A: выполнить метод/задачу. R: Work/продукты. F: обновить метрики/PTR/CDH.

Входы → Выходы. WorkPlan/методы → Work/продукты/план‑факт.

Интерфейсы и Сервисы. Таймер/календарь/уведомления; сервисы выполнения.

Память. Журналы Work/продуктов.

Метрики. Систематичность; Инвестированное время; Выпуск продуктов.

Assurance ↔ Reward. Work — главный источник; прямой вклад в Reward.

DRR/Эволюция. Ритмы, длина перерывов.

Модуль E2.1.5. Сбор показателей развития

Назначение. Агрегирует метрики (систематичность, время, выпуск, продуктивное состояние, Экзокортекс, окружение, прогресс по Траектории, PFI); передаёт в Reward; обновляет CDH‑сводки.

Роли и «Зелёные ворота». Телеметрист=Ready.

Контекст и Мосты. Метрический.

SOP‑5. T: конец окна. D: валидация CSLC. A: расчёт/агрегация. R: записи метрик. F: в Reward/отчёты.

Входы → Выходы. Work/WorkPlan/продукты/опросы → Показатели.

Интерфейсы и Сервисы. Интеграция с трекерами.

Память. Хранилище метрик.

Метрики. Валидность CSLC=100%; Своевременность сводки.

Assurance ↔ Reward. Метки источников обязательны; PFI вносит вес в Reward.

DRR/Эволюция. Окна/формулы.

Модуль E2.1.6. Персонализация и дозирование (Recommendation & Sequencing)

Назначение. Подбор индивидуальных заданий/материалов (сложность/доза/формат/примеры) и их последовательности на основе CDH и Библиотеки; выдаёт спецификации в WorkPlan.

Роли и «Зелёные ворота». Персонализатор=Ready; Gatekeeper OK; этические лимиты C1.3.3.

Контекст и Мосты. Библиотека↔Роли/ступени; CDH.

SOP‑5. T: планирование/перепланирование. D: PFI‑прогноз/ограничители PTR. A: сформировать подбор/последовательность. R: запись «RecSpec». F: апдейт весов по факту.

Входы → Выходы. CDH/Каталог методов/Библиотека → RecSpec → WorkPlan.

Интерфейсы и Сервисы. Read‑API Библиотеки; SLO форматов.

Память. История рекомендаций и PFI.

Метрики. PFI (день/неделя); Completion‑rate заданий.

Assurance ↔ Reward. PFI напрямую в Reward; источники материалов помечены Assurance.

DRR/Эволюция. A/B правил дозирования.

Блок 2.2 — Внутренние действия

Модуль E2.2.1. Рефлексия и приёмка сервиса

Назначение. Ретроспектива по Work; приёмка сервисов (в т.ч. человеческих) по SLO; корректировка PTR/CDH.

Роли и «Зелёные ворота». Аудитор=Ready.

Контекст и Мосты. Везде.

SOP‑5. T: конец окна/завершение. D: соответствие SLO. A: принять/отклонить. R: акт приёмки. F: изменения планирования/политик.

Входы → Выходы. Work/SLO → Решения приёмки/замечания.

Интерфейсы и Сервисы. Канал обратной связи сервисам.

Память. Реестр приёмок.

Метрики. SLO‑соответствие; Доля отклонений.

Assurance ↔ Reward. Принятые сервисы повышают вес вклада в Reward.

DRR/Эволюция. Причины принятия/отказа.

Модуль E2.2.2. Самообучение и творчество

Назначение. Петля эволюции и творческий абдуктивный контур; A/B персонализации; тюнинг правил E2.1.6.

Роли и «Зелёные ворота». Исследователь=Ready.

Контекст и Мосты. Базовый.

SOP‑5. T: сигнал Reward/Assurance/ретро. D: выбрать гипотезы (NQD). A: запустить тест/изменение. R: DRR. F: внедрить/откатить.

Входы → Выходы. Метрики/Reward → Обновлённые параметры/политики.

Интерфейсы и Сервисы. —

Память. Журнал экспериментов (DRR).

Метрики. Доля успешных экспериментов; Impact на Reward/PFI.

Assurance ↔ Reward. Изменения учитывают оба сигнала.

DRR/Эволюция. DRR обязателен.

Модуль E2.2.3. Аналитика показателей

Назначение. Атрибуция вклада методов/материалов/персонализации; отчёты и рекомендации E2.1.2/E2.1.6.

Роли и «Зелёные ворота». Аналитик=Ready.

Контекст и Мосты. Метрический.

SOP‑5. T: поступили метрики. D: проверка CSLC. A: аналитика/атрибуция. R: отчёт. F: веса в Reward/предложения.

Входы → Выходы. Метрики/Work → Отчёты/веса.

Интерфейсы и Сервисы. Дашборды/экспорт.

Память. Архив аналитики.

Метрики. Время аналитики; Доля принятых рекомендаций.

Assurance ↔ Reward. Источники помечены; корректные веса → стабильнее Reward.

DRR/Эволюция. DRR на смену методик.

Блок 2.3 — Память и Узкие ИИ‑агенты

Модуль E2.3.1. Ведение памяти, CDH и Мостов

Назначение. Нормализация/индексация Эпистем/Work/DRR/Метрик; хранение/версионирование CDH; построение Bridges (CL); контроль TTL.

Роли и «Зелёные ворота». Хранитель памяти=Ready.

Контекст и Мосты. Все заявленные.

SOP‑5. T: новые данные/устаревание. D: нормализация/Bridge. A: обновить записи. R: версии/CL. F: оповещение зависимых модулей.

Входы → Выходы. Эпистемы/Work/UTS/CDH → Нормализованные записи/Bridges.

Интерфейсы и Сервисы. API шины знаний; RAG.

Память. Общая память; раздел CDH.

Метрики. Средний CL; Доля актуальных записей.

Assurance ↔ Reward. Полнота/свежесть ↑ точность RAG → косвенно Reward.

DRR/Эволюция. TTL/правила Bridge — через DRR.

Модуль E2.3.2. Конструктор Узких ИИ‑агентов и сервисов

Назначение. Онбординг/настройка Узких ИИ‑агентов; маршрутизация задач по Capability; права доступа к CDH/Библиотеке; связка с приёмкой (E2.2.1).

Роли и «Зелёные ворота». Оркестратор=Ready.

Контекст и Мосты. Базовый.

SOP‑5. T: потребность/ограничение. D: build/buy/config. A: подключить/настроить. R: контракт/SLO. F: мониторинг SLO.

Входы → Выходы. Требования E‑модулей → Зарегистрированные агенты/сервисы.

Интерфейсы и Сервисы. Управление SLO/SLA.

Память. Каталог агентов/сервисов.

Метрики. Время онбординга; Стабильность SLO.

Assurance ↔ Reward. Приёмка по Work усиливает вклад.

DRR/Эволюция. История решений build/buy.

Модуль E2.3.3. Синхронизация локальных памятей

Назначение. Двусторонний синк Локальных памятей Узких ИИ‑агентов с Общей памятью; разрешение конфликтов/версий; соблюдение TTL/приватности и UTS‑согласованности.

Роли и «Зелёные ворота». Инженер данных=Ready.

Контекст и Мосты. Память; доменные схемы — через Bridges.

SOP‑5. T: изменение локальной/общей памяти. D: стратегия merge. A: синхронизировать. R: журнал синка. F: отчёт о конфликтах.

Входы → Выходы. Дельты данных → Согласованные записи/версии.

Интерфейсы и Сервисы. Коннекторы к Узким ИИ‑агентам.

Память. Логи синхронизации/версий.

Метрики. Конфликты/синк; Время синхронизации.

Assurance ↔ Reward. Точный синк ↑ качество RAG → косвенно Reward.

DRR/Эволюция. Тюнинг merge/разрешения конфликтов.

Примечание

В каждом модуле подразумевается генерация с RAG (Общая память/UTS/Work/CDH/Библиотека) и маркировка доказательств (Assurance).

Приёмка сервисов — исключительно по Work и соответствию SLO (см. C1.4.3, E2.2.1).

PFI участвует в Reward и управляет политиками персонализации (C1.4.5, E2.1.6).

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.