Проверяемая архитектура переносимого цифрового состояния

В этой модели FP — fixed representation (фиксированное представление), ED — editable state (редактируемое состояние), а R — revision data (данные ревизии). Для ревизии i обозначения FPᵢ и EDᵢ описывают два компонента, а Rᵢ логически связывает их как один согласованный набор.

Descriptors/hashes Hfpᵢ и Hedᵢ позволяют сверить содержимое FPᵢ и EDᵢ с ожидаемыми описаниями. Их наличие не означает, что Hfpᵢ и Hedᵢ обязаны быть физически вложены в Rᵢ: формат может разместить данные иначе, сохранив проверяемую связь.

Сначала Recoverable отдельно проверяет требуемые компоненты: соответствует ли FPᵢ descriptor/hash Hfpᵢ и соответствует ли EDᵢ descriptor/hash Hedᵢ. Положительный локальный результат подтверждает целостность конкретного компонента, но ещё не подтверждает, что пара принадлежит одной ревизии.

После локальных проверок revision check сопоставляет компоненты с Rᵢ. Только сочетание локальной целостности и согласованной связи может открыть путь восстановления.

FP18 и ED17 могут независимо пройти локальную проверку: содержимое каждого соответствует собственному descriptor/hash. Но их номера и проверяемые связи относятся к разным ревизиям, поэтому вместе они не образуют согласованный набор.

Совместная упаковка, имя файла или порядок компонентов не заменяют revision consistency. При обнаружении mixed revision восстановление ED блокируется.

ED может присутствовать в переносимом объекте, но передача этого состояния приложению начинается только после verification gate. При положительном результате adapter при необходимости преобразует уже проверенное ED в форму, понятную прикладной среде.

При отрицательном результате restore path для ED закрывается. Это не означает автоматическое уничтожение объекта: в предусмотренном формате FP может оставаться доступным для просмотра или другой безопасной операции.

После успешной проверки EDᵢ может быть восстановлено и передано приложению. Результат редактирования не подменяет один компонент внутри старой ревизии: формируется ревизия i+1 со своими FP, ED, descriptors/hashes и revision data.

Так сохраняется различие между неизменным согласованным набором ревизии i и новым согласованным набором ревизии i+1.

Некоторые форматы могут хранить опциональную карту между элементами фиксированного представления и объектами редактируемой структуры. Она помогает прикладным сценариям связывать область результата, слой, параметрический элемент или другой объект с соответствующей частью ED.

Correspondence map не обязательна для каждого Recoverable object, не заменяет integrity/revision checks и не обещает универсальное восстановление в любом приложении. Если карта присутствует, формат должен явно определить её идентификаторы, ревизию и назначение.

POST /v1/integration/ingest создаёт job и ревизию объекта, упаковывает EOC, выполняет strict verify, определяет формат, применяет policy, формирует evidence, сохраняет артефакты и записывает события. Результат выражается машинным решением ALLOW / REJECT / QUARANTINE. Gateway обращается к внутреннему /api/integration/ingest только после проверки credential и scope.

В проверенной non-production конфигурации EOC service 0.27.0 метаданные и события сохраняются в PostgreSQL, а артефакты проходят через S3-совместимый storage adapter. Для S3-клиента подтверждены запись, чтение, удаление, SHA-256 integrity, idempotency, безопасные ключи и изоляция tenant/project. Компенсация откатывает частично записанные данные при ошибке операции. Production rollout этого storage-контура требует отдельной runtime-проверки.