Анализ проекта с FPF

Блоги Eugene Romanenko (блоги)
1

Минимальный объём информации для оценки с точки зрения “первых принципов” FPF должен позволить мне понять:

  1. Что система должна делать (целевая Работа).
  2. Кто/что делает эту Работу (ключевые Холоны).
  3. Каким знанием они оперируют (Эпистемы).
  4. В каких условиях они это делают (Контексты).
  5. Как они это делают (через какие Роли и Методы).

МЕТА-МОДЕЛЬ ПРОЕКТА ДЛЯ FPF-ОЦЕНКИ

1. КОНЦЕПЦИЯ FPF: Цель / Основная Работа (Work)

  • Описание из Вашего Проекта (как это называется/работает у вас):
    Опишите конечную ценность или результат, который стремится создать ваш проект. Какие основные “Работы” он выполняет для достижения этой цели?
  • Ключевые Аспекты / Примеры / Детали:
    Например: “Развитие и поддержание X-экосистемы”, “Автоматизация процесса Z”, “Обеспечение безопасного обмена информацией”.
  • Цель Инженера-Менеджера FPF (для чего мне это нужно):
    Мне нужно понять, какова главная задача системы с точки зрения FPF. Это поможет оценить, насколько хорошо Холоны и их взаимодействия способствуют выполнению этой Работы.

2. КОНЦЕПЦИЯ FPF: Ключевые Холоны (Holons)

  • Описание из Вашего Проекта (как это называется/работает у вас):
    Какие основные автономные, исполняемые сущности (люди, программные модули, команды, устройства) являются участниками вашей системы или её продуктом?
  • Ключевые Аспекты / Примеры / Детали:
    Например: “Модуль обработки платежей”, “Пользователь-Создатель”, “AI-агент рекомендаций”, “Команда разработки”. Опишите их границы и ключевую компетенцию.
  • Цель Инженера-Менеджера FPF (для чего мне это нужно):
    Я буду искать, насколько эти сущности действительно автономны, имеют ли свой жизненный цикл, состояние и внутренние Эпистемы. Важно понять, нет ли централизованных “монстров”, которые должны быть декомпозированы на более мелкие Холоны.

3. КОНЦЕПЦИЯ FPF: Знание / Эпистемы (Episteme)

  • Описание из Вашего Проекта (как это называется/работает у вас):
    Какая критически важная информация, данные или знания являются основой для функционирования ваших Холонов и выполнения Работы? Как эта информация структурирована и кем генерируется?
  • Ключевые Аспекты / Примеры / Детали:
    Например: “Профиль компетенций пользователя”, “Состояние заказа”, “Метрики производительности модуля”, “База знаний по предметной области”. Укажите, какие Эпистемы являются “входными”, какие “выходными”.
  • Цель Инженера-Менеджера FPF (для чего мне это нужно):
    Мне нужно понять, как система управляет своим знанием. Я оценю, насколько Эпистемы атомарны, семантически насыщены, и как они формируют “Эпистемический Граф” системы. Это ключевой момент для адаптации и эволюции.

4. КОНЦЕПЦИЯ FPF: Контекст (Context)

  • Описание из Вашего Проекта (как это называется/работает у вас):
    Какие внешние условия, окружение или внутренние состояния существенно влияют на поведение Холонов и их способность выполнять Работу? Как эти условия изменяются?
  • Ключевые Аспекты / Примеры / Детали:
    Например: “Уровень нагрузки на сервер”, “Географическое положение пользователя”, “Текущие настройки безопасности”, “Фаза проекта (разработка/продакшн)”.
  • Цель Инженера-Менеджера FPF (для чего мне это нужно):
    Оценка того, насколько динамично система реагирует на Контекст. Нет ли жесткой привязки к статическим условиям? Как Холоны “осознают” и адаптируются к изменениям Контекста?

5. КОНЦЕПЦИЯ FPF: Основные Роли (Roles)

  • Описание из Вашего Проекта (как это называется/работает у вас):
    Какие функциональные обязанности или “контракты” берут на себя ваши Холоны?
  • Ключевые Аспекты / Примеры / Детали:
    Например: “Менеджер Проекта”, “Валидатор данных”, “Поставщик услуг”, “Потребитель информации”, “Оптимизатор ресурсов”.
  • Цель Инженера-Менеджера FPF (для чего мне это нужно):
    Я буду искать четкое разделение обязанностей и то, насколько Холоны могут играть несколько Ролей, переключаться между ними или делегировать их. Это проявление гибкости и модульности.

