R1.1:Tasks5 - Задание: Оцените качество эпистемы из руководства R1. Распожаризация: как не «тушить пожары», а избегать их появления

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

Взял спецификацию одной из интеграций данных со смежной организацией.

Ее можно назвать описанием так как в ней есть:

  • описание зачем делается эта интеграция
  • список терминов
  • описание схем и тестовые примеры входных и выходных данных, требования к типам и диапазонам
  • алгоритм трансформации
  • расписание запуска

Моделью если и можно назвать, то ограниченно - есть только “happy path” пошаговый алгоритм того, что именно делается в интеграции и в каком случае этот алгоритм выполняется.
Нет крайних случаев или описания того, что будет происходить в случае сбоя.

И так, это эпистема и описание, но не модель.


Загрузите в свою LLM, усиленную FPF, этот рабочий документ, и дайте ей команду “Определи как онтолог, является ли информация из этого документа чистой эпистемой/intensional object, описанием или спецификацией. При ответе на вопрос руководствуйся паттернами A1 и E10.D2 из FPF” .

Конституция C.2.1 <ClaimGraph, EntityOfConcern, ReferenceScheme> восстанавливается. Документ является description episteme (эпистемой описания).

Является ли документ спецификацией?
Нет. Раздел 4 назван «Спецификация», но E.10.D2:4.1.3 (Specification-use admission) требует выполнения четырёх условий. Не названы:

  • Именованный harness / валидационное отношение
  • Сохранение/обновление viewpoint при reliance


    Если вам не понятен ответ LLM, скопируйте в запрос фрагмент ответа и попросите LLM его пояснить. Попросите её покритиковать этот текст, задайте вопрос, насколько это правильно.

    Расспросил, что такое:

  • Именованный harness / валидационное отношение.
    Получается, что нужно добавить в описание ещё и описание механизма проверки того, что описываем в спецификации.
  • Сохранение/обновление viewpoint при reliance
    Тут нужно указать, какая роль как проверяет сделанное


    Сделайте выводы: где ваши догадки оказались правильными, а где нет. Опубликуйте результат в клубе МИМ.

    Итог:

  1. не является чистой эпистемой (я считал, что если описание, то уже эпистема), но сама эпистема - не EntityOfConcern
  2. Описание - да, преимущественно (множественные EntityOfConcern с т.з. доступной LLM)
  3. Спецификация - нет, но я оценивал текст как модель (то, что позволяет делать выводы о поведении описываемой системы), а не спецификацию. Требования к полной спецификации, которых не было в моем описании показывают, какой результат должна показывать система в случае, если все работает как задумано.