What's new

Adaptive Optimization — New Preview

The previous preview completed one of the most important milestones in Adaptive Optimization's development:

AO learned how to perform a controlled optimization experiment, measure what actually happened, roll the optimization back, preserve the result as a trustworthy causal fact, and store that fact safely across restarts.

At the end of that preview, the next challenge was no longer collecting experiments.

The next challenge was understanding them.

That work has now started.

This preview introduces the first major pieces of Adaptive Optimization's new Candidate Knowledge architecture, together with a significantly richer causal record format capable of preserving not only the result of an experiment, but also the context in which it happened and the measured effect that produced that result.

AO is beginning to move from:

"What happened in this experiment?"

toward:

"What do all of these experiments collectively tell me about this optimization?"

Causal records now contain much more context

The previous causal record format was intentionally minimal.

It could safely preserve things such as:

• Candidate identity
• Target identity
• Environment fingerprint
• Performance result
• Safety result
• Semantic result
• Comparability
• Evidence quality
• Experiment reasons
• Evidence integrity

That was enough to create trustworthy historical facts.

However, it was not enough for Adaptive Optimization to safely generalize knowledge across different targets and environments.

This preview introduces a new schema2 causal record with much richer contextual information.

New experiments can now preserve dedicated descriptors for:

• The optimization candidate
• The target being optimized
• The environment where the experiment occurred
• The actual measured causal effect

This gives the future learning system substantially more information to work with without forcing it to guess what an old hash meant.

Historical causal records remain unchanged

Backward compatibility was a major requirement for the new format.

Old schema1 causal records are not upgraded, rewritten, enriched, or reinterpreted.

If an older experiment only recorded a target hash and environment hash, Adaptive Optimization keeps that historical fact exactly as it was originally recorded.

It does not attempt to reconstruct missing context using information available today.

The real schema1 experiment from the previous preview remains byte-for-byte identical, including its original canonical hash.

This means the causal history follows an important rule:

Historical evidence keeps the meaning it had when it was created.

New experiments use the richer schema2 format.

Old experiments remain valid schema1 history.

Both can exist together in the same causal ledger.

New Candidate Descriptor

New causal records can now preserve a structured description of the optimization candidate that was actually tested.

This can include information such as:

• Candidate ID
• Canonical candidate representation
• Candidate hash
• Implementation version
• Optimization mechanism
• Magnitude
• Parameters
• Physical optimization vector identity

The descriptor describes what was tested.

It does not contain:

• Candidate rank
• Promotion status
• Champion status
• Optimization Value
• Trust tier

Those systems have intentionally not been implemented yet.

The causal record stores facts, not opinions about whether the candidate should eventually be used.

New Target Descriptor

Adaptive Optimization can also preserve a richer description of what the candidate was targeting.

Depending on the information available during the experiment, this can include:

• Target identity
• Target group
• Thread context
• Vanilla/modded origin
• Owning mod
• Subsystem
• Workload family
• Provenance
• Resolution confidence

When information is unavailable, AO preserves that honestly.

For example, some current experimental targets do not yet expose their complete class, method, module, or loader identity to the causal experiment layer.

In those cases, AO stores them as unresolved instead of inventing details.

This allows the knowledge system to understand the difference between:

"AO knows this target precisely"

and

"AO only knows part of this target's identity."

New Environment Descriptor

Causal experiments can now preserve a structured description of the environment where they occurred.

This can include information such as:

• Minecraft version
• Runtime / Forge version
• World
• Dimension
• Logical side
• Thread context
• Reload state
• Relevant runtime buckets
• Stable environmental attributes

The environment descriptor is descriptive.

It does not automatically decide that two worlds, modpacks, dimensions, or runtime conditions are equivalent.

That decision belongs to future Candidate Knowledge and learning systems.

This is important because an optimization that works extremely well in one environment may behave differently somewhere else.

Full causal effect vectors

One of the largest additions in this preview is the new CausalEffectVector.

The previous record could preserve the final experiment result and an evidence integrity hash.

The new format can also preserve the closed measurement summaries that produced that result.

For each supported measurement provenance, Adaptive Optimization can retain information for:

• PRE
• EXPERIMENT
• RECOVERY

including:

• Availability
• Sample count
• Mean
• P50
• P95
• P99
• Maximum
• Over-budget fraction
• Measured effect fraction
• Recovery deviation
• Performance classification

Raw samples are not permanently copied into Candidate Knowledge.

Only bounded causal summaries are preserved.

This gives AO enough information to understand the actual measured behavior without turning its knowledge store into another massive profiler log.

Forge and Minecraft measurements remain independent

The two server performance measurements introduced previously remain separate:

• Forge Server Tick Event Span
• Minecraft Recorded Server Tick Duration