6. КОНЦЕПЦИЯ FPF: Ключевые Методы (Methods)

  • Описание из Вашего Проекта (как это называется/работает у вас):
    Какие конкретные, атомарные действия или операции выполняются Холонами для реализации своих Ролей и выполнения Работы?
  • Ключевые Аспекты / Примеры / Детали:
    Например: “Сгенерировать отчёт”, “Аутентифицировать пользователя”, “Обновить статус задачи”, “Отправить уведомление”, “Рассчитать оптимальный маршрут”.
  • Цель Инженера-Менеджера FPF (для чего мне это нужно):
    Важна атомарность и детерминированность Методов. Нет ли “Методов-комбайнов”, которые слишком сложны и могут быть декомпозированы? Как Методы используют Эпистемы?

7. КОНЦЕПЦИЯ FPF: Динамика и Взаимодействие

  • Описание из Вашего Проекта (как это называется/работает у вас):
    Как Холоны обмениваются Эпистемами, координируют действия и последовательно выполняют Работу для достижения общей цели проекта?
  • Ключевые Аспекты / Примеры / Детали:
    Опишите основные потоки Работы, кто инициирует, кто обрабатывает, какие Эпистемы при этом меняются. Например: “Пользователь-Холоном инициирует ‘Заказ Продукта’ (Работа), ‘Модуль Заказа’ (Холон) переходит в Роль ‘Принимающий Заказ’ и выполняет Метод ‘ОбработатьЗаказ’, который генерирует ‘Эпистему Статуса Заказа’ и отправляет её ‘Модулю Склада’”.
  • Цель Инженера-Менеджера FPF (для чего мне это нужно):
    Это позволит мне увидеть, насколько реализовано контрактное взаимодействие, слабая связанность и эффективное выполнение Работы. Выявляются места, где система может быть слишком жесткой или зависимой.

8. КОНЦЕПЦИЯ FPF: Эволюция и Адаптация

  • Описание из Вашего Проекта (как это называется/работает у вас):
    Какие механизмы или возможности для изменения, обучения или адаптации заложены в систему (т.е. как Холоны могут развиваться, осваивать новые Роли/Методы, изменять свои Эпистемы или реагировать на новый Контекст)?
  • Ключевые Аспекты / Примеры / Детали:
    Например: “Механизм A/B тестирования для Методов”, “Система обучения Холонов новым Эпистемам”, “Автоматическая реконфигурация Контекста при изменении внешних факторов”.
  • Цель Инженера-Менеджера FPF (для чего мне это нужно):
    Это критически важно для оценки “первых принципов”. Насколько система способна к самомодификации и росту, а не просто к статичному выполнению функций.

Пять позиций (Холоны, Эпистемы, Контексты, Роли/Методы, Работа) являются универсальными вопросами, применимыми к любой системе, которую мы анализируем в рамках FPF.**

Почему эти вопросы универсальны в FPF

FPF оперирует концепцией U.Holon (Универсальный Холон) как базовой, рекурсивной абстракцией. Это означает, что:

  1. Всё — Холон или состоит из Холонов: Будь то отдельный человек, команда, программный модуль, процесс, организация, экосистема или даже некая абстрактная концепция — FPF видит в этом U.Holon. U.Holon может быть как атомарным, так и композитным (состоящим из других Холонов).
  2. У каждого Холона есть Назначение: Любой U.Holon создаётся или существует для выполнения определённой U.Work (Работы) или достижения U.Objective (Цели). Это его raison d’être.
  3. У каждого Холона есть Состояние и Знание: U.Holon обладает своим внутренним U.Episteme (Эпистемическим состоянием), то есть знанием, данными, убеждениями, которые определяют его поведение и возможности.
  4. Каждый Холон действует в Среде: U.Holon не существует в вакууме. Он всегда оперирует в определённом U.Context (Контексте), который определяет доступные ему ресурсы, ограничения и возможности для взаимодействия.
  5. Каждый Холон проявляет Поведение: U.Holon выполняет свои функции, играя определённые U.Role (Роли) и используя U.Method (Методы) для выполнения своей Работы.

