Whats New

Adaptive Optimization — New Preview

The previous preview introduced the first version of Adaptive Optimization's new Candidate Knowledge system.

At that stage, AO could already take many trustworthy causal experiments and begin identifying patterns such as:

• repeated success or failure;
• context-specific behavior;
• contradictions;
• safety hazards;
• semantic failures;
• evidence breadth;
• measured effect distributions.

However, that knowledge still existed mainly as a derived in-memory understanding of the causal history.

The next challenge was making that knowledge durable, safely reconstructible, and useful as the foundation for a completely new candidate lifecycle.

That work is now largely complete.

This preview introduces:

Durable Candidate Knowledge
↓
Modern Candidate Lifecycle
↓
Durable lifecycle state
↓
Runtime read-only lifecycle integration

Adaptive Optimization can now preserve not only what happened during its experiments, but also a structured understanding of what those experiments collectively mean for each optimization candidate.

---

Candidate Knowledge is now durable

The Candidate Knowledge system introduced in the previous preview can now be persisted as a materialized view.

The causal ledger remains the source of truth.

Candidate Knowledge is intentionally treated as a rebuildable interpretation of that history.

Conceptually:

Causal Learning Ledger
↓
Candidate Knowledge aggregation
↓
candidate-knowledge.json

If the Candidate Knowledge file is:

• Missing
• Outdated
• Corrupted
• Built with an older knowledge algorithm

Adaptive Optimization can rebuild it from the authoritative causal ledger.

This means Candidate Knowledge does not become another irreplaceable database.

The original experimental facts remain authoritative.

---

Candidate Knowledge can be rebuilt safely

The durable Candidate Knowledge system now validates the exact causal history it was generated from.

It tracks information such as:

• Source ledger hash
• Source ledger byte length
• Source experiment count
• Knowledge algorithm version
• Candidate count
• Canonical Candidate Knowledge payload hash

If the ledger changes, the Candidate Knowledge view becomes stale and is rebuilt.

If the aggregation algorithm changes, older knowledge views can also be considered stale and regenerated.

This prevents AO from silently using knowledge created under incompatible rules.

---

Candidate Knowledge persistence is crash-safe

Candidate Knowledge files are written using a safer replacement process rather than directly overwriting the currently valid view.

The persistence flow uses a temporary file, forced persistence, and replacement of the previous materialized view.

If the derived knowledge file becomes corrupted, it can be isolated and rebuilt without modifying the causal ledger.

This maintains an important hierarchy:

Causal history is authoritative.

Candidate Knowledge is derived.

A failure in Candidate Knowledge does not change the result of previous experiments.

---

The modern Candidate Lifecycle is now implemented

Adaptive Optimization now has the first modern lifecycle system for optimization candidates.

This system is separate from the older Action / Policy architecture.

The lifecycle layer is designed to eventually represent how AO currently understands the state of a candidate based on accumulated evidence.

Candidate evidence can now produce lifecycle recommendations without immediately changing the actual optimization state.

This creates a new distinction between:

what the evidence suggests

and:

what AO is actually authorized to do.

That distinction is extremely important for future autonomous behavior.

---

Evidence and authority are now separated

The new lifecycle architecture separates concepts such as:

• Evidence-derived lifecycle
• Recommended disposition
• Effective disposition

For example, Candidate Knowledge may suggest that a candidate should be quarantined.

That does not automatically quarantine it.

A recommendation alone cannot silently become authority.

Similarly, an authoritative lifecycle event can keep a candidate quarantined even if current evidence later recommends that it should be available.

This gives Adaptive Optimization a clean boundary between:

analysis

and:

action.

---

Candidate recommendations do not automatically change candidates

The new system intentionally prevents Candidate Knowledge from directly performing actions such as:

• Promoting a candidate
• Quarantining a candidate
• Superseding a candidate
• Applying a candidate
• Disabling a candidate
• Starting an experiment

Candidate Knowledge can currently describe and recommend.

It cannot automatically enforce those recommendations.

This safety boundary is deliberate.

