Где FPF помогает: 25 ситуаций из разных сфер

От платёжного API до семейного совета о переезде - конкретные ситуации, где паттерны FPF Анатолия Левенчука превращают кашу в работающую структуру. С привязкой к конкретному паттерну в каждом кейсе.

В предыдущем посте я рассказал, что такое FPF целиком: откуда берётся фреймворк, зачем он нужен, как устроен его базовый словарь. Этот пост - дополнение: где конкретно эти паттерны применяются.

25 ситуаций из 12 сфер. Для каждой - какой именно паттерн FPF решает проблему и что изменится в результате.

Структура каждого кейса одинакова:

Ситуация - реальный сценарий, где что-то идёт не так
Паттерн FPF - конкретный механизм из спецификации
Что меняется - конкретный результат после применения паттерна

Важная оговорка: это не призыв «внедряйте FPF везде». Наоборот - каждый конкретный паттерн отвечает на конкретную проблему. Если проблемы нет, паттерн не нужен. Кейсы ниже показывают, где проблема есть и какой именно инструмент её снимает.

Некоторые паттерны из спецификации FPF звучат устрашающе: A.6.3.RT RepresentationTransduction, B.5.2.1 Creative Abduction NQD, G.4 CAL Pack. На практике за каждым из них стоит конкретный вопрос - «что именно здесь запрещено?» или «сколько гипотез мы рассмотрели до публикации?» - который звучит понятно без специального словаря. Я буду называть паттерн по его обозначению в спеке, но суть описывать обычным языком.

Кейсы не связаны между собой: читать можно с любого раздела, в котором узнаёте свой контекст. Если делаете продукт - начните с первой секции. С контрактами работаете - смотрите Law & Compliance. Остальное по тегам или ситуации.

Product / Engineering

1. Платёжный API: контракт-каша

Ситуация. Платёжная команда выкатывает v2 API. В одном документе смешаны: «нельзя возврат старше 180 дней», «merchant обязан вернуть webhook 200 за 5 сек», «при отказе - log в audit», «банк-партнёр сам решает FX-курс». Интеграторы ломаются непредсказуемо, support тонет.
Паттерн FPF. A.6 Boundary Discipline (L/A/D/E) - разнести по Laws / Admissibility / Deontics / Effects.
Что меняется. Каждое утверждение получает тип. Тестировщик пишет отдельные suite на запреты и на обязанности. Юристы читают только L+D, SRE - только E.

2. «Релиз сам себя задеплоил»

Ситуация. Разбор инцидента: «CI/CD конвейер решил выкатить срочную правку без проверки». Команда защищается: «процесс так настроен». Руководство злится: кто конкретно принял решение пропустить быструю проверку?
Паттерн FPF. A.3 Transformer Quartet - процесс ничего не «решает», решает система-носитель в роли.
Что меняется. В разборе появляется явное «release engineer в роли дежурного при отсутствии разрешения на выпуск», а не «конвейер». Дальше можно чинить либо роль, либо MethodDescription.

3. Дашборд SRE врёт зелёным

Ситуация. 12 SLI-графиков зелёные, заказчик жалуется на latency. Оказывается, alerting rules не обновлялись 9 месяцев, latency-bucket был расширен в марте, никто не пересмотрел.
Паттерн FPF. B.3.4 Evidence Decay + Epistemic Debt - у каждого SLI должен быть valid_until и политика рефреша.
Что меняется. Панель показывает не только цвет, но и возраст определения порога. Старше 90 дней - визуальная метка «устаревший», owner получает Refresh-task.

4. Архитектор выбрал Kafka «потому что Kafka»

Ситуация. На ревью техлид защищает решение «event bus = Kafka». На вопрос «а что рассматривали ещё» отвечает «ничего, Kafka стандарт». Через год команда упирается в ops-сложность для их нагрузки.
Паттерн FPF. B.5.2 Abductive Loop - минимум 2 кандидата и 2 фильтра, явные Abort/Defer.
Что меняется. В RFC обязательны альтернативы (NATS, Redpanda, SQS) + критерии отсева. Решение становится reviewable, а не «вкусом архитектора».

5. «У нас нет процесса релизов»

Ситуация. Новый VP Eng слышит от всех: «у нас нет процесса». При этом релизы выходят, инциденты тушатся. Что именно отсутствует - никто сформулировать не может.
Паттерн FPF. A.15 Role-Method-Work Alignment - 5 разных сущностей, надо понять каких именно нет.
Что меняется. Аудит показывает: есть Capability (умеют), есть Work (делают), нет MethodDescription (нигде не записано как) и нет назначенной Role. Лечится двумя документами, а не «внедрением процессов».

