Bias Evolution — Self-Evolving Inductive Biases¶

What It Is¶

Every AIBlock in G6 carries an inductive bias — a set of assumptions, strategies, and tunable parameters that shape how the block processes its inputs. Normally these biases are static: a developer sets them once and they remain fixed.

Bias evolution makes these biases self-evolving. The adapt_bias component implements a cybernetic learning loop that observes system performance, proposes targeted mutations to component biases, verifies them against theoretical foundations, and applies them — all under strict safety constraints.

The result is a system that gets better at its own tasks over time, without human intervention in the mutation mechanics, while remaining fully auditable and reversible.

How It Works: The 8-Stage Cybernetic Loop¶

graph TD
    A["1. Observe<br/>Classify situation via context_engine"] --> B["2. Understand<br/>Structural analysis via self_model"]
    B --> C["3. Evaluate<br/>Multiobjective scoring<br/>(speed / cost / quality)"]
    C --> D["4. Propose<br/>Generate mutation via<br/>agent_autogen debate"]
    D --> E["5. Verify<br/>4-layer safety gate"]
    E --> F{"All 4 layers<br/>passed?"}
    F -->|Yes| G["6. Select<br/>Pareto frontier ranking"]
    F -->|No| H["Reject mutation"]
    G --> I["7. Apply<br/>Record in registry + memory"]
    I --> J["8. Record<br/>Git tag + episodic memory +<br/>always-on memory"]
    J --> A
    H --> A

Stage 1: Observe¶

The loop begins by classifying the current situation. The context_engine component processes workflow traces (execution logs, quality scores, latency data) and determines whether the system is in a stable, degraded, or novel state. Always-on memory is queried for recent patterns.

Stage 2: Understand¶

Structural analysis via self_model and deep_understanding builds a picture of the target component's contracts, verification status, and parameter relationships. This produces a domain specification that maps the component's bias structure.

Stage 3: Evaluate¶

Multiobjective fitness scoring runs the workflow trace through three optimisation components:

• opt_speed — latency and throughput analysis
• opt_cost — token and API cost analysis
• opt_quality — output quality scoring

Results are combined via opt_meta Pareto analysis with configurable weights (default: speed 0.33, cost 0.33, quality 0.34).

Stage 4: Propose¶

Mutation proposals are generated via agent_autogen multi-agent debate. Two agents analyse the current bias and frontier, then propose a specific parameter change. If the LLM path is unavailable, a deterministic fallback nudges the first numeric evolvable parameter by 10% toward its upper bound.

Stage 5: Verify¶

The proposed mutation passes through all 4 safety layers (see Safety below). If any required layer rejects the mutation, it is discarded and the loop continues to the next iteration.

Stage 6: Select¶

Accepted candidates are scored and inserted into a Pareto frontier of the top 5 performers. The frontier prevents catastrophic forgetting — even if a new mutation regresses, the previous best is preserved.

Stage 7: Apply¶

The winning mutation is recorded in the BiasRegistry, stored in episodic memory (adapt_memory), written to the prompt library (align_prompt_library), and a Git tag is created for auditability.

Stage 8: Record¶

An automatic self-heal check runs (self_debug + system_doctor). If regressions are detected, the system attempts automated repair. If repair fails, an automatic rollback restores the previous version.

Always-On Memory¶

Bias evolution uses an LLM-based read-think-write memory system (no vectors or embeddings). This provides:

• Continuity — insights from previous evolution cycles persist across restarts
• Pattern recognition — the system recalls which mutations worked and which failed
• Context enrichment — observation and understanding stages query memory for relevant history

Memory is accessed through workspace_manager.always_on_memory.agents.MemoryAgents and records are ingested with the bias_evolution source tag.

Theoretical Grounding¶

Bias mutations are constrained by a second-order directive derived from the G6 theoretical foundations. Six principles act as evolutionary guardrails:

Each check runs as a deterministic heuristic (no LLM calls). If any principle fails, the mutation is rejected and the failure is recorded to always-on memory for future reference.

Safety: 4-Layer Verification¶

Before any mutation is applied to a live component, it must pass all 4 layers:

The number of required layers is configurable via safety_layers_required (default: 4). If a component for a given layer is unavailable, that layer passes through — but in production with observability_required=true, all layers should be present.

Additional safety mechanisms:

• Workspace sandbox — mutations operate within a workspace boundary enforced by workspace_manager
• Automatic rollback — if post-mutation self-heal detects regressions and cannot repair them, the previous version is restored
• Git tagging — every applied mutation creates a bias/<component>/v<N> tag for full audit trail
• Episodic memory — all mutations (accepted and rejected) are recorded for long-term analysis

Configuration¶

All configuration lives under settings.bias_evolution (class BiasEvolutionConfig):

Production Setup Checklist¶

Set these before exposing bias evolution through MCP or REST:

BIAS_EVOLUTION_ENABLED=true
BIAS_EVOLUTION_CONFIRM_TOKEN=<random-human-reviewed-secret>
BIAS_EVOLUTION_TIER=premium
BIAS_DB_PATH=~/.bias_mcp/bias.db

BIAS_EVOLUTION_CONFIRM_TOKEN is required for evolve, apply, and rollback. The caller must pass the same value as confirm_token; otherwise the operation is refused. This prevents an automated planner or prompt-injected MCP call from silently mutating a component.

For standalone local MCP servers, tier is resolved in this order:

Use trialing for time-limited design partner or trial access. Use premium for paid access. Avoid G6_DEV_MODE=true outside local development because it bypasses tier checks.

Storage Backend¶

Bias evolution uses MLflow when it is installed. If MLflow is unavailable, it falls back to a local SQLite store. The SQLite default is ~/.bias_mcp/bias.db; override it with BIAS_DB_PATH.

SQLite is appropriate for local pilots and the launch-plan goal of a single-user MCP workflow. Use MLflow for shared staging or production deployments that need experiment tracking, model registry stages, and artifact-backed reproducibility.

Premium Tier Restriction¶

Bias evolution mutating operations are restricted to premium or trialing access. Read-only local direct calls can still run in developer contexts, but public MCP and REST entry points enforce strict access checks. Mutating operations (evolve, apply, rollback) additionally require confirm_token.