The new causal effect format does not average them into a fake universal number.

Each provenance keeps its own:

• PRE measurements
• Experimental measurements
• Recovery measurements
• Effect
• Recovery deviation
• Classification

This will eventually allow Candidate Knowledge to detect whether multiple independent measurements agree or disagree about an optimization.

Schema2 has now been validated in real Minecraft runtime

The new causal record format was not only tested offline.

A complete schema2 experiment was executed in an actual integrated Minecraft world.

Adaptive Optimization again completed the full lifecycle:

PRE
↓
APPLY
↓
STABILIZE
↓
EXPERIMENT
↓
ROLLBACK
↓
RECOVERY
↓
EVALUATE
↓
FINALIZE

The experiment once again returned the optimization to its original physical state:

Captured:
(false, false, 256)

Experimental:
(true, false, 69)

Restored:
(false, false, 256)

The final causal result remained:

• Performance: NO_EFFECT
• Safety: SAFE
• Semantics: NOT_VERIFIED
• Comparability: VALID
• Final verdict: INCONCLUSIVE
• Learning eligibility: NOT_ELIGIBLE

The richer schema2 record did not change the experiment's meaning.

It only preserved more truthful information about why that result occurred.

Runtime effect data matched the experiment journal exactly

The schema2 runtime validation compared the new causal effect vector directly against the experiment journal.

Both server tick measurement systems were checked across:

• PRE
• EXPERIMENT
• RECOVERY

with the complete measurement summaries.

The comparison produced:

0 discrepancies.

The experiment contained 200 samples per phase for each measurement provenance.

This confirms that the new durable record is not reconstructing approximate evidence after the experiment.

It is preserving the same causal measurements that were actually evaluated.

Mixed schema1 and schema2 history is now working

The real causal ledger now contains both:

the historical schema1 experiment from the previous preview

and

the new schema2 experiment

at the same time.

Both records retain their own original identity and canonical hash.

The old record remains untouched.

The new record contains the richer descriptors and effect vector.

This proves that Adaptive Optimization can evolve its causal evidence format without invalidating trustworthy experiments collected by older versions.

Restart safety remains intact

After the schema2 runtime experiment completed, Minecraft was saved and restarted without manually arming another experiment.

On restart:

• No experiment was replayed
• No candidate was applied again
• No intervention lane was acquired
• No PRE / EXPERIMENT / RECOVERY cycle occurred
• No legacy learning was written
• The causal journal remained unchanged
• The mixed causal ledger remained byte-for-byte unchanged

This confirms that the richer causal record system did not break the exactly-once persistence and restart guarantees introduced in the previous preview.

Candidate Knowledge core is now implemented

The first core version of Candidate Knowledge has now been implemented.

This system is currently offline and informational.

It does not control optimization decisions yet.

Its purpose is to take many trustworthy causal records and answer questions such as:

• How many times has this candidate been tested?
• How many results were actually eligible for causal learning?
• How many independent sessions have observed it?
• How many different contexts have been tested?
• How many different targets have been tested?
• How often did the candidate produce positive causal evidence?
• How often did it produce negative causal evidence?
• Are results repeatable inside the same context?
• Are results contradictory?
• Does behavior change between different contexts?
• Has any safety or semantic hazard ever been observed?
• What measured effects were observed?

This is the beginning of the system that will eventually allow AO to understand its own optimization history.

Candidate Knowledge is contextual

Candidate Knowledge is not built around one global:

"this optimization is good"

or:

"this optimization is bad."

Knowledge is organized approximately as:

Candidate
↓
Exact Context
↓
Target
↓
Global Candidate View

This allows AO to distinguish between situations such as:

The same candidate repeatedly works on one target

and:

The same candidate behaves differently on another target

without automatically treating the second situation as a contradiction.

This is essential for a future optimizer that must operate across hundreds of mods and many different workloads.

Repetition and independent evidence are now separated

One of the biggest risks in an autonomous learning system is pseudoreplication.

For example:

100 experiments performed under essentially the same conditions

must not automatically become equivalent to:

100 independent environments proving the same conclusion.

Candidate Knowledge now separates concepts such as:

• Raw experiment count
• Eligible experiment count
• Session count
• Exact-context breadth
• Target breadth
• Positive causal evidence
• Negative causal evidence

This means 100 repeated experiments can still increase knowledge about repeatability inside that context, while not pretending that AO has tested the optimization across 100 independent situations.

Contradiction and context sensitivity are different

Candidate Knowledge now distinguishes between two very different situations.

Contradiction

The same candidate, under the same exact context, produces trustworthy results that disagree.

For example:

ACCEPT
REJECT
ACCEPT
REJECT

