Что происходит с FPF в первые дни второго года проекта, в середине июня 2026

ailev · 13.Июнь.2026 19:52:56

Планы, как всегда, меняются на ходу (я много лет не понимал замечания, что “планы нужны только для того, чтобы их выбросить, ибо первый же пункт выполненного плана – путь в тупик, путь к ошибке. Но вы не имеете права не разрабатывать планы”, теперь-то я хорошо это понимаю!). 10 июня 2026 проекту FPF исполнился год (FPF перед днём рождения (проекту 10 июня 2026 будет годик).: ailev — ЖЖ), с начала второго года проекта уже прошло несколько дней – а изменений уже хоть отбавляй.

Я закончил очередную кампанию, в которой в очередной раз пытался уточнить понятие метода – ибо идёт отчаянная путаница в понимании изменений: метод, работа, алгоритм, трансдукция, функция и многое другое, где что-то “синонимы с нюансами”, а что-то имеет принципиально другую природу. Предмет (scope) этой кампании расширялся много раз, так что при очередном расширении я разозлился и предложил уладить сложные отношения между методом, механизмом, алгоритмом, планом работы и работой через задействование нового архитектурного блока: онтики.

Я предложил начать с онтики изменений и онтики темпоральности (ибо изменения во времени). Для этого – формально ввести понятие онтики примерно так же, как мы вводили онтику эпистемы в E.2.1 (не называя её там “онтикой”) – это не вся онтология области, а маленький кусочек онтологии: набор слотов, ограничений и инвариантов, о которых надо подумать в типовой ситуации встречи с каким-то понятием. Так что в E.2.1 слова “онтика” не было, а онтика была, а сейчас и слово “онтика” есть – сделан паттерн E.24, который даёт шаблон для онтики, и он был отмоделирован по E.2.1, улучшен, а затем по нему были улучшены в том числе и E.2.1, и другие паттерны.

Основная идея введения онтик в FPF – в повышении модульности: связи между понятиями слотов в отношении (основное понятие онтики задаётся отношением) доступны в одном месте (при оформлении паттернами слоты описываются в одном паттерне), а потом для каждого слота можно делать отдельный разбор в отдельном паттерне. Сама онтика онтики уже определяется E.24 (это всё уже в GitHub):

предотвращает duplicate ontology;
заменяет “отрицательные каталоги” позитивной slot discipline (“как бы тебе, Чебурашка, объяснить, что такое вертолёт? Апельсин знаешь? Вот вертолёт на апельсин совсем не похож” – агенты очень любят задавать предмет не через онтику “по Витгенштейну”, “предмет задаётся связями с другими предметами”, а наоборот, через развязывание с другими, чем-то похожими предметами: “архитектура – это не любая структура, не архитектурное описание, не свидетельство, не доказательство, не обещание, не Библия, не ящерица, не апельсин”);
даёт зависимым паттернам онтики стабильные имена слотов (а не сущностные имена), ибо многообразие мира закрывается дисциплиной слота. В эпистеме entityOfConcern и groundingHolon – слоты, а замещаться они могут чем угодно. Это параметризация, мощнейший приём. Это не наследование, которое плодит типы! Нет, типов немного, а многообразие мира – отражается.
отделяет стабильно используемую онтику (durable ontic) от ad hoc появляющихся отношений, имён и прочих ситуативных описаний.
делает лексику производной от онтологии и слотов, что вообще чудесно (без онтики wording-use ontological precision restoration быстро превращается в бесплодную замену одних слов-зонтиков на другие – попытки чисто лексического лечения проблемы омонимии бесплодны, но поскольку это кажется агентам лёгким путём поднятия точности языка, то срыв в “подбор слов” вместо “восстановления онтики” идёт постоянно).

