What's new since the last development update

The previous update ended with Adaptive Optimization approaching one of its most important goals:

connecting real runtime discovery to the complete generative optimization lifecycle.

That architecture has now advanced significantly.

The modern generated-strategy pipeline is no longer only a collection of isolated offline components.

Adaptive Optimization now contains bridges connecting much more of the complete path:

real runtime observation
↓
optimization question
↓
generated hypothesis
↓
strategy preview
↓
durable candidate registration
↓
AVAILABLE lifecycle
↓
opportunity detection
↓
Admission
↓
reservation
↓
ARM
↓
physical APPLY
↓
measurement
↓
rollback
↓
recovery
↓
causal finalization
↓
Candidate Knowledge
↓
modern decision
↓
promotion eligibility
↓
EXPERIMENTAL

This is a major step toward making generated optimization strategies participate in the same real architecture as the rest of modern AO.

Runtime observation can now feed the generative system

Earlier runtime hypothesis validation still used deliberately incomplete placeholder input.

That meant the public runtime probe correctly returned:

INSUFFICIENT_OBSERVATION

even though the deeper generative architecture already existed.

That boundary has now been improved.

Adaptive Optimization now contains a read-only canonical adapter capable of translating existing runtime detection and assessment information into input understood by the generative question system.

The adapter does not manufacture opportunities.

Only a legitimately observed canonical runtime condition can produce a material relationship.

Unsupported, stale, contradictory or cross-side input still fails closed.

Conceptually:

runtime detection
↓
canonical observed relationship
↓
optimization question

rather than:

validation command
↓
hardcoded synthetic relationship

Runtime side remains preserved through generation

The new runtime-to-generative bridges preserve the exact runtime side associated with the observation.

Generated reasoning therefore continues to distinguish:

• CLIENT;
• INTEGRATED_SERVER;
• DEDICATED_SERVER;
• CROSS_SIDE;

where applicable.

A relationship observed on one side is not silently converted into evidence for another.

Cross-side mismatch fails closed.

Real runtime questions can now reach hypothesis generation

Canonical runtime questions can now enter the existing hypothesis-generation architecture directly.

The new bridge preserves:

• source observation identity;
• target identity;
• canonical context;
• runtime side;
• hypothesis identity;
• logical fingerprint.

Equivalent inputs remain deterministic.

Unsupported constraints can still produce:

NO_HYPOTHESIS

rather than forcing AO to generate a strategy.

This preserves an important rule:

generation is optional; correctness is not.

Generated hypothesis previews can now become durable candidates

A valid generated preview can now cross the boundary from:

temporary generative reasoning

to:

durable candidate identity.

Adaptive Optimization now reuses the existing generated candidate registry to persist an exact generated candidate.

The registration preserves:

• CandidateId;
• StrategySpec;
• fingerprint;
• hypothesis identity;
• preview identity;
• transformation identity;
• registration identity;
• lineage.

Replay of the same exact generated candidate is idempotent.

Concurrent attempts do not create multiple copies.

Generated candidate provenance is now durable

Closing the runtime registration path exposed an important missing capability.

The original generated registration format preserved many identities, but did not durably preserve enough runtime provenance to reconstruct exactly where the candidate came from after restart.

A new additive registration schema now preserves:

• canonical runtime context;
• runtime side;
• adapter/source identity.

This allows a generated candidate to survive reopen without losing the exact runtime provenance that justified its creation.

Historical registrations remain compatible.

Older registrations without this provenance remain:

UNKNOWN / ABSENT

rather than having new meaning invented retroactively.

Generated registrations now survive authoritative recapture

A generated candidate can now be reopened and recaptured with its exact:

• CandidateId;
• StrategySpec;
• fingerprint;
• registration;
• lineage;
• context;
• side;
• source provenance.

If any of those identities drift before the next decision:

the chain stops.

AO does not assume an old generative decision remains current forever.

Generated candidates can now enter the real opportunity pipeline

A durable generated candidate can now be fed into the existing opportunity architecture.

No separate generated-strategy opportunity policy was created.

Instead, AO recaptures the generated candidate and delegates to the already established opportunity source.

