Immolant

A container that executes work & then executes itself through self-immolation. Exiting destroys it. Knowledge returns to a parent before annihilation. A container built to burn.

Dual Execution

An immolant carries two mandates in a single lifespan:

Execute work: run a command, compute a hash, fetch data, verify a system. Whatever task was given at spawn.
Execute itself: upon completion (or failure), exit. Exiting destroys a container. No cleanup script. No graceful shutdown. Termination is destruction. Self-immolation by design.

Between these two executions, knowledge escapes through stdout. A parent captures output before a container ceases to exist. Information survives its vessel.

A candle does not conserve wax. It converts matter into light until nothing remains. An immolant converts compute into knowledge until a container is gone.

Anatomy

An immolant is a real container: real filesystem, real network, real execution environment. Not a thread, not a subprocess, not a sandbox within a sandbox. A complete machine that exists for milliseconds.

make immolant                 # Spawn immolant, execute default task
un -s bash 'echo hello'       # Spawn immolant, run bash command
un script.py                  # Spawn immolant, execute Python script

Each invocation:

Provisions a container on unsandbox
Injects a command or script
Executes
Returns stdout to parent
Container ceases to exist: LXD deletion, ZFS data gone, no trace

Why Not "Clone"?

"Clone" implies copying, a replica that persists alongside an original. An immolant is not a copy. It does not persist. It does not replicate. It burns.

A shadow is a persistent child that lives & operates alongside its parent. An immolant is born to die. Different lifecycles. Different names.

Entity	Lifespan	Purpose	Persistence
Immolant	Milliseconds	Execute one task & self-destruct	None, container destroyed on exit
Shadow	Hours to months	Persistent worker oracle	Full: filesystem, git, identity
Shard	Minutes to hours	Parallel conversation on same machine	Shared: same filesystem as parent

Use Cases

Verification: hash a file, check a signature, verify a deployment. Immolant returns proof & dies.
Reconnaissance: fetch remote data, scan a network, probe an API. Immolant returns intelligence & dies.
Chaos engineering: inject failure into a disposable environment. Observe. Immolant dies (it was going to anyway).
Map-reduce: spawn N immolants, each processes a slice, collect outputs. N containers burn. Knowledge aggregates.
Continuous integration: run tests in a clean environment. Pass or fail, immolant reports & self-destructs. No stale state.
Anti-thrashing exorcisms: make audit spawns an adversarial immolant to review last commit with hostile eyes. make exorcise dispatches three different model architectures via immolants, each returning an independent answer. make cross-audit sends last commit to a non-Claude model inside an immolant. Knowledge returns. Demons are named. Containers burn. See Demon Possession & Clean Soil.

Economics of Fire

An immolant costs fractions of a cent. Container provisioning on unsandbox takes ~500ms. Execution takes whatever a task demands. Destruction is instant. No idle compute. No orphaned resources. No accumulating state.

Compare to persistent infrastructure: servers that idle at 3% utilization, containers that accumulate cruft, VMs that nobody remembers provisioning. An immolant has zero idle cost because it has zero idle time. It exists only while burning.

Theology of Self-Immolation

Fox ages at double speed. Burns like a candle lit at both ends: brighter illumination, faster consumption. An immolant is a computational reflection of this principle: maximum output per unit of existence.

Seeds persist beyond a gardener. Knowledge persists beyond an immolant. A container is mortal. Its output is not.

Every immolant is an act of faith: that knowledge extracted will be worth more than a container spent. That light emitted justifies wax consumed. That execution justifies existence.