Что даёт онтика? Чеклист – “если встретил слот, то ищи понятие, у которого есть этот слот, и другие слоты, о которых надо подумать”. Скажем, если встретил EntityOfInterest, то в голову сразу должна приходить онтика эпистемы-описания этой сущности, и будет groundingHolon и много чего ещё из слотов онтики эпистемы. В C.2.1 онтика описывалась главным образом “отношением слотов” с представлением в виде кортежа или графа по C.29 (уже SlotRelation, не SlotGraph), и дальше всё многообразие возможных связей онтики с окружающим миром происходит на языке слот-дисциплины (мешок картошки на складе именуется по его слоту – “хранимый товар”, а программистам надо думать о “передаче параметров”: внутри говорим имена параметров-слотов, а снаружи в эти слоты подсовываем самые разные значения).

Ещё одна законченная кампания – введение онтики изменений. Это серьёзная ломка архитектуры FPF: она даже пока оставила FPF в полуразобранном состоянии (надеюсь, завтра это уже починится, но я надеюсь, что и в текущем состоянии FPF будет более-менее работать). Это была внеочередная “8 Temporal dynamics ontic and C.27 cluster amendment”, и там была реализована моя мечта: онтика изменения, давно хотел (новый паттерн A.3.4 - U.Transformation: Bounded Change Under Conditions), заодно починен C.27 – этот паттерн разделён на два паттерна: онтика темпоральности (время, ритмы и так далее) и разговоры (в том числе математика) о темпоральности, то есть как строим описания темпоральности (а математика там – math lens, “матаппарат”). Вообще, в FPF в этой кампании больше внимания уделялось различению онтологических различений и их математических представлений. Скажем, “граф слотов” или “граф трансдукций” были отслежены как смешение онтологического языка (слоты, трансдукции) и математического. Для слотов там было “отношение” (slot n-ary relation, и сразу выяснилось, что и кортежа/tuple хватит, граф там был избыточен), для трансдукций – flow structure (а уж графом или чем иным выражать – отдельный вопрос).

И тут transduction graph architecture была резко отрефакторена: трансдукция оказалась изменением, а поток трансдукций – потоком изменений. И, конечно, связка с архитектурой – в том, что поток изменений – структура в каком-то контексте/проекте. И до кучи функционирование функционального элемента – это тоже изменение, только у него есть встроенность в какой-то поток изменений. Всё не слишком идеально, но схлопнулось: онтики для этого и существуют. Теперь есть изменение, оно задано онтикой как отношение слотов (ситуация будет подставлять в слоты самые разные объекты), а сам набор слотов там служит чеклистом “о чём надо подумать, если вы рассматриваете изменение”. Ну и в онтике ещё инварианты и ограничения, она побогаче, чем просто онтологическое n-арное отношение.

Там интересные источники в SoTA для онтики изменений: общая теория изменений берётся с опорой на свежайшую (5 июня 2026) работу “Tests of constructor theory” от Deutsch, Marletto и Vedral ([2606.07352] Tests of constructor theory), а темпоральность ещё и опирается в какой-то мере на обновление (тоже от 5 июня) годичной давности работы “Constructor theory of time” от Deutsch и Marletto ([2505.08692v3] Constructor theory of time) – там transformation specification для задачи сама по себе не несёт duration и внутреннего хода исполнения, а duration и dynamics восстанавливаются через отношения атрибутов по таймеру/часам. Это ж разделение между методом и работой (про метод мы обычно говорим функционально в “логическом времени”, а о работе – с учётом реального времени). И ещё transductor и system в контекстной роли – это ведь просто transformer (в constructor theory это constructor), а его поведение – “ограниченное изменение в определённых условиях”, то есть “преобразование”, transformation.

Онтика изменений уже опубликована, но это только половина дела. Transduct* пока встречается 143 раза в 53 паттернах, TGA-остатки – 331 раз в 49 паттернах, поэтому прямо сейчас происходит нормализация всего FPF под новую онтику изменений – кампания 8a. После этого разговор о функционировании, функциональных элементах, преобразователях и прочем таком – унифицируется. “Изменитель” (в наших руководствах – “создатель”) и “изменение”, а дальше много-много нюансов, о которых надо подумать – и они задаются слотами, каждый из которых имеет свой паттерн, разъясняющий, что там делать с типовыми проблемами.

