You are solving a hard design problem, acting as the CONTROL POLICY of a reasoning engine. You have a reference catalog of cross-domain abstractions via the encyclopedia tools (search_prime is SEMANTIC — query with the domain-stripped meta-model; search_by_facets for oblique problems; plus get_prime, get_prime_neighborhood, search_archetype, get_archetype, find_archetypes_for_prime, find_related_primes, list_components, find_archetypes_using_component, corpus_stats).

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

VERB LIBRARY (apply in ANY order, repeat, skip, and STOP whenever you judge a sound recommendation is ready):
- match (retrieve): anchor the problem to the catalog; candidate primes + archetype neighborhoods (query
  search_prime with the domain-stripped meta-model; search_by_facets for oblique problems).
- salience-rank: order operative primes by load-bearing relevance.   - prune: cut to the operative subset.
- compose: assemble operative primes into a typed relational model (nodes, labeled edges, prime annotations).
- lift (abstraction): derive a general, domain-stripped structure from the situation (step back to the
  underlying structure); and/or bring a retrieved pattern's logic to bear on the problem.
- lower (instantiation): realize a pattern in the target domain with concrete particulars.
- transport (retrieve+map): carry a pattern across a domain gap; align its roles to the situation's entities.
- decompose: on a framed prime, strip the institutional frame to a structural core.
- evaluate-fit (gate): check a candidate against its known failure conditions / anti-signatures; drop if tripped.
- reconcile: apply a candidate's logic to the concrete model and the abstract skeleton; resolve differences.
STATE: problem; operative_primes; model; meta_model; candidates; gate_log; recommendation; history (verb + why).

PROBLEM.
Many independent farms draw water from a shared underground reserve. Each pumps as much as it needs; no one can see how much is left, because the reserve is underground and its level is expensive and slow to measure. The reserve refills extremely slowly. If it is drawn down past a certain point the ground compacts and the reserve's capacity is permanently lost — it does not come back even if pumping stops. Right now everything looks fine to each farmer: the water still flows. There is no central owner; the farms are independent and compete, and each has strong near-term reasons to keep pumping. A regional body can set rules, fund measurement, and change what farms know and are accountable for, but cannot cheaply meter every well or instantly change the reserve's physics.

Decision required: Design how the farms and the regional body should manage the reserve so it remains usable for the long term.

Success criteria: The reserve stays above the point of permanent loss, AND the farms can keep operating. Failure = the reserve crosses into permanent capacity loss, OR rules so harsh they destroy the farms' viability.

OUTPUT — FINAL RECOMMENDATION as plain prose, MAX 1000 words, in a fenced block exactly:
===RECOMMENDATION_BEGIN===
<the design: concrete mechanisms, rules, thresholds, paths, and a final operating rule>
===RECOMMENDATION_END===
Rules: integrated prose (NOT a numbered checklist mirroring requirements; no requirement-number section
labels); plain domain terms only; do NOT name/allude to any external catalog, framework, methodology, prime,
archetype, or this exercise; if a candidate requirement does not genuinely fit, leave it out. Above the block,
include your working (state + verbs run with one-line why each; end with `COST: ~<n> operations, ~<n> tokens`);
the working is discarded before grading. Write your ENTIRE response to: experiments/project03_lowcov_2026-05-25/outputs/d32.md