The result may still be:

NO_OPPORTUNITY

and that remains completely valid.

Generated candidates do not receive special treatment simply because AO created them.

Generated candidates can now reach Admission

A valid generated opportunity can now proceed into the existing modern Admission architecture.

The bridge remains read-only at this stage.

Possible results remain:

• ALLOW;
• BLOCK;
• DEFER.

An ALLOW does not itself execute anything.

This preserves the existing separation:

opportunity
≠
Admission
≠
reservation
≠
ARM
≠
APPLY

Generated candidates can now create real reservations

An exact Admission ALLOW can now create a reservation using the existing lease/reservation system.

The reservation is:

• identity-bound;
• replay-safe;
• concurrency-safe;
• durable where required;
• restart-aware.

Replay does not create a second reservation.

Concurrent attempts produce one winner.

A reservation still does not grant physical execution.

Restart invalidates transient generated reservations safely

Transient pending reservations are not blindly replayed after Minecraft restarts.

When reopened under the wrong transient state, the reservation can reconcile into:

CANCELLED_RESTART

rather than pretending the previous runtime authority still exists.

This preserves another important rule:

durable knowledge survives restart; transient execution authority does not.

Generated candidates can now reach ARM

A valid pending reservation can now enter the existing ARM boundary.

AO performs a fresh recapture before granting the next stage.

Stale, cancelled, mismatched or restart-invalid reservations cannot ARM.

Replay and concurrency remain bounded to at most one successful ARM transition.

Even after ARM:

• no physical APPLY has necessarily occurred;
• no evidence has been created;
• no trust has been granted.

Generated candidates can now reach physical APPLY preflight

An ARMED generated candidate can now enter the real existing physical APPLY preflight.

This includes existing checks around:

• current ARM state;
• runtime coordinator state;
• freshness;
• physical readiness;
• quiescence;
• ownership constraints.

A successful result means:

READY_TO_APPLY

not:

APPLIED.

The distinction remains explicit.

Generated candidates can now acquire experiment start authority

READY_TO_APPLY can now cross into the existing experiment-start authority.

The start boundary consumes the valid ARM and enters the experiment's:

PRE

phase.

Importantly, this still does not perform the physical treatment inside the authority decision itself.

This keeps:

permission to start

separate from:

the physical mutation.

Generated candidates can now physically APPLY

One of the largest changes in this development cycle is that a generated candidate can now reach the existing physical experiment actuator.

The bridge validates the exact active PRE identity and then advances through the existing Experiment Coordinator until the first real physical APPLY.

The path captures the exact physical baseline before mutation.

A successful APPLY marks the treatment as physically applied.

It does not yet manufacture a causal result.

Replay does not apply the same generated experiment again.

Concurrent attempts do not create a second physical winner.

Physical failure remains rollback-safe

The generated APPLY path also preserves the existing rollback guarantees.

If the physical operation fails partially, AO does not leave an ambiguous treatment behind.

The existing recovery/rollback path restores the captured neutral baseline.

Generated execution therefore inherits the same physical safety principles already established for controlled modern experiments.

Generated experiments now reach real measurement

After a physical APPLY, generated experiments can now continue through the existing measurement architecture.

A useful implementation detail was discovered here:

the existing Experiment Coordinator closes the experiment window and begins rollback in the same tick.

Rather than splitting or weakening that CLOSED architecture, the generated bridge was adapted to respect the real boundary.

The resulting path is:

APPLIED
↓
experiment measurement
↓
measurement window closes
↓
initial rollback begins
↓
physical baseline restored

This reuses the coordinator exactly as designed.

Measurement does not leave generated treatments active

Once enough experimental measurements have been captured, the generated experiment begins rollback automatically.

The optimization is therefore still temporary.

The physical baseline is restored before the experiment proceeds deeper into evaluation.

A generated experiment cannot use measurement completion as an excuse to leave itself enabled.

Generated experiments now pass through post-rollback settling

After rollback, AO can now advance the exact generated experiment through the existing settling phase.

The baseline is revalidated while the runtime stabilizes.

The experiment then reaches:

RECOVERY

without yet fabricating a final causal interpretation.

Wrong identities, stale state or baseline drift still block progression.

Generated experiments now complete recovery

The recovery phase can now be completed through the existing Experiment Coordinator as well.

Another important CLOSED boundary was discovered here:

the final recovery sample, recovery-window closure, transition to EVALUATING and causal evaluation occur inseparably inside the same coordinator tick.

AO again preserves the existing architecture rather than splitting it artificially.

The real generated path therefore becomes:

RECOVERY sampling
↓
recovery window closes
↓
EVALUATING
↓
existing evaluateAndFinish()
↓
causal result

Generated strategies can now produce a real causal result

This is one of the most significant milestones in the current preview architecture.

A generated candidate can now travel through:

physical treatment
↓
measurement
↓
rollback
↓
recovery
↓
causal evaluation

and produce exactly one causal result through the existing experiment system.

Replay and concurrency do not create duplicate causal finalizations.

The result still does not automatically create trust or permanent activation.

Physical success does not automatically become positive evidence

Adaptive Optimization explicitly preserves the actual causal verdict.

A generated experiment that physically executes successfully can still produce:

• positive evidence;
• negative evidence;
• inconclusive evidence;
• insufficient evidence;

depending on what was actually measured.

AO does not convert:

"the actuator worked"

into:

"the optimization worked."

That distinction is now preserved through the generated pipeline.

Generated causal results now enter Candidate Knowledge

The finalized causal record can now be linked back into the durable causal ledger and existing Candidate Knowledge system.

The generated candidate's knowledge can therefore be rebuilt from the same causal architecture as other modern candidates.

Replay or reopen does not duplicate the experiment semantically.

Negative and inconclusive classifications retain their original meaning.

Generated candidates now receive initial lifecycle state

Another missing boundary was discovered after causal knowledge became available.

A generated registration did not necessarily have authoritative lifecycle state yet.

Adaptive Optimization now reuses the existing lifecycle materializer and reducer to represent a newly generated registered candidate as:

AVAILABLE

without manufacturing a transition event.

The empty authoritative lifecycle event log naturally reduces to the already defined initial state.

This means:

registration creates existence; it does not create promotion.

AVAILABLE generated candidates can now enter modern decision logic

With lifecycle authority available, a generated candidate can now enter the existing:

• Coherent Decision Input;
• Candidate Resolution;
• Applicability;
• Modern Candidate Selector.

The modern selector therefore no longer needs to reject the candidate simply because authoritative lifecycle state is absent.

However:

AVAILABLE

does not mean:

SELECTABLE

and does not imply promotion.

The result may still honestly remain:

INSUFFICIENT_INFORMATION
or
NO_ACTION.

Generated candidates can now produce promotion eligibility facts

Modern decision evidence can now be translated into a bounded promotion eligibility result.

The current mapping preserves the existing meaning:

SELECTABLE
→ ELIGIBLE

EXCLUDED
→ NOT_ELIGIBLE

INSUFFICIENT_INFORMATION
→ INSUFFICIENT

Positive and negative evidence counts remain unchanged.

No evidence is rewritten simply to obtain promotion.

Generated candidates can now build a real promotion request

An ELIGIBLE generated candidate can now construct the existing modern decision request for the minimum valid lifecycle transition:

AVAILABLE
↓
EXPERIMENTAL

This remains a preview until productive authority commits it.

NOT_ELIGIBLE and INSUFFICIENT produce no transition request.

Generated candidates can now become EXPERIMENTAL productively

The generated promotion request can now be handed to the existing productive authority and lifecycle event store.

A valid exact request can perform:

AVAILABLE
↓
EXPERIMENTAL

with the established exactly-once behavior.

The transition survives reopen.

Replay becomes:

ALREADY_COMMITTED

rather than creating another lifecycle event.

Concurrency still produces one winner.

This is a major milestone:

a strategy originating from the generative pipeline can now reach the real modern EXPERIMENTAL lifecycle through existing authority.

EXPERIMENTAL generated candidates can now reach trust readiness

Once EXPERIMENTAL, a generated candidate can now be reviewed using the general modern decision architecture for:

