Перейти к основному содержимому

Часть V. Авторство

19. Где уместен LLM​

IDF — формат, в котором LLM отсутствует в рантайме. Это означает: ни одно решение, влияющее на состояние мира (confirm, reject, invariant check) или на рендер артефакта, не зависит от непредсказуемого провайдера. Детерминизм формата не соседствует с LLM; он его исключает.

Это не означает, что LLM бесполезен. Напротив, он уместен в трёх местах формата — все на этапе проектирования:

(а) Вывод онтологии из описания домена. Автор описывает домен текстом: «приложение для отслеживания привычек, в котором пользователь задаёт себе цели, видит ежедневные задачи и оценивает прогресс». LLM превращает описание в draft онтологии: сущности (Goal, Task, Habit, HabitLog), поля с типами и read/write matrix, роли, начальные намерения. Draft — не истина; автор подтверждает, корректирует или отвергает. После подтверждения онтология становится частью формата — декларативная, проверяемая, без скрытых LLM-допущений.

(б) Crystallize enrichment. Артефакт после кристаллизации — структура слотов и контролов. Но labels, placeholder'ы, iconHints, explanation-теггинги — это частично натурально-языковые строки, которые LLM может предложить. Enrichment — это witness-of-heuristic: reliability "heuristic", caveat «это предположение, требующее подтверждения». Автор принимает/отвергает enrichment; принятые — становятся частью projection или онтологии.

(в) Pattern suggestion. Pattern Bank расширяется постепенно. LLM-researcher pipeline просматривает живые приложения, находит повторяющиеся структурные паттерны, формулирует trigger-предикат и rationale, предлагает их как candidate-паттерны. Candidate становится stable после human review и добавления falsification-fixtures.

Что исключено из LLM:

  • Runtime UI — рендер артефакта в DOM происходит детерминированно, без LLM-стороны
  • Execute — валидация и применение намерений не обращаются к LLM
  • Materialize — voice, agent API, document не генерируются LLM; они порождаются чистыми функциями над артефактом
  • Анкеринг без witness-of-proof — переход witness'а от reliability: "heuristic" к более сильному классу требует декларативного доказательства, не LLM-подтверждения

Формат проектирует так, чтобы LLM можно было заменить любой другой design-time эвристикой (grep+линтеры, rule-based recommendation engine, human-only) без изменения формата и его гарантий.

Открытая epistemic задача: anchoring promotion writer (механизм превращения heuristic-witness в anchored-witness через counterexample-search). Пока не формализован; является частью дорожной карты формата.

20. Authored vs derived​

Каждый элемент артефакта имеет происхождение: он либо authored (автор проекции зафиксировал его), либо derived (движок вывел его из намерений и онтологии через кристаллизацию).

Это различие — первоклассное свойство артефакта. Его можно прочесть в artifact.witnesses[]: derived-элементы несут witness с соответствующим basis (pattern-bank, heuristic, структурный вывод), authored-элементы — witness с basis authored или отсутствуют (authored данные «не нуждаются в свидетельстве»).

Формат даёт автору два различающихся механизма влияния на derived-часть:

  • Preference (input modifier): projection.patterns = { enabled: [...], disabled: [...] }. Preference — часть входа кристаллизации. Артефакт остаётся чистой функцией: (intents, ontology, projection + preference, patternBank, features) → artifact. Два разных preference → два разных артефакта, оба валидны, оба рестоурабельны.

  • Slot-override (output freeze): авторская projection.slots явно переопределяет слот артефакта. Это — модификатор выхода, обход кристаллизации для данной части. Свойство «артефакт = f(input)» для этой части теряется: slot-override freeze'ит artifact-фрагмент.

Различие принципиальное для воспроизводимости. Preference сохраняет возможность rebuild-from-input; slot-override — не сохраняет. Формат не запрещает slot-override, но рекомендует preference как первый выбор:

  • Если желаемое поведение можно выразить как выбор из stable-паттернов Pattern Bank'а или другой flag'и — preference.
  • Если paradigma принципиально не уложена в преференсы (новый архитектурный приём, не предусмотренный форматом) — slot-override с явной заметкой для code review.
  • Если slot-override становится распространённым на конкретный случай — это сигнал расширить Pattern Bank или онтологию, а не тиражировать override.

Authored vs derived — не дихотомия «мой код vs движка». Это epistemological различие: derived-часть имеет формальное происхождение, authored — декларативное решение автора. Оба вида артефактов валидны; их микширование — свобода автора, обратная сторона — собственная ответственность за reproducibility.

21. Authoring environment​

Studio — отдельный инструмент исследования формата: визуализация онтологии как графа, Pattern Inspector для prototype-preview кристаллизации, viewer/role switching, Φ-playback. Формально Studio не является частью формата и не требуется для конформной реализации. Она — среда авторства, опциональная надстройка над форматом.

Важно, что Studio не участвует в рантайме. Если автор использует Studio при проектировании домена и потом поставляет его в production, никакой элемент рантайма не знает о существовании Studio. Это следует из строгого разделения:

  • Формат — описание (онтология, намерения, проекции, Pattern Bank)
  • Реализация — читатели формата (adapter, voice, agent, document)
  • Studio — инструмент работы с описанием (design-time)

Studio может быть реализована разными способами и разными командами — на React, как CLI, как LSP-plugin. Это также не ограничивает формат.

Концептуально Studio воплощает тезис, что формат читаем: его можно загрузить, отрендерить граф, прогнать falsification-fixtures, увидеть Pattern Bank match'и. Это — способ валидации гипотезы «формат достаточно ясен, чтобы быть auditable'ным». Наличие или отсутствие Studio — не аксиома формата, но её возможность — важный качественный тест.