Поддержка ответит через 2 минуты. Или через вечность. Work ≠ Service

Как проверить, насколько умней LLM с FPF, чем LLM без FPF? Возмьём какую-нибудь LLM, которая и так умна "из коробки", например GPT-5 Pro. Зададим ей вопрос: "Для набора фраз дай табличку, какие из них означают сервис как обещание, а какие - нет". 1. Сервис платежей недоступен: "503". 2. Госуслуга “Выдача загранпаспорта” должна быть оказана в 30 дней. 3. Запусти billing.service на сервере. 4. SLA по услуге “Сжатый воздух 6 бар” сегодня нарушен. 5. Добавь порт "443" в Kubernetes Service для ingress 6. Сервис поддержки отвечает дольше 2 минут 7. Наш микросервис orders должен предоставлять REST API 8. Клиент получил услугу возврата налогов и дал оценку 5/5 9. Сервис “API-шлюз” — это endpoint /v1/.... 10. В Jira создан сервисный тикет Умная GPT-5 Pro сразу говорит, что надо по современной практике SRE/ITSM задать три вопроса: -- есть ли получатель и желаемый исход? -- задано ли качество/срок/объём как обязательство? -- можно ли измерить выполнение с точки зрения получателя? И если "да", то это "сервис как обещание", а если нет -- ну, разное (состояние системы, технический компонент, интерфейс и т.д.). Конечно, тут же есть советы, как переформулировать "технические" фразы в язык обещаний. И даёт ответы на вопросы: нет, да, нет, да, нет, да, нет, да, нет, нет. Теперь подгружаем (для чистоты эксперимента в новом чате) FPF и в конец такого же вопроса добавляем "Используй FPF из подгруженного файла". Получаем такую же таблицу, но ответы чуть другие: нет, да, нет, да, нет, нет, нет, нет, нет, нет. И набор критериев другой: -- есть ли обещание для потребителя? -- говорим про интерфейс/endpoint/port? -- говорим про фактическое событие/инцидент/тикет? Разошлись: -- 6. Сервис поддержки отвечает дольше 2 минут -- 8. Клиент получил услугу возврата налогов и дал оценку 5/5 FPF отказывает в статусе "обещание" этим двум строчкам, а "просто умная нежить" -- говорит, что всё ОК, обещание есть! А чем объясняет свой отказ по этим двум позициям FPF? Тем, что в этих двух строчках речь идёт не о сервисах-как-обещаниях, а просто замере работы. И в обоснованиях пишет: "такой разбор согласуется с современными канонами управления услугами (напр., ITIL 4, 2019) и инженерией надёжности (SRE, error budgets), где обещания формулируются как SLO/SLA, а выполнение доказывается телеметрией/Work-фактами; FPF делает эту связку явной и формальной". Теперь вчитываемся: действительно, мы не знаем, что там было обещано в пункте 6 и 8. Но мы знаем, что была выполнена какая-то работа с какими-то плохими и хорошими результатами. А обещание? Ничего про него не знаем, природа "сервиса поддержки" и "услуги возврата налогов" остаётся непонятной. Мораль всей истории: FPF задаёт более тонкие и профессиональные различения в моделировании мира, чем отлавливается "просто очень умным" интеллектом. В FPF отражены основные принципы довольно большого числа профессиональных инженерных и менеджерских стандартов, причём во взаимосвязи. На практике это означает, что FPF неявное делает явным: иногда этого не надо, "лишняя бюрократия", но иногда спасает проект. Предупреждение: термин service в наших руководствах по рабочему развитию и в FPF отличается по своему значению. Но если вы владеете материалом руководств, то вы легко разберётесь. Cеминар "First Principles Framework в программе исследовательского развития инженеров-менеджеров" я буду проводить 4 октября 2025, писал вот тут: https://ailev.livejournal.com/1776026.html