Retire, Never Delete

"Retire is a headstone, not a shredder. The record stays; only the authority ends."

Remove doesn't mean erase

When you remove a Mac from the fleet, you retire it. Retirement blocks new probes, operations, terminals, and campaign targeting; it requires any active work to be resolved or closed first; it drops the machine from the active grid but keeps it under Retired; and it preserves policy, observations, operation history, and audit. What ends is authority — not the record.

Why a tombstone

Retirement leaves a tombstone: a marker that says this machine was deliberately removed. Without it, the same Mac rediscovered next week looks like a brand-new candidate, and you lose the one fact that mattered — that a human already decided it was done. The tombstone is the memory of the decision, and it's what stops discovery from silently re-enrolling a machine you meant to let go.

Retire is reversible; purge is the heavy door

Restore reactivates the same logical host after its identity and access are reverified — the history comes back with it. Purge is a separate, high-risk action, available only for a retired host with no active references, and even purge leaves a minimal audit tombstone behind. You can always get a retired machine back; you deliberately can't fully un-see a purge — which is exactly why purge is hard to reach.

The tower can't retire itself

And the rule from the first track returns: the control-plane host can't retire itself while it holds the pen. Handing off the fleet is a verified migration, not a self-erase — because a writer that deletes itself leaves no one to record that it's gone.

Archive, tombstone, restore — but never hard-delete a record you might need to prove something with. Deletion is the one operation you can't take back, so it should be the heaviest door in the building.

Code

Retire keeps; purge is separate and rare·python

retire_host(host_id="old-laptop")
#   blocks new probes / ops / terminal / campaign targeting
#   requires active work resolved first
#   KEEPS policy + observations + operation history + audit
#   leaves a tombstone so discovery can't silently re-enroll it
#   -> gone from 'active', present under 'retired'

restore_host(host_id="old-laptop")     # same logical host, re-verified; history returns

purge_host_data(host_id="old-laptop")  # SEPARATE, high-risk, retired-only, no active refs
#   removes retained detail -- but a minimal audit/tombstone still remains.
#
# There is no path that turns a live machine straight into nothing.

Exercise

Think of something you 'deleted' recently that you later wished you could see — a file, a message, a config. Redesign that deletion as a retire-with-tombstone: what would you block, what would you keep, and what would the tombstone need to record so a future you doesn't recreate the exact thing you meant to be rid of?

Hint

The tombstone's job is to answer 'was this an accident or a decision?' If a rediscovered thing can't tell those apart, it comes back — fine for a laptop, terrible for the spam contact you keep re-adding because nothing remembers you banished it.

Remove doesn't mean erase

Why a tombstone

Retire is reversible; purge is the heavy door

The tower can't retire itself

Code

External links

Exercise

Progress

Comments 0