MCP-сервер для FPF
Стас Недбайлов сделал сегодня reference-сайт для чтения паттернов FPF (https://fpf.sh/), а также наладил там MCP с шестью инструментами для FPF – https://mcp.fpf.sh/. Синхронизация с оригинальным сайтов в GitHub – раз в сутки. Сам FPF уже имеет на сегодня 352 звезды и 61 форк, очень немало для такого проекта – 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.
Очередная кампания по семиотической архитектуре: доработки формулировок допусков к работе
А у меня в FPF закрыта очередная небольшая кампания по семиотической архитектуре, их ещё осталось только семь. Кампания про то, как оформляют эпистемы по допуску к работам: когда написано что-то вроде “одобрено” (approved), “разрешено” (allowed), “готово” (ready), “соответствует требованиям” (compliant), “авторизовано” (authorized). Это может быть написано в выводе на экран (компьютера, смартфона, кассового терминала), в аналитическом отчёте, в выжимке из многостраничного документа, в тексте пропуска или цифрового сертификата, в правиле, стандарте, в вызове API, в сгенерированном объяснении. Люди (или не совсем люди) читают это – и после этого собираются что-то сделать, предпринять конкретную работу, потратить ресурсы: выкатить релиз, пустить партию сырья в производство, дать подрядчику доступ к информационной системе, изменить план ремонта, выполнить поставку против платежа, провести испытание, считать Васю полномочным действовать из роли Большого Начальника.
Это необязательно текст, семиотика шире текстов. Есть знаки, которые означают разрешение на работу или, наоборот, запрет: цвет, пропуск, подпись в нужной графе, отметка статуса, краткое резюме, штамп “проверено”, текст наряда на работу. И везде такие вторичные знаки могут выглядеть как разрешение более сильное, чем исходная эпистема в её самых разных публикационных формах, на которую такой знак “поехали!” может опираться. Нормально, если зелёная плитка на дашборде означает “можно выкатывать”. Для этого дашборды и делают. Нормально, если метка контроля качества означает “эту партию можно передать на следующий участок”. Нормально, если пропуск помогает охране понять, кого пускать в цех. Плохо не это.
Плохо, когда зелёная плитка дашборда, грамотно оформленный пропуск или строка “одобрено” выглядят как разрешение, но за ними не видно того, что именно разрешили и что реально нужно для работы, а также невозможно разобраться, откуда вообще взялось это решение: правда ли, что там было два грузовика цифровой документации, или этот миллиардный контракт в работу запускается просто по кивку мало понявшего ситуацию Большого Начальника. Ведь где-то есть совершенно другой уровень документирования: решение о допуске в контрольной точке (GateDecision), акт одобрения научно-техническим советом с многочисленными подробностями, приказ о назначении агента на роль с подробными описаниями прав и обязанностей по действиям в этой роли, актуальный статус удостоверения или пропуска в реестре (пропуск как выписка из реестра), цепочки подтверждающих записей инженерных обоснований, и всё это с областями действия, версиями использованных правил, временными окнами и свежестью проверок. Когда команда проекта начинает действовать не по самому основанию для работы, а по знаку такого основания – это означает пропуск семиологического шага. Напомню, что семиология у врачей – это когда симптомы болезни называют знаками, по которым определяют саму болезнь или, наоборот, здоровье. Отметка “разрешено” или “запрещено” – это знак, по которому определяют реальную ситуацию с разрешением или запретом. В FPF реальные разрешения и запреты могут быть GateDecision, SpeechAct, Commitment, RoleAssignment, admissibility predicate, credential status и т.д. Врачи смеются, когда пациенты считают знаки-симптомы (насморк!) болезнями, инженеры должны смеяться, когда деонтические знаки (впрочем, тут речь идёт немного шире, чем о деонтике) пишутся и воспринимаются в качестве собственно разрешений или запретов. Это проблема, с которой работала законченная кампания.
Главный результат кампании: в FPF теперь есть короткий чеклист для таких случаев, когда встречается знак запрета или разрешения на работу:
- что команда собирается сделать сейчас;
- какая запись, какое решение или правило, какое действие должны поддерживать именно то, что команда собирается сейчас сделать.
Если команда собирается выкатывать релиз, нужен не “зелёный цвет”, а решение о допуске релиза: GateDecisionRef, что выкатывают, в какую среду, в каком временном окне, по какой версии правил допуска, с какой цепочкой подтверждающих записей. Если охрана собирается дать доступ подрядчику, нужен не красивый пропуск, а проверенная связка самых разных сведений: кто выдал удостоверение, кому оно выдано, кто его проверяет, что показала проверка статуса, не отозвано ли оно, свежая ли проверка, в каком контексте допуска на эту связку сведений можно опираться, а в каком контексте надо бы добрать дополнительные сведения о ситуации. Если речь уже не только о действующем удостоверении, а о разрешении, роли или статусе, нужна отдельная запись, решение или роль. Если в выжимке написано “главный инженер одобрил”, нужен не факт, что выжимка содержит слово “одобрил”, а наличие возможности понять это одобрение: кто и когда одобрил, в какой роли, что именно одобрил, для какой области действия и временного окна, с какими условиями и ограничениями. Если метка говорит “безопасно”, “готово”, “проверено”, “соответствует требованиям”, нужен не сам текст метки, а инженерное обоснование: что именно обосновывается, для какого применения, при каких условиях оценки, в каких документах это есть, в каких протоколах или записях проверки, с какими ограничениями и когда это надо пересматривать. Если AI-агент пишет “этот доступ разрешён правилом X” в объяснении, это может быть полезной подсказкой для поиска исходного правила и его чтения, но это не собственно “разрешение от AI-агента”: сначала надо показать связь объяснения с исходным правилом, ибо не факт, что AI-агент хорошо знает контекст, в котором работает или не работает правило.
Это всё звучит почти очевидно, банально, естественно. Но помним, что говорил Атул Гаванде про чеклисты: девять раз из десяти чеклист даёт положительный результат, “всё в порядке”. Но один раз из десяти оказывается, что не всё в порядке – и эта короткая проверка спасает проект. Очевидная семиотическая гигиена вдруг теряется, когда рабочий экран сделан “для скорости и краткости” без отсылок, отчёт сокращён до одной страницы резюме, и на нём нет отсылки не только к исходным материалам для отчёта, но и к самому отчёту, одобрение скопировано в письмо без учёта многочисленных оговорок, которые шли вместе с одобрением, пропуск (выписка из реестра!) показан без дат начала и конца действия и без ссылки на реестр, сгенерированное объяснение написано уверенно и гладко – но без учёта самых разных нюансов (которые обязательно окажутся важны именно в вашей ситуации, но именно они и не будут объяснены).
Главные изменения в A.15, паттерне про контекстуальную связку “роль-метод-работа”
A.15 Role-Method-Work Alignment / Contextual Enactment в FPF занимается согласованием роли, метода, плана и выполненной работы, это не семиотический паттерн. Но именно тут были основные добавки – ибо команда проекта, например, не просто “реагирует” на экран или метку с разрешением поработать. Она ведь по этому разрешению делает работу: выбирает метод, планирует работу, выполняет работу (тратит ресурсы), получает результаты (эффекты работы), иногда возвращается к началу и меняет метод или план, если обнаруживается, что ситуация того требует. Одобрение, решение о допуске, удостоверение, подтверждающие записи и инженерное обоснование не являются этой работой, это “разговоры о работе”, знаки, знаниевые, семиотические объекты. Они могут разрешать, поддерживать, ограничивать или объяснять работу, но не заменяют собственно работы. A.15 не имеет своей проблемой знаниевое “какая метка перед нами?”. Его решения про другое, про действия в реальном мире:
- какая работа сейчас начнётся (и вопрос про основание для работы – тоже не знаниевый, а про ситуацию в реальном мире, что-то вроде FullKitting в TameFlow – наличие всех необходимых материалов и инструментов, а также работника);
- какой метод из какого семейства методов и какой план работы (включая планирование “на лету”) используются;
- какая роль действует (и имеет ли исполнитель роли соответствующее мастерство);
- какое одобрение, решение о допуске, разрешение, подтверждение или инженерное обоснование нужно, чтобы этот шаг был допустимым, где в паттернах FPF искать подтверждение, что это нужный тип основания. Семиотика только вот тут, и именно это было добавлено кампанией.
Если нужное основание есть, действие не тормозится. Хороший релизный дашборд не заставляет инженера проводить мини-аудит перед каждым выкатыванием. Он сразу показывает GateDecisionRef, что выкатывают, в какую среду, в каком окне, версию правил допуска и цепочку подтверждающих записей. Тогда зелёная плитка не магическая. Она коротко показывает (“означает”, это просто знак) решение о допуске, а не скрывает за собой решение о допуске (почувствуйте разницу! “Не сотвори себе кумира”: знак не должен вызывать особых чувств и действий, полностью замещая означаемое).
Если за знаками разрешения или запрета не видно их оснований/значений, FPF показывает, что чинить: “дашборд не показывает ссылку на решение”, “выжимка потеряла выражение одобрения”, “пропуск не показывает, где смотреть его оперативный отзыв”, “метка не раскрывает инженерное обоснование”, “сгенерированное объяснение не показывает связь с тем, что оно должно было объяснить”.
Пять обновлённых в кампании паттернов
В кампании были обновлены пять уже существующих паттернов, но нового большого паттерна вроде AuthoritySign или общего формата записи “разрешения” не появилось: тогда сначала люди (и не люди) верили бы зелёной плитке, потом стали бы верить карточке про зелёную плитку, и так до бесконечности. Поэтому ничего нового как “источника второй правды о разрешениях”, зато в пяти паттернах добавили короткое узнавание ситуации как потенциально проблемной (даже если эту проблему не видит инженер-менеджер как пользователь FPF). Дальше эти паттерны показывают, какие другие существующие паттерны FPF проясняют нужный тип основания: решение о допуске (правила допуска), (речевой) акт одобрения, назначение роли, обязательство, цепочку связанных подтверждающих записей или инженерное обоснование.
A.15Role-Method-Work Alignment / Contextual Enactment получил тот список вопросов, который мы только что обсудили в предыдущих абзацах.A.10Evidence Graph Referring получил подсказки содержания подтверждающих записей: откуда взялся проверяемый вывод, в каком документе, протоколе или записи он появился, какая роль или система его выдала или записала, какое временное окно действует, насколько свежа проверка, что могло быть альтернативным объяснением. Настоящее пособие для бюрократов!B.3Trust and Assurance Calculus держит инженерное обоснование/assurance: когда метка “готово”, “безопасно”, “надёжно”, “соответствует требованиям” действительно даёт инженерное обоснование, а когда остаётся только знаком-ориентиром.A.6Signature Stack and Boundary Discipline решает проблему формулировок-“зонтиков” со многими значениями: одно слово “разрешено”, “одобрено”, “гарантировано” или “рекомендовано” может означать определение, допустимость или решение о допуске, обязательство, подтверждение факта или рабочий эффект. Надо понять, что это слово означает онтологически, а не верить слову как слову/лексеме. Многозначность слов никто не отменял, это вечная проблема всех рабочих проектов.E.17.EFPExplanation Faithfulness Profile держит сгенерированные объяснения: объяснение помогает понять или даже просто найти исходную запись, решение или документ, где сделан проверяемый вывод, но объяснение не становится одобрением, подтверждением, инженерным обоснованием или прохождением контрольной точки только потому, что написано уверенно. Если у вас объяснение теории относительности, написанное для пятиклассников, то оно написано обычно очень уверенно, но собственно текстов статей (даже не учебников, которые тоже объяснения!) по теории относительности это объяснение не заменяет.
Что FPF теперь будет делать лучше
Можно проектировать нормальные рабочие экраны. Если дашборд говорит “релиз готов”, он должен показывать не только цвет плашки “зелёный”, но кратенько само решение: что выкатывают, в какую среду, в каком окне, по какой версии правил допуска, где цепочка подтверждающих записей. Тогда инженер видит не “настроение системы”, а основание для выкатывания.
Можно проектировать нормальные производственные метки/tags. Если партия получила одобрение контроля качества, метка должна вести к сведениям о проверке партии, области действия одобрения, времени проверки, условиям годности, статусу повторной проверки и тому, что именно разрешено: передать на следующий участок, отгрузить заказчику, использовать только внутри испытаний или вернуть на доработку.
Можно чинить допуск и удостоверения. Пропуск подрядчика сам по себе не создаёт роль и не выдаёт разрешение. Он показывает статус удостоверения, если за ним есть запись о выдаче, держателе, проверяющем, результате проверки статуса, отзыве, свежести проверки и контексте допуска (и этот реестр как административная база данных, само внесение записей в которую создаёт права и обязательства – вот это уже не удастся пропустить). Дальше отдельно решается, какой исполнитель в какой роли действует и какие работы (действия) эта роль разрешает.
Можно чинить скопированные одобрения. Фраза “одобрено главным инженером” в письме или выжимке полезна, если она быстро ведёт к акту одобрения: кто, в какой роли, что одобрил, для какой работы, партии, площадки, временного окна или версии документа. Если акт одобрения не найден, выжимка остаётся подсказкой, а не одобрением.
Можно использовать объяснения без самообмана. Хорошее объяснение помогает найти исходное правило, запись решения или подтверждающий документ. Плохой шаг – принять объяснение за разрешение, производные работы — за эквиваленты основного текста. Новый вопрос в FPF: “спасибо, теперь покажи связь с исходным правилом или решением и подтверждение именно этого вывода”. В частности, сам FPF имеет сегодня 61 форк, и многочисленные адаптации в формате и способах доступа. Но все ли они имеют отсылки к оригинальному тексту в 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?
Можно лучше разбирать инциденты. После сбоя часто пишут: “команда действовала по дашборду”, “в отчёте было одобрено”, “пропуск был действующим”, “модель объяснила, что доступ разрешён”. Теперь это не финал объяснения. Это начало разбора: какая работа была начата, какое основание было нужно, что именно отсутствовало или устарело.
Чем это отличается от Controlled Semantic Coarsening (A.6.3.CSC, выпущенный в прошлой семиотической кампании)? CSC нужен, когда исходное описание или представление сознательно упростили/огрубили: сделали выжимку, таблицу, упрощённый вид, презентацию, редактированную версию. Там главный вопрос: какой смысл потерян, какое более узкое поддержанное применение осталось, что уже нельзя утверждать после сокращения. Здесь вопрос другой. Экран, метка, выжимка, экран удостоверения или сгенерированное объяснение могут не только упростить изложение. Они могут ещё и подтолкнуть к работе: релизу, допуску, пуску партии, одобрению, прохождению контрольной точки, опоре на роль/статус, опоре на подтверждающие записи или появлению инженерного обоснования. Тогда надо не только сказать, что потеряно в сокращении. Надо назвать работу, которая должна начаться, и основание, без которого этот шаг недопустим.
Типовые промпты даже не даю, AI-агент с FPF должен сам сообразить, что из него брать, если ему дать достаточно ситуационного контекста: агент должен будет посмотреть на всё, что вы ему скажете, а затем рассказать про замеченную им проблему и предложить решение – в том числе дать подсказки про то, как лучше сформулировать допуск к работе.
