Заметки по FPF

cryptoemcee · 05.Январь.2026 09:53:07

(картинка взята из поста А. Левенчука потому, что она прекрасно отражает ключевую идею мышления с LLM+FPF)

В рамках подготовки к интервью с А. Левенчуком в рамках проекта экосистемы развития интеллекта мне необходимо ознакомиться с материалами про FPF в его блоге, начиная с лета 2025 года. Поскольку их до сотни, для этого на сессии стратегирования от 4 января 2026 года запланировано ежедневно инвестировать 4 часа в работы по переработке материалов блога практикой систематического медленного чтения с созданием заметок в Телеграм-боте МИМ. А поскольку заметок для моего понимания first principles накапливаются десятки в день, принято решение разбирать их ежедневно, чтобы не накапливалась критическая масса, с написанием такой вот заготовки. Гипотеза, что за неделю 2 года 2026 (с 5 по 11 января) мне таким образом удастся переработать материалы блога, инвестировав 28 часов, понять идею FPF и подготовиться к интервью с А. Левенчуком на неделе 3 года 2026. Апдейт: гипотеза подтвердилась.
Дополнительно читаются все попадающиеся под руку материалы единомышленников по тегу fpf или с аббревиатурой FPF в заголовке.
Кроме данной, за неделю написаны заготовки:
Философия FPF с пояснением ИИ. Часть 1
Философия FPF с пояснением ИИ. Часть 2
Анализ проекта с FPF
Readme к спецификации FPF: осмысление
О мастерстве на языке FPF
Добавлены ценные куски в https://systemsworld.club/t/moi-metody-fpf/28300
FPF - фреймворк, который представляет выжимку из руководств МИМ и предназначен для обучения ИИ агентов, чтобы они давали более качественные ответы. AI могуч, даёт на первый взгляд адекватные советы, но тащит в них всё подряд “попсовое”, ибо его задача – не говорить неприятную правду, а говорить приятные слова, и это будут обтекаемые мягкие формулировки из попсовых бизнес-книжек, болтовня из маркетинга, случайные «лучшие практики» двадцатилетней давности из случайных предметных областей. У FPF тут роль фильтра для всего этого приятного “бла-бла-бла”, он становится между AI-агентом и человеком, обеспечивая инженерную предвзятость (bias) для работы AI-агента. FPF работает ровно с этим: это архитектура мастерства сильного мышления. FPF вытаскивает из помойки субличностей LLM более-менее осмысленного инженера-менеджера.
Топовые LLM потенциально знают всё, но у них особенности характера. Пришлось изучить особенности характера: выяснилось, что невозможно работать с одной сеткой, надо обязательно с несколькими (и хорошо, что у меня был уже опыт работы с одной примерно так же устроенной бригадой соавторов). То, что можно поручить одной сетке, опасно поручать другой, и наоборот.
Если просто спросить сетку, то получите ответ прохожего с улицы, даже если этот прохожий будет нобелевским лауреатом в своей узкой предметной области. Нет, вам надо сначала жёстко ограничить сетку в том, как она думает. По большому счёту, задать ей основы рациональности. У нас есть руководство по рациональной работе, так вот там осваивается мышление по некоторой выжимке из интеллект-стека фундаментальных методов мышления. Отличие в том, что в этом курсе ничего выдуманного нет, всё это общечеловеческое знание. Но надо, чтобы сетка “включала мозг”, когда с вами разговаривает. Это не так-то просто, свелось к prompt engineering.
– … и дело пошло, в итоге получился .md файлик с кривым аутлайном, с кусками текста на двух языках (мне и сеткам было всё равно), с половиной ссылок на литературу, ведущих куда-то в никуда, но крайне любопытный и интересный. Его сегодня мы смотрели на встрече лаборатории рациональной работы, ибо по содержанию там материал системного мышления, а по методу работы – как раз рациональность (но и для части работы там тоже есть материал: жёсткое различение стратегии/Policy, планирования/ActionPlan и собственно действия/Action).
Руководство по системному мышлению — это прикладной практический и педагогический текст, нацеленный на формирование у инженеров и менеджеров конкретных навыков системного мышления для решения сложных задач в реальных проектах. Его язык — естественный, методология — эвристическая, а фокус — прагматический. Фреймворк (USF) — это формальный, кросс-дисциплинарный мета-фреймворк, нацеленный на унификацию научного знания через выявление функционально эквивалентных концепций в разных областях (термодинамика, биология, машинное обучение). Его язык — математический (теория категорий, HoTT), методология — аксиоматическая, а фокус — теоретический.
Система в её окружении как центральный объект анализа. Оба подхода отвергают простой редукционизм. Ключевой мыслительный ход — рассмотрение целевой системы (system-of-interest) не в вакууме, а в контексте её надсистемы и окружения. Эта идея — ядро обоих документов.
Оба документа признают иерархическую, многоуровневую природу сложных систем и наличие эмерджентных свойств на каждом уровне.
Оба документа отражают переход от «систем первого поколения» (где системы существуют объективно) к «системам второго и третьего поколений», где ключевую роль играют создатели и эволюционные процессы (система сама себя не создаёт; система в глазах смотрящего; созданная система постоянно развивается).
Оба подхода признают, что для адекватного понимания сложной системы необходимо несколько разных, но согласованных описаний (views).

Концепт из руководства	Аналог или формализация в USF
Целевая система в окружении	U.System, U.Boundary, U.Interaction
Системные уровни, эмерджентность	Scale-Map (функторы Σ, Π, μ)
Граф создателей, роли, агенты	Постулат Agent Externalisation, constructor systems
Техно-эволюция, «неустроенность»	Ключевые научные основания USF, U.ScaleConflict
Функциональное, конструктивное и др. разбиения	Domain-Projections, множество Views
«Чёрный» и «прозрачный» ящики	Концепция использования vs. Концепция системы
Мышление письмом, моделирование	Требование документирования, формальные модели

Универсальные примитивы (U-Types). USF стремится к созданию минимального, безмасштабного и аксиологически нейтрального ядра понятий, в то время как Руководство оперирует богатым, но предметно-ориентированным словарём (например, «инженер-менеджер», «концепция использования»).
«Руководство по системному мышлению» и «Unified Systems Framework» не являются конкурирующими подходами. Они представляют собой два разных, но комплементарных уровня описания системной реальности.
Руководство можно рассматривать как высококачественную, богатую и практически-ориентированную доменную проекцию (Domain-Projection) универсальных принципов, которые USF стремится формализовать. Оно представляет собой «инженерный срез» системного мышления. USF, в свою очередь, предоставляет теоретический и математический фундамент, который объясняет, почему эвристики и методы из Руководства работают и как они связаны с фундаментальными законами в других, неинженерных областях.
4-2 U.ScaleConflict. Межуровневый конфликт Конфликты системных уровней, «неустроенность". Оба документа, независимо друг от друга, приходят к идее о том, что конфликты между уровнями иерархии являются фундаментальным источником сложности и движущей силой эволюции, и оба ссылаются на одни и те же новейшие работы в области физики и биологии. Это самое сильное подтверждение их концептуальной общности.

