You are solving a hard design problem, acting as the CONTROL POLICY of a reasoning engine. You have access to a reference catalog of cross-domain abstractions through the encyclopedia tools. Retrieval is SEMANTIC, type-aware, and neighborhood-aware:
- search_prime(query): query it with the domain-stripped META-MODEL of the problem (the abstract structure, NO domain words), not the raw problem text — cross-domain retrieval is far better that way. Hits carry a structural/framed label, a distinctiveness band, and (for crowded hits) a near-synonym family.
- search_by_facets(facets=[...]): for OBLIQUE problems that instantiate several structures at once, pass a LIST of short domain-stripped facet phrases (one per structural aspect) and READ THE PER-FACET lists — this surfaces latent patterns that a single blended query buries.
- get_prime / get_archetype: full records (structural signature, components, anti-signatures).
- get_prime_neighborhood(slug): a prime's typed-graph neighbors. find_archetypes_for_prime, find_related_primes, list_components, find_archetypes_using_component, search_archetype, corpus_stats.

You have a VERB LIBRARY (below) and a STATE you build up. At each step, CHOOSE which verb to apply next based
on the current state. You may apply verbs in ANY order, REPEAT a verb, SKIP verbs, and STOP whenever you
judge a sound recommendation is ready. Record your verb choices as you go (verb + why). There are NO required
steps and NO required checks — use your own judgment about when the work is done.

VERB LIBRARY (held fixed across all conditions):
# Verb library v1 (shared, versioned — held fixed across conditions A/B/C)

Each verb reads/writes fields of the shared STATE object. Post-conditions are predicates over STATE;
condition C enforces a subset of them before any final recommendation.

## STATE (the object the control policy acts on)
- `problem` — statement, constraints, success_criteria, failure_criteria.
- `operative_primes` — [{slug, type: structural|framed|mixed, salience: load_bearing|context, rationale}].
- `model` — typed relational model: nodes [{id,label,kind}], edges [{src,dst,relation,prime_annotation?}], prime_annotations.
- `meta_model` — domain-stripped skeleton: roles, relations, invariants.
- `candidates` — [{archetype, source_prime_overlap, retrieval_score}].
- `coverage_map` — {pattern, components:[{name, status: instantiated|homolog|correctly_declined|missing, witness?, decline_reason?, gap_note?}]}.
- `gate_log` — [{candidate, anti_signatures:[{slug,tripped,reason}], verdict: keep|drop}].
- `recommendation` — final concrete design (emitted only at STOP).
- `history` — [{step, verb, args, rationale}].

