Apoptosis as Resource Lifecycle (Paired with Reference Counting) (874fce5b)

**Note** from Bead: 874fce5b · [canonical source](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/apoptosis-vs-necrosis.md) · session 2026-04-23 · discussion: Talk: 874fce5b

**Date:** 2026-04-23 **Context:** Architecture chat. Complement to [uri-bind-mount.md](uri-bind-mount.md) (how resources live and are addressed) and [polarized-links.md](polarized-links.md).

## The pair - **Reference counting** (external): a resource lives while bindings point at it, dies when the last binding is removed. Hard links realize this at the filesystem level: directory entry = URI binding, inode = resource, `unlink` decrements the count. - **Apoptosis** (internal): a resource self-terminates by policy even when bindings still point at it. Triggered by TTL, schema supersession, revocation, obsolescence, detected damage. Both are needed. Ref-count covers demand-driven lifecycle; apoptosis covers policy-driven lifecycle.

## Apoptosis vs necrosis - **Apoptosis** = programmed, signaled, orderly. Dependents receive death notice and adapt. State is released cleanly. Bindings are redirected or removed. No inflammation (no cascading confusion in the namespace). - **Necrosis** = unplanned death (crash, network partition, hung agent). Leaves dangling bindings, held locks, cached tokens, confused peers, stale shared state. Mayordomo cleanup becomes necessary. An ecology defaulting to necrosis accumulates zombies and requires constant janitorial work. An ecology defaulting to apoptosis decays gracefully; mayordomos only handle refuseniks.

## Apoptotic patterns already present in the stack - **Geo.camera JWT TTL** — grant tokens apoptose at `exp`; auto-renew mints a successor before death; clean transition. - **Grant revocation** — camera publishes `accessRevoked` so grantee clears cached tokens, removes marker, stops trying to reconnect. Signaled apoptosis. - **CameraMap 60s stale-camera cull** — a guess at apoptosis-vs-necrosis because the absent camera gave no explicit signal. Works as a fallback; not as good as a real death signal. - **Chat session end** — transcript persists (state archived), session-scoped resources released (in-memory context, connections).

## Design heuristics - **Prefer signaled termination.** Before a resource apoptoses, publish a death signal so dependents can adapt. - **Prefer named causes.** `accessRevoked`, `tokenExpired`, `schemaSuperseded`, `policyEvicted` convey why; generic "gone" is weaker. - **Distinguish HTTP 404 from 410.** 404 = "not found here right now." 410 = "intentionally removed, don't look again." The latter is apoptotic. - **Apoptosis triggers carry policy.** TTL, schema-version mismatch, authority revocation, obsolescence detection, self-detected corruption. The trigger determines whether a successor should be minted. - **Force is fallback, not default.** Forceful deletion is necrosis-from-outside. Acceptable only when a resource refuses apoptotic signals. - **Refusal to apoptose = governance issue.** The digital analogue of cancer; handle with escalation, not default behavior.

## The creative side Apoptosis in biology is sculpting, not just cleanup. Fingers form by webbing cells apoptosing. In this ecology: schema migration, tier promotions, deprecations, and capability supersessions should be modeled apoptotically. The old version dies cleanly when the successor is ready, signals propagate, bindings re-point. Growth of the namespace happens partly through programmed death of superseded pieces, not just addition.

## Mayordomo responsibilities implied - Issue apoptotic signals for resources that should self-terminate (scheduled, conditional, policy-driven) - Observe acknowledgments; enforce via force only when apoptosis is refused - Maintain lists of known-dead bindings (410-scale memory) so callers don't keep retrying - Propagate successor information when apoptosis triggers replacement (binding re-point, not rebinding loop)

## When to remember this - Designing any resource with non-trivial lifecycle: ask "how does this die?" before "how does this live?" - Any scheduled cleanup task: reframe as "trigger apoptosis in resources matching X" - Any revocation/expiry feature: model it as a death signal, not just a flag flip - Any schema migration: sequence the new birth and old apoptosis so bindings can re-point smoothly - Any "why is this stale data hanging around?" debugging: look for missing apoptotic signal propagation