Data Deletion and Offboarding

A company leaving Covio moves through a fixed sequence of states. The sequence is a whitelist: a transition that is not on it is impossible, and only one code path in the whole platform is permitted to write a company's state at all.

1. 1ACTIVE — a customer. Everything works.
2. 2CANCELLING — the company has said it is leaving. Machines keep sending data, deliberately: a commercial decision must not silently stop a factory's record.
3. 3EXPORT_PENDING — the export bundle is being produced. The lifecycle cannot advance past this without one.
4. 4TERMINATED — the account is closed. The retention clock starts here.
5. 5RETENTION — the data is held, awaiting the end of the retention period.
6. 6PURGED — the data has been destroyed and a certificate has been written.

A company that comes back gets a new company record. TERMINATED is terminal in the customer sense; there is no reactivation that resurrects the old data.

The bundle is assembled by nineteen modules, each of which declares what it owns, reads it for one company only, and flattens it for a spreadsheet. Every query in it is filtered by company; there is no "export everything and filter afterwards" step, because by the time a bundle holds a row it should not, the mistake has already left the building.

What it contains: the company record and settings; every person who worked there and what they could do; invitations; sites; entitlements; the plan and billing history; machines with their full measurement ledger, calibration lineage, daily figures and the findings drawn from them; the wire catalogue and run ledger, panel photographs named by checksum, and every validation check; document metadata with a SHA-256 for each file and the ledger of who opened it; compliance activities, cycles, approvals and the complete decision history; attention items with their evidence; notifications; WhatsApp consent records including the exact wording agreed; the Tally reading in full; the support-access log; and the platform action ledger.

Authentication material is deliberately absent and always will be: password hashes, sessions, verification challenges, device API keys. Handing those over would be a breach performed at the customer's own request.

Not settled / not in placeWhat Covio cannot put in the bundle is named in the manifest with its reason, not silently omitted. Today that is: device, document and compliance history still held in the legacy Mikiwire workspace, which Covio has not migrated; and document file bytes, which are unbounded in size — the metadata and a SHA-256 per file are in the bundle, and the files themselves stay downloadable through the authenticated, ledgered route for the whole retention window.

The download link is authenticated and valid for 72 hours. A new one can be issued.

There is deliberately no single sweep that deletes everything belonging to a company. A sweep silently stops being complete the day a table is added, cannot express the order foreign keys require, and cannot express which part of the system owns a deletion. So eighteen modules each declare what they own, count it, delete it, and prove the count went to zero. The order between them is a dependency order, and the database refuses a wrong one rather than failing quietly.

• Document file bytes are removed from the store before the rows that describe them, and the removal is verified by counting files in the store — not by counting rows twice and calling one of them a file count.
• Append-only ledgers have exactly one named exit: a delete is refused by the database unless the transaction has first declared which single company is being purged.
• The company record itself is not deleted — the audit ledger points at it and refuses. It is scrubbed instead: the name and slug go, the identifier stays as the anchor the ledger points at.
• A person who is a member of another Covio company is never deleted. Only people left with no company anywhere lose their account, and with it their stored credentials.
• Three modules cover data still held in the legacy Mikiwire workspace. They have no delete function at all, deliberately, so that no code path can claim to have deleted them. The purge records them as not-owned rather than as zero.

A certificate is written at the end. It states what was deleted with counts, what was retained and on what basis, what was not owned, the policy version it ran under, and the date on which the last backup containing the company expires.

Not settled / not in placeCovio's software will not run a production purge right now, and this is by design rather than by omission. Two of the retention categories that gate destruction are unratified proposals, and the gate refuses rather than proceeding on a proposal. An operator who asks is given the reasons, not a boolean.

The practical effect: a company can leave, can be exported in full, and can be terminated. Its data then sits in the retention state until the periods are ratified. No customer has yet offboarded and no purge has ever run.

• The categories in question →

A purge removes the data from the live databases and the document store. It remains in encrypted backup sets until those sets age out 30 days later. The certificate states that date, because a company is not truly gone until the backups holding it are.

Not settled / not in placeRemoving a person from a company removes their access and their membership. It does not erase the record of what they did — an approval they made, a document they opened — because those are the company's compliance record and Covio has no mechanism to selectively erase within it. Whether an erasure right reaches those records is a question for counsel.

Covio drafted this document from its own systems rather than from a template, so what follows are the points where engineering cannot decide and a lawyer must.

1. 1Until the retention periods are ratified, no departing customer's data can be destroyed. Is it acceptable to hold a terminated customer's data indefinitely in the meantime, and must Covio tell a departing customer that in writing?
2. 2Is "complete metadata plus a SHA-256 per file" sufficient portability for document files, or must the bytes themselves be in the bundle?
3. 3Device, document and compliance history in the legacy Mikiwire workspace cannot be deleted by Covio's purge today. What must Covio tell a customer whose data is in that position?
4. 4The company record is scrubbed rather than deleted, leaving an identifier the audit ledger points at. Is that sufficient deletion?
5. 5Does an individual's erasure right reach approval history and document-access records that form the company's compliance evidence?
6. 6Is 30 days of encrypted-backup survival after a purge an acceptable erasure horizon to state in a contract?