This may indicate poor repeatability or unstable behavior.

Cross-context heterogeneity

The candidate behaves differently in genuinely different contexts.

For example:

Target A → ACCEPT

Target B → REJECT

This does not automatically mean the candidate is unreliable.

It may mean that the candidate is context-sensitive.

That distinction will eventually be extremely important when AO starts deciding where an optimization should and should not be used.

Safety and semantics cannot disappear inside averages

Candidate Knowledge preserves the major causal axes independently.

It does not turn everything into one average score.

Performance, safety, semantics, comparability, and evidence quality remain separate.

For example:

many good performance results + one real UNSAFE result

does not become:

"mostly safe."

The safety hazard remains visible.

The same applies to semantic failures.

This prevents future Optimization Value calculations from accidentally hiding serious problems behind a large number of successful performance measurements.

Inconclusive experiments are still useful without becoming negative evidence

INCONCLUSIVE and ABORTED experiments remain part of Candidate Knowledge history.

They can tell AO things such as:

• This candidate is difficult to measure
• This workload often disappears during experimentation
• This environment produces poor comparability
• This candidate frequently encounters restart or operational interruptions

However, they still contribute:

zero positive causal direction

and:

zero negative causal direction

An experiment that could not prove anything is not silently converted into evidence that the candidate is bad.

Effect aggregation avoids raw global averaging

The new knowledge core can also summarize schema2 effect vectors.

However, it deliberately avoids simply averaging every experiment together globally.

The hierarchy is designed approximately as:

Experiments
↓
Exact-context summaries
↓
Target summaries
↓
Global candidate summary

This prevents a candidate tested hundreds of times in one context from completely overwhelming evidence collected from other independent contexts.

Forge and Minecraft measurement provenance also remain separate during aggregation.

There is still no artificial universal performance score.

Candidate Knowledge is deterministic

The knowledge core is designed so that the same set of causal records produces the same logical Candidate Knowledge snapshot regardless of the order in which those records are provided.

Duplicate protection also exists.

If the same Experiment ID and identical causal record are seen again:

it does not count twice.

If the same Experiment ID appears with conflicting causal data:

Candidate Knowledge fails closed instead of silently choosing one version.

This adds another layer of protection on top of the exactly-once causal ledger.

Candidate Knowledge remains bounded

The new aggregation system is designed with explicit structural limits.

Candidate Knowledge stores summaries rather than copying the complete causal history.

The full experiment history remains in the causal ledger.

Candidate Knowledge only keeps the information required to describe the accumulated evidence.

If structural limits are exceeded, the system fails explicitly rather than silently deleting causal evidence.

Future strategy cleanup and archival systems will handle long-term knowledge maintenance deliberately instead of hiding it inside arbitrary eviction behavior.

Candidate Knowledge does not control Minecraft yet

This is very important for the current preview.

The Candidate Knowledge core exists, but it currently has:

zero runtime optimization decision authority.

It does not:

• Promote candidates
• Apply optimizations
• Change Policy
• Change StrategyMemory
• Select champions
• Start experiments automatically
• Generate candidates
• Assign Optimization Value
• Rank strategies

The current system is intentionally separated into stages.

Adaptive Optimization is first learning how to build trustworthy knowledge.

Only after that knowledge system is validated will it be allowed to influence decisions.

What is still missing?

The previous preview ended with Candidate Knowledge as the next major challenge.

The first core aggregation system now exists.

However, Candidate Knowledge is not yet fully integrated into Adaptive Optimization's runtime architecture.

The next step is making this derived knowledge durable and safely rebuildable from the causal ledger.

The causal ledger will remain the historical source of truth.

Candidate Knowledge will remain a derived view of that history.

Plan for the next previews

Next previews — Durable Candidate Knowledge

The next stage will introduce a persistent materialized Candidate Knowledge view.

Conceptually:

Causal Ledger
↓
Candidate Knowledge rebuild
↓
Persistent Candidate Knowledge snapshot

The causal ledger will remain authoritative.

If Candidate Knowledge is:

• Missing
• Outdated
• Corrupted
• Built using an older aggregation algorithm

AO should be able to discard or isolate it and rebuild the knowledge from the original causal history.

A failure in Candidate Knowledge must never alter:

• Experiment verdicts
• Causal history
• Physical rollback
• Outbox acknowledgement
• Current optimization behavior

Candidate Knowledge is intended to be rebuildable knowledge, not irreplaceable history.

Later previews — Modern candidate lifecycle

Once Candidate Knowledge is persistent and validated, optimization candidates can begin receiving a lifecycle independent from the legacy Action system.

This will eventually allow AO to represent states such as:

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

These states will not simply be based on one successful experiment.

They will eventually depend on accumulated causal evidence across contexts and time.

