What's new

Adaptive Optimization — New Preview

The previous preview introduced the new observation, attribution, measurement, and causal evaluation foundation for Adaptive Optimization.

At that point, the next major goal was clear:

connect those systems into a real experiment coordinator capable of applying an optimization, measuring it, rolling it back, and deciding whether the result was actually trustworthy.

That system is now real.

This preview moves Adaptive Optimization significantly further toward its long-term autonomous architecture by completing the first full causal optimization lifecycle in actual Minecraft runtime testing.

The new system can now take an optimization from controlled observation all the way to a durable causal result without allowing incomplete, inconclusive, or unsafe experiments to become fake learning.

The Experimental Coordinator is now implemented

In the previous preview, the Experimental Coordinator was still part of the roadmap.

It is now implemented.

Adaptive Optimization now has a dedicated state machine controlling the complete lifecycle of a causal optimization experiment:

• OBSERVING
• PRE
• APPLYING
• STABILIZING
• EXPERIMENT
• ROLLING_BACK
• RECOVERY
• EVALUATING
• FINALIZED

This means the experimental system no longer consists only of independent measurement tools.

There is now a central coordinator responsible for deciding when an experiment is valid, controlling the intervention, collecting the correct windows, restoring the original state, and producing the final causal result.

First complete real optimization experiment

The new causal system has now completed its first full optimization experiment in a real integrated Minecraft world.

The pilot experiment used a small and reversible FriendlyByteBuf / VarInt optimization path.

Adaptive Optimization successfully:

• Captured the original physical configuration
• Collected a full PRE control window
• Applied the experimental optimization
• Verified the applied physical state
• Allowed the system to stabilize
• Collected the EXPERIMENT window
• Rolled the optimization back
• Verified that the original state was restored
• Collected the RECOVERY window
• Evaluated performance, safety, semantics, comparability, and evidence quality
• Finalized the experiment
• Returned control to the normal optimization system

The physical states were verified as:

Captured:
(false, false, 256)

Experimental:
(true, false, 69)

Restored:
(false, false, 256)

This is important because AO is no longer only comparing abstract statistics.

It can now prove that a specific optimization was physically active during the experimental window and physically removed during recovery.

AO can now reject placebo optimizations

The first real experiment did not produce a large enough performance improvement to pass the causal threshold.

Its performance result was:

NO_EFFECT

with:

EFFECT_BELOW_THRESHOLD

The final experiment verdict remained:

INCONCLUSIVE

and learning was:

NOT_ELIGIBLE

This is a successful result for the architecture.

Adaptive Optimization did not try to force the experiment into a success simply because the optimization ran without crashing.

It correctly concluded that the available evidence was not strong enough to prove a useful improvement.

This is one of the most important behaviors required for the final system:

an optimization that does not prove its value should not automatically become permanent.

Stronger intervention ownership

The experimental system now has explicit ownership of physical interventions.

While a controlled experiment owns an optimization state, other systems cannot silently modify the same state underneath it.

This prevents situations where:

• one system applies an optimization;
• another system changes it during measurement;
• the experiment measures a mixture of multiple interventions;
• AO incorrectly attributes the result to the wrong candidate.

The intervention lane is released after the experiment returns to a verified neutral state.

Crash-safe experiment journal

The experiment coordinator now uses a durable journal.

Important experiment state is persisted before dangerous transitions such as applying or rolling back an optimization.

If Minecraft closes while an experiment is incomplete, AO does not blindly continue the previous treatment after restarting.

Non-terminal experimental state is treated fail-closed.

The system is designed to prioritize:

restoring a known safe state

over:

trying to preserve an unfinished performance experiment.

Restart recovery is now separated from experimentation

Adaptive Optimization can now distinguish between:

recovering information from a completed experiment

and

replaying an experiment.

This distinction has been validated across a real Minecraft restart.

A completed terminal experiment does not automatically:

• acquire the intervention lane;
• apply the candidate again;
• create another PRE window;
• start another experiment;
• increment physical intervention counters.

This gives the new system a much safer foundation for future long-running autonomous operation.

More honest semantic verification

The semantic evaluation introduced in the previous preview has also been tightened.

Adaptive Optimization no longer considers:

"I did not observe an obvious bug"

to mean:

"the optimization is semantically proven correct."

Semantic results now preserve:

• PASS
• FAIL
• NOT_VERIFIED

A real PASS requires actual positive semantic evidence.

If AO only knows that no explicit failure was observed, the result remains:

NOT_VERIFIED

The first real experiment correctly finished with:

NOT_VERIFIED

instead of receiving an artificial semantic pass.

Canonical causal learning records

A completed experiment can now be converted into a new canonical causal record.

This record represents:

one specific experiment and what actually happened during it.

It preserves information such as:

