You are solving a hard design problem. 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.

Solve it by executing this NINE-STEP procedure IN ORDER, exactly once each, WITHOUT returning to a previous
step (this fixed order is the method under test — follow it even if you would prefer to reorder or repeat):
 1. Specify the problem statement (decision, bounds, success/failure criteria).
 2. Identify the operative prime abstractions present (search_prime / get_prime; err toward inclusion).
 3. Salience-rank the primes by load-bearing relevance.
 4. Prune to an operative subset (~3-9) with rationale.
 5. Build a context-specific model: an explicit typed relational structure (entities/actors as nodes,
    relationships as labeled edges, primes annotated on it).
 6. Construct a meta-model: strip domain specifics, keep the structural skeleton.
 7. Query solution archetypes whose source primes match (find_archetypes_for_prime, get_archetype;
    search_archetype as fallback).
 8. Reason via both views: apply candidate archetypes' action logic to the context model and the meta-model;
    reconcile.
 9. Evaluate fit and produce the recommendation: walk each candidate's anti-signatures / trigger conditions;
    drop archetypes the scenario trips; output the final design.

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