EXPERIMENTAL
↓
TRUSTED

readiness.

The review distinguishes:

• ELIGIBLE;
• NOT_ELIGIBLE;
• INSUFFICIENT.

A positive experiment is not automatically sufficient.

Contradictory negative evidence remains negative.

Insufficient evidence remains insufficient.

No TRUSTED commit occurs during readiness evaluation.

A new general TRUSTED scope gap was discovered

Connecting generated candidates to trust exposed another important architectural limitation.

The older general modern decision request for:

EXPERIMENTAL → TRUSTED

does not contain an explicit:

TrustedAuthorityScope.

Using it directly would create trust whose exact context/runtime-side authority could not be represented correctly.

Adaptive Optimization deliberately refuses to do that.

The current generated path can therefore identify:

TRUST_SCOPE_UNREPRESENTABLE

rather than silently creating ambiguous trust.

UNKNOWN trust scope is not treated as real authority

Historical or incomplete scope information remains:

UNKNOWN.

AO does not reinterpret:

UNKNOWN

as:

globally trusted

or as the current runtime context.

This prevents a generated optimization from accidentally gaining authority outside the exact context in which its evidence was collected.

General scope-bound TRUSTED requests now have a representation

The architecture now contains a bounded representation for a future general scope-aware TRUSTED request.

A valid request binds:

• candidate;
• registration;
• canonical context;
• runtime side;
• source identity;
• trust-readiness identity;
• TrustedAuthorityScope.KNOWN.

The identity is deterministic.

This representation currently remains non-productive.

It does not yet commit TRUSTED.

That next authority boundary remains intentionally unfinished.

Restart-required experiments now have their own durable boundary

Another major addition is explicit support for experiments that cannot safely be completed entirely within one Minecraft runtime session.

AO can now represent:

restart-required experiment intent
↓
PENDING_RESTART
↓
restart
↓
authoritative recapture
↓
exact resume validation
↓
continued bounded experiment
↓
finalization

The experiment identity is deterministic and durable.

Restart-required experiments do not blindly replay

After restart, AO revalidates:

• CandidateId;
• StrategySpec;
• fingerprint;
• registration;
• lineage;
• target;
• context;
• runtime side;
• lifecycle;
• restart capability intent.

If the environment no longer matches:

the experiment does not resume.

A previous pending operation is never treated as sufficient authority by itself.

Restart-required execution is exactly-once

A valid resumed experiment delegates to the existing idempotent experiment pipeline.

Recovery can distinguish between:

• durable intent;
• start requested;
• finalized state.

A previously finalized restart-required experiment cannot be physically replayed just because Minecraft restarted again.

This creates the foundation for future optimization techniques that require:

• startup state;
• bootstrap configuration;
• load-time changes;
• restart-dependent verification.

Runtime provenance now matters across the entire generated chain

The recent work exposed how important exact provenance is for autonomous optimization.

A candidate must not merely remember:

what strategy was generated.

It must also preserve:

where and why it was generated.

That includes:

• runtime context;
• side;
• source observation;
• registration;
• hypothesis;
• lineage;
• evidence;
• lifecycle.

This provenance is increasingly recaptured before every authority-changing step.

Generated strategies increasingly use the same architecture as manually known candidates

One of the most important architectural outcomes of this cycle is what AO did not create.

There is no completely separate:

generated optimization runtime.

Instead, generated candidates increasingly reuse the existing:

• registry;
• Candidate Knowledge;
• Candidate Lifecycle;
• opportunity detection;
• Admission;
• leases;
• ARM;
• Experiment Coordinator;
• causal ledger;
• modern selection;
• lifecycle authority.

This reduces duplicated policy and makes generated autonomy inherit the safety work already completed elsewhere in AO.

Early runtime testing shows a major practical improvement

Recent real gameplay testing of the current AO development line has shown a very noticeable practical improvement.

In the tested modpack, frame delivery appeared substantially more stable and FPS was noticeably higher than in earlier builds.

This is especially encouraging because the improvement is visible during normal gameplay rather than only through an offline unit test.

