Адекватное использование математики -- уже в FPF

ailev · 18.Май.2026 12:37:51

Новый паттерн: “C.29 - Mathematical Lens Adequacy (MLA)”
Я закрыл в FPF очередную кампанию, на этот раз про “C.29 - Mathematical Lens Adequacy (MLA)” – пригодность непосредственного (мимо “физической онтологии для grounding”) моделирования математическим аппаратом каких-то рабочих ситуаций. В английском имени паттерна остаётся Math Lens: по-английски говорят про “viewing through a lens”. В FPF C.29 закреплён как паттерн хода на первые принципы: как найти математический аппарат, который улучшает следующий инженерный шаг, и тут же назвать границы его применения. Это у меня была не кампания “про математику вообще” и не попытка сделать из FPF справочник всех красивых математических идей. Но если в проекте естественный язык уже не удерживает компактное и точное описание потока, зависимости, масштаба, сравнения, симметрии, состояния, переноса или скрытой потери, FPF теперь даёт короткий способ выбрать полезный математический аппарат: подобрать такие математические (идеальные, ментальные) объекты, поведение которых хорошо изучено и операции с которыми “в уме” как-то аналогичны тому, что происходит с какими-то реальными объектами в физическом мире.

Такая “подмена рассуждений в терминах физических объектов рассуждениями в терминах математических объектов” как раз то, чем занимаются физики, у которых даже “пространство” – вполне себе математический объект, а вовсе не физическая сущность в реальном мире. Физики честно рассуждают в терминах математических объектов – до тех пор, пока поведение их математических объектов в умозрительных операциях в определённом смысле и узком каком-то аспекте напоминает поведение реальных физических объектов (то есть результаты вычислений примерно предсказывают результаты измерений). Если это поведение математических объектов перестаёт с нужной точностью в каких-то ситуациях напоминать поведение реальных объектов, то физики просто подбирают другие математические объекты с другим поведением. Скажем, евклидову геометрию заменяют на риманову – переходя от ньютоновской механики к теории относительности. Подробно у меня это рассказывается в разделах “Физика” и “Математика” руководства по интеллект-стеку (Aisystant).

Вот новый паттерн C.29 как раз говорит, что так и надо делать не только физикам, но и всем остальным: если в каких-то удобных для математического моделирования ситуациях нужного математического аппарата ещё нет, то паттерн предлагает им озаботиться поиском такого аппарата, продемонстрировать выигрыш от такого моделирования и сразу обозначить область применимости (scope). Ну, или вы можете попросить AI-агента ответить на вопросы паттерна: паттерн чётко формулирует при этом, что должно быть в ответе – вы сами можете и не догадаться всё это попросить.

Если в проекте уже звучит “у нас тут граф”, “это похоже на поле”, “система ведёт себя квантовоподобно”, “здесь нужно латентное пространство”, “эта организация – сеть”, “это можно понять через категорию”, “ML-модель выучила физику”, и даже “у нас есть цифровой двойник”, то паттерн помогает такое обнаружить и задаёт контрольные вопросы по инженерной пригодности этой неявно втаскиваемой в разговор математики: что именно эта математика помогает увидеть, что без неё не получится, что в модели она сохраняет, что теряет, что позволяет сделать в проекте и где находится условие для её неприменения ввиду бесполезности.