Adaptive Optimization is being given better memory and reasoning before being given more authority.

---

Authoritative disposition events

The lifecycle system now supports a separate authoritative event history for candidate disposition changes.

These events can represent explicit lifecycle authority independently from Candidate Knowledge recommendations.

The lifecycle materializer combines:

Candidate Knowledge
+
Candidate lifecycle recommendations
+
Authoritative disposition events

to build the final effective lifecycle view.

This prevents a derived recommendation from pretending to be a durable decision.

---

Event-only candidates remain honest

A candidate can appear in the lifecycle authority even when Candidate Knowledge does not yet contain enough evidence about it.

In that situation, Adaptive Optimization does not invent an evidence lifecycle.

The candidate can exist with an effective disposition while its evidence-derived lifecycle remains unavailable.

This prevents AO from pretending:

"I know this candidate is new/trusted/rejected"

when it actually only knows that an authoritative event exists for that Candidate ID.

---

Durable Candidate Lifecycle

The modern lifecycle itself can now be materialized into:

candidate-lifecycle.json

Like Candidate Knowledge, this file is not an authority.

It is a rebuildable view generated from:

• Candidate Knowledge
• Candidate lifecycle evaluation
• Authoritative disposition events

If either source changes, the lifecycle view becomes stale.

If the lifecycle file becomes corrupted, it can be isolated and rebuilt.

The authoritative Candidate Knowledge history and disposition event history remain untouched.

---

Lifecycle state is tied to exact source generations

The durable lifecycle view records which Candidate Knowledge and disposition-event state it was created from.

This prevents AO from accidentally treating:

old Candidate Knowledge + new events

or:

new Candidate Knowledge + old events

as if they were one coherent lifecycle state.

The lifecycle view can detect when its source information has changed and rebuild itself accordingly.

This becomes increasingly important as AO moves closer to live autonomous decisions.

---

Corrupted authority now fails closed

Adaptive Optimization now makes an important distinction between:

corrupted derived state

and:

corrupted authoritative state.

If candidate-lifecycle.json is corrupted:

it can be rebuilt.

If the authoritative disposition event history is corrupted:

AO does not rewrite, truncate, delete, or reconstruct that authority from recommendations.

Instead, lifecycle health becomes degraded.

This prevents Candidate Knowledge from silently replacing a damaged authority with its own opinion.

---

Candidate Lifecycle is now integrated into Minecraft startup

The modern Candidate Lifecycle has now been connected to Adaptive Optimization's startup path.

The runtime flow is now approximately:

Causal Ledger
↓
Candidate Knowledge
↓
Candidate Lifecycle
↓
Read-only runtime health

During startup, AO can now:

• Validate Candidate Knowledge
• Load or rebuild Candidate Knowledge
• Validate lifecycle authority
• Load or rebuild Candidate Lifecycle
• Publish lifecycle health information
• Expose the resulting state through diagnostics

The lifecycle is now visible to the runtime.

But it still does not control runtime optimization decisions.

---

Candidate Lifecycle runtime integration has been validated

The new startup integration was tested in a real Minecraft runtime.

On the first launch:

• Candidate Knowledge loaded successfully
• Candidate Lifecycle was missing and rebuilt
• One known candidate was materialized
• The candidate remained available
• No quarantine event was created
• No supersede event was created
• No experiment was started
• No optimization was physically applied
• No legacy learning was written

Minecraft was then closed normally.

After restarting:

• Candidate Knowledge loaded without rebuild
• Candidate Lifecycle loaded without rebuild
• Candidate Knowledge remained identical
• Candidate Lifecycle remained identical
• The causal ledger remained identical
• The disposition authority remained unchanged
• No experiment was replayed
• No candidate was applied

The lifecycle materialized view remained byte-for-byte stable across restart.

---

Lifecycle health is now observable

Adaptive Optimization can now expose read-only Candidate Lifecycle health through diagnostics.

The runtime can observe information such as:

• Lifecycle ready/degraded state
• Candidate count
• Evidence lifecycle availability
• Available candidate count
• Quarantined candidate count
• Superseded candidate count
• Candidate Knowledge binding
• Event-log binding
• Lifecycle payload identity
• Rebuild reason
• Algorithm identity

This gives AO and developers visibility into the new lifecycle architecture without giving that architecture decision authority yet.

---

The lifecycle still cannot control optimizations

This remains one of the most important limitations of the current preview.

Even though Candidate Lifecycle is now available in runtime, it still cannot:

• Automatically apply an optimization
• Automatically reject an optimization
• Automatically quarantine a candidate
• Automatically supersede a candidate
• Automatically promote a candidate
• Start a causal experiment
• Choose the next candidate
• Modify legacy Policy
• Modify StrategyMemory
• Modify ActionState

The modern lifecycle is currently:

observable

but not:

operationally authoritative.

This is intentional.

---

The modern causal architecture is now end-to-end clean

A full architectural audit was performed after the Candidate Lifecycle integration.

The modern chain is now structurally separated as:

Experiment
↓
Causal Learning Record
↓
Durable Causal Ledger
↓
Candidate Knowledge
↓
Candidate Lifecycle

The audit found no direct path from Candidate Knowledge or Candidate Lifecycle into the older:

• Policy system
• ActionState
• StrategyMemory
• Automatic candidate selection
• Experiment arming
• Physical optimization application

The legacy optimization system remains the current operational authority.

The new causal architecture remains separate while its decision layer is developed.

---

Candidate identity remains consistent across the modern pipeline

For candidates originating from real causal experiments, identity is now preserved through the complete modern chain.

Conceptually:

CandidateSpec
↓
Canonical Candidate ID
↓
Experiment Outcome
↓
Causal Learning Record
↓
Ledger
↓
Candidate Knowledge
↓
Candidate Lifecycle

This gives Adaptive Optimization a much stronger foundation for future autonomous candidate selection.

A candidate should no longer become a different conceptual object every time it moves between systems.

---

Legacy and modern systems remain intentionally separated

The current AO still contains its older operational optimization systems.

Those systems continue performing the optimizations that users currently experience.

The newer causal architecture is being built alongside them.

This means the current mod effectively contains two different layers:

Current operational layer

The existing Adaptive Optimization behavior that already optimizes Minecraft.

Modern causal intelligence layer

The newer system responsible for:

• causal experimentation;
• trustworthy evidence;
• durable causal history;
• Candidate Knowledge;
• Candidate Lifecycle.

The next major architectural challenge will be allowing the modern system to influence decisions without simply feeding its knowledge back into legacy Policy structures that cannot represent the new causal model correctly.

---

An important remaining problem: live coherence

The end-to-end audit identified the next major issue that must be solved before Candidate Knowledge can safely influence decisions.

Candidate Knowledge and Candidate Lifecycle are currently refreshed primarily around startup.

If a new experiment is committed to the causal ledger during the same Minecraft session, the durable causal history may become newer than the Candidate Knowledge currently visible to runtime.

Conceptually:

New causal experiment
↓
Ledger updated

but:

Candidate Knowledge may still describe the previous ledger generation

until refresh/restart.

That is safe today because Candidate Knowledge does not control decisions.

It would not be safe once AO begins using it to choose what to do next.

---

The next safety boundary: coherent decision input

Before Adaptive Optimization is allowed to make decisions from its new knowledge, it needs one coherent read model representing:

• The exact causal ledger generation
• Candidate Knowledge derived from that generation
• The exact disposition event generation
• Candidate Lifecycle derived from those exact sources
• Health and staleness information

A future decision should never be allowed to observe:

Candidate Knowledge from one generation

and:

Candidate Lifecycle from another generation

at the same time.

That is the next major development target.

---

What is still missing?

Adaptive Optimization now has:

Trustworthy experiments
↓
Durable facts
↓
Contextual Candidate Knowledge
↓
Durable Candidate Knowledge
↓
Modern Candidate Lifecycle
↓
Durable lifecycle state
↓
Runtime lifecycle visibility

But the system is still intentionally stopped before the next major boundary:

using that knowledge to influence behavior.

AO still needs several systems before modern causal knowledge can become operational.

---

Plan for the next previews

Next previews — Coherent Decision Input

The next stage will create a single coherent snapshot containing the modern information required by future decisions.

Conceptually:

Causal Ledger generation
+
Candidate Knowledge
+
Disposition authority
+
Candidate Lifecycle
+
Health / generation metadata
↓
Coherent Decision Input

This system will ensure that a future decision never sees incompatible generations of AO's memory.

It will still remain read-only.

No automatic candidate selection will be introduced at this stage.

---

Later previews — Context Applicability

After the decision input is coherent, AO will need to determine whether historical evidence actually applies to the current runtime situation.

An optimization may have strong evidence under:

• one mod configuration;
• one workload;
• one dimension;
• one target;
• one environment;

without having enough evidence to justify using it somewhere else.

The future applicability system will need to answer:

"Does the evidence AO has actually apply here?"

without treating all environments as equivalent.

---

Later previews — Candidate Resolution

Adaptive Optimization also needs a modern mapping from:

Candidate ID

to:

the actual optimization implementation capable of executing it.

The current causal system can identify candidates.

However, a future autonomous system needs a safe catalog that knows:

• Which candidate implementations exist
• Which physical mechanism they control
• Which parameters they require
• Whether they can be rolled back
• Whether they require restart
• Whether they are currently executable
• Which optimization lane they own

Event-only or unresolved Candidate IDs must never become executable simply because they appear in lifecycle history.

---

Later previews — Manual Experiment Admission

The first recommended behavioral use of Candidate Knowledge will remain conservative.

Rather than immediately allowing AO to automatically choose and apply optimizations, the first step is planned to influence manual causal experiments.

A future admission gate can answer:

• ALLOW
• DEFER
• BLOCK

for an explicitly requested experiment based on Candidate Knowledge, lifecycle, safety history, and current context.

The user/admin would still explicitly arm the experiment.

The knowledge system would only decide whether that requested experiment is currently safe and meaningful enough to attempt.

This will be the first controlled point where modern causal knowledge begins influencing behavior.

---

Later previews — Candidate selection

Only after manual admission is proven safe will AO begin selecting which optimization candidates deserve experimentation.

Candidate selection will eventually need to consider:

• Current bottleneck
• Candidate applicability
• Existing evidence
• Evidence gaps
• Safety history
• Previous failures
• Context similarity
• Experiment cost
• Cooldowns
• Duplicate experiment prevention
• Expected information value

The goal will not simply be:

"try the optimization with the highest predicted FPS."

The system should choose experiments that produce useful and safe causal information.

---

Later previews — Optimization Value

Candidate Knowledge and Candidate Lifecycle will eventually feed the future multidimensional Optimization Value system.

Optimization Value is planned to consider much more than raw performance.

Possible dimensions include:

• Causal improvement
• Repeatability
• Independent context breadth
• Safety
• Semantic correctness
• Compatibility
• Recovery quality
• Long-term stability
• Generality
• Runtime overhead
• Experiment cost
• Activation cost
• Restart cost
• Rollback reliability
• Blast radius

Optimization Value will eventually help AO compare multiple candidate strategies without compressing dangerous evidence into a misleading simple average.

---

Later previews — Modern promotion authority

Eventually, Adaptive Optimization will need an explicit modern authority capable of deciding whether a candidate should become:

• Available
• Experimental
• Trusted
• Rejected
• Quarantined
• Superseded

This authority will need its own durable decision journal.

Candidate Knowledge recommendations alone will not be enough.

Promotion must become an explicit, auditable decision.

---

Later previews — Legacy de-authority

The current legacy Action / Policy systems still control much of AO's real optimization behavior.

They cannot simply be removed immediately.

Future development will need to move authority from legacy systems to the modern causal architecture gradually.

This transition must occur per optimization mechanism and intervention lane.

The goal is to avoid a dangerous period where both systems believe they own the same optimization.

---

Later previews — Strategy competition and evolution