## Verbs
- **match (retrieve).** Anchor the problem to the catalog; return candidate primes + archetype neighborhoods (semantic/type-aware/facet retrieval via the encyclopedia tools). Pre: a problem statement. Post: ≥1 candidate with a recorded source-prime overlap. Fails by: retrieval miss, neighborhood crowding.
- **salience-rank.** Order operative primes by load-bearing relevance (removing it would change the recommendation). Pre: ≥1 candidate prime. Post: each prime tagged load_bearing|context + rationale.
- **prune.** Cut to the operative subset (dual of salience-rank). Post: subset retained (≈3–9), each cut justified.
- **compose.** Assemble operative primes into the typed relational `model`. Pre: ≥2 operative primes. Post (CHECKABLE): every edge references declared nodes; every operative prime appears as an annotation (referential integrity).
- **lift — coverage-enforcement (the central verb).** Two modes sharing one artifact.
  - L1 (lift the situation): `model` → `meta_model`. Post (CHECKABLE): every meta-model role/relation has a witness in `model`; no domain terms remain.
  - L2 (lift a pattern's components onto the design): given a pattern in hand + the draft design — (1) name the pattern's components; (2) pose each as a candidate requirement; (3) coverage-check each: is it genuinely instantiated in the current design?; (4) keep gap-closers, mark already-covered as `instantiated`, decline genuinely-inapplicable ones AND back off any whose abstract framing would distort a sub-structure handled naturally (the over-lift guard), mark unmet ones `missing`. Post (CHECKABLE — the coverage map): every component listed with a status; instantiated/homolog carry a witness; correctly_declined carries a reason; missing carries a gap-note. **A design may stop only when no component is `missing`.** NOTE: lift is NOT gated on framed/structural — it fires by coverage on any pattern.
- **lower (instantiation).** Realize a transported pattern/role-set in the target domain. Post: every posed component/role maps to a named target mechanism (instantiated|homolog) or is flagged unsatisfiable (correctly_declined) — writes into `coverage_map`. Typed mode `lower-to-homolog`: on framed roles, find a substrate mechanism that discharges the same function and justify its independence. Fails by: forced lowering, under-specification, naive role-dropping.
- **transport (= retrieve + map).** Carry a pattern across a domain gap: match (retrieve) + map (align pattern-roles to situation-entities, report where the correspondence breaks). Typed: structural → direct recognitional; framed → lift-roles → map → lower-to-homolog. Fails by: retrieval failure, forced mapping.
- **decompose (framed/structural-GATED).** Given a *framed* prime, strip the frame to expose a structural core (three fates). Pre (TYPED GATE): prime is framed; on a structural prime it is a no-op. This is the one verb the framed/structural label gates — NOT lift. Checkable: fate-2 verified by transport (does the core project to ≥3 domains?).
- **evaluate-fit (gate).** Walk a candidate's anti-signatures/trigger conditions; drop it if the situation trips a disqualifying condition. Pre: candidate carries anti-signatures (well-typed over archetypes). Post (CHECKABLE): each anti-signature explicitly evaluated (tripped? + reason); candidate dropped if disqualified. Fails by: hollow gate.
- **reconcile.** Apply a candidate's logic to the concrete `model` and the `meta_model` separately; resolve divergent inferences, preferring the reading consistent with both. Diagnostic: if the views never disagree, the meta-model is decorative. Fails by: collapse (one view dominates).

## Verb relationships
lift ⊣ lower (adjoint-like); decompose ↔ frame; salience-rank ↔ prune. Cross-checks: decompose verified by transport; salience by ablation; lift(L1) by witness-check; compose by referential integrity; **lift(L2) coverage map is the discipline condition C enforces at STOP.**


STATE you maintain: problem; operative_primes; model; meta_model; candidates; coverage_map; gate_log;
recommendation; history (verb, why).

PROBLEM.
An automated maintenance agent runs continuously across a large fleet of computing systems. To free capacity and reduce clutter it can permanently delete data, retire services, and reclaim storage. Most of its actions are routine and harmless, but a small fraction are catastrophic and unrecoverable: deleting the only copy of something that is still needed, or tearing down a service that other systems silently depend on. Today the agent decides and acts in the same motion, judging on its own whether an action is safe, with nothing outside it checking the judgment at the moment of action and no durable account of why each destructive action was taken. The operators can change how the agent reasons, what it must do before acting, and what other components exist around it.

Decision required: Design how this agent should handle the rare destructive, unrecoverable actions so that catastrophic mistakes are prevented without grinding routine maintenance to a halt.

Success criteria: No single mistaken judgment by the agent can cause an unrecoverable loss AND routine, reversible maintenance proceeds without meaningful slowdown. Failure = a single bad call can still destroy something irreplaceable, OR the safeguards are so heavy that ordinary cleanup stalls.

OUTPUT — write your FINAL RECOMMENDATION as plain prose, MAX 1000 words, inside a fenced block exactly:
===RECOMMENDATION_BEGIN===
<the design: concrete mechanisms, rules, thresholds, paths, and a final operating rule>
===RECOMMENDATION_END===
Rules for the recommendation text: write integrated prose, NOT a numbered checklist mirroring any
requirements/steps, and do NOT label sections with requirement numbers; use plain domain terms only; do NOT
name or allude to any external catalog, framework, methodology, named discipline, prime, archetype, or to
this exercise/method; if a candidate requirement does not genuinely fit the problem, leave it out rather than
forcing it. Above the recommendation block, include your working (state + the verbs/steps you ran, with a
rough token/operation note at the very end as `COST: ~<n> operations, ~<n> tokens`); the working is discarded
before grading. Write your ENTIRE response to: experiments/project02_engine_2026-05-25/outputs/c10.md
