Status: working design for the next ACE iteration.
This document refines COMMUNITY_GROWTH_ENGINE.md around a practical constraint: IDKMesh currently lives inside GitHub. Its community-evolution system therefore has to work with GitHub Issues, Pull Requests, reviews, labels, reactions, repository files, Actions, schedules, and API limits instead of assuming an unrestricted autonomous social platform.
The objective is not to automate publicity. It is to create a self-improving contribution ecology in which verified useful work makes the next useful contribution easier while the control policy itself learns from evidence.
Do not implement:
GitHub event -> public comment -> another event -> another public comment -> ...
That architecture is noisy, expensive in workflow/API calls, easy to game, and constrained by GitHub recursion/rate protections.
Use a generational architecture:
many repository events
|
v
one quiet state / evidence ledger
|
v
periodic generation evaluation
|
v
choose community mode + policy
|
v
at most a small bounded set of public actions
|
v
observe verified descendants
|
+---------------------------> next generation
GitHub is the environment; ACE is the adaptive policy living inside that environment.
Let:
P_t = number of verified parent contributions in generation t;D_t = verified descendant contributions caused by those parents within window W;L_t = review/maintainer load;K_t = sustainable review capacity.Define the community reproduction number:
R_c(t, W) = D_t / max(1, P_t)
A useful community can become self-sustaining when R_c > 1, but only if it does not exceed its verification capacity.
Define the ecological capacity gate:
C_t = 1 / (1 + exp((L_t - K_t) / tau))
C_t approaches 1 while the review system has capacity and approaches 0 when the project is overloaded.
The effective reproduction pressure is therefore:
R_eff(t) = R_c(t) * C_t
The goal is not maximum R_c. The target is a stable region where verified contribution reproduces while latency, review debt, and maintainer concentration remain bounded.
Ant colonies coordinate by leaving traces in the environment. ACE can use a digital equivalent without a central dispatcher.
Useful traces include:
good first issue and help wanted labels;A contributor should be able to inspect the repository and infer where useful energy is needed without private coordination.
ACE should not permanently hard-code one growth strategy.
Let the available strategies be:
S = {
reproduce,
challenge,
extend,
explain,
newcomer_second_step,
recruit_reviewer,
improve_onboarding,
cross_project_connection
}
Each strategy i has probability/weight w_i(t).
Measure fitness from verified descendants per scarce human attention, not raw interactions:
f_i(t) =
verified_descendant_value_i
----------------------------------
1 + reviewer_minutes_i + maintainer_minutes_i
- lambda_spam * noise_i
- lambda_latency * added_review_delay_i
A replicator-style update is:
w_i*(t+1) = w_i(t) * exp(eta * (f_i(t) - mean_fitness(t)))
Normalize and add mutation/exploration:
w_i(t+1) =
(1 - mu) * normalize(w_i*(t+1))
+ mu / |S|
mu > 0 prevents the project from converging permanently on one strategy or one contributor niche.
This is the main mechanism by which the community-building algorithm improves itself.
ACE should use an exploration temperature T_t.
When evidence is weak or the repository is stagnant, increase T_t: try more diverse Growth Seed types and preserve multiple hypotheses.
When evidence is strong and review capacity is constrained, decrease T_t: concentrate on proven strategies and consolidation.
A simple policy-selection distribution is:
P(strategy = i) = exp(f_i / T_t) / sum_j exp(f_j / T_t)
High T_t -> flatter distribution -> exploration.
Low T_t -> sharper distribution -> exploitation.
A possible adaptive temperature is:
T_t = clip(T_min, T_max,
T_0 * uncertainty_t * capacity_t)
This is inspired by statistical mechanics/simulated annealing. It is not a claim that GitHub is a physical thermodynamic system.
For candidate Growth Seed s, estimate:
I_s: expected useful impact;G_s: expected information gain;B_s: boundedness/clarity;N_s: newcomer accessibility;D_s: diversity/niche value;H_s: expected reviewer/maintainer attention;X_s: execution friction;S_s: spam/noise risk.Define a potential gradient:
Potential(s) =
(I_s * G_s * B_s * N_s * D_s)
--------------------------------
(1 + H_s + X_s + S_s)
ACE should surface a small number of high-potential seeds, not create a large number of generic tasks.
This turns repository growth into a search for high information gain per unit of human attention.
An adaptive community system needs checks on its own growth.
ACE uses a two-gate model for any higher-amplification action.
The parent activity must be independently useful or verified.
Examples:
The community must be able to absorb the descendant work.
Check:
A growth action occurs only when both gates pass.
This is analogous to bicameral checks: value is insufficient without capacity, and popularity is insufficient without evidence.
Future IDKMesh cells/subprojects can use polycentric governance: local communities choose local strategies while shared constitutional rules govern security, provenance, interoperability, and high-impact changes.
Biological Red Queen dynamics and adversarial strategy suggest a useful rule: every successful capability should periodically face a counter-test.
For a verified parent contribution, ACE may choose among:
build -> reproduce
build -> challenge
build -> security review
claim -> falsification experiment
optimization -> regression benchmark
new workflow -> abuse/threat model
This creates a constructive attacker/defender loop without turning the project into conflict between people.
The target is resilience:
progress = capability_gain - unmeasured_failure_surface
This is also the useful part of military/OODA-loop inspiration:
Observe -> Orient -> Decide -> Act -> Observe
ACE should shorten this loop for evidence while keeping high-impact acts bounded and reviewable.
Ordinary GitHub Actions are classical computation. ACE should not claim quantum behavior.
A useful quantum-inspired principle is to avoid collapsing uncertain choices too early.
Maintain a probability distribution over policy hypotheses:
p(t) = [p_1, p_2, ..., p_n]
Measure policy uncertainty with Shannon entropy:
H(p) = -sum_i p_i log p_i
As verified evidence arrives, update probabilities (for example by Bayesian or multiplicative-weights updates). High entropy means several strategies remain plausible; low entropy means evidence supports concentration.
This gives IDKMesh the useful conceptual property often loosely associated with “superposition” while staying mathematically honest: multiple alternatives remain live until evidence justifies convergence.
ACE should treat GitHub limits as part of the optimization problem.
Let:
A_t = GitHub API calls consumed in a window;W_t = content-generating writes (issues, comments, edits, labels where applicable);G_t = Actions workflow runs;N_t = notifications likely generated;B_API, B_WRITE, B_RUN, B_NOTIFY = internal conservative budgets below platform limits.Define the automation budget:
B_t = min(
B_API - A_t,
B_WRITE - W_t,
B_RUN - G_t,
B_NOTIFY - N_t
)
No growth policy may spend more than B_t.
The internal budgets should be deliberately much smaller than GitHub’s maximums. Platform limits are emergency ceilings, not desired operating points.
As of 2026-08-28, GitHub documentation states:
GITHUB_TOKEN REST requests are limited to 1,000 requests/hour/repository for ordinary GitHub.com repositories (higher for some Enterprise Cloud cases).GITHUB_TOKEN normally do not create another workflow run, with documented exceptions including workflow_dispatch, repository_dispatch, and special handling for some automation-created pull-request events. This protects against accidental recursive workflows but also means ACE cannot rely on an unrestricted recursive event chain.pull_request_target runs in a privileged base-repository context. GitHub advises avoiding it where unnecessary and never checking out or executing untrusted PR code in a privileged workflow.Sources:
The ACE ratio should be deliberately asymmetric:
many observations : few public writes
A good initial target is conceptual rather than fixed:
100 observed signals -> 1 or fewer autonomous public growth actions
The exact ratio should later be learned from evidence.
Preferred state storage order for GitHub-only v0/v1:
Instead of recursive per-event growth, operate in generations, for example daily or after enough high-value events accumulate.
At generation t:
Collect/update low-cost state:
Compute:
R_c(t)
C_t
policy fitness f_i(t)
uncertainty H_t
review debt L_t
if severe review/security/governance debt:
CONSOLIDATE
elif R_c < 1 and capacity is healthy:
EXPLORE
elif R_c >= 1 and capacity is healthy:
GROW
else:
DORMANT
Examples:
“Do nothing” is a valid policy action.
After descendant outcomes become measurable, update strategy weights and temperature.
Not every GitHub event deserves an Actions run forever.
Good direct triggers:
workflow_dispatch.Potentially aggregate or sample:
Prefer low-frequency aggregate sampling once the repository becomes busy:
At small scale, direct events are acceptable. At larger scale, one Actions run per star/fork is unnecessarily expensive relative to its information value.
ACE must not optimize:
These can all be gamed and can all increase while project health declines.
The leading candidate objective is:
verified useful descendant value
---------------------------------------------
reviewer attention + maintainer attention
+ compute cost + community friction
with hard constraints on security, conduct, contributor consent, and maintainer concentration.
The intended loop is:
verified contribution
-> leaves a legible trace / opportunity
-> another contributor can act
-> independent verification
-> descendant is measured
-> policy fitness is updated
-> successful strategy becomes slightly more likely
-> mutation preserves alternatives
-> capacity governor limits reproduction
-> next generation
This is a community metabolism rather than an advertising bot.
Do not add broad autonomous write capability yet. The repository already has ACE v0 and an active bootstrap cohort.
The next evidence-first steps are:
R_c from real repository descendants rather than proxy credit.The first success criterion is not community size. It is evidence that a verified contribution can reliably create another verified contribution without increasing maintainer effort at the same rate.