Продолжаю потихоньку рефакторить задание на principled enactment architecture, как теперь (опять “пока”) она называется. Удивительно, но мои тексты в блоге и текст FPF читают, несмотря на всю их “заумность”, так что мне было много точных вопросов про “сигнатуру” и аксиомы-постулаты из предыдущего опубликованного варианта задания (30 октября 2025, “Тема недели: математика-физика-инженерия в FPF”, Тема недели: математика-физика-инженерия в FPF: ailev — ЖЖ). Всё это подробно разъяснялось в руководстве по интеллект-стеку, но вот пришло время это пустить это знание в дело. Да, в вузах этому не учат, даже в инженерных вузах, ну штош.
Несколько дней работы в паре с GPT-5 Pro показали, что:
– для математики надо завести собственный морфизм U.FormalSubstrate, который выдаёт мат.объекты с хорошо понятным поведением как язык для всей цепочки.
– термин “сигнатура” используется в трёх значениях: 1. место, где лежат какие-то “законы” с понятным к ним типом обращения, наши паттерны A.6.0 и A.6 закрепляют именно это значение, оставили этот термин для паттернов. 2. Место, выдающее постулаты (и оно типа “сигнатура”, поэтому так и назвалось поначалу) в нашей цепочке морфизмов principles enactment architecture. 3. Публикационный/интерфейсный/“заголовок с параметрами” характер термина, вроде OpSig или MechSig.
– и вот тут пришлось ввести морфизмы публикации для интенсиональных объектов в A.7 (как сделать описание такого объекта и как описание формализовывать дальше), а ещё добавился E.17 MVPK (multi-view publication kit)для правил публикации описаний интенсиональных объектов (по факту - как весит “записи для мышления письмом”, пока этот термин “публикация” не правлю). Заодно поставил облегчённые профили публикаций для слабой формализации в этом E.17 и послабления для проверок в ATS E.11. Общий принцип послаблений: “можно заполнять меньше полей, но не менять содержание полей публикации” (поля - это в “карточках” записей для мышления моделированием). Там много интересного, например, это всё multi-views по ISO 42010.
– почищена деонтика в терминах (вспомнили, что у нас есть Rule-of-Constraints, RoC в E.11), и ещё отработано заклинание “посмотри что там со смыслом и онтологией, затем подбери Tech и Plain по F.17, а начальные значения возьми по NQD из части G”. Пишу каждый раз заклинание из головы, чуть разными словами, и оно отлично работает! Надо бы ввести где-нибудь аббревиатуру, уж больно часто приходится на эту тему заклинать.
– а дальше было два шага: введён Single-Writer Principle (SWP) и явная проверка на модульность (coupling и cohesiveness). И много-много шагов, чтобы утрясти входы-выходы (интенсионалы) и публикационные “лица” (surfaces и faces).
В итоге задание сейчас тянет на 51Кзнаков (текущий вариант задания: Задание на principled enactment architecture в FPF.md — Яндекс Диск, там для удобства прямо с текущим промптом, а текущий текст FPF всё там же – First Principles Framework — Core Conceptual Specification (holonic).md — Яндекс Диск). В этом задании две части: в первой расписана цепочка морфизмов “от математики через физику к выполнению работы, а затем отслеживанию сделанного” (U.FormalSubstrate → U.PrincipleFrame → U.Mechanism → U.ContextNormalization → U.SelectionAndBinding → U.WorkPlanning → U.Work → U.RefreshAndEvaluate).
Как это понять? Давайте разберём на кофеварке, любимый пример, приведём ровно как это выглядит в задании:
U.FormalSubstrate: дифференциальное исчисление для баланса масс/теплаU.PrincipleFrame: постулат «экстракция — функция помола/темп‑профиля/давления» + Measurement‑CHR (TDS, °C, бар; ReferencePlane=world).U.Mechanism: MethodFamily={capsule-espresso, capsule-lungo}; LawSet как баланс масс/тепла при фиксированном давлении помпы; AdmissibilityConditions: капсула ∈ {Nespresso-совместимые}, T ∈ [88, 94] °C (фактический диапазон капсульных), порция воды дискретна.- U.ContextNormalization: CG‑Spec (единицы, шкалы, плоскости), ComparatorSet (Pareto; медоида для ординалов); Transport(Φ) — только из реестра UNM.
- SelectionAndBinding: «ParetoOnly» по {вкус/телесность/горечь} с архивом режимов;
- WorkPlanning: расписание, калибровки (EvidenceHooks).
- U.Work: привязка значений запуска (граммы/сек/темп), телеметрия.
- U.RefreshAndEvaluate (G.11): издания компараторов/калибровок, портфель вкусовых профилей.
Дальше в задании расписано некоторое количество самых разных проблем, при этом кроме проблем там ещё и приводится набор решений. Задание тут в том, что проблемы в нём надо переводить в решения, которые исполнять как задачи. Часть найденных проблем я уже перевёл в задачи, а задачи выполнил, это уже ушло из задания. Вся эта “разработка архитектуры” явно не “водопад” со слоганами вроде “мужик сказал – мужик сделал”. Нет, “мужик много говорит – мужик что-то из этого делает, затем опять много говорит, и так всё время”. Когда вы читаете эти строки, состояние проекта будет опять другим. Так, прямо сейчас:
– я решаю проблему с SoD, ибо это то State-of-Done в одном месте и Separation-of-Duties в другом месте. И надо было ещё разобраться, что это LLM так разносит на этом SoD. Теперь разобрался, надо залатать.
– я до сих пор недоволен вот этим SelectionAndBinding, ибо мне кажется, что там где-то уместен Grounding вместо невнятного Binding как “ход от умозрения к земле”. Намётки есть: вроде как засада того же типа, что и с сигнатурой как публикационным объектом: binding про “карточки” и публикации, а grounding и selection про интенсионалы, нужны все три – дребезг опять-таки из-за перегрузки, “три смысла двумя словами”. Selection нельзя бросать, это же из decision theory, это свобода – выбор из множества альтернатив, когда есть из чего выбирать (несвобода - это когда альтернатив нет. Альтернативы – это сразу Парето, портфель, архив, а ещё всё на свете устаревает, Парето движется – и поэтому “телеметрия” и обновления. Но если путать этот свободный выбор, заземление на измерения и записи обо всём этом – запутаешься. Будем распутывать.
– решение по U-Scope в задании есть и активно используется, но это очередной извод generality, тут уже десять раз на грабли наступали, поэтому я не очень доволен, это наверняка мина замедленного действия. Я уже понял, что нужно делать полный набор механизмов характеризации, с чего всё и началось. И уже с ними всеми вместе обсуждать эту “шкалу общности”. И тут проблема курицы и яйца: чтобы определить механизмы, надо определить что такое механизм и где его место в архитектуре, а для этого нужно как-то характеризовать механизмы эээ… механизмами характеризации, которые я как раз и хочу сделать.
– … и такого много, поглядите в задание, там не всё, у меня есть и другие идеи о том, что там надо срочно делать, я их даже в предыдущих постах приводил, но там не так много сделано ещё, сколько бы хотелось.
В любом случае, это пока только задание на создание архитектуры (короткий вам тест: вы отличаете архитектуру как интенсиональный объект от архитектурного описания? Если нет, то вам будет не очень понятно, что там с “публикациями” и чем они отличаются от “входов-выходов” морфизмов, описываемых в задании). Это задание даже ещё не оформлено в виде ADR, как положено делать с архитектурой. При этом сам FPF это ведь по факту набор ADR, это же язык паттернов по форме изложения (классические intension → Problem frame → Problem → → Solution → Conformance Checklist → не очень классический Archetypal Grounding → Rationale → Consequences → SoTA-Echoing → Relations to other patterns). Поэтому “оформление в виде ADR” (написание и редактирование паттернов FPF) и будет “выполнение задания”, очень удобно. Но вот этот шаг – как эту архитектуру “математика-физика-инженерия”, она же “от мысли к делу”, она же “воплощение от первых принципов” реализовать в текущем тексте FPF – отдельный трудный вопрос.
Пока я занят тем, что убираю много разных мелких несоответствий, об которые спотыкается LLM. Большинство из этих несоответствий связано с плохой лексикой. Например, LLM сбивается (как и живые люди) на перегруженных словах: если в тексте “косил косой косой косой”, то в этом месте всё плохо – и пока не разгребёшь эту многозначность, будет тупить. Проблема с SoD (State-of-Done в одном месте и Separation-of-Duties в другом месте) как раз пример такого. Я вот думаю, не сделать ли какую метрику по лексике, чтобы оценивать качество текста? Какой-нибудь semantical collision rate (но это одby индикатор, а анти-Гудхарт говорит, что индикаторов должно быть некоторое количество, надо честно выполнить характеризацию по механизмам, которые я ещё не сделал!), чтобы отслеживать накопление онто-лексического, сиречь, семантического долга. Классический Fitness function на E.10 с подпаттернами. Если кому-то интересно, сделайте, плиз! У меня у самого руки пока не дойдут до такого.
Так что убираем мелкие огрехи сначала, чистим-блистим лексику, разгребаем невнятную онтологию. Найти источник проблемы чаще всего легко, но вот затем выплачивать онтологический и лексический долг – трудно и долго. А главное, результаты почти не видны, если ты сам не разработчик и не упираешься в это лично. Время уходит, а хорошо видимого внешнего результата – нет.
Но овчинка явно стоит выделки, моё обоснование тут можно начинать так: “Во-первых, это красиво”. Ну, и это я точно первыми принципами занимаюсь. Это точно продолжение моей работы по интеллект-стеку: идея про “всё сидит на математике-логике, связано с физикой и физичностью мира, а занимаемся мы инженерией и менеджментом”. Это точно продолжение моей работы по системному мышлению, ибо оно оказывается только небольшой частью общехолонического мышления, прихватываем ещё и эпистемы. Это точно продолжение моей работы по методологии, ибо вот это principled enactment - это и есть ход “от математики и рассуждений к действию по изменению мира”. Поэтому я ещё поупираюсь, поглядим на результат. И инструмент у меня для этого подходящий, хотя я был бы благодарен мирозданию за LLM-модельку получше. Но я вообще с o3 начинал, так что GPT-5 Pro до сих пор выглядит подарком богов (посылаю этим небожителям лучи добра). Всё-таки приматы очень ограничены по своим биологическим способностям, палка-копалка сильно увеличивает их производительность по возне с землёй, экскаватор заставляет забыть про палку-копалку, гусиное перо увеличивает производительность по возне с идеями тоже сильно, а вот современные LLM (да ещё с возможностью подключения инструментария, например, ChatGPT можно попросить сделать grep по тексту на 3Мзнака) заставляют забыть про гусиное перо, чтобы тут же вспомнить, что homo sapiens - это всего лишь примат, весьма ограниченный биологическими мозгами – Приматы — Википедия ).
