Offboarding and data erasure
What happens when a pilot, an engagement, or a signed-in account ends. There is no self-service delete button today — this describes what a written request triggers, what gets deleted outright, what gets cryptographically erased rather than deleted, and what EcoKure never held in the first place. The deletion clause a DPA would need is discussed in more legal detail on the DPA outline; this page is the operational version of the same position.
The distinction that decides what happens
Two systems, same as the DPA outline, and offboarding means something different for each.
The Assurance Runtime deploys inside the customer’s own account. Evidence, signing keys and decision records live there, not with EcoKure. In a standard deployment, offboarding this system is something the customer does inside their own infrastructure — there is nothing on EcoKure’s side to delete, because nothing was ever received.
Where EcoKure has anything to offboard, it is the website and portal: the account used to sign in, tenant records used to route a pilot, and correspondence. The table below is scoped to that.
What happens to each record type
| Record | On a written request | What remains |
|---|---|---|
| Ecosystem account & session | DELETED | Nothing. The session row is removed outright; there is no soft-delete flag to reactivate. |
| Tenant / integration record | DELETED | The tenant’s row and role memberships in EcoKure’s own control-plane database. Any associated API key is revoked as a first step, not an afterthought — see the security pack for the rotation and revocation path. |
| Contact messages & pilot enquiries | DELETED | Correspondence held for the relationship. Deleted on request; no separate retention policy is coded for this today, so a request removes what exists at the time it is actioned. |
| Signed contributor attribution (Lighthouse) | DE-ATTRIBUTED | A promoted public submission is not deleted — that would break the append-only record other people rely on for provenance — but the @username attribution is cleared, so the entry reads “Public contribution” going forward, the same as any anonymous one. See the public audit gallery for what that looks like. |
| Evidence chain entries, signing keys, decision records | NEVER HELD | These live in the customer’s own AWS (or equivalent) account under the Assurance Runtime deployment. EcoKure does not receive them in a standard deployment and has nothing to delete. |
| Support-session diagnostics | ERASED, SEPARATELY LOGGED | The one case where customer data can reach EcoKure — a support engagement working from logs the customer shared. Deleted at the end of the support session; the DPA outline’s counsel questions on breach notification and audit rights apply to this pathway specifically. |
Why some things say “erased” and not “deleted”
The public Lighthouse corpus is an append-only, shared chain. Deleting an entry outright would break the tamper-evidence for every other entry that chains from it — not just the one being removed. This is the identical constraint the DPA outline describes for the Assurance Runtime’s evidence chain, and it is handled the same way here: destroy everything that makes the entry attributable, and leave an unattributed record that was never readable without what was just destroyed.
This is cryptographic erasure and de-attribution, not deletion, and this page will not call it deletion. If that distinction matters to a specific regulatory obligation you are under, say so in the request and we will tell you plainly whether erasure satisfies it — the same open counsel question the DPA outline raises.
How to request it
There is no self-service control for this yet. It is a written request, handled by a person, on purpose — a destructive, irreversible action getting an automated one-click path before there is a second customer to have broken it against would be the wrong thing to optimise first.
- Email the request to kyal11105@gmail.com, from the address associated with the account or tenant, stating what should be removed.
- We confirm scope in writing before acting — specifically, which of the categories above apply, so nothing is removed that you actually wanted kept (a support ticket history, for instance).
- Deletion or erasure is carried out and confirmed back to you, including the timestamp and which rows were affected.