Docs·2ac88ac·Updated Apr 9, 2026·48 ADRs
Back
ADR-047implemented
ADR-047: Community Evolution Engine
ADR-047: Community Evolution Engine
Status: Implemented Date: 2026-03-20 Sprint: 31
Context
Sprint 30 introduced individual trust evolution — each user's trust parameters calibrate based on lived experience. This creates a source of signal that had no destination: individual calibrations happened but didn't feed back into the community-level trust model.
Decision
Build a Community Evolution Engine that aggregates member trust deltas to drift community config.
Key design decisions:
- Delta-based, not absolute: The signal is the change in each member's trust since they began evolving — not their current values. A community of uniformly trusting members who never evolved has no signal to contribute.
- Two opt-out levels, no middle state: Users opt in/out of personal evolution. Communities opt in/out of community evolution. If a user's trust evolves, their delta contributes to the community — there is no third flag.
- Interaction rate as a health validator: Before applying evolution, we check whether interaction rate is declining. Declining interaction dampens the nudge, preventing the system from drifting toward configurations that correlate with disengagement.
- Direction consensus for hop count:
trust_path_max_hopsonly changes after 3 consecutive evolution cycles agree on direction, preventing oscillation on a high-impact parameter. - Pluggable by design:
communityEvolutionService.tschecks the evolution flag at every entry point and is removable without touching core karma/trust logic. - Default opt-out: Both user and community evolution default to TRUE. Consent is given at account/community creation.
Three Parameters That Evolve
cross_community_prior(0.05–0.95): Direct delta aggregation × 0.30 dampingkarma_split_helper(0–100): Follows prior direction, ±1 per cycletrust_path_max_hops(1–5): Follows prior direction, ±1 only after 3 consecutive same-direction cycles
Consequences
- Community configs are no longer static — they require a history audit log (
community_evolution_log) - Admins need a UI surface to observe evolution history and toggle it off
- Sprint 32 (fractal feed) can now blend individual + community evolved params in the matching model