FPF как набор методов управления "мыслительным долгом" (Thought Debt) инженеров-менеджеров

Вчера выступал на методсовете с рассказом о новациях онтологии FPF по сравнению с текущей онтологией руководств по рабочему развитию (рациональная работа, системное мышление, методология, системная инженерия, инженерия личности, системный менеджмент) и исследовательскому развитию (интеллект-стек). С одной стороны, ничего не изменилось. С другой стороны, есть довольно радикальные решения. Почему идём на радикальные решения? -- Потому что SoTA сдвинулась. Так, конструктивная математика в обоснованиях в начале 21 века была ещё экзотикой и в узких кругах остромодной (скажем, у программистов это шло через острую моду на Haskell), а теперь это общее место. Chris Partridge с его BORO и CCO как наследники ISO 15926-2:2003 сделали радикальный разворот к конструктивной онтологии, и там вовсю используются идеи Kit Fine, что часть-целое это не просто "выделение вниманием", а вот прямо таки мыслительные операции сборки-разборки, которые оставляют след/trace сборки из каких-то примитивов. FPF вводит три оператора для сборки разных типов: sum (для структурных сборок), set (для коллекций) и slice (для аспектов), а ещё отдельно фаз и темпоральных частей. Операторы работают над холонами, в том числе над вариантами разных видов холонов: системами, эпистемами, фазами, членством и т.д. Там, конечно, проблема: мыслят все инженеры "в вечных типах", а вот современность -- она уже "конструктивна", мыслят "в операциях". Поэтому одно из главных решений -- это разделение на видимый инженерам ярус/tier Working-Model с обычными типами "часть-целое" и многоуровневые Assurance Layers: Mapping/Logical/Constructive+ Empirical Validation. Грубо говоря, 95% всех проектов и всех обоснований делаются не очень формально, работаем с эвристикой. Но если вам вдруг сильно приспичит, то "в кустах у нас рояль": обоснования могут готовиться со звериной серьёзностью и там все может быть полностью конструктивно (в смысле конструктивной математики), абсолютно формально. У нас тем самым в FPF появляется развитый аппарат разговора о доказательствах, обоснованиях, а также сборке из частей знаний, методов, сообществ и так далее. Дальше с этим аппаратом можно идти и в инженерию личности, и в инженерию сообществ, и я надеюсь, что это можно будет делать уже этой осенью. -- МИМ в том или ином виде работает с 2015 года, уже десять лет. Руководства уже пережили переход со второй версии системного мышления ("жизненный цикл" от рождения до смерти системы) на третью ("инженерный процесс" бессмертной вечно обновляющейся системы, "пока эволюция не разлучит нас"). Аргумент перехода (тоже болезненного) был по David Deutsch: перед нами бесконечность, если мы выучили 200 человек, то выучим вдесятеро больше по новому варианту. Вот, текущая оценка -- выучили как раз 2000 человек. Если продолжим в том же духе, пойдём на эти радикальные улучшения, то их получат следующие 20000 человек (и 20000 AI-систем, почему бы и нет). Рассказать на методсовете вчера успел только о нескольких архитектурных принципах, вот они: Принцип 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 хотя бы на уровне прототипа: явные логические дыры, не до конца выверенная терминология, отсутствие каких-то объяснений. Методологическая работа, формулирование трансдисциплинарного метода мышления, запись его спецификации на языке паттернов. -- объяснить уже готовую спецификацию FPF, перевести в совместное мастерство работы человека и AI. Это методическая задача. Решать её надо потом, когда понятно, чему учить. Далее смотри предыдущий пункт, без него тут обсуждать нечего. -- объяснить, зачем этот FPF вообще вдруг нужен, чтобы озаботиться прохождением предыдущего пункта, для которого был нужен самый первый пункт. Грубо говоря, "продать": если об FPF никто не узнает и никто им пользоваться не будет, то можно было бы его вообще не делать. Текущая версия FPF лежит вот тут: https://disk.yandex.ru/d/N2xaJZWo-hhFYw