Later previews — Optimization Value

Candidate Knowledge will eventually provide the evidence required for the future multidimensional Optimization Value system.

Rather than asking only:

"Did FPS increase?"

AO will eventually evaluate things such as:

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

The purpose will not be to find the optimization with the largest short-term number.

The purpose will be to identify the optimization that provides the most reliable overall value.

Later previews — Strategy competition

Multiple strategies targeting the same underlying problem will eventually be able to compete using accumulated causal knowledge.

Instead of permanently keeping every successful variant, AO will eventually be able to identify:

• Stronger strategies
• Context-specific strategies
• Dominated strategies
• Obsolete variants
• Candidates requiring more evidence
• Unsafe candidates

This will form the foundation for future strategy champions and evolutionary optimization.

Later previews — Improving existing optimizations

A successful optimization will eventually be able to become the parent of new candidate variants.

AO is planned to experiment with:

• Different parameters
• Different activation conditions
• Different contexts
• Combined optimization mechanisms
• More efficient descendants

An accepted strategy should not necessarily remain unchanged forever.

The system should eventually be able to improve its own previously successful optimizations.

Later previews — Strategy combinations

Future candidate generation is also intended to support combinations such as:

• Cache + invalidation
• Deduplication + batching
• Batching + scheduling
• Reuse + fast path
• Multiple compatible optimization mechanisms

A combination will not automatically inherit the trust of its individual components.

Every combined strategy will still require its own causal identity, measurements, safety checks, rollback behavior, and experimental evidence.

Later previews — Self-correction

The future self-correction system will use long-term Candidate Knowledge to detect when an optimization that previously looked safe later causes:

• Performance degradation
• Gameplay bugs
• Compatibility problems
• Instability
• Delayed regressions

The intended process remains:

Detect
↓
Roll back
↓
Quarantine
↓
Diagnose
↓
Create a corrected descendant when possible
↓
Experiment again

A previously accepted optimization will not be considered permanently correct forever.

Later previews — Long-term optimization surveillance

Future versions will continue observing promoted strategies after their initial acceptance.

This is important because some problems only appear:

• After hours of gameplay
• After changing dimensions
• After deaths
• After reloads
• After world restarts
• After interacting with other optimizations
• After accumulated memory or state changes

Candidate Knowledge will eventually need to incorporate this long-term evidence as well.

Later previews — Restart-required experiments

Adaptive Optimization still needs a separate experimental lifecycle for candidates that cannot be safely tested entirely during a running Minecraft session.

Examples include optimizations requiring:

• Startup changes
• Class loading
• Bootstrap changes
• Restart

These candidates will require persistent pre-start state, startup verification, post-restart validation, and fail-closed recovery.

A failed experimental startup must not create a permanent crash loop.

Later previews — Open-world optimization discovery

The long-term goal remains unchanged.

Adaptive Optimization should not be permanently limited to a developer-written list of:

• Entities
• Chunks
• Networking
• Rendering
• I/O
• Other known categories

Those categories describe known workloads.

They should not define the complete optimization search space.

Future AO systems are intended to identify previously unknown workload relationships and optimization opportunities from observation and causal evidence.

Later previews — Autonomous candidate generation and evolution

The final architecture still aims for:

Observe
↓
Discover
↓
Identify
↓
Diagnose
↓
Generate hypotheses
↓
Create candidates
↓
Experiment
↓
Measure
↓
Accept / reject / quarantine
↓
Remember
↓
Compare
↓
Improve
↓
Combine
↓
Correct
↓
Repeat

without requiring an external AI service to operate.

The safety requirements remain the same:

Autonomy should increase what Adaptive Optimization can discover.

It should not reduce the evidence required before Adaptive Optimization is allowed to trust a change.

Current status

This preview continues directly from the Candidate Knowledge milestone announced in the previous release.

Adaptive Optimization can now move through a much larger portion of its intended future architecture:

Observe
↓
Identify
↓
Diagnose
↓
Experiment
↓
Measure
↓
Roll back
↓
Evaluate
↓
Create a trustworthy causal fact
↓
Persist it exactly once
↓
Preserve detailed context and measured effects
↓
Combine many causal facts into contextual Candidate Knowledge

The new Candidate Knowledge system is still deliberately isolated from runtime optimization decisions.

That is the next safety boundary.

AO now has the beginning of the memory required to distinguish between:

an optimization that worked once

and:

an optimization that repeatedly works under known conditions, across known targets and environments, without hiding contradictory or unsafe evidence.

The next challenge is making that knowledge persistent, rebuildable, and eventually useful to a modern candidate lifecycle.

Adaptive Optimization is no longer only building a history of its experiments.

It is beginning to understand the patterns inside that history.