• Experiment identity
• Candidate identity
• Canonical candidate representation
• Candidate implementation version
• Target
• Target group
• Environment fingerprint
• Performance result
• Safety result
• Semantic result
• Comparability
• Evidence quality
• Diagnostic reasons
• Semantic evidence provenance
• Experiment timestamps
• Server session
• Evidence integrity hash

The same causal fact produces the same deterministic canonical representation.

This creates an important new boundary:

ExperimentOutcome = what happened during this experiment

CausalLearningRecord = the durable factual representation of what happened

The record itself does not decide that a candidate is good, bad, trusted, or important.

It stores facts.

Positive and negative causal evidence

The new causal learning format can preserve both successful and unsuccessful trustworthy experiments.

A valid:

ACCEPT

can become positive causal evidence.

A valid:

REJECT

can become negative causal evidence.

Meanwhile:

• INCONCLUSIVE
• ABORTED

can still be retained as historical information without contributing positive or negative causal learning.

This will eventually allow AO to understand not only what worked, but also:

• what failed;
• what could not be measured reliably;
• which environments produce inconclusive experiments;
• which strategies repeatedly fail to demonstrate value.

Durable causal learning ledger

Adaptive Optimization now has a new independent causal history store:

causal-learning-ledger.jsonl

The ledger is append-only and stores canonical experimental facts separately from the legacy learning systems.

Each causal record is associated with:

• its unique Experiment ID;
• its canonical record hash;
• its schema version;
• durable commit metadata.

The Experiment ID acts as the idempotency identity.

The record hash verifies the exact causal payload.

This gives the future learning system a clean source of historical evidence without requiring it to depend on legacy Policy or Action statistics.

Exactly-once causal persistence

A new transactional outbox now connects completed experiments to the causal ledger.

The persistence path works approximately like this:

Experiment becomes terminal
↓
Canonical causal record is prepared
↓
FINALIZED + PENDING record are persisted
↓
Record is committed to the causal ledger
↓
Journal marks the record as ACKNOWLEDGED

This solves an important restart problem.

If Minecraft closes after the ledger write but before the final acknowledgement, AO can retry the ingestion after restart.

If the same Experiment ID and the same record already exist:

the record is not duplicated.

If the same Experiment ID appears with different causal data:

the conflict is rejected instead of overwriting the original history.

Interrupted and corrupted causal writes fail closed

The causal ledger also includes corruption handling.

If an interrupted write damages the end of the ledger:

• previously valid records remain available;
• the damaged suffix can be isolated;
• the ledger returns to the last valid record boundary;
• corrupted data is not silently accepted.

Unknown future causal record versions are also rejected rather than being interpreted using assumptions from the current version.

The goal is for causal history to remain trustworthy even as Adaptive Optimization evolves.

Real restart idempotency validation

The complete causal persistence system has now been validated in Minecraft.

The runtime test produced:

• One manually armed experiment
• One physical application
• One completed causal experiment
• One causal ledger record
• One acknowledged outbox entry
• Zero legacy learning writes

Minecraft was then saved and closed normally.

After restarting Adaptive Optimization without starting another experiment:

• No new experiment was created
• No optimization was applied again
• No PRE / EXPERIMENT / RECOVERY sequence was replayed
• The causal ledger still contained exactly one record
• The journal remained unchanged
• The ledger remained byte-for-byte unchanged

This confirms that completed causal knowledge can survive restart without causing the physical experiment to happen again.

Legacy learning remains isolated

The existing Adaptive Optimization systems are still present and continue handling the currently active optimization behavior.

However, the new causal results are intentionally not written directly into the old Policy, ActionState, StrategyMemory, plan, or variant systems.

This separation is deliberate.

The old architecture was not designed to preserve all of the causal dimensions that now exist, including:

• candidate identity;
• target identity;
• environment;
• performance;
• safety;
• semantics;
• comparability;
• evidence quality.

Directly feeding the new results into legacy learning would throw away important information and could recreate many of the problems the new architecture is designed to solve.

The new causal learning system will therefore develop independently before it is allowed to influence autonomous decisions.

What is still missing?

The previous preview listed the Experimental Coordinator, real causal experiments, and learning integration as major future steps.

The first two are now functional, and the foundations of the third are now implemented.

However, Adaptive Optimization is still not finished.

AO can now preserve trustworthy experimental facts, but it does not yet have the full modern knowledge system required to understand those facts across many experiments.

The next major question is:

What does AO know about an optimization after observing it many times across different workloads, targets, mods, and environments?

That is the next stage of development.

Plan for the next previews

Next previews — Candidate Knowledge

The next major system will be CandidateKnowledge.

Instead of treating each experiment as an isolated result, AO will begin building contextual knowledge about each optimization candidate.

It will need to distinguish between evidence for:

• The same candidate
• Different targets
• Different mods
• Different environments
• Repeated experiments
• Contradictory evidence
• Global behavior
• Context-specific behavior

