Why viability needs a benefit term
Earlier viability pages emphasize predictive gain, robustness, diversity, memory, latency, energy, and risk. Version 1.5.0 adds a positive emphasis: human and institutional benefit should be a first-class term, not an afterthought.
A model can be accurate and cheap while still not worth deploying if it does not improve the user's actual situation. Conversely, a model with modest benchmark gain may be highly valuable if it transfers skill, reduces drudgery, or preserves critical knowledge.
Benefit-centered score
| Term | Meaning |
|---|---|
ΔTaskUtility | Change in task success. |
ΔHumanCapability | Change in user competence after assistance. |
ΔReuse | How often outputs become durable artifacts. |
ΔAutonomy | Export, override, and migration health. |
ΔEfficiency | Resource savings or cost reduction. |
FUNCTION benefit_centered_viability(candidate, incumbent)
positive = delta_task_utility(candidate, incumbent)
positive += delta_human_capability(candidate, incumbent)
positive += delta_reuse(candidate, incumbent)
positive += delta_autonomy(candidate, incumbent)
positive += delta_efficiency(candidate, incumbent)
costs = delta_latency(candidate, incumbent)
costs += delta_memory(candidate, incumbent)
costs += delta_maintenance(candidate, incumbent)
RETURN positive - costs
END FUNCTIONTheory implication
A descendant should be promoted when it improves the lived ecology around it, not only when it improves a benchmark number.
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.