Сжатие – это нахождение закономерностей/паттернов в огромном массиве данных о мире (токенов, квантов входного потока), чтобы представить их в более компактной, эффективной форме. Например, вместо того чтобы запоминать последовательность “1, 2, 3, 4, 5, … 100”, можно “сжать” ее до правила “ряд целых чисел от 1 до 100”. Это правило и есть сжатая модель данных. Сжатие это и есть моделирование, оно требует понимания. Чтобы хорошо “сжать данные” (“отмоделировать мир”: перевести мир в его описание, то есть данные, то есть выполнить замеры), нужно понять их структуру. Чтобы предсказать следующее слово в осмысленном тексте, нужно кроме грамматики и контекста ещё что-то знать о мире, ибо текст является какой-то моделью мира (в том числе, возможно, моделью воображаемого мира, например, моделью поведения математических объектов). Вот эта идея моделирования-сжатия-предсказания как раз центральная.
Отдельно надо упомянуть open-endedness как новацию “традиционного обучения”: одновременная генерация как данных, так и задач, так и архитектур с выходом на бесконечное саморазвитие агента (тут уж не LLM, а агент сразу). Ключевое тут: намеренное привнесение новизны (все бесконечно ищут stepping stones) и тем самым “жизненный цикл не заканчивается, пока есть компьют, то есть жизненного цикла нету, бесконечное развитие”. И тут выход в реальный мир и отсутствие проблемы “всё выучил, новой литературы нет” (data engine, “горшочек, вари”), наука с проблематизацией goldilock и потом решением самосозданных проблем вся тут, робототехника с выходом в физичность и тем самым grounding тоже тут, “AI, который себя улучшает” (liftoff) тоже тут. Мне эта open-endedness важна, чтобы подчеркнуть “иную культуру”, другое мировоззрение: как и в нашей мастерской инженеров-менеджеров, у этого направления нет “продукта в конечной форме”, “готовой версии модели”, ибо агенты там постоянно развиваются, “нет жизненного цикла”, бесконечное развитие и акценты на “решение проблем” другие, “решение очередных проблем, завтра проблемы будут потруднее”. Прохождение бесконечной игры с регулярными боссами в конце игрового уровня, игра не кончается (пока справляешься с боссами, конечно), а боссы десятка уровня назад кажутся тебе очень лёгкими (но когда эти проблемы решал, ничего лёгкого, конечно, не было). Никакого “завтра расслабишься, победил”, наоборот – “победил, теперь всё будет труднее!”. Вот надо это брать, разворачивать тамошние идеи – и строить нашу людскую культуру бесконечного развития, ибо в текущем варианте lifelong learning ничего конкретного нет, кроме лозунгов “вечного обучения”, а ведь надо уметь рассказывать и про принципиальную важность новизны, и про goldilock трудность задач, и про генератор задач и генератор решений, и про “проблемы будут всегда, в этом и смысл”, и про stepping stone, и про “люди – универсальные объяснители” как самая универсальная (пока) вещь на свете, и т.д.
Основная там у всех проблема – это резкая деградация качества ответов по мере роста чата. Если даёшь переписать три абзаца – на выходе один абзац “переписанного”. Если у тебя список был из 20 понятий, то на выходе - 15, а на вопрос “куда оно усохло” ответ “ну, там похожие были, я объединил. А ещё надо быть лаконичным, я сократил”. Так что удержание внимания и памяти промптингом – это и есть наш главный prompt engineering. С остальным потихоньку разбираемся, но главный приём тут – пригласить в команду экспертной панели роли, знакомые с интеллект-стеком (логика, онтолога, эпистемолога и т.д.), а учёному секретарю дать в его искусственные зубы точную инструкцию. Дальше надо отслеживать, чтобы нежить работала пошагово, а ей на каждом шаге давать промпты типа “Продолжай по одному объекту из нового их списка, следуй строго инструкции” иногда заменяя его на “Приведи план очередного шага работы с учётом инструкции. Какие объекты надо будет обработать?” (объёкт, конечно, надо специфицировать. Скажем, у меня объект – это понятие). Контекст контекстом, но там внутри очень жёсткие ограничения на число выдаваемых токенов, и если выдача чуть больше этого ограничения, то неестественный интеллект банально сократит весь хвост из, например, 10Кзнаков в пару предложений. Если понимать, что тут никакие промпты не помогут, то будет всё в порядке. Ну, и инструкция остаётся слишком далеко от начала диалога, её банально забывают (там какое-то скользящее окно “реального контекста”), поэтому рекомендуется напоминать.
Чтобы сообщество мастерской инженеров-менеджеров могло делать собственные эксперименты. Главный из этих экспериментов – это брать Руководство, а затем задавать вопросы по собственному рабочему проекту, задавая достаточный для ответа контекст, но с опорой на методы мышления руководства. Конечно, чтобы проверять работу LLM, надо и самому знать содержание загружаемых руководств! А вопросы задавать не по улучшению самих руководств (это мой рабочий проект), а по собственным рабочим проектам, это полезнее. Формула действия инженера-менеджера: Руководства МИМ + собственные рабочие проекты + LLM/FPF.
Ещё одна всплывшая тема – это неизбежность “галлюцинаций” у нейросеток. Мой тезис в том, что с людьми ровно то же самое. При этом политкорректно говорить, что люди не выдумывают/галлюцинируют, а заблуждаются, у них misconception, неправильная концептуализация. Поэтому людей надо из их заблуждения вывести. Мой пойнт в том, что и AI надо не ругать, а вывести из заблуждения. Но дальше упираемся в недообразованность (неумении нежити думать), что решается претренингом и RL разного вида — и вот эта недообразованность к нам и поступает, и нам “базовое образование” нежити недоступно ввиду запретительно высокой цены самой процедуры и закрытости топовых моделей. Поэтому нам доступно только попытки “чуть-чуть доучить” через prompt-как-manual в результате исследования. Чем и занимаемся: наши инженеры-менеджеры, которые проходят стажировки с наставниками, все нам сообщают, что стали лучше срабатывать и с людьми, и с нежитью — после освоения методов мышления из наших руководств. Лучше дают промпты, в том числе “дообучают” этими промптами: и людей, и нежить.
Эксперименты показали, что без внешнего по отношению к LLM контуру обработки текста – никак, LLM всегда обманет.
Мне хорошо известна предметная область, в которой я работаю. Онтология, эпистемология, системное мышление - всё это довольно редкие дисциплины, но у меня в них неожиданный многолетний опыт. И когда LLM делают ошибки, то я их быстро замечаю: это ровно те же ошибки, которые делают большинство наших стажёров, когда они осваивают работу по руководствам. И я примерно понимаю, как объяснить стажёрам и AI-ассистенту, что надо учесть, чтобы такой ошибки не делать. А ещё это означает, что на автомате проверяется доводимость всей это “теории” до практической пользы в работе. И это работает. Поэтому работа продвигается относительно быстро: делаю всё то же самое, только автоматизирую. Моё “несправедливое преимущество”, ибо LLM похожи на всех остальных людей, с кем я имел дело в ходе “генерального консультирования” (по факту - содержательного руководства группой консультантов в каком-нибудь большом проекте типа отраслевой реформы или реформы крупного предприятия, их там было у меня множество таких проектов в моей карьере консультанта), а также в ходе научного руководства ШСМ/МИМ и даже наставничества наших инженеров-менеджеров. Все ошибки - те же, что у инженеров-менеджеров, поэтому я их быстро замечаю и быстро отлавливаю. Так что дело происходит даже быстрее, чем я ожидал.
Ожиданная неожиданность: переработка интеллек-стека “первых принципов”, проводимая сама “от первых принципов”. Как я пришёл к необходимости работать над интеллект-стеком фундаментальных методов мышления? Напомню мой маршрут:
– надо обновлять руководство по инженерии личности, но там нужна посадка на естественнонаучную понятийную базу;
– поэтому берём системное мышление и делаем его апдейт, “унифицированный системный подход”, куда включаем унификацию по ряду предметных областей (от термодинамики до системной инженерии, а learning sciences там только один из примеров). Дальше предлагаем AI предложить структуру оглавления для Руководства по инженерии личности;
– текст про унифицированный системный подход быстро разросся до полноценного фреймворка, при этом значительная часть его оказалась посвящена эпистемологической динамике (это ж всё про системы, описания систем и их взаимоотношение, а также про то, как мы унифицируем разные описания систем из разных предметных областей – что там считаем конгруэнтным, хотя термин поначалу был “функционально унивалентным”, конгруэнтность появилась позже). Поэтому проект был остановлен, когда объём текста стал примерно 85Кзнаков;
– следующий текст был про унифицированную эпистемологию, надо было описывать динамику (изменения) эпистем, определяемых по всем знакомой линии “синонимов с нюансами”: знания/теория/онтология/доказательство/алгоритм. Конечно, кроме проблемы формального описания конгруэнтности, немедленно всплыли старые боли, прежде всего - это мереология эпистем. Мы говорили много лет про идеи Kit Fine, но ничего не делали. А тут начали делать!
– дальше попытались разобраться с унификацией как таковой: кроме системного подхода и эпистемологии нам нужны какие ещё фундаментальные (безмасштабные, то есть одинаковые на каждом уровне композиции и трансдисциплинарные, то есть приложимые к предметам опять таки на разных уровнях мереологической иерархии) методы мышления? Дальше появился формальный FPF (First Principles Framework), где первые принципы понимались по факту как upper ontology, “элементарные понятия/концепты/типы”, до которых происходит декомпозиция обсуждения самых разных ситуаций - с последующей возможностью что-нибудь пересобрать, “исходя из первых принципов”.
– дальше договорились (кто договорился? Я и две нежити под моим чутким руководством), что будет формальная спецификация FPF в виде kernel про то, как оно там всё устроено, фреймворков (FPF как “фреймворк фреймворков”) вроде системного подхода и той самой эпистемологии, только их там оказалось штук семь разных - и ключевой принцип их выделения был в наличии объекта с иерархической композицией (вроде системы и эпистемы), а также фасет - обсуждение каких-то характеристик универсальных декомпозируемых типов, но сами эти характеристики устроены не иерархично, они не безмасштабны. По факту это результат работы методолога: содержание знания, которое потом будет использовано для научения людей, компьютеров и AI, и которое как-то формально проверяемо на полноту и непротиворечивость. В отличие от классических upper ontology, излагаемых в виде FOL knowledge graphs, тут изложение идёт в трёх лексических регистрах: на естественном языке (“для менеджеров”), операторном математическом языке (“для инженеров”), в языке теории категорий (“для спецов по формализации”). И ещё дополнительно в виде файлов для разных tools (скажем, YAML-файлы, чтобы можно было проверять compliance со спецификацией FPF из коробки). FPF получается унифицированием знания, раскиданного как в академической литературе (вроде понятия “эпистема” или “мема” как “эпистема с нюансом”), так и просто путём нахождения конгруэнтных объектов в разных предметных областях по мотивам процедуры, продемонстрированной в работах типа ванчуринской со товарищи таблички конгруэнтности понятий из термодинамики, теории эволюции и теории машинного обучения из статьи Thermodynamics of Evolution and The Origine of Life;
– дальше работа методиста: целевым тут является получение интеллекта как мастерства мышления по фундаментальным методам, описанным в kernel, фреймворках и фасетах FPF. Мышление определяем по методам, разложенным в стек (интеллект-стек фундаментальных методов мышления), а вместо “учебные материалы” говорим о guides, приспособленных для понимания людьми и мышление о которых осваивается в ходе какого-то curriculum, предусматривающего обучение. Это два объекта: Intellect Stack (методы мышления, входящие в интеллект и организованные в виде стека), а также их описания - Intellect Stack Guides. FPF же служит формальным методическим ядром, позволяя иметь самые разные curriculums и наборы Guides для изучения методов мышления интеллект-стека, которые все основаны на первых принципах.
Текущим результатом можно и похвастаться, и наоборот. Вот он, ужас-ужас-ужас онтологических Нью-Васюков (хорошо помним, что лет тридцать назад модно было иметь собственную upper ontology каждому университету, затем двадцать лет назад это было модно иметь для группы университетов и обязательно “на OWL” или “на Common Logic”, лет десять назад это полностью вышло из моды ввиду “непонятной полезности этой адовой ручной работы” и переключения внимания с knowledge graphs на deep learning и нейросети, а сейчас эту унификацию приходится специально обосновывать. Скажем, Our contribution is not a new set of facts or laws about the world. It is a practical, engineering-grade toolkit for thought that empowers you, the expert, to do your work more effectively. This toolkit consists of three concrete components:

A Common Language (The U. Ontology): We provide a rigorously defined, yet intuitive, vocabulary of first principles (U.System, U.Objective, U.Reliability, etc.). This is a “lingua franca” that allows a physicist, a software architect, and a business strategist to communicate about complex system dynamics without losing precision.
A Universal Checklist (The FPF Modules): The structure of the Intellect Stack itself serves as a powerful diagnostic and design tool. It provides a systematic checklist of questions that forces you to consider any problem from multiple, essential perspectives: What is the system (USF)? How good is my knowledge of it (KDF)? What is the best method to act (MDF)? What is my ultimate goal (NOF)? This prevents cognitive blind spots and ensures a holistic analysis.
A Set of Actionable Methods Description (The Guides & Playbooks): We provide concrete, step-by-step procedures for applying these principles. Our guides are not philosophical treatises; they are operational playbooks that teach you how to model a system, how to assess the quality of evidence, how to structure a rational decision, and how to resolve goal conflicts.
In short, we are not trying to build a single, grand cathedral of knowledge. We are providing better **scaffolding, architectural blueprints, and interoperable power tools for all the builders, no matter which part of the cathedral they are working on. Our goal is not to replace the expert, but to supercharge them—to transform deep specialists into more effective, T-shaped professionals who can seamlessly collaborate to solve the complex, interconnected challenges of our time.

Одна из задач проекта - определить именно понятийный минимум, first principles, дать основания почистить наши разбухшие текущие Guides, а также показать пути модуляризации (те же фреймворки и фасеты как вариант).
Всё это, конечно, интересно только по линии программы исследовательского развития. Те, кто интересуются рабочим развитием – им надо интересоваться позже, “прийти на готовенькое”. Исследования в этой области требуют быть хотя бы чуть-чуть полиматом (скажем, уже как-то одолеть материал текущего руководства по интеллект-стеку фундаментальных методов мышления). Делать FPF - запредельно сложно, слишком много предметных областей, из которых происходит дистилляция/сжатие знания. А программа рабочего развития наоборот: берёшь совсем немного знания из руководств (они уже готовы!) и быстро-быстро применяешь в конкретном проекте. Это как с беспилотным автомобилем: чтобы он управлялся простыми командами “отвези меня в парк потрогать траву”, этот автомобиль должен быть довольно сложно устроен, разработчики должны попотеть и решить множество проблем. И чем больше они проблем решат, тем проще будет потом управляться с таким автомобилем. А есть пользователи, их не волнует сложность устройства и сколько там проблем приходится решать инженерной команде. Их волнует, чтобы было проще пользоваться. Так вот этот текст и вся эта работа с командой нежити – она не должна быть интересна “пользователям”, это интересно только исследователям и инженерам интеллекта (целевого для наших Руководств). Остальным можно этот текст проигнорировать.
Эта работа (context engineering, она же артигогика, она же “настройка AI для использования в проекте через промпты-manuals” (обо всём этом я писал раньше, и давал ссылки), если ей заниматься full time, оказывается очень похожа по общему ощущению и стилю на программирование: надо втолковать компьютеру то, что надо втолковать, добившись хоть как-то безошибочного исполнения. Только программирование не классическое, а нейролингвистическое (привет старым нэлперам! которые про естественный язык, но который идёт прямо в мозг для обработки, а не который идёт в компьютер), что сути не меняет.
Общая архитектура спецификации “фреймворка фреймворков” первых принципов, намётки по составу фреймворков и фасетов. Прояснение отношений фреймворка и руководств как результата методологической работы и методической (instructional design) работы при примате общей целевой системы: интеллекта с его работой по методам фундаментального мышления.
Обсудили на методсовете также конкурентоспособность мастерской инженеров-менеджеров. Всё-таки к AI-лихорадке мы готовились довольно долго, просто ждали, пока AI-агенты не станут достаточно умны, чтобы реально помогать нам в работе. Для понимания mission и vision надо читать текст Церена Церенова Наши конкурентные преимущества в эпоху всеобщей “ИИ-лихорадки”. Но важно не только куда идём, но и стратегия и планы того, как туда попасть. Кроме почти двухчасового обсуждения на методсовете я выдал в чат методсовета ещё и большой пост с тезисами, а к посту ещё и чеклист. Мой личный срочный проект сейчас в этой стратегии направлен на закрепление “инженерного” и “естественнонаучного” начала: посадка всех наших руководств и материалов на первые принципы (то есть доработать FPF и отследить, чтобы это был минимальный набор понятий, чтобы не затесалось туда что-то прикладное). После этого (хотя это можно уже и сегодня делать! Черновики-то уже есть) можно проверять все наши тексты и руководства на предмет соответствия — например, не перебарщиваем ли мы с метафорами вместо реальных объяснений или не проникает ли в тексты мифологическое мышление. И там же ходы на как-то обоснованную модульность FPF, а следствие — модульность наших руководств и программ стажировки. Цель - сообщество носителей гибридного (человеко-машинного, киберличности) интеллекта. Интеллект – это часть киберличности (личность человека плюс AI-экзокортекс, хотя любая из этих частей может отсутствовать, просто людям и просто AI интеллекте не отказываем), представляющая собой мастерство мышления по интеллект-стеку фундаментальных методов. Интеллект используется для изменения мира к лучшему в коллективных проектах. Мы делаем следующее:
– меняем мир к лучшему (по-крупному, с прицелом на сферу Дайсона и переходы типа цивилизации по Кардашёву: “от сердца - к Марсу”, ага).
– для этого делаем сообщество инженеров-менеджеров как киберличностей с сильным интеллектом, оно и меняет мир к лучшему.
– для сообщества готовим из личностей “простых инженеров-менеджеров” киберличности инженеров-менеджеров с сильным интеллектом
– для получения сильного интеллекта делаем описание его методов мышления (FPF, first principles framework, результат методологической работы) прямо для AI-части киберличности, а для человека - описываем через guides (результаты методической, instructional design работы по материалам методологической работы).
– опционально и потом: усиливаем интеллект прикладными skills.
Именно интеллект-стек помогает отличать фрагментарную эрудицию от мышления, «чтение статьи» от реального понимания, «работу в проекте» от системной роли в нём.
Фреймворк первых принципов (FPF, first principles framework) задаёт фундаментальное мышление, исходящее из первых принципов. FPF постулирует, что в мышлении важны универсальные и унифицированные типы объектов (U-Types), которые позволяют избежать ошибок в мышлении и действии. Универсальность означает применимость к разным предметным областям, унификация - сведение некоторого разнообразия типов объектов к одному типу путём выделения самых важных особенностей. FPF разворачивает на базе FPF универсальную мыслительную кухню.
Откуда взяты U-типы в FPF? В отличие от умозрительной (аксиоматической) философской работы, которая лежит в основании большинства верхнеуровневых (top/upper/foundational) онтологий, онтология FPF получена наблюдением паттернов в лучших образцах человеческого мышления (например, системного подхода из физики и инженерии, эпистемологических теорий, теорий типизации). Эти элементарные паттерны мышления не были выведены, они были сформулированы на основе обобщения данных наблюдений в качестве догадок-постулатов. Эти догадки-постулаты по поводу U-типов и их отношений остаются фальсифицируемыми/опровергаемыми, то есть вполне может появиться класс проблем, где FPF работает плохо – тогда можно ожидать, что они будут изменены или их число будет увеличено. Но пока фальсифицирования не произошло, предполагается, что всё остальное знание будет выводиться уже на их основе. Это совпадает с определением первых принципов: что-то такое, что не раскладывается уже дальше на части, невыводимое, но известное до попадания в ситуацию (в естественных науках это знание обозначают ab initio). Альтернативное понимание задал Ричард Фейнман в своей знаменитой цитате: “The first principle is that you must not fool yourself - and you are the easiest person to fool”. FPF поддерживает ровно этот тезис Ричарда Фейнмана: первый принцип – не обмануть себя в мышлении.
И фреймворк первых принципов (FPF), и классические верхнеуровневые онтологии (BFO, ISO 15926 и т.д., сегодня это часто верхние уровни графов знаний, knowledge graphs) позиционируют себя как универсальные унифицированные языки для самых разных предметных областей, но их подход к тому, что же там “универсально” и “унифицировано” - разный. Универсальность и унифицированость классической верхнеуровневой онтологии оценивается по возможности проверить логическое соответствие разнородных фактов в согласованном внутри себя наборе данных, чтобы добиться ответа на вопрос “какие объекты нас окружают”, “что есть в окружающем нас мире”. Универсальность и унифицированость FPF оценивается по возможности проверить логическое соответствие разнородных ходов мышления каких-то интеллектуальных агентов (людей или AI) следованию каким-то ходам мышления, чтобы убедиться о том, что подумано обо всём, о чём хорошо бы было подумать. Проще говоря, FPF задаёт то, как вы думаете, “что надо найти в мире и что об этом подумать”, а классические верхние онтологии говорят “какие объекты бывают в мире и как их обозначать”. FPF задаёт познавательную полноту мышления о мире (каждый рациональный ход “цель – метод - доказательство - план - действие” представлен и эти ходы согласованы между собой), а классические верхние онтологии задают логическую непротиворечивость и строгие типы данных для подобного описания. FPF тоже содержит онтологию верхнего уровня (набор универсальных и унифицированных типов объектов, U-Types), но он оптимизирован не для того, чтобы объединять разные “базы данных” или “базы знаний”, а для решения проблемных ситуаций в разных предметных областях. Никаких таксономий объектов в FPF нет, ибо они важны для разных предметных областей и вполне могут формулироваться в соответствии с какой-то верхней онтологией. Скажем, FPF говорит: “думайте о системах, а также агентах-создателях этих систем”. Но таксономии “системы – оборудование – насосы – поршневые насосы” там не будет, её надо будет брать внешнюю. Зачем нужен тогда FPF? В ситуации с поршневым насосом FPF говорит “поршневые насосы - системы, думайте об агентах-создателях поршневых насосов”. Верхняя онтология позволит точно описать поршневые насосы, FPF позволит точно подумать о том, о чём надо подумать, чтобы снизить вероятность проблем в мышлении и действии в ситуации с поршневыми насосами, если уж вы занимаетесь именно ими. Онтологии - это про то, “что существует”, FPF - про то, о чём следует думать и что следует делать.
И FPF с его “онтологией, исходящей из первых принципов” и классические верхние онтологии (они же верхние уровни графов знаний) дают «минимальные фундаментальные понятия», но в FPF его онтология направляет мышление, а в классических верхних онтологиях организует описание. Какой-то граф знаний, поддерживаемый его верхнеуровневой онтологией, предоставляет знания “что там есть в ситуации” — хорошо типизированные факты о насосах, белках или политиках. FPF направляет на поиск знаний (их ёще может не быть, это placeholders для важных знаний, “пустографка”) о “почему и что дальше”, заставляя ещё и найти недостающие для заполнения этой пустографки “что”. FPF говорит: сформулируйте свою цель (U.Objective), оцените надёжность (U.Reliability) доказательств, выберите или придумайте метод работы (U.Method), составьте план задействования ресурсов (U.Resource) для работы по этому методу. Наличие U-типов из FPF означает, что интеллектуальный агент (человек или AI, или киберличность человека+AI, или даже организация) может переходить от любой импортированной из предметной области онтологии (в которой есть, например, поршневые насосы, но нет шнековых насосов) к рассуждениям о проблемах (чаще всего проблемы будут “на стыках”, междисциплинарны, они не в самой предметной области). FPF упорядочивает мышление, фокусируя его на потенциально самых важных объектах - которые как раз и маркируются U-типами из онтологии FPF. FPF даёт элегантность (“ничего лишнего”, lean) мышления, а классические верхнеуровневые онтологии – элегантность таксономии как иерархического представления знаний об объектах мира, что делает удобным учёт этих знаний. FPF не навязывает собственный граф знаний, но умеет использовать внешние графы знаний, оценивая их формальность, надёжность и общность так же, как и любых других знаний/теорий/доказательств/алгоритмов/описаний (унифицированный тип “эпистема”, U.Epistem). Но даже не это главное. Главное тут, что FPF увязывает эти внешние графы знаний с текущей проблемной ситуацией: спецификация FPF рассказывает о том, зачем вам надо лезть в эту внешнюю базу знаний, что там искать в предметной области из того, что потенциально поможет решить проблему. FPF сознательно отказывается от подразумеваемого расширения в сторону отраслевой иерархии объектов (middle ontology): таксономия — удел графа знаний, тогда как FPF — навигатор мышления, совместимый с любой из таких таксономий.
FPF имеет своей целью интеллект как мастерство решения самых разных проблем, а интеллект оперирует двумя представлениями/representations знания: локальными/символьными представлениями разных регистров формальности и распределёнными/нейросетевыми представлениями, у которых про “форму” и “формальность” говорить трудно. Руководства превращают спецификацию FPF как доступную для изучения и следования ей только гениями (людьми и AI) в удобоваримое для изучения и следования ему описание мышления сильного интеллекта. Спецификация FPF гарантирует строгость, руководства гарантируют понятность (по энциклопедиям и справочникам не учатся, им не следуют в работе. Руководства не надеются на то, что знание из спецификации как-то непосредственно применимо в работе без дополнительных разъяснений: руководства учат использованию этого знания, обогащают материал спецификации примерами использования, примерами неправильного понимания, объясняют последствия неиспользования. Руководства добавляют полезность спецификации, причём как для людей, так и для AI-агентов, равно как и для их гибридов (киберличностей: людей, использующих AI-агентов). Но руководства не добавляют новые U-типы, это делается спецификацией. При этом руководства вполне могут существовать в некотором разнообразии для разных применений, например, делать упор на применение спецификации FPF на каком-то одном уровне формальности. Спецификация FPF одна, но могут быть разные наборы руководств. Например, может быть один набор руководств для обучения подростков сильному мышлению, а другой – для знакомства с сильным мышлением выпускников математических факультетов ведущих вузов.
Фреймворк первых принципов нормативен: он задаёт мыслительную норму, заставляет так думать. Спецификация FPF - это “как надо”. Руководства по задаваемым им интеллект-стеку фундаментальных методов мышления служат не только и не столько учебным материалом, сколько регламентами сильного мышления, избегающего ошибок. Верхнеуровневая онтология описательна: она запрещает противоречивые классы, но не говорит, надо ли этот класс вообще вводить. Верхнеуровневая онтология даёт возможность различить разные унифицированные сущности, а FPF не только предписывает какие сущности следует различать (например, System, Objective, Method), но и предписывает, в какой момент проекта ими нужно оперировать, иначе чек-лист мышления о проекте считается непрошедшим, доверия к результатам мышления нет. Верхнеуровневые онтологии вообще не озабочены проблемами доверия к каким-то знаниям, FPF прямо вводит шкалу надёжности знания (U.Reliability) - это одна из уникальных его особенностей. U.Reliability заставит различить инженерную эмпирику с результатами замеров от ссылок на художественную литературу как источник обоснования. Верхнеуровневая онтология такими градациями по шкале надёжности знания не располагает — для неё все факты после отсутствия логических проблем равноправны по своей надёжности, нельзя разобраться, насколько этим фактам можно доверять.
Я спросил у трёх AI систем, что в FPF и руководстве по системному мышлению из идей общее, что разное, а в чём они по составу идей отличаются.
Вот что пишет Grok-4:
Концептуально совпадающие идеи в обоих документах
– Определение системы: В обоих текстах система представлена как универсальный конструкт, состоящий из частей с отношениями, приводящими к эмерджентным свойствам, с акцентом на физическую реализуемость и применимость через домены (физика, инженерия, биология).
– Границы системы: Общий акцент на необходимости четкого определения границ для обеспечения объективности и предотвращения самоотсылок, с использованием внешнего агента-наблюдателя.
– Отношения и взаимодействия: Оба описывают отношения как типизированные (с арностью и направленностью), с примерами из реальных доменов, подчеркивая их роль в формировании системного поведения.
– Эмерджентные свойства: Эмердженс объясняется как результат агрегации частей, с универсальными примерами из физики (например, термодинамика) и биологии (фитнес в эволюции).
– Первопринципы: Определяются как недеривируемые, универсальные концепты, проверяемые через проекции на несколько доменов (не менее трех), с отсылками к пост-2015 подходам в физике и AI (например, конструкторная теория Deutsch-Marletto 2015–2021).
– Роли в системном мышлении: Роль системного инженера как мастера структуры реальности, интегрирующего универсальные методы для моделирования систем.
Вот что пишет о3 Pro:
Концептуально совпадающее ядро
– Граница системы. Оба текста настаивают на том, что первую операцию системного анализа — чёткое отделение «самой системы» от окружения. FPF описывает это через универсальный тип U.Boundary 𝔅 и сопровождающий аудит потоков . Руководство даёт почти то же требование в методическом разделе о «выборе границы командой-создателем».
– Физическое отношение «часть-целое» и иерархия уровней.** FPF формализует шесть строго типизированных отношений (ComponentOf, MemberOf, …) и вводит масштабные свёртки между уровнями k → k + 1 . Руководство столь же подробно разбирает «истинные части» и необходимость подниматься от части к целому (breakdown / надсистема).
– Потоки как носители взаимодействия. В FPF потоки проходят через формальные порты, а агрегирование на границе подчиняется инвариантам сохранения массы/энергии . Guide трактует поток как «объект с постоянством пути», показывая его на DFD‑/гидравлических схемах.
– Многоуровневая модель и явление эмерджентности. FPF рассматривает «RG‑flow» — последовательность агрегирований, где на уровне k + 1 появляются новые свойства. Guide связывает рост сложности и появление уровней с принципом минимизации свободной энергии.
Итоговое наблюдение исследователя
Несмотря на разные цели документов (машинно‑проверяемая спецификация против обучающего руководства), их концептуальный пересечённый набор устойчив: границы, физическая мереология, потоки и многомасштабность. Различия заключаются в формальном уровне фиксации (автоматически проверяемые контракты в FPF) и в социотехнической перспективе (роли, стоимость и лингвистическая чистота в Guide). Уникальные элементы обоих текстов могут быть взаимно усиливающими: формальные инварианты FPF способны стать «инженерной обвязкой» для практик continuous‑evolution, а подробные лингвистические и ролевые чек‑листы Guide — снизить риск семантических ошибок при внедрении строгого агрегирующего фреймворка.
Уже к концу 2025 года пользоваться нежитью для исследований будут все. Это неудивительно: качество ответов калькулятора при умножении десятизначных чисел никого почему-то не удивляет, почему должно удивлять качество ответов при “перемножении” десяти предметных областей? Можно предпринимать уже прямо сейчас очень сложные научные и инженерные проекты с опорой на коллектив из нежити. Не ждать, пока у тебя будут деньги на организацию лаборатории.
В системном подходе довольно много школ задействовало эту интуицию – и системное мышление понималось как мышление о системах как структурированных объектах, независимо от их физичности. Но эти рассуждения были “менеджерские”, абсолютно нестрогие. В FPF мы под это кладём более-менее формальное основание, строгость/formality вырастает. Можем ли мы говорить, что FPF – это системное мышление? Можем, если считать физические системы и эпистемы – системами: физическими и знаниевыми. Можно даже избежать этой терминологической путаницы и говорить не о “системах”, а о “холонах”, хотя путаница всё одно останется: это будет всё одно системное мышление, которое будет во многом одинаково про холоны, но таки потом всё равно будет специализироваться для физических систем и для эпистем, а потом всё равно специализироваться для конкретных видов систем (авиалайнеры и чашки) и эпистем (теоремы и художественные описания исторических событий).
Какое мышление задаёт фреймворк первых принципов? Архитектурное? Инженерное? Системное? Общее фундаментальное? Итак, мы можем говорить, что даже в текущем недоделанном виде FPF – фреймворк для архитектурного мышления (и это легко дотягивается до инженерного мышления: акцент на изменении мира, а не просто на описании, и тут что инженерия физических систем, что инженерия знаний оказываются во многом похожими), для системного мышления, накрывающего не только физические системы (акцент на исследованиях, понимании мира – очень многими системное мышление описывается не как мышление действия агента-создателя, а как мышление системного моделирования). Я когда-то пытался говорить о текущем варианте системного мышления для инженерии (а не только для моделирования мира) как о системноинженерном мышлении. Потом это распространил на менеджмент (инженерия организаций), потом на инженерию личности (обучение) – и снял этот термин, как путающий. Но внешние люди могут не догадываться, что у нас вполне деятельный, а не только моделирующий/аналитический вариант системного мышления, поэтому путают системное мышление в целом с системным анализом и подчёркивают его разницу с архитектурным в частности и инженерным в целом мышлением. И LLM это радостно высказывают в своей критике. Зачем всё это надо? Затем, что можно “вынести за скобки” вот это архитектурно/инженерно-системное мышление, выучить его один раз, затем выучить небольшие специализации для (сейчас видно шесть типов) холонов – и далее пользоваться везде. А разве это не осуществляется уже сейчас в текущих Руководствах для инженеров-менеджеров? Да, конечно, но с оговорками:
– про эпистемы говорится очень мало, их -ilities вводятся “на пальцах”, динамика практически не рассматривается;
– мышление про системы и эпистемы разделено, хорошо проработано и изложено главным образом для физических систем;
– речевой регистр всё-таки больше “для менеджеров”, нет чёткой формализации “с математикой”.
Получается, что у нас три типа знаний (и три типа мышления):

Знание о том, как устроено знание о мышлении и методы мышления на его основе (kernel и мета-архитектурное/безмасштабное знание про целые и части как холоны и мышление о них, включая общие характеристики вроде характеристик модульности и указаний на функциональность). Сюда же относим cross-cutting facets;
6 видов безмасштабного/фундаментального/архитектрного знания о том, как устроено мышление об отдельных типах холонов с разными подтипами отношения части-целого (системы для ComponentOf, эпистемы для ConstituentOf и так далее), они определяются отдельными фреймворками, эти фреймворки описывают только отличия (специализации) общего мета-безмасштабного/фундаментального/архитектурного мышления. Тут тоже могут быть cross-cutting facets для отдельных типов холонов (системы, эпистемы и т.д.) и их важнейших/архитектурных характеристиках;
Прикладное (domain) знание, которое не безмасштабно/фундаментально, применимо на ограниченном числе уровней агрегации и композиции. FPF занимается первыми двумя видами знания о мышлении, а также показывает на стык с прикладным мышлением, которое остаётся вне его описаний.

У нас же в FPF главная цель - поддержка мышления, “не пропустить главного, отмоделировать главное”, а не “моделировать всё, что захочется моделировать”. Надо управлять вниманием, управлять драгоценным мыслительным ресурсом: моделировать то, что надо моделировать. А что не надо моделировать – то не надо моделировать!
Мы уже умеем превращать AI в инженера-менеджера нашими “данными для контекста”/“сверхбольшим промптом-инструкцией”/“фреймворком первых принципов” – можно называть как угодно. Но там есть две особенности:
– чтобы говорить на равных с инженером-менеджером, надо владеть мышлением первых принципов и тамошней лексикой: когда тебе говорят “ты забыл о целевой системе” надо понимать, что это такое, чтобы оценить совет.
– AI сейчас делает ошибки примерно такие же, как делают наши стажёры, которые только-только начали осваивать интеллект-стек методов фундаментального мышления. Но с этим уже примерно понятно что делать: а) улучшать сам FPF, ибо даже выбор терминов больше значит для LLM, чем можно подумать, плохо подобранный термин сшибает кремниевый мозг напрочь, ровно как сшибает напрочь мясной мозг, но ещё б) мозг инженеров-менеджеров через год будет примерно тем же, а вот мозг AI-агента подрастёт, и результаты будут лучше.
Для понимания сути слов-слов-слов надо откатываться к первым принципам, самым элементарным мыслительным операциям, которые нужны ещё до того момента, как мы поняли предметную область.
First Principles Framework (FPF) — это не просто еще одна онтология, ещё один (даже не международный) стандарт или “процессная agile системная методология”. Это фреймворк, который даёт не только универсальный/нейтральный для разных прикладных предметных областей язык, “рабочий/нейтральный/унифицированный/общий язык первых принципов мышления”, но и указывает на то, о чём вообще стоит говорить.
FPF не заменяет текущие лучшие знаниевые фреймворки (онтологии, Agile, стандарты), а надстраивается над ними. Своды знаний (SEBoK, PMBoK) каталогизируют какие-то “лучшие практики”. FPF предоставляет трансдисциплинарный клей, который позволяет этим практикам из самых разных стандартов и из самых разных голов (не всё берётся из стандартов или постов в блогах замечательных людей, что-то люди в проекте придумывают сами!) работать вместе без противоречий, особенно на стыках архитектуры, организации и методологии. Поэтому “конкуренты” остаются на другом уровне, FPF тут трансдисциплинарен, “по ту сторону”:
– если вы опираетесь на онтологии, то они “описывают мир”, а FPF описывает, как мыслить о мире. FPF задаёт первичные принципы мышления о мире, предписывает искать какие-то объекты в мире, а не просто сообщает, какие объекты бывают и как их получше описать.
– если вы опираетесь на процессные инженерные стандарты, то забудьте про предметную суть вашей системы, там лишь общие слова (даже движение agile начинало с равной роли инженерного и менеджерского знания, а затем свалилось в “процессы” и чистый менеджмент, инженерия оказалась “за бортом”). FPF увязывает мышление и действие системы-создателя и поведение создаваемой системы (у которой мышление может и быть, например, мышление AI, но может и не быть – даже если это космический корабль).
– если речь идёт об архитектурных стандартах, то у вас не будет ни онтологий, ни общего хода инженерного процесса. FPF отлично справляется с архитектурой, которая по определению вынуждена работать на стыках с самыми разными инженерными специализациями, а в силу закона Конвея ещё и стыкуется с организационной архитектурой. И ещё FPF поддерживает нарождающуюся роль прикладного методолога, которой пока никто не озабочен. А ведь “прикладность” в крупном проекте тоже междисциплинарна!
– если речь идёт об общем интеллекте, то вас научат физике-математике - а с тем, как работать, будет опущено. FPF вполне дружит с физикой и математикой, но не останавливается на этом. С ним можно и в исследования (например, в эволюционную биологию eco-evo-devo), и в работу и даже в личное развитие.
– что делать с AI, который крайне мультидисциплинарен, не говорится вообще нигде. FPF тут поддерживает вот эту мультидисциплинарность: вы можете подгрузить FPF искусственному интеллекту, и вы обсудите сложные вопросы “на стыке дисциплин” на одном с ним языке. К мультидисциплинарной команде это тоже относится: вы подгрузите в головы членам команды FPF (сейчас ближайшее к нему приближение – это руководства по программе рабочего развития), и дальше сможете с командой обсуждать проблемы “на стыках” на одном общем языке. И, конечно, это “минимальный язык”: первые принципы, которых не так много.
Метафор для FPF можно придумать много: это и “мышление оркестратора мультидисциплинарных проектов”, и “операционная система мышления для совместной работы множества прикладных процессов мышления и деятельности”. FPF задаёт “чек-лист мышления”, поэтому проект не теряет цель, обоснования, ресурсы, конфликтов системных уровней, и всё это даже на стыке дисциплин — там, где классические онтологии, процессные и архитектурные стандарты, инженерные корпуса знаний молчат о «почему» и «кому доверять». Первые принципы - это ab initio, “до опыта” (погуглите или спросите у AI-агента), то есть “до входа в проект”: зная первые принципы из фреймворка, вы будете уже знать о проекте и о том, как действовать в проекте ещё до момента первого с ним знакомства. И это позволит сориентироваться в проекте раньше других, вы будете конкурентоспособны даже внутри команды проекта! FPF не выполняет работу за вас, но усиливает вашу способность управлять неминуемой проектной сложностью, задавать правильные вопросы (чек-листы!) и принимать быстрые, обоснованные и проверяемые решения. В мире, где цена ошибки из-за недопонимания между командами может стоить недель, месяцев или даже лет работы, FPF предлагает страховку в виде ясности мышления и общего языка, общей для команды картины мира.
Cетка не видит своих ошибок в мышлении точно так же . как их не видит ученик! она сразу же нарушает промпт и выдаёт чушь. Поэтому надо следить, хватать её за язык, даже если чушь уверенная. А для этого надо самому владеть мышлением и быть мастером, чтобы видеть ошибки.
Ещё пример - это рассуждение про “AI отберёт всё работу, а зарабатывать будут только крупные корпорации с нулём людей”. Исходят при этом почему-то из неявного тезиска, что сумма работ на планете постоянная. И если какие-то работы взяты, то работ становится меньше. Это же ни разу не так! Когда работу отняли у крестьян, люди пошли на заводы, когда заводов стало поменьше, пошли в офисный планктон, когда офисного планктона стало поменьше, пошли в маникюрную экономику (grooming), а дальше ещё что-нибудь придумается. Опять же, если за AI (как сервис) никто не платит, то его никто и не делает, даже AI-агент из их толпы будет ограничен в ресурсах. Калькуляционный аргумент Мизеса при этом до сих пор не фальсифицирован, так что работает и для AI-агентов. Если все без работы и без денег, то никто ничего не покупает, поэтому бизнесы обанкротятся. Ну, или AI будут покупать у AI, бизнесы не обанкротятся, экономика просто станет безлюдной, так вроде и сейчас бизнесы с очень небольшим количеством людей покупают много у бизнесов с очень небольшим количеством людей, но все они в конечном итоге пока работают на удовлетворение потребностей людей. У экономики нельзя раздельно обсуждать потребление и производство, при этом нельзя исходить и из того, что есть “баланс спроса и предложения”, равновесие. Равновесия нет, оно динамическое. При этом спрос и предложение только растут, общий объём производства только растёт (кризисы перепроизводства и последующие межотраслевые переливы капитала тут нормальное явление, длинного тренда не меняют), он не постоянный - это почему не обсуждается? Вот чего не хватает во всех этих рассуждениях “на коленке”, так это опоры на хоть какую-то теорию (скажем, праксиологию как “математику деятельности агентов”, над которой уже выстраиваются разные “физики” - экономика, право, социология). Да, можно образно сказать, что как физика (воплощение) надстраивается над математикой (описание объектов, априорное и аксиоматическое, а ещё можно приплести сюда геометрию с аксиомами), так экономика/под которой понимают экономическую историю прошлого и будущего надстраивается над праксиологией (априорной аксиоматикой, логикой человеческого действия) - и тут проблема псевдо-экономистов в том, что они понятия не имеют про праксиологию и тянут в качестве аксиоматики в экономическую историю математику, не зная, что методы естественных наук в науках о человеке неприменимы, так как объекты иные и имеют цели.
FPF (First Principles Framework) (статья В. Покровского) — это «операционная система для мысли»: набор простых правил, языка и паттернов, чтобы собирать целое из частей без потери смысла, измерять сравнимое, держать контексты «разведёнными» и повышать надёжность решений. Его задача — вернуть в работу первые принципы: что именно мы измеряем, в каком мире рассуждаем, на каком уровне и по каким правилам склеиваем выводы.
Open Ended Evolution: развитие без заданного потолка — баланс поиска (exploration) и доводки (exploitation), зондирование масштабирования, обновление решений по мере появления новых данных.
“Портфель решений” по Парето: нет “лучшего” решения, а есть их набор по качеству/стоимости/риску/сроку. Каждое решение лучше других по какому-то критерию. Нужно определить ключевые критерии и выбрать из фронтира под конкретный контекст.
С LLM FPF снижает риски галлюцинаций, но не обнуляет их: обязательны рамки, версии, инженерные обоснования. FPF даёт понятный «скелет мышления».
“Первые принципы” могут стать удачным ребрендингом интеллект-стека (пост Ц. Церенова по итогам семинара по FPF). FPF — это не ещё один модный ярлык, а рабочая операционная система для мышления и совместной работы с ИИ. Дальше — только развитие, портфельные выборы и новые правила масштабирования.
Промыслил пятнадцать подразделов спецификации FPF из основного файла с ИИ, чтобы врубиться в суть “первых принципов” ещё лучше. Понимание улучшилось, пост1 и пост2. Фактически, осваивается практика мышления с ИИ, но сразу правильно, с FPF.
Это не замена руководствам МИМ по программе рабочего развития, ибо текст не для людей, а для AI. При этом цели “совпасть с руководством” по идеям и терминологии не было, и это намеренно. Была цель получить решения лучше, чем это сейчас в руководстве (например, общее мышление для систем и эпистем, ход на конструктивную мереологию, поддержка speech act theory, более строгий механизм назначения ролей, процедура унификации и так далее). Сделать mapping для идей в наших руководствах, перетащить в FPF всё полезное; сделать обратный mapping идей FPF в руководства, перетащить из FPF в руководства всё полезное.
С июня 2025 ситуация в мире кардинально поменялась: появились сильные модели AI, которые начали выдавать сравнимые с людьми результаты в самых разных проектах. Эта “сравнимость с людьми” тут играет злую шутку:

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

Для олимпиад по математике, победами в которых хвастаются сегодня все крутые AI-модели, всё просто: там хорошо определённый предмет с уймой литературы, но эпистемический треугольник всего с двумя углами (ибо понятие и объект совпадают, аксиоматические “умозрительные” теории про идеальные/математические объекты с исключениями вроде экспериментальной математики). Для других проектов, связанных с физическим миром (инженерия) всё уже не так просто, и конгруэнтность (“приблизительную тожесамность”) понятия и объекта приходится оговаривать. Если тождество A=B в математике легко выводимо, то в физике для отождествления Утренней Звезды и Вечерней Звезды нужно иметь какие-то предсказательные постулатные теории, а ещё провести измерения. И ещё надо учесть множество масштабов рассмотрения. И ещё учесть много чего. Для беседы в реальных проектах должен выйти хорошо образованный AI-агент с нормально простроенным мировоззрением, а не просто instruct-версия, обученная на вопросах эзотериков про особенности астрологии и вопросах этиков про феминизм и защиту верований малых народов как движущую силу прогресса (ведь обучение нежити сегодня заключается главным образом в том, чтобы удовлетворить всех в рамках их же верований, если они “не нарушают закон”. Астрологи закон не нарушают!). Надо как-то задать набор “верований”, которым надо удовлетворять: естественнонаучную и инженерную SoTA картину мира. Написать manual/guide, по которому надо отвечать на вопросы, и часто даже не те вопросы, которые задают (“лечить симптомы”), а вопросы, которые в какой-то рабочей ситуации надо задать (вроде неприятного вопроса “а что там у вас целевая система, давайте разберёмся”, этот вопрос очень не любят, ибо чаще всего надо признать после ответа на этот вопрос, что проект или дохлый и деньги инвестора просто на него прокушиваются, или признать проблемы с этикой, или признать, что твоя собственная работа на результаты проекта влияет “никак”). Вот это SoTA мировоззрение, культуру современного сильного мышления можно получить, залив достаточное количество мегазнаков разных текстов в головы, чтобы полезного из окружающего информационного бедлама вынималось больше, а на вываливающийся на тебя информационный мусор ставились фильтры на уровне рефлексов. Сейчас в головы мы заливаем нашим инженерам-менеджерам примерно 8Мзнаков текстов руководств только по линии рабочего развития. Мой текст для context engineering будет тянуть где-то на 1Мзнак, ибо там не надо слишком сильно заниматься spaced repetition, нежить понимает всё чаще и чаще с первого раза (но не факт, может быть и надо повторять и повторять какие-то примеры, few shot learning).
LLM - это “помоечное мировоззрение”. А вот context engineering должен вытащить из этой помойки какое-то связное мировоззрение.
Моя (Левенчук) работа как раз про это: я вытаскиваю современное унифицированное системное мышление (и даже больше: холоническое мышление, ибо системное мышление с физическими системами там оказываются внутри него) , поверх него - инженерное мышление. И уж затем можно задавать “любые вопросы”, чтобы получить не любые ответы. Тот же подход, что с TLO (top-level/upper ontologies), только у меня не только объекты, но и методы мышления тоже, достаточно общие. Со всеми оговорками, что “универсальность в силу теоремы бесплатного обеда не слишком эффективна, но уж если вы попали в нужный класс задач, то она рулит”. Все разработчики TLO оговаривают, что классы задач не “все возможные задачи во вселенной”, но когда у вас будет мультидисциплинарный проект и надо будет как-то свести всё это растрёпанное знание вместе — придёте, никуда не денетесь.
Появляется новое, более умное поколение моделей нежити, а вот появления нового поколения более умных людей ждать не приходится. Более того, нежить есть шанс научить – она честно прочтёт тексты регламентов мышления, которые ей даёшь почитать. А людей научить мыслить “как надо”, а не “как всегда” шансов мало, ибо ты им никто и звать тебя никак. ОК, будем учить нежить. А желающих пообщаться с нежитью на эффективном языке сильного мышления, мышления из первых принципов, мы тоже научим. First principles framework как раз и посвящён этой задаче.
Никакая роль не существует сама по себе, вне контекста. Роли получают смысл только внутри своего U.BoundedContext. Например, роль «инженер» имеет определённый набор обязанностей и полномочий лишь в контексте конкретного проекта (скажем, Project Phoenix), но не по всему миру вообще.
FPF даёт “рельсы мышления” для AI и вас, чтобы результат был чуть более надёжным и получался чуть быстрей, чем без этих рельсов.
Контексты – это как «комнаты смысла», внутри которых правила, термины и модели считаются полными (посылка закрытого мира, CWA), поэтому можно принимать какие-то однозначные решения. Но при этом есть возможность обсуждать, что там не вошло в контекст (OWA), чтобы порассуждать и про это тоже – это просто будет рассуждение в другом контексте. Таким образом, FPF предлагает “рельсы мышления” для решения сложных задач с участием AI. Он не пытается превратить весь неопределённый мир в одну большую базу данных. Вместо этого он позволяет вам очерчивать чёткие границы (U.Boundary), внутри которых вы можете действовать с инженерной точностью и уверенностью (закрытый мир, CWA), при этом всегда осознавая, что за этими границами простирается постоянно меняющийся и полный открытий мир (открытый мир, OWA). Этот гибридный подход позволяет создавать надёжные системы, которые остаются гибкими и способными адаптироваться к новой информации.
По большому счёту, это очень похоже на DDD: вы приходите в организацию, в которой в каждой комнате говорят на своём особом рабочем сленге, исторически полученном из каких-то любимых в этой комнате регламентов, стандартов и BoK. А вам поручают сделать какой-то софт, который объединяет их всех. Вы начинаете с того, что строите софт-переводчик: пытаетесь определить для используемых в этих комнатах понятий нейтральные термины, которые конгруэнтны (“синонимы с нюансами”, то есть не полностью тождественны, но как-то похожи), хоть как-то понимаемые в разных этих комнатах. Вот U-Types (унифицированные) типы ровно таковы. В разных комнатах говорят про метод, культуру, способ работы, практику, деятельность, рабочий процесс, методологию и всякое такое, вам надо это отличить от работы, исполнения, прогона и их описаний, а затем обозначить каким-то одним термином, чтобы потом “практику” из одной комнаты отождествить как-то с “культурой” из другой. Весь FPF про это, это ведь и есть “междисциплинарность”. Унификация вполне себе рабочая задача. Всем ведь знакомы бесконечные совещания, где отделы говорят на разных профессиональных языках (часто они отличаются для разных практик: что у конструкторов “комплектующее”, то у закупщиков – “предмет поставки”), а “единое видение” и “единомыслие” реализуются только как “единоневидение” и “единонемыслие”. Любая попытка что-нибудь сделать в большом проекте будет иметь из-за вот этой “междисциплинарности” огромный “налог на коммуникацию” в каждой попытке договориться. FPF с его унификационной частью F – это ни разу не академическое упражнение в глубокомыслии, это вполне прагматичный инструмент снижения коммуникационного налога. Вы получите “словарь” и понимание, что там “вообще то же самое”, что “не совсем то же самое”, а что “совсем разное”.
Принцип 1. Радикальная локальность смысла — U.BoundedContext (“Комната смысла”).
Традиционный подход: неявно предполагает “глобальную истину”. Слово “процесс” или “роль” должно означать одно и то же везде, но правда жизни в том, что “кому должно?”, “кто сказал?”. Дальше на эту тему можно писать в Спортлото в надежде, что там помогут.
FPF: всякий смысл — локален. Нет глобальных терминов. Значение слова определяется исключительно внутри “комнаты” какой-то предметной области, в которой живут предметы этой предметной области и идёт их обсуждение (U.BoundedContext, тот самый, который из DDD. В онтологии это известно через подход CYC как “микротеории”). Это позволяет разрешать парадоксы: Плутон может играть PlanetRole в контексте Астрономия_начала_XX_века и DwarfPlanetRole в контексте Определение_МАС_2006. Граф Дракула может быть вампиром в контексте художественной литературы и вампиров может не быть вообще в контексте рационального мышления.
Связь между “комнатами”: осуществляется только через явные “мосты” (Alignment Bridge), которые заявляют уровень соответствия (Congruence Level - CL) и потери в семантике. Это раскрывает более содержательно и формально то, что мы называем в нынешних руководствах “синонимы с нюансами”, потери из-за “нюансов” можно явно обсуждать. И это же лежит в основе той унификации, которой я собирал из самых разных предметных областей текущий вариант мета-мета-модели из наших руководств.
Принцип 2. Строгое различение — Сущность/Entity vs. Роль (в том числе такая сущность, как Holon vs. Role). Традиционный подход: часто смешивает то, чем объект является, с тем, что он делает. Это приводит к “взрыву типов” (НасосОхлаждения, НасосТопливный). И тут же путаница “функционального” и “процессного” (мало кто её понимает, в том числе синонимию функционального и ролевого объекта).
FPF: жестко разделяет все сущности и холоны как сущности с определённой иерархией по отношению часть-целое, причём эти сущности считаем стабильными. Но есть контекстуальная (BoundedContext), временная (temporal window) роль. Насос — это конструктивно всегда насос (U.System). Но в контексте системы охлаждения он играет роль CoolingCirculatorRole. Это дает невероятную гибкость и поддерживает онтологическую чистоту. Роль — это “маска”, которую носит сущность в определенном контексте. Роль всегда в контексте, всегда на время, всегда связана с действием. Вася-инженер - это синтаксис, ибо инженер это “маска” Васи, абстрактный объект, это не сам Вася. Хотя более точно будет сказать Вася#ИнженерRole:ПроектТабуретки (и ещё добавить что-то про окно во времени: 2025 год, например. А хоть и склеить с контекстом в ПроектТабуретки_2025). И ещё роли складываются, на них некоторая алгебра (определены операции). Например, в контексте самостоятельности и принятия решений Вася-агент, а в контексте constructor theory Вася может менять какие-то другие объекты и не разрушаться при этом, Вася-преобразователь (transformer). Но это только во время окна во времени, когда Вася не спит. И да, холон-в-роли может бродить по графу состояний примерно как альфа в OMG Essence (у меня была догадка, что речь идёт о ролевом объекте, но там кривая онтология, а в FPF можно будет эту кривизну выпрямить, это RoleStateGraph, паттерн A.2.5).
Принцип 3. Причинная чистота — Внешний Transformer и “Никакой само-магии”.
Традиционный подход: допускает фразы “система сама себя настраивает” или “документ сам себя обновляет”, создавая причинные чёрные дыры.
FPF: никакой “само-магии”. Любое изменение (Work) всегда выполняется внешней системой, играющей TransformerRole (но не эпистемой, которая не может быть преобразователем, но зато может быть MethodDescription, описанием преобразования). Эпистема (знание) в FPF никогда не действует сама. Она пассивна. Но она может служить инструкцией/алгоритмом/руководством (MethodDescription) для активной Системы, играющей TransformerRole. Таким образом, мы сохраняем причинность: не ‘инструкция построила дом’, а ‘строитель построил дом, следуя инструкции’"
Рефлексивный раскол (Reflexive Split): если система действительно меняет сама себя (например, самокалибровка), FPF требует смоделировать ее как две части: регулирующую (система-преобразователь/transformer, а если это ещё и регулирование с планированием, то можно обсудить и систему-агента) и регулируемую (преобразуемую). Это снимает все парадоксы рекурсии, “саморегулирования”. Если брокеры “самоорганизовались”, то это означает, что какой-то из исполнителей роли брокера в каком-то временном окне, когда он не брокер, стал организатором сообщества – и организовал из брокеров биржу. Никакого “само”, у этого “само” всегда появляется фамилия, имя и отчество. В руководствах у нас это есть, но оно вот так не выпячено, а тут прямо таки важно. Вообще, у нас в руководствах система-создатель, а надо бы система-преобразователь (ибо “создаёт и развивает, в том числе просто меняет” – это и есть “преобразует”), явно ведь улучшение!
Принцип 4. Временная дуальность — время проекта (система в состоянии “задумана”, “делается”, но не работает) vs. времени работы системы (design-time vs. run-time), а дальше можно ещё говорить будет о методологическом времени, но это когда-нибудь потом.
Традиционный подход: часто смешивает чертёж (ах, чертежей уже и не увидишь, “старинная метафора”) с реальностью. Спецификация считается эквивалентной работающей системе (“я написал код программы, моя роль программиста на этом закончилась”).
FPF: вводит строгое разделение времени подготовки к работе системы (development/design time) и времени самой работы/прогона/work/run. MethodDescription (алгоритм) живет в design-time. Work (факт исполнения, актуальная трата ресурсов при работе по алгоритму) живет в run-time. Их нельзя смешивать. Это делает разрыв между планом и фактом видимым и управляемым. Вот тут это мало отличается от того, что у нас уже есть сейчас в руководствах. Переход между ними — это формальный акт (Observe или Deploy), выполняемый Transformer/преобразователем.
Принцип 5. Масштабируемая формальность — Лестница от наброска к доказательству (M-mode, “проектируем карандашом на салфетке” → F-mode, “доказываем строго и ещё проводим эксперименты”).
Традиционный подход: требует либо полной формальности с самого начала (что душит инновации, не допускает работать с гипотезами), либо допускает неформальность, которая не может быть верифицирована.
FPF: предлагает лестницу формальности. Артефакт может “созревать” от неформального наброска в M-режиме (Mental model) до формально верифицированной системы в F-режиме (Formal realization), не меняя своей идентичности, это некоторый аналог release train, похоже на прохождение графа состояния альфы в OMG Essence). Это позволяет сочетать гибкость и строгость. При этом отдельно будут ярусы/tiers формализации-доказательств (Working-Model и Assurance Levels), ибо release train может идти вообще “на авось”, но может и сочетаться с какими-то обоснованиями, это состояния Assurance case. Можно с обоснованиями поступать как хочешь, если знаешь, что делаешь: просто об этом надо явно сказать. Скажем, система может быть абсолютно неформальна, но хорошо работать (при этом мы можем быть не уверены, что это будет всегда). А может надёжность её быть строго доказана “в проекте”, но работать система не будет хотя бы потому, что ещё не сделана и не испытана.
FPF делает “мыслительный долг” (thought debt) видимым и управляемым:
– семантический долг: управляется через Alignment Bridges между “комнатами смыслов” (BoundedContexts) и CL (congruency level). Это все “содержательные недопонимания”, которые идут от того, что разные люди для разных целей говорят одинаково о разном и по-разному об одном и том же. FPF заставит об этом подумать, если не подумал – должок, если совсем не подумал – должок выставит тебя на счётчик.
– Онтологический долг: управляется через Strict Distinction, где нельзя путать объекты разных типов (роли с холонами, алгоритм с его работой, описание с описываемым объектом).
– Эпистемический долг: управляется через Epistemic Debt (об этом есть отдельный паттерн B.3.4 — Evidence Decay & Epistemic Debt) и Assurance Levels (verifiedBy и validatedBy; математика уверенности). Слова про эпистемы/знания выглядят умными, но должок этот накапливается незаметно: это когда вы продолжаете полагаться на старые доказательства, предположения или данные, зная, что мир вокруг мог измениться. Это “долг”, который вы берёте у будущего, предполагая, что ваше знание все ещё актуально. Со временем этот долг “накапливает проценты” в виде растущего риска того, что ваша система или теория уже не соответствует реальности. В 2000 году вы закончили вуз и ваши знания были более-менее ОК. Сейчас вы считаете, что они ОК, но это ведь не так: тогда вы учились довольно интенсивно, чтобы набрать эти знания, но за 25 лет старые знания выветрились, а новых в аналогичных объёмах вы не набрали. Да и знания надо не “вспомнить”, ибо они тоже устарели, а найти новые и изучить. Всё, эпистемический долг: уверенности в текущих ваших знаниях нет банально из-за того, что эти “консервы в мозгу” уже просрочены.
– Инженерный долг: управляется через Temporal Duality (надо сначала задумать, а потом таки сделать) и Canonical Evolution Loop: Operate (Run-time) → Observe (Run-time to Design-time bridge, performed by a Transformer) → Refine (Design-time) → Deploy (Design-time to Run-time bridge, performed by a Transformer) → Operate.
Поэтому я делаю FPF хотя бы на уровне прототипа: явные логические дыры, не до конца выверенная терминология, отсутствие каких-то объяснений. Это методологическая работа, формулирование трансдисциплинарного метода мышления, запись его спецификации на языке паттернов.

