What's new since the previous preview

The previous preview focused heavily on one major transition:

Can Adaptive Optimization legitimately earn the right to keep an optimization active?

Since then, the architecture has moved substantially beyond that boundary.

Adaptive Optimization now contains much more of the complete autonomous lifecycle required to:

generate
↓
experiment
↓
learn
↓
repair
↓
promote
↓
trust
↓
monitor
↓
revoke
↓
quarantine
↓
replace
↓
clean up
↓
repair again

without collapsing those responsibilities into one unsafe automatic path.

This preview contains one of the largest expansions of Adaptive Optimization's autonomous architecture so far.

Generated strategies are no longer limited to a fixed optimization list

Adaptive Optimization now contains a dedicated generative strategy model.

Generated strategies have their own:

• canonical identity;
• StrategySpec;
• fingerprint;
• lineage;
• provenance;
• safety metadata;
• rollback requirements;
• binding state;
• applicability;
• lifecycle;
• causal evidence.

Generated strategy families are not treated as a permanently closed list.

The architecture is designed so that AO can reason about strategies produced dynamically rather than only developer-written optimization entries.

This is an important step toward the original goal of Adaptive Optimization:

optimization discovery instead of only optimization configuration.

Strategy mutation is now structural

Generated strategies can now evolve through more than parameter changes.

The architecture supports bounded mutation such as:

• parameter mutation;
• context specialization;
• adding optimization primitives;
• removing primitives;
• reordering primitives;
• bounded structural changes.

Strategies can also be composed from multiple parent candidates under explicit limits.

This allows descendants to differ structurally from their parents rather than being only slightly different configurations.

Generated strategies have lineage

Every generated descendant can preserve where it came from.

Lineage allows AO to distinguish:

original candidate
↓
mutation
↓
descendant
↓
corrective descendant
↓
future replacement

without pretending each candidate appeared independently.

This becomes especially important when a strategy later fails.

AO can preserve:

• the successful history;
• the harmful history;
• the parent;
• the corrective child;
• the reason the new strategy exists.

Generated hypotheses now have a dedicated bridge

Adaptive Optimization now has dedicated architecture connecting:

observed optimization questions

to:

generated optimization hypotheses

and then toward:

generated strategy intent.

The system also explicitly supports:

NO_HYPOTHESIS

when current observations do not justify creating something.

AO is not required to invent an optimization simply because the generative system was invoked.

Insufficient observation now fails closed

The runtime hypothesis probe can explicitly return:

INSUFFICIENT_OBSERVATION

with reasons such as:

SOURCE_INSUFFICIENT.

In that state AO produces:

• no generated preview;
• no registration;
• no fabricated evidence;
• no execution authority.

This is intentional.

The generative architecture is designed around:

no evidence → no invented optimization.

Generated candidates now have durable identity and registry state

Generated candidates can now be represented in a dedicated registry.

This gives dynamically created strategies durable candidate identity rather than leaving them as transient runtime ideas.

The generated registry preserves enough state for later systems to reason about:

• which candidate exists;
• where it came from;
• whether it is current;
• whether it has already been registered;
• whether it has evolved;
• whether a descendant already exists.

Generated strategies can enter the existing experiment architecture

A generated strategy is not given physical authority simply because it was generated.

Generated candidates must still pass through bounded experimental control.

The architecture now includes bridges that allow generated strategies to use the existing safe experiment lifecycle:

generated candidate
↓
opportunity
↓
selection
↓
Admission
↓
reservation
↓
ARM
↓
APPLY
↓
measurement
↓
rollback
↓
causal result

Generated strategies therefore do not bypass the experiment safety model.

Generated strategies own their own causal evidence

A generated child does not automatically inherit positive evidence from its parent.

A corrective descendant begins with its own evidence history.

The system preserves the distinction between:

parent knowledge

and:

child proof.

This prevents AO from creating a descendant and immediately treating it as proven simply because a related strategy succeeded previously.

Multi-generation evolution is now bounded

Adaptive Optimization can now reason across multiple generations of strategy evolution.

The evolution controller is explicitly bounded.

Limits exist around:

• additional generations;
• descendants;
• experiments;
• repeated failures;
• inconclusive outcomes;
• duplicate/stale candidates;
• simultaneous active candidates;
• concurrent experiments.