Бизнес и стратегия

6. Due diligence: «компания растёт»

Ситуация. Инвестор смотрит таргет: revenue +40% YoY. Покупает. Через полгода обнаруживает, что рост был от одного контракта, который заканчивается; динамика прироста новых клиентов уже 6 месяцев отрицательная.
Паттерн FPF. C.27 Dyn0/Dyn1/Dyn2 - различать состояние, темп и темп изменения темпа.
Что меняется. В DD-чеклист добавляется «покажите производную второго порядка по воронке продаж и когорте». Сделка либо разваливается, либо цена корректируется.

7. Стратегия на 5 лет без альтернатив

Ситуация. CEO презентует совету директоров «стратегия 2030: фокус на enterprise». Один из директоров спрашивает: «что ещё рассматривали и почему отбросили?». Внятного ответа нет.
Паттерн FPF. E.9 DRR - Problem frame + Decision + Alternatives + Basis + Loss/Recoverability.
Что меняется. К стратегии прикладывается ledger из 4-5 отвергнутых ставок с критериями. Совет может оспаривать выбор, а не верить на слово. На next review легко увидеть, что изменилось во входных данных.

8. Pre-IPO: «всё готово»

Ситуация. Финдиректор говорит «готовы к IPO». Юристы говорят «готовы». Команда controls говорит «есть базовый набор SOX-контролей, прогоняли год назад». Аудитор обнаруживает, что половина контролей не пересматривалась после миграции в облако.
Паттерн FPF. B.5.1 Explore -> Shape -> Evidence -> Operate с AssuranceLevel - «есть» не равно «на L2».
Что меняется. Каждый контроль получает явный уровень assurance и дату последнего evidence. «Готовы» превращается в матрицу: 60% L2, 25% L1, 15% L0 - и план дотягивания.

Наука и R&D

9. Лаборатория и «всем понятный» эксперимент

Ситуация. PI публикует результат, рецензент просит протокол. PhD-студент, который вёл руки, ушёл. Никто не может воспроизвести: «делали как обычно». Repeat-эксперимент даёт другую кривую.
Паттерн FPF. A.15 Role-Method-Work - различать MethodDescription (текст), Method (носитель), Work (конкретный прогон).
Что меняется. Лаб вводит требование: каждый Work привязан к версии MethodDescription и явному Method-носителю (прибор + калибровка). Воспроизводимость становится проверяемой.

10. Странное наблюдение в данных

Ситуация. Аспирант замечает «какой-то пик в районе 340 нм, наверное артефакт». Удаляет из чистового датасета. Через 8 месяцев другая лаба публикует открытие - тот самый пик.
Паттерн FPF. A.16.1 PreArticulationCuePack - сохранять cue до того, как он стал гипотезой.
Что меняется. В lab-notebook вводится отдельный раздел «cues»: наблюдения, которые непонятно куда деть. Раз в месяц PI ревьюит. «Артефакт» не выбрасывается, а лежит до прояснения.

Медицина

11. Гайдлайн по сепсису не пересматривался

Ситуация. Отделение работает по протоколу 2019 года. Новые мета-анализы показали, что часть рекомендаций по жидкостям пересмотрена. На обходе ординатор предлагает по новому, заведующий отвечает «у нас протокол».
Паттерн FPF. B.3.4 Evidence Decay + Refresh policy - у каждого пункта протокола valid_until.
Что меняется. Каждый блок протокола получает «next review by» и owner-эксперта. Протокол не становится скрижалью. На обходе можно ткнуть в дату.

12. «Опухоль доброкачественная, скорее всего»

Ситуация. Радиолог пишет в заключении «образование, наиболее вероятно доброкачественное». Клиницист принимает как «доброкачественное», наблюдение откладывает. Через год оказывается, что это была одна из 3 рассмотренных гипотез, и не главная по совокупности признаков.
Паттерн FPF. B.5.2.1 Creative Abduction + NQD - возвращать Pareto-front, а не победителя.
Что меняется. Заключение содержит не «диагноз», а ранжированный набор: 3 гипотезы с весами и критерии, что их разводит. Клиницист видит, какое доп-обследование разрешает спор.

Образование

13. Программа курса «как-то сложилась»

Ситуация. Университетский курс по алгоритмам читает 4-й год один преподаватель. Программа разрослась, темы наслаиваются. Новый ассистент спрашивает «почему здесь именно эти 12 тем» - ответ «исторически».
Паттерн FPF. E.9 DRR - решение «состав курса» = Problem frame + Rationale + Alternatives.
Что меняется. Каждая тема получает явное обоснование: какую компетенцию формирует, какую тему вытеснила, что было альтернативой. Замена темы становится дискуссией, а не войной.

