ProvenanceGraph

Provenance model: what changed, when, and by whom?

The design favours append-only revision records over silently overwriting an artefact. A new revision should refer to its predecessor and preserve evidence of the change. This makes a history auditable: an investigator can ask not only what the latest artefact contains, but how it came to exist and which inputs and actions contributed.

W3C PROV provides a useful conceptual vocabulary: an Entity represents a thing such as an artefact version; an Activity represents processing, revision or recovery; an Agent represents a person or software service with responsibility for an activity. Keeping these concepts separate is useful when the same file passes through several services. The design is PROV-informed; formal interchange conformance is a future validation goal.

Storage adapters and cloud-provider boundaries

The backup architecture uses a protected-store abstraction so the core recovery rules do not need to know the details of every cloud SDK. An adapter must map provider-specific object versions, retention settings, checksum and content-length evidence into a common verification contract. This allows the core workflow to ask whether a backup is recoverable while still retaining the provider-specific metadata that makes a claim testable.

Development work includes adapters for AWS S3, Azure Blob Storage and Google Cloud Storage. Their SDK-facing behaviour has been exercised with mocked provider responses, including mismatched content, altered receipts and interrupted transfers. The difficult trade-off is avoiding a lowest-common-denominator interface that conceals different provider guarantees: a retention flag returned by an API is not automatically proof that an independent administrator could not remove the data.

Integrity and cryptographically signed receipts

SHA-256 is useful for comparing expected and recovered bytes, but a hash stored alongside an artefact can be modified by someone who can edit both values. The receipt design uses Ed25519 signatures to bind claims such as backup identity, storage version, checksum, retention metadata, issuing key identifier and time. A verifier checks the signature and compares the claims with the actual retrieved content and provider metadata.

A signature answers a narrower question than people sometimes expect: did an authorised signing key attest to these exact receipt fields? It does not prove the original data was truthful, the signer was not compromised, the storage provider honoured retention, or that data can be restored quickly. Those need independent controls and operational tests.

Testing, threat boundaries and unresolved work

The Java 21 and Gradle prototype has test work around signed receipts, content-length and checksum mismatches, source-version reuse, interrupted recovery and empty backups across provider adapters. These cases matter because a backup can appear present and still be unsafe: it might be truncated, linked to the wrong revision or paired with a tampered receipt.

The remaining security questions are as important as the code. Production claims require independently controlled signing keys, trustworthy storage identity, narrowly scoped credentials, persistent verification receipts, durable replay protection and a reproducible recovery drill. Those guarantees cannot be established purely by mocking SDK responses, and no live-provider immutability certification is claimed.

• Keep version identity and provenance alongside every integrity check; never assume a matching filename denotes matching bytes.
• Reject a recovery when the receipt, stored object version or measured content does not match the expected source revision.
• Exercise real provider IAM and retention controls separately, with cost limits and non-sensitive test data, before describing any provider as independently hardened.