Темпоральная адекватность утверждений (temporal claims adequacy) — уже в FPF

ailev · 01.Май.2026 16:48:02

С.27 как паттерн семиотики в разговорах о производных по времени
В сентябре 2022 года я написал программный текст “Статика, динамика первой производной, динамика второй производной” (Статика, динамика первой производной, динамика второй производной: ailev — ЖЖ), в котором я высказал мысль о необходимости перехода не просто от статики к динамике (производная первого порядка пути по времени: скорость), но и рассмотрению ускорения, рывка и прочих производных более высоких порядков, ритмов и связи всего этого с какими-то усилиями, ибо без усилий никаких изменений получить будет нельзя. Этот текст я дал GPT-5.5 Pro и предложил написать про это набор паттернов. Нет, сказала GPT-5.5 Pro, это слишком узкая постановка вопроса. Надо вообще научиться говорить о времени и изменениях так, чтобы не забывать ни о ритмах, ни об усилиях, ни о чём таком. И при этом архитектурно ещё и не подменять понятие динамики. Подход близок к семиотическому: если встречается слово-триггер, которое как-то связано с изменениями (скорости, ускорения и прочее темпоральное разных порядков), то надо говорить об этом адекватно.

Я только что пополнил FPF (GitHub - ailev/FPF: First Principles Framework (FPF): Operating system for open-ended thought for engieering, research, and mixed human/AI teams: bounded contexts, auditable reasoning, decision records, and multi-view publication. · GitHub) паттерном C.27 по temporal claims adequacy (адекватность утверждений, связанных со временем) и правками к соседним паттернам. Получился просто огромный паттерн, 169К знаков. Там внутри одного паттерна пришлось развести значения сразу многих понятий: state, rate, rate-change, усилие, окно, сопротивление, инерцию, ритм, торможение, coasting, recovery, benchmark, promise, quality, viability, QL-routing, causal/evaluation и U.Dynamics. Это всё про адекватность разговора об изменениях во (производных по) времени. Нет, C.27 сам не определяет все эти понятия, но помогает найти паттерны, где с этими понятиями разбираются подробней. Теперь можно разбираться с ситуациями, которые в инженерно-менеджерском тексте прячутся за формулировками “ускорились”, “темп вырос”, “ритм/cadence наладился”, “адаптируемся быстрее”, “восстановление теперь за два часа”, “агенты ускорили отладку”, “релизный ритм стабилизировался”, “команда вошла в поток”, “инерция мешает”, “надо притормозить выкатку”.

В 2026 году уже недостаточно заявить “скорость/velocity выросла”, “выпуск/throughput удвоился” или даже “мы добавили AI-агентов, значит скорость обучения (learning rate) стала выше”. Такие заявления должны сразу вызывать вопросы об их инженерной состоятельности. Эти вопросы как раз и есть предмет паттерна C.27. Современная инженерия сложнее, надо ещё показать, что к этому привело и что из этого следует – показать владение ситуацией, а не пассивное наблюдение за происходящим. Наблюдать какую-то скорость — это ещё не знать, как её менять. Видеть тренд в изменении индикатора — это ещё не иметь модель вмешательства в ситуацию, чтобы управлять трендом. Уметь замерять красивые time-series — это ещё не иметь право обещать что-то в SLA, использовать как benchmark, делать какой-то dashboard, просить на этом основании бюджет или запускать проверки незнамо чего.

C.27 как раз про вот эту связь происходящего в проектах с заявлениями о скорости, ускорениях, торможениях, рывках. Нет, это не про физическую динамику, не про то, что теперь у команды есть U.Force, у процесса есть U.Mass, а у backlog reduction есть настоящее ньютоновское U.Acceleration. Нет, онтологического балагана не устраиваем. В FPF всё аккуратнее: C.27 занимается адекватностью каких-то утверждений о связанных с производными по времени (temporal claims). Речь идёт о привязке ко времени, явно и неявно проявляющейся в текстах – фразах из отчётов, утверждениях в поручениях, строчках планов, строчках бенчмарков, обещаниях и обязательствах. C.27 в FPF цепляется за это и спрашивает: “какие производные по времени эти фразы упоминают, хватает ли для этих выражений обоснований, или это художественная, а не инженерная речь?”.

