Я никуда не исчез, просто я свою норму мышления письмом/моделированием писал не в блог, а в задание на разработку архитектуры графа трансдукций и реализацию этого задания в FPF. Я по-прежнему хочу показать в FPF, как математика превращается в физику, а та в инженерию (Principled Enactment Architecture: от аксиом к постулатам, затем к чашке кофе (и обратно): ailev — ЖЖ, 3 ноября 2025), но этого слона съесть за пару дней не получилось, и даже за пару недель не получилось. Но я сильно продвинулся в этой задаче и можно уже смотреть какие-то результаты.
Начнём со слова “трансдукция”, оно означает по факту “конвертацию” чего-то из одной формы в другую, transduction это просто отглагольное существительное от transduce (TRANSDUCING Definition & Meaning - Merriam-Webster), а transducer (Transducer - Wikipedia) чаще всего используется для названия преобразователей сигналов, скажем, термопара преобразует тепло в электричество. Так что по-русски это “преобразователь”.
Вот у нас граф из узлов-морфизмов, которые делают преобразования формы в общем виде (например, на входе аксиомы, а на выходе - математический формализм, или на входе набор постулатов и единиц измерений, а на выходе – семейство методов). Но почему по-английски это не transformation (который в FPF уже есть), а именно transduction? “Преобразование/transformation” – это что угодно во что угодно, а у нас преобразование формы, более узкий класс. Традиционный перевод transduction на русский как “преобразование” (тепла в электричество, например) для FPF тем самым плох. Ну, пусть будет по-русски калька: трансдуктор (хотя более правильно не transductor тут, а transducer, оба слова существуют, нам нужно второе, ну да ладно, “трансдусер” по-русски точно не приживётся, а трансдуктор вообще другое – магнитный усилитель, но кто об этом знает?). Какие-то “входы” трансдукции (ну, или трансдуктора – можно смотреть на узел как на функцию, а можно как на функциональный объект, который осуществляет эту функцию) преобразуются в “выходы” (а не вообще какое-то любое преобразование формы), вот это важно. В FPF взяли transduction с осознанно узкой трактовкой, ибо важно преобразование формы и представления, плюс строгая типизация и строгие проверки тех объектов, которые преобразуются в каждом узле графа.
Узлы-трансдукторы (в математике это будут морфизмы) соединены рёбрами-переносами, и по графу идёт поток этих самых “разных форм”, которые иногда называют жетонами/токенами. И тут есть развилка в представлении потока по графу преобразователей:
– лагранжево представление каких-то частиц-токенов (объектов), которые бегут по путям потока. Крайне распространено: supply chains, водопроводы, и само слово flow вызывают ровно такое представление. Объекты текут по течению от входа к выходу, у каждого объекта своя история, но если объект вдруг меняет форму, то описать это затруднительно.
– эйлерово представление, где поток моделируется какими-то правилами-ограничениями его состояния на рёбрах. В этом представлении ничто никуда не течёт (на самом деле течёт! но не надо мысленно преследовать каждый токен), есть только состояния “по правилам/уравнениям”, которые и задают динамику. Все формулировки немедленно становятся контрфактическими “допустимо” и “не допустимо” (возможно-невозможно). Если что-то меняет форму – просто контролируется допустимость состояний ребра (ребро тут будет U.Transfer, переносом выхода одной трансдукции на вход другой).
Если бы мы выбрали лагранжево представление, то мы бы потеряли универсальность по типу потока: для счётных объектов (токенов) в supply chain (читай: “операционный менеджмент”) ещё хоть как-то бы всё работало, а вот перетоки знаний уже была бы трудно представима, знание трудно представляется токенами. С законом Кирхгофа и “перетоками” тут тоже трудновато, поэтому “принципиальные схемы” в лагранжевом представлении - кошмар. И ещё движение токена описывается процедурно, journey – теряем декларативные контрфактические описания причинности. В лагранжевом представлении моделировать эволюцию и “открытый мир” для наших целей было бы заметно труднее: появление (или обнаружение в исследовании) новых узлов и путей непонятно как моделировать, а в эйлеровом представлении – просто появляются какие-то новые локальные законы/правила/ограничения, ничего страшного. Ну, и композиционность самого потока в лагранжевом представлении заставляет желать лучшего: поставить новый трансдуктор или новую проверку - это переписать всё, а в эйлеровом представлении – это “дописать ещё пару уравнений к системе, удерживающей состояние всего потока в целом”.
В общем, выбрали эйлерово представление: примат описания целого графа, а не каждого токена. Не просто TGA, а E.TGA (Eulerian Transduction Graph Architecture).
Оговорка первая: в русском и английском деонтическое “позволено/дозволено” и “не разрешено” очень плохо отличимы от контрфактических “возможно” и “невозможно”. “Недопустимо делить на ноль”: в языке невероятно трудно выразить эту идею так, чтобы это был не запрет чиновника, законы физики и законы чиновников нещадно путаются. И этот деонтический язык для контрфактических высказываний (admissibility против duties) был одной из проблем, с которой пока не очень понятно, что делать. Нейросети (что мокрая, что не очень мокрая) в деонтике-контрфактичности путаются.
Особенность эйлерова представления: разнообразие родов/типов узлов (разнообразие видов/типов морфизмов/операций/процедур/функций, и у нас в FPF не типы, а kinds-species, роды-виды), но скучный род ребра, это U.Transfer – и всё, никаких видов. Вся семантика живёт в узлах, а на рёбрах только переносы. Даже указание путей на графе - это не особые виды/типы рёбер, а мета-указания рёбер, попадающих в путь. Но вот все законы движения по графу в целом (а не по отдельным трансдукциям) – они выполняются именно на рёбрах.
Почему так всё сложно? Если ты делаешь скворечник или даже табуретку – это всё абсолютно не сложно! Но когда ты переходишь к массовому выпуску скворечников или табуреток с заданным качеством, то сразу всё сложно: требуется минимум дефектов (шесть сигма, чуть больше трёх дефектов на миллион реализаций!) и большая точность (чтобы всё собиралось без подгонки каждой детали по месту напильником, как ещё полвека назад). Ну, и о запусках ракет надо забыть, ибо там всё то же: минимум дефектов и большая точность, а качество всей системы определяется качеством слабейшей её подсистемы – и так “до самого низу”, до болтика. Поэтому делаем моделирование точным и надёжным, а в граф встраиваем кучу проверок. Фишка в том, что на каждом ребре, если по уму делать этот граф, не нужно делать все проверки. Можно делать только минимально необходимые проверки, подсказанные математикой. Вся эта математика и принципы такой организации графа приведены в тексте (разделы SoTA Echoing).
И что же мы описываем этим графом трансдукций? Разные-всякие потоки над формами-холонами (системами, эпистемами), ибо смотреть на этот поток можно по-разному (views, как в ISO 42010), но сам поток один и тот же – вот мы его в целом и моделируем:
- функциональные/принципиальные представления: всевозможные flow, от электрических и кинематических схем до DataFlow. Резистор - это такой механизм, который реализует закон Ома. Attention - это такой механизм, который реализует “законы внимания” (формулы!) в нейронных сетях.
- модульные представления: какие-то модули, соединённые друг с другом через интерфейсы. И они что-то передают друг другу через эти интерфейсы.
- процедурные представления: какие шаги предпринимаются и кем в какой последовательности.
- эволюция: что там меняется в этом графе (какие трансдукции-узлы и передачи-рёбра появляются, как меняются там правила).
- … самое чудесное, что список этот открыт.
Тем самым это основание для методологии в FPF, выходы на все flow (функциональный дизайн, архитектура и много чего ещё).
Какие остались проблемы, которые неплохо бы решить перед написанием паттернов A.21-A.45? О, их множество, так что этот подпроект в FPF закончится ещё не скоро. Вот только несколько первых пунктов плана, как я его вижу сейчас:
- внести, наконец, заклинание про NQD прямо в F.18 (устал каждый раз это писать в промпте, надо просто это внести в паттерн, всё руки не доходят)
- убрать carrier, вместо него view! Это уже задано в E.17 (но надо исполнить и в E.17, и в USM).
- разобраться с CtxState и PublicationScope: в каких они отношениях, какой там нейминг?
- разобраться с тем, что у нас холон: вроде как системы и эпистемы побеждают, но это только в последнее время, раньше родов холонов было много больше.
- вопросы про “характеризацию” и (сюрприз!) онтологизацию, она сейчас спрятана чуть ли не внутрь PrincipleFraming, а её надо бы оттуда вытащить. Онтология и эпистемология – тут, причём в тесной связке с праксиологией.
- разнесение механизмов и проекций (механизм объявляет и реализует эффекты, а проекция их не объявляет и не исполняет). Проекций уже есть несколько разных, надо бы сделать паттерн и объявить всё остальное его вариантами. Это всё как раз про “первые принципы”, вот такие различения.
- паттерн-аналог ISO 42010, multi-view проекции (инженерные в графе трансдукций и публикационные в MVPK). Тут ещё надо договориться, что TGA это и есть “инженерия” (почему бы и нет, он ещё и “исследования” и даже “математика”, с этим ещё можно поразбираться)
- проверить, что U.Mechanism и U.Signature соответствуют TGA, ибо дальше на них будет развёрнута цепочка P2W (principle-to-work), то есть цепочка “от аксиом через постулаты к теориям, методам и работам”.
- ещё раз поглядеть на онтологию работ и семейств методов, там оказались “записи о”, а не сами работы и методы, с этим надо будет разбираться. Патч в A.15 про “работу” вроде уже сделан, но по тексту остались ещё какие-то остатки старой онтологии, их надо найти и поправить.
- доотладить P2W (principle-to-work) цепочку. Скажем, в задании до сих пор не переименованы полностью механизмы в U.MechanismRealization (ибо U.Mechanism тут оказывается более общим понятием) и вообще, именование надо бы проверить: все морфизмы только-только переименовались отглагольными существительными, но могут остаться какие-то рудименты.
- … дальше планов громадьё: на этом фундаменте вырастить недостающие паттерны для характеризации (скоринг, индикатризацию и т.д.), доделать TGA, а затем таки пройтись по архитектурным характеристикам и выйти окончательно на понятие архитектуры.
Тут, конечно, всегда есть развилка:
– ловить блох, напускать разные чекеры и аналитику, ибо в 3Мзнаков всегда найдутся нечёткие формулировки, граммотичиские ашипки, несовпадение входных и выходных параметров у морфизмов и т.д. (и да, я некоторое время этим и занимаюсь каждый день, чтобы чётче понять архитектурные проблемы, а не исправлять “по месту”)
– решать архитектурные проблемы, а не править снова и снова многочисленные ошибки, получающиеся при плохой архитектуре. Конечно, чеки вроде “проверь модульность” я сделал, грубые дыры уже почистил. Но фишка в том, что лечить надо обычно не симптомы, а болезнь. В предыдущем пункте ловля блох вроде “вот тут у вас формулировочка неясна” - это симптомы, болезнь они не вылечат. Можно бесконечно заниматься подобным поверхностным (“логическим”, поиск всяческих cognitive bias и пробелов в логике, вроде “у вас тут стрелочка выходит и никуда не входит, поправьте”) рефакторингом и полностью профукать накапливающийся архитектурный долг.
– решать проблемы на уровне первых принципов, ибо архитектурные проблемы чаще всего заключаются в бесконечной отладке архитектуре прошлого поколения, когда из первых принципов можно предложить чего получше. Онтология, семантика, эпистемология и так далее – заниматься интеллект-стеком фундаментальных методов мышления и править то мышление, которое занимается потом архитектурой.
Пока же наслаждайтесь тем, что есть (я точно знаю, что этими материалами уже пользуются для получения непоправимой пользы прямо на работе):
– спецификация FPF: First Principles Framework — Core Conceptual Specification (holonic).md — Яндекс Диск (3Mзнака, из TGA тут уже есть E.TGA и A.20)
– задание на TGA: Задание на TGA.md — Яндекс Диск (0.35Mзнаков)
Что с таким делать при текущих скромных возможностях и меня, и неестественного интеллекта от GPT-5 Pro (а это до сих пор топовая модель) работать с такими объёмами не-кода? С кодом-то проще, он же формальный. А тут – полуформальный текст, да ещё и по-русски как задание для пополнения и рефакторинга англоязычного FPF. Работает тут старинный рецепт: “Как съесть слона? По кусочку за раз! Запивая кофе”.
