Согласно первоисточнику, на GitHub опубликован проект под заголовком «Show HN: Prove your code produced your claims without making reviewers rerun it», предлагающий подписывать результаты запусков и верифицировать их без необходимости повторного выполнения кода рецензентом (источник).
Согласно первоисточнику, в состав kveritas входят команды init (старт сессии с параметрами --local, --harness, --disclosure и --show-names), run (выполнение произвольной команды под управлением kveritas), seal (подписание сессии в PDF), verify (локальная проверка и серверный аудит отчёта), prove/verify-proof (доказательство для отдельного файла) и harness-prove/verify-harness-proof (доказательство для шага harness), каждая из которых выполняет строго определённую функцию в жизненном цикле сессии (источник).
Согласно первоисточнику, при наличии в запуске model card команда seal формирует сертификат, проверяющий заявленные FLOPs относительно физически достижимых пределов оборудования: граница «Time» признаётся невозможной, когда произведение пиковой производительности GPU на активные секунды GPU плюс пиковой производительности CPU на ядросекунды CPU оказывается меньше заявленных FLOPs; граница «Energy» признаётся невозможной, когда заявленные FLOPs превышают измеренные джоули GPU, делённые на минимальную энергию на один FLOP; граница «Memory» относится к заявленному весу модели, превышающему наблюдаемую память GPU, и помечается как мягкая (источник).
Согласно первоисточнику, жёсткое нарушение указанных границ классифицируется как FABRICATION-IMPOSSIBLE и включается в состав подписи, что позволяет верификатору обнаружить невозможные заявления о вычислениях непосредственно при проверке отчёта (источник).
Согласно первоисточнику, каждый запуск представляет собой подписанную временную шкалу контент-адресуемых снапшотов, фиксирующих состояние исходного кода на старте, состояние по фазам и на завершении запуска, а также перечень изменений; эти снапшоты связаны через структуру Меркла и включены в подпись, при этом уровень раскрытия — redacted, names или open — задаётся пользователем на уровне сессии и влияет только на отображение, тогда как целостность всегда зафиксирована (источник).
Согласно первоисточнику, подпись в kveritas формируется по схеме: сначала из signing data строится canonical_json как компактный JSON с отсортированными ключами, затем вычисляется data_hash = SHA-256(canonical_json), payload собирается как строка вида «{data_hash}:{nonce}:{signed_at}», а итоговая подпись вычисляется алгоритмом RSA-PSS-SHA256 с использованием 4096-битного ключа; canonical_json, сама подпись и открытый ключ размещаются в PDF после маркера %%EOF между метками seal, и верификаторы хешируют хранимые байты напрямую (источник).