На берегу Средиземного моря (в Белеке) в отеле all ultra inclusive кормят круглосуточно, цветёт жасмин и гибискус, а работа продвигается очень медленно. Но таки продвигается. Прошлое улучшение было в ведении механизма нормализации, а также предположением, что дальше надо будет доделать механизм скоринга, сравнения и ещё много-много других механизмов самых разных видов. “Механизм” оказался одним из важнейших понятий, первопринципным.
Очередное улучшение FPF – это введение понятия “механизма” прямо в FPF kernel. Поднимаем “механистичность” ещё на ступеньку: какой-нибудь ClaimScope задаётся унифицированным механизмом Scope (это уже было), а сам механизм Scope теперь задаётся унифицированным “механизмом механизмов”, для чего мы сделали паттерн “A.6.1 — U.Mechanism · Law-governed signature for a GovernedSubject on a HostSpacecharacteristic on a HostSpace”. Теперь можно будет сравнивать механизмы, порождать новые виды механизмов, улучшать механизмы, использовать альтернативные реализации механизмов и т.д. А ещё мы задействовали мировой SoTA опыт создания аналогичных механизмов и частей подобных механизмов.
«Механизм» в FPF ближе всего к алгебраически специфицированной сигнатуре с законами — то есть к публично объявленной сигнатуре, у которой
(1) есть тип пространства значений и значение/состояние характеристики,
(2) указана алгебра допустимых операций,
(3) прописаны инварианты/условия/guards и
(4) определены правила кросс-контекстного переноса между предметными областями со штрафами за “неполное соответствие”
Механизм - это именно “механизм”, то есть не метод и не «реализация метода». Это “сигнатура с правилами” над методами, которая ограничивает и направляет допустимое механизмов множество реализующих механизм методов. Механизм также не просто “сигнатура”, а “сигнатура-на-стероидах”: с довольно специфической обвязкой. Механизм не дублирует сигнатуры архитеорий, это более общий эээ… механизм!
И тут же выяснилось, что “сигнатура-на-стероидах” базируется на понятии сигнатуры, которое присутствовало уже в FPF, но только как сигнатура архитеорий. Сигнатура, а не “интерфейс”, ибо нежить активно пыталась заменить любые похожие слова на “интерфейс”, но после этого немедленно появлялся боевой взвод виртуальных DevOps, хардкорных программистов и концептуальная работа становилась невидима за строгим data governance, работа со знаниями заменялась управлением работой коллектива программистов, забота шла о “машиночитаемости”, а всё концептуальное исчезало, ибо у программистов обычно примат формы над содержанием (и да, они возражают, им изнутри себя этого не видно, даже виртуальным программистам, хорошо отмоделированным LLM по живым образцам).
Поэтому ввели ещё и паттерн A.6.0 сигнатуры в общем виде – каких-то объектов, у которых может быть много разных реализаций. Сигнатура архитеории A.6 стала специализацией сигнатуры. А механизм - сигнатурой с обвязкой. И дальше два механизма, которые уже есть в FPF стали порождением вот этого “механизма механизмов”:
– USM (unified scope mechanism) работает над множеством срезов контекста (ContextSlices) и его алгеброй (∈, ∩, SpanUnion — объединение с заполнением промежутков, translate — сдвиг по характеристикам/осям контекста, widen/narrow, refit) с явным заданием периода (контекст по времени) Γ_time и кросс-контекстным переносом с потерями через Bridge/CL. ;
– UNM (unified normalization mechanism) — работает с классами допустимых нормализаций и порождаемыми ими эквивалентностями ≡_UNM для сопоставимых шкал, с классами преобразований «ratio:scale / interval:affine / ordinal:monotone / nominal:categorical / LUT(+uncertainty propagation)», а также с правилами аудита и валидности периодов (временнЫх окон).
А что там в SoTA дисциплинах на тему механизмов? SoTA дисциплины (взятые по нормам NQD, что уже прописано было в FPF) говорят, что в механизмах должны быть а) сигнатура, б) алгебра операций, в) законы/инварианты, г) правила применения и область действия. Вот что смотрели:
-
Алгебраическая спецификация / «Институции» (institutions)
В институциональной теории (Goguen–Burstall) и инструментах вроде HETS логика описывается как 4-ка “signature–sentences–models–satisfaction”; есть морфизмы/коморфизмы для переноса между сигнатурами/логиками. Это очень близко по духу: “сигнатура + инварианты + перенос”. Отличие FPF — явная «локальность по контексту» (BoundedContext) и маршрутизация потерь для надёжности R (штраф в зависимости от уровня конгруэнтности понятий в различных контекстах). И, конечно, выход на методы и в конечном итоге работу. -
Алгебраические эффекты и «обработчики эффектов» (effect handlers).
В языках программирования после 2015 идёт активная унификация операций/эффектов через “подписанные операции + обработчики + законы” (Koka, Effekt, OCaml 5 с effect handlers), тот же принцип: “сигнатура операций → реализация/handler”, плюс статически отслеживаемая область действия. Это похоже на то, как USM «разрешает/запрещает» применение метода по срезу контекста (context slice) и как UNM допускает лишь «классы» нормализаций. Разница: в FPF пространство значений и гварды — кросс-дисциплинарные (claim/work scope; evidence windows), а перенос между контекстами штрафует доверие (R), а не «тип». -
Policy-as-Code для гвардов (например, OPA/Rego: open policy agent, и язык задания полиси Rego как наследник DataLog - Policy Language | Open Policy Agent)
ODD/ISO 34503:2023 задаёт таксономию и формат описания условий, где ADS может безопасно работать — это очень близко к Work scope (пространство значений — capability, а не знание). Отличия: FPF типизирует операции над областью (∩/SpanUnion/translate), вводит обязательный Γ_time и отделяет «scope» от «доверия/свежести» (R). Ещё пример: ASAM OpenODD, a modeling approach and exchange formats to specify and describe operational design domains (ODD) for automated driving systems). -
Session Types / Typestate-ориентированное программирование.
Поведенческие типы/тип-сосостояния формально ограничивают разрешённые последовательности/состояния операций; это похоже на FPF-гейты для ролей и методов в части выполнения работы: Method–Work по WorkScope и “разрешаемость” состояний в RSG/Green-Gate. Отличие: FPF оперирует не только последовательностями, а ещё и множествами срезов контекстов, а также кросс-контекстными мостами со штрафами к неполным соответствиям.
Так что вовне FPF его механизмы можно объяснять как «алгебраизованная сигнатура с законами и политиками применимости», где “сигнатура” и “законы” задают пространство допустимых реализаций/методов, а “scope+policy” определяет в каком контексте и с какими допусками эта сигнатура может быть использована.
Конечно, тут же вскрылось много нового:
– понятие характеристики оказалось перегруженным (механизмы работают отнюдь не только над измеримыми значениями, но и над странными объектами типа “множество срезов контекстов”, ибо это и будет “область применимости”. Это только-только начали чистить, и надо будет довести до конца: “характеристика это то, что можно измерить”.
– некоторые вроде бы “характеристики” и в жизни оказались сложными структурами: часть архитектурных характеристик (quality characteristics, -ilities) вполне измерима, а вот в других характеристиках измерения оказались только одним из слотов. Пришлось ввести понятие Q-bundle для таких характеристик (новый паттерн C.25), и даже capability “измерения” имеет только одним из слотов. С этими -ilities придётся ещё разбираться дополнительно.
– развалилась конструкция FGR, это теперь не “пространство характеристик эпистемы”, ибо G (Scope) оказался набором/set срезов контекстов по USM, а это никак не похоже на характеристику. “Универсальность” и “общность”, конечно, можно считать – но это не будет Scope, “область, где работает механизм”. Поэтому FGR теперь components, а не характеристики, причём непонятно чего, а не пространства.
– понятие архитектуры так и не стало ближе. Хотя уже сегодня можно задавать вопрос “что это онтологически” и получать интересные ответы про “архитектура из FPF по сравнению с архитектурой из ISO 42010”. В FPF две важных особенности, 1. “контекстуальность: локальность смысла и переносимость со штрафами”, а не просто “есть view и viewpoint”, что предотвращает «магическую совместимость» описаний, которая всем мерещится в ISO 42010 - но в жизни её нет, в FPF это явно. 2. Многокритериальность-портфельность, ибо “архитектура” оказывается не одна и акцент сразу на портфеле, ибо trade-offs даёт не просто “выбор одного на Парето”, а ещё ведь надо учитывать evolvability. Это всё, конечно, предварительные соображения.
– и да, надо продолжать разбираться с механизмами измерений-сравнений (там ещё ведь после нормализации будет скоринг и ещё много чего другого).
– и теперь ещё разбираться с этими “композитами” из характеристик (измеримых) и всякого другого. Ибо “механизм” тут только один из таких композитов.
– и продолжать разбираться с сигнатурой в общем виде, ибо это дорожка ещё и к сигнатуре метода, и к аффордансам (и эта дорожка лежит через понятие capability)
– и надо что-то делать с types и kinds, ибо сильно путаются.
– … это можно продолжать и продолжать. Жду с нетерпением новых LLM, с ними жизнь обещает стать веселее.
А пока надо пить кофе и наслаждаться в баре на пляже (где я пишу эти строки) последнюю пару часов разницей температур между Москвой и Белеком в 20 градусов, тут сейчас 25 этих градусов, в Москве - 5 таких же. Сравнение температур - любимый пример для обсуждения “характеристик” и того, что можно, и чего нельзя делать со шкалами. Например, можно сказать про “масса А вдвое больше Б”, а “температура в Белеке впятеро выше, чем в Москве” - нельзя. Характеристики, измерения, сравнения - это вполне первопринципные понятия. Скажем, в экономике вся дискуссия кардиналистов и ординалистов - она об этом, концепция “цены” без этого непонятна вообще. Нигде этому не учат, и даже мы в МИМ явно недостаточно внимания уделяли этому. Вот, исправляемся, под приятную босса-нову в пляжном баре и иногда в кафе с аутентичным турецким кофе. Научно-практическая дольче вита, двадцать первый век таким и должен быть.
Обновления FPF брать там же: First Principles Framework — Core Conceptual Specification (holonic).md — Яндекс Диск (там сейчас уже 2.9M знаков).