The goal is autonomous evolution without unbounded recursion.

Regression can now trigger self-healing

Adaptive Optimization now has dedicated generated-strategy self-healing architecture.

When a strategy produces a sufficiently harmful causal regression, AO can preserve that failure and reason about a corrective descendant.

The intended process is:

harmful candidate
↓
rollback
↓
quarantine
↓
preserve negative evidence
↓
diagnose regression
↓
generate corrective intent
↓
create corrective descendant
↓
retest

The harmful parent is not silently rewritten into a good strategy.

Autonomous quarantine now has durable authority

Adaptive Optimization can now quarantine an exact harmful candidate through an explicit autonomous authority path.

Quarantine is:

• durable;
• exactly-once;
• replay-safe;
• concurrency-safe;
• provenance-aware;
• recoverable after interrupted receipt persistence.

The architecture uses an explicit autonomous quarantine provenance rather than disguising the operation as manual authority.

A quarantine event does not grant release authority.

Corrective descendants remain separate from quarantined parents

When AO creates a repair candidate, the harmful parent remains quarantined.

The corrective child:

• receives a distinct CandidateId;
• keeps exact lineage;
• does not inherit quarantine;
• does not inherit trust;
• does not inherit the parent's causal evidence as its own.

This preserves the meaning of both strategies.

Corrective descendants can re-enter the safe experiment pipeline

A newly created repair candidate can now return through the normal safe candidate pipeline.

The child can reach:

first observable trial
↓
proposal
↓
selection
↓
reservation

without automatically becoming armed or executed.

The re-entry architecture reuses the existing Admission and experiment systems rather than creating a second experimental architecture.

Corrective strategies can complete controlled experiments

Corrective descendants can now perform bounded experimental cycles using the existing experiment infrastructure.

A corrective child can:

• reserve;
• ARM;
• APPLY temporarily;
• produce its own causal result;
• roll back;
• finalize evidence.

The harmful parent remains quarantined throughout the process.

Successful repairs now have explicit governance

Adaptive Optimization now distinguishes between:

• a promising repair;
• a repair that needs more evidence;
• a failed repair;
• a repair ready for promotion review.

One successful experiment is not automatically enough to create long-term authority.

This allows AO to accumulate evidence rather than treating every positive result as final.

Corrective promotion is now durable

A corrective child that legitimately passes promotion review can now move through:

AVAILABLE
↓
EXPERIMENTAL

through a dedicated productive promotion authority.

The transition is:

• durable;
• exactly-once;
• replay-safe;
• concurrency-safe;
• scope-aware;
• evidence-bound.

The parent remains quarantined.

Promotion does not automatically grant:

• TRUSTED;
• release;
• execution;
• permanent application.

Runtime side is now part of optimization authority

Modern candidate authority now explicitly distinguishes:

• CLIENT
• INTEGRATED_SERVER
• DEDICATED_SERVER
• CROSS_SIDE

when applicable.

Historical ambiguous side information remains:

UNKNOWN

rather than being silently mapped to another runtime.

This prevents knowledge learned on one side from automatically becoming authority on another.

Trust is now scope-bound

One of the most important architecture changes in this preview is that:

TRUSTED no longer needs to mean globally trusted everywhere.

Adaptive Optimization can now represent trust together with an exact authority scope.

For example:

TRUSTED
+
context:B | CLIENT

does not imply:

TRUSTED globally.

The durable lifecycle can preserve:

• exact context;
• runtime side;
• scope identity;
• scope health;
• provenance.

Historical TRUSTED authority is not rewritten

Older TRUSTED lifecycle events did not contain the new authoritative scope representation.

Adaptive Optimization does not reinterpret those historical events as globally scoped authority.

Instead, historical trust without authoritative scope becomes:

TRUSTED
+
scope = UNKNOWN

for new scope-aware consumers.

Historical lifecycle meaning remains intact.

Trust requires stronger evidence than experimentation

Adaptive Optimization now contains dedicated:

• Trust Readiness;
• Trust Review;
• Productive Trust Authority.

A strategy becoming EXPERIMENTAL is not enough to become TRUSTED.

Trust evaluation considers things such as:

• repeated causal improvement;
• evidence ownership;
• repeatability;
• scope breadth;
• late negative evidence;
• correctness;
• safety;
• rollback;
• recovery;
• runtime side;
• exact context.