Once modern decision authority exists, multiple candidate strategies will eventually be able to compete.

AO is planned to support:

• Candidate variants
• Strategy descendants
• Parameter mutations
• Context-specific strategies
• Combined optimization mechanisms
• Dominance detection
• Strategy champions
• Supersession
• Quarantine
• Archival of obsolete strategies

Accepted candidates will eventually become possible parents for improved descendants.

---

Later previews — Self-correction

Candidate Lifecycle will eventually become an important part of Adaptive Optimization's self-correction architecture.

If an optimization that was previously trusted later causes:

• A regression
• A semantic failure
• A compatibility issue
• Instability
• Long-term degradation

AO should eventually:

detect the problem
↓
remove the optimization
↓
quarantine the candidate
↓
preserve the failure evidence
↓
diagnose what changed
↓
create a corrected descendant when possible
↓
causally test it again

A promoted optimization will never be considered permanently correct simply because it passed once.

---

Later previews — Long-term surveillance

Future Candidate Knowledge will also need to incorporate evidence collected long after an optimization was initially accepted.

This includes problems that only appear:

• After hours of gameplay
• After multiple world loads
• After dimension changes
• After player deaths
• After reloads
• After accumulated memory/state
• After interaction with other optimizations
• After mod configuration changes

Adaptive Optimization's long-term goal is continuous optimization without sacrificing long-term stability.

---

Later previews — Restart-required optimization lifecycle

Some future candidates will require changes that cannot be tested entirely during a running Minecraft session.

Adaptive Optimization will eventually need a separate pipeline for:

• Startup-only candidates
• Class-load changes
• Bootstrap transformations
• Restart-required optimizations

These candidates must have:

• Durable pending state
• Controlled startup application
• Boot verification
• Runtime validation
• Crash-loop prevention
• Fail-closed rollback

A candidate that breaks startup must never permanently trap a Minecraft instance in a crash loop.

---

Later previews — Open-world optimization discovery

Adaptive Optimization's final discovery system is still intended to go beyond a fixed list of optimization targets.

Entities, chunks, rendering, networking, ticking, I/O, and other known workload categories are useful descriptions.

They are not intended to permanently define AO's search space.

Future versions should be capable of identifying:

• New workload relationships
• Unknown bottleneck families
• Unexpected interactions
• Previously unseen optimization opportunities

and creating new conceptual target families when the evidence supports them.

---

Later previews — Autonomous candidate generation and evolution

The long-term architecture continues toward:

Observe
↓
Discover
↓
Attribute
↓
Diagnose
↓
Generate hypotheses
↓
Create candidates
↓
Evaluate applicability
↓
Experiment
↓
Measure
↓
Accept / reject / quarantine
↓
Remember
↓
Compare
↓
Improve
↓
Combine
↓
Correct
↓
Monitor long-term
↓
Repeat

without requiring an external AI service to operate.

The objective remains the same:

give Adaptive Optimization as much freedom as possible to discover better optimization strategies while requiring increasingly strong evidence before those strategies are allowed to control the game.

---

Current status

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

The previous preview ended with Candidate Knowledge beginning to understand patterns across causal history.

Adaptive Optimization can now go further:

Observe
↓
Identify
↓
Diagnose
↓
Experiment
↓
Measure
↓
Roll back
↓
Evaluate
↓
Persist trustworthy causal history
↓
Build contextual Candidate Knowledge
↓
Persist and rebuild that knowledge
↓
Evaluate a modern Candidate Lifecycle
↓
Persist and rebuild that lifecycle
↓
Load Candidate Lifecycle safely in real Minecraft runtime
↓
Expose it through read-only health and diagnostics

The next major boundary is different from everything before it.

AO no longer mainly needs better memory.

It now needs to learn how to consult that memory coherently before making a decision.

The system is deliberately stopped before that authority is enabled.

Adaptive Optimization can now remember what happened, understand patterns across those experiments, and maintain a modern lifecycle for its candidates.

The next step is teaching it how to safely use that knowledge when deciding what to do next.