потом объяснить уже готовую спецификацию FPF, перевести в совместное мастерство работы человека и AI. Это методическая задача. Решать её надо потом, когда понятно, чему учить. Далее смотри предыдущий пункт, без него тут обсуждать нечего.
– объяснить, зачем этот FPF вообще вдруг нужен, чтобы озаботиться прохождением предыдущего пункта, для которого был нужен самый первый пункт. Грубо говоря, “продать”: если об FPF никто не узнает и никто им пользоваться не будет, то можно было бы его вообще не делать. Это предпринимательская задача, зачем.
То есть, сначала “зачем вообще нужен этот новый метод”, потом “что такое этот новый метод, в чём он заключается, каковы рабочие продукты”, а потом “как ему научить, чтобы человек, на входе не владеющий этим методом, на выходе владел им ,имел мастерство, создавал рабочие продукты”. Я для себя сам ответил на вопрос “зачем мне”, продал; сейчас я разбираюсь, что это за метод; и параллельно сам себе методист, овладеваю им самостоятельной работой.

Хотя кто знает наши руководства по программе рабочего развития может себе представить их переписанные формальным языком по канонам архитектурных паттернов, FPF вот это оно и есть. FPF сейчас - это OMG Essence + DDD на стероидах.
«FPF — это двигатель идей: как расширять фронтир, быстро пробовать, честно отбирать и доводить до сервиса — с прозрачным отслеживанием и явной статистикой» (привет, всё предприниматели).
Системы-создатели (в оригинале там constructor из constructor theory) становятся системами-преобразователями (ибо constructor выполняет transformations, значит он - transformer). Тут, конечно, есть разные варианты, в том числе и просто слово “трансформер”.
FPF — это не дескриптивная онтология (каталог “что существует”). Он не является атласом всех существующих ролей и методов. FPF — это генеративная архитектура для мышления. Он предоставляет паттерны, принципы и язык, с помощью которых вы (как U.Holon: Human-Engineer-Manager) можете создавать, описывать, анализировать и развивать новые U.Role, U.Method и U.Work, которые ещё не существуют или уникальны для вашего проекта.
Трюк с архитектурой будет в том, что она мыслится холонной, а не только системной. И там много интересных нюансов (функциональных объектов нет, вместо них маски-роли, поведение есть только у систем). И там же задача “изобретения”: подбора холона с необходимой для роли capability (aффорданс, “подходяшка”).
Отличие руководств МИМ от FPF:

различается форма: руководства это что-то типа учебника, где вопрос разжёвывается много раз и жирным шрифтом выделены важные положения. FPF - это “язык паттернов”, там приведён набор архитектурных паттернов мышления. Паттерны сгруппированы как паттерны ядра, паттерны холонической конструктивной мереологии, паттерны исчислений, паттерны логик, паттерны характеризаций. Языки паттернов удобны для архитектурной работы (а мы тут занимаемся архитектурой мышления), ими записываются архитектурные решения. Но они неудобны для освоения людьми. Особой популярности вне архитектурных кругов языки паттернов не имеют, ибо это что-то вроде википедии: отдельные статьи со ссылками на другие статьи, “энциклопедия принятых решений”. Руководства написаны как обычная книга из разделов, подразделов, с большим количеством разъяснений - путеводитель/guide разительно отличается от “сборника решений”;
различается лексика: в руководствах специально работалось с лексикой, чтобы исключать ошибки понимания при изучении. В FPF большинство терминов as is, лексика (за очень редкими исключениями) часто более-менее случайна или не адаптирована;
различается уровень формальности: руководство написано не слишком формальным языком, это обычный человекочитаемый язык со всеми его достоинствами (понятность) и недостатками (многозначность). FPF написан строгим формальным языком, и там смесь теории категорий, логики и канцелярита из стандартов с многочисленными MUST, SHALL и MAY, а также NOT в тексте. Значительное внимание в FPF уделено чеклистам, там в каждом паттерне по десятку-другому контрольных вопросов (в ADR принято решение, вот вам conformance checklist), сформулированных абсолютно формально;
различается онтология. В руководствах много говорится про системы, очень немного про эпистемы (описания), мереология эпистем не даётся, а онтология описывается как классическая многоуровневая классификация (в основе там “старый BORO”, ISO 15926-2, HQDM). Сам рассказ привязан к инженерным и менеджерским ситуациям, а набор понятий (основные типы и отношения) называется мета-мета-моделью. В FPF сразу речь идёт о конструктивной мереологии (новый радикальный конструктивный BORO, а также Core constructive ontology, ибо ключевые разработчики предыдущих упомянутых стандартов перешли на конструктивную мереологию с классической). Поскольку инженеры размышляют “в типах”, то эта конструктивная мереология (поддержаная теорией категорий) переводится специальным строгим образом в рассуждения об объектах и отношениях “как обычно”, и там задействуется классическая логика, но ещё допускаются и неформальные рассуждения. В любом случае, унифицированных типов (вроде сущности, холона, системы, эпистемы) немного, а дальше работает не столько механизм подтипов/подклассов, сколько механизм ролей - и вот понятие роли онтологически существенно отличается от понятия роли в руководствах. Вообще, в FPF всё привязано к понятию ограниченного контекста (boundedContext, как в DDD) и унификации понятий из разных контекстов (“комнат смысла”) со оговариваемыми нюансами. Это похоже на онтологический подход CYC с микротеориями. В руководствах говорится об онтологиях предметной области и ситуативной онтологии, классический механизм;
различаются знаниями, нужными для использования: FPF лёгок в использовании, если перед его использованием владеть работой по руководствам. А если не владеть – вы даже не поймёте, почему FPF так устроен и что он вам даст, чем может быть полезен, какие проблемы решает. Руководства начинаются с программы личного развития (если надо восстановить умение читать, думать, писать по паре часов в день, а не только “заниматься текучкой”), далее продолжаются программой рабочего развития (рациональная работа, системное мышление, методология, системная инженерия, инженерия личности, системный менеджмент), далее продолжаются программой исследовательского развития, которая и выводит на те проблемы, которые решает FPF. Лестница длинная, минимум на год, но она довольно пологая. FPF будет отвечать на ваши вопросы сразу, но на отдельные вопросы. А вот чтобы с FPF выполнить длинное размышление по проекту – вот тут надо иметь какие-то начальные знания, которые и дают наши руководства.

