Trust And Safety Model#

BenchVault is intentionally read-only against production LabArchives access. Its production client permits browser login URL generation, user-access lookup, and full-size notebook backup download. It rejects write-like operation names and backup options that would omit attachments.

Backup Correctness#

For a successful notebook backup, BenchVault:

  • downloads the full archive into a temporary .part file first,

  • extracts the archive locally,

  • parses LabArchives JSON tables or a compatible SQLite backup layout,

  • verifies reported original attachment files,

  • writes a readable/search copy,

  • writes backup_record.json,

  • seals protected files with integrity_manifest.json,

  • appends the manifest hash to the local integrity ledger.

Tamper Evidence#

When a selected backup is opened, BenchVault verifies:

  • the integrity manifest still exists,

  • the current manifest hash matches the local seal,

  • the local ledger chain is not broken through that entry,

  • every protected file still exists,

  • every protected file still has the expected SHA-256,

  • no unexpected protected-file additions are present.

If the copy is not verified, the viewer shows Local copy not verified before normal reading.

What This Does Not Prove#

A local-only seal cannot defeat a notebook owner who controls the computer, app installation, local clock, backup folder, and local seal ledger. Misconduct- resistant evidence requires at least one witness record outside that owner’s control.

BenchVault also cannot prove that the live LabArchives notebook was not edited before backup. That requires LabArchives server audit logs, revision history, export records, access logs, and institution-managed chain of custody.

Secret Handling#

Credentials, notebook access records, notebook IDs, schedules, integrity records, backup archives, and AI API keys stay local or in platform secret storage. Public docs and code must not contain local absolute paths, credentials, raw backups, or source PDFs.