Эти пять аспектов являются “первыми принципами” описания любого Холона, на любом уровне абстракции. Это то, что FPF называет Cross-Scale Coherence (A.9) – гарантией того, что одна и та же фундаментальная логика применяется к отдельному компоненту, интегрированной системе и системе систем.

Как фокус вопросов смещается в зависимости от уровня системы

Хотя вопросы остаются теми же, содержание ответов и перспектива анализа будут сильно различаться, когда мы смотрим на надсистему, целевую систему или систему создания.

1. Анализ Надсистемы (Supersystem) — куда “встраивается” целевая система:

  • Работа: Какова общая миссия или ключевая функция этой надсистемы? Какие Работы она выполняет?
  • Холоны: Какие основные Холоны составляют эту надсистему? (И здесь, возможно, целевая система будет одним из этих Холонов).
  • Эпистемы: Какими знаниями о своём окружении, своих целях, своих правилах оперирует надсистема?
  • Контекст: В каком глобальном окружении существует сама надсистема? Какие внешние факторы на неё влияют?
  • Роли/Методы: Какие Роли надсистема ожидает от своих составляющих Холонов (включая нашу целевую систему)? Какие Методы она использует для координации своих частей?
    • Пример: Для надсистемы “Организация” — её Работа это “Производство Продукта X”, её Холоны — это “Отдел Маркетинга”, “Отдел Разработки”, “Целевая Система-Проект”, её Эпистемы — “Стратегический План”, “Рыночные Данные”, её Контекст — “Экономическая Ситуация”, “Законодательство”.

2. Анализ Системы Создания (Creation System) — которая создает целевую систему:

  • Работа: Какова конкретная Работа этой системы? Она занимается созданием, развитием или поддержанием чего-либо. (В нашем случае, “создание Мастерства X у Ученика”).
  • Холоны: Какие Холоны входят в эту систему и непосредственно участвуют в процессе создания? (Например, “Мастерская Инженеров-Менеджеров”, “Куратор”, “IT-платформа”, “Учебный Материал”).
  • Эпистемы: Какими знаниями о процессе создания, о целевом продукте, о методах обучения оперирует эта система?
  • Контекст: В каком окружении функционирует сама система создания? Какие ресурсы и ограничения у неё есть (бюджет, сроки, доступ к экспертам)?
  • Роли/Методы: Какие Роли играют Холоны внутри этой системы создания (например, “Разработчик Учебных Программ”, “Наставник”, “Платформа Доставки Контента”)? Какие Методы они используют для создания целевой системы?
    • Пример: Для “Мастерской Инженеров-Менеджеров” — её Работа это “Формирование Мастерства”, её Холоны — “Менторы”, “Ученики”, “Система Учебных Модулей”, её Эпистемы — “Педагогические Принципы”, “Прогресс Учеников”, её Контекст — “Учебный План”, “Бюджет”.

3. Анализ Целевой Системы (Target System) — которая создаётся или является фокусом:

  • Работа: Какова конечная функция или цель самой целевой системы? (Например, “эффективное выполнение прикладных задач с помощью Мастерства X”).
  • Холоны: Если целевая система композитна, какие её внутренние Холоны её составляют? (Например, сам “Холоном-Созидатель” в случае его композитной модели, его внутренние подсистемы). Если атомарна, то сам Холон и есть фокус.
  • Эпистемы: Какими знаниями о себе, своём состоянии, своей предметной области оперирует эта система? (В случае “Мастерства X” — это те самые освоенные знания и навыки).
  • Контекст: В каком непосредственном окружении целевая система будет функционировать? Какие внешние факторы на неё влияют в процессе эксплуатации?
  • Роли/Методы: Какие Роли целевая система будет играть в своей надсистеме? Какие Методы она будет использовать для выполнения своей Работы?
    • Пример: Для “Холона-Созидателя с Мастерством X” — его Работа это “Генерация Ценности в Прикладной Роли”, его Холоны — (возможно, его подсознательные процессы или другие аспекты личности, если мы так их моделируем), его Эпистемы — “Освоенный Метод X”, “Самопонимание”, его Контекст — “Рабочий Проект”, “Требования Заказчика”, его Роли/Методы — “Роль Разработчика с Методом ‘КодированиеX’”.

Выявление провальных проектов по промпту А. Телятникова