Описание семинара по FPF. Зачем идти? Чтобы за один день:
– Понять, как использовать AI для работы с большими сложными текстами. Вы увидите реальный кейс разработки и применения фреймворка объёмом в 3М знаков (примерно размер “Руководства по системному мышлению”) с помощью LLM и поймёте границы их возможностей. Если вам надо разрабатывать стандарты, регламенты, техническую документацию и вы хотите задействовать AI – это как раз пример такой работы.
– Получить новую версию языка для междисциплинарного разговора в рабочих проектах. FPF даёт унифицированный понятийный аппарат (роль, сервис, обязательство, доказательство, обоснование и т.д.), который позволяет инженерам, менеджерам, исследователям говорить на одном языке, устраняя дорогостоящие недопонимания и связанные с ними вечные переделки и исправления.
– Заново понять, что такое роль: с помощью “алгебры ролей” проще обсуждать самые разные контекстуальные и временные “ролевые маски” одних и тех же систем (например, Вася-агент, Вася-инженер и Вася-пациент это один и тот же Вася в разных контекстах и в разное время), это радикально упрощает проектирование сложных систем, как классических инженерных, так и организационных.
– Узнать про способы превращения творчества в управляемый процесс. Вы узнаете об эволюционных алгоритмах творчества, которые хаотическую генерацию идей превращают в дисциплинированный поиск сильных решений.
– Взглянуть на моделирование эволюции систем через динамику, глазами физика: траектория системы в многомерном пространстве её архитектурных характеристик (-ilities/-ости: надёжность, гибкость, доступность и т.д.). Проще будет прогнозировать и направлять эволюцию системы, “путь развития” будет именно путь (траектория), “скорость развития” будет именно скоростью (движения в пространстве архитектурных характеристик).
– Узнать про три мощных идеи наведения порядка в проекте: 1. Унифицированный (для претензий/claims, работ) механизм “охвата” (unified scope mechanism), формализация “границ применимости”. 2. Обобщение графов состояний альф OMG Essence до графов состояний ролей в FPF. 3. Конструктивная мереология для надёжной интеграции данных (уже используется в UK digital twin программе в строительстве, текущие работы BORO и Core constructive ontology, отношения часть-целое для единиц знаний становятся возможными).
– Получить представление об исследованиях мастерской инженеров-менеджеров. FPF – это не “серебряная пуля”, это пока исследовательский проект. Но он отражает SoTA современного фундаментального инженерного и исследовательского мышления.
Проблема информационных систем в целом, как показал “кровавый энтерпрайз”, оказалась не в хитростях алгоритмов “обработки данных”, а в кучерявости и запутанности данных, отражение предметных областей сложных предприятий в базах данных, моделирование данных. Вот этим “моделированием данных”, то есть семантико-онтологической и эпистемологической работой и занимаемся как при создании FPF, так и при помощи самого FPF.
Вот FPF работает в той самой зыбкой предметной области проблем (есть даже специальный паттерн “C.22 — Problem-CHR: Problem Typing & TaskSignature Binding”), boundedContexts (те самые из DDD), нестыкующейся терминологии из разнообразных “вертикалей” (silo), голословных заявлений (где непонятно, что там “в проекте”, что “сделано”, что “сделано, но не проверено”, что “только гипотеза”) и прочего месива, из которого растут рабочие проекты, а также R&D как фундаментальные, так и прикладные. Наши руководства рабочего развития более-менее успешно учат разбираться с этим месивом даже гуманитариев, а FPF с одной стороны учит разбираться с этим LLM, то есть представляет собой код экспертной системы, которая привносит культуру мышления в помойку мышления LLM. Хорошо, если у вас математическая задача: LLM сегодня отлично выдрессированы на математическую работу и на поиск ошибок в физических статьях или ошибок в химических формулах. А если у вас междисциплинарность, то как избежать того, что из мыслительной помойки вам не расскажут абсолютно системным языком какую-нибудь психоастрологию? И тут ещё поворот от “аналитики” как поиска ошибок и “глубокого понимания” к синтезу, к творчеству, к агентности и творческому началу. Как развернуть мысль не в критику, а “конструктивную критику”, где тебе предлагают не диагностику “вот тут у тебя ошибка”, а правку “вот надо сделать вот так, ибо у тебя тут не сработает потому-то, а с правкой сработает потому-то”? Вот мы наших инженеров-менеджеров на это нацеливаем, и FPF будет нацеливать туда LLM.
Инженеры-менеджеры в эпоху бурного цветения LLM будут учить уму-разуму (например, не полагаться на SoTA астрологию) не только своих живых сотрудников, но и нежить. Некоторые уже сегодня этим заняты. Вот это и есть фронтир, об этом и рассказываем (а мой проект по переносу культуры сильного трансдисциплинарного/фундаментального мышления в форме FPF – это демонстрация того, что мы что-то в этой сфере и сами можем, демонстрируем не рассказы, а работающий “код для LLM”, да ещё и разработанный при помощи этой LLM).
Ванчурин: “The future of fundamental research in physics lies with AI agents. We are on the verge of having tools that are genuinely useful for fundamental physics, and they will soon be developed. Either you learn how to use these tools, or you are out. 2. The amount of garbage generated by AI will grow exponentially. The hallucination problem is fundamentally impossible to eliminate, and the resulting mistakes could be difficult to detect. Either you learn how to identify and correct mistakes, or you are out”. Ну, и так далее, включая определение vibe physics примерно такое же, как vibe coding.
Вот мы ровно этим салатом из (системной) инженерии и менеджмента с выходом в R&D (формулирование проекта и его продукта, визионерство) и занимамся в мастерской инженеров-менеджеров. FPF тут – один из инструментов решения проблемы. И “обучением” тут не отделаешься, это цивилизационный сдвиг, это освоение другой культуры.
Холон - это просто целое, в котором есть части, но это целое само является частью другого целого. Так что холон - это просто участник отношений “часть-целое” с двух сторон. Роли - это “маска” для холона.
Многоуровневое всё, “первые принципы” всего лишь один из уровней. На семинаре будут рассказывать уже не только про первые (математика, физика, computer science) и вторые с третьими (всё прикладное) принципы, но и про нулевые (общие для первых принципов, которые разные для математики, физики, computer science). Вот короткий сильно сжатый списочек (сразу скажу, FPF весьма дыряв в поддержке этого списка, но кое-что там вполне поддержано):

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

