FPF ((raw text) -> Связь "План" - "Физический мир"

Блоги Юрий Калин (блоги)
1

Связь “План” - “Физический мир”
На основе спецификации FPF (паттерны A.15, A.4, A.3, A.7), связь «плана» с физическим миром является опосредованной и строго регламентированной. План не воздействует на физический мир напрямую.

1. Онтологическийc статус (A.15.2:4.1, A.7)

  • План (U.WorkPlan) — это U.Episteme (артифакт знания/описания). Он существует в Design-Time (T^D). Это декларация намерений, а не физическое событие.
  • Физический мир представлен через U.Work (датированное событие исполнения) и U.System (держатель способности). Это Run-Time (T^R).
  • Принцип: Описание (U.Episteme) ≠ Объект/Событие (U.System/U.Work). План сам по себе не изменяет состояние мира (A.7).

2. Механизм связи: Исполнение и Вариация (A.15.2:4.5)

Связь осуществляется через отношение fulfilment (исполнение) между событием и намерением:

  • Ссылка baseline: Каждое событие U.Work может ссылаться на элемент плана (PlanItem) как на базовую линию (plannedAs → PlanItem).
  • Вариация (Variance): Физическая реальность сравнивается с планом через измерение отклонений:
    • Δt (Schedule): Раньше/позже запланированного окна.
    • Δc (Cost): Фактические затраты ресурсов vs бюджет плана.
    • Scope/Quality: Фактический метод/спецификация vs запланированные.
  • Правило: План не переписывается «задним числом» под факт (no backfill). Если реальность отличается, фиксируется вариация в U.Work, а не редактируется U.WorkPlan (A.15.2:4.5, A.15.3:8.1).

3. Ресурсный след (B.1.6, A.15.2:4.2)

  • В плане: Указываются budgets/reservations (планируемые энергия/материалы/слоты оборудования). Это эпистемические ограничения.
  • В физическом мире: U.Work несет actual spend (фактический расход), фиксируемый в агрегации ресурсов Γ_work.
  • Связь: Сопоставление бюджета плана и факта работы позволяет оценить эффективность использования физических ресурсов.

4. Агентное воздействие (A.3, A.15.2:4.2)

  • Трансформер: Изменения в физическом мире требуют U.System, играющего роль TransformerRole (Принцип Трансформера, A.3). План не является трансформером.
  • Роли: План указывает intended performers (требуемые виды ролей или предложенные назначения RoleAssigning).
  • Исполнение: Фактическую работу выполняет держатель (Holder) через валидное U.RoleAssignment в момент исполнения (A.15.3). План лишь декларирует намерение назначения.

5. Временное разделение (A.4)

  • Дизайн-время (T^D): Интервал, когда план может быть изменен структурно.
  • Ран-тайм (T^R): Интервал, когда происходит физическое исполнение (U.Work).
  • Связь: План «живет» в T^D, но проецируется на окна в T^R. Пересечение T^D и T^R для одного и того же состояния запрещено (Temporal Duality).

6. Аудит и Доказательства (A.15.2:4.5, A.2.8)

  • Связь верифицируется через аудит: U.Work.Audit цитирует PlanItem как baseline.
  • Если план не позволяет зафиксировать вариацию (отклонение факта от намерения), он считается «картинкой календаря», а не инструментом управления (A.15.2:4.5).

Резюме: План связан с физическим миром не как причина, а как базовая линия для сравнения. Физический мир воздействует на себя через U.System (Трансформер), выполняющий U.Work, который затем сравнивается с U.WorkPlan для выявления вариаций и учета ресурсов.