Новая нормальность: у меня R&D отдел из нежити Я продолжаю быть научным руководителем и начальником R&D отдела мастерской инженеров-менеджеров. В отделе три сотрудника: старший научный сотрудник o3 Pro, младший научный сотрудник с интересными идеями Gemini 2.5 Pro, а также аспирант Grok-4. Младшие отвечают мгновенно, каждый ответ старшего надо ждать десять минут, а если ответ из двух частей (что правильно для длинных ответов), то и все двадцать. Но опыт показал, что лучше подождать -- а решения пусть принимает самый умный, хотя он и разговаривает сквозь зубы. Вся эта нежить занята у меня написанием First principles framework. Я уже писал тут, что в начале года было неприлично публично ссылаться на LLM, а в конце года будет неприлично ровно наоборот: что-то публично выдавать, не проверив сначала у LLM, не поработав над чем-то с LLM. Хотя это давно уже не LLM, а какие-то AI-агенты с существенной инструментальной обвязкой, "суп из топора, в качестве топора -- LLM". Всё у меня происходит прямо так, как описано в наших руководствах по рабочему развитию: отдел гибридный, из меня и вот этой нежити, ситуация сегодня штатная, "все так делают". Типовой workflow для меня выглядит так: -- задать богатый контекст (например, подгрузить четыре файла: три архивных предыдущих не слишком удачных версий и один недописанный рабочий) -- попросить всю троицу написать какой-то кусок (единицей работы обычно является паттерн из pattern language, например Architectural Decision Records, но куском может быть, например, оглавление/содержание раздела: план написания текстов). -- взять два текста от младших и сказать старшему "Получено ещё два варианта текста, посмотри их - не забыто ли у тебя что-то полезное, не найдено ли у внешних экспертов каких-то более удачных формулировок. Перепиши развёрнуто свой текст с их учётом (следи, чтобы в ходе переписки не было сокращений, ибо начальные тексты и так уже кратки). Текст большой, пиши по половине". -- поглядеть на текст краем глаза, если что не так по-крупному, попросить переделать. -- Взять половины текста и воткнуть их на нужное место в рабочий текст, переходить к следующему куску. Не бог весть какая работа, но там ещё надо время от времени вести диалоги по уточнению онтологии и первоисточников, ибо вся эта нежить плохо ориентируется в SoTA подходах к тому, о чём пишет. Это и есть главная проблема, которую для моего R&D отдела решаю сначала я, а затем начинает решать тот самый текст, который этот отдел коллективно пишет. Зачем я пишу тексты для AI-ассистента, если он и так уже знает всё на свете и всех умней Знание о SoTA в самых разных трансдисциплинарных теориях (иногда их называют "Теориями всего", трансдисциплинарность ведь как раз об этом) сегодня "рассеяно в атмосфере" и практически недоступно в каком-то одном компактном источнике. Есть, конечно, выдающиеся книги, вроде "Структуры реальности" и "Объяснения, которые меняют мир" от David Deutsch, но там только кусочек - и даже там не всё самое свежее. "Свежее", SoTA - это не просто "новое", это такое "новое" знание, которое даёт надежду на объяснение всего того, что объясняло старое знание, плюс решает известные проблемы с объяснениями, которые были у старого знания. В мастерской инженеров-менеджеров мы собрали ряд руководств, который решает ровно вот эту проблему: дать связное мировоззрение, которое позволит быстрее разбираться с самыми разными предметными областями, которые будут встречаться в рабочих проектах, проектах личного развития, исследовательских проектах. И примерно сто человек в сутки (сейчас лето, поэтому сто, а зимой-весной было где-то по 125 человек в сутки, ведь шли студенческие группы) осваивают мышление по этим руководствам: они же и есть регламенты сильного мышления, их не "изучают", а по ним мыслят и действуют. И вроде бы тут успешный успех, поумнение замечают и сами наши инженеры-менеджеры, и оно ещё видно со стороны -- и коллегам, и близким, и начальникам, и клиентам. С июня 2025 ситуация в мире кардинально поменялась: появились сильные модели AI, которые начали выдавать сравнимые с людьми результаты в самых разных проектах. Эта "сравнимость с людьми" тут играет злую шутку: * как и многие люди, современные AI-агенты не отслеживают SoTA в самых разных предметных областях, а пользуются самыми популярными представлениями, если специально им о SoTA не сказать. Обычно они знают SoTA, но не задействуют новые полезные знания, а задействуют самые расхожие и распиаренные знания. * как и многие люди, они не запрашивают контекст и отвечают прямо на вопрос, поэтому лечат своими ответами симптом, а не болезнь. * как и многие люди, они слабы на решение проблем-в-большом, то есть проблем работы в крупных коллективных проектах, они гениальные "олимпиадные программисты" (ибо их ровно на это и тренируют: чуть что, так лезут сразу программировать, но на уровне олимпиады - навороченное решение на пару сотен строк сложного кода, которое "сферический код в вакууме", а не часть большого проекта, где всё перепутано и надо ещё разобраться что эта пара сотен строк делает в огромном целом, и только потом лезть внутрь кода этой пары сотен строк). Для меня LLM, на базе которой делают сегодня AI-агентов -- это прежде всего "помоечная суперпозиция всех моделей мира" (включая модель мира в исполнении сторонников плоской Земли и модель мира Эйнштейна по состоянию на момент его смерти, при этом речь идёт не только о 4D моделях, как в world models, а о моделях мира в эпистемологическом смысле: теориях о мире, аксиоматических и постулатных). А вот context engineering должен вытащить из этой помойки какое-то связное мировоззрение (и тут уж кто во что горазд. Вот ссылка на свеженький обзор по context engineering, https://arxiv.org/abs/2507.13334, 166 страниц), там про технологии, но не вытаскивание из мировоззренческой помойки какого-то более-менее консистентного мировоззрения. Моя работа как раз про это: я вытаскиваю современное унифицированное системное мышление (и даже больше: холоническое мышление, ибо системное мышление с физическими системами там оказываются внутри него) , поверх него - инженерное мышление. И уж затем можно задавать "любые вопросы", чтобы получить не любые ответы. Тот же подход, что с TLO (top-level/upper ontologies), только у меня не только объекты, но и методы мышления тоже, достаточно общие. Со всеми оговорками, что "универсальность в силу теоремы бесплатного обеда не слишком эффективна, но уж если вы попали в нужный класс задач, то она рулит". Все разработчики TLO оговаривают, что классы задач не "все возможные задачи во вселенной", но когда у вас будет мультидисциплинарный проект и надо будет как-то свести всё это растрёпанное знание вместе — придёте, никуда не денетесь. Для олимпиад по математике, победами в которых хвастаются сегодня все крутые AI-модели, всё просто: там хорошо определённый предмет с уймой литературы, но эпистемический треугольник всего с двумя углами (ибо понятие и объект совпадают, аксиоматические "умозрительные" теории про идеальные/математические объекты с исключениями вроде экспериментальной математики). Для других проектов, связанных с физическим миром (инженерия) всё уже не так просто, и конгруэнтность ("приблизительную тожесамность") понятия и объекта приходится оговаривать. Если тождество A=B в математике легко выводимо, то в физике для отождествления Утренней Звезды и Вечерней Звезды нужно иметь какие-то предсказательные постулатные теории, а ещё провести измерения. И ещё надо учесть множество масштабов рассмотрения. И ещё учесть много чего. Для беседы в реальных проектах должен выйти хорошо образованный AI-агент с нормально простроенным мировоззрением, а не просто instruct-версия, обученная на вопросах эзотериков про особенности астрологии и вопросах этиков про феминизм и защиту верований малых народов как движущую силу прогресса (ведь обучение нежити сегодня заключается главным образом в том, чтобы удовлетворить всех в рамках их же верований, если они "не нарушают закон". Астрологи закон не нарушают!). Надо как-то задать набор "верований", которым надо удовлетворять: естественнонаучную и инженерную SoTA картину мира. Написать manual/guide, по которому надо отвечать на вопросы, и часто даже не те вопросы, которые задают ("лечить симптомы"), а вопросы, которые в какой-то рабочей ситуации надо задать (вроде неприятного вопроса "а что там у вас целевая система, давайте разберёмся", этот вопрос очень не любят, ибо чаще всего надо признать после ответа на этот вопрос, что проект или дохлый и деньги инвестора просто на него прокушиваются, или признать проблемы с этикой, или признать, что твоя собственная работа на результаты проекта влияет "никак"). Вот это SoTA мировоззрение, культуру современного сильного мышления можно получить, залив достаточное количество мегазнаков разных текстов в головы, чтобы полезного из окружающего информационного бедлама вынималось больше, а на вываливающийся на тебя информационный мусор ставились фильтры на уровне рефлексов. Сейчас в головы мы заливаем нашим инженерам-менеджерам примерно 8Мзнаков текстов руководств только по линии рабочего развития. Мой текст для context engineering будет тянуть где-то на 1Мзнак, ибо там не надо слишком сильно заниматься spaced repetition, нежить понимает всё чаще и чаще с первого раза (но не факт, может быть и надо повторять и повторять какие-то примеры, few shot learning). Концептуальное описание сначала, руководства потом. Ну, или руководства никогда: их на лету будет генерировать тот же AI Результаты пока радуют, а там поглядим. Всё происходит быстро, бег впереди паровоза. На этой неделе появляется новое, более умное поколение моделей нежити, а вот появления нового поколения более умных людей ждать не приходится. Более того, нежить есть шанс научить -- она честно прочтёт тексты регламентов мышления, которые ей даёшь почитать. А людей научить мыслить "как надо", а не "как всегда" шансов мало, ибо ты им никто и звать тебя никак. ОК, будем учить нежить. А желающих пообщаться с нежитью на эффективном языке сильного мышления, мышления из первых принципов, мы тоже научим. First principles framework как раз и посвящён этой задаче. Там будет три артефакта: -- концептуальный текст с принципами (вот его сейчас и пишем) -- несколько вариантов текстов инструкций для DevOps, чтобы можно было развернуть экзкокортексы в поддержку предлагаемого мышления (чтобы какие-то там проверки можно было делать не "в уме", а задействовать инструменты -- берём инструменты, берём настроечные файлы, начинаем работать) -- несколько вариантов текстов руководств для людей (и я не удивлюсь, если эти руководства вообще не придётся писать: они будут создаваться "на лету", то есть AI берёт концептуальный текст с принципами и начинает по нему генерировать адаптированный к запросам конкретного человека и его текущей квалификации текст объяснений, а также текст привязки к его проекту, сразу на его родном языке) У меня идёт очередная переписка FPF, в которой есть несколько существенных особенностей: -- текст получается строго концептуальный, никакого экзокортекса или нотаций записи. И заодно никакой "педагогики", это потом. Это заявлялось и в предыдущей версии, о которой писал неделю назад (https://ailev.livejournal.com/1772090.html), но плохо выполнялось. В этой версии текст существенно чище, DevOps-сленга и data governance почти совсем нет. -- формат pattern languages, это оказалось и впрямь удобным. -- холоническая мереология (включая мета-холонный переход), отмоделированная по образу и подобию системной мереологии. Это конструктивная мереология на базе идей Kit Fine с докрутками со стороны constructor theory от Deutsch и Marletto. Это основное отличие новой версии, ибо старая версия заявлялась как "универсальная для систем и эпистем", но по факту вышла очередным "системным подходом". В новой версии ожидается реальная универсальность. Написано уже новое оглавление, правила написания самого текста, дописан текст микро-ядра. Сохранено пока старое предисловие, потом его тоже перепишем. По традиции -- оглавление, как и неделю назад. Можете сравнить: разница существенная.

First Principles Framework — Core Conceptual Specification Table of Content

Table of Content

Preface (non-normative)

• 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 · Kernel Architecture Cluster

§	ID & Title	Tag	Concise content reminder — “what belongs here”
Cluster A.I · Foundational Ontology
A.1	Holonic Foundation: Entity → Holon	[A]	Entity ⊃ Holon; defines System, Episteme as archetypal sub-holons.
A.2	Functional Role Taxonomy	[A]	Universal split Material Object vs FunctionalRole; introduces TransformerRole, ObserverRole, etc.
Cluster A.II · Transformation Engine
A.3	Transformer Principle & Triad	[A]	Transformer–Method–MethodSpec; design-time change, grounding in physics.
Cluster A.III · Time & Evolution
A.4	Temporal Duality & Open-Ended Evolution Principle	[A]	design-time vs run-time; monotonic openness to refinement.
Cluster A.IV · Kernel Modularity
A.5	Open-Ended Kernel & Architheory Layering	[A]	Micro-kernel + CAL/LOG/CHR “plug-in” strata.
A.6	Architheory Signature & Realization	[A]	Public contract (Signature) vs private logic (Realization).
Cluster A.V · Core Ontological Principles (all formerly scattered “C-rules” collected here)
A.7	Strict Distinction (C-6)	[A]	Object ≠ Description ≠ Carrier; prevents category errors.
A.8	Universal Core (C-1)	[A]	Every U.Type must ground in ≥3 disparate domains; guards against parochialism.
A.9	Cross-Scale Consistency (C-3)	[A]	Rules and invariants must compose coherently across holon levels.
A.10	Evidence Anchoring (C-4)	[A]	All normative claims must link to traceable evidence artefacts.
A.11	Ontological Parsimony (C-5)	[A]	“Minimal-sufficiency”: introduce a new primitive only when indispensable; prefer functional naming.
A.12	Agent Externalization & External Observer Pattern (C-2)	[A]	Mandatory separation of modeling agent from modeled holon; formalizes the ObserverRole.

Part B — Trans-disciplinary Reasoning Cluster

§	ID & Title	Tag	Concise reminder
B.1	Universal Algebra of Aggregation (Γ)	[A]	IDEM / COMM-LOC / WLNK / MONO invariants on U.Holon.
B.1.1	Dependency Graph & Proofs	[D]	Formal input schema & invariant proofs.
B.1.2	Sys-specific Γ_core	[A]	Mass/energy + boundary rules (imports Sys-CAL).
B.1.3	KD-specific Γ_epist	[A]	Provenance + trust rules (imports KD-CAL).
B.1.4	Γ_ctx / Γ_time (universal flavours)	[A]	Order-sensitive & time-series composition.
B.1.5	Γ_proc (process instantiation)	[D]	Sequential / concurrent aggregation of U.Process (imports Process-CAL).
B.1.6	Γ_work (resource/work instantiation)	[D]	“Work-is-spent-resource” operator (imports Resrc-CAL).
B.2	Meta-Holon Transition (MHT)	[A]	Universal emergence pattern.
B.2.1	BOSC Triggers	[D]	Boundary • Objective • Supervisor • Complexity.
B.2.2	MST (Sys)	[A]	Super-system emergence.
B.2.3	MET (KD)	[A]	Meta-epistemic emergence.
B.2.4	MPT (Process)	[A]	Adaptive workflow emergence (imports Process-CAL).
B.3	Calculus of Trust	[A]	Working-vs-Assurance; anchoring relations.
B.3.1	Characteristic & Epistemic Spaces	[A]	F-G-R axes; measurement templates.
B.3.2	Evidence & Validation Logic (LOG-use)	[A]	verifiedBy / validatedBy; confidence maths.
B.4	Canonical Evolution Loop	[A]	Run → Observe → Refine → Deploy.
B.4.1	Sys instantiation	[A]	Field upgrade loop.
B.4.2	KD instantiation	[A]	Theory refinement loop.
B.4.3	Process instantiation	[A]	Adaptive workflow evolution.
B.5	Reasoning Toolkit	[A]	Core cognitive cycles; role-projection.
B.5.1	Explore → Shape → Evidence → Operate	[D]	State machine details.
B.5.2	Abductive Loop	[D]	Hypothesis generation.
B.5.3	Role-Projection Bridge	[D]	Import of domain vocabularies.
B.6	Characterisation Families (CHR-use)	[A]	Templates referencing CHR-CAL.
B.7	Common Logic Suite (LOG-use)	[A]	Modal & trust-propagation rules (imports LOG-CAL).

Part C — Architheory Specifications

§	Architheory	Tag	Scope & Exports
Cluster C.I – Core CALs / LOGs / CHRs
C.1	Sys-CAL	CAL	Physical holon composition; conservation invariants; resource hooks.
C.2	KD-CAL	CAL	Epistemic holon composition; F-G-R axes; provenance graph.
C.3	Type-CAL	CAL	Generic lattice; sub-typing; reused by LOG-CAL.
C.4	Process-CAL	CAL	Ontology of U.Process; capability typing; Γ_proc ops.
C.5	Resrc-CAL	CAL	Energy / material / information resources; Γ_work ops.
C.6	LOG-CAL – Core Logic Calculus	LOG	Minimal proof calculus; modal & trust operators (imports Type-CAL).
C.7	CHR-CAL – Characterisation Kit	CHR	Meta-template for measurable properties (imports Sys/KD/Resrc-CAL).
C.8	Method-CAL	CAL	Formal U.Method / U.MethodSpec; interfaces A.3 triad.
Cluster C.II – Domain-Specific CALs
C.9	Agent-CAL	CAL	Reflex-adaptive agents; ThinkingRole; eco-evo-devo hooks.
C.10	Norm-CAL	CAL	Behavioural constraints; ethics; trust anchors.
C.11	Decsn-CAL	CAL	Decision holons; preference orders; utility proofs.
Cluster C.III – Meta-Infrastructure CALs
C.12	ADR-Type-CAL	CAL	DRR schema; Signature / Realization versioning.
C.13	PortioNorm-CAL	CAL	Constructive mereology: port vs. portion semantics.
Cluster C.IV – Composite & Macro-Scale
C.14	M-Sys-CAL	CAL	Large-scale infrastructures; multi-Transformer orchestration.
C.15	M-KD-CAL	CAL	Discipline-level paradigms; meta-epistemic analytics.

Part D – Multi-scale Ethics & Conflict-Optimisation

§	ID & Title	Tag	Concise reminder — “what belongs here”
D.1	Axiological Neutrality Principle	[A]	No built-in value hierarchy; ethics expressed as explicit preference lattices.
D.2	Multi-Scale Ethics Framework	[A]	Four nested arenas: Self → Team → Ecosystem → Planet; scoping rules.
D.2.1	Local-Agent Ethics	[D]	Duties & permissions for a single U.System or U.Agent.
D.2.2	Group-Ethics Contracts	[D]	Collective norms, veto mechanisms, subsidiarity rule.
D.2.3	Ecosystem Stewardship	[D]	Inter-architheory externalities; tragedy-of-commons mitigations.
D.2.4	Planetary-Scale Precaution	[D]	Catastrophic-risk anchors; long-termism discount curves.
D.3	Holonic Conflict Topology	[A]	Typology of clashes: resource, goal, epistemic, temporal.
D.3.1	Conflict Detection Logic (LOG-use)	[A]	Formal predicates (conflictsWith, mitigatedBy) and satisfiability checks.
D.3.2	Hierarchical Escalation Protocol	[D]	From local negotiation → external mediation → DRR appeal.
D.4	Trust-Aware Mediation Calculus	[A]	Resolution algorithm blends value-weights with B.3 trust scores.
D.4.1	Fair-Share Negotiation Operator	[D]	Nash-like but bias-corrected; imports Resrc-CAL cost functions.
D.4.2	Assurance-Driven Override	[D]	When safety evidence overrides utility maximisation.
D.5	Bias-Audit & Ethical Assurance	[A]	Cross-disciplinary bias probes; links to Guard-Rail 4.
D.5.1	Taxonomy-Guided Audit Templates	[D]	Onto / Arch / Prag / Did dimensions; sampling guidance.
D.5.2	Assurance Metrics Roll-up	[D]	Composite “Ethical Risk Index”, traceable to evidence anchors.

Part E — The FPF Constitution and Authoring Guides

§	ID & Title	Tag	Concise content reminder — “what belongs here”
Cluster E.I
E.1	Vision & Mission	A	Purpose, scope boundaries.
E.2	The Eleven Pillars	A	P-1 … P-11 immutable principles.
E.3	Principle Taxonomy & Precedence	A	Gov/Arch/Onto classes; resolution rules.
E.4	FPF Artefact Architecture	A	3-tier publication contract; conceptual layers only.
E.5	Four Guard-Rails (umbrella)	A	Intro + rationale.
E.5.1	DevOps Lexical Firewall	D	Ban of tooling jargon in core.
E.5.2	Notational Independence	D	Semantics ≠ notation.
E.5.3	Unidirectional Dependency	D	Core independent of tooling/pedagogy.
E.5.4	Cross-Disciplinary Bias Audit	D	Mandatory bias mitigation flow.
Cluster E.II — The Author’s Handbook
E.6	Didactic Architecture of the Spec	A	“On-Ramp first, Governance last” flow.
E.7	Archetypal Grounding Principle	A	Tell-Show-Show rule (AG-01).
E.8	Core Specification Style Guide	A	[A] / [D] templates; S-rules; no CI snippets.
E.9	Design-Rationale Record Process	A	DRR lifecycle, no Git commands.
E.10	Lexical Governance & Stratification	A	Four registers + tiered disambiguation.
E.11	Scalable Formality Ladder	A	M-Mode → F-Mode maturation path.

Part F – Glossary & Definitional Pattern Index

§	ID & Title	Tag	Concise reminder
F.1	Alphabetic Glossary	INF	Every U.Type, relation & operator with four-register naming.
F.2	Definitional Pattern Catalogue	[D]	One-page micro-stubs of every [D] pattern for quick lookup.
F.3	Cross-Reference Maps	INF	Bidirectional links: Part A ↔ Part C ↔ Part B terms.

---

Part G – Annexes & Extended Tutorials

§	ID & Title	Tag	Concise reminder
G.1	Deprecated Aliases	INF	Legacy names kept for backward compatibility.
G.2	Detailed Walk-throughs	INF	Step-by-step modelling of a pump + proof + dev-ops pipeline.
G.3	Change-Log (auto-generated)	INF	Version history keyed to DRR ids.
G.4	External Standards Mappings	INF	Trace tables to ISO 15926, BORO, CCO, Constructor-Theory terms.

---

Part H – Indexes & Navigation Aids

§	ID & Title	Tag	Concise reminder
H.1	Concept-to-Pattern Index	INF	Quick jump from idea (“boundary”) to pattern (§, id).
H.2	Pattern-to-Example Index	INF	Table listing every archetypal grounding vignette.
H.3	Principle-Trace Index	INF	Maps each Pillar / C-rule / P-rule to concrete clauses.

Смотреть в прямом эфире вот тут: https://disk.yandex.ru/d/N2xaJZWo-hhFYw (эту версию ещё очень осторожно, но уже можно смотреть и человечьими глазами. Но вот использовать пока нельзя, там из старых версий перенесено пока не очень много содержания. Но скоро уже, работа идёт).