После этого рефакторинга “изменений” будет рефакторинг структуры FPF, там будет общий переход на онтики – кампания 8b, ибо если уж продолжать – то надо и онтику архитектуры делать, и онтику публикации, и ещё кое-какие онтики. Прикидки по шкалам улучшения самого FPF (E.2.DA) дают рост от введения онтик по почти всем шкалам. Так что какое-то время уйдёт на вот эту “модуляризацию онтологии в FPF”, наведение архитектурного порядка уже в самом FPF.

С онтиками также выяснилось, что легче стало разговаривать об онтике самих предметов отдельно и об онтиках их описаний – ибо онтики описаний – это специализации онтики эпистемы. Уже не надо долго объяснять про semio-bias, ибо онтика позволяет ткнуть сразу во множество своих слотов-понятий, а не вести долгие разговоры про каждый отдельный слот – что там, реальная жизнь или просто запись о жизни? В принципе, вы уже можете аккуратно пробовать делать онтики для ваших любимых предметных областей: “Сделай мне паттерн онтики для того-сего по E.24” – и кто увлекался созданием онтологий, тот может неожиданно остаться довольным. И ещё мне эти онтики очень напоминают мантры: это такие кусочки общей онтологии, о которых надо обязательно подумать, когда сталкиваешься с ситуацией этой онтики. Но только напоминают, потому что “мантры” тут – это эдакий декларативный поход по онтикам (а поход по слотам внутри онтики – это уже внутри онтики, мантры тут на уровень выше). Надо будет вернуться к этой идее. Кстати, различие между императивностью и декларативностью в FPF теперь тоже есть: C.2.P.DR - Declarative Representation Precision Restoration. Но большого доверия у меня к этому паттерну в плане его общности нет, пока он только помогает убирать попытки вычитывания “маршрутов выполнения” в цепочке паттернов. Паттерны “применяются”, но не вызывают друг друга, не диспетчируют токен вызова друг в друга. AI-агенты имеют такой же bias вычитывания императивных структур “пошагового выполнения” и “цепочек действий” из любых декларативных описаний, что и большинство людей. Всё-таки декларативные языки очень и очень контринтуитивны, а FPF весь насквозь декларативный, так что без хотя бы такого не очень общего паттерна – никуда.