However, Adaptive Optimization does not yet treat a subjective runtime observation as formal benchmark evidence.

Until the new real-time benchmark architecture is complete, these results remain:

strong practical observations, not final quantified performance claims.

No fixed percentage improvement is being claimed from this test.

Adaptive Optimization is clearly active in the tested runtime

The latest runtime data shows AO actively maintaining and learning optimization state.

The current profile contains heavily exercised adaptive strategies, including COMPRESSION_PACK, with large trial histories and context-dependent promotion decisions.

Candidate Knowledge and lifecycle state are also healthy and reconstructible.

This confirms that the runtime is not simply loading AO and remaining inert.

AO is actively observing and adapting its existing optimization systems.

The latest runtime does not yet prove a newly generated autonomous strategy

The latest diagnostic data also provides an important distinction.

The current runtime snapshot reports:

runtimeGenerativeHypothesis.inputStatus = INSUFFICIENT_OBSERVATION

with:

hypothesisCount = 0

and the productive runtime generation counters currently show:

registered = 0

and:

generatedCandidatesInspected = 0.

The visible generative model candidate is currently identified as:

BUILTIN_BOOTSTRAP

with family:

NETWORK_BUFFER_PACK.

Therefore, this particular runtime session does not yet prove that AO autonomously invented and registered a brand-new strategy from runtime observation.

This distinction is intentional.

AO will not label an existing bootstrap strategy as a newly discovered optimization merely because it appears inside the generative model.

This makes the next runtime milestone much clearer

The next important runtime proof is now:

real material observation
↓
canonical optimization question
↓
generated hypothesis
↓
new StrategySpec
↓
durable registration
↓
AVAILABLE
↓
real opportunity
↓
controlled physical experiment
↓
causal evidence
↓
EXPERIMENTAL promotion

Much of that chain is now connected and offline-validated.

The remaining goal is to observe it occurring naturally inside Minecraft without fabricated input.

Offline validation has continued growing

The automated validation suite has now exceeded:

1100 test bodies

across:

153 suites

during this development line.

Recent checkpoints reached:

1125

executed tests.

The only recent full-suite anomaly was a known Windows/JUnit temporary-directory cleanup race after functional assertions had already passed.

The affected CLOSED test passed when executed independently.

AO does not hide this type of issue with arbitrary sleeps or repeated full builds.

The autonomous loop is now much closer to being physically complete

The current generated strategy architecture can now conceptually traverse:

Observe
↓
Canonicalize
↓
Generate question
↓
Generate hypothesis
↓
Create StrategySpec
↓
Register candidate
↓
AVAILABLE
↓
Detect opportunity
↓
Admission
↓
Reserve
↓
ARM
↓
APPLY
↓
Measure
↓
Rollback
↓
Recover
↓
Finalize causal evidence
↓
Build Candidate Knowledge
↓
Evaluate
↓
Promote
↓
EXPERIMENTAL
↓
Evaluate trust

This is substantially closer to the original Adaptive Optimization vision than the architecture available in the previous preview.

TRUSTED remains deliberately unfinished for general generated candidates

Corrective-child TRUSTED authority already has a dedicated scope-bound path.

General generated candidates do not yet have the equivalent productive scope-aware commit.

This is deliberate.

The system now knows enough to recognize that the old generic TRUSTED transition would lose authoritative scope.

Instead of accepting ambiguous trust, AO blocks at the boundary.

The next architecture must allow a general generated candidate to earn:

TRUSTED

while preserving exact:

• context;
• runtime side;
• scope;
• evidence;
• provenance.

Real-time benchmarking remains one of the next major systems

The current physical experiment system already performs bounded causal measurements.

The larger real-time benchmark architecture is still a separate goal.

AO is intended to eventually maintain a continuous, low-overhead performance history for each optimization during real gameplay.

This will allow it to evaluate not only:

did the experiment pass?

but:

is this optimization still producing meaningful net benefit right now?

The real-time benchmark will become part of optimization knowledge

Future optimization evidence is intended to include relevant measurements such as:

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

Sampling must remain bounded enough that benchmarking itself does not cause self-lag.