Как говорят о производных по времени инженеры-менеджеры
Для инженеров-менеджеров это очень часто встречающиеся высказывания. “Мы на два спринта добавили людей на проверку кода, значит очередь задач будет разбираться вдвое быстрее”. Нет, само по себе “вдвое быстрее” из “добавили людей на два спринта” ещё не следует. Возможно, вы просто увидели текущую скорость разборки очереди. Возможно, вы заметили тренд. Но если дальше на этом основании просят бюджет, обещают срок, меняют состав команды или продают это как повторяемый способ работы, то это уже утверждение о вмешательстве во времени: intervention-sensitive temporal claim. В такой ситуации C.27 требует сказать, какое усилие приложено, в каком окне времени, чему оно сопротивляется, на чём основана оценка, для чего её можно использовать (supported use) и при каком условии её надо пересмотреть (reopen trigger, всё-таки сленг FPF сильно отличается от обычного инженерного разговора, тем более русскоязычного разговора. Всегда просите говорить не на сленге FPF, а на языке инженеров-менеджеров, а в случае русского языка “как говорят русскоязычные инженеры-менеджеры”). По Pearl это do-calculus высказывание, но C.27 тут его не обрабатывает: он может обнаружить, что утверждение уже похоже на причинное, но сам C.27 не требует сразу Pearl do-calculus. Если это дальше используется как причинное утверждение, придётся подключать причинную проверку, а C.27 не даст спрятать этот переход к причинности.

Другой пример: “Мы добавили использование инструментов AI-агентами (agentic tool-use), теперь ошибки находятся быстрее”. Может быть. Но больше обращений к инструментам (tool calls) — это не автоматически лучшее мышление и тем самым не автоматически нахождение ошибок. Или “мы дали больше контекста AI-агентам” — это не автоматически “работа будет быстрее, ибо у агентов стало меньше неопределённости”. C.27 учит различать план использования инструментов и контекста, фактическую работу с инструментами и контекстом и утверждение о производных по времени: что именно ускорилось, за счёт какого действия, на каком классе задач, в каком интервале, с какой ценой проверки, какое усилие нужно для совершения действия, что там сопротивлялось, какая была бы инерция, если бы не было действия, и так далее – очень много вопросов, которые C.27 не даст пропустить.

И ещё один частый случай: “Мы притормозили выкатку/rollout, значит всё стало хуже”. Тоже нет, ибо ускорение-торможение не любого процесса хорошо или плохо по умолчанию. Торможение, пауза, движение по инерции (coasting, “накатом”), восстановление/recovery, стабилизация/stabilization и перенаправление усилий могут быть как раз правильным анти-Гудхарт ходом, ибо кроме скорости даже выкатки есть и много других характеристик. Медленная выкатка иногда нужна именно для того, чтобы удержать нагрузку на поддержку, запас безопасности, внимание операторов и ритм реакции на инциденты в допустимых границах. SRE (site reliability engineering) говорит, что вообще никакой выкатки новых фич, пока не будет достигнута какая-то заранее заданная безошибочность – и это как раз SoTA: ускорение выкатки при росте числа ошибок неправильно, надо притормозить.

Главная развилка: состояние, скорость, ускорение
Главная новая развилка в C.27 дешёвая и понятная, она связана с производными по времени (dyn – это динамика, далее порядок производной):

Dyn0 — считывание/замер состояния (state reading): “сейчас в очереди 400 задач”, “сервис в деградированном состоянии”, “команда перегружена”.
Dyn1 — чтение/замер скорости, тренда или траектории (rate, trend, trajectory reading): “очередь уменьшается на 40 задач в день”, “среднее время восстановления/MTTR пошло вниз”, “релизы выходят раз в две недели”.
Dyn2 — утверждение о вмешательстве во времени (intervention-sensitive temporal reading), ибо если что-то ускоряется или тормозится, то это может быть и без вмешательства, но при планировании или обсуждении вмешательства надо обсуждать ещё и причины сопротивления или наоборот, разгона (может и не в строгом смысле causal inference, но хотя бы “менеджерской гипотезы” с хоть каким-то удержанием логики): “если добавить двух проверяющих на два спринта, очередь будет уменьшаться вдвое быстрее”, “если сменить ритм релизов/cadence, восстановление улучшится”, “если включить агента, скорость отладки вырастет”, “если притормозить выкатку, нагрузка на поддержку останется приемлемой”. Это “если” тут включено в формулировку только для того, чтобы подчеркнуть причинность. Обычно этого “если” нет, но паттерн C.27 всё равно отследит такое (если вы задействуете достаточно продвинутого AI-агента и правильно поставите вопрос).