Математика в инженерной и управленческой работе появляется уже не только в расчётах балки, гидравлики, надёжности или очереди работ. Развитая математика очень полезна, если она уместна. Но не все различают евклидову и риманову геометрию, поэтому красивая математическая фраза может быть глубоко неверна, никак не соотноситься с реальной жизнью, но в чьих-то глазах она начинает выглядеть как знание, доказательство, причина, гарантия, разрешение действовать или даже как настоящая онтология предметной области (да, работы Вольфрама как раз такие: “компьютер на небе”, как об этом говаривал Дэвид Дойч). Эта “художественная математика” знакома всем: “мы представили организацию как граф, поэтому центральность узла графа показывает, кто реально главный”; “модель показала кластер, значит это настоящие типы клиентов”; “симуляция показала этот вариант как лучший, значит можно менять регламент”; “в embedding видно небольшое расстояние, значит эти объекты действительно близки”; “если байесовская модель предсказывает плохо, значит ситуация должна моделироваться как квантовоподобная”; “если нейросеть хорошо аппроксимирует физический процесс, значит она выучила закон природы”; “если категория красиво описывает интерфейсы, значит у нас всё композиционно”. Можно продолжать и продолжать, вся современная инженерия пронизана такими высказываниями. Иногда это подсказывает полезный ход на математическое моделирование, но часто – просто престижная математическая краска поверх слабого рассуждения.

Главная мысль C.29 в том, что полезный математический способ рассмотрения – это сжатие описания с инвариантами и явно объявленными потерями. Сжатие, потому что математика убирает часть деталей и оставляет структуру (я обязательно вернусь к понятию структуры, когда через месяц-другой займусь понятием архитектуры как дисциплины, изучающей структуру, смотрите заметки в От контекстного окна к виртуальной памяти: skills-пакеты FPF и архитектура подкачки знаний: ailev — ЖЖ, а затем большой текст из двух частей Position paper про "длинногоризонтное мышление" (long-CoT) как мышление письмом/моделированием (1/2): ailev — ЖЖ и Position paper про "длинногоризонтное мышление" (long-CoT) как мышление письмом/моделированием (2/2): ailev — ЖЖ, это же сказано в исходном плане работ от 1 февраля 2026, Начинаем февраль 2026: громадьё планов по FPF: ailev — ЖЖ). Инварианты нужны для указания, что именно сохраняется при математическом (идеальном, умозрительном) рассмотрении. Потери, потому что всё остальное не исчезает из мира, а просто больше не представлено в модели – математическое моделирование обычно исходит из онтологической посылки открытого мира (“что не сказано, то просто не сказано, хотя в мире вполне присутствует”). И ещё нужен видимый следующий ход по использованию самого FPF: что теперь можно честно посчитать, сравнить, проверить, запретить, уточнить, отложить или передать для рассмотрения с помощью какого-то соседнего паттерна FPF.

В текущем C.29 сформулирован Mathematicalization Utility Principle: математический аппарат стоит вводить только тогда, когда он меняет следующий допустимый ход в инженерном процессе. Математический аппарат может показать сигнатуру, переменную состояния, симметрию, инвариант, границу, вариационный принцип, ограничение ресурса, вероятностную неопределённость, препятствие, различение с другим конкурирующим математическим аппаратом или оказаться языком рассмотрения чего-то другого, что надо честно передать для нахождения решений в текущей проблемной ситуации с помощью паттернов C.28, F.9, C.16 или каких-то других. Если следующий инженерный ход не меняется, это обычная проза, дидактическая метафора или NoMLANeededNote (“заметка о ненужности адекватного математического аппарата”).

Вот эта последняя ситуация с “математика вам не нужна” особенно важна. Если математическая фраза уже стала точным описанием ситуации, математическая модель выбрана правильно, но после неё всё равно непонятно, что делать, то применение уточняющих математику паттернов FPF не даёт выигрыша. Замена туманной красивости псевдоматематического языка на аккуратный, но мёртвый математический язык без выхода в деятельность – это был бы плохой результат от использования FPF. Паттерн C.29 поэтому устроен не как требование “заполните огромную карточку на любое встретившееся математическое слово-триггер и уточните ваш матаппарат”, а как дешёвая развилка (trade-off): математика тут вообще нужна или для красивого словца? Достаточно одной строки или формулы-леммы-теоремы? Нужна маленькая карточка как чеклист? Нужен ли полный профиль пригодности матаппарата и труды по его заполнению? Или ваш вопрос должен решаться не абстрактной “математизацией” в паттерне C.29, а в других содержательных паттернах, и C.29 должен отправить в эти паттерны – например, паттерны, занимающиеся причинностью, измерениями, обоснованиями (assurance), мостами между проектными контекстами, и т.д.