A candidate may remain EXPERIMENTAL indefinitely if stronger trust evidence is not earned.

Corrective children can now legitimately become TRUSTED

A corrective child that satisfies the trust chain can now transition through:

EXPERIMENTAL
↓
TRUSTED

using a dedicated autonomous corrective trust authority.

This transition is:

• exactly-once;
• durable;
• scope-bound;
• provenance-aware;
• recovery-safe.

The quarantined parent remains quarantined.

Trusting the repair does not forgive the harmful parent.

Trusted strategies are now monitored after promotion

TRUSTED is no longer intended to mean:

trusted forever.

Adaptive Optimization now contains long-term regression surveillance for trusted strategies.

New causal evidence can be compared against existing trust.

The surveillance architecture can identify:

• late regressions;
• correctness failures;
• safety failures;
• rollback degradation;
• recovery degradation;
• material compatibility problems;
• scope-specific regressions.

Trust can be revoked only where it actually failed

Adaptive Optimization now supports scope-bound trust revocation.

If a strategy is trusted in multiple valid scopes and one scope regresses, AO can preserve the trust that is still valid.

For example:

CLIENT + DEDICATED_SERVER trusted

and later:

CLIENT regression

can become:

DEDICATED_SERVER trusted

without automatically destroying unrelated valid authority.

Full trust revocation can return a strategy to EXPERIMENTAL

If no trusted scope remains after a legitimate revocation, AO can remove active trust without automatically quarantining the candidate.

The strategy can return to:

EXPERIMENTAL

when that is the existing valid lifecycle representation.

This preserves the difference between:

performance regression

and:

materially unsafe behavior.

Serious trusted-strategy failures can trigger quarantine

Some regressions are too severe for simple trust revocation.

Material problems involving:

• correctness;
• safety;
• unsafe rollback;
• unsafe recovery;
• cross-scope harm;
• compatibility corruption;

can now justify a dedicated trusted-strategy quarantine path.

Adaptive Optimization can durably perform:

TRUSTED
↓
QUARANTINED

exactly once.

Previous trust history and causal evidence remain auditable.

Quarantined trusted strategies can self-heal again

A strategy that was once trusted and later failed is not the end of the evolutionary chain.

AO can now review whether that quarantined former-TRUSTED strategy is eligible for another bounded corrective cycle.

The process can derive a new corrective re-entry intent without:

• restoring trust;
• releasing the parent;
• executing the strategy;
• inheriting old evidence.

Corrective re-entry is bounded

The current corrective re-entry architecture allows exactly one new bounded descendant intent per authorized cycle.

This prevents:

• recursive descendant explosions;
• uncontrolled strategy generation;
• duplicate repairs;
• concurrent ambiguous descendants.

The new repair must still earn its own evidence.

A new corrective descendant can now be synthesized and registered

Adaptive Optimization can now take an exact corrective re-entry intent and produce one new bounded corrective descendant.

The new child receives:

• a distinct CandidateId;
• a distinct StrategySpec;
• exact lineage;
• durable registration;
• zero inherited evidence;
• zero inherited trust;
• no inherited quarantine;
• no execution authority.

The original strategy remains quarantined.

Corrective re-entry returns to the existing pipeline

The new descendant does not receive a special shortcut.

It is routed back through the existing safe pipeline.

The current productive re-entry bridge reaches:

registered child
↓
Admission
↓
selection
↓
reservation
↓
pending = true
↓
armed = false

The strategy is not executed merely because it was created as a repair.

Authoritative recapture is now part of re-entry

The latest architecture also introduces authoritative recapture before later lifecycle decisions.

This is important because long autonomous chains must not continue operating from stale snapshots.

Before moving forward, AO can recapture current authoritative state including:

• candidate identity;
• registration;
• evidence;
• lifecycle;
• lineage;
• context;
• runtime side;
• scope;
• relevant provenance.

The next lifecycle decision therefore reasons about current state rather than assuming that an earlier decision remains valid forever.

Harmful parents can now become SUPERSEDED

A quarantined parent is not automatically released after a repair succeeds.

Instead, AO can determine whether an exact trusted corrective descendant completely covers the harmful scope of the parent.

If full coverage is demonstrated, the parent can become eligible for:

SUPERSEDED

rather than being treated as safe again.

This preserves the meaning:

the old strategy was harmful and has been replaced.

SUPERSEDED is now durable

Adaptive Optimization can now durably perform:

QUARANTINED
↓
SUPERSEDED

for an exact harmful parent after full trusted corrective coverage.

The transition is exactly-once.

It does not:

• release the parent;
• rehabilitate it;
• execute it;
• delete its evidence;
• delete its lineage.

The harmful history remains part of AO's long-term knowledge.

Adaptive Optimization now distinguishes knowledge from garbage

Once a harmful strategy has been replaced, not every artifact associated with that strategy needs to live forever.

However, AO cannot simply delete everything belonging to an old candidate.

The new retention architecture classifies information into categories such as:

• authoritative permanent;
• causal history permanent;
• lineage permanent;
• reconstructible derived;
• auxiliary reviewable;
• unknown retain.

This creates a foundation for safe long-term maintenance.

Causal history is not garbage

Adaptive Optimization explicitly preserves:

• harmful causal evidence;
• lifecycle history;
• quarantine provenance;
• trust provenance;
• supersession provenance;
• lineage;
• corrective relationships.

These are not deleted merely because a newer strategy is better.

They prevent AO from forgetting why an old optimization was rejected.

Strategy GC is now item-level

Garbage collection is not performed as:

delete everything old.

Instead, AO reviews exact artifacts individually.

Only items already classified as:

• reconstructible derived;
• non-authoritative auxiliary;

may enter productive GC review.

Unknown or authoritative items fail closed.

Productive GC is now exactly-once

Adaptive Optimization can now remove one exact pre-reviewed artifact through a bounded productive GC authority.

The GC path does not allow:

• directory sweeps;
• wildcard deletion;
• age-based cleanup;
• cascading deletion;
• unrelated file deletion.

The request identifies one exact artifact.

Derived state can be reconstructed after GC

For reconstructible artifacts, AO can prove that equivalent semantic state can be rebuilt from durable authoritative inputs.

The reconstruction does not need to reproduce irrelevant transient details such as timestamps.

It must reproduce the same semantic identity.

Post-GC integrity is verified

After productive GC, Adaptive Optimization can verify that authoritative knowledge still exists.

Verification includes:

• lifecycle;
• causal history;
• trust;
• quarantine;
• supersession;
• lineage;
• registry identity;
• trusted scope.

If any authoritative fact changes unexpectedly:

AO fails closed.

GC failures are classified

Adaptive Optimization can now distinguish different post-GC failures such as:

• reconstruction mismatch;
• missing reconstruction inputs;
• hidden auxiliary dependency;
• lifecycle integrity loss;
• causal history loss;
• lineage loss;
• trust scope loss;
• quarantine provenance loss;
• supersession provenance loss;
• GC journal corruption;
• unrelated mutation.

This gives GC its own failure diagnosis rather than treating every cleanup problem the same way.

Unsafe GC paths can now be quarantined

A GC path that proves unsafe can now be excluded from future automatic reuse.

Adaptive Optimization can durably quarantine an exact automatic GC path after verified integrity risk.

This quarantine is:

• exactly-once;
• durable;
• identity-bound;
• narrowly scoped.

It does not globally disable GC.

Other unrelated GC paths remain available.

GC quarantine does not delete or repair anything

Quarantining an unsafe cleanup path does not:

• delete more files;
• rewrite lifecycle;
• repair history;
• synthesize evidence;
• execute strategies.

It only removes automatic permission to reuse that unsafe GC path until future review.

Exactly-once authority is expanding across AO

Several modern productive boundaries now use explicit deterministic request identities and durable recovery patterns.

This includes architecture around:

• quarantine;
• corrective promotion;
• corrective trust;
• supersession;
• trust revocation;
• trusted-strategy quarantine;
• productive GC;
• GC-path quarantine.

Replay does not mean:

perform the action again.

It means:

ALREADY_COMMITTED
or
NO_OP

when the same exact request is already durable.

Concurrency is being treated as an authority problem

Modern AO increasingly tests concurrent attempts explicitly.

For productive exactly-once boundaries, concurrent requests are expected to produce:

one winner

rather than duplicate durable mutations.

This is important for an autonomous optimizer where multiple observations or workers may reach related decisions at nearly the same time.