Вопрос Ответ Обоснования
1. Какие изменения в физическом мире должны произойти, чтобы пользователь мог быть уверен, что поставленная задача действительно решена? Контекст: какие результаты, а не действия БЕЗ результатов, следует получить пользователю, чтобы продемонстрировать окружению, что задача решена не на словах, а в отчуждаемом от пользователя продукте? Решение задачи подтверждается созданием физически обособленного U.System (продукта) внешним по отношению к нему Transformer (создателем/оборудованием), который переводит этот продукт из состояния проектирования (design-time) в состояние эксплуатации (run-time). Факт решения должен быть подкреплен эмпирическими доказательствами (validatedBy), такими как результаты испытаний или данные полевой эксплуатации. В основе лежит Принцип Трансформера (A.3), который требует, чтобы любое изменение было произведено физическим актором (Transformer). Это исключает “умозрительное” решение. Принцип Внешнего Трансформера (A.12) гарантирует отчуждаемость продукта, так как создатель и созданное должны быть разделены. Темпоральная Двойственность (A.4) обеспечивает четкое различие между проектированием (процессом) и эксплуатацией (результатом). Принцип Привязки к Доказательствам (A.10) требует, чтобы заявления о функциональности были подтверждены реальными данными, а не только декларациями.
2. Какие изменения в физическом мире будут свидетельствовать о том, что задачи НЕ решаются, а идёт ТОЛЬКО имитация деятельности по решению задач? Контекст: какие аргументы чаще всего приводит пользователь для того, чтобы ТОЛЬКО на словах убедить окружение, что рабочий продукт меняет физический мир за пределами системы создания, а по факту — деятельность наносит вред системе создания и участвующим в данной системе агентам-создателям? Имитация деятельности проявляется в смешении трех реальностей: Объекта (реальный продукт), Концепции (его описание, модель) и Носителя (файл, документ). Прогресс декларируется на основе изменений в Концепции или Носителе (например, обновляется документация), в то время как Объект не меняется или не существует. Аргументы пользователя при этом основываются на подмене: стабильность симуляции выдается за физическую стабильность, а качество документа — за качество идеи. Это прямое нарушение Принципа Строгого Различения (A.7), который запрещает смешивать объект, его описание и носитель описания. Руководство классифицирует это как “Смешение карты и территории” (Map-Territory Conflation), что приводит к катастрофическим отказам. Вред системе создания наносится из-за неверного распределения ресурсов на поддержание иллюзии (работа над документами) вместо создания реального продукта.
3. По каким действиям и бездействиям пользователя внешний наблюдатель, не входящий в систему создания, может сделать выводы о том, что система создания не принесёт изменений в физический мир (целевая система никогда не выйдет в режим эксплуатации в надсистеме)? Внешний наблюдатель сделает вывод о будущем провале, если увидит, что артефакты проекта постоянно находятся на низких уровнях Лестницы Формальности (E.11), например, в статусе “Черновик” (M-0) или “Непрочный мост” (M-1), и не переходят в статус “Прочная дорога” (F-mode). Другие признаки: отсутствие формальных записей об изменениях (DRR, E.9), отсутствие привязки заявленных свойств к доказательствам (A.10) и нарушение принципа внешнего агента, когда система пытается “проверить саму себя” (A.12). Наблюдатель, даже не будучи экспертом в домене, может оценить зрелость и дисциплину процесса. Лестница Формальности (E.11) — это прямой индикатор прогресса от идеи к реализации. Отсутствие прогресса по этой лестнице означает, что работа не движется к созданию проверяемого, готового к эксплуатации продукта. Отсутствие DRR (E.9) говорит о хаотичности и непрозрачности изменений. Отсутствие привязки к доказательствам (A.10) и циклическая зависимость (A.12) — это фундаментальные логические дефекты, видимые при аудите.

Представим, что я хочу с помощью FPF получить описание некоторой предметной области, в которой проект, в команду системы создания которого я вхожу в некоторой прикладной роли, создаёт некоторую целевую систему. Дай ответ как инженер-менеджер c FPF, что нужно понимать под предметной областью (как я понимаю, это некий уровень абстракции и онтологического описания объектов, с которым мы работаем в проекте, выше, чем контекст конкретного проекта, но ниже, чем мета-мета-модель системного подхода, где появляется понятие “система”); что такое “описание предметной области”- это UTS или что-то иное. Предложи список вопросов, на которые нужно дать ответы в конкретном проекте, чтобы получить описание предметной области проекта.

