First principles framework: progress-report по итогам июня-июля 2025

Как я пришёл к FPF: краткое содержание июньских серий 11 июня я закончил основную часть проекта по переходу от ШСМ к МИМ и занялся перепиской "Инженерии личности", где основной задачей посчитал посадку инженерного процесса на надлежащее теоретическое основание (и там deep learning, active inference, world as a neural net в сочетании с learning sciences и многослойными теориями управления Matini и Doyle), https://ailev.livejournal.com/1767685.html Сначала я попробовал использовать AI для того, чтобы извлечь унифицированный системный подход из его приложений. За основу была взята работа Ванчурина со товарищи про термодинамику эволюции, где приводилась табличка типичного междисциплинарного Розеттского камня: соответствие (как мы сейчас говорим - "конгруэнтность") понятий термодинамики, машинного обучения и эволюционной биологии. Я добавил туда ещё пяток разных дисциплин (instructional design, системную инженерию и т.д.) и дал задание вытащить универсальные понятия системного мышления. После некоторых приключений с описанием многоуровневости в каком-то математическом языке и одновременно на человеческом языке на выходе получилось оригинальное описание унифицированной системной онтологии, уже 12 июня, https://ailev.livejournal.com/1768045.html. К 19 июня уже было очевидно, что инженерия личности подождёт, я кроме онтологии системного подхода перешёл к созданию целого фреймворка системного мышления, куда кроме онтологии были добавлены идеи про методы и инструментарий, https://ailev.livejournal.com/1768211.html. Содержание там не пересекалось с содержанием руководства по системному мышлению, но дополняло его вот той самой "посадкой на надлежащее теоретическое основание". Далее текст быстро распух, а я начал изучать режимы редактирования текста - игрался с разными "регламентами" для нежити, и сильно отвлекался на "понятийный минимум по системному мышлению", вот 21 июня -- https://ailev.livejournal.com/1768555.html. 23 июня я объявил, что эпицентр моих усилий на лето - задействование AI, ибо июньские модели уже приносят больше пользы для работы, чем являются отвлечением на "интересненькое", https://ailev.livejournal.com/1768862.html. 29 июня я написал про мышление AI-письмом/моделированием/кодированием/онтологизированием и архитектуры AI-экзокортекса, https://ailev.livejournal.com/1769411.html. Там я выполнил обзор инструментария и сделал главный вывод: нейросетке принципиально нельзя давать ничего переписывать, ибо текст при этом стремительно деградирует. Только генерировать и сообщать куда вставить. А вставлять лучше самому, руками -- инструментарий тут пока убог, и он должен быть внешним по отношению к LLM. Дальше я на неделю ушёл в работу, а 7 июля вынырнул с идеями First Principles Framework и Intellect Stack Guides в их разработке нежитью, а главной темой стала унифицированная эпистемология: уход от онтологической статики "как устроен мир" на динамику "как мы узнали, как устроен мир", https://ailev.livejournal.com/1769548.html. И даже дал там ссылки на ужас-ужас: тексты FPF и Primer, разработанные нежитью под моим научным руководством. 10 июля я отчитался о тестировании результата (подгрузить файл с FPF в LLM и задать какие-нибудь вопросы с его учётом, FPF как промпт или FPF как контекст-инженерия), вышел успешный успех, и я опять написал про планы на лето: "FPF + LLM = x10 продуктивности сначала для меня, а потом для всех", https://ailev.livejournal.com/1769890.html. Идея в том, что AI будут пользоваться все, а FPF резко усилит результативность его использования, ибо со "случайного" будет нацеливать на "важное". Объем текстов FPF (основной файл-заготовка и файл заготовок к заготовкам) уже превысил на этот момент 1Мзнак в Markdown. И тогда же 11 июля я озаботился различениями FPF и классических верхнеуровневых онтологий, ибо всё неожиданно быстро начало сползать в онтологическую сторону, а мне нужен был не фреймворк "как устроен мир", а фреймворк "как думать о мире, как действовать в мире", где онтология была бы где-то там внутри и не слишком бы выпячивалась -- https://ailev.livejournal.com/1770224.html. Как распухал FPF: краткое содержание последних двух июльских недель 13 июля я опять написал про планы разработки FPF, и там речь шла уже о резком увеличении числа внутренних фреймворков, название "фреймворк фреймворков и фасетов" (ибо в модулях там появились ещё и фасеты) начало жать, https://ailev.livejournal.com/1770263.html. 14 июля я написал про планы унификации архитектурного и системного/многоуровневого мышления для систем и эпистем: идеи Kit Fine конструктивной мереологии в сочетании с идеями Deutsch и Marletto из constructor theory, лежавшие несколько лет в "планах на будущее" стали настоящим, https://ailev.livejournal.com/1770689.html. 15 июля я уже выдал первые результаты по линии унификации системной инженерии и инженерии знаний на базе общей мереологии систем и эпистем соответственно, https://ailev.livejournal.com/1770870.html. И объявил, что надо заняться терминологией, ибо читать производимые нежитью тексты стало тяжело, власть захватили формалисты. Это была моя первая контрреволюция: надо было отнять проект у неживых формалистов и отдать его инженерам-менеджерам. Основные термины должны были стать инженерными, а термины формалистов должны были уйти в синонимы. 16 июля мереологические рассуждения были в какой-то степени финализированы, чтобы формальность мереологического рассмотрения была не ниже, чем у BORO и CCO: https://ailev.livejournal.com/1771205.html. FPF в плане идей существенно опередил нынешнее руководство по системному мышлению. Следующие ходы были на удавливание формалистов с одной стороны (это трудно! если уж нежить захватила какую-то власть, то заставить её эту власть отдать обычно не так просто), но дальше ещё и расщепление эпистемы на три угла семантического треугольника, чтобы вытащить чистую концептуальную работу, отделённую от работы со знаками и предметами, а также чтобы чётче разделить аксиоматические (умозрительные) теории и постулатные (с экспериментами) теории. И ещё ход на унификационный фреймворк: выделение трансдисциплинарной части в FPF и объяснение того, как она связана с предметно-специфическими частями, https://ailev.livejournal.com/1771443.html, это 20 июля. Тут было много интересных открытий, в частности был внесён механизм мантр/чеклистов/канв/шаблонов/"уравнений в типах" на уровне формальных механизмов. 23 июля я перешёл на новый способ работы, ибо занимался в основном модульностью распухшего фреймворка: я начал писать architecture decision records (ADR), принимать архитектурные решения: https://ailev.livejournal.com/1771775.html. Конечно, ADR тоже писал не я, ибо там получались огромные объёмы этих решений, объём ADR становился быстро сравнимым с объёмом всего текста в целом. Задача была - переписать FPF из состояния "помойки отдельных фрагментов" в состояние нового хорошо структурированного текста, но ещё и реализовать принятые архитектурные решения, которых становилось всё больше и больше, а в какой-то момент их число стало больше сорока. 30 июля я продолжал бороться с нежитью (https://ailev.livejournal.com/1771945.html) в части написания ADR, причём результат мне совсем не нравился. Борьба с не очень живыми DevOps (и я победил!) Если первую атаку формалистов как-то удалось отбить (стало понятно, куда их упаковывать, были приняты решения по лестнице формальности и что делать с основными атаками по этой линии, даже Dimensions удалось переименовать в Characteristic, а для физиков и метрологов оставить синонимом), то от засилья DevOps избавиться было много трудней. Ведь все эти LLM много и долго обучали быть программистами прежде всего, поэтому при малейшем намёке они и становятся программистами. Или даже без намёка, эдакий professional bias. Мне это напоминало старый анекдот, как программист долго и внимательно слушал выступление оперного певца, а потом выдал своё мнение: "это можно написать на Фортране" (этого анекдота тысячи вариантов, но ведь он правдив!). Тексты одного абзаца концептуальных решений от нежити сопровождались пятью абзацами описания структур данных на JSON, Turtle, YAML для поддержки базы данных этих решений (tooling), затем огромным числом замечаний о проверках (CI, lint), затем файлах, куда это всё надо разложить в проекте. Это было и в основном тексте, и в ADR, которые планировалось использовать при переписке. Никакие увещевания, что речь идёт о концептуальной части документов, а не об инструментальной и data governance части не помогали, ибо запреты на data governance упоминания сопровождались советами, какими инструментами отследить выполнение этих запретов и в какие файлы эти все запреты положить, и какая последовательность действий должна быть при проверке. И при этом пух состав ADR, без которых было совершенно ясно, что текст не переписать - ADR давали хоть какую-то структуру в обсуждениях, и LLM их уважала (программисты архитекторов уважают, хотя и любят с ними поспорить). Победа (конечно, временная) была одержана заведением ещё одного набора ADR, где они были обозваны "концептуальными", первые две штуки сделаны мной практически вручную (хотя и они не совсем), и их там оказалось всего три: constitutional principles, Canonical Shape of the Rewritten FPF Core and the Invariants Governing Future Edits, Authoring Conventions for FPF Conceptual Documents. Как удалось победить распухание ADR? Я просто заметил, что ADR по форме очень напоминает то, что я хотел бы видеть в самом тексте - это же наследие pattern languages. Я предложил сам текст FPF сделать как набор решений/decisions, хотя и необязательно архитектурных. После краткого совещания (известно же, что кроме архитектуры языки паттернов особо нигде не прижились) нежить предложила способы "митигации" (это слово не я придумал!) недостатков языков паттернов, перекроила под это оглавление концептуальной части, и следующее решение про стиль текста (довольно интересное решение, тоже было получено интерактивно) уже ушло не в текст ADR, а прямо в текст спецификации концептуального ядра FPF. Какой же ход окончательно остановил атаку DevOps? Был введён DevOps Lexical Firewall как принцип, который не пропускал тексты со словами lint, JSON и именами файлов. Было несколько вялых попыток убрать слово DevOps и оставить только Lexical Firewall, но я таки настоял, чтобы слово DevOps там осталось. А часть с tools будет разработана потом, когда-нибудь. И там строгие запреты, чтобы в ней не было сочинения своих концептов, только поддержка уже имеющихся. И симметрично всё то же самое про педагогическую часть: предметно-специфическую (предмет - instuctional design) характеризацию ядра FPF. Все Guides и Playbooks потом, на основе готового концептуального ядра. И всё только по-английски. И жизнь немедленно наладилась. Оглавление готово, предисловие 20Кзнаков тоже готово Мне трудно сказать, какая из нейросеток тут умней других. Интереснейшие решения приходили и от Grok-4 (когда все остальные тупили), и от Gemini 2.5 Pro (когда для остальных было "всё в порядке, ничего не надо делать"), и от o3 Pro (которая дико медленная, но зато умная). Эти сетки быстро договорились об оглавлении. Вот оно (A -- это полноценные паттерны, а D -- облегчённые), и там вот эти самые Guard-Rails от DevOps, зависимости от нотаций, центральности концептуальной работы (unidirectional dependency: DevOps и instructional designer делают то, что говорят методологи, а не наоборот), захвата власти спецами из какой-то предметной области (отслеживается предметный bias). Повторюсь: сложность была в том, что на слово "проверка принципа" первыми откликаются DevOps, и дальше их не заткнуть. Это мной было отслежено, поэтому проверки вроде есть, но организованы не совсем в лоб, а через Conformance Criteria (CC). Можно, наверное, как-то попроще, но пока не знаю, как. Ну, и в оглавлении также наличествует всё остальное, что полтора месяца обсуждалось и накапливалось в текстах. Наверняка это оглавление ещё будет меняться много раз, но вот текущий вариант: Preface -- Introduction: FPF as a Pattern Language and its Historical Roots -- Descriptive Ontologies vs A Thinking‑Oriented Architecture -- Transdisciplinarity as Meta-Theory of Thinking -- Artefact Families as Tiered Publication Contract -- Intellect Stack (informative overview) -- Purpose, Scope, and Explicit Non-Goals -- How to Navigate Architectural [A] and Definitional [D] Patterns Part A · Constitutional Pattern Cluster Section A-I · Foundational Patterns -- A.1 Vision & Mission – “Operating System for Thought” [A] -- A.2 The Eleven Pillars [A] -- A.3 Principle Taxonomy & Precedence Model [A] Section A-II · Guard-Rail Patterns -- A.4 DevOps Lexical Firewall (CC-Guardrail 1) [A] | -- A.5 Notational Independence (CC-Guardrail 2) [A] | -- A.6 Unidirectional Dependency (CC-Guardrail 3) [A] | -- A.7 Cross-Disciplinary Bias Audit [A] Part B · Authoring & Evolution Pattern Cluster -- B.1 Scalable Formality Ladder (M- to F-mode) [A] -- B.2 Tiered Lexical Disambiguation (Meta / Macro / Micro) [A] -- B.3 Design-Rationale Channel – requirement to precede any normative change [A] -- B.4 Four-Register Lexical Stratification [D] Part C · Kernel Architecture Cluster -- C.1 Open‑Ended Kernel & Plugin Layering [A] -- C.2 Architheory Classes & Γ-Contract [A] -- C.3 Temporal Duality — Design-Run [A] -- C.4 Open-Ended Evolution Principle [A] -- C.5 External Observer Pattern [A] Part D · Trans-disciplinary Reasoning Cluster -- D.1 Algebra of Physically Grounded Aggregation [A] Invariants for composing parts that have a material creator -- -- D.1.1 System‑Boundary Distinction [D] Defines `U.System` ✓ boundary types. -- -- D.1.2 Physically Grounded Composition [A] Contract: creator + dependency graph ⇒ whole. -- -- D.1.3 Weakest-Link Roll-up [A] How aggregated risk propagates. -- D.2 Meta-System Transition (MST) [A] Formalises emergence across scales. -- -- D.2.1 Supervisor–Subsystem Feedback Loop [A] Control law for MST. -- -- D.2.2 Boundary-Inheritance Contract [D] When subsystem boundaries promote. -- -- D.2.3 Emergent Objective Escalation [A] How goals lift one layer up. -- D.3 Unified Trust & Epistemic Dynamics [A] Maps evidence to computable assurance. -- -- D.3.1 Two-Layer Trust Architecture [A] Working-Model vs Assurance layer. -- -- D.3.2 Anchoring Relations (`verifiedBy / validatedBy`) [D] | Canonical edge types for proof links. -- -- D.3.3 Computable Assurance Level [A] FV/EV/CL → numeric trust score. -- -- D.3.4 Congruence Ladder (CL) [D] Scale-free epistemic congruence levels. -- D.4 Canonical Evolution Loop [A] Explore → Shape → Evidence → Operate cycle. -- -- D.4.1 Explore–Shape Iteration [D] Hypothesis generation loop. -- -- D.4.2 Evidence Accumulation [D] Data & test artefacts as creators. -- -- 4.3 Operate–Refine Feedback [D] Runtime learning hooks. -- D.5 Reasoning Cycle — Abduction First [A] Abduction precedes deduction & induction. -- -- D.5.1 Abductive Leap [D] Creating candidate explanations. -- -- D.5.2 Deductive Constraint [D] Logical pruning of hypotheses. -- -- D.5.3 Inductive Consolidation [D] Generalising confirmed patterns. -- D.6 Role-Projection Bridge [A] Links domain terms to universal `U-Types`. -- -- D.6.1 Universal Type Node (`U.TypeNode`) [D] Root for every taxonomy import. -- -- D.6.2 Taxonomy Merge Operator (Γ-type)[A] Safe union of heterogeneous trees. -- -- D.6.3 Domain-Specific Role Mapping [D] `plays_role_of`, `refinesType` patterns. Part E · Ethical & Reflective Pattern Cluster -- E.1 Axiological Neutrality [A] -- E.2 Bias-Audit Cycle [A] -- E.3 Didactic Primacy [A] -- E.4 Pragmatic Utility [A] Part F · Glossary & Definitional Pattern Index -- F.1 U.TypeNode [D] -- F.2 Anchoring Relations [D] -- F.3 U.Entity, U.Relation … [D] ... (all other [D] patterns) * Definitional patterns for U.Entity, U.Relation, Strategic Choice, etc. [D] * Alphabetical quick-look table of core terms in four lexical registers. Part G · Outlook -- Success Criteria: Learnability, Extensibility, Traceability -- Open Questions: Multilingual Extensions, Automated Score Estimation Annex A — Conformance Criteria Index (Auto-generated list of every CC anchor and the pattern that defines it.) Annex B — Design-Rationale Archive (Chronological reference list of accepted DRR identifiers; actual records reside outside the core text.) Annex C — Pattern Catalogue (Hyperlinked map and dependency graph of all Architectural and Definitional patterns.) Предмет моей гордости: это оглавление писал не я, я там ни одной строчки не написал! Я рулил процессом. Я понимаю, что это звучит примерно как "предмет моей гордости, что я ни одной машинной команды не сгенерировал, это всё работа компилятора. Я рулил процессом, писал на языке высокого уровня". Да, именно так, ощущения очень похожие. Дальше это оглавление было проверено: по этому оглавлению уже сгенерировано предисловие 20Кзнаков. Теперь надо сгенерировать и весь остальной текст, и тут два пути: -- попросить какой-нибудь DeepResearch, чтобы сгенерировал несколькими большими кусками. Но доверия к этому никакого нет. -- проходить в том же медленном режиме, как с предисловием: по одному разделу-паттерну за раз, при этом генерируется три текста от трёх разных LLM, а затем o3 Pro обобщает эти тексты в один такой, что у двух других LLM к нему не остаётся претензий. Это две генерации o3 Pro, примерно 10 минут такт работы, 6 фрагментов за час, 60 фрагментов за день, автоматизации ноль - cut/paste, ощущения примерно те же, что при выпечке блинов: ничего сложного, но надо быть внимательным, не отвлекаться, и это долго. Потом ощущения будут как у программиста: обнаружить, что всё не так, надо переделать с самого начала. Где на всё это посмотреть Вот где это всё сейчас лежит, можете поглядеть одним глазком: - целевой файл концептуальной части FPF (там сейчас только table of content, а дальше из него аутлайн и предисловие, а из прочего - паттерн редакторского стиля для текста концептуальной части): https://disk.yandex.ru/d/LOCtDa0JayOStg -- концептуальные ADR (их там всего три штуки): https://disk.yandex.ru/d/tP3c5QJFC2tSug -- основной текст прошлой версии спецификации FPF от 20 июля 2025: https://disk.yandex.ru/d/FeMwAUgjHgfFRA (вперемешку концептуальная часть и инструментальная часть с замечаниями по data governance, человечьим глазом читать невозможно) -- ADR с идеями, как этот основной текст переписывать, что туда дополнительно вписывать: https://disk.yandex.ru/d/qbEwoQ6Jm_LgbA (вперемешку концептуальная часть и инструментальная часть с замечаниями по data governance, человечьим глазом читать невозможно) Что греет душу, так это несколько сообщений от наших инженеров-менеджеров, которые уже попробовали FPF в работе. Последнее -- "попробовал FPF в действии, прям очень круто! получил интересные инсайты прям в рабочем проекте!!!", https://t.me/ailev_blog_discussion/32023. Но и это ещё не тот результат, которого я бы хотел добиться. К концу августа FPF должен стать существенно понятней -- и для людей, и для AI, и для людей с AI.