Beta Channel — Privacy Supplement

This page supplements the Vrtmv Privacy Policy, which governs generally. It describes the one collection the beta channel adds, in the detail the enrolment consent depends on. Where the two differ on the beta channel, this page is the more specific statement.

Applies to beta-channel builds only · Privacy Policy effective August 1, 2026

1. Scope

This supplement describes how Vrtmv handles diagnostics reported by beta-channel builds of the Vrtmv migration and attestation client. Everything else — account information, website and portal data, customer environment data, retention, rights, and contact — is covered by the Privacy Policy linked above.

2. Data locality

Vrtmv is built so that customer workload data — disk image contents, configuration, and extracted inventory — stays within the customer environment. From a stable-channel build, the only data sent to the hosted Vrtmv API is package identifiers (for translation) and a one-way, depersonalized VM fingerprint (for metering). See the architecture and security posture documentation.

2a. The beta channel

An account may opt into the beta channel, which is the one exception to the paragraph above. Beta builds additionally report diagnostics on every run: engine version and channel, which command ran, whether it succeeded, the source and target operating systems, timings, counts (never names), which optional code paths ran, and — on a failure — an error message from which file paths, host names, IP addresses, email addresses and credential-shaped strings have been removed.

That redaction runs twice, once in the binary before anything is transmitted and again on the Vrtmv side before storage. It is a best-effort filter rather than a guarantee: it recognises the shapes that carry identity, and it cannot recognise every one. Diagnostics are retained for 180 days and then deleted.

Vrtmv engineers read beta diagnostics to identify and correct defects. Vrtmv may email an enrolled account when an issue its builds reported has been fixed, naming the release that fixes it, and a Vrtmv engineer may open a support ticket on the account's behalf about such an issue. Both are stated here because they are uses of the data that the act of collecting it does not by itself imply.

An enrolled account can view every diagnostic report its builds have sent, in the customer portal, and delete any or all of them. Deletion is permanent: the records are removed, no copy or anonymised remainder is retained, and any pending notification tied to them is lost. Vrtmv retains only a record that a deletion occurred and how many records it covered.

Enrolment is per account and requires two acts by two roles: a user reads the terms and requests access, recording their acceptance, and an account administrator is then shown the same terms and accepts them on the account's behalf. The administrator's acceptance is what enrols, and it covers every member of the account rather than only the person who asked. Both acceptances are retained separately, each with its own actor and terms version. Together they are the whole consent — diagnostics cannot be disabled separately while remaining on the channel. Only an administrator can leave the channel; leaving stops further reports immediately but does not retroactively delete reports already made, which Vrtmv will do on request. Stable builds cannot report diagnostics under any configuration: the channel is fixed when the binary is compiled, not read at run time. Any build will state which channel it belongs to when run as vrtmv diagnostics.

3. Contact

Questions about this supplement, or a request to delete diagnostics already reported: contact your Vrtmv account manager, or use the privacy contact in Section 17 of the Privacy Policy.