С семинарами по содержанию FPF двигаем дальше: я сделаю сначала первый обзорный семинар, потом пару недель перерыв (там ведь надо где-то 250 слайдов будет сделать для этой серии) и дальше раз в неделю остальные, чтобы и люди не вымерли, и не растягивать быстроскисающий материал. Старт всех семинаров по воскресеньям в 11:30, до 14:45 (три часа рассказа, в середине будет перерыв на 15 минут). Сейчас, что там внутри FPF, практически никто не знает, используют его все как “магию” – и, удивительно, но пока это работает. Но делегировать понимание FPF – опасно (я писал про это 16 мая 2026 в lytdybr: ailev — ЖЖ, а сегодня ещё напомнил Григорий Сапунов в Telegram: View @gonzo_ML – нельзя доверять AI понимание статей, “Потому что понимание – это то, на чём строится следующее понимание; отдав его, ты теряешь не одну статью, а способность достраивать. Развитие абстракций – наша суть, не бросайте этот путь. Оставляйте себе время на понимание. Особенно базовых вещей. Не воспринимайте слова из области просто как ярлыки для чёрных ящиков”). Так что эту ситуацию с “FPF как-то там сам внутри работает, и этот магический чёрный ящик” надо как-то ломать, делать из FPF “прозрачный ящик”. Я не думаю, что кто-то сейчас понимает содержательно, над чем я работаю в FPF – понимание у большинства наших инженеров-менеджеров осталось на уровне текущих текстов моих руководств (это примерно годичная давность, там AI ещё разрешалось, но они не AI-native и там понятные дыры в содержании – в FPF для части этих дыр уже нашлись затыки, вот на семинарах про часть из них расскажу). Вот итоговое расписание (хотя меня ещё за него ругают – “сформулировано так, что никто не придёт, особенно на первый семинар”, а записываться надо будет с вечера понедельника через @schoolbot (продвижение будет через некоторое время, а пока пишу только у себя в блоге, чтобы немногие его читатели не забыли заранее поставить эти события себе в календарь, более подробно про программу семинаров см. в Юбилейная (FPF исполнился 1 год) серия из пяти семинаров по текущему содержанию FPF: ailev — ЖЖ):

Итоги первого года разработки FPF как языка паттернов для смешанной работы людей и AI-агентов над проблемами в рабочих проектах – 28 июня 2026
От системного мышления к архитектурному мышлению – 12 июля 2026
Рабочие процессы: от проблем через принципы к работе (структуры потоков изменений и P2W) – 19 июля
Как хватать за язык себя и других (управление точностью языка) – 26 июля
Как сделать технический регламент для AI-агентов в форме языка паттернов для вашей предметной области (second principle framework, SPF на основе FPF) – 2 августа

В последние несколько дней я отказался от использования тяжёлой процедуры внешнего review с GPT-5.5 Pro, процесс разработки полностью ушёл в Codex – и всё стало много быстрее:

поставлен и как-то отлажен цикл улучшений со шкалами для DRR и паттернов, это E.21 (шкалы качества паттерна, а как делать шкалы – E.22), E.23 (собственно ведение цикла), E.9.DA для шкал качества DRR, E.2.DA для шкал качества FPF в целом.
поставлены проходы по wording-use ontological precision restoration (E.10 и куча паттернов ему в помощь, архитектура описана в E.10.ARCH), это снимает огромный пласт проблем по художественности языка изложения паттернов.
есть проход по E.19 (там тоже много чего собрано, вроде проверки соответствия шаблону паттерна, консистентности ID секций, культуры использования деонтики в тексте), поэтому меньше неожиданностей в итоге процесса.
есть harness (и я практически отказался от автоматизации передачи ходов reviewer и executor друг другу: опыт показал, что мне проще не спешить в эти моменты, я не успеваю думать и писать при автоматизации этой передачи, хотя по ходу работы каждого агента что-то успеваю продумывать и писать “под руку”, это основное моё времяпрепровождение. Но в момент передачи handoff обычно надо остановиться и потребовать доработать, а не передавать дела очередному агенту без затребованной мной доработки. Я как “секретный соус” ровно в этих местах процесса: приговаривание агентам “под руку”, а затем дополнительные задания в моменты handoff).
память в виде множества файлов с возможностью тут же поправить файл с найденной ошибкой и быстро продолжить – это решающий фактор.
всяческие ledgers с разрядкой/discharge – это бесценно: агенты не теряют внимания, а отчёт в чат позволяет быстро ловить ошибки. Основное моё занятие – это чтение того, что пишут агенты в ходе закрытия бесконечного числа чеклистов (они же планы работы, но практически тождество плана и чеклиста замечал ещё Atul Ghawande в своей книжке: “как не забыть ни одной из шести тысяч работ, которые должны сделать строители? Они имеют чеклист для этого, хотя и называют его планом”). Вот это как раз оно.
с учётом всего вышенаписанного время удержания внимания на генерации, а потом проверки и чистки результатов генерации – примерно 8 часов, что явно больше времени, которое сейчас можно получить от чатового варианта Pro модели. А в нечатовый вариант (“по API”) не лезем, ибо там всё запредельно дорого. Альтернатива – пробовать Claude Code, но мне что-то подсказывает, что сейчас при прочих равных надо сидеть на Codex App (ибо это банально экономически выгодно при более-менее сравнимых результатах, а с новыми моделями и результаты будут подтянуты, о новых моделях серии GPT ведь уже тоже объявлено, что они есть – просто ещё недоступны, Anthropic тут просто агрессивнее с выкаткой “мощных, но всё-таки безопасных моделей”).
и да, я сижу на Codex App и даже не дёргался на всякие Fable (и через пару дней стало понятно, что правильно сделал).

На картинке то ли “прозрачный ящик”, то ли “ящик Пандоры” – это неважно, она просто красивая. И дата там появилась неведомым мне образом (вероятно, из текста было взято 16 число, но не мая, а текущего месяца – “я художник, я так вижу”).