https://ailev.livejournal.com/1770870.html
Что там с разделением функционального и конструктивного для эпистем? И для функциональных, и для конструктивных разбиений систем можно использовать мереологию по отношению ComponentOf и отношение воплощения/realization между ними. Скажем, ножницы состоят из двух половинок и скрепляющего винтика конструктивно, а функционально - из рукоятки и режущего блока. Как можно разделить эпистемы на "функциональные эпистемы" и "конструктивные эпистемы" и можно ли для них обоих использовать мереологию ConstituentOf? Если пройти по линии аргументов Fine конструктивного подхода к мереологии (не "состоит из", а "составляется из") и вместо безличных операций добавить создателя/constructor, который "составляет/собирает" по линии аргументов Deutsch, то вроде всё получается и логично, и физично. Скажем, в научной статье конструктивные части (аналог половинок и винтика в ножницах) -- это данные документа в формате LaTeX (.tex файл), ConstituentOf которого являются:
-- Преамбула (\documentclass, \usepackage...).
-- Раздел "Введение" (\section{Introduction}).
-- Раздел "Основная часть" (\section{Main Body}).
-- Блок "Теорема" (\begin{theorem}).
-- Блок "Доказательство" (\begin{proof}).
-- Рисунок 1 (\begin{figure}).
-- Список литературы (\begin{thebibliography}).
Это "детали" статьи на сборочном чертеже, конструктивы. Они существуют независимо от того, понимает ли кто-то их смысл, чисто логистические единицы, удобные для сериализации, представления на носителе. Слово "данные" тут очень хорошо: "обработка данных", неважно какая, это про конструктивы. А вот функциональные/ролевые части (аналог рукоятки и режущего блока в ножницах), которые вычитывает не программист инструментов обработки текста, а математик или AI в роли математика -- там важен уже не "документ" (статья), а "главный аргумент", ConstituentOf которого являются:
-- Постановка проблемы: Формулировка того, что мы хотим доказать, часто ещё и зачем мы это хотим делать (ход на окружение).
-- Формулировка Теоремы: Точное математическое утверждение.
-- Стратегия Доказательства: Высокоуровневый план (например, "докажем от противного, используя эллиптические кривые").
-- Ключевая Лемма 1: Важное вспомогательное утверждение.
-- Расчетная Часть: Детальные выкладки и шаги вывода.
-- Завершение Доказательства (Q.E.D.): Финальный логический шаг.
Функциональная часть может быть воплощена разными эпистемическими конструктивами, которые в свою очередь довольно уже легко привязываются к физическим носителям (и там тоже может быть это сделано по-разному). При этом, как и в ножницах, функциональная часть может быть "размазана" по нескольким конструктивам:
-- Функциональная часть "Стратегия Доказательства" может быть описана в конструктивных частях "Аннотация", частично во "Введении" и в первом абзаце блока "Доказательство" (ещё и дублироваться, рассказана в разных речевых регистрах).
-- Функциональная часть "Ключевая Лемма 1" может быть целиком содержаться внутри конструктивной части "Раздел 3.1".
Эта двойная декомпозиция невероятно полезна. Конструктивный вид нужен для автоматизации, версионирования, проверки синтаксиса -- "обработки данных". Функциональный вид нужен для понимания, навигации, мышления, обучения. Что касается остальных "обязательных системных разбиений" для "эпистемных разбиений" -- тоже можно поразбираться (скажем, allocation/размещение/компоновку можно привязывать к тому же носителю конструктива, а полную стоимость владения привязывать к затратам ресурсов на получение и последующее использование).
Важнейшие/архитектурные характеристики холонов: архитектурное пространство и физических систем, и эпистемМожем ли мы говорить о важнейших характеристиках эпистем так же, как говорим о важнейших характеристиках систем -- говорить об архитектуре и архитектурных характеристиках? Да, можем. Например, в текущем варианте FPF архитектурными характеристиками эпистем являются их Formality, Generality, Reliability (определяемые на ординальных шкалах, но тип шкалы тут неважен -- они могут быть какие угодно). Мы там даже говорим об эпистемическом пространстве этих характеристик, а также о динамике эпистем как движениях в этом пространстве. И это типичные -ilities, как ни посмотри (даже по названиям - Formality, Generality, Reliability). Можем ли для отношений между эпистемами взять характеристики модульности - cohesiveness, coupling и т.д.? Да, вполне можем добавить уже к имеющейся Congruency/"тожесамности". И даже "тожесамность" можем вытащить в физические модули (микроскоп и молоток "тожесамны" в каком-то смысле, если речь идёт о забивании гвоздей).
Это мы тащим из физического системного и архитектурного-инженерного мышления в эпистемное мышление, мышление о знаниях, мышление инженерии знаний. А что мы можем утащить из этого эпистемного мышления в инженерный физический мир? Можем утащить, например, идею эпистемического пространства, определяемого эпистемическими координатными осями. В случае архитектурного мышления (-ilities становятся архитектурными характеристиками, проверяются fitness functions) это естественно назвать архитектурным пространством и вводить архитектурную динамику. Более того, вполне можно говорить об архитектуре эпистем, равно как об архитектуре систем. И по поводу эпистем принимать архитектурные решения как ADR, а также строить какие-то функциональные описания (если у вас есть модель из квадратиков и стрелочек, то она вполне себе исполняемая: её исполняет тот, кто на неё смотрит - делает по ней какие-то выводы, это её run-time).
В системном подходе довольно много школ задействовало эту интуицию -- и системное мышление понималось как мышление о системах как структурированных объектах, независимо от их физичности. Но эти рассуждения были "менеджерские", абсолютно нестрогие. В FPF мы под это кладём более-менее формальное основание, строгость/formality вырастает. Можем ли мы говорить, что FPF -- это системное мышление? Можем, если считать физические системы и эпистемы -- системами: физическими и знаниевыми. Можно даже избежать этой терминологической путаницы и говорить не о "системах", а о "холонах", хотя путаница всё одно останется: это будет всё одно системное мышление, которое будет во многом одинаково про холоны, но таки потом всё равно будет специализироваться для физических систем и для эпистем, а потом всё равно специализироваться для конкретных видов систем (авиалайнеры и чашки) и эпистем (теоремы и художественные описания исторических событий).
Какое мышление задаёт фреймворк первых принципов? Архитектурное? Инженерное? Системное? Общее фундаментальное?Итак, мы можем говорить, что даже в текущем недоделанном виде FPF -- фреймворк для архитектурного мышления (и это легко дотягивается до инженерного мышления: акцент на изменении мира, а не просто на описании, и тут что инженерия физических систем, что инженерия знаний оказываются во многом похожими), для системного мышления, накрывающего не только физические системы (акцент на исследованиях, понимании мира -- очень многими системное мышление описывается не как мышление действия агента-создателя, а как мышление системного моделирования). Я когда-то пытался говорить о текущем варианте системного мышления для инженерии (а не только для моделирования мира) как о системноинженерном мышлении. Потом это распространил на менеджмент (инженерия организаций), потом на инженерию личности (обучение) -- и снял этот термин, как путающий. Но внешние люди могут не догадываться, что у нас вполне деятельный, а не только моделирующий/аналитический вариант системного мышления, поэтому путают системное мышление в целом с системным анализом и подчёркивают его разницу с архитектурным в частности и инженерным в целом мышлением. И LLM это радостно высказывают в своей критике.
Зачем всё это надо? Затем, что можно "вынести за скобки" вот это архитектурно/инженерно-системное мышление, выучить его один раз, затем выучить небольшие специализации для (сейчас видно шесть типов) холонов -- и далее пользоваться везде. А разве это не осуществляется уже сейчас в текущих Руководствах для инженеров-менеджеров? Да, конечно, но с оговорками:
-- про эпистемы говорится очень мало, их -ilities вводятся "на пальцах", динамика практически не рассматривается
-- мышление про системы и эпистемы разделено, хорошо проработано и изложено главным образом для физических систем
-- речевой регистр всё-таки больше "для менеджеров", нет чёткой формализации "с математикой"
Вопросы к нежити и ответы нежитиКак я всё это проверяю? Тем же способом, что и в предыдущем посте: задаю трём нежитям одни и те же вопросы, получаю очень интересные ответы. Вот вопросы (и я подгрузил файлы спецификации FPF, а также парочку книг по эволюционной архитектуре, где обсуждаются и -ilities, и собственно архитектурные метрики deployments frequency, lead time for changes, change failure rate, time to restore service):
1. Надо проверить Measurement & Metrics Facet из файла с FPF specification: 1. Достаточно ли его для отражения архитектурных характеристик? (Про архитектурные характеристики говорится в приаттаченом файле книги про fundamentals of software Architecture). 2. Достаточно ли его для отражения Software architecture metrics? (про архитектурные метрики говорится в приаттаченном файле книги по этим метрикам).
2. KDF из FPF спецификации определяет шкалы-оси-лестницы (это там путается) эпистемического пространства и шкалу конгруэнтности для отношения. Вопрос: насколько определяемое там эпистемическое пространство похоже на архитектурное пространство из приложенных книг по эволюционной архитектуре, если рассматривать его как пространство, задаваемое набором архитектурных характеристик? Ведь даже имена осей в KDF (Reliability, Generality, Formality) выбраны как -ilities? Или наоборот, лучше отойти от идеи пространства и говорить просто об архитектурных характеристиках эпистемы по аналогии с архитектурными характеристиками системы? Как лучше?
3. Есть ли в современной науке идеи совместного пространства по кардинальным и ординальным осям (часть архитектурных характеристик кардинальны, часть ординальны - надо иметь общее архитектурное пространство)?
Если брать какие-то внешние характеристики системы в целом, то их можно условно поделить на "важнейшие" или "архитектурные" и какие-то прикладные. Можем ли мы взять критерии безмасштабности и фундаментальности из FPF (отвязка от domain, наличие оператора агрегации), чтобы их разделить? Какой язык проще для унификации - безмасштабности-фундаментальности-трансдисциплинарности или архитектурности (архитектурное - это рекурсивно применяемое на каждом уровне в каждой предметной области, набор -ilities в этом плане довольно стабилен)?
В KDF его эпистемическое пространство имеет более-менее ортогональный набор осей, но по факту эти оси в жизни вполне конфликтуют (пример: рост формальности эпистемы требует дополнительных проверок безошибочности, чтобы не падала надёжность). Можем ли мы явно проводить какую-то ортогонализацию классических системноинженерных -ilities? Их ведь насчитывают около 300, из них часто употребимых примерно 30.
4. Можем ли в KDF для отношений между эпистемами кроме конгруэнтности ("тожесамности") взять характеристики модульности - cohesiveness, coupling и т.д.?
Для функциональных и конструктивных объектов (physical functional object и physical material object в ISO 15926-2) обоих можно использовать мереологию по отношению ComponentOf, деля на части по разным критериям. Скажем, ножницы состоят из двух половинок и скрепляющего винтика конструктивно (деление для удобства design-time), а функционально - из рукоятки и режущего блока (деление по функции/назначению в run-time). Как можно разделить эпистемы на "функциональные эпистемы" и "конструктивные эпистемы" и можно ли для них обоих использовать мереологию ConstituentOf? Приведи примеры для эпистем, аналогичные примеру ножниц.
5. По итогам обсуждения в этом чате становится понятным, что основной материал в KDF и USF в существенной мере дублируется (он рассказан для систем и эпистем дважды, содержательно/концептуально почти одно и то же, только разнится терминология). Исходя из этого можно задумать перепроектирование FPF. Там надо учесть следующие вопросы: 1. У нас мереология была вынесена в ядро. Поскольку тут обсуждаем архитектурную/фундаментальную/безмасштабную составляющую фреймворка, то общую конструкцию тоже можно вынести в ядро. Получается, что ядро оказывается "про архитектуру/безмасштабность/трансдисциплинарность", определяет архитектурное (оно же системное, оно же эпистемическое, оно же системноинженерное и инженерии знаний) мышление о мире. Это верная догадка? Или речь идёт просто об "унифицированном архитектурном/фундаментальном/трнасдисциплинарном фреймворке" для "как думать обо всём одинаково на разных уровнях разбиения систем и эпистем"? 2. У нас рассмотрено два типа отношений части-целого для архитектурных рассмотрений систем и эпистем (ComponentOf и ConstituentOf соответственно). Осталось ещё четыре типа, которые упомянуты в мереологии FPF. Могут ли быть там обнаружены такие же паттерны архитектурного мышления, только не для систем и эпистем, а других типов объектов с другими типами отношений частей-целых? Как это повлияет на итоговый состав фреймворков и фасетов FPF?
6. Оцени предположение о будущей архитектуре FPF на основе обсуждений из текущего чата: Получается, что у нас три типа знаний (и три типа мышления): 1. Знание о том, как устроено знание о мышлении и методы мышления на его основе (kernel и мета-архитектурное/безмасштабное знание про целые и части как холоны и мышление о них, включая общие характеристики вроде характеристик модульности и указаний на функциональность). Сюда же относим cross-cutting facets. 2. 6 видов безмасштабного/фундаментального/архитектрного знания о том, как устроено мышление об отдельных типах холонов с разными подтипами отношения части-целого (системы для ComponentOf, эпистемы для ConstituentOf и так далее), они определяются отдельными фреймворками, эти фреймворки описывают только отличия (специализации) общего мета-безмасштабного/фундаментального/архитектурного мышления. Тут тоже могут быть cross-cutting facets для отдельных типов холонов (системы, эпистемы и т.д.) и их важнейших/архитектурных характеристиках. 3. Прикладное (domain) знание, которое не безмасштабно/фундаментально, применимо на ограниченном числе уровней агрегации и композиции. FPF занимается первыми двумя видами знания о мышлении, а также показывает на стык с прикладным мышлением, которое остаётся вне его описаний.
7. Традиционно архитектура была главной дисциплиной системной инженерии, а системное мышление очень часто распространялось и на нефизические системы, понятие холона не относилось именно к классической 4D мереологии. С учётом доработок по формализации 4D мереологии по линии Fine (конструктивная мереология) и-Deutsch (создатель/constructor для проведения мереологических операций или мереологических рассуждений для constituents) можно ли говорить о результирующем "мышлении по первым принципам", как определено в FPF не только как об архитектурном, но как о системном? Это будет адекватно, или слишком узко для закрываемого FPF общего мышления (что тогда закрывает сейчас FPF из общих важных методов мышления "обо всём", то есть методов мышления интеллекта, что не закрывается вот этой архитектурно/системной частью?), или наоборот: это будет адекватно, потому как FPF очень мало закрывает из общих важных методов мышления интеллекта (и что тогда ещё не учтено в "первых принципах", что надо было бы учесть?
Вот ответы от трёх систем (напомню, что текущая спецификация FPF --
https://disk.yandex.ru/d/k1IAnJN8ixOR4Q, я там пока ничего не трогал. Но, конечно, буду трогать). Ответы там во многом противоречивые, тем интересней:
-- Gemini 2.5 Pro (ответ явно выделяется, ибо я забыл сказать "отвечай как профессионал профессионалу" в системном промпте, поэтому в ответе попытки "объяснять на пальцах" и избегать нюансов. И ещё эти ответы нагло льстят -- и поэтому мне очень нравятся, и там тоже есть несколько неожиданных поворотов),
https://aistudio.google.com/app/prompts?state=%7B%22ids%22:%5B%221-XLxnrhXxQVpKtrStJv81bISlTVl7Mtf%22%5D,%22action%22:%22open%22,%22userId%22:%22115325060035114944424%22,%22resourceKeys%22:%7B%7D%7D&usp=sharing,
-- o3 Pro, умный сухарь
https://chatgpt.com/share/68762d43-d160-8013-b3ea-9ec8b40a353f-- Grok-4, "безумный изобретатель", но зато подсовывающий много литературы (значительная часть которой не по делу, но часть -- вполне по делу!)
https://grok.com/share/c2hhcmQtMw%3D%3D_f8cdfd2a-8710-44fb-8241-5126188acdd8Планы: сначала думать о терминологии, затем о стратегии, а сами планы - потомКакие планы? Ну, какие-то вопросы мы уже рассматривали. Так, там советы пополнить этот системно-инженерный-архитектурный фреймворк фасетами "про личность" и "про людей" -- это мы и так знаем, как раз с попыток посадить инженерию личности и инженерию сообществ на более рациональное основание, чем размахивание руками, всё и началось, даже выпущен только для групп с наставниками черновик руководства по инженерии личности, куда вставлено было 120 страниц ровно на те темы, которые мне советуют включить "для полноты" (текущие оценки у нежити различаются: кто-то/что-то говорит, что охват 80% фундаментального мышления, а кто-то/что-то говорит, что 25%. Я горжусь: даже 25% от общего числа затронутых тем фундаментального мышления -- это много!). Опять же, ход на захват эпистемологией гносеологии (включение религиозного познания и художественного с адекватной оценкой архитектурных характеристик тамошних эпистем) мы уже проговаривали, но в текущем заходе у нежити голова была забита инженерией и шкалами архитектурных характеристик, поэтому такие "оговорки в тексте" были не замечены, это быстро поправимо.
Но в целом пока планы - думать, ибо сначала должна быть какая-то более-менее понятная непротиворечивая терминология и хоть какая-то стратегия, а планировать буду потом. В любом случае, всё будет происходить быстро.

https://ailev.livejournal.com/1770870.html