Паттерн нужен не потому, что слова-триггеры “скорость”, “ритм”, “ускорение” или “инерция” опасны сами по себе. Более того, в обычных фразах эти слова останутся частями обычной речи, на них паттерн не обратит внимание. Паттерн не просто про лексику и даже онтологию. Он вполне семиотичен: кроме лексики и онтологии паттерн учитывает ещё и прагматику: C.27 включается там, где такая фраза с этими лексическими маркерами темпоральности начинает работать как основание для действия какой-то роли: в обосновании решения, плана, бюджета, сравнения/benchmark, контрольной проверки (gate), обещания/promise, выводится на табло/панель показателей (dashboard), свидетельствует о переносимости какого-то метода в другой контекст или переносимости метода на другой масштаб. Да, ситуаций много, это явно не полный список, это просто примеры.

Карточка для “мышления письмом” о производных по времени
Как обычно, паттерн требует “мышления письмом” и управляет вниманием, требуя заполнить короткую карточку. Конечно, это требование необязательно к вам лично: у вас может быть агент, который заполнит карточку за вас. Но вам надо проследить, что агент ничего не сочинил и что заполнение соответствует ситуации. Вот поля этой карточки:

утверждение об изменениях во времени: та фраза (а не одно слово!), которую надо проверить – что именно текст обещает, объясняет или использует как основание для действия.
какое изменение по времени заявлено: ускорить, замедлить, притормозить, восстановить, стабилизировать, удержать ритм, перенаправить усилие, дать движению продолжиться по инерции/накатом/coasting. “Ускорить разборку очереди” или “притормозить выкатку ради устойчивости поддержки” – это как раз тут.
какое вмешательство или усилие должно изменить ход событий: люди, AI-агенты, инструмент, методы, новый порядок работы, дополнительный бюджет, пауза, подстройка под ограничение (по Голдратту), ручная проверка. “Два дополнительных проверяющих”, “новая первичная сортировка инцидентов”, “AI-агент для первичного поиска ошибок”. |
окно времени приложения усилия, замера результата, жизни заключения по ситуации. Часто это ещё и разные окна, и их нельзя склеивать. “Два спринта работы плюс один спринт наблюдения”, “первые 48 часов после релиза”.
сопротивление, задержка или требуемая цена. Почему изменение не происходит бесплатно и мгновенно: ввод людей в контекст, неучитываемая координация, скрытые переделки и возвраты (rework), переключение внимания на другой контекст, выплаты технических/архитектурных долгов, не упомянутая очередь, просто усталость, риск ухудшить качество при ускорении. “Новые разработчики сначала замедляют команду, потому что их надо вводить в контекст”.
основание оценки, на котором держится утверждение: аналогичность прошлых ситуаций с похожей работой, замеры, расчёт по надёжной методике, экспертное допущение, интуиция. Это указание на силу вывода. “По похожей максимальной очереди в прошлом квартале”, “по трём последним инцидентам”, “пока только управленческая гипотеза”, “так говорит Вася”.
для чего это можно использовать, допустимая область применения: локальная оценка только для текущей команды в текущем проекте, планирование не больше чем на неделю, разговор о бюджете токенов на три дня, внутренний для дивизиона обзор рисков, подготовка сравнения/benchmark с конкурентом. “Можно использовать для предварительного обсуждения бюджета на два спринта”.
что из карточки не следует (с чем нельзя путать) и когда карточку пересматривать: другой состав задач, другое окно измерения, другой класс работ, перенос на другой benchmark, обещание срока, причинное доказательство. “Это не доказательство причины и не публичное обещание срока; пересмотреть, если изменился состав задач или способ сортировки очереди”.

Та же карточка в короткой записи для ситуации добавления двух разработчиков на пару спринтов “для ускорения разработки” может выглядеть так:

утверждение об изменениях во времени: добавление двух разработчиков на два спринта удвоит скорость разборки очереди
что именно меняется: скорость уменьшения очереди задач
какое изменение заявлено: ускорение разборки очереди
какое вмешательство или усилие: два дополнительных разработчика в спринтах N и N+1
окно времени: два спринта работы плюс один спринт наблюдения
сопротивление, задержка или цена: ввод людей в контекст, координация проверок, скрытые переделки, устройство очереди
основание: по замерам, оставшимся от прошлой работы
для чего это можно использовать: локальная оценка для обсуждения бюджета
что этим не доказано и когда пересматривать: не причинное доказательство, не публичный benchmark и не обещание срока; пересмотреть при изменении состава задач, окна измерения или способа сортировки очереди.

