Я уже публиковал в нескольких постах разные фрагменты моего плана работ по FPF, а теперь просто собрал все эти отрывки вместе и расположил в более-менее логической последовательности. Конечно, по пути такой огромной работы всплывёт ещё много нового неучтённого – и всё в жизни будет не так. Планы нужны, чтобы их выкидывать, но их нельзя не разрабатывать! Вот и разрабатываю:
– сейчас хороший момент, чтобы убрать противоречия с онтологией холонов, методов, работ, ролей (в тексте FPF ещё остались какие-то следы старых вариантов). Без этого дальше будет трудно. Вот прямо сейчас этим занимаюсь: чистка определений в паттернах B.1.5, B.1.6, A.14, A.2, чтобы Method везде был design-time capability, Work везде была run-time enactment, MethodDescription мог быть как step-graph, так и dynamics, solver, quantum-channel или что-то подобное. Как предварительное решение, методы и роли не будут холонами (впрочем, это уже и так в большинстве мест прописано, что это “маски на холонах, сами не холоны”). Также сразу разбираемся с затыками по лексике вокруг “целостности” – сразу делаем A.6.H. Впрочем, пока писал – уже всё это сделал.
– архитектура управления точностью языка, чтобы развить идею восстановления “мутной речи на границе” паттерна A.6.P, где по факту задействовано две разных технологии: routing высказываний о контекстах/границах L/A/D/E и лексическая точность на границе в сигнатурах/отношениях/интерфейсах. Надо вытащить оттуда управление сжатием-разжатием в языке, и я сегодня весь день как раз этим и занимался, там могут быть разные архитектуры. Работаем по норме: предлагаются варианты, ищутся недоминируемые, далее идёт из них выбор. Перед тем как лезть в архитектуру, хочется иметь более-менее универсальную машинку управления точностью/сжатостью разговора. Одна из идей – это уподобление куска текста LLM, а ситуации – набору данных, чтобы как-то “прикидывать на пальцах” оценки сжатия, “текст кодирует структуру ситуации” с ходом на “структуру” по линии, намеченной в недавних работах по ML (см. паттерны ML.* в От контекстного окна к виртуальной памяти: skills-пакеты FPF и архитектура подкачки знаний: ailev — ЖЖ). Это не формализация. Тут можно писать большой пост, ибо написанный мной в несколько заходов промпт для анализа архитектуры управления точностью и сжатостью (это два разных viewpoint: один про провоцирование ошибок и реальные ошибки, другой про длину релевантного высказывания перед ходом на мышление) уже больше, чем весь этот пост. Вот прямо сейчас GPT-5.2 Pro в подрежиме extended thinking размышляет, что там можно было бы сделать в FPF. Ведущие архитектурные характеристики при этом – evolvability, universality, usability и вычислительная ёмкость повышения точности (скажем, сколько раз надо кликнуть по ссылке, чтобы попасть на нужный фрагмент “одной точки правды” – это, похоже, ключевое будет, “самодокументируемые имена” вместо “глоссария” или “регистра claimID” именно из этой характеристики растут), а характеристику трудоёмкости переделок я пока игнорирую.
– после того, как можно будет ткнуть пальцем на точность языка, можно пообсуждать всякие “целостности” (мереологическая “границы и идентичности”, интерфейсная как инвариант для внешних взаимодействий, семантическая как смысл внутри контекста и т.д.). Это нужно, чтобы доразобраться с холоническим мышлением: трудные вопросы про холоничность не только систем и эпистем, но и методов, работ, ролей (пока FPF на эти вопросы отвечает очень уклончиво и разнообразно, что верный признак необходимости “распаковки” пересжатой лексики во что-то более точное. В этих всех объектах что там холон и агрегации частей-целых, что “просто алгебра”, а что “факторизация стрелок”, несводимая к холоничности? Какие понятия пропущены? Можно и так, и сяк – но как надо? Очень мутное место, там надо делать отдельный набор паттернов для восстановления семантической точности, наподобие A.6.P для семантической точности “на границе”. Если уж и начинать систематически подкладывать под рассуждения какую-то математику, чтобы потом рассуждениям можно было как-то доверять, то без этого никак. Надо доделывать часть B, прописывая всё недосказанное про холоны и добавляя всё недосказанное про механизмы и сигнатуры, их алгебры, факторизации стрелок и всё подобное.
– теперь нам надо уметь описывать инженерные процессы самого разного вида, сложные методы. Поэтому дальше будет TGA, ибо все эти “процессы” сводятся к применению развитого аппарата описания потоков трансдукций (читай: функциональных описаний). Отсутствие развитой характеризации было барьером, теперь можно вернуться к вопросу. И говорить точным языком! Там же от принципов к работе – а результаты работы хорошо бы измерить и сравнить с тем, что было предсказано по принципам, и вот это всё работа с характеристиками, там это сквозная нить. Есть задание на эту работу, и в этом задании почти 400Кзнаков, предусматривающие генерацию чуть ли не пары десятков паттернов. Это задание надо будет освежить – и выполнить.
– теперь надо будет добавить материал по проблематизации (по итогам семинара “Развитие для развитых”: в FPF уже хорошо поддержана вторая фабрика – фабрика решений, а вот первая фабрика поддержана, но недостаточно. При этом уже есть C.22 Problem-CHR, и много чего ещё по линии проблем. Но надо больше!). Как получить план? Как обычно: “В файле у тебя спецификация FPF, которую мы улучшаем, а также слайды для семинара по развитию, в которых описан SoTA-тренд на изменение типового инженерного процесса. Надо понять, чего не хватает в FPF для полноценной поддержки упоминаемых в презентации идей. Понятно, что собственно сам процесс может выразить TGA, но ведь явно не хватает каких-то kinds, mechanism suits и отдельных механизмов в их состав, каких-то наборов viewpoints, чего-то ещё. Надо затем предложить для этих разрывов набор паттернов, который их ликвидирует. Возможно, надо также изменить какие-то уже имеющиеся паттерны в FPF, чтобы было удобней моделировать предложенный в слайдах процесс (если, конечно, процесс этот более SoTA чем то, что уже описано в FPF)”. Выдача – это и есть план (хотя в реальности чуть сложней: надо прогнать пару раз этот промпт, ибо в выдаче будет разное. А потом обобщить результаты нескольких выдач. На выходе где-то до десятка паттернов вроде “F.20 — ProblemCard@Context” (каноническая карточка проблемы). Цель: если уж инженерный процесс обновился, надо переставать изобретать каждый раз идеи проблемы, решения, архива и портфеля со связанными с ними операциями заново, документировать паттерны и анти-паттерны работы с ними всеми. После этого промпт для LLM+FPF вроде “оформи портфель проблем в нашей Jira” должен отрабатывать без особых сюрпризов. Это уже второй вопрос, что тут “прикладное”, а что “фундаментальное, из первых принципов”. Вроде как все эти понятия достаточно фундаментальные, а вот конкретные workflow будут прикладными.
– и вот тут надо будет вернуться к теме холонов и добить её так, чтобы уже не оставалось вопросов. Там ещё куча паттернов в части B недописана. В том числе раскрыть тему конфликтов между холоническими уровнями, ибо “проблематизация” к этому моменту уже вся будет, OEE будет, вот и дать онтологию конфликтов.
– характеризация в FPF уже есть, какой-то паттерн для Q-bundle характеристик уже есть, моделировался по мотивам архитектурных характеристик. Так что дальше можно заняться темой архитектуры, а начать её с “характеристик качества” как архитектурных характеристик. Известно, что их в литературе всего упоминается порядка 300, часто используемых порядка 30, вот и поисследовать. На эту тему и я уже немного писал в руководствах, а ещё были исследования Антона Королёва в МИРЭА, он рассказывал о них на нашей рабочей встрече INCOSE Rus по проблемам системной инженерии, эти исследования как раз подтверждают оценки “300 всего” и “30 самых употребимых”. Трудность в том, что каждая архитектурная характерстика оказывается не просто каким-то скаляром, а вот этим самым Q-bundle, распаковывается в целый набор характеристик (и книжки по характеризации в эволюционной архитектуре как раз пытаются с этим сработать, подзаголовок профильной книжки там говорящий: the hard part).
– дальше будет обсуждение характеристик собственно архитектуры, не путайте с архитектурными характеристиками. Архитектурные характеристики – это характеристики холона, определяемые его архитектурой. А характеристики архитектуры – это характеристики самой архитектуры. Скажем, reliability - это типичная архитектурная характеристика. Но сама архитектура? Например, coupling модулей в этой архитектуре можно отнести к характеристикам архитектуры. И тут мы идём к формулированию понятия “архитектура”, и у меня есть идеи по тому, как это делать (вернуться к “архитектуре как структуре”, дальше архитектурное описание – это (multiple viewpoints and multiple views)-определяемое описание структуры, а недавние работы по ML (см. паттерны ML.* в От контекстного окна к виртуальной памяти: skills-пакеты FPF и архитектура подкачки знаний: ailev — ЖЖ) показывают, как там что-то можно оценить численно: что из структуры мы описываем, а что не описываем. Всё опять упирается в “моделирование”, viewpoints, “сжатое описание” и это общий аппарат, а вот сами viewpoints уже предметны. Вот этот viewpoint – архитектурный. Тем самым можно будет обсуждать качество архитектурных описаний, а также “динамику архитектуры” (изменение значений в пространстве характеристик архитектуры во времени для какой-то конкретной архитектуры).
– и вот теперь у нас всё есть для занятий архитектурой самого FPF, где в основе “нулевые принципы”, а архитектура крутится не вокруг “вставки модулей”, а вокруг специализаций, семейств, наборов механизмов и прочего такого, и вообще речь идёт о “спецификации FPF”, то есть эпистеме.
– и вот тут-то SoTA-packs (часть G), Second and Third Principles Frameworks, типовые P2W профили и прочие варианты расширения на предметные области. Хотя часть G уже готова, но я ещё вернусь к этому вопросу, мне не всё там нравится.
Поскольку у нас тут в связи с приходом AI-агентов и сдвигом инженерной работы на проблематизацию и организацией решений проблем силами этих агентов получается некоторый новый инженерный процесс, то ещё надо будет опять и снова срочно дорабатывать руководства. Туда надо добавлять довольно много по самой проблематизации, протоколы характеризации (сейчас там, конечно, даются ссылки на “как измерить всё, что угодно”, но тут сам подход меняется – собственно идеи по характеристикам как характеризация, но затем индикаторизация, нормирование, возможный скоринг и свёртка/агрегация, сравнение и выбор, набор механизмов существенно больше, чем просто “указать набор характеристик”). Или взять хотя бы понятие stepping stones, которое вводится сейчас в “Методологии” абсолютно неформально и метафорично, но его ведь надо вводить абсолютно явно.
