Как применять результаты FPF-рассуждений в работе и жизни
Практическое руководство по дисциплине FPF (Spec.md, февраль 2026)
С позиции FPF мои ответы — это не «рекомендации», а артефакты-описания (U.Episteme), которые становятся полезными только когда вы превращаете их в U.Work (датированные действия) с явными U.Commitment (обязательствами) и Evidence carriers (носителями доказательств).
Ниже — как это делать системно.
1. Превратите ответы в артефакты (A.7: Object≠Description≠Carrier)
Согласно A.7, нельзя смешивать объект, его описание и носитель. Мои ответы — это описания. Чтобы они работали:
| Что вы получили |
FPF-статус |
Что сделать дальше |
| Bridge Matrix для данных |
U.Episteme (описание мостов) |
Опубликовать как U.MethodDescription с версией (edition pin) |
| Episode Policy |
U.Episteme (политика) |
Утвердить как U.Claim с Γ_time и назначить ответственного (U.Commitment.subject) |
| Чек-листы |
U.Episteme (требования) |
Превратить в Guard-предикаты (A-*) для проверки перед началом работ |
| Индикаторы |
U.Episteme (метрики) |
Зафиксировать как U.CharacteristicSpace с единицами измерения (KD-CAL) |
Правило (A.7): Описание само по себе не работает. Оно должно быть институировано через U.SpeechAct (утверждение ответственным лицом) и привязано к Work через U.Commitment.
2. Запустите Canonical Reasoning Cycle (B.5)
FPF не даёт «готовых ответов» — он даёт цикл рассуждения, который вы применяете к своей ситуации:
| Фаза |
Что делать |
FPF-артефакт |
| Abduction (B.5.2) |
Сформулировать гипотезу: «Если мы применим Bridge Matrix с CL≥2, то потери данных будут ≤5%» |
L0-Claim (гипотеза) |
| Deduction (B.5.4.2) |
Вывести следствия: «Значит, для CL=1 требуется ручная проверка; значит, нужно назначить роли верификаторов» |
MethodDescription с Guard-условиями |
| Induction (B.5.4.3) |
Проверить на фактах: запустить миграцию, собрать логи, сравнить с гипотезой |
U.Work + Evidence carriers (A.10) |
Правило (B.5): Не останавливайтесь на гипотезе. Пройдите весь цикл до индукции с evidence.
3. Зафиксируйте обязательства (A.2.8)
Согласно A.2.8, обязательство должно иметь:
subject: accountable role (не «система», не «команда»)modality: MUST / SHOULD / MAY (нормализовано)scope: U.ClaimScope (где применимо)validityWindow: Γ_time (когда действует)referents: ссылки на Claim ID (не пересказ!)adjudication.evidenceRefs: какие证据 подтвердят исполнение
Пример:
U.Commitment {
id: CM-MIG-001,
subject: RoleAssignment[DataSteward:NewERP@2026],
modality: MUST,
scope: ClaimScope[NSI-Migration],
validityWindow: Γ_time[T_start .. T_liquidation],
referents: {Claim-Bridge-NSI-v1.0},
adjudication: {
evidenceRefs: {E-NSI-Verification-Log},
carrierRefs: {SignedAct-NSI-Migration}
}
}
Анти-паттерн (A.2.8:8): «Система гарантирует целостность» — это ошибка. Гарантия — это обязательство роли, а не эпистемы.
4. Разделяйте План и Факт (A.15, A.15.1)
Согласно A.15, нельзя смешивать:
| Артефакт |
Что это |
Как использовать |
U.MethodDescription |
Рецепт (инструкция, скрипт) |
Хранить с версией (edition pin); не менять задним числом |
U.WorkPlan |
График (кто/когда) |
Содержит только ссылки (pins) на методы, не фактические значения |
U.Work |
Факт выполнения |
Записывать с Γ_time, Γ_work (затраты), performedBy (RoleAssignment) |
Variance |
Отклонение от плана |
Фиксировать в журнале Work, не править План |
Правило (A.15.3:4.3): Если факт отличается от плана — это variance, а не «обновление плана». План остаётся базовой линией для аудита.
5. Собирайте носители доказательств (A.10)
Согласно A.10, утверждение без evidence carrier — это декларация, а не доказательство.
| Утверждение |
Требуемый Evidence Carrier |
| «Данные перенесены» |
Лог скрипта с хеш-суммами, счётчиками записей |
| «Инвентаризация проведена» |
Подписанный акт с ролями Steward + Auditor |
| «Сотрудник обучен» |
Сертификат / тест с баллами, привязанный к U.Capability |
| «Период закрыт» |
Оборотно-сальдовая ведомость со статусом Locked и подписями |
Правило (A.10): Evidence carrier должен быть отдельным объектом от утверждения. Ссылка на него — в adjudication.evidenceRefs.
6. Управляйте способностями и ролями (A.2.1, A.2.2, A.2.5)
Согласно A.2.1 и A.2.2:
U.Capability — способность (может ли делать)U.RoleAssignment — авторизация (разрешено ли делать)U.RoleStateGraph — состояние роли (Active / Suspended / Authorized)
Применение:
- Перед назначением задачи проверить:
Capability.WorkScope ⊇ JobSlice (A.2.2:4)
- Перед началом работы проверить:
RoleAssignment.State = Authorized (A.2.5)
- После обучения обновить:
Capability с новыми WorkMeasures
Правило (A.2.2:5): Если вы говорите «может делать» — это Capability. Если «назначен делать» — это RoleAssignment. Не смешивать.
7. Ведите Design-Rationale Record (E.9)
Согласно E.9, каждое важное решение должно иметь обоснование:
DRR {
id: DRR-MIG-001,
decision: «Episode Policy = retryOf для производственных заказов»,
alternatives: {resumptionOf, abort},
rationale: «Bridge.CL=1: технологический маршрут не маппится»,
consequences: «Потеря 3 дней работы; стоимость WIP списана»,
owner: Role[ProductionManager:NewERP],
Γ_time: [2026-03-15],
reviewDate: [2026-04-15]
}
Правило (E.9): DRR — это не «протокол совещания», а цитируемый артефакт с owner и сроком пересмотра.
8. Применяйте Verifiability по F.12
Согласно F.12, судите обещания по тому, что произошло, а не по тому, что планировалось:
| Ячейка |
Вопрос |
Что записать |
| ClauseCell |
Что обещано? |
Claim ID с формулировкой |
| WorkCell |
Что сделано? |
U.Work с Γ_time и performedBy |
| MeasureCell |
Как измерили? |
U.Observation с числами и единицами (KD-CAL) |
| Window |
Когда действовало? |
U.QualificationWindow (Γ_time) |
Вердикт: Выносится только если все 4 ячейки заполнены и связаны.
9. Явное время (A.2.6:8.2)
Согласно A.2.6:8.2, implicit «latest» запрещён. Всегда указывайте:
Γ_time как point, window или policy- Не «как можно быстрее», а «до 2026-03-31 23:59»
- Не «после утверждения», а «после SpeechAct ID=X в окне [..2026-03-20]»
10. Чек-лист для повседневного применения
| Ситуация |
FPF-действие |
Артефакт |
| Получили задачу |
Проверить WorkScope ⊇ JobSlice |
U.Capability sheet |
| Назначили роль |
Зафиксировать RoleAssignment с Γ_time |
U.RoleAssignment record |
| Начали работу |
Записать U.Work с началом Γ_time |
Work log |
| Завершили работу |
Записать U.Work с окончанием, прикрепить evidence |
Work record + carriers |
| Было отклонение |
Зафиксировать Variance, не править план |
Variance journal |
| Приняли решение |
Записать DRR с альтернативами и обоснованием |
DRR |
| Утвердили что-то |
Зафиксировать U.SpeechAct с подписью |
SpeechAct record |
| Дали обещание |
Оформить U.Commitment с subject/modality/scope/window/referents/adjudication |
Commitment record |
| Проверили результат |
Заполнить F.12 quartet (Clause/Work/Measure/Window) |
Acceptance record |
11. Что НЕ делать (анти-паттерны по FPF)
| Анти-паттерн |
Почему плохо (FPF) |
Как исправить |
| «Система гарантирует» |
Subject = episteme (нарушение A.2.8:C1) |
Назначить роль: «DataSteward MUST…» |
| «Сделаем ASAP» |
Implicit «latest» forbidden (A.2.6:8.2) |
Указать Γ_time point или window |
| «Процесс нарушен» |
Смешение Method/Work (A.15) |
Уточнить: рецепт нарушен или факт выполнения? |
| «Все согласны» |
Нет SpeechAct evidence (A.2.9) |
Зафиксировать: «SpeechAct ID=X, signed by Role Y» |
| «Данные целы» |
Нет evidence carrier (A.10) |
Приложить: лог с хеш-суммами, акт сверки |
| «План изменили» |
Variance не зафиксирована (A.15.3) |
Оставить план, записать variance в журнал Work |
| «Сотрудник обучен» |
Нет U.Capability measures (A.2.2) |
Приложить: тест с баллами, сертификат с Γ_time |
12. Итог: FPF как операционная система для мысли
Согласно E.1 и E.13, FPF — это не «библиотека ответов», а инфраструктура для рассуждения:
- Внеш化яйте мысль (E.1): Записывайте решения в артефакты (DRR, Commitment, Work), а не держите в голове.
- Разделяйте страты (A.7): Описание ≠ Объект ≠ Носитель.
- Трассируйте (A.2.1:7.1): От Work → RoleAssignment → Role → Context.
- Верифицируйте (F.12): Судите по фактам (MeasureCell), а не по планам (ClauseCell).
- Эволюционируйте (B.4): Поднимайте Formality (F) поэтапно: F1 (скетч) → F3 (контролируемый нарратив) → F5 (исполняемая семантика).
Практическое правило: Если вы не можете записать решение в форму артефакта FPF (Commitment, Work, DRR, Bridge), значит, оно ещё не готово к исполнению. Вернитесь к abduction (B.5.2) и уточните гипотезу.