[sinkog]

Documentation only: the Backblaze B2 preflight verification record for V1, V2, V3 and V6 of the storage proposal (#34), at documentation level (docs/en/T3-B2-PREFLIGHT-VERIFICATION.md). No account, bucket, key, test object or upload exists or was made; S10 stays held; the archive is untouched; the second copy stays NOT BACKED UP. A statement in documentation is not a passed deletion or permission test, and none is recorded as passed. Review does not authorize merge.

For each check, three separate lists: what the provider's documentation establishes (with the page and how it was read), what it does not establish, and what only a throw-away bucket can show (the tests are written out, each marked "not run").

• V1 (Object Lock and versions). Documented: compliance retention cannot be removed by any user and can be extended, one to 3 000 days; changes or deletions of a locked file fail, lifecycle rules cannot delete a locked version; buckets keep versions by default, a name-only upload adds a version, an older version is read by File ID; a delete refused by Object Lock returns HTTP 401 access_denied on the native API. Not established by the pages read: that an upload or delete under the same name leaves the locked version in place (only a forum post quoting the documentation says so); the S3-API error for a versioned delete of a locked version (the page is stale and silent); what bypassGovernance does to a compliance version.
• V2 (two-factor). Documented (the backup product's pages for the same Backblaze account; B2 is an "Enabled Product" of it): authenticator-app (TOTP), ten backup codes, SMS fallback after the first payment. Not established: that these are the pages for a B2-only account, any hardware key, a way to require it, the recovery path when device and codes are both lost. Several pages refused automated access.
• V3 (extending retention without delete rights). Documented: b2_update_file_retention needs the writeFileRetentions capability and mentions no readFiles, writeFiles or deleteFiles; compliance retention can be extended, not removed; a bucket-restricted key may carry exactly the retention capabilities. Not established: what a shortening attempt returns, whether listFiles is needed to find the File ID, which capabilities the S3 path needs, and that a key without deleteFiles really extends.
• V6 (the end of an account). The Terms of Service (effective 2026-04-16, read in full): Backblaze may suspend or terminate on non-payment and "may delete your data"; the Terms set no deletion timelines and never mention Object Lock; closing a B2 account requires removing all files, buckets and non-master keys first, and that page is silent on locked files. So the lock protects against the customer's identities, not by a promise of the provider; this confirms the "account is the weakest point" risk of the proposal and is why the second copy of a different class is required. The non-payment article could not be read; a written answer from Backblaze (four questions in the record) is needed and no test bucket can replace it.

Verdict of the record. The documentation supports the central claim, that a compliance-locked version cannot be shortened or deleted by the customer's identities. It does not establish that the provider will keep it. B2 cannot be said to meet the T3 retention contract until V1 and V3 have passed on a throw-away bucket and the written answer on V6 is in the record. S3 stays "a conditional go after V1 to V3 and V6".

How the sources were read. Through a fetch tool that returns an extract of the page for a question, not the page; several provider pages refused access (403) or no longer exist (404) and are named; before an approval relies on a line, the owner re-reads the cited page.

Not claimed: that any check passed; that a deletion, shortening, overwrite or permission test was run; that B2 meets the retention contract; that the provider will keep locked data; that two-factor can be required; anything about an account, a payment method or a person.

Review round (2026-11-05): (1) The V6 statement is no stronger than the evidence. "The lock does not bind the provider" is gone from the record. It now says, in the sentence the review proposed: The available documentation does not establish whether compliance retention survives account suspension, termination, non-payment, or provider-initiated deletion. Until Backblaze confirms this in writing, provider-side preservation remains an unverified assumption. The Terms neither exempt locked data from the provider's right to delete nor say that they override the lock, so neither "the provider may delete locked data" nor "the provider must keep it" follows. The record also says that data the customer cannot delete and data the provider is committed to keep are not the same thing; the documentation describes the first, the inquiry asks for the second. (2) Appendix A: the draft of the written inquiry to Backblaze, NOT SENT (no personal data, no account identifier, no secret; the data is public). Five questions: compliance retention against suspension, termination, non-payment and provider-initiated deletion; the phases and notice periods; closing an account with locked files; the effect of a committed term; changes of the Terms or the service. For every answer it asks Backblaze to separate (A) what is technically possible or current practice from (B) what is a contractual commitment, with the document, clause, version or date, and whether it holds for the whole retention period, and to say whether a support answer is binding. The record states that a technical statement or a practice does not close V6; only a provider commitment that holds for the retention period does, and otherwise the second copy of a different class carries the guarantee. Sending it, creating an account, the trial and the upload stay on hold. New HEAD, so the gate check is needed again.