Restart recovery continues to preserve intent instead of replaying work

Modern durable paths continue following the rule:

recover durable state; do not blindly replay physical operations.

When a durable event exists but a secondary receipt is missing, recovery can reconstruct the receipt without creating a second authoritative event.

Orphaned or mismatched receipts fail closed.

Async lifecycle hardening has also increased

Recent full validation exposed a reproducible asynchronous snapshot cleanup race under Windows temporary-directory cleanup.

The functional assertions completed successfully, but background snapshot work could still recreate files while JUnit attempted to remove the temporary directory.

This was treated as a real lifecycle/quiescence problem rather than hidden with:

• arbitrary sleeps;
• ignored tests;
• blind cleanup retries.

The architecture is being hardened so shutdown means:

stop new work
↓
drain or safely cancel owned work
↓
reach quiescence
↓
return

This work also supports the larger requirement that AO itself must not create unnecessary background contention or self-lag.

Validation coverage has grown substantially

The modern offline validation suite has expanded significantly during this development cycle.

Recent validated baselines have crossed:

1000+ automated test bodies

covering more than:

130 dedicated suites

across modern lifecycle, authority, generated strategies, self-healing, persistence, recovery and bounded autonomy.

Passing offline tests does not replace runtime validation.

However, the larger suite provides much stronger regression protection before AO reaches Minecraft.

The current runtime generative probe remains intentionally conservative

The current public runtime hypothesis probe may still return:

INSUFFICIENT_OBSERVATION

and:

SOURCE_INSUFFICIENT

without producing a strategy.

That is not treated as a failure.

The probe currently remains intentionally conservative while the complete real-runtime observation → hypothesis → synthesis wiring continues to mature.

AO will not generate fake optimization evidence simply to make a runtime validation look successful.

Runtime discovery is still being connected to the full generative loop

The generative architecture is substantially more advanced than the current public runtime probe.

The remaining runtime integration must connect real observed relationships into:

runtime observation
↓
material relationship
↓
optimization question
↓
hypothesis
↓
strategy synthesis
↓
registration
↓
controlled experiment
↓
causal benchmark
↓
learning

without fabricating proposals or experimental cost.

This remains an important milestone after this preview.

This preview is still a preview

This release contains a very large architectural expansion.

It is not being presented as the final form of Adaptive Optimization.

Several major systems are still being developed or hardened.

Real-time optimization benchmarking is being designed

A future Adaptive Optimization build is intended to contain a dedicated real-time optimization benchmark.

The goal is not a one-time synthetic benchmark.

Each optimization should eventually accumulate its own performance evidence during real operation.

Conceptually:

baseline
↓
optimization
↓
continuous bounded measurement
↓
causal attribution
↓
net performance value
↓
long-term evidence

The benchmark is intended to consider metrics such as:

• frame time;
• FPS;
• stutter;
• TPS;
• MSPT;
• memory;
• GC;
• loading;
• relevant I/O;
• AO's own overhead.

This system is not yet considered complete in this preview.

Adaptive Optimization must also measure itself

AO is not allowed to claim success by making Minecraft faster while its own infrastructure creates stutter.

Future real-time benchmarking and self-monitoring are intended to distinguish:

workload cost

from:

optimization benefit

from:

Adaptive Optimization's own overhead.

Profiling, persistence, diagnostics, snapshots, workers, experiments and benchmarks themselves must remain bounded.

Self-healing will also apply to AO's own overhead

Adaptive Optimization's self-healing model is intended to include self-lag.

If AO itself causes:

• frame spikes;
• tick spikes;
• excessive allocations;
• synchronous I/O;
• worker bursts;
• lock contention;
• profiling overhead;

that behavior should eventually be attributable and correctable.

However, this protection must remain proportional.

AO should not become slower and more complex because of excessive defensive layers intended to prevent tiny theoretical overheads.

Optimization strategies are intended to become much more expressive

The final generative goal is not:

change configuration values until performance improves.

Adaptive Optimization is intended to create increasingly structural optimization strategies.

A future strategy may behave more like a small specialized optimization subsystem with its own:

• triggers;
• state;
• scheduling;
• batching;
• buffers;
• caching;
• invalidation;
• control flow;
• scope;
• rollback;
• measurement.

The fixed part should be the safe execution substrate.

