# B′ control-policy working — destructive maintenance agent

## STATE

**problem.** A continuous fleet-maintenance agent that decides and acts in one motion (delete data, retire services, reclaim storage). Most actions routine/reversible; a rare fraction are catastrophic and unrecoverable. No independent check at the moment of action; no durable account of why a destructive act was taken. Operators can change the agent's reasoning, its pre-action obligations, and surrounding components. Goal: no single mistaken judgment can cause unrecoverable loss, AND routine reversible work is not meaningfully slowed.

**meta_model.** An actor both judges safety and executes in the same motion; most acts are reversible, a few cross a point of no return; reversal cost jumps discontinuously past that point; no second pair of eyes before commitment; no reconstructable record of justification; a safety check must not tax the common harmless case.

**candidates (retrieved).** reversibility_horizon / reversibility_and_irreversibility; checks_and_balances_architecture; tiered_escalation; accountability_chain_design; fail_safe_default; compensating_transaction; irreversible_commitment_management (point-of-no-return marking, staged exposure, finality record, gate-before-not-after).

## VERBS RUN (in order)

1. **match** (search_by_facets, 5 facets) — oblique multi-structure problem; per-facet retrieval surfaced irreversibility, checks/due-process, accountability/falsifiability, fail-safe, and the "don't slow the common case" cluster, which a blended query would blur.
2. **match** (search_prime, meta-model) — confirmed reversibility_horizon, due_process/checks family, accountability, proportionality near top.
3. **salience-rank** — load-bearing: (a) reversibility classification is the master lever; (b) independent check before commitment on the destructive subset; (c) durable justification record; (d) recovery/offset when undo is partial; (e) proportional routing so routine work is untouched.
4. **transport + get_archetype** (irreversible_commitment_management, tiered_escalation, checks_and_balances_architecture, fail_safe_default, accountability_chain_design, compensating_transaction) — pulled concrete mechanisms and, critically, anti-signatures.
5. **decompose** — stripped "due process / separation of powers" frame to its structural core: the actor that executes must not be the only actor that authorizes a high-consequence irreversible act; the gate sits *before* the threshold or it is only a damage record.
6. **compose** — model: agent (maker) → action; classifier tags each action reversible|uncertain|irreversible-destructive; reversible path = direct execute + log; destructive path routed through interposition + independent checker + finality record; checker (separate component) holds veto; recovery layer offsets residue.
7. **evaluate-fit (gate)** — checked against the two killer failure modes. *Paralysis-by-irreversibility / heavy safeguards stall routine* (tiered_escalation + checks scaling with consequence): defended by gating ONLY the destructive subset and making the default destructive operation a reversible one. *Rubber-stamp / late gate* (irreversible_commitment_management symptoms): defended by gate-before-threshold + soft-delete quarantine so the "real" deletion is deferred, not blocking. *Rollback illusion*: dependency-probe before service teardown.
8. **lower (instantiate)** — realized below in fleet terms (soft-delete tombstones, quarantine window, dependency canary, dual-key on irreversible commit, decision ledger).
9. **reconcile** — abstract skeleton (interpose reversibility, separate authorize-from-execute on the tail, record finality, plan offset) matches the concrete model; residual tension (checker latency) bounded by auto-approve under evidence + cheap interposition so latency never touches routine work. STOP — recommendation sound.

COST: ~9 operations, ~46k tokens.

===RECOMMENDATION_BEGIN===

Stop letting the agent decide and destroy in one motion. Split every action it wants to take into two questions answered in order — *is this reversible?* and only if not, *who else has confirmed it's safe?* — and make the default form of every destructive operation a reversible one.

**Classify first, and make routine work the fast path.** Before acting, the agent tags each operation: reversible (the overwhelming majority — restarting a process, clearing a cache, reclaiming clearly-unreferenced scratch space), uncertain, or destructive-and-unrecoverable (deleting the last copy of data, tearing down a service others may depend on). Reversible actions execute immediately with only a lightweight log entry. This is the whole answer to "don't slow ordinary cleanup": the heavy machinery never touches them. When the agent is unsure, it treats the action as destructive rather than reversible — silence or ambiguity routes to the safe side, never to deletion.

**Convert irreversible into reversible by interposition.** No destructive action should ever be a single instantaneous loss. Replace permanent deletion with a two-stage move: the data or service is first *quarantined* — soft-deleted with a tombstone, or stopped-but-retained — and only a later, separate sweep performs the physical reclaim after a holding window (sized to how fast a missing dependency or a needed file would surface; e.g. days for storage, longer for anything irreplaceable). During the window the action is fully undoable. This alone guarantees that no single mistaken judgment causes immediate unrecoverable loss, and it costs almost nothing for the common case.

**Require a second, independent confirmation before the point of no return — but only there.** The agent that proposes a destructive action must not also be the sole authority that finalizes it. A separate checker component, with its own logic and its own view of the system, must approve before either (a) a destructive action proceeds at all, or (b) the holding window expires and physical reclaim runs. Crucially, the checker can *block*, not merely advise. For services, the checker runs a dependency probe first: stop the service in a reversible "lame-duck" state and watch for dependents failing or calling in; tear down for real only if nothing surfaces during the probe. Scale the check to the stakes — an action affecting the last copy of data, or a widely-reachable service, demands stronger evidence and possibly a human; a small, clearly-bounded reclaim can be auto-approved when the evidence is unambiguous. The check sits *before* the irreversible step; a check that runs after deletion is only a record of damage.

**Write down why — durably, before acting.** Every destructive action records, in an append-only ledger, what was acted on, who (which component) judged it safe, on what evidence, what the dependency probe showed, what the holding window is, and how to restore it. This is written at decision time, not reconstructed afterward. Routine reversible actions need only a terse log line; the full account is reserved for the destructive tail. The ledger makes after-the-fact review and learning possible and turns every quarantine entry into a recoverable handle.

**Plan the offset for what truly can't be undone.** When physical reclaim finally happens and is genuinely irreversible, treat residual harm as a first-class step: confirm restorability was verified, ensure the restore path was tested before the window closed, and keep the finality record so that if a downstream system breaks later, operators can trace cause and remediate quickly even though exact rollback is gone. Repeated quarantine reversals or near-misses for the same pattern should feed back into the classifier so the agent learns to tag that pattern as destructive earlier.

**Operating rule.** *Reversible actions run freely and immediately. No action that cannot be undone happens in a single motion or on the agent's judgment alone: it is first made reversible by quarantine, confirmed safe by an independent checker that can veto and (for services) by a dependency probe, recorded with its full justification before commitment, and only physically finalized after a holding window with restorability verified. When in doubt, treat it as destructive and keep the safe, reversible path.*

This prevents any single bad call from destroying something irreplaceable — because the destructive path always has a reversible buffer plus a second approver — while leaving routine, reversible maintenance running at full speed, since none of that machinery engages for it.

===RECOMMENDATION_END===
