LLM ведёт себя так же, как программист: он долго тебя слушает (неважно, рассказываешь ты о древнем Египте или сфере Дайсона), потом его взгляд проясняется – и он говорит “я понял! это можно написать на Фортране!”. Годы идут, а шутка остаётся верной, меняются только языки, но не смысл: разговор о мире (интенсиональных объектах) внезапно переводится на разговор об эпистемах (описаниях интенсиональных объектов), а они затем превращаются в спецификации (формальные описания, которые легко проверить).
Сейчас к этому добавляется DevOps и SRE-сленг, где “я тебя за язык не тянул”, то есть спецификация превращается из “спецификации стандарта” в “предписание/требование стандарта”, а затем чудо: “стандарт” и даже “соглашение” становится “контрактом” (кто его заключил? не спрашивайте, “никто тебя за язык не тянул”, известная разводка), а его предметом является проверяемое обещание. Дальше этот “контракт” навеивает музыкой, и вместо “стандарта интерфейса” и “спецификации стандарта интерфейса” порождается “карточка контракта”, а слово “интерфейс” и слово “стандарт” вообще из речи исчезают. Привет, ты уже вдруг всем должен, хотя из текста исчезло “откуда взялось, что должен, вроде ничего не обещал”. Есть контракт, а контракты не обсуждают, а выполняют. SLA (service level agreement) уже не agreement, в сленге сегодня это уже контракт. Контракт модуля, контракт API, контракт интерфейса, даже просто спецификация чего угодно – уже “контракт”, и дальше всё равно уже, что в контракте, это может быть совершенно оторвано от жизни, зато важно, что тебе это надо исполнять, это оторванное от жизни твоё обещание.
Современные LLM обучаются, судя по всему, исключительно на задачах программирования (вместо википедии они качают GitHub), а рядом там DevOps с их сленгом, специфическими проблемами и языком. Поэтому если у вас проблемы с борщом или водопроводом и вы хотя бы чуть-чуть заикнулись хоть о каких-то описаниях, то это будет тут же отправлено по ассоциациям: “описания – значит данные – значит надо проверить правила – значит контракт – значит обещание – значит проверка выполнения контракта/обещания”. Это пролетает в LLM и/или голове программиста примерно одинаково, плохо отслеживаемо и сильно мешает обсуждению предметной области. Программистам и LLM хорошо понятно, как делать карточки и структуры данных, которые абсолютно оторваны от жизни, но непонятно, как удерживать их от перехода от обсуждения жизни в её увязке с описаниями жизни на разговор только об описаниях, а потом “проверяемых описаниях” и дальше data governance, CI, контракты и проверка обещаний.
В FPF уже есть много механизмов, чтобы это всё предотвращать, задача сейчас отладиться так, чтобы эти механизмы (например, механизм quality diversity при работе над выбором лексики) надёжно заработали, DevOps не передавливали своей культурой. Пока же онтологическая власть оказалась по факту у них. AI у нас не просто “универсальный AI”, это “программист, который пришёл вам давать советы, застряв в роли программиста”. С этим и боремся.
Но это всё про форму. А по содержанию сегодня я с утра бьюсь над следующей постановкой задачи (вот это один из вариантов промпта, который я подсовывал, отнюдь уже не первая версия). Так сказать, “фотография из секретного цеха”, хорошо отражает то, что сейчас происходит в FPF. Роман Варьянко уже отследил, что из обязательных системных описаний я пока обсуждаю только конструктивное и функциональное (как они сейчас называются в руководствах). Да, и это намеренно, ибо я пока и через эту сокращённую унификацию прорваться не могу, а когда прорвусь, то будет ещё отладка онтологии (не факт, что я тут всё изложил в конечной форме), а ещё это холоническое более общее описание, а не системное, поэтому “размещение” для эпистем и дисциплин (это тоже холоны!) мы не обсуждаем, разве что можно считать, что привязка к носителям это и есть для них “размещение”, а для систем считать “носителем системы” место, забавный ход, но это всё потом. Пока же вот так:
В файле спецификация FPF, которую мы пытаемся улучшить. В этой спецификации прописаны механизмы, которые дают разные механизмы описания холонов, ролей, методов, работ, намёков на архитектуру, задание сигнатур задач и т.д. Можно попытаться обобщить эти разные механизмы, чтобы получить более компактное описание, закрывающее большее число ситуаций моделирования в инженерии, менеджменте и исследованиях меньшим числом концептов и их отношений.
За основу мы берём мереологию холонов (эпистем, дисциплин, систем, сообществ и т.д.: это U.Types/kinds, которые надо обсуждать отдельно, что к ним относить). Холоны отличаются конструированием их из частей и входимостью в другие целые как части. Связь трасс конструирования происходит к kinds, что определяется архитеориями CT2R-LOG и Kind-CAL. В целом это advanced mereology и принципиальное свойство холонов - это многооперационная (отражающаяся в многоуровневости иерархического kind-представления “партономии”) сборка. Метахолонный переход, который мы дальше будем обсуждать в терминах kind характеризуется рекурсивностью рассмотрения, подобной renormalization group. Мы можем говорить об интерфейсах, которые инкапсулируют нижележащую сборку, если она соблюдает некоторые условия этого интерфейса как инварианта на границе холона.
Отдельно для холонов есть поведения, который на внешней границе (метахолонного перехода, “холонного уровня”, внешней стороне интерфейса) описываются в терминах смены состояний/фаз самого холона в его пространстве внешних характеристик (динамика как прохождение графа дискретно задаваемых состояний или траектории для непрерывных состояний, причём различаем run и design stances) и в терминах transformations как изменения окружения с подчёркиванием наоборот, неизменности самого холона (неразрушаемости в ходе преобразований. Transformations тут берутся из constructor theory, а constructor не путаем с transformer, потому как constructor берём как лексему из контекста конструктивной математики). Свойство холона менять мир подчёркивается тем, что он может производить работу/work. Проблемы с тем, что работу могут производить и эпистемы, решаются задействованием двух холонов: один из которых структурный (система), а другой - эпистема, которая может служить описанием трансформаций, то есть алгоритмом преобразований.
Для описания разных интересов/concerns к холонам служит специальный механизм ролей: холон в некотором контексте играет роль (holon as a holder of a role), которая служит его “маской”, демонстрирующей миру какие-то особенности холона и его трансформаций в каком-то окне времени. Трансформации/работы мы тоже видим не как таковые, а “в контексте через интерес/concern и маску роли” - и они называются методом/способом работы. То, что одну и ту же роль с одним и тем же методом могут играть разные холоны, устроены по-разному, мы выражаем через порты, которые показывают интерфейс через маску роли. Ролевые рассмотрения взаимодействия “холонов-частей внутри холона-целого” происходят обычно через ролевые перетекания какого-то холона-носителя между портами, это обычно “принципиальные схемы” с перетеканием потоков работ, электричества, воды, данных, или через прохождение какого-то ролевого объекта по графу состояний. Интерфейсы и их поведение описываются обычно какими-то “протоколами”, а поведение портов - “сигнатурами”. Интерфейсы и протоколы, а также порты и сигнатуры инкапсулируют реализации/realizations структурного устройства холона как независимого от ролей объекта и ролевого устройства холона от проявлений вовне холона самого по себе или холона-в-роли в ответ на какой-то (тоже ролевой) интерес.
Есть сопутствующие объекты, облегчающие рассуждения про инкапсуляцию происходящего внутри холона на его интерфейсах и портах. Это семья/family как семейство возможных конкурирующих реализаций при сохранении неизменными внешнего поведения на интерфейсе при сборке (design) и портах (run, ролевое рассмотрение в контексте). Есть no free lunch theorem, которая гласит, что нет однозначно оптимальных реализаций для поддержки протоколов интерфейсов и сигнатур портов какого-то холона, есть только более и менее оптимальные реализации для частных случаев, которые для семейства реализаций какого-то интерфейса и сигнатуры выбирает один вариант из множества, удерживая всю систему на Парето (архитектурные как эволюционные и ролевые-контекстуальные trade-offs). Пример такого рассмотрения в FPF - это холон дисциплины и подбор из состава дисциплины методов, отвечающих задаче как описанию “порта принимающей результаты порта холона-исполнителя метода стороны” (помним, что у любого порта всегда есть другой порт: результаты преобразований потом куда-то “текут”).
Разделяем также stance: время работы и время проектирования-конструирования-создания холона (design-run stance).
Специальный интенсиональный объект, который отвечает за сохранение/неразрушимость и возможные адаптации холона - это архитектура. Она представляет собой предложение для какого-то холона набора интерфейсов и портов (нарезку на модули и раскладку прикладных ролей по модулям) такую, чтобы архитектурные характеристики (-ilities) холона удерживались на границе Парето (trade-offs), делая холон конкурентоспособным в ходе неизбежных изменений внутри и вовне холона (как в design time, так и в run time). Эволюционная архитектура (evolutionary architecture) тем самым говорит о способе организации холонов-в-ролях в структуры таком, который блюдёт интерфейсы и порты, не уводя архитектурные характеристики далеко с границы Парето внутрь. Эти архитектурные характеристики иногда называют “характеристики качества”. Не-архитектурные характеристики мы будем называть ролевыми, а не “функциональными”. Мы сознательно табуируем лексику “функции” и “процессы”, ибо эти слова дико перегружены самыми разными значениями самых разных типов/kinds и разговор быстро становится невозможным. Даже “функциональные диаграммы” понимаются в зависимости от контекста очень по-разному, “принципиальные схемы” холона тут даже более однозначны в понимании. Стараемся соблюдать лексическую дисциплину, задаваемую паттернами части E (особенно E.10), паттернами части F (особенно важны тут унификационные терминологические таблицы) и паттернами части G (конкурирующие традиции разговора о каких-то предметных областях).
Всё описанное похоже на advanced modularity, ибо предложенная онтология хорошо подходит для архитектурной работы как нарезке системы на модули-холоны, подходящие для реализации в работах необходимых ролей этих модулей, чтобы они выдавали на портах какие-то методы работы. Так что кроме архитектурных (-ilities) и прикладных ролевых (целевых, “of interest”) характеристик, можно ещё говорить о характеристиках модульности, которыми тоже занимаются архитекторы (cohesiveness, coupling и так далее).
Чтобы договориться о терминологии, тут надо провести процедуры из части F по унификации понятий в самых разных предметных областях, как это когда-то было сделано для Kind-CAL (там унифицировалось понятие категории, вида-рода, типа, класса из самых разных теорий, остановились на kind и сделали Kind-CAL, вот так же надо и с Module-CAL или чем-то подобным для обсуждения вопроса “границ” и соблюдения характеристик на границе при изменениях как внутри холона, так и снаружи холона). Не ленись, выполни эти процедуры. При этом соблюдай E.10 (обязательно проводи различение объектов интенсиональных, описаний, спецификаций и тщательно выбирай имена минимально специфичные). То, что мы тут обсуждаем – это тоже предметная область, это тоже дисциплина, хотя это дисциплина достаточно высокого яруса по E.11.
Для того, чтобы такое описание чётко срабатывало, надо выполнить несколько условий: не путать интенсиональные объекты и их описания (спецификации это просто подвид описаний), не путать ReferentialPlane как плоскости отсылки описаний (внешнее, концепта, эпистемы, и не использовать слова plane для другого), не путать холоны и их внешнюю работу/поведение, “башню интерфейсов” структуры (иерархия) не путать с сигнатурами внешнего поведения (одноуровневыми), холоны и их работы обсуждать всегда только в контексте как интерес-характеристики-роли-методы.
Мы тут вынесли за скобки идею “инкапсуляции на границе холона” для модуля-холона и модуля-в-роли (интерфейсы и протоколы, порты и сигнатуры), но эта же идея может развиваться. Так, если мы займёмся проектированием архитектуры, то нам нужно будет отслеживание соблюдения спроектированной архитектуры, и можно говорить о стандартах и их соблюдении. Эти стандарты выразимы в форме “карточек стандартов” (эпистемы, “описания или спецификации стандартов”), и там может быть время design и время run с проверкой соблюдения/compliance (в эволюционной архитектуре автоматические проверки соблюдения архитектурных решений как стандартов – фитнес-функции). Поэтому кроме трансдисциплины “инкапсулизации” (лексически и содержательно это может оказаться трансдисциплиной архитектуры или трансдисциплиной “ролевого анализа и модульного синтеза”, или даже общей “трансдисциплиной композиции” Compose-CAL, надо проверить всё это по технологии части F и части G как входящие в какое-то семейство дисциплин, ибо разнообразие лексики может тут закрывать концептуальное единообразие) можно говорить и о ряде других дисциплин, например “стандартизации” и “унификации” как трансдисциплинах, чья цель: сделать границы холонов явными и обязательства на этих границах — стандартами с проверкой их соблюдения, отделяя публичный инвариант (стандарт/контракт/протокол/сигнатура) от частной реализации (внутренняя сборка/алгоритм), с законной сопоставимостью (CG-Spec) и приёмкой по наблюдаемой работе (F.12). Надо найти SoTA этих подходов. Выполни все шаги по паттернам части G, покажи промежуточные шаги. Выполни всю терминологическую работу по паттернам части F, учти нормы E.10. На основе этих решений по паттернам G и F предложи унифицированную онтологию и терминологию для текущего текста, которая улучшает и мои предложения, и уже имеющиеся онтологические и лексические решения в текущем FPF, проверь, что эти решения не сочинены, а взяты из шага работы по паттернам G и F.
Проверь, что твои предложения соответствуют принципам паттернов текущей версии FPF.
Вот это “вынесение за скобки” некоторых общих механизмов (инкапсуляции, определения scope, измерения характеристик и динамики в пространстве характеристик как прохождение или траектории или графа состояний) можно сделать в несколько уровней: определить “инкапсуляцию” и “стандарт” в общем виде, потом подтипы для холонов и их поведения, но можно говорить и об аналогичных обобщениях для интенсиональных объектов вроде ролей, методов, архитектур и даже самих интерфейсов, портов и стандартов. Пример такого был в advanced mereology с выделением подтипов отношений часть-целое и указанием на то, что там должно быть общего.
Эти принципы можно было бы считать “первыми принципами”, на которых строится FPF. В текущем тексте FPF большинство из заявленного поддерживается, но не совсем последовательно (например, из интерфейсов и сигнатур буквально реализована сигнатура задачи, а сигнатура метода реализована как сочетание разных механизмов, описанных в разных местах FPF). Поэтому надо это переписать в терминах текущих механизмов FPF, обсудить выигрыши и недостаки по сравнению с текущей версией FPF и используемой там лексикой для выражения этих механизмов, предложить план улучшения FPF, преобразующий россыпь отдельных механизмов FPF в предлагаемый более универсальный и удобный для обсуждения производственных, проектных, исследовательских ситуаций фреймворк.