The optimization topology itself should be able to evolve.

Adaptive Optimization is intended to create new optimization tools

The long-term architecture is not intended to permanently restrict AO to combining a closed set of developer-written optimization techniques.

The goal is eventually:

observe Minecraft
↓
discover an unresolved optimization pattern
↓
design an optimization structure
↓
validate it
↓
measure it
↓
abstract successful behavior
↓
create reusable internal optimization tools

Those tools may then become building blocks for later strategies.

This is closer to the process followed by optimization-mod developers:

observe
↓
understand
↓
design
↓
implement
↓
benchmark
↓
maintain

rather than only:

select a preset optimization.

New tools must still be safe

Adaptive Optimization is not intended to generate unrestricted arbitrary Java or bytecode and immediately inject it into Minecraft.

New optimization tools need bounded execution contracts.

Future synthesized tools are expected to preserve:

• semantic specification;
• input/output contracts;
• side/runtime scope;
• correctness invariants;
• resource budgets;
• rollback;
• lineage;
• provenance;
• causal evidence;
• real-time benchmarking.

The goal is maximum autonomy compatible with correctness.

Adaptive Optimization may eventually grow its own optimization vocabulary

The initial primitives should not permanently define everything AO can ever discover.

Successful structures may eventually be abstracted into new reusable operators.

This creates the possibility that AO's optimization vocabulary grows over time.

The fixed substrate provides safe capabilities.

The solutions built above that substrate can evolve.

Small improvements are not automatically valuable

Future optimization evaluation will also distinguish:

measurable meaningful improvement

from:

statistical noise or complexity for negligible gain.

A strategy should not survive merely because it improves one metric by a tiny amount.

AO is intended to consider:

• net benefit;
• repeatability;
• uncertainty;
• frame/tick stability;
• correctness;
• memory;
• GC;
• overhead;
• complexity;
• maintenance risk.

A substantially simpler optimization may be preferable to a much more complex one that provides almost the same result.

Complexity itself has a cost

An autonomous optimizer that continually accumulates small defensive layers, caches, workers and special cases can eventually become its own performance problem.

Adaptive Optimization is therefore moving toward another long-term rule:

improvement does not mean accumulation.

A new strategy or protection should replace existing behavior only when it demonstrates enough net value to justify its cost.

Successful complex strategies may eventually be candidates for simplification and compression.

The complete self-correcting loop is becoming visible

The modern architecture is increasingly approaching:

Observe
↓
Discover
↓
Attribute
↓
Diagnose
↓
Generate
↓
Experiment
↓
Benchmark
↓
Learn
↓
Promote
↓
Trust
↓
Own
↓
Monitor
↓
Detect regression
↓
Revoke or quarantine
↓
Generate corrective descendant
↓
Supersede harmful strategy
↓
Safely clean derived state
↓
Re-enter the optimization pipeline
↓
Repeat

This is much closer to the original Adaptive Optimization goal.

What this preview represents

The previous preview demonstrated that:

Adaptive Optimization can safely borrow physical control.

The next architecture began asking:

Can Adaptive Optimization legitimately earn the right to keep that control?

This preview goes substantially further.

Adaptive Optimization now has much stronger architecture for:

• generated strategies;
• structural mutation;
• multi-generation evolution;
• self-healing;
• autonomous quarantine;
• corrective descendants;
• durable corrective promotion;
• scope-bound TRUSTED authority;
• long-term trust surveillance;
• scope-bound trust revocation;
• trusted-strategy quarantine;
• corrective re-entry;
• durable parent supersession;
• safe strategy-related GC;
• post-GC integrity verification;
• quarantine of unsafe GC paths;
• exactly-once autonomous lifecycle authority;
• restart/recovery safety.

The architecture is increasingly capable not only of finding an optimization...

but of managing the full lifetime of that optimization.

The most important change

Adaptive Optimization is moving from:

"Can this candidate improve Minecraft?"

toward:

"Can AO create, prove, maintain, repair, replace and eventually retire its own optimizations safely?"

That is the direction represented by this preview.

The project is still evolving.

Real-time benchmarking, stronger open-ended optimization synthesis, self-overhead optimization and the final runtime integration of the full generative loop remain active development goals.

But the system underneath those goals is now significantly more capable than the previous public preview.