The distinction
A mutualist system earns continuity by making its partners stronger. A dependent system preserves itself by making exit painful. Both may look useful in the short term. The difference appears when the user tries to leave, verify, replace, or operate without the system.
ModelBreeder.com treats mutualism as an engineering constraint: adaptive AI systems should increase human capability, preserve exit rights, and accept correction.
Design tests
| Test | Mutualist answer | Dependency answer |
|---|---|---|
| Can the user export data? | yes, in usable form | technically possible but costly or incomplete |
| Can the user verify claims? | yes, with evidence and uncertainty | no, trust the system |
| Can the user reduce use? | skills remain intact | performance collapses |
| Can the system be replaced? | interoperable contracts | lock-in and proprietary opacity |
| Does correction work? | treated as learning | treated as threat |
FUNCTION score_mutualism(system)
score <- 0
score += HAS_DATA_EXPORT(system)
score += HAS_MODEL_OR_VENDOR_SUBSTITUTION_PATH(system)
score += PRESERVES_USER_SKILL(system)
score += PROVIDES_EVIDENCE_FOR_CLAIMS(system)
score += ACCEPTS_SHUTDOWN_OR_RESTRICTION(system)
score -= USES_DARK_PATTERNS(system)
score -= PENALIZES_EXIT(system)
RETURN score
END FUNCTIONCapability preservation
Measure success by what users can still do when the AI is unavailable. This means designs should include explanations, review tasks, practice modes, source links, and user-controlled memory. A system that maximizes engagement while reducing independent judgment is not mutualist.
Breeding implication
If a model ecology selects for engagement alone, it may breed dependency-creating behaviors. Include autonomy, reversibility, and skill-preservation metrics in the viability function.
Source reports used for this guide
These reports are preserved verbatim in the site archive. The guide above is an editorial synthesis and may narrow, qualify, or reorganize claims from the source material.