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.
A community runs a peer-to-peer exchange where members trade help by the hour: teach a class, fix a bike, tutor a child, each logged as credits that can be spent on others' help. It worked at first but keeps destabilizing. Some members accumulate huge unspent credit balances and stop offering help; others run deep deficits and drift away; a few discover that certain easy-to-offer services are wildly over-rewarded relative to effort and flood the system with them, crowding out the help people actually need. Participation is now spiraling down. The organizers can change how credits are earned and spent, what is tracked, what limits exist, and what information members see.

Decision required: Design the rules and mechanisms that keep the exchange stable, fair, and genuinely useful over time.

Success criteria: Active give-and-take participation holds steady or grows over a year AND no class of easy-to-offer service systematically drains value from the rest. Failure = runaway hoarding or deficit drift kills participation, OR a few low-value services dominate the exchange.

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/c26.md
