Как мы дошли до сегодняшнего дня
Но последние пару недель я больше работал и меньше писал, поэтому кратко запишу сегодняшнее состояние. Не было планов замолкать надолго, ибо я собирался просто по-быстрому дописать архитектурные паттерны FPF, перемежая их нужными кусками архитектуры графа трансдукций. Но по факту пришлось чинить то, как FPF вообще отличает интересующую сущность от её описаний – это место меня беспокоило давно, но разобраться довелось только сейчас. Без этого разбирательства архитектурные паттерны превращались в инструкции “как правильно читать текст про архитектуру”, а не были помощью архитектору. В итоге всё получилось, но пришлось потрудиться.
Старт всего проекта FPF был 10 июня 2025 года, с началом экспериментов по унификации системного мышления (lytdybr: ailev — ЖЖ, а что там происходило дальше – см. Что прихвачено в ушедшем 2025 году: ailev — ЖЖ, слово FPF как First Principles Framework появилось в июле 2025 года).
За это время FPF вырос до более чем 8M английского текста на Markdown, и в репо на GitHub 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 у него на сегодня более 380 stars и 64 forks, и даже силами Стаса Недбайлова появился MCP – https://fpf.sh.
Я регулярно писал о новинках FPF в своём блоге “Лабораторный журнал”, а также провёл четыре семинара (их записи доступны здесь: https://events.system-school.ru/).
В FPF успели пройти следующие кампании (план 13 кампаний я приводил в Тринадцать кампаний до FPF для инженеров последней мили (forward-deployed engineers): ailev — ЖЖ), об итогах которых я пока не написал (и все они идут по процессу улучшений DRR и паттернов, который я описал в Циклы улучшения (OODA, POOGI, PDCA и даже Ralph loop) "в одном флаконе" -- уже в FPF: ailev — ЖЖ):
Архитектура: паттерны первой и второй кампаний
Был сделан архитектурный документ и план кампаний по архитектуре в FPF. В основе там было наблюдение, что у EoC есть какие-то структуры разных видов, а архитектура – это “вытащенный” (отжатый) набор структур, причём мера отжатости – эпиплексия/epiplexity (я писал подробнее в От контекстного окна к виртуальной памяти: skills-пакеты FPF и архитектура подкачки знаний: ailev — ЖЖ).
Был выпущен первый набор паттернов, который как-то это формулирует – но объявления об этом я не делал, подробности не писал, а сразу пошёл на разработку паттернов второй кампании.
В ходе разработки паттернов второй кампании я заметил, что рассуждения про саму архитектуру вдруг сменяются рассуждениями об архитектурных описаниях, а затем и вообще подменяются разговором о том, как оценивать разные варианты прочтения этих описаний: “архитектурные описания не должны путаться с доказательствами, приказами, свидетельствами, обещаниями, описаниями архитектурных работ” и так далее – страницы текста. Вместо того чтобы просто сослаться на A.15.4, где как раз это “не путайте…” прописано для общего случая, в большинстве паттернов появились огромные блоки семиотических предупреждений про то, как не надо читать тексты описаний интересующей сущности. Причём речь шла не столько даже о самих описаниях (для структуры и архитектуры это структурные и архитектурные описания, тоже интересная тема), сколько о прагматике чтения – о том, что нельзя вычитывать из этих описаний. Я назвал это “semio-bias”: вместо паттерна про интересующую сущность (EntityOfConcern) мы получали семиотический паттерн.
Поэтому паттерны были написаны, но вместо их публикации в монолит было проведено три кампании по снятию semio-bias.
Снятие semio-bias: три кампании
Первая кампания по снятию semio-bias должна была наладить общую архитектуру wording-use ontological precision restoration (этот термин про “восстановление онтологической точности использования слов” появился как раз в ходе этой кампании), ибо внутри паттернов про интересующие сущности появились ещё и развёрнутые тексты о том, какими словами надо об этих сущностях говорить, а какими не надо. Общий принцип был в том, что определялось онтологическое соседство (ontologicalNeighborhood) в паттернах, которые описывали какую-то смысловую область (semanticArea), и все рассуждения про то, какими словами говорить можно, а какими нельзя, собирались в отдельный паттерн, содержание которого и алгоритм исправления определялись в E.10.ARCH.
В итоге этой кампании дополнительно были объединены паттерны E.10 и E.10.SEMIO, так что теперь E.10.SEMIO вообще нет, E.10 стал эдаким реестром слов-триггеров, а дальше по каждому слову-триггеру в этом реестре был назначен паттерн конкретных ремонтов лексики на базе восстановления онтологической точности использования слов в какой-то смысловой области. В FPF уже было некоторое количество таких паттернов для смысловой области (главным образом для relational области), но в ходе этой и последующих кампаний были написаны и многие другие. Прежде всего занялись смысловой областью (semanticArea) эпистемы: чтобы вся семиотика, вся работа с описаниями опиралась на терминологию из достаточно богатого и подробно прописанного понятия эпистемы. Следующими были паттерны лексики для характеризации, для описания состояний, поймали ещё некоторое количество лексики для уже имеющихся смысловых областей (вроде support, которое добавили к уже имеющимся anchor и base), и сейчас в FPF чуть ли не десяток этих паттернов повышения онтологической точности в использовании слов.
Дальше всплыл вопрос о том, как же мы говорим о сползании разговора об интересующей сущности на разговор об описаниях этой сущности – это сползание как раз было незаметно, поэтому надо было прописать это жёстче. Так что вторая кампания по снятию semio-bias занялась вопросом различения “разговора об интенсиональном объекте” и “разговора об описании интенсионального объекта”. Это проявление strict distinction, паттерн A.7 – ход от объекта к его описанию. Но ведь описание – это эпистема, где была другая терминология для того же самого: describedEntity. Интересующая сущность была одной и той же, но говорилось о разных её ипостасях.
Моё предложение тут было (ибо AI-агенты тут никак не могли предложить решения) снять лексическую разницу за счёт использования термина EntityOfConcern, EoC, “интересующая сущность”. Термин был предложен такой, чтобы не попадать в лексическое совпадение с Entity-of-Interest из ISO 42010, после которого весь разговор сразу становился архитектурным, а не про описания как таковые. Concern традиционно является синонимом для interest, поэтому замена была содержательно “шила на мыло”, но лексически давала чёткое различение.
Слово “описание” тем самым оказывалось description episteme (описание как эпистема), а уж про эпистему и как её публиковать в FPF было давно написано. А что делать, если EoC – эпистема? Ничего специального, ибо легко можно перейти к вторичному разговору “что вы не должны вычитывать в описании описания” – эпистемы, которые описывают другую эпистему как EoC – это OK.
В A.7 вместо различения I/D/S (различения объекта, его какого угодно описания-эпистемы и спецификации как формальной публикации описания-эпистемы) осталось противопоставление EntityOfConcern (EoC) и любого его описания, а из E.10.D2 исчез огромный кусок мутного различения “любого описания” и “спецификации как особого вида описаний”.
Третья кампания по снятию semio-bias была связана с использованием Codex App (и там я получил один из самых длинных сеансов непрерывной работы одного агента, 8 часов 42 минуты): эти изменения были аккуратно (надеюсь! ибо с этими AI-агентами всяко бывает) проведены через паттерны всего FPF. Это тысячи строк с заменами, в FPF ведь сейчас 234 паттерна, а менять приходилось по нескольку строк. Как контролировалось? Лучший метод контроля тут был – считать по diff баланс замен строк по каждому hunk и объяснять разницу. Необъяснимых разниц не было, но иногда эти объяснения были “ой, тут вот отсюда был удалён лишний кусок” – и ошибки исправлялись.
Правился не только текст FPF, но и архитектурные документы, и тексты DRR, и тексты черновиков паттернов:
- восстанавливалась точность использования слов (wording-use ontological precision restoration) по E.10, огромное число слов-зонтиков как слов-паразитов было уточнено, тысячи замен. Увы, это было сделано только для свежих полутора десятка паттернов (где-то 1М текста), но не для всех 8М текста FPF. Так что работы тут ещё много.
- снимался semio-bias (иногда для этого приходилось делать отдельные паттерны для разговора об описаниях), контролировалось, что в паттернах говорится об EoC, а не об описаниях EoC (если разговор был про собственно описания, это тоже контролировалось – чтобы не было скатывания на разговор об описании описаний). Цели достигнуты, починены не только архитектурные паттерны, но и, например, C.29 – там вместо “адекватного разговора про матаппарат” теперь говорится про само использование матаппарата.
- чистилось старинное “строгое различие” I/D/S, в сотнях мест переходили к различению EoC и эпистем-описаний EoC.
- предметы интереса паттерна тоже переобзывались: object of talk, governed object, governed problem и другие варианты названий центральной сущности области смысла какого-то паттерна перевели на EoC для единообразия.
Это была довольно сильная онтологическая ломка и лексическая чистка, ибо две онтологии и две лексики (вокруг I/D/S и вокруг понятия эпистемы и публикаций эпистемы, а также введение “объекта рассмотрения” онтологически как EoC) были по факту склеены и упрощены сведением к чуть модифицированной онтологии эпистемы.
Что дальше: архитектура, TGA, остатки semio – и рассказать обо всём этом на паре семинаров
Дальше вернулись ко второй архитектурной кампании и быстренько её доделали. Быстренько – это потому как разработка идёт прокручиванием цикла улучшений, причём была добавлена ещё и шкала для отслеживания semio-bias, чтобы больше не надо было ничего ремонтировать по этой линии сползания разговора о предмете интереса на разговоры об описаниях предмета интереса – скажем, сползания разговора об архитектуре на разговор об онтологических описаниях, разговора о рабочем процессе на разговор об описаниях рабочего процесса. Теперь FPF не только вводит понятие архитектуры и поддерживает разговор о функциональной архитектуре, но и объясняет модульный синтез как уторговывание разных структур в порядке многоуровневой оптимизации по решению межуровневых конфликтов, ведущих к неустроенностям/frustrations. Матаппарат тоже это поддерживает (паттерн C.29 тоже обновили). И это всё было только условно “быстренько”, ибо кампанию пришлось расширять, чтобы она не ссылалась на ещё неопубликованные паттерны – проще было эти паттерны дописать.
Теперь AI-агент с опорой на FPF умеет:
- отличать архитектурную работу со структурами от работы с описаниями структур.
- говорить о модульности и повторной используемости в терминах набора характеристик, а не давать схлопнутые оценки вроде “плохая модульность” или “хорошая модульность”. Конечно, ещё и чинить отношения между модулями через интерфейсы, а не просто называть что угодно “модулем”.
- задавать вопрос масштаба: где архитектура выдерживает рост, а где могут быть проблемы и неизбежен выход на более высокий системный уровень, а ещё где в этом нужно будет опереться (и нужно ли вообще это делать) на матаппарат из C.29.
- делать “первый ход” по вопросу: нужна ли вообще архитектура как многоаспектная работа со структурами, или проще сработать с какими-то описаниями, рассмотреть какие-то характеристики в их пространствах, а то и вообще выправить терминологию, ибо проблема не в структуре, а в терминах.
Дальше надо продолжить выполнение плана, то есть делать кампании 6-13 из их начального списка в Тринадцать кампаний до FPF для инженеров последней мили (forward-deployed engineers): ailev — ЖЖ (нумерация там чуть изменилась), а именно:
- TGA в части “от принципов к работе”, и теперь граф понятным способом понимается как описание потоков, что важно для функциональной архитектуры.
- остатки архитектурных кампаний, и там ещё немало.
- остаток семиотических кампаний.
После этого в честь годовщины FPF (всё-таки 10 июня будет год с начала работы над этим проектом) я сделаю 28 июня 2026 года платный лекционный семинар “Итоги первого года разработки FPF как языка паттернов для смешанной работы людей и AI над проблемами в рабочих проектах”. На этом юбилейном семинаре я расскажу, чем стал FPF за первый год разработки: не “энциклопедией умных понятий”, а языком паттернов для совместной работы людей и AI-агентов над проблемами в рабочих проектах. Это будет не “краткий список изменений”, а обзор работы с базовыми сущностями: роли, работы, описания, обоснования, свидетельства, проблемы, решения, архитектуры, графы трансдукций, матаппараты, характеристики и шкалы качества. И даже “квантовоподобность” в менеджменте – когда “я только измерить хотел, только спросить, но почему они там все хором после этого уволились?”. Главное – как это всё использовать в конкретных рабочих ситуациях: что мы обсуждаем, какой объект хотим улучшить в ходе работы, какие описания этому помогают, где нужны измерения, где нельзя без архитектуры, как получить конкурентоспособное решение, а где надо просто перестать путать слова. FPF стал большой, 8.5M знаков, 235 паттернов на сегодня (а на момент проведения семинара будет ещё больше), в нём есть ответы на множество вопросов, которые вам не приходило в голову ему задать. Вот и расскажу, что обсуждать с AI-агентом, которому вы в помощь дали FPF. Всё это мелькало у меня в блоге, но на семинаре будет целостный рассказ с учётом всех многочисленных новинок последней пары месяцев.
И ещё я планирую сделать бесплатный часовой семинар именно по архитектуре в FPF, дату его объявим позднее.
А вы пока покопайтесь в своих проектных документах: надо ли вам исправлять semio-bias, не обсуждаете ли вы в них описания и описания описаний вместо того чтобы обсуждать реальные объекты из жизни? Не подменяете ли разговор о жизни разговором о текстах или диаграммах, отчётах и приказах?