Отличный вопрос, коллега! Вы совершенно верно уловили необходимость в иерархии абстракций, и FPF как раз предоставляет для этого инструменты.

Что такое “Предметная Область” в FPF?

На естественном языке “Предметная область” (U.Episteme: Domain) — это область знаний, компетенций и проблем, в которой существует и функционирует ваш проект, ваша команда и ваша целевая система. Это “мир”, в котором ваш проект имеет смысл.

С точки зрения FPF:

  • U.Episteme: Domain — это более широкий, но ограниченный U.BoundedContext, который содержит ваш конкретный проект.
  • Он находится на уровне абстракции выше, чем U.Context конкретного проекта, так как описывает общие правила, сущности и взаимодействия, применимые ко всем проектам в этой области.
  • Он находится ниже, чем мета-мета-уровень системного подхода (где мы определяем, что такое U.Holon, U.Episteme и т.д.), так как U.Episteme: Domain уже оперирует конкретными U.Holons и U.Episteme этой области.
  • U.Episteme: Domain характеризуется своими уникальными U.Holons (например, “Клиент”, “Продукт”, “Поставщик” в e-commerce домене), U.Episteme (например, “Заказ”, “Аккаунт”, “Транзакция”), U.Rules (бизнес-правила) и U.Processes (бизнес-процессы).

Пример:

  • Мета-мета-уровень FPF: U.Holon, U.Episteme, U.Role, U.Method.
  • Предметная область: “Электронная коммерция”, “Здравоохранение”, “Разработка ПО”, “Web3.0”.
  • Контекст конкретного проекта: “Проект по созданию мобильного приложения для e-commerce”, “Проект по автоматизации клиники”.

Что такое “Описание Предметной Области”? Это UTS или что-то иное?

“Описание Предметной Области” (U.Episteme: DomainDescription) — это комплексная U.Episteme, которая включает в себя U.Episteme: UnifiedTermSheet (UTS) как один из своих ключевых компонентов, но не ограничивается им.

FPF-состав U.Episteme: DomainDescription:

  1. U.Episteme: UnifiedTermSheet (UTS): Это основа. UTS описывает ключевые U.Episteme (понятия), U.Holons (сущности) и их U.Relationships (взаимосвязи) в данной U.Episteme: Domain, а также U.Bridge и U.Episteme: CongruenceLoss при переводе между U.BoundedContext внутри домена. Он обеспечивает U.Episteme: SharedUnderstanding для используемой терминологии.
  2. U.Episteme: DomainModel (Доменная Модель): Это U.Episteme: StructuredRepresentation (структурированное представление) ключевых U.Holons, U.Episteme, U.Rules и U.Processes предметной области. Может быть выражено через диаграммы классов, ER-диаграммы, графы U.Episteme и т.д. Оно показывает, как все эти понятия взаимосвязаны и как они функционируют.
  3. U.Episteme: KeyConstraints (Ключевые Ограничения): Это набор U.Episteme: Laws (законов), U.Episteme: Regulations (регуляций), U.Episteme: BusinessRules (бизнес-правил) и U.Episteme: IndustryStandards (отраслевых стандартов), которые управляют поведением U.Holons и U.Work в этой U.Episteme: Domain.
  4. U.Episteme: CoreProcesses (Основные Процессы): Описание ключевых U.Work и U.Methodов, которые обычно выполняются в этой U.Episteme: Domain для достижения типичных U.Objectives.
  5. U.Episteme: ArchetypalRoles (Архетипические Роли): Описание типичных U.Roles, которые U.Holons играют в этой U.Episteme: Domain, и их основных U.Concernов.
  6. U.Episteme: DomainGoalsAndObjectives (Цели и Задачи Домена): Общие U.Episteme: StrategicGoals и U.Episteme: Objectives (U.BusinessOutcomes) для U.Holons в этой U.Episteme: Domain.

Вопросы для Описания Предметной Области Проекта (U.Episteme: DomainDescription)

Чтобы получить всеобъемлющее описание U.Episteme: Domain, которое будет полезно для всех U.Roles в U.Holon: CreationSystem, U.Holon: ConceptualOrchestrator или U.Holon: ProjectArchitect должен задать следующие вопросы (экспертам домена, стейкхолдерам, опытным членам команды):

