Кампании по холонам, уровням и культурной эволюции закрыты, результаты опубликованы. Следом прошла (как всегда, внеочередная) кампания по уточнению MOVE, и она тоже закончена. Хорошее продолжение после посадки в FPF многоуровневой этики в предыдущих кампаниях (я мельком упоминал это в последних постах lytdybr).
Первая кампания стабилизировала, какие объекты и отношения мы вообще считаем основными рабочими единицами в FPF, холоны вводятся прямо в паттерне A.1. Кампания прописала, как холоны конфликтуют между их холоническими уровнями (целые конфликтуют и со своими целыми как части, и со своими частями), давая принципиальную неустроенность/неустаканенность/frustration как движущую силу увеличения сложности в ходе биологической или культурной эволюции или даже инженерии как техноэволюции. Тут в FPF опора на работы линии Ванчурина-Кацнельсона про роль этих конфликтов в неизбежном росте сложности в эволюции и одновременности эволюции на всех уровнях.
С MOVE пришлось разбираться, чтобы почистить язык инженерных действий в FPF: я ведь готовлю слайды к семинарам, и там выражения вроде «инженерный ход», «следующее действие/ход», «готовность хода» по отношению к паттернам опасно начали путаться с «просто изменениями» и даже с MOVE из TameFlow, где совсем другая «готовность ХОДА». Надо было восстановить точность языка.
U.Holon остался общим случаем «целое с частями» в заданном контексте. U.System — это холон, который действует (делает изменения в окружении), он может нести роли, способности (capabilities), выполнять работы по методам, реализовывать механизмы, участвовать в разных преобразованиях и даже нести ответственность. U.Episteme — недействующий, но несущий утверждения холон: теория, модель, описание, корпус знаний, стандарт, семейство документов (но без носителей! Носители информации, carriers, — это системы, они вне эпистемы, «это другое»). Работы, дисциплины, ограниченные (то есть проектные) контексты и коллекции (например, коллективы агентов, живых и не очень) тоже могут рассматриваться как холоны, но только через свои собственные паттерны и свои собственные онтики, а не через заявление, что «это тоже система» или «это тоже эпистема», с прихватом онтик системы и эпистемы. Это означает, что со всеми ними можно действовать и рассуждать как с холонами: главное там — метахолонный переход, когда сборка из частей вдруг даёт новое целое с эмерджентностью как появлением новых характеристик целого холона, которых не было у холонов-частей (при этом U.Emergence так и не была введена, как-то обошлось).
Практический выигрыш: FPF теперь лучше держит ситуации, где команда, документ, метод, работа, продуктовая структура, дисциплина и архитектурное описание оказываются рядом, но не превращаются друг в друга. Например, токарный станок может менять заготовку, но от этого не становится надхолоном заготовки. BIM-модель или цифровой двойник может описывать сооружение, но не становится самим сооружением, его архитектурой, свидетельством существования чего-то в сооружении или принятым решением по поводу сооружения. Платформа онлайн-СМИ может влиять на стиль, но не становится сама корневым типом «культура». Внимание не путается, рассмотрение разных видов сущностей и действия с ними поэтому тоже не путается.
Отдельно прояснён вопрос холонических уровней: системных, эпистемных, рабочих и т.д., а также границ, взаимодействий и появления нового целого. В FPF не заводятся отдельные корневые типы U.Interaction, U.Boundary, U.Level, U.Emergence, U.Frustration: такие объекты удобны в метафорической речи, но слишком широки для точной. Уровень, граница, взаимодействие, обратная связь, новая целостность и межуровневые конфликты в FPF, тем не менее, определяются более-менее строго. В итоге проще отслеживать риск, что любой граф, таблица, иерархия, интерфейс, диаграмма или метрика будут автоматически объявлены архитектурой или системным уровнем. В руководствах выражение «граф создателей» тем самым путает математический аппарат «граф» (а могла бы быть нейросеть, и тогда не «граф») и структуру потока преобразований систем в роли преобразователей (в текущих руководствах они «создатели»).
Культурная эволюция получила свой собственный паттерн C.36 - Cultural Evolution and Cultural-Evolution Engineering. Это важно: речь не о новом словаре для слов «культура», «стиль», «традиция» и «жанр», а о рабочих ситуациях, где проект управляет развивающимся набором вариантов. Примеры: семейство продуктов, инструментальная цепочка, исследовательская программа, дисциплина, инженерная практика, методическое семейство, музыкальный или танцевальный стиль, организационная культура, семейство AI-агентов.
Для таких случаев C.36 собирает то, что обычно разбросано по разным теориям и разным паттернам: коллективные холоны, роли, семейства работ, семейства методов, каноны и эпистемы памяти, режимы распознавания и отбора, посредничающие системы и архитектуры, наборы вариантов, мосты для терминов вроде «стиль» и «традиция», измерения, обновление и текущую интервенцию. И ещё помогает, конечно, выбрать текущую интервенцию в рамках NQD/OEE, потому что культурная эволюция прямо стыкуется с подходами novelty-quality-diversity в open-ended evolution. C.36 не заменяет паттерны, которые дают решения для проблемных ситуаций с самыми разными холонами, но даёт вход в проблемные ситуации культурно-эволюционной инженерии без биологизирующей метафоры и без корневого U.Culture. Понятий FPF для рассуждений о культуре, инженерии культуры и культурной эволюции вполне хватает, и можно просто игнорировать спор о терминах — это вечное «что такое культура».
Смысл эволюционной инженерии культуры в FPF теперь можно формулировать инженерно: мы меняем не «культуру вообще» и даже не спорим, что это такое. Но мы вполне можем менять конкретные отношения генерации, передачи, распознавания, отбора, сохранения, обучения, публикации, измерения, архитектурного посредничества и способы обновления вариантов конкретных холонов. Это хорошо ложится на работу с AI-агентами: агент может генерировать варианты холона (системы, метода, работы), но кому-то в проекте всё равно нужно решить, что считается вариантом, как он сравнивается, как сохраняется, кто его распознаёт, по каким признакам он отбирается, как попадает в работу и когда старый набор вариантов надо обновлять.
Именно эта кампания завершила мои усилия по отражению в FPF материала «Развитие для развитых». Там я рассказывал идеи, которые были на тот момент только частично поддержаны FPF, а дальше надо было использовать «слайдомент». Тот «слайдомент» для менеджерских и инженерных заметок до сих пор актуален, но теперь основная трансдисциплинарная часть полностью поддержана паттернами FPF.
Новая кампания по MOVE началась потому, что слово move стало полезным в объяснении того, что делают инженеры-менеджеры и как они применяют паттерны. У меня уже есть проект для 247 слайдов всей серии из 1+5 семинаров, и там слово «ход» встречается 918 раз. Но это слово не только полезно, но и дико перегружено. В одном месте это «первый полезный ход» при применении паттерна, в другом — TameFlow MOVE как управленческая единица поставки результата работы, в третьем — готовность работы к запуску (в том же TameFlow не церемонятся с отслеживанием типа), в четвёртом — локальный ход в архитектуре (принятие архитектурного решения), какое-то действие в работе с языком как таковым (скажем, повышение точности языка) или указание на планирование (а не исполнение) вызовов инструментов AI-агента, и даже команда машинного языка MOVE. FPF не заводит корневой U.Move, не вводит такую онтику.
Вместо этого разделяются три случая использования термина move:
- MOVE из TameFlow остаётся внешним управленческим материалом: целевая единица поставки результата, минимальное усилие с полезным результатом, подготовка к обязательству и входу в работу. В FPF это раскладывается на уже существующие там понятия: намеренную работу, план, готовность входа в работу, ресурсные условия, решение о запуске работы и даже выполненную работу — только тогда, когда работа действительно произошла, а не идёт долгий разговор о её планировании. Для понимания того, что происходит в таких случаях, есть новый паттерн
E.10.MOVE - Move and Readiness Wording Precision Restoration - «Первый полезный ход», «рабочий ход», «профессиональный ход» и «SoTA-ход» остаются нормальной инженерной речью, но при необходимости онтологической точности языка FPF будет восстанавливать их как рекомендации применения паттерна (wording-use ontological precision restoration). Для этого есть новый паттерн
E.11.PUR - Pattern-Use Recommendation and Pattern-Use Sequence - Готовность входа в работу в FPF — отдельный вид сущности: это ещё не работа и не результат, а проверка условий перед запуском, обязательством или прохождением через рабочую границу. Новый паттерн
A.15.5 - Work-Entry Readiness and Full-Kit Preparation
Слово «ход» не запрещается. Инженерный текст вполне может говорить «первый полезный ход» там, где это естественно для обычного разговора инженеров-менеджеров. Но при проектной коллективной работе, особенно если в коллективе есть AI-сотрудники, надо переходить к онтологически точному языку, включать «машинку типов». Должно быть понятно, что именно стоит за этим словом: какое из десятка или даже большего числа его значений.
Всем этим уже пользуйтесь (GitHub - ailev/FPF: First Principles Framework (FPF): Pattern language and core specification for admissible action in problematic engineering, research, and mixed human/AI work. · GitHub), дальше по плану у меня четыре подряд кампании по уточнению понятий «архитектура» и «архитектурная работа» в FPF. И одновременно делаю слайды к семинарам (там уже мой рабочий файл с черновичками 247 слайдов тянет на хорошую такую книжку, «руководство/guide по FPF»). Вот как выглядит, например, текущий черновичок последнего слайда серии (сорок пятый слайд пятого семинара), основная идея тут была в чёткой привязке человеческого русскоязычного содержания слайда к специфическому сленгу и точным паттернам FPF:
5.45 FPF даёт язык ходов, SPF даёт предметную работу
Ключевая онтика: язык паттернов (pattern language), рекомендация применения паттерна (PatternUseRecommendation@Context), последовательность применения паттернов (PatternUseSequence@Context), проблемная ситуация (problem situation), первый практический вход (first-practical entry), предметный SPF (subject pattern language), SoTA-пакет (SoTA pack), архитектурный вопрос (ArchitectureQuestionCard@Project), работа (U.Work), цикл улучшения (QualityImprovementLoopMethod), ИИ-задание (AI task face)
- Вся серия прошла путь от myFirstSPF к настоящему предметному языку паттернов: сначала короткий регламент для ИИ, затем FPF как язык паттернов, архитектура, P2W, точный язык вашей предметной области и SPF как язык паттернов вашей предметной области, опирающийся на мощь FPF
- FPF — не проверочная система и не словарь различений, а общий язык рабочих ходов: сформулировать проблему, построить варианты, выбрать, спроектировать структуру, довести до работы и улучшить
- Паттерны применяются вместе, как слова складываются в фразы: один паттерн даёт вход, другой выбирает структуру, третий переводит решение в работу, четвёртый обновляет SoTA или текст
- Хороший вход начинается с обычной проектной потребности: что болит, что надо решить, какой объект под вопросом, какой первый результат нужен и где нельзя делать вид, что всё уже понятно
- SPF переносит эту дисциплину в предметную область: добавляет свои проблемные ситуации, SoTA-ходы, объекты, роли, методы, примеры, имена
- Команда получает повторяемый вопрос: какая это ситуация, какой профессиональный ход здесь силён, какой объект меняем, какие границы держим и как поймём, что стало лучше
- ИИ-агент становится полезнее не из-за магии промптов, а потому что получает предметный язык действий, границ, примеров, SoTA и ожидаемых рабочих выходов
- Минимальный полезный результат серии практикумов семинара — один SPF из десятка (или даже меньше) паттернов, применённый на реальном рабочем случае и затем улучшенный по итогам результатов первого применения
- Дальнейшая работа: выбрать следующую наболевшую ситуацию в этой предметной области, расширить SPF решениями для этой ситуации, но не превращать SPF в энциклопедию этой области, «нельзя объять необъятное»
- Финальный вопрос для себя: после серии семинаров вы можете объяснить не “что такое FPF”, а какой рабочий ход он даёт в вашей предметной задаче?
Технические опоры: 1) E.11 - First-Practical Entry and Pattern-Use Discoverability Discipline; 2) E.8 - FPF Authoring Conventions and Style Guide; 3) C.22.2 - ProblemCard@Context; 4) C.11 - Decision Theory (Decsn-CAL); 5) C.30 - Grounded Architecture and Selected-Structure Adequacy; 6) A.15 - Role-Method-Work Alignment (Contextual Enactment); 7) E.18 - Transformation Flow Structure; 8) G.2 - SoTA Harvester & Synthesis; 9) E.23 - Quality Improvement Loop Method; 10) E.13 - Pragmatic Utility and Value Alignment.
