The ASI Evolution Engine is Treeova's self-improving configuration system. A four-agent pipeline — Researcher, Engineer, Analyzer, Judge — generates and evaluates candidate configuration changes for named platform domains under hermetic evaluation contracts and a status-based mutex that prevents intra-domain races. Judge rubrics, mutation operators, eval thresholds, per-role model routing, and exact prompts are intentionally withheld.
ASI Evolution Engine
The ASI Evolution Engine is Treeova's self-improving configuration system. A four-agent pipeline — Researcher, Engineer, Analyzer, Judge — generates and evaluates candidate configuration changes for named platform domains under hermetic evaluation contracts and a status-based mutex that prevents intra-domain races. Judge rubrics, mutation operators, eval thresholds, per-role model routing, and exact prompts are intentionally withheld.
ASI Evolution proposes and evaluates configuration changes, not application code.
The pipeline has four roles: Researcher, Engineer, Analyzer, Judge.
Each domain has a hermetic evaluation contract that isolates the candidate from outside state.
A status-based mutex prevents two runs from racing inside the same domain.
Judge rubrics, mutation operators, thresholds, model routing, and prompts are withheld.
ASIMethodologyArchitecture
Treeova Whitepaper · v1.0
WP-04 — ASI Evolution Engine: Self-Improving Configuration
The ASI Evolution Engine is Treeova's self-improving configuration system. A four-agent pipeline — Researcher, Engineer, Analyzer, Judge — generates and evaluates candidate configuration changes for named platform domains under hermetic evaluation contracts and a status-based mutex that prevents intra-domain races. Judge rubrics, mutation operators, eval thresholds, per-role model routing, and exact prompts are intentionally withheld.
Authored by Treeova Research· Research CollectiveUpdated 2026-04-18
The ASI Evolution Engine is the system Treeova uses to evolve its own configuration. It does not rewrite application code, and it does not touch user data. Its job is to propose candidate changes to the named configuration domains that govern platform behavior, evaluate those candidates under hermetic contracts, and adopt only the candidates that demonstrably improve the relevant domain.
The design is deliberately conservative. Every adoption is the end of a fully recorded pipeline run: Researcher evidence, Engineer draft, Analyzer evaluation, Judge verdict. Nothing self-deploys.
Researcher. Pulls prior cognition relevant to the target domain — past evaluations, calibration trends, cross-domain learnings — from the engine's cognition store.
Engineer. Drafts a candidate configuration change shaped to the target domain's contract.
Analyzer. Runs the candidate through the domain's hermetic evaluation contract and produces a structured evaluation report.
Judge. Reviews candidate and evaluation together and returns one of three structured verdicts: adopt, reject, or iterate.
The four roles are decoupled by design. Each role's output is structured input to the next role, and each role's run is individually auditable.
The engine operates over a fixed set of named domains, each with its own evaluation contract. Public framing covers nine domains spanning intelligence, risk, calibration, agent infrastructure, and content surfaces. Domains are named publicly so cross-domain cognition can be referenced; the contents of each contract are withheld.
A hermetic evaluation contract is a domain-specific specification that fixes the inputs, the candidate change format, and the deterministic outputs an Analyzer run must produce for the candidate to be considered evaluable.
The contract isolates the evaluation from outside state. The same candidate, re-evaluated tomorrow, produces the same evaluation result. This is what makes the Judge's verdict defensible — the verdict is a function of the candidate and the contract, not of ambient runtime conditions.
Each completed run contributes to a shared cognition store. The Researcher consults this store on the next run, so improvements in one domain can inform investigations in adjacent domains. Cognition entries are scoped, dated, and revisable — not a monolithic prompt blob.
To prevent two evolution runs from racing inside the same domain — for example, two Engineers concurrently drafting candidates against the same baseline — the engine enforces a status-based mutex at the data layer. A domain whose status indicates an active evolution cannot start another run in the same status.
Enforcing the mutex at the data layer rather than in application code means the safety property survives application restarts, parallel workers, and retry loops. The mutex is a property of the system, not of any one process.
The Judge is the only role permitted to return an adopt verdict. Its inputs are the candidate, the Analyzer's evaluation report, and the relevant cognition. Its output is a structured verdict with rationale. The Judge's scoring rubric and threshold values are intentionally withheld; the Judge's role and contract are public.
The engine evolves configuration, not application logic or user data. Configuration changes are powerful but bounded.
Hermetic contracts make evaluations reproducible, but they cannot guarantee that the contract itself captures every relevant production effect. Contracts are reviewed and revised; no contract is permanently complete.
The status-based mutex prevents intra-domain races, but cross-domain dependencies still require human judgment when two domains are co-evolved.
Candidate generation is bounded by the Engineer's mutation space. Genuinely novel configurations outside that space require human authoring, not autonomous evolution.
Nothing the engine does is investment advice. Evolution improves platform behavior; trading outcomes depend on markets, not on configuration alone.
Download the PDF
The full HTML version is freely available above. Enter your email to download the printable PDF of ASI Evolution Engine: Self-Improving Configuration.