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

Планы, как всегда, меняются на ходу (я много лет не понимал замечания, что "планы нужны только для того, чтобы их выбросить, ибо первый же пункт выполненного плана -- путь в тупик, путь к ошибке. Но вы не имеете права не разрабатывать планы", теперь-то я хорошо это понимаю!). 10 июня 2026 проекту FPF исполнился год (https://ailev.livejournal.com/1802830.html), с начала второго года проекта уже прошло несколько дней -- а изменений уже хоть отбавляй. Я закончил очередную кампанию, в которой в очередной раз пытался уточнить понятие метода -- ибо идёт отчаянная путаница в понимании изменений: метод, работа, алгоритм, трансдукция, функция и многое другое, где что-то "синонимы с нюансами", а что-то имеет принципиально другую природу. Предмет (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 (https://arxiv.org/abs/2606.07352), а темпоральность ещё и опирается в какой-то мере на обновление (тоже от 5 июня) годичной давности работы "Constructor theory of time" от Deutsch и Marletto (https://arxiv.org/abs/2505.08692v3) -- там 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 в https://ailev.livejournal.com/1801179.html, а сегодня ещё напомнил Григорий Сапунов в https://t.me/gonzo_ML/5539 -- нельзя доверять AI понимание статей, "Потому что понимание -- это то, на чём строится следующее понимание; отдав его, ты теряешь не одну статью, а способность достраивать. Развитие абстракций -- наша суть, не бросайте этот путь. Оставляйте себе время на понимание. Особенно базовых вещей. Не воспринимайте слова из области просто как ярлыки для чёрных ящиков"). Так что эту ситуацию с "FPF как-то там сам внутри работает, и этот магический чёрный ящик" надо как-то ломать, делать из FPF "прозрачный ящик". Я не думаю, что кто-то сейчас понимает содержательно, над чем я работаю в FPF -- понимание у большинства наших инженеров-менеджеров осталось на уровне текущих текстов моих руководств (это примерно годичная давность, там AI ещё разрешалось, но они не AI-native и там понятные дыры в содержании -- в FPF для части этих дыр уже нашлись затыки, вот на семинарах про часть из них расскажу). Вот итоговое расписание (хотя меня ещё за него ругают -- "сформулировано так, что никто не придёт, особенно на первый семинар", а записываться надо будет с вечера понедельника через @schoolbot (продвижение будет через некоторое время, а пока пишу только у себя в блоге, чтобы немногие его читатели не забыли заранее поставить эти события себе в календарь, более подробно про программу семинаров см. в https://ailev.livejournal.com/1803425.html): 1. Итоги первого года разработки FPF как языка паттернов для смешанной работы людей и AI-агентов над проблемами в рабочих проектах -- 28 июня 2026 2. От системного мышления к архитектурному мышлению -- 12 июля 2026 3. Рабочие процессы: от проблем через принципы к работе (структуры потоков изменений и P2W) -- 19 июля 4. Как хватать за язык себя и других (управление точностью языка) -- 26 июля 5. Как сделать технический регламент для 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 число, но не мая, а текущего месяца -- "я художник, я так вижу").