В FPF cистемное мышление обобщалось до холонического мышления, общего для систем и знаний/эпистем, механизм ролей поэтому обновился, методология (role enactment) обновилась, в явном виде добавилось “творчество”.
Основное, что теперь поддерживается в FPF:
– часть G даёт управляемую фабрику SoTA-пакетов архитеорий: как собирать, пакетировать и публиковать наборы конкурентных методологических традиций внутри какой-то инженерной или менеджерской дисциплины с едиными правилами сравнения и выбором под задачу (selector в паттерне G.5).
– алгоритмы многокритериальной оптимизации NQD (новизна качество решений, и не одно решение, а набор решений, которые выходят на границу Парето). Выигрывают (доминируют) решения или чрезвычайно сильные по какой-то характеристике, или дающие уникальное поведение, которое не дают другие. Доминируемые (у которых выграли) решения выкидываются, не-доминируемые – победители, они остаются все, а не берётся только какое-то одно.
– теорема бесплатного обеда (которого не бывает, NFL, no free lunch theorem): постановка задачи общая, эффективное решение можно найти методом для какого-то частного случая. Сигнатура и реализации.
– дисциплина как семейство описаний методов, которые делаются различными научными и инженерными школами
– выбор эффективного метода, если он есть, переход к созданию нового метода, если его нет
– открытая эволюция (open-ended evolution) через одновременную эволюцию проблем и решений (всё это вместе будет OEE-NQD, ибо эволюция будет разбегаться на множество решений, оптимальных для своих ниш, это не “получение одного решения”).
– учёт “горького урока” (bitter lesson от Sutton и scaling laws из машинного обучения): если у тебя автономный агент, то от метода-предписания переходи к заданию правил-ограничений и бюджета, а дальше там пусть экспериментирует и эволюционирует.
Но потом оказалось, что системное мышление (мышление про части-целые и транс-системный переход) это только маленький кусочек базовых мыслительных конструкций, которые общи для многих и многих дисциплин, это первые принципы, но не все, и даже не самые общие (холоническое мышление как обобщение системного мышления – вот это уже ближе к реальным первым принципам). Вот явное проговаривание всего этого и стало одной из целей работы над FPF, почему я и выбрал такое название. Всё как полагается: надо уметь думать, а там тебе подвластны и физика, и математика, и биология, но также и новый рынок, новое предприятие, новая команда, новые жизненные обстоятельства.
“Первые принципы” – это те аксиомы и постулаты, пошевелив некоторые из них и применяя все остальные, мы можем получить новое знание, новое содержание научной традиции (скажем, заменить ньютоновскую механику на релятивистскую, классическую физику на квантовую, евклидову геометрию на риманову, а множество объявить отнюдь не начальной математической конструкцией, заявив “унивалентные основания математики”, как это сделал Воеводский). Это обратный ход на мышление о таких понятиях, которые лежат в самом основании огромного научного знания. Какие это понятия? Давайте послушаем, какие понятия звучат постоянно в речи “настоящих физиков” (которые “делают физику”, а не “применяют физику”), математиков, computer scientists. И попробуем выстроить мышление так, чтобы они опирались на похожие понятия, которые могут оказаться более-менее похожими для самых разных дисциплин и составляющих их научных традиций. Все эти “инварианты”, “симметрии”, “ренормализации”. Это то место, которое “обучение” переводит в “развитие”.
Обучение – это оптимизация в фиксированном пространстве задач, а развитие – это open-ended evolution (OEE) с портфельным поиском по новизне-качеству-разнообразию и illumination-подходами, при этом разнообразие заставляет находить новые и новые классы задач, а решения нужны на непрерывно двигающейся границе Парето, и выигрыш в неизбежной в ходе эволюции конкуренции – это сдвиг этой самой границы Парето, поэтому учитываем ещё и устаревание сегодняшних “лучших решений”. А ещё и bitter lesson оказывается связанным с этим самым развитием как ставка на простые методы, выигрывающие от масштаба, вроде той же эволюции, так что дальше можно разговаривать и про рыночную экономику против плановой, и agile с планированием on-the-fly против upfront-планирования проектного управления с классическим однократным жизненным циклом, и много что другое, включая то самое “однократное обучение” (оптимизация для заданного множества задач) против бесконечного/открытого/open-ended развития/эволюции.
Так что я с FPF затеял после интеллект-стека (акцент на сборку трансдисциплинарного мышления в интеллект) альтернативный ход: выявление этих самых первых принципов и концептуальный синтез правил мышления, основанных на этих принципах.
Принцип строгого разграничения объектов и их описаний, метода и работы – и самые разные другие принципы, при этом игнорируя принадлежность этих принципов к конкретным традиционным дисциплинам. Собрать такие принципы “под одной обложкой”, а поскольку я уже понимал, что читать такое никто не будет, то читать это должен был сразу AI. Вот это и есть First principles framework.
Про эти первые принципы на вчерашнем семинаре я рассказывал до обеда: какие именно принципы лежат в основе сильного творческого мышления, в том числе мышления физиков, математиков, computer scientists, и дальше всех-всех, кто занимается методами решения самых разных проблем. Мышление по первым принципам способно создать новую научную или инженерную традицию, новую школу мысли. Но вот этому как раз нигде не учат.
Ибо Эйнштейны ещё как-то будут требоваться, постановщики проблем будут требоваться, а “рядовые решатели проблем” – для этого есть AI, и вам ещё придётся организовывать их команду на решение проблем, побыть и в шкуре менеджера тоже. Для этого надо уметь мыслить не по каким-то методам, которым учат современные вузы (как учат в ПТУ, только в ПТУ учат работать по известным методам и с известными инструментами руками, а в вузах работать по известным методам и с известными инструментами, но только головой). Нет, надо будет уметь мыслить о работе с неизвестными методами с неизвестными инструментами над непонятными никому проблемам. Для этого откидываем огромный объём знания человечества – и переходим к трансдисциплинарному, фундаментальному мышлению, мышлению по первым принципам.
Самый краткий сегодня путь освоить мышление по первым принципам – это сначала освоить мышление по руководствам МИМ (по руководствам программы рабочего развития, ибо исследовательского развития без этого не одолеть, а личное развитие вообще про другое). Затем – познакомиться с интеллект-стеком, ибо там ещё написано более-менее по-человечески. И тогда появляется шанс разобраться с FPF, где про первые принципы говорится уже более явно и более концентрировано и в их более современном SoTA виде, чем в руководстве по интеллект-стеку.
LLM нельзя доверять, но можно рассчитывать, что она натолкнёт на какие-то свои мысли. LLM надо проверять, для этого надо хоть что-то уже знать самому! Поэтому FPF сам по себе вас не спасёт. Чудес не бывает. FPF – это инструмент для мышления, и нужно некоторое умение, чтобы им овладеть. Это умение даёт программа рабочего развития, без неё трудно.
Положение на шкале универсальности существенно связано с уровнем онтологии (foundational, upper, middle, domain-specific). В текущих руководствах программы рабочего развития онтологию мы называем “моделью” и там сразу появляется модель, мета-модель, мета-мета-модель как раз для трансдисциплинарности и мета-мета-мета-модель для обсуждения самой онтологии как таковой. Сейчас, после опыта работы с FPF, я мог бы назвать мета-мета-мета-модель “первыми принципами”, самыми базовыми и универсальными. Аксиомы, постулаты, измерения, сравнения, инварианты и прочее “самое общее, элементарное, откуда вырастает всё остальное”. Вторые принципы - это мета-мета-модель, наши руководства МИМ главным образом прописывают этот уровень универсальности моделей/онтологий/“картин мира”. Третьи принципы - это мета-модели каких-нибудь учебников, отраслевых или даже корпоративных стандартов. Это очень условное деление, тут хорошо бы иметь шкалу вот этой “универсальности”, “числа мета- для модели”, “трансдисциплинарности”, “номера принципов” – уж как ни назови. Первые принципы интересны тем, что они а) меняются, они не вечны, б) списков их обычно нет, в) они используются при построении предмета, а дальше “пользователям предмета” их знание особо не нужно, г) до прикладности там ещё одна полочка знаниевой многоуровневой этажерки, и такую многоуровневость надо много тренировать, перевопринципное мышление мощнее “обычного прикладного”, но и труднее. Мир, модель, мета-модель, мета-мета-модель, и где-то вот тут эти самые “первые принципы”, из которых можно строить разные мета-мета-модели (например, писать руководства для инженеров-менеджеров).
Журналистом тогда и блогером/инфлюенсером сейчас я не хочу быть, это легко может выполнить довольно много народу, так что с “распространением” я был бы аккуратней. Было бы что очевидно распространять, а уж распространители найдутся.
– “Породить новое” – на каком уровне? Атомы у всего “нового” инженерного одинаковые, кварки – тем более. Со знаниями то же самое. Оказалось, что я а) методолог, занимаюсь методами работы в целом и методами мышления в частности, б) неплохо справляюсь с унификацией, онтологической работой, в) могу делать какие-то сборки-гармонизации в методах, г) намечаю какие-то ходы на методики, то есть довожу до руководств и даже курсов (но это не шум в атмосферу по “распространению”, это дозревание знаниевой семечки до полноценного плода, который способен дальше выжить в каком-то новом месте: кто-то его съест с аппетитом и перенесёт знанием семечки куда-нибудь подальше, увеличит ареал).
– мощные идеи да, контринтуитивные – да, но жизнь показывает, что они лежат на много уровней мета-моделирования вверх, и самые мощные идеи тут - это идеи по порождению и оформлению других идей. Эпистемология, математическое и физическое мышление в основе знаниевой эволюции, разбирательство с культурной эволюцией и т.д. И мы приходим к тем самым первым принципам именно в этой точке. Самые умные люди используют понятие инварианта и симметрии, а вот кто попроще - не используют. Кто не использует - они работают на прикладных уровнях, в стабильном мире устоявшихся SoTA знаний, их novelty - прикладное. А вот меня тянет куда-то к истокам, я вечно иду по цепочкам графов создателей к самым начальным точкам. По любой речке графа создателей вверх (к инструментарию, а также инструментарию создания инструментария), от любой границы целевой системы - вверх по уровням.
– насчёт “людей” в 2007 году можно было говорить, а также замечать шёпотом, что я и в сообщество экстропианцев входил когда-то (буквально, входил в списки рассылки), и трансгуманист по убеждениям и вообще радикал в плане “не обязательно гуманист”, а за разумную жизнь, природу которой можно порассматривать (понятно, какая природа: экосистема, open-endedness, это лучшее знание про жизнь на сегодня). Так что я “за благо/эффективность всех живых веществ” (веществ, а не существ – это просто обобщение, существа ведь вещественны, а вот насчёт белковости – не факт).
– насчёт “достижения цели”, так это bias, человечество зациклено на “целях” и “целеполаганиях”. Сейчас у меня триггер на слово “цель”, ибо там оказывается то выход на портфолио решений на границе Парето, то open endedness с его “вечным развитием”, то ещё что-то такое же, проблематизирующее саму идею целеполагания. Вся дискуссия на тему “настоящего искусственного интеллекта” как раз про это. Какая такая цель получить термоядерную энергию, если сама идея термоядерной реакции вам в какой-то момент времени может быть неизвестна?! Поэтому “помогать достигать целей” – это неверная постановка вопроса, “помогать развиваться” (то есть помогать бесконечно выбирать проблемы для решения и решать их) тут много лучше.
– то есть при чтении по-диагонали вроде бы ничего особенного не изменилось, но по факту изменилось вообще всё.
В любом случае, “первые принципы” где-то в центре текущих интересов, и FPF тут только неожиданно найденная форма выражения, форма каталогизации и записи, форма ведения методологической работы (язык паттернов с докрутками для “мышления моделированием” – это как раз один из интереснейших форматов для выражения результатов методологической работы).
Задач по линии “первых принципов” по факту три:
– методологическая, как сделать неявные первые принципы явными, то есть найти и описать.
– методическая, ибо никаких способов обучения мышления по первым принципам на сегодня нет, разве что иногда отдельным их видам, но не всем вместе. Ну, можно стать подмастерьем (пойти аспирантом к профессору), но и это не гарантия.
– популяризационная (как минимум, начальная часть этой работы, до момента получения устойчивой популяции, а стадию “захвата мира” проигнорируем). Мало говорить и уметь учить, надо обязательно “плодиться и размножаться”, ибо эволюция – удел популяций. Нет популяции – нет эволюции, эволюционирует не одна особь. Так что надо как-то стартовать процесс, это моя задача. А вот вести-сопровождать “распространение идей” – это уже не ко мне. Вот этот мой “Лабораторный журнал” это лабораторный журнал, хотя и публично доступный. Это не “рупор первых принципов”. По большому счёту, вот эта популяризационная задача вполне выполняется моей работой в МИМ, мои семинары как раз по этой линии.
Документ получается уникальный: можно читать глазами и чесать затылок, но можно скормить LLM. На текущее поколение людей надежды в том, что текст прочтут глазами больше сотни человек на планете – нет. Но вот что текст возьмёт нежить и будет по нему действовать – надежда есть. Уже сегодня FPF как фреймворк наносит непоправимую пользу нашим инженерам-менеджерам.
– FPF как средство автоматизации мышления по первым принципам, “модулятор мышления LLM”, привноситель культуры мышления в мышление LLM-дичка. Мышление по первым принципам как раз и должно приводить к NQD появлению новых (N - novelty) полезных (Q - quality) и разнообразных (D - Diversity) решений.
– FPF это хорошая “семечка” для размножения мышления по первым принципам, это не так чтобы суперплотная ДНК этих “мощных идей”, но и не полноценный “образовательный плод, со всем необходимым для обучения первым принципам”.
Отдельная линия работ тут ещё по втягиванию SoTA из руководств в FPF. Так, предыдущая попытка втащить материал первого раздела “методологии” провалилась (она была короткая, много времени не потерял): FPF был ещё недостаточно мощным для такого шага. Но я планирую с этим продолжать. И то же относится ко всем руководствам: там много материала, которого в FPF ещё нет, но хорошо бы, чтобы был. Руководства ещё очень рано списывать со счетов, это пока главный результат моей методологической (и в последнюю пару лет методической) работы. Они ни разу ещё не устарели, и даже многие идеи, которые развёрнуты были в FPF, там уже намечены (скажем, конструктивная холоника от Kit Fine вполне упомянута как “наше светлое будущее”. Просто это светлое будущее потихоньку уже наступает, но в руководствах оно вполне представлено!). А если нужны первые принципы – то сначала руководства, а затем приходите за первыми принципами, это ещё на ступенечку выше, “исследовательское развитие”. Руководства исправно делают своё дело и весьма современны (так, в них нет “людей”, но есть “агенты” и это люди и AI, и ещё там нет “жизненного цикла”, а есть непрерывное развитие системы, инженерный процесс и эволюционная архитектура, а ещё вполне современный состав инженерных ролей. Так что всё вполне рабочее, последним допискам там существенно меньше года.
И к этой же теме отношу культуру сильного мышления: то ли это культура мышления из первых принципов, то ли умения непрерывно учиться, то ли культура бесконечного развития, то ли выживания в ходе эволюции (язык эволюции – язык жизни и смерти, как же иначе?), то ли просто инженерии, менеджмента, исследований на базе всего этого (прикладная культура). И как её замерять (бенчмарки?), как показать результативность (замерять?), как сравнивать (comparability frame для культуры/традиции). Это культура МИМ, надо научиться о ней говорить.
Разные роли делают что-то, исходя из своих онтологий, своих узкопрофессиональных мета-моделей, а результаты как-то склеиваются в жизни, при полном сопротивлении сторон. Договариваются же ровно потому, что контекст один и тот же и можно наложить две классификации/таксономии/“понятийные решётки”/“онтологические описания” на одну и ту же реальность: ткнуть пальцем в “это жёлтое”, чтобы другой сказал “звезда”, а ещё кто-то “Sun”. Так и тут: в жизни что-то происходит, тыкаем пальцем - и один раз об этом же рассказываем как об “обучении”, а другой раз как о развитии. Делаем какие-то предсказания (проектируем), воплощаем проекты в жизнь, а для точности понимаем, по какой из концептуальных линий надо идти, чтобы предсказания поменьше расходились с жизнью (правила применимости).
Ну, и это я точно первыми принципами занимаюсь. Это точно продолжение моей работы по интеллект-стеку: идея про “всё сидит на математике-логике, связано с физикой и физичностью мира, а занимаемся мы инженерией и менеджментом”. Это точно продолжение моей работы по системному мышлению, ибо оно оказывается только небольшой частью общехолонического мышления, прихватываем ещё и эпистемы. Это точно продолжение моей работы по методологии, ибо вот это principled enactment - это и есть ход “от математики и рассуждений к действию по изменению мира”.
- Путь «от принципов к работе» как пример потока. Пройдём на примере по шагам:

математика → на выходе формализм;
онтология → семейство понятий;
характеризация → семейство характеристик;
физика/механизмы → семейство методов;
замер условий среды и выбор конкретного метода → метод работы;
планирование работы с учётом ресурсов → план работы;
выполнение работы по плану → результаты работы;
замер результатов работы (возврат к началу цикла).

P2W (Principles-to-Work) — это не просто аббревиатура. Это один из фундаментальных механизмов FPF, позволяющий нам, как инженерам-менеджерам, эффективно переводить высокоуровневые стратегические цели и основополагающие принципы в конкретные, исполнимые и измеряемые действия (U.Work) . Это наш GPS для навигации от абстрактного видения к ежедневному исполнению. Промпт: “Распиши P2W из E.TGA в FPF для моей ситуации: <>”
Cross-Scale Coherence (Согласованность между Масштабами) — это один из ключевых столпов FPF, который напрямую отвечает на вопрос: как убедиться, что “правда” на одном уровне системы остаётся “правдой” на другом, будь то мельчайшая деталь или вся организация целиком? Cross-Scale Coherence — это не просто красивый термин, это архитектурная гарантия того, что наши системы, данные и понимание о них будут оставаться истинными и согласованными, независимо от того, насколько глубоко мы в них погружаемся или насколько высоко мы поднимаемся в их абстракции. Это основа для построения по-настоящему надёжных, масштабируемых и управляемых систем.
LLM вынуждена каждый раз следовать указаниям FPF, заставляющим её учитывать контекст и удерживать смысл понятия внутри одного контекста. Современным LLM это крайне трудно, они сбиваются даже с FPF (я рекомендую использовать ChatGPT Pro и Gemini Deep Think, чтобы это было полегче), но без FPF эти LLM просто идут вразнос – на выходе у них не просто убедительный набор слов ни о чём, но набор слов с уплывающим смыслом. Общая предвзятость FPF сдвигает рассуждения (reasoning) LLM в инженерную сторону.
Чтобы облегчить разговор, надо выбрать терминологию. “Если на клетке со львом написано “осёл”, не верь глазам своим”. Менеджеры часами мучаются, подбирая удачные названия. Программисты подбирают идентификаторы. Делают они это как поэты: по чистому наитию. В паттерне F.18 FPF описано, что считается хорошим именем самых разных сущностей – ролей, программ, подразделений, систем, рабочих продуктов. Можно попросить LLM+FPF дать имя, которое не будет вызывать неточности в использовании, клетки со львом получат свои надписи “лев”. FPF задаёт чёткий SoTA регламент выбора имён: откуда брать имена-кандидаты, по каким характеристикам их сравнивать, как выбирать парочку для разных целей.
LLM+FPF не панацея, не философский камень, не магия, не будет работать за вас
Инженер-менеджер, использующий LLM+FPF, остаётся главным, ибо если “инженера-LLM” никто не зовёт, то он и не выйдет. FPF не обладает магией, которая превращает инженера в оператора кнопки “сгенерировать отчёт”. Именно инженер, а не LLM+FPF должен уметь сформулировать, чем занимается проект, какие ограничения недопустимо нарушать, какие стандарты считать обязательными, что считать успехом проекта: какие характеристики важны, по каким индикаторам будем смотреть успешность, какие компромиссы допустимы. И в конце концов именно инженер-менеджер должен довести всё до реальных действий: до кода, схем, договоров, оргрешений, изменений процесса. LLM вместе с FPF рук, ног, голоса не имеют, они не проявляют собственной агентности-активности, они лишь снимают часть рутинной работы: помогают придумать варианты, структурировать аргументы, оформить словарь, набросать цепочку “от принципов до задач”, проверить догадки. FPF в этом месте нужен не как ещё одна философия из их множества, но как инженерный способ сделать LLM более рациональной, сильнее и чище, чем vanilla LLM. Идея в том, чтобы вытащить наиболее мудрую часть LLM, а “попсовую” часть заглушить, отфильтровать, не пустить в ответы. FPF уменьшает словесный шум, повышает долю явно задаваемых характеристик и критериев приёмки результата, снижает вероятность неприятных сюрпризов при переходе от текста, который всё стерпит, к настоящей работе в физическом мире. Если у вас уже есть LLM в продуктах или внутренних инструментах, следующий шаг — не придумывать ещё пятьдесят хитрых промптов, а решить, какой стиль мышления вы считаете правильным для своих задач, оформить его в явную архитектуру объектов, характеристик и принципов, и подложить эту архитектуру под модель как отдельный слой. В моём (Левненчук) случае эту роль архитектуры мастерства сильного инженерно-менеджерского мышления играет FPF, который используется как слой-фильтр между всеохватной vanilla LLM и человеком. FPF нужен не для того, чтобы “LLM думала за нас”, а для того, чтобы LLM перестала быть просто ещё одним говорящим попсовым интернетом. FPF даёт возможность получить для LLM понятный, проверяемый и воспроизводимый инженерный стиль мышления и действия.
МИМ занимается добавкой интеллекта как мастерства сильного/фундаментального/системного/инженерного (и так далее – подставьте сюда сами всё хорошее) мышления как в нейросетки людей (программы развития, что личного, что рабочего, что исследовательского), так и в нейросетки не очень людей (FPF, 80% содержания там совпадают с содержанием наших программ развития, это всё про первые принципы, фундаментальное мышление).
Разобраться с тем, как текущие руководства переползают на онтологию FPF. В чём-то эта онтология лучше, “первопринципней”, SoTA по сравнению с онтологией из наших текущих руководств. Но в чём-то FPF ещё отстаёт от руководств. В целом 80% материала там совпадают, но в руководствах много больше разного прикладного, а в FPF зато “выполнимость в LLM” (но и “невсовываемость в голову”). Вот это и надо будет решать, и достаточно оперативно. Пока план мне (авторы четырёх других руководств имеют другой план) опережающе развивать FPF, а не руководства: руководства вполне свежие, поэтому сначала осваиваем мышление и деятельность по ним, а затем уже поймёте, что там в FPF. Без руководств – нет шансов разобраться, что там в FPF, если вы не гений (а вы точно не гений, хотя и очень умный, никто не спорит, но без руководств, включая руководство по интеллект-стеку фундаментальных методов мышления, разобраться с FPF – всё одно без шансов. Использовать FPF можно будет в рамках выученного десятка заклинаний, но это другой уровень возможной пользы от FPF, “филейная часть мудреца”).
Цепков: “Различие между эпистемами – математическими объектами, которые специфицируют методы мышления , и системами, которые относятся к физическому миру. Ранее эпистемы как предмет математики не были понятийно выделены таким образом, говорили о моделях. При этом само содержание эпистем сильно расширилось, если раньше это сводилось к тройке знак – объект – идея, то теперь там довольно сложная структура.
Но важен пререквизит: надо самому разбираться в системном мышлении, и желательно – в том свежем варианте, который есть у Анатолия. Еще полезно понимать конструкты самого фреймворка, чтобы в вопросах напрямую на них ссылаться: не просто «придумай имя для XXX», а «выдай Name Card для XXX», или не «выдай список понятий для области», а «выдай UTS для основных терминов в такой-то области» (UTS – Unified Term Sheet), но это уже не так важно, как именно разбираться в системном подходе.
А еще, если вы думаете над описанием своей предметной области так, чтобы LLM хорошо с ней работал, то есть смысл использовать опыт Анатолия. Можно делать прикладное описание поверх FPF. Можно просто познакомиться с опытом Анатолия по его блогу и попробовать сделать независимо. FPF разрабатывается всего полгода, с ноября. Так что задача – посильная, особенно если речь идет не об одном разработчике, а о большой группе. Например, вы захотите обучить LLM хорошо разбираться в банковском деле и особенностях вашего конкретного банка.”
Все нейросетки одинаковы, учить надо и сухие, и мокрые, ошибки затем у них одни и те же. МИМ обучает агентов, без деления на людей и нежить.
Изрядно всё же помогает такой фреймворк:

Гружу в ChatGPT FPF в качестве общего контекста раздела.

Гружу в ChatGPT в чат по теме, свои заметки по области знания, которые вёл пока проходил ещё учебники.

Прошу составить граф трансдукции для работ по проекту в этой области

Подгружаю контекст текущего проекта, тоже в виде, который получился в моём экзокортексе, тоже с опорой на метамодели из курсов/практик

Задаю задачу, которая передо мной стоит. И предлагаю задать мне вопросы по теме.

Отвечаю на вопросы.

Получаю годный рабочий документ, который можно допиливать.

Пример “смысловой распаковки” понятий из инженерии и менеджмента (скажем, распаковку фраз “гарантирует p95 latency < 200 ms”, “эта посадка обеспечивает соосность”, “Проект согласован”. Скажем, “гарантирует p95 latency < 200 ms” и распаковываем на четыре части: какая использована метрика, что в этой метрике допустимое значение, что там оказывается обязательством и что считается доказательством выполнения обязательства.
Пример онтологической проверки текста.
Вот это повышение точности языка требует
– по каким-то ключевым словам-триггерам раскрыть/распаковать онтику (обрывок онтологии) ситуации, затем
– подложить под эту онтику какую-то математику (мат. объекты с понятным поведением, чтобы потом рассуждение не рассыпалось – по факту потом вы сможете рассуждать с математической точностью, “формализация” как раз этот шаг, хотя поэтический язык назовёт через метонимию весь этот процесс в целом “формализацией” по имени вот этого одного внутреннего шага, но мы будем говорить о процессе в целом как “повышении семантической точности”), затем
– поправить онтологию под эту математику
– затем точно назвать понятия этой онтологии какими-то специфичными для этой онтологии лексемами.
Удивился тому, сколько народу пытаются засунуть 4MB файл спецификации FPF в контекст, так что ответил всем сразу: вписал в несколько мест ReadMe.md в GitHub, что надо add file (в RAG), а не read file (в контекст). Надеюсь, это поможет. FPF не надо помещать весь в контекст, с ним отлично (насколько он вообще может работать “отлично”, ибо есть технические ограничения) работает RAG! Там для RAG довольно много сделано в самом файле, чтобы и “машиночитаемость” была, и “человекочитаемость”. FPF is a file (around 4MB, 50000lines) and should be added only as a file (to the RAG), not to as a prompt (to the LLM context!). Use it with a prompt in you preferable language: “You have FPF in a file. Use it but answer with no FPF-specific terminology. Answer as to engineer-manager.”
Куча руководств условно делится на две части: дообразовывание “вообще”, то есть до более сильного мышления (системное мышление и методология оказались тут даже не первыми дисциплинами, не хватало ступенек в мышлении и для них). Мы сейчас называем это мышлением из нулевых и первых принципов. Дальше – обучение системной инженерии, инженерии личности и менеджменту, как абсолютно конкретные вещи, которые нужно знать топам крупных компаний. Слоган – “Образование для образованных”. Всё заработало, по этим руководствам прошло обучение в том числе несколько топов крупных (единороги, ага) международных (а не только российских) компаний. Всё работает!
– и тут появляется AI, мышление которого помоечное: менеджерское бла-бла-бла из глянцевых журналов с маркетингом “гуру” вроде Адизеса, менеджерские психологические байки от таких же “гуру”, как Адизес, системная инженерия двадцатилетней давности и так далее. Ты хочешь системного мышления от LLM, а к тебе выходит астролог и блогер. Тьфу. Но уже понятно, что делать: сначала делать сильное, рациональное, системное мышление – LLM такая же, как люди. Большой языковой модели нужно “образование для образованных”. ОК, делаем: разрабатываю FPF, first principles framework. Он далеко ещё не готов, но общий замысел уже понятен, и он работает. В руководствах уже говорится о предприятиях из агентов (людей и не очень людей), а FPF по факту представляет собой такое “руководство для не очень людей”, добавляет инженерность мышления к AI-агентам предприятия. FPF уже активно используется нашими инженерами-менеджерами и вполне успешен сам по себе, даже в ещё не совсем законченной форме.
– но мышление по нулевым и первым принципам в FPF это ещё не всё: надо добавлять прикладное мышление по системной инженерии, инженерии личности, менеджменту. В руководствах для людей у нас это в каком-то виде есть, а в FPF – нет, там же “первые принципы”. Так что будем делать “фреймворки вторых принципов” (примерно соответствует о метаУ-модели из наших текущих руководств, то есть более-менее общим учебникам), а затем и “фреймворки третьих принципов” (примерно соответствует метаС-модели из наших текущих руководств, то есть “корпоративным стандартам”). Вот я закончу характеризацию и TGA, затем разберусь с архитектурой и модульностью, и дальше по плану ходы как раз на эти second principles frameworks.
Сначала надо заставлять осваивать сильное (системное/холоническое, рациональное, онтологическое, причинное/контрфактическое и т.д.) мышление по нашим руководствам, и только потом – FPF
FPF - это эпистема, то есть спецификация метода мышления (спецификация не мыслит, но определяет ход сильного мышления). Чтобы поменять что-то в физическом мире, нужен исполнитель. Поэтому для эффектов в физическом мире думаем про связку компьютер с LLM+FPF + человек для эффекта в физическом мире. Базовый конкурент за эффекты в физическом мире - компьютер с LLM без FPF + человек.
“Самостоятельное применение” у LLM+FPF почти отсутствует: надо постоянно намекать, говорить ключевые слова - но вот после этого рассуждение проводится “из первых принципов”.