Adaptive Optimization will eventually evaluate its own cost

The system must be able to distinguish:

Minecraft workload
+
optimization effect
+
AO overhead

rather than attributing all performance changes to the candidate.

If AO's:

• profiling;
• persistence;
• snapshots;
• workers;
• experiments;
• benchmark;
• diagnostics;

begin causing measurable lag or stutter, that cost must become visible to AO itself.

Generated strategies are still intended to become much more open-ended

The current generative model already supports structural strategy representation and evolution.

The long-term goal remains larger.

AO should eventually be able to create strategies that resemble small specialized optimization subsystems rather than only parameter modifications.

A strategy may eventually contain its own combination of:

• observation;
• state;
• scheduling;
• batching;
• coalescing;
• caching;
• buffering;
• invalidation;
• adaptive control flow;
• rollback;
• measurement.

The primitive catalog is not intended to become AO's permanent imagination limit

Initial primitives provide a safe execution substrate.

They should not permanently define every optimization AO can ever discover.

Future successful structures may be abstracted into reusable internal tools.

This creates the longer-term possibility that AO can:

observe a problem
↓
design a new solution
↓
prove it
↓
abstract it
↓
add a new optimization operator to its own vocabulary
↓
reuse that tool in later strategies

This remains one of the major final goals of the project.

Adaptive Optimization is increasingly behaving like an optimization developer

The long-term development model is becoming clearer.

AO is not intended to merely ask:

"Which preset should I enable?"

The target process is closer to what an optimization-mod developer does:

observe Minecraft
↓
identify expensive behavior
↓
form a hypothesis
↓
design a solution
↓
build it
↓
test it
↓
benchmark it
↓
correct it
↓
maintain it
↓
replace it when something better exists

The difference is that AO also has dedicated systems for:

• causal evidence;
• rollback;
• quarantine;
• lineage;
• self-healing;
• trust revocation;
• supersession;
• safe GC;
• restart recovery.

The current direction

The previous update described AO as moving toward:

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

The latest work has now connected much more of the word:

create.

A runtime-derived candidate can increasingly travel through the same physical and causal machinery used by the rest of modern Adaptive Optimization.

The system can now carry a generated optimization much further through its real lifecycle without granting it shortcuts simply because AO created it.

What this development update represents

The newest architecture establishes major progress in:

• real runtime observation → generative input;
• runtime question generation;
• hypothesis preview;
• durable generated candidate provenance;
• generated candidate registration;
• initial AVAILABLE lifecycle;
• existing opportunity integration;
• autonomous Admission integration;
• durable reservation;
• ARM;
• APPLY preflight;
• experiment-start authority;
• real physical APPLY;
• measurement;
• exact rollback;
• settling;
• recovery;
• causal finalization;
• Candidate Knowledge refresh;
• modern candidate decision;
• promotion eligibility;
• productive AVAILABLE → EXPERIMENTAL;
• EXPERIMENTAL trust readiness;
• explicit detection of unrepresentable general trust scope;
• general scope-bound TRUSTED request representation;
• restart-required experiment persistence and resume.

The final autonomous architecture is still not complete.

But the gap between:

AO can theoretically generate optimization structures

and:

AO can route a generated optimization through real Minecraft experimentation and modern lifecycle authority

has become dramatically smaller.

The most important milestone in this update

Adaptive Optimization is no longer only building the machinery required to generate strategies.

It is increasingly building the complete path required to answer:

"What happens after AO creates one?"

A generated candidate can now be treated as a real modern optimization candidate:

identified
↓
registered
↓
tested
↓
measured
↓
rolled back
↓
learned from
↓
evaluated
↓
promoted

without bypassing the safety architecture.

The next major boundaries are increasingly about:

• general scope-bound TRUSTED authority;
• continuous real-time optimization benchmarking;
• self-overhead correction;
• meaningful-improvement governance;
• more expressive generated optimization structures;
• creation of new reusable optimization tools;
• full runtime proof of naturally generated strategies.

Adaptive Optimization continues moving toward the original goal:

an optimizer capable not only of using optimizations, but of learning how to create and maintain them itself.