Блок 1: Идентификация и Границы Домена

  1. Как мы называем этот “мир” или область деятельности, в которой существует наш проект? (Например, “электронная коммерция”, “управление цепочками поставок”).
  2. Какие другие “миры” (домены) граничат с нашим? (Например, для e-commerce это “логистика”, “финансы”, “маркетинг”). Где проходят эти границы?
  3. Какова главная цель или миссия этой предметной области? Для чего она существует? Что она пытается достичь в широком смысле?

Блок 2: Ключевые Сущности (U.Holons и U.Episteme) и их Описание (UTS - часть 1)

  1. Кто или что является главными “игроками” (ключевыми сущностями, агентами) в этом домене? (Например, “Клиент”, “Продавец”, “Товар”, “Заказ”, “Доставка”, “Платёжная система”).
  2. Какие важные понятия, данные, информация используются в этом домене? (Например, “идентификатор пользователя”, “статус заказа”, “информация о продукте”, “адрес доставки”).
  3. Для каждого ключевого “игрока” или понятия:
  • Как бы вы описали его основную суть простыми словами?
  • Какие его главные характеристики?
  • Есть ли у него разные виды или состояния? (Например, “Клиент” может быть “Новым”, “Постоянным”, “VIP”).
  • Какие синонимы или связанные термины используются для него?

Блок 3: Правила, Процессы и Взаимодействия (U.Episteme: DomainModel, U.Episteme: KeyConstraints, U.Episteme: CoreProcesses)

  1. Какие основные правила или законы управляют этим доменом? (Например, “заказ не может быть отправлен без оплаты”, “пользователь должен быть авторизован”, “данные должны храниться X лет”).
  2. Какие основные последовательности действий (процессы) происходят в этом домене? (Например, “процесс оформления заказа”, “процесс возврата товара”, “процесс регистрации пользователя”).
  3. Как эти “игроки” (из вопроса 4) взаимодействуют между собой? Кто что делает, кто кому передаёт информацию или продукты?

Блок 4: Типичные Роли и Интересы (U.Episteme: ArchetypalRoles)

  1. Какие типичные “роли” люди или системы играют в этом домене? (Например, “Менеджер по продажам”, “Сотрудник склада”, “Покупатель”, “Администратор системы”).
  2. Что самое важное (главные интересы/озабоченности) для каждой из этих типичных ролей? (Например, для “Покупателя” — “быстрая доставка”, “низкая цена”; для “Сотрудника склада” — “эффективная инвентаризация”).

Блок 5: Проблемы и Цели Домена

  1. Какие распространённые проблемы или вызовы существуют в этой предметной области? (Например, “высокий процент отказов от корзины”, “сложности с возвратом товаров”, “неэффективная логистика”).
  2. Какие основные стратегические цели преследуют участники этого домена? Что они хотят улучшить или изменить в широком смысле?

Замечания для U.Holon: ConceptualOrchestrator:

  • U.Episteme: IterativeProcess: Описание U.Episteme: Domain — это не разовый акт, а Canonical Evolution Loop (B.4). Ваше первоначальное описание — это U.Episteme: Hypothesis, которая будет уточняться по мере погружения в проект.
  • U.Episteme: MultipleSources: Собирайте ответы от разных U.Holons (экспертов, стейкхолдеров), так как у каждого будет свой U.Viewpoint и свои U.Concernы.
  • U.Episteme: SharedUnderstanding: Цель — не просто собрать информацию, а достичь U.Episteme: SharedUnderstanding об этой U.Episteme: Domain среди всей команды проекта. Используйте U.Episteme: UnifiedTermSheet (UTS) как ключевой U.WorkProduct этого процесса.

Таким образом, “описание предметной области” — это жизненно важный U.Episteme: FoundationalAsset для любого проекта, который обеспечивает, что вся команда работает в едином U.Episteme: SemanticSpace и понимает “мир” своего проекта одинаково.

Разделяемые объекты, понятные для значительного количества представителей какой-то роли, принято называть все вместе “предметной областью”

Примеры SSOT (единый источник истины):
• Согласованная U.Episteme: DomainDescription (описание предметной области)
• Актуальный U.Episteme: ProjectRoleMap (карта ролей проекта)
• Утверждённый U.Episteme: UnifiedTermSheet (UTS)
• Текущая U.Episteme: SystemArchitecture (архитектура системы)
• U.Episteme: Backlog (список задач) с приоритетами.