14. «Студенты не понимают рекурсию»

Ситуация. Лектор уверен, что «студенты не схватывают рекурсию». Меняет объяснения, добавляет примеры - не помогает. На самом деле проблема в pre-req: они не владеют стэком вызовов как моделью.
Паттерн FPF. A.1 Holon - спутаны уровни обсуждения: «рекурсия» как тема и как навык, опирающийся на другие.
Что меняется. Препод раскладывает «рекурсию» на холоны: модель памяти, синтаксис, шаблон проектирования. Диагностика выявляет конкретный уровень провала. Лечится одной лекцией про стэк.

Право и compliance

15. Контракт смешивает обязанности и санкции

Ситуация. SaaS-контракт на 40 страниц. Юрист клиента жалуется: невозможно понять, где обязанности поставщика, где условия допустимости использования, где санкции, где автоматические эффекты (пеня). Переговоры затягиваются.
Паттерн FPF. A.6 Boundary Discipline (L/A/D/E) - разнести положения по 4 типам.
Что меняется. Контракт переписан с маркерами: [L] запрет, [A] условие допустимости, [D] обязанность, [E] последствие. Время согласования падает в 2 раза; диспуты адресуют конкретный тип.

16. Compliance-чеклист «зелёный», аудит провален

Ситуация. Внутренний compliance показывает 100% по GDPR-чеклисту. Внешний аудитор обнаруживает, что чеклист последний раз пересматривался до Schrems II, ряд пунктов уже неактуален, а DPA с подрядчиками - старого образца.
Паттерн FPF. B.3.4 Evidence Decay - чеклист это evidence с TTL.
Что меняется. У каждого пункта - дата валидации и regulatory-source. При изменении источника пункты автоматом помечаются как устаревшие. «100%» становится «100% по версии 2019», что сразу некомфортно.

Гос-управление

17. Новый регламент: «работает в пилоте»

Ситуация. Минцифры пилотирует электронный документооборот в 2 регионах. Через 6 месяцев готовится тиражирование на всю страну. Метрики пилота показывают «успех», но evidence - опросы 200 пользователей и uptime сервиса.
Паттерн FPF. B.5.1 Explore -> Shape -> Evidence -> Operate с AssuranceLevel L0 -> L2.
Что меняется. Перед тиражированием явно проговаривается: пилот дал L1 (узкая выборка, мягкие метрики). Для L2 нужны нагрузочные тесты + 3-региональная валидация + fallback. Решение не «катить», а «доращивать assurance».

PR и кризис-коммуникация

18. Кризис: первая правдоподобная версия

Ситуация. Утечка данных. PR-команда за 2 часа собирает версию «взлом подрядчика», публикует заявление. Через сутки выясняется, что это был инсайдер. Второе заявление противоречит первому, репутационный ущерб удваивается.
Паттерн FPF. B.5.2 Abductive Loop - нельзя пускать в публикацию первую гипотезу без второй и фильтра.
Что меняется. PR-протокол требует: до публичного заявления - минимум 2 гипотезы и хотя бы один фильтр их различающий. Если фильтр невозможен за отведённый срок - публикуется «расследуем», а не версия.

19. Лендинг: «AI-powered, blockchain-ready, quantum-safe»

Ситуация. Маркетинг сгенерил лендинг с тремя buzz-словами. Технический CMO видит: «AI-powered» = одна regex, «blockchain» = ничего нет, «quantum-safe» = одна библиотека. Юрист предупреждает про misleading.
Паттерн FPF. E.17 MVPK + Source-support posture - визуальная подача не равна authority; нужна явная позиция «насколько источник поддерживает claim».
Что меняется. Каждое утверждение на лендинге получает класс: marketing-claim / verified-feature / aspirational. Для verified - ссылка на доку. Маркетинг и tech-writing работают по одной шкале.

AI safety

20. Агент «сам решил» удалить таблицу

Ситуация. LLM-агент в внутреннем tool выполнил DROP TABLE staging_users. Постмортем: «модель решила, что таблица не нужна». Команда требует «запретить агенту опасные команды», но не может сформулировать какие именно.
Паттерн FPF. A.3 Transformer Quartet + A.6 Boundary Discipline (L/A/D/E).
Что меняется. Агент это не «решатель», а Method, исполняющий Role «assistant под надзором». L/A/D/E-контракт явно перечисляет Laws (запрещённые операции), Admissibility (когда DROP допустим), Deontics (обязанность подтверждения), Effects (audit-log). «Решил сам» становится «нарушил A».

