От файла к проверяемому набору
Обычный файл отвечает на практический вопрос: что открыть или передать. Но рабочий цифровой проект часто состоит из нескольких представлений. Есть результат, удобный для просмотра или публикации, есть редактируемое состояние, из которого этот результат получен, и есть сведения, связывающие их с конкретным этапом работы. Если перенести только один компонент, продолжение работы может оказаться невозможным. Если случайно соединить компоненты разных этапов, проект откроется, но уже не будет тем состоянием, которое ожидал получатель.
В модели EOC эти роли обозначаются как FP, ED и R. FP — fixed representation, фиксированное представление результата. ED — editable state, редактируемое состояние. R — данные ревизии, которые логически связывают компоненты одного состояния. Это модель ролей, а не требование хранить всё в одном физическом поле. Подробная схема приведена на странице технологии Recoverable.
Проверяемым объект становится тогда, когда ожидаемый состав и контрольные значения зафиксированы, а процедура может сравнить с ними фактически полученный набор. Проверка не делает предположений по похожему имени файла или времени изменения. Она должна установить, что обязательные компоненты присутствуют, их содержимое соответствует описанию и все они относятся к одной выбранной ревизии.
Что именно сообщает проверка
Результат проверки ограничен доступными доказательствами. Совпавшая контрольная сумма сообщает, что проверенные байты совпадают с теми, для которых было сохранено ожидаемое значение. Проверка состава сообщает, что обязательные элементы найдены. Проверка связи ревизии сообщает, что FP, ED и данные R образуют один ожидаемый набор. Вместе эти сигналы позволяют принять решение до того, как содержимое будет передано приложению для восстановления.
Отсюда следует различие между целостностью и подлинностью. Целостность отвечает на вопрос, изменилось ли содержимое относительно известного значения. Подлинность требует основания доверять самому значению и субъекту, который его сформировал. Политика доступа, контекст проекта, аудит и другие механизмы могут дополнять проверку, но не должны незаметно подменять её смысл.
Почему проверка выполняется до восстановления
Если сначала распаковать или открыть полученное состояние, а затем искать несоответствия, приложение уже может обработать повреждённые либо смешанные данные. Безопаснее разделить этапы: принять объект, проверить состав и целостность, проверить согласованность ревизии, получить решение и только после разрешающего результата передавать данные в restore-процесс. В Recoverable несогласованный набор должен быть заблокирован, а результат проверки — отражён в отчёте.
Такой порядок особенно важен для проекта, который продолжат редактировать. Фиксированное представление может выглядеть корректно, пока редактируемый компонент относится к другой версии. И наоборот: рабочие файлы могут открываться, но опубликованный результат не соответствовать им. Проверяемая связь не доказывает смысловую правильность проекта, зато не позволяет тихо принять компоненты разных состояний как одну ревизию.
Как читать публичный контракт Recoverable
Текущий публичный контур разделяет описание модели и технический интерфейс. Раздел Recoverable EOC объясняет контейнер, его компоненты и доступный baseline. Раздел для разработчиков описывает публичный API, аутентификацию, scopes, tenant/project context и операции проверки. Это полезное разделение: продуктовый термин не превращается в обещание маршрута, которого нет, а техническая документация остаётся привязана к фактическому контракту.
На практике начинать стоит не с формата архива, а с границ объекта. Нужно определить, какой результат считается фиксированным, какие файлы нужны для продолжения работы, какие элементы обязательны и когда создаётся новая ревизия. Затем для каждого компонента фиксируют описание и контрольную сумму, а данные ревизии связывают их в одну единицу восстановления.
Короткая проверка здравого смысла
- Можно ли однозначно назвать ревизию, которую предстоит восстановить?
- Известен ли обязательный состав этой ревизии?
- Есть ли ожидаемые контрольные значения, полученные из доверенного процесса?
- Будет ли несоответствие остановлено до передачи данных приложению?
- Сохраняется ли понятный результат проверки без секретов и содержимого пользовательских файлов?
Если на эти вопросы есть точные ответы, цифровое состояние можно рассматривать как проверяемый объект. Если ответы зависят от ручного выбора «похожих» файлов, модель остаётся хрупкой: открываемость ещё не означает согласованность.