OKF v0.2: что изменилось в спецификации

Что вышло 25 июля

Версия 0.1 спецификации OKF была опубликована 12 июня 2026 года. Ровно через шесть недель, 25 июля, Google Cloud выпустил версию 0.2. Формулировка задачи в v0.1 была простой — описать, что представляет собой концепт. Версия 0.2 отвечает на другой вопрос: кто за этим концептом стоит и можно ли ему доверять.

Логика такая: когда документ пишет человек, ответственность подразумевается сама собой — кто-то поставил под текстом своё имя. Когда агент генерирует десять тысяч концептов за ночь, эта гарантия исчезает, и системе, которая читает бандл дальше, нужны проверяемые сигналы, а не подразумеваемое доверие. Все изменения v0.2 отвечают на эту проблему.

Четыре новых семейства полей

Все поля v0.2 опциональны — существующие бандлы v0.1 остаются полностью валидными, ничего не ломается.

Attestation — узкоспециальная механика для финансовых и аналитических команд, которым нужно доказать, что агент выполнил санкционированный запрос к BigQuery, а не придумал число сам. Для большинства сайтов это поле нерелевантно. Остальные три семейства касаются каждого, кто публикует бандл.

verified и три уровня доверия

Поле verified — список подтверждений, и у каждого подтверждения указан автор. Автор с префиксом human: читается иначе, чем автор-агент. На практике это даёт три уровня: концепт без подтверждений, концепт, подтверждённый машиной, и концепт, который проверил человек. Спецификация прямо оговаривает: потребитель не вправе отвергать концепт только за отсутствие verified — но само отсутствие поля тоже становится значимым сигналом в момент, когда веб заполняется сгенерированным текстом, который никто не читал.

Важная деталь: подтверждение — это не факт создания. Автор, который сам написал концепт, не может проставить себе verified просто по факту публикации — это должна быть отдельная, более поздняя проверка того же или другого автора.

stale_after вместо таймера

Второе поле, которое стоит взять на вооружение сразу, — stale_after. Это абсолютная дата, а не счётчик дней от публикации: устаревание концепта становится фактом, который можно проверить, а не результатом отдельного вычисления где-то ещё. Поле status при этом описывает текущее состояние (например, stable), а stale_after — горизонт, после которого его стоит перепроверить.

Два переименования — обратная совместимость сохранена

Вместе с новыми полями пришли два переименования, оба backward-compatible: timestamp стал generated.at, а список # Citations в теле файла превратился в массив sources внутри frontmatter. Старые бандлы, где использованы прежние названия, продолжают читаться корректно — миграция добровольная и не имеет жёсткого срока.

Нужно ли переделывать существующий бандл

Нет, и это не отложенная формальность, а прямое следствие того, как устроено версионирование OKF: минорные версии добавляют поля, не меняя обязательных. Если у вас уже есть бандл на v0.1 — он рабочий. Практичная тактика — не переписывать всё разом, а добавлять поля trust и lifecycle по мере того, как вы возвращаетесь к конкретным концептам: обновили страницу — проставили verified и стало ли что-то stale, для остального не спешить.

Что это меняет для новых бандлов

Если вы только собираете первый бандл — разумно закладывать поля v0.2 сразу, а не догонять потом. Минимум: generated с указанием автора (у большинства сайтов это будет human: плюс имя редактора) и stale_after на каждом концепте, который со временем теряет актуальность — прайсы, регламенты, обзоры продуктов. verified добавляйте только тогда, когда реально перепроверили концепт отдельно от написания — иначе поле обесценивается так же, как обесценился бы штамп «проверено», который ставят не глядя.