FPF – это про первые принципы, поэтому C.29 явно отсылает к математическим первым принципам
Эта кампания была важна потому, что математизация кратчайшим путём выводит на мышление от первых принципов, и паттерн C.29 ровно это и реализует.

Опора на первые принципы в FPF закреплена явно в E.1 (про миссию FPF, “операционная система мышления” как раз там, и будем это потихоньку двигать в коллективное мышление и ещё коллективное действие), а также в паттерне E.2 The Eleven Pillars: в E.2:4 перечислены одиннадцать столпов/pillars – опорных принципов, обязательных для FPF. C.29 не добавляет к ним новую “математическую конституцию”, а делает их проверяемыми для применения математического аппарата.

Напомню: есть 100500 (и даже больше) способов сделать что-то неправильно на каждый один способ сделать правильно. Например, число невычислимых функций в бесконечное число раз больше числа вычислимых функций (конечно, с бесконечностями трудно рассуждать, но вероятности на бесконечностях отлично работают, смотрите подробней в книгах Дойча): если вам нужна какая-то функция, то наткнуться на невычислимую функцию проще простого, вычислимую подобрать труднее, а уж не любую, а именно подходящую под вашу ситуацию вычислимую функцию подобрать совсем трудно. Физика ровно поэтому трудная наука: один из тестов для современных моделей AI – это про то, может ли AI, обученный на трудах до 1911 года, создать теорию относительности, как это сделал Эйнштейн. Вся математика на месте, надо только подобрать формулы так, чтобы результаты вычислений лучше соответствовали результатам измерений. Это трудно, очень трудно, пока этого не удалось достичь. Если вы пользуетесь первыми принципами и ограничиваете свою свободу творчества как свободу говорить любую чушь, то вы изо всего пространства возможных высказываний, которые можно сделать “на математическом” попадёте в ту область пространства, где эти ваши высказывания будут полезны для проекта.

Согласно C.29 надо явно назвать кандидатный математический объект, моделируемую этим объектом математическую структуру, заведомую потерю, видимый выигрыш от математизации, следующий допустимый ход рассуждения, границы с соседними дисциплинами и стоп-условие в области применения (scope). Если вы самоограничите себя этими условиями, вы с большей вероятностью скажете на языке математики что-то полезное, а не просто художественно-иллюстративное. Это и есть роль первых принципов: задать самые общие ограничения, отсекающие огромные области бесполезных высказываний, в данном случае – математических высказываний. Вот основания/столпы FPF (pillars) из паттерна E.2 The Eleven Pillars, в C.29 они проявились так:

P-1 Cognitive Elegance требует выделять структуру, которая решает проблему, а декоративную формализацию убирать. Если выбранный математический аппарат не меняет следующий инженерный ход, он не элегантен, а декоративен. Красивое слово “топология” не лучше слова “связность”, если из него не следует ни новый замер, ни новый запрет на перенос знания между предметными областями, ни новый способ сравнения, ни новое условие остановки ввиду пересечения границы применимости матаппарата (StopCondition). Хорошая математика не делает текст длиннее ради солидности. Она делает ситуацию короче в правильном месте: “вот что сохраняется, вот что теряется, вот почему теперь можно сравнить только это с тем и нельзя делать вот такой вывод”.
P-2 Didactic Primacy говорит, что понимание человеком важнее чистоты формализма и удобства инструмента. Поэтому C.29 начинается не с полного набора полей карточки-чеклиста применения матаппарата в проекте, а с первой рабочей проектной ситуации. Инженер или менеджер видит фразу “поток задач – это очередь” и должен за минуту разобраться, что дальше спрашивать, чтобы уменьшить неопределённость высказывания: где поступление новых работ в эту очередь, где храним незавершённую работу, где взять время обслуживания, где узкое место (если уж скопилась очередь), какие типы работ вообще сравнимы, чтобы их отождествить как “тип работ для этой очереди”. Он не должен сначала читать длинный формальный трактат “про очереди и математическое их выражение”. Формальность появляется тогда, когда она уже нужна.
P-3 Scalable Formality в C.29 работает почти буквально. Один и тот же материал может начать жизнь как осторожная рабочая догадка, затем стать чеклистом в одну строку MLA.OneLine, потом коротким чеклистом MLA.MiniCard, а при публикации, сравнении, бенчмарке, прогнозе, assurance input или переносе между контекстами (только там, где это критично) – полной карточкой “математического допроса” MLA.FullCard. Не нужно разрывать документ и начинать заново. Нужно повышать подробность и формальность матаппарата ровно там, где растёт риск его некорректного использования.
P-4 Open-Ended Kernel удерживает C.29 от превращения в новый центр FPF. Никакое семейство математики не попадает в kernel как универсальная онтология, “мир устроен математически – и это вот такая математика, вот такой матаппарат”. C.29 не делает заявления, что “теория категорий нас спасёт” или “теория квантовых полей даст ответы на все вопросы”. Нет, ядро FPF стабильно, а матаппараты могут быть разными.
P-5 FPF Layering удерживает C.29 как паттерн в Part C: он помогает проверить пригодность математического аппарата для текущей ситуации, а привязка к предметному вопросу (причинность, измерения, evidence, assurance, bridge, решение, работа и так далее) остаётся у соседних паттернов.
P-6 Lexical Stratification про язык, которым говорим о математике. В русской инженерной речи можно сказать “посмотреть как на очередь”, “описать как динамическую систему”, “взять аппарат теории графов”. Это нормальные понятные фразы. Но если такая фраза начинает использоваться как строгое высказывание и лежит в основе решения, доказательства, причины, сравнения, допуска, то её придётся уточнить: какой математический объект, какой способ отображения, что сохраняется, что теряется, какая область применения, какие данные или замеры нужны, где стоп в области применения (этот ряд чеклиста мы уже несколько раз тут приводили). Паттерн следит, чтобы было “говорим понятно”, а не “говорим красиво, но неясно”.
P-7 Pragmatic Utility напоминает: математические доказательства, корректное сравнение с результатами измерений каких-то характеристик, моделирование как таковое существуют для работы, а не для подпитки самоуважения автора или возможности получить одобрение классического “reviewer №2”. Математический аппарат полезен только если он помогает принять решение, отложить решение, выбрать проверку, провести сравнение, снять ложную претензию, ограничить область применения или найти место, где нужна другая дисциплина. Если после формализации стало только “строже звучит”, но не стало яснее, что делать, это не повышает прагматическую полезность, усилия по формализации не нужны – оставляйте всё как есть.
P-8 Cross-Scale Consistency важен потому, что математический аппарат часто кажется переносимым между масштабами: узел в графе, поток, очередь, поле, coarse-graining, локально-глобальное отношение, симметрия или граница будто бы “те же самые” на уровне человека, команды, организации, рынка или технической системы. C.29 требует назвать, что именно сохраняется при смене масштаба, что меняется, где начинается потеря структуры и где нужен соседний паттерн вместо свободного переноса. Это и есть системное мышление (одинаковое для всех уровней масштаба, а также явные спецификации, что происходит при смене масштаба).
P-9 State Explicitness не даёт математике прятать состояние. Если речь идёт о state space, динамике как законах движения по каким-то траекториям в пространствах характеристик, наблюдении (измерении), имитационном моделировании, learned representation или цифровом двойнике, надо явно сказать, состояние чего именно рассматривается (describedEntity для какого groundingHolon), в каком окне времени, какой переход или наблюдение допустимы, какое основание (в английском – support) есть у применения и где StopCondition (да, всё те же вопросы математического чеклиста). Без этого “модель состояния” легко становится красивым именем, не имеющим никакого отношения к возможным предсказаниям этого состояния – и поэтому не нужна.
P-10 Open-Ended Evolution и P-11 SoTA Alignment важны потому, что математика вокруг инженерии сейчас действительно быстро меняется. Geometric deep learning, SciML, neural operators, causal representation learning, physics-informed machine learning, probabilistic programming, optimal transport, category theory in engineering, quantum-like modeling, modern Bayesian experimental design, optimal experimental design, active learning и Bayesian optimization – всё это не надо запрещать как “новомодную терминологию”, но и нельзя тащить в FPF просто потому, что “это же новое”. SoTA даёт кандидатов на математический аппарат и вопросы к проверке, а не готовое право утверждать, что “так устроен мир”. Поэтому в текущем C.29 у SoTA-источников явно указана роль: принять как опору, адаптировать, использовать как подсказку для поиска аппарата, как stress-test или как recognition cue. Источник может подсказать хороший аппарат, но не становится доказательством, причинностью, assurance или release-confidence сам по себе. Так, у свежей статьи Ванчурина (https://www.researchgate.net/publication/404659508_The_Self-Learning_Universe) берём идеи по унификации самой разной математики в части её первых принципов, но более осторожно относимся к физической части (которая в статье является главной), то есть к идее самообучающейся вселенной. Тем не менее, эта статья попала в SoTA-echoing раздел паттерна, математика там интересная.

И, конечно, C.29 опирается и на A.7 Strict Distinction: модель не равна моделируемому миру, описание не равно объекту, граф не равен организации, симуляция не равна факту, embedding не равен смыслу, математическая элегантность не равна доказательству, validation не равна verification, explanation не равна assurance, причинный вывод не равен корреляции и так далее. Именно жёсткость в проведении таких различений и делает FPF не набором красивых слов, а инженерной дисциплиной мышления письмом. Жёсткость в проведении таких различений тренируют у людей во всех наших резидентурах рабочего развития, с первой по десятую, без этого никак. Когда вы читаете эти строки, вам всё понятно. Когда начинаем смотреть, что вы делаете в своих рассуждениях по поводу рабочего проекта – ой. Но ничего, этим различениям можно научиться.

Иногда рабочая ситуация сама просит математический аппарат: поток задач плохо виден без очереди, зависимость изменений плохо видна без графа, сравнение случаев плохо видно без явно выбранной меры расстояния в каком-то многомерном пространстве характеристик, изменение масштаба плохо видно без понимания coarse-graining, перенос между интерфейсами плохо виден без прояснения композиционной структуры. В таких местах C.29 помогает выбрать дешёвый первый кандидат и проверить, меняет ли он следующий инженерный ход. Обычная же математика остаётся там, где ей место. Если в модели надёжности есть Markov kernel, в расчёте прочности есть дифференциальное уравнение, в измерительной процедуре есть шкала и единицы, а спорного переноса между дисциплинами нет, то нет нужды открывать C.29. Математика сама по себе не преступление и не событие. C.29 становится нужен только тогда, когда математический объект, формализм, семейство моделей, learned representation или simulation substrate выходит в действие инженерного проекта: помогает выбрать, объяснить, спрогнозировать, сравнить, опубликовать, перенести смысл через bridge между контекстами (да, те самые bounded contexts из DDD, domain-driven design), дать надёжное инженерное обоснование (assurance) или повторно использовать модель в другой ситуации.

И если вопрос не про адекватность/пригодность матаппарата, то C.29 направит к “другим докторам”, которые лечат “другие болезни”. Если математическая модель говорит “вот возможный механизм”, это ещё не causal-use support – надо идти в C.28. Если модель даёт красиво оформленный результат, это ещё не evidence path – надо идти в A.10. Если формализм выглядит надёжно, это ещё не assurance – надо идти в B.3. Если сравниваются величины, нужны измерения и сопоставимость – C.16. Если смысл переносится между контекстами – F.9. Если речь о скорости, темпе, восстановлении, сходимости, окне времени – C.27. Если по модели выбирают вариант – C.11, а если начинают работу – A.15 и соседние паттерны про методы, планы и их связи с работами.

Не “сильная математика”, а пригодный математический аппарат
Сначала AI-агентам очень хотелось говорить про “сильную математическую линзу”. Это звучит ярко по-английски, но по-русски это двойная проблема: и калька с lens, и слово “сильная” без шкалы. Инженер сразу должен спросить (что я и делал): сильная по какой шкале? По выразительности? По доказательной силе? По переносимости? По вычислительной мощности? По объяснительной полезности? По способности выдержать validation? По праву поддержать решение? Если шкала не названа, слово “сильная” (математика, формула, что угодно) становится шумом. Поэтому в FPF итоговое имя – Mathematical Lens Adequacy, а по-русски лучше говорить “пригодность/адекватность математического аппарата”, причём эта пригодность к конкретной задаче, а не “вообще пригодность”. Важно, нужны ли вам квантовоподобность или ренормализационная группа в вашей задаче, а не нужны ли они сами по себе где-нибудь. Это чуть длиннее “силы”, зато честнее. Инженерный язык скучнее рекламного, но он выигрывает тем, что не даёт перепутать впечатление с реальной пользой для работы.

Пригодность/адекватность тут не означает “вся математика доказана до конца, всё строго”. Во многих задачах пригодность много менее строга, например analogy-only prompt: фраза помогает думать, но не может лечь в основу решения, “художественная речь”, будит воображение, полезные ассоциации – но не более. Иногда это diagnosticOnly: математический аппарат помогает увидеть препятствие или область применения, но не демонстрирует причину хоть с какой-то достоверностью. Иногда это simulation или empirical fit, где нужна validation posture (если не смогли перевести с английского, то вам это и не надо!). Иногда это общепринятая теория для какой-то предметной области, иногда машинное доказательство. Так что паттерн учит с подозрением относиться к фразе “математически обосновано”, есть разные степени обоснования, всегда надо уточнять.

Скажем, организация как quantum-like система. Иногда это не шутка и не мистика. Если порядок вопросов меняет ответы (у людей именно так, экспериментальный факт), измерение меняет состояние (хауторнский эффект), разные предметные области опроса несовместимы (опрос про безопасность даёт иные ответы “предпочтительного цвета крышки”, чем опрос про эстетику), KPI вдруг из индикатора превращается в “целевой показатель” и дальше работает закон Гудхарта, публикация показателя (“всего лишь замер, мы делаем его известным”) меняет поведение команды, quantum-like язык может быть полезен – он как раз для подобных ситуаций. Но этот язык не говорит, что организация физически квантовая, если моделировать её удобно в математическом аппарате квантовой механики. Физическая квантовая онтология не переносится, причинность не доказывается, решение не принимается только потому, что в модели появились “наблюдение” и “измерение”, и даже сама квантовоподобность тут не обязательная опция (“Байес не работает” ещё не означает “тогда берём квантовоподобность”). FPF теперь позволяет более-менее подробно обсуждать подобные ситуации.

Или нейронные суррогаты, или physics-informed models как ускорители традиционных инженерных расчётов. Имитационное моделирование ускоряется в десятки или сотни раз, типовые сценарии проходят быстрее. Но всё-таки надо сказать, на каком семействе задач модель обучалась, где и как проверялась, какие режимы она не видела и сумела ли на них генерализоваться, как оценивалась ошибка, что происходит вне области применимости и где границы этой применимости, можно ли заменить расчёт или только получить предварительную оценку – а потом всё равно надо считать “как всегда”, без нейросуррогатов. “Модель выучила физику” – слишком сильная бытовая фраза. Инженернее: модель аппроксимирует оператор в заявленном классе условий с такой-то ошибкой и такой-то проверкой пригодности результата для дальнейших действий в проекте.

В инженерии не надо запускать полный расчёт прочности, чтобы решить, можно ли поставить кружку на стол. Но если это не стол, а мост, не кружка, а эшелон с рудой, то нужны расчёт, допущения, материалы, коэффициенты, проверка, область применения и чья-то ответственность за то, что всё посчитано верно. С математическим аппаратом так же: чем больше последствий у “математизированной” фразы, тем больше надо её уточнять и проверять.

C.29 и другие математические паттерны в FPF

Главный новый паттерн кампании – C.29 Mathematical Lens Adequacy. Но математический аппарат многолик, поэтому он расползается по соседним паттернам: где-то как модель, где-то как объяснение, где-то как сравнение, где-то как основание для выбора. Поэтому кампания затронула не только сам C.29, но и привязала к нему соседние паттерны (главным образом добавила в список related patterns).

A.6.P получил связь с математическим субстратом (на английском вместо “аппарата” часто говорят “субстрат”, не пугайтесь) для восстановления точности отношений (relations, там ведь пятишаговый “конвейер”, в середине которого предлагается выбрать адекватную математику), но без права переносить онтологию исходной математической области в само отношение (скажем, онтологию вы выражаете на языке логики первого порядка – но это “просто язык”, а не онтология логики первого порядка). A.3.3 различает обычную локальную динамику и спорный математический аппарат для динамики. A.19 удерживает characteristic space и structural overlays, не превращая каждое расстояние (евклидово, махаланобисово или ещё какое – их много), порядок или топологию в предмет рассмотрения для C.29. C.18.1 и C.19.1 держат scale-law и Bitter Lesson линии, чтобы красивая математика не выигрывала у более масштабируемого способа только за счёт элегантности, нужна не собственно элегантность, а полезность.

C.26 стал явной специализацией для quantum-like modeling: quantum-like – это не physical quantum без отдельного физического основания. C.28 принимает causal-use вопросы: если математический аппарат начинает отвечать на “что поменять, чтобы получить эффект”, это уже не только C.29. C.27 принимает temporal claims: прогнозы, скорость, ритм, восстановление, сходимость и окна времени требуют своей проверки. C.16 удерживает измерения и сопоставимость, F.9 – перенос смыслов между контекстами, A.10 и B.3 – evidence и assurance, C.11 – решения, A.15 и A.15.4 – метод, план, выполненную работу и восстановление рабочих источников.

Были затронуты и паттерны объяснения, сравнительного чтения, representation transition и controlled semantic coarsening. Всего в кампании был затронут 22 паттерна, кроме C.29. Математики в FPF уже было немало.

Математический аппарат часто приходит не в виде “полной модели”, а в виде объяснения, выжимки, сравнения, упрощённого отчёта или перехода между представлениями. Именно там легко потерять смысл за красивыми и умными словами. Скажем, потерять потери. Это не тавтология: при математизации каких-то описаний часто теряют сведения о том, что было потеряно. “Обозначим скорость буквой V” – и всё, дальше только математика и формулы, но что при этом моделировании теряем, что остаётся за пределами модели? Паттерн C.29 как раз не даст про этот вопрос забыть, в его чеклисте вы на него наткнётесь (отвечать, возможно, будете не вы сами – но вашим AI-агентам ответить придётся, в этом и замысел).

Вот вам примеры запросов, которые теперь можно делать к FPF:

проверь текст по C.29, нет ли там ненужной математизации и не пропущен ли какой нужный математический аппарат
проверь, есть ли здесь ситуация без нужного математического аппарата: обычная речь уже скрывает структуру, а дешёвый матаппарат мог бы упростить или изменить следующее действие?
какие первые принципы (boundary, cohomology, symmetry, variational, RG, diagonal, composition, probability или information) мы забыли применить к тексту, и как их надо было бы применить?
в тексте какая-то математика, за которой скрывается предметная область вроде “теории решений”, “причинности” или другой общемыслительной дисциплины. Какая это дисциплина?
в тексте много математики. Что изменится в следующем инженерном действии, если мы примем этот математический способ рассмотрения? Если ничего не изменится, зачем он здесь?
… и как всегда, есть надежда, что в какой-то ситуации AI-агент сам догадается применить C.29 – и это спасёт ваш проект.