Status: current plain-language explainer. Canonical authority rules remain in
EVOLUTION.md,
ITERATION_MODEL.md,
CONSTITUTION.md, and the linked executable workflows.
IDKMesh “self-growth” is a guarded feedback loop for increasing verified project capacity. It does not mean that one AI agent can rewrite the repository and approve its own changes.
The shortest description is:
observe repository/community state
-> preserve evidence and history
-> diagnose bottlenecks
-> choose a bounded mode/action
-> expose or execute bounded work
-> produce candidate artifacts/PRs
-> verify independently
-> human/governance integration decision
-> measure the outcome
-> update evidence/state
-> repeat
The loop is intentionally asymmetric: many observations, few public writes, and no self-approval.
Self-growth is also multi-axis. Repository correctness and verification are only two dimensions; the controller must also observe discoverability, SEO/AEO, community acquisition, contributor retention, reviewer/leader capacity, and real adoption. See docs/community/VISIBILITY_AND_COMMUNITY_GROWTH_LOOP.md for the external-growth control surface and the read-only visibility observatory.
GitHub and repository state are treated as the environment.
The evolution workflow observes bounded metadata such as:
The canonical workflow is
.github/workflows/evolution-loop.yml.
It runs on trusted repository events, manual dispatch, and a daily scheduled audit.
IDKMesh keeps inspectable state rather than relying on hidden agent memory.
The repository-evolution loop preserves:
ACE, the community-growth loop, keeps a public state ledger in GitHub issue #23.
The important principle is:
learning must leave an inspectable evidence trail.
This is not hidden model fine-tuning.
The live repository observatory computes engineering signals including:
It also computes pressures over bounded strategies:
protect
verify
consolidate
integrate
onboard
explore
maintain
A replicator-mutator response preserves some exploration instead of allowing one strategy to dominate forever.
These quantities are decision-support signals, not authority.
The current controller can move into modes such as:
GUARD
CONSOLIDATE
VERIFY
ONBOARD
INTEGRATE
EXPLORE
Historical evidence cannot compensate for a current hard blocker.
Examples:
GUARD;CONSOLIDATE;VERIFY;ONBOARD.The conjunctive controller combines historical evidence with current live state, but its non-compensation rule is deliberately conservative:
current hard blocker = true
=> stronger experiment escalation = false
See
docs/architecture/CONJUNCTIVE_EVOLUTION_CONTROL.md.
There are two distinct growth loops.
The repository-evolution workflow is currently recommendation-only. It can observe, score, produce evidence, and recommend bounded needs. It does not grant itself:
ACE is the current limited public-write growth mechanism.
It converts repository activity into reproductive credit using:
DeltaCredit = ActivityEnergy * Novelty * Capacity
where repeated event types receive diminishing novelty and review saturation reduces the capacity multiplier.
ACE may create a new Growth Seed only when both are true:
main is protected; andACE_AUTONOMOUS_ACTUATION_ENABLED is explicitly true.Even then, the actuator is narrow. A merged PR must be explicitly labeled
growth:spawn, and ACE creates a bounded follow-up issue inviting a contributor to
reproduce, challenge, extend, or explain the result. Recovery is capped so an
unexpected backlog cannot cause mass issue creation.
The executable implementation is
.github/workflows/ace-community-growth.yml.
The growth controller should not depend on one model.
A bounded task can be executed through humans or replaceable worker adapters such as coding agents, local workers, A2A/MCP-connected workers, or future integrations.
The intended path is:
GitHub issue / bounded goal
-> WorkUnit
-> selected worker/agent
-> candidate branch/artifacts
-> ResultManifest
Worker completion is never acceptance.
Candidate work must pass verifier-owned checks and provenance requirements.
The key separation is:
worker says "done"
!=
verifier says "evidence passes"
!=
repository/governance says "integrate"
Verification capacity therefore acts as a biological-style resource constraint: generation should slow when independent verification becomes scarce.
Canonical project state changes only through the repository/governance integration boundary.
The self-growth machinery may recommend or generate bounded descendants, but it cannot approve its own high-impact changes.
This is the main safety property that makes “self-growing” different from “self-modifying without control.”
After work is accepted, rejected, reverted, reproduced, or challenged, its outcome can feed the next observation cycle.
Useful future outcome signals include:
The project should increasingly replace authored heuristics with calibrated models only after enough observed evidence exists.
IDKMesh explicitly avoids equating activity with improvement.
stars != correctness
forks != correctness
commits != improvement
comments != evidence
agent output != acceptance
score != authority
The target is verified useful improvement per unit of scarce human and verification attention, not maximum repository activity.
Today, IDKMesh already has:
It does not yet have one fully autonomous end-to-end controller that discovers an arbitrary goal, dispatches it to an agent, independently verifies it, changes its own policy, and integrates the result without external authority.
That limitation is intentional.
The desired long-term property is not maximum autonomy. It is:
the repository becomes progressively better at discovering, routing, verifying, and learning from useful work while keeping irreversible authority outside the mechanism being evaluated.
For live ACE state, read the repository’s [ACE] Community Growth Ledger issue rather than copying a status snapshot into this document.