Decide the delete path before you store the record.
A workflow stores a row because it needs a fact on Tuesday. Two years later it's in a warehouse, an export and a ticket attachment, and nobody knows who may remove it or what breaks if they do. Decide how a record ends before you first save it.
Before a workflow stores a record, write a TWIMCO Retention and Delete Path Spec: what is kept, the retention your policy actually names, who may delete, what must remain after deletion, and which downstream steps break if the record vanishes. The spec does not invent a legal term. It makes the path you already owe explicit.
Storage without an ending is unfinished
A workflow needs a fact, so it stores a row. The row is useful on Tuesday. On a Tuesday two years later it is still there, copied into a warehouse, an export, a ticket attachment, and a model’s context, and nobody can say who is allowed to remove it or what else falls over if they do. Retention was treated as a legal footnote to be answered at the end. The end arrived as a request, an incident, or a cleanup, and the path was missing.
The TWIMCO Retention & Delete Path Spec is the page you fill before the first write of a record type, not after the copies exist. It says what is kept, how long your own policy says to keep it, who may delete, what a delete must leave behind so the operation can still explain itself, and which steps break when the record is gone. It is not a vendor-exit scorecard, which asks whether you can leave a tool. It is not a completeness checklist, which asks whether the record contains the fields a handoff needs. This spec asks how the record ends.
It is not legal advice, and it does not supply a retention period. If counsel or your existing policy names a period, you write that period down and point at the policy. If nobody has named one, the line says “not decided,” and you do not store the record type in a new place until it is decided. Inventing “seven years” because it sounds familiar is how a draft becomes fake compliance.
TWIMCO’s work connected to PatientIQ sits with data-heavy healthcare products, where operational records outlive the screen that captured them and are awkward to casually erase. The same shape shows up in any operation that stores facts about people or about money. Making the path real is business process automation when the delete has to cross systems, not only a button in one admin screen. This spec is not a published interactive tool. The fields are the asset.
Write one spec per record type. “User data” is too wide. A support note, a payment reference, an identity document, and a derived score can have different lives. Glue them together and you will keep the strictest thing forever and delete the thing you needed for the books.
What you name before the first write
The TWIMCO Retention & Delete Path Spec starts with the record, not with the database table. Tables multiply. The record is what a person means when they ask you to delete it.
Record type. A name an operator recognizes, plus the systems that hold a copy. The list of copies is the spec. If you do not know the copies, you do not know the path. Include exports, tickets, logs, search indexes, and analytics tables if a person could still be identified there. You may discover the list is incomplete. Write “copies not fully known” and treat that as a block on calling the path done.
Why it is stored. The operation that needs it. A purpose you cannot say is a purpose you will not be able to defend later. This line is a sentence, not a policy citation stacked to look serious.
Retention. The duration or the event your policy uses: a fixed term, the life of an account, the close of a dispute, whichever your policy says. Cite the policy by name and date. Do not translate it into a number the policy does not contain. If two policies seem to conflict, the spec records the conflict and the role who must resolve it. It does not pick a winner quietly.
Clock start. When the term begins. Creation, last activity, end of contract, and “when we feel done” are different clocks. Pick the one the policy means. If the product cannot express that event, the gap is engineering, and the spec says so.
Who may delete. A role, not a shared inbox. Say whether the request comes from the subject, from an operator, or from the clock itself. Say who verifies the request. A delete that anyone with admin rights can perform, with no reason captured, is not a path. It is a hazard.
What the requester receives. A confirmation that names the record type and the outcome: deleted, retained for a named reason, or partially deleted. Silence is not an outcome. You do not need a legal template in this note. You need the commitment that some specific role sends a specific kind of answer.
Grace and holds. Whether a legal hold, a dispute, or an unpaid balance can pause deletion, who may place the hold, and how the hold is visible. A hidden hold means the confirmation will lie.
Fill these before you discuss implementation tricks. A cascade job with an empty who-may-delete line is a faster way to be wrong.
Sequence of work
From the first write to what remains
- Before the write
Record type, copies you know, purpose, and a retention line taken from policy or marked not decided.
- While kept
The clock is running from the event the policy named. Holds are visible.
- Delete
A named role verifies the request. The primary store changes. Proof does not keep the payload.
- Copies follow
Each copy has a status: gone, pending a cycle, or not in your control.
- Residue
Only what the operation must still explain, without a path back to the person.
A record you cannot delete is a record you have not finished designing.
Deletion still has to leave an explanation
Some facts must survive the record. A ledger may need to show that a payment occurred without keeping the personal note attached to it. An audit trail may need to show that a role deleted a record on a date without keeping the payload. The spec separates the record from the residue.
Residue. What remains, where, and why. A tombstone with an id and a timestamp. An aggregate that cannot be walked back to a person. A financial entry with identifiers removed. If you claim the residue is not the record, say what a skeptical reader would use to re-identify someone, and why that path is closed. If you cannot close it, the residue is still the record, and calling it anonymous does not make the delete real.
Copies that do not follow. Backups, a vendor you cannot instruct, a laptop export, a message attachment. The spec lists them and says the honest status: deleted on the next cycle, retained until a named date, or not in your control. “Not in your control” is allowed. Hiding it is not. The confirmation to the requester should not say “all copies” if you mean “the primary store.”
Downstream breaks. The steps that fail or change when the record is gone. A later report, a model feature, a support macro, a foreign key, a warehouse job that expects the row. For each, say the intended behavior: skip, show residue, block the job, or forbid the delete until that dependency is redesigned. “The job will error and someone will notice” is a break you have not designed.
Rebuild temptation. Whether an upstream feed will recreate the deleted record on the next sync. If it will, the path includes the suppression: a do-not-restore mark in the system that syncs. A delete that the next import undoes is not a delete. It is a delay. This is the line teams skip because the import was owned by someone who was not in the meeting.
Proof. What you keep to show the path ran: who requested, who approved, when the primary store changed, when copies were due to follow. Proof should not smuggle the deleted payload back into the log. If your logs currently do that, the spec names the log change. Shipping the delete button first and the log later means the first deletes are the ones you documented worst.
The residue design is the part another team cannot honestly copy from a generic prompt, because it depends on what your operation still has to explain after the person is gone. Write it in your nouns.
Refuse the path that only works in the primary screen
A few shapes recur. They are composites, not client outcomes, and not a statement about any healthcare or commerce deployment.
The admin button deletes the row the screen was looking at. The warehouse still has yesterday’s copy. The spec’s copy list was never filled, so the button looked finished. Call the path incomplete until the copies have a status.
The term is “as long as we need it.” The clock never starts. The record type accumulates because need is evaluated by the next feature, which always needs a little history. “Not decided” should have blocked the new store. If it did not, stop adding copies and decide the clock.
A model or a search index was trained or built with the record and has no story on the spec. You may not be able to untrain a model in any clean way. The honest line is that prompts, caches, and indexes you control are cleared, and a model you cannot unwind is named as a limit, not waved through. Do not write “AI forgets” on the spec.
The confirmation says deleted while a hold retained the record. The requester is misled. Holds belong on the spec because they change the sentence you are allowed to send.
An operator deletes to be helpful, without the role the spec named, and without residue. The books or the audit can no longer explain a step that happened. Who-may-delete is a control, not a courtesy, and the downstream-breaks list is what you show that operator before they get the permission.
If you recognize one of these, the fix is to complete the spec and then change the systems to match it. Completing the spec and leaving the button as it is will only make the gap easier to quote. That is still useful, and it is not the same as having the path.
Revisit the spec when you add a copy. A new export, a new vendor, a new agent context window that receives the record: each one amends the copy list before it goes live. A path that does not survive the next integration was a description of last quarter.
Decision guide
Kept forever versus a named ending
| Consideration | The row just stays | The spec has an ending |
|---|---|---|
| How long | As long as someone might want it. | The term or event your policy names, with the clock start. |
| Who removes it | Anyone with an admin login. | A role, a verified request, and a confirmation that matches the outcome. |
| Other systems | The screen deleted it, so it is gone. | Every copy listed, including the sync that would restore it. |
| Afterward | Jobs break, or the payload sits in a log. | Residue and downstream behavior are chosen, and proof is payload-free. |
Put this into practice
- Choose one record type you are about to store, or one you already stored without an ending. Not every table. One type.
- Fill the TWIMCO Retention & Delete Path Spec: copies, purpose, retention as your policy states it, clock start, who may delete, confirmation, holds.
- Write residue, copies you do not control, downstream breaks, and the suppression that stops a sync from restoring the row.
- If retention is “not decided” or copies are unknown, do not add a new store for that type. Decide or map first.
- Where the delete has to cross tools, scope the work as business process automation. Keep the stakes concrete, as in work connected to PatientIQ, where records are kept because a workflow needs them and cannot be shrugged off later.
The right time to design the ending is while the record is still a proposal. After that, every copy is an argument you have to win one by one.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.