21. Бенчмарк показывает «AGI-level»

Ситуация. Модель набирает 92% на новом бенчмарке. Пресс-релиз: «опережает PhD-экспертов». Через месяц независимая команда показывает, что 40% задач бенчмарка были в обучающей выборке, а формулировка «PhD-level» считалась по узкому subset.
Паттерн FPF. E.17 Source-support posture - 19 явных позиций, насколько evidence поддерживает claim.
Что меняется. Каждое утверждение в model card получает posture: directly-evidenced / partially / contested / unsupported. Маркетинговое «PhD-level» классифицируется как partially - и обязано указать какой именно subset и какой эталонный уровень эксперта.

HR

22. Оценка работы: «работает хорошо»

Ситуация. Менеджер пишет ревью: «Анна работает хорошо, проявляет инициативу». На калибровке его просят обосновать повышение - не может предъявить ни конкретных Work, ни новых Capability. Повышение отклонено, Анна в шоке.
Паттерн FPF. A.15 Role-Method-Work Alignment - различать Role, Capability и Work.
Что меняется. Шаблон ревью требует: какие новые Capability освоены, какие Work выполнены сольно, какая Role расширилась. «Хорошо работает» больше не валюта; решения о повышении становятся ревьюабельными.

23. Найм: «не подходит культурно»

Ситуация. Кандидат прошёл 5 этапов, на финале нанимающий менеджер даёт отказ «не вписывается культурно». HR-партнёр требует конкретики - её нет. Через 2 месяца такой же отказ другому кандидату того же бэкграунда. Возникает риск discrimination claim.
Паттерн FPF. E.9 DRR - решение о найме = Decision + Basis + Alternatives + Rationale.
Что меняется. Hire/no-hire требует record: какие competency-evidence собраны, какие альтернативные интерпретации рассмотрены, что именно перевесило. «Культура» либо превращается в конкретный observable signal, либо исключается.

Финансы

24. Портфельное решение: ребаланс «по правилам»

Ситуация. Family office ведёт портфель по 7 критериям (доходность, риск, ESG, ликвидность, валюта, корреляции, мандат). При ребалансе менеджер сводит всё в одну Excel-формулу, которая никому не понятна. Бенефициар спрашивает «почему продали X» - ответ «модель так сказала».
Паттерн FPF. G.4 CAL Pack - typed operators + acceptance clauses + flows + evidence profiles + proof ledger.
Что меняется. Каждое решение - явный flow: какие критерии активны, какие пороги, какой evidence по каждому, какой proof-ledger. Бенефициар видит цепочку. Менеджер защищён от обвинения «как захотел».

Повседневная жизнь

25. Семейный совет: переезд в другую страну

Ситуация. Пара 3 месяца обсуждает «переезжать или нет». Каждый разговор скатывается на разные уровни: «дети vs школа», «налоги vs визы», «свекровь vs климат». Решения нет, осадок растёт.
Паттерн FPF. A.1 Holon + A.7 Strict Distinction - спутаны уровни обсуждения и сущности.
Что меняется. Пара выписывает 4-5 явных холонов (карьера, дети, родители, финансы, образ жизни) и обсуждает каждый отдельно с фиксацией. На общем уровне принимается интеграционное решение. Из «бесконечного спора» получается structured decision за выходные.

Что бросилось в глаза

A.6 Boundary Discipline (L/A/D/E) работает далеко за пределами API. Контракты, compliance, AI guardrails - везде, где документ смешивает «нельзя», «обязан», «когда допустимо», «что произойдёт автоматом». Это самый универсальный паттерн.

B.3.4 Evidence Decay - универсальный антидот «зелёным дашбордам» в любой сфере с медленно меняющейся истиной: медицина, регуляторика, security, compliance, SLI.

A.15 Role-Method-Work Alignment, как ни странно, чаще нужен не инженерам. В HR, науке, образовании «процесс» особенно размыт, и спор «есть ли он» решается через «какой из 5 элементов отсутствует».

И ещё две беглые мысли. B.5.2 Abductive Loop одинаково спасает PR-кризис, медицинский диагноз и архитектурное решение - паттерн «не публикуй первую правдоподобную версию» переводится на нетехнические аудитории за минуту. А E.9 DRR заходит туда, где решения политически чувствительны: стратегия, найм, повышение, состав куррикулума. Даёт защищаемость без бюрократии.

Если хочется разобраться в самих паттернах подробнее:

Обзор всего FPF: /blog/ru/what-is-fpf/
Спека: github.com/ailev/FPF