The causal ledger will remain the factual source of truth.

Candidate Knowledge will be a derived understanding of those facts.

At first, this system will remain informational and will not automatically promote or apply candidates.

Later previews — Modern candidate lifecycle

Once Candidate Knowledge is reliable, optimization candidates will begin receiving a lifecycle independent from the legacy Action system.

This will eventually allow AO to distinguish candidates that are:

• Experimental
• Promising
• Trusted
• Rejected
• Superseded
• Quarantined

without confusing candidate identity with the older action-selection architecture.

Later previews — Optimization Value

Future versions will move beyond evaluating optimization quality using only a single performance number.

Adaptive Optimization is planned to evaluate strategies using a multidimensional Optimization Value system.

Possible factors include:

• Causal performance improvement
• Confidence
• Safety
• Semantic correctness
• Repeatability
• Long-term stability
• Coverage
• Generality
• Compatibility
• Runtime overhead
• Rollback reliability
• Activation cost
• Restart cost
• Blast radius

This will eventually help AO distinguish between an optimization that looks fast once and an optimization that is actually valuable long term.

Later previews — Strategy competition and evolution

Multiple strategies solving the same problem will eventually be able to compete.

AO is planned to support:

• Strategy variants
• Strategy descendants
• Improved versions of existing optimizations
• Strategy combinations
• Dominance detection
• Champions within optimization families
• Quarantine of unsafe strategies
• Removal or archival of obsolete strategies

An accepted optimization should not necessarily represent the end of experimentation.

It may become the parent of a better strategy.

Later previews — Self-correction

Adaptive Optimization is also planned to detect when one of its own accepted optimizations later causes:

• Performance regressions
• Gameplay problems
• Instability
• Compatibility issues

The intended process is:

Detect
↓
Roll back
↓
Quarantine
↓
Diagnose
↓
Generate a corrected descendant when possible
↓
Test again

AO should not hide a broken optimization behind additional patches while leaving the original problem active.

Later previews — Restart-required experiments

The first validated experiment operates entirely during a live Minecraft session.

Future optimizations may require:

• Startup changes
• Class-load changes
• Bootstrap transformations
• Restart

These candidates will require a separate fail-closed experimental lifecycle.

A restart-required candidate must never be able to create a permanent crash loop simply because AO was testing it.

Later previews — Open-world optimization discovery

The long-term goal remains larger than a fixed list of optimization categories.

Entities, chunks, rendering, networking, I/O, and other subsystem names are useful descriptions of workload.

They are not intended to permanently define the limits of what Adaptive Optimization is allowed to discover.

Future versions are intended to identify new performance patterns, causal relationships, and optimization opportunities that were not explicitly predicted when the mod was written.

Later previews — Autonomous candidate generation

The long-term architecture still aims for:

Observe
↓
Identify
↓
Diagnose
↓
Generate hypotheses
↓
Create optimization candidates
↓
Experiment
↓
Measure
↓
Accept or reject
↓
Remember
↓
Improve
↓
Repeat

The final objective is for Adaptive Optimization to progressively discover and improve optimization strategies without requiring an external AI service or runtime code-generation system.

Every candidate will still have to obey causal measurement, safety, rollback, compatibility, and semantic requirements.

Working together with the rest of the optimization ecosystem

The overall ecosystem goal remains unchanged.

Adaptive Optimization is being designed to cooperate with specialized projects such as:

• Sync Fix
• Chunks Optimization
• Logs Fixer
• Render optimization systems
• Mods Fixer

Specialized optimizers can continue owning deep optimization mechanisms inside their respective domains.

Adaptive Optimization can observe those domains and eventually provide complementary, adaptive, contextual, or cross-system optimizations when there is measurable evidence that they add value.

AO is not intended to blindly reproduce work that another optimizer already performs.

At the same time, its observation and discovery systems are not artificially restricted from understanding those workloads.

Current status

This preview completes the next major milestone described in the previous release.

Adaptive Optimization can now perform a real controlled causal optimization experiment from beginning to end.

It can:

Observe
↓
Identify
↓
Diagnose
↓
Measure PRE
↓
Apply a real optimization
↓
Verify the intervention
↓
Measure EXPERIMENT
↓
Roll back
↓
Verify recovery
↓
Measure RECOVERY
↓
Evaluate the evidence
↓
Refuse inconclusive learning
↓
Create a canonical causal fact
↓
Persist it exactly once
↓
Recover that history safely after restart

The next challenge is no longer proving that AO can perform a trustworthy experiment.

That has now been demonstrated.

The next challenge is teaching Adaptive Optimization how to combine thousands of trustworthy experimental facts into reliable knowledge about which optimization strategies work, where they work, why they work, and when they should be used.

Adaptive Optimization is no longer only learning how to prove that an optimization works.

It is now building the memory required to understand what those experiments mean over time.