Это важно: C.27 не требует заводить большую анкету на каждую фразу “быстрее”. Если фраза ничего не меняет в решении, её можно оставить в покое, не уточнять, не проверять адекватность. Если достаточно состояния — это Dyn0. Если достаточно скорости или тренда — это Dyn1, а при важном измерении подключается измерительная дисциплина. Если нужно локально объяснить, почему вмешательство должно изменить скорость, хватает короткой карточки. Если утверждение важное и связано с существенными тратами ресурсов, то C.27 предлагает более полный профиль/profile, но только с теми разделами, которые действительно нужны в обсуждаемой ситуации. Опять же, вы сами это вряд ли будете заполнять – но вот AI-агент может споткнуться, оглянуться и пересобрать рассуждение, если его заставить заполнять более полный профиль C.27.

Самый частый сбой: что-то ускоряется или замедляется, но не факт, что по заявляемым причинам
Самый частый сбой, который C.27 исправляет, звучит так: текст измеряет или называет скорость, а потом ведёт себя так, будто уже знает, как эту скорость менять. В инженерной работе это встречается постоянно. В эксплуатации: “среднее время восстановления снизилось после изменения процесса работы с инцидентами”. Возможно, но это может быть другой состав инцидентов, новая политика первичной сортировки, меньше скрытых переделок или просто другое окно измерения. В продуктовой разработке: “AI ускорил разработку”. Возможно, но надо отделить локальное ускорение генерации кода от изменений на проверках, уменьшения задержек интеграции, потерь качества, но ещё и уменьшения нагрузки по сопровождению. В освоении новых методов работы: “команда быстрее осваивает новый класс задач”. Возможно, но тогда надо хоть как-то определить скорость, понять бюджет для этой скорости, учесть прошлый опыт, переносимость метода и надёжность удержания навыка. В поиске решений: “мы быстрее находим хорошие варианты”. Возможно, но скорость поиска ещё не говорит о новизне, ценности, покрытии пространства вариантов и политике баланса между поиском и использованием найденного (привет “развитию для развитых”). В сравнении методов: “метод B улучшается быстрее метода A”. Это уже динамическое сравнение, где нужны сопоставимые исходные условия, свежесть данных (это вчера улучшался быстрее, сегодня, или мы ожидаем, что так будет через пару месяцев?), честный способ сравнения улучшений (что такое “улучшение”, какие его характеристики?) и воспроизводимый отчёт, не зависящий от личности дающего отчёт об улучшениях.

C.27 не превращает всё в формальную динамическую модель, это не паттерн всей “теории динамики”. Если действительно нужен закон перехода, имитация/simulation, прогноз/prediction или модель управления (control model), это уже другой уровень строгости – там будет уже не семиотика и “начальный здравый смысл, темпоральная адекватность”. Фраза “ускорение произошло после такого-то усилия” сама по себе не является формальной динамической моделью. Это утверждение о производной по времени с ограниченной областью применения.

Так же C.27 не предписывает, что скорость безусловно полезна. “Быстрее вводим людей в работу”, “больше выпускаем”, “чаще релизимся” — это не автоматически хорошо. Польза, вред, безопасность, юридические ограничения, этика, обещания клиентам и искажения метрик живут в соседних паттернах. C.27 делает только одну вещь: проясняет изменения во времени так, чтобы дальше было понятно, что именно проверять – и уже после него применять какие-то другие паттерны FPF. И вот эти “какие-то другие паттерны” в рамках текущего обновления тоже получили уточнения, чтобы утверждения о производных по времени не расползались по системе как метафоры. Если утверждение о производной по времени говорит об измерениях, то дальше C.27 направит к паттернам характеризации и измерений: характеристика, шкала, единицы, окно наблюдения, индикаторы и так далее. Если фраза претендует на описание настоящей модели изменения, то C.27 будет вести к паттерну динамики, “законы изменений во времени”. Если она описывает усилие и фактическую работу, она будет перенаправлена в паттерны планирования и работы. И так далее, поэтому C.27 и получился таким большим: это “входной разбор”, а не принятие решений, что делать с результатами этого входного разбора.

В этой кампании было поправлено множество паттернов, а не только C.27
Кампания правила не один новый паттерн C.27, а целую связку паттернов. C.16 уточнён для случаев, где скорость, темп, ритм или изменение скорости становятся измеряемой характеристикой. A.3.3 U.Dynamics остаётся для законов изменения, прогнозов, имитационного моделирования (simulation) или моделей управления (control model), он уже не про расхожие менеджерские фразы про ускорения и замедления. A.19, B.1.4 и B.1.6 помогают не путать пространства характеристик, срезы на момент времени, планируемые усилия и фактическую работу. C.18.1 отвечает за масштаб: больше данных, людей, вызовов или мощностей не означает линейного ускорения. C.19 держит поиск, сужение, расширение и баланс exploration/exploitation. C.22.1 отвечает за скорость освоения классов задач. C.24 — за заявления о том, что задействование инструментов и агентов что-то ускоряют. C.25 удерживает качество (Q-bundle): гибкость/agility, устойчивость и возможность ремонта нельзя читать только как “быстрее”. C.26 и C.26.3 не дают преждевременно объявлять обычную проблему разговора об изменениях квантовоподобной/quantum-like.

G.9 теперь явно связан с динамическими сравнениями: если сравнивается изменение скорости, ритма, восстановления, эффекта вмешательства или бюджета усилий. A.2.3, A.2.8, A.2.9, A.6.C и F.12 остаются местами для обещаний, обязательств, сервисных границ и приёмки, связанных с производными по времени. А A.10, B.3, B.3.4, G.6 и G.11 удерживают доказательства, подтверждение надёжности, свежесть данных, устаревание и пересмотр, когда утверждение о производных по времени становится вдруг долговечным.

Именно поэтому C.27 не предлагает “пояснить за механику”: силу, массу, ускорение, частоту колебаний или инерцию. Физические слова оставлены как удобные подсказки в обычном языке, а строгий инженерный текст в соответствии с C.27 говорит о приложенном рабочем (а не физическом) усилии, работе, окнах времени, сопротивлении, задержках, цене, скорости изменения, ритме, а также о границах применения подобных рассуждений. Это менее всеохватно, менее эффектно, зато не ломает архитектуру FPF для применения инженерами-менеджерами в рабочих проектах.

Отдельная победа была в борьбе с неизбежной для FPF бюрократией. Полезный паттерн легко испортить так: “увидели слово скорость/speed — заполните 17 полей, приложите доказательства, созовите комитет, потребуйте клятвы о достоверности”. C.27 устроен наоборот: подсказывает самый слабый вариант для честного использования выражений о производных по времени. Если выражение ничего в проекте не меняет — C.27 вообще не используем. Хватает снимка состояния (Dyn0, нет ни скорости, ни ускорения с вмешательством) — снимок состояния, и всё, остановились. Хватает скорости (Dyn1, первая производная) — скорость. Нужна локальная гипотеза о вмешательстве (Dyn2, утверждение о второй производной по времени, ибо делаем в работе рывок или резко тормозим, то есть меняем ускорение) — короткая карточка. Нужна публикация с переносимым в другие проекты выводом — тогда да, включаем более сильные проверки и подключаем другие паттерны.

Для практики это означает много меньше красивых, но пустых фраз “менеджеров, но не инженеров”. Нельзя продавать скорость/rate как модель вмешательства (intervention model). Нельзя выдавать тренд/trend за причину (causal evidence). Нельзя обещать восстановление/recovery без окна и основания. Нельзя сравнивать ускорения без честного сравнения (parity). Нельзя считать торможение провалом только потому, что после него дела пошли медленнее. И нельзя тащить квантовоподобность/quantum-like (уже есть в FPF), теорию управления (control layered architecture есть в FPF) или полноценную физическую динамику (законы изменений) туда, где обычные инженерные проверки на адекватность разговора о чём-то “во времени” ещё не были сделаны по C.27.

Типовые промпты, которыми можно задействовать C.27
Вот набор типовых промптов, которыми можно включать C.27 в инженерно-менеджерской работе.

проверь это утверждение по C.27: [текст утверждения].
Отдели состояние, скорость/тренд изменения состояния и утверждение о вмешательстве во времени. [по идее, тут даже не надо указывать C.27 – этот паттерн должен сам подтянуться]
Если C.27 не нужен, скажи почему. Если нужен, заполни его карточку.
Перед тем как использовать это как обещание срока, проверь по C.27: что именно ускоряется или стабилизируется, за счёт какого усилия, в каком окне, против какого сопротивления, и чего этим ещё нельзя обещать.
Мы хотим обосновать бюджет этим утверждением: [текст]. Проверь по C.27, достаточно ли тут основания для бюджетного решения, или это только гипотеза.
Проверь утверждение про ритм/cadence: [текст]. Назови носитель ритма и всё остальное, что говорит C.27 о ритме.
Проверь этот dashboard/панель показателей по C.27. Какие утверждения о производных по времени пользователь может из него сделать? Где есть риск принять тренд за причину или скорость за управляемость?
Прочитай этот фрагмент как C.27-reviewer. Найди все фразы “быстрее”, “медленнее”, “ритм”, “ускорили”, “стабилизировали”, “восстановили”, “инерция”, “throughput”, “velocity”. Для каждой скажи: обычная речь, Dyn0, Dyn1 или Dyn2; если Dyn2 — заполни короткую карточку.