Adaptive Optimization(reborn)
- By
Curse Maven Snippet
What's new
Whats New
Adaptive Optimization — New Preview
The previous preview completed one of the most important foundations of Adaptive Optimization's modern architecture.
AO could already:
Run trustworthy causal experiments
↓
Persist causal history
↓
Build Candidate Knowledge
↓
Persist and rebuild Candidate Knowledge
↓
Evaluate Candidate Lifecycle
↓
Persist and rebuild Candidate Lifecycle
↓
Expose that lifecycle safely to runtime
But the previous preview intentionally stopped before allowing that knowledge to influence behavior.
The next problem was much harder.
Before AO could safely consult its modern causal memory, it needed to answer several questions:
Is all of the information I am reading from the same generation?
Does the historical evidence actually apply to the current Minecraft environment?
Does this Candidate ID correspond to a real executable optimization?
Is the requested experiment safe and meaningful enough to run right now?
Can that permission still be trusted when the experiment actually begins?
This preview implements and validates that next layer.
Adaptive Optimization now has:
Coherent Decision Input
↓
Context Applicability
↓
Candidate Resolution
↓
Exact Executor Binding
↓
Physical State Verification
↓
Manual Experiment Admission
↓
Single-use Admission Lease
↓
Fresh start-time revalidation
↓
Real controlled experiment
For the first time, Adaptive Optimization's modern causal architecture has been validated influencing a real physical optimization decision from end to end.
Coherent Decision Input
The previous preview identified a major future safety problem.
Candidate Knowledge and Candidate Lifecycle could both be valid independently while still describing different generations of causal history.
For example:
New experiment
↓
Causal Ledger generation B
while runtime could still temporarily hold:
Candidate Knowledge from generation A
or:
Candidate Lifecycle built from an older Candidate Knowledge view
That would be unsafe once AO started making decisions from this information.
This preview introduces a new Coherent Decision Input layer.
Instead of future decision systems independently reading:
- Causal Ledger state
- Candidate Knowledge
- Candidate Lifecycle
- Disposition authority
AO can now publish one immutable coherent snapshot containing information that belongs together.
Conceptually:
Exact ledger boundary
+
Candidate Knowledge derived from that boundary
+
Exact lifecycle-event boundary
+
Candidate Lifecycle derived from those exact sources
+
health / generation metadata
↓
Coherent Decision Input
A future decision should no longer need to assemble its own view from independently changing systems.
READY, STALE and DEGRADED decision states
The coherent decision layer can explicitly represent whether its information is currently usable.
The main states include:
READY
The complete decision tuple is coherent and can be inspected safely.
STALE
A newer authoritative source exists, but the currently published snapshot still preserves the complete previous coherent generation while the new derived state is refreshed.
DEGRADED
AO cannot currently prove that a safe coherent decision input is available.
This distinction is important.
Adaptive Optimization does not silently combine:
old Candidate Knowledge
with:
new Candidate Lifecycle
while pretending the result is valid.
Same-session causal refresh
Candidate Knowledge and Candidate Lifecycle are no longer limited to effectively becoming current only after restarting Minecraft.
When a causal experiment successfully commits a new authoritative record and that commit is acknowledged, the modern decision state can become dirty and refresh.
Conceptually:
READY generation
↓
new causal experiment committed
↓
STALE old coherent generation
↓
bounded refresh
↓
new READY coherent generation
The STALE state still represents one complete older generation.
AO does not publish a half-updated hybrid.
Coherent decision refresh was validated in Minecraft
The coherent decision architecture was tested in a real Minecraft runtime.
The runtime demonstrated:
READY
↓
manual causal experiment
↓
new durable ledger record
↓
STALE
↓
refresh
↓
new READY generation
The updated Candidate Knowledge and Candidate Lifecycle were published together.
A clean restart was also validated.
The new JVM reconstructed one coherent READY state from the durable sources without replaying the previous experiment.
Context Applicability
A coherent memory is still not enough.
AO also needs to know whether historical evidence is relevant to what is happening right now.
An optimization may have succeeded under:
- another modpack;
- another Minecraft version;
- another dimension;
- another target;
- another workload;
- another mod version;
- another class or method;
- another runtime environment.
This preview introduces a formal Context Applicability model.
Historical evidence can now be classified as:
EXACTSTRONG_MATCHPARTIALUNKNOWNMISMATCH
This is not a generic similarity score.
The system preserves explicit dimensions and reasons.
Critical context contradictions fail explicitly
Some contextual differences are more important than others.
Known contradictions in critical dimensions can produce a real MISMATCH.
Relevant dimensions can include information such as:
- logical side;
- dimension;
- thread role;
- target origin;
- mod ID;
- class;
- method;
- method descriptor when available;
- subsystem;
- stable target identity.
AO does not allow a strong match in unrelated dimensions to hide a known critical contradiction.
Missing information remains UNKNOWN
Adaptive Optimization now has a stricter rule:
missing information is not permission.
If AO does not know enough about a historical context, it does not silently transform that uncertainty into compatibility.
This prevents dangerous reasoning such as:
"I cannot prove this is the same target, therefore it is probably the same."
UNKNOWN remains UNKNOWN.
Historical compatibility remains honest
Older causal records are still supported.
However, old schemas do not gain information they never contained.
Schema 1 historical records remain effectively hash-only history.
AO does not reconstruct target details that were never originally persisted.
This allows backward compatibility without falsifying evidence quality.
Richer Target Context
The modern target descriptor can now preserve substantially more execution context when that information is genuinely available.
This can include:
- Vanilla / modded origin
- mod ID
- mod version
- class
- method
- method descriptor
- subsystem
- module
- class loader
- Minecraft version
- provenance
- confidence
- source stable key
- stable target identity
The previous historical format remains readable.
No causal ledger migration was required.
Current Decision Context
Adaptive Optimization can now construct a bounded description of the current Minecraft execution environment for future decisions.
Current context can be:
DESCRIBEDPARTIALUNAVAILABLE
The system can capture information such as:
- Minecraft version
- Forge version
- Java environment
- logical side
- current dimension
- thread role
- world identity
- reload generation
- mod environment fingerprint
- relevant mod versions
- target information
The environment fingerprint is deterministic, normalized and bounded.
AO does not perform unbounded collection of every possible runtime detail.
Candidate Resolution
Knowing that a Candidate ID exists in history does not mean AO knows how to execute it.
This preview introduces a modern Candidate Catalog and Resolver.
A Candidate ID can now resolve to states such as:
RESOLVEDUNKNOWN_CANDIDATEIMPLEMENTATION_UNAVAILABLEEVENT_ONLY
This creates another important rule:
lifecycle presence does not imply executability.
An event-only Candidate ID cannot suddenly become runnable because it exists in lifecycle authority.
Exact Candidate IDs only
Candidate resolution is intentionally strict.
AO does not use:
- fuzzy Candidate ID matching;
- prefix matching;
- nearest candidate fallback;
- guessed aliases.
An executable implementation must correspond to the exact expected Candidate ID.
This reduces the possibility that historical evidence for one candidate accidentally authorizes another optimization.
The first modern executable candidate
The current modern Candidate Catalog contains one deliberately narrow real executable candidate:
FriendlyByteBuf causal pilot
Canonical Candidate ID:
sha256:77e2d5919463a8a3c57a38f045d2585799a0ed00624c3084db68c10f6a701f80
Executor identity:
ao:fbb-pilot-intervention@pilot-v1
Execution lifecycle:
LIVE_RUNTIME
Rollback capability:
EXACT
Target subsystem:
NETWORK
This candidate exists primarily as a controlled proof that the new causal architecture can govern real physical behavior safely.
Exact Executor Binding
Candidate resolution alone is still not enough.
AO now also verifies that the resolved candidate is attached to the exact expected implementation.
The executor binding tracks the expected relationship between:
- Candidate ID
- Catalog entry
- Executor identity
- Implementation identity
- Physical optimization vector
The FBB pilot does not use a fuzzy or interchangeable executor.
If the exact expected implementation is unavailable or conflicts with the catalog description, admission fails closed.
Read-only Physical State Probes
Before allowing a physical experiment, AO also needs to know whether the real optimization mechanism is currently in a compatible state.
The FBB pilot now has a read-only physical probe.
The probe can report states such as:
READYUNKNOWNINCOMPATIBLE
The probe reads the physical optimization state.
It does not apply or rollback anything.
If the implementation cannot be observed reliably, AO does not invent a neutral state.
A real context can honestly remain PARTIAL
The FBB pilot exposed an important architectural problem during development.
FriendlyByteBuf is affected through multiple hooks.
There is no single honest method identity that represents the entire candidate.
The wrong solution would have been to invent one method simply to make the current context appear complete.
Adaptive Optimization does not do that.
The real FBB Current Decision Context remains:
PARTIAL
because its class and subsystem are known, but one canonical method identity is not.
This led to a new distinction.
Structurally Verified Partial Context
A context can be historically incomplete while its physical execution identity is independently verified.
Adaptive Optimization now distinguishes that case.
A PARTIAL context can become:
STRUCTURALLY_VERIFIED_PARTIAL
for a controlled trial only when several independent requirements agree.
For example:
Current context = PARTIAL
+
environment descriptor present
+
target descriptor present
+
candidate RESOLVED
+
target contract COMPATIBLE
+
exact executor BOUND
+
physical probe READY
+
compatible execution capability
↓
STRUCTURALLY_VERIFIED_PARTIAL
This does not change the Current Decision Context itself.
The context remains honestly PARTIAL.
Structurally verified partial does not improve historical evidence
This distinction is deliberately narrow.
STRUCTURALLY_VERIFIED_PARTIAL does not make historical evidence more comparable.
It does not upgrade:
- Candidate Knowledge confidence;
- applicability;
- richness;
- generality;
- lifecycle evidence;
- future promotion evidence.
It only answers a different question:
"Do we know enough about the physical candidate and current environment to safely perform a new controlled experiment?"
That is not the same as:
"Do we know that old historical evidence applies here?"
Manual Experiment Admission
This preview introduces the first modern behavioral authority based on the causal architecture.
The initial scope is deliberately conservative.
Adaptive Optimization still does not automatically choose an optimization.
Instead, an admin/user explicitly requests a manual experiment.
The modern admission system evaluates that request and returns:
ALLOWDEFERBLOCK
This is the first point where Candidate Knowledge, Candidate Lifecycle, current context and physical verification can influence whether AO is allowed to perform a real optimization experiment.
BLOCK, DEFER and ALLOW have different meanings
The admission policy deliberately separates permanent/structural problems from temporary inability to proceed.
BLOCK
Used for structural or incompatible conditions.
Examples can include:
- incompatible candidate implementation;
- incompatible target;
- insufficient rollback capability;
- authoritative lifecycle state that forbids execution.
DEFER
Used when the candidate might be valid later, but AO cannot safely authorize it now.
Examples can include:
- stale/degraded coherent input;
- insufficient current context;
- unknown physical probe state;
- temporary recovery state.
ALLOW
Requires explicit positive requirements.
AO does not implement admission as:
not BLOCK and not DEFER = ALLOW
Permission must be positively established.
Controlled Trial and Retest are separate
The admission architecture now distinguishes:
MANUAL_CONTROLLED_TRIALMANUAL_RETEST
A first controlled trial can be allowed under structurally verified partial context.
A historical retest remains stricter.
For a retest, AO still needs sufficiently comparable historical context.
This prevents the structural verification exception from becoming a shortcut around context applicability.
Productive FBB admission
The manual command:
/ao experiment arm fbb-pilot
now passes through the modern admission path.
Conceptually:
exact command mapping
↓
coherent decision input
↓
current decision context
↓
Candidate Knowledge / Lifecycle assessment
↓
candidate resolution
↓
target compatibility
↓
exact executor binding
↓
physical probe
↓
manual admission policy
Only an ALLOW can create a pending manual arm.
DEFER, BLOCK, exceptions or failed boundaries create no arm.
There is no fallback to the legacy manual arm path.
Command-time permission does not execute the optimization
An admission ALLOW still does not physically apply FBB.
The command is only allowed to create:
- one pending arm;
- one admission lease.
It does not:
- acquire the optimization lane;
- call the physical intervention;
- start the experiment session;
- write a causal verdict.
This preserves another safety boundary between:
permission to prepare
and:
permission to actually begin.
Admission Lease
A new immutable AdmissionLease now represents the command-time authorization.
The lease binds the original admission to the exact state that justified it.
It includes identity derived from information such as:
- manual request
- admission purpose
- Candidate ID
- candidate specification
- catalog identity
- coherent generation
- coherent source tuple
- current context identity
- context availability
- context admission sufficiency
- lifecycle state
- effective disposition
- resolution state
- target compatibility
- executor binding
- physical probe
- arm generation
The lease is deterministic and single-use.
Permission cannot silently survive changing conditions
A major race existed conceptually between:
the moment the command is admitted
and:
the later tick when the experiment actually begins.
Minecraft can change between those moments.
The Candidate Lifecycle may change.
The context may change.
The physical optimization state may change.
The coherent causal generation may change.
A command-time ALLOW therefore cannot be treated as permanent authorization.
This preview introduces fresh start-time revalidation.
Fresh start-time revalidation
Immediately before the experiment is allowed to start, AO reconstructs the admission facts again.
Conceptually:
runtime becomes eligible
↓
fresh admission evaluation
↓
compare against AdmissionLease
↓
exact match
↓
consume lease
↓
attempt startSession
If the current facts no longer correspond to the original authorization:
the arm is cancelled/deferred safely.
The stale permission is not retained indefinitely waiting for conditions to become valid again.
A new manual command would be required.
AdmissionLease is single-use
Once the lease:
- is consumed;
- is invalidated;
- is cancelled;
- starts the experiment;
- encounters a lane conflict;
it cannot be reused.
This prevents an old authorization from silently starting a second experiment on a later tick.
The optimization lane remains the final atomic boundary
The admission system does not reserve the physical optimization lane.
Even after successful revalidation, the existing experiment session still needs to acquire the lane atomically.
The order remains conceptually:
fresh admission PASS
↓
startSession
↓
lane.tryAcquireIfNeutral
↓
physical experiment
The AdmissionLease is not a substitute for physical ownership.
Runtime admission observability
Because this new path controls real physical behavior, Adaptive Optimization now exposes bounded runtime diagnostics for the admission flow.
The diagnostics are:
- in-memory;
- read-only;
- non-authoritative;
- non-durable;
- bounded.
They do not influence execution.
The runtime can expose information about:
- command admission;
- fresh revalidation admission;
- lease identity/state;
- revalidation attempts;
- exact seed matching;
- correlated admission events.
The event trace is bounded to prevent unbounded runtime growth.
The full admission path was validated in real Minecraft
The new architecture was tested in a real Forge 1.20.1 Minecraft instance with a large modpack.
The runtime demonstrated the complete sequence:
COMMAND_EVALUATED
↓
LEASE_CREATED
↓
LEASE_PENDING
↓
REVALIDATION_STARTED
↓
FRESH_ADMISSION_EVALUATED
↓
REVALIDATION_PASSED
↓
LEASE_CONSUMED
↓
START_SESSION_ATTEMPTED
↓
START_SESSION_STARTED
The trace belonged to the same manual request and lease.
The fresh evaluation returned ALLOW.
The lease matched the fresh admission state.
The experiment started only after successful revalidation.
The real FBB admission remained honest
During the runtime validation, the FBB candidate was admitted as:
Current Decision ContextPARTIAL
Context Admission SufficiencySTRUCTURALLY_VERIFIED_PARTIAL
Target CompatibilityCOMPATIBLE
Candidate ResolutionRESOLVED
Executor BindingBOUND
Physical ProbeREADY
AdmissionALLOW
The system did not invent a missing method identity simply to obtain permission.
The real experiment executed exactly once
After successful admission and lease revalidation, the original causal experiment FSM executed:
PRE
↓
APPLYING
↓
STABILIZING
↓
EXPERIMENT
↓
ROLLING_BACK
↓
RECOVERY
↓
EVALUATING
↓
FINALIZED
Runtime counters confirmed:
experimentsStarted = 1
physicalApplications = 1
There was no second automatic experiment.
Physical rollback was exact
The FriendlyByteBuf optimization pilot began from its neutral state:
FBB = false
varintFast = false
capacity = 256
During the experiment:
FBB = true
varintFast = false
capacity = 69
After rollback:
FBB = false
varintFast = false
capacity = 256
The intervention returned exactly to the captured baseline.
The experiment result remained conservative
The runtime experiment finalized as:
INCONCLUSIVE
with learning state:
NOT_ELIGIBLE
That is not considered a failure of the admission system.
The purpose of this validation was not to force AO to discover a performance improvement.
The purpose was to prove that:
- admission;
- lease;
- revalidation;
- physical execution;
- rollback;
- causal persistence
all remained correctly separated.
Adaptive Optimization did not promote a candidate simply because the experiment successfully executed.
The causal pipeline remained intact
After the physical experiment completed, the existing causal pipeline continued normally.
The experiment produced one new authoritative causal record.
The transactional outbox became acknowledged.
Candidate Knowledge refreshed from the new ledger state.
Candidate Lifecycle refreshed from the updated Candidate Knowledge and lifecycle authority.
Coherent Decision Input eventually returned to a new READY generation.
The new admission architecture did not bypass or replace the existing causal persistence pipeline.
Derived-state rebuilds remain safe
During runtime validation, some materialized views were observed rebuilding from authoritative sources.
This included states equivalent to:
- Candidate Knowledge rebuilt from the causal ledger;
- Candidate Lifecycle rebuilt from current Candidate Knowledge.
These rebuilds completed successfully and produced coherent READY state.
This confirms an important architectural rule introduced in previous previews:
derived state can be reconstructed.
A rebuilt Candidate Knowledge or Candidate Lifecycle file is not equivalent to corrupted causal authority.
The authoritative ledger and disposition-event history remain the source boundaries.
Clean restart and no-replay were validated
The manual experiment authorization is intentionally not durable across JVM restarts.
After a clean Minecraft restart, Adaptive Optimization returned with:
- no pending manual arm;
- no AdmissionLease;
- zero experiments started in the new JVM;
- zero physical applications in the new JVM;
- empty in-memory admission telemetry.
Candidate Knowledge, Candidate Lifecycle and Coherent Decision Input recovered their durable state normally.
The previous manual experiment was not replayed.
The previous AdmissionLease did not become cross-restart authority.
The modern causal system now influences a real physical action
This preview marks a major architectural transition.
Previously:
Modern causal architecture
trusted memory and analysis
while:
Legacy architecture
real operational authority.
That boundary has now moved slightly.
For one deliberately controlled manual experiment path, the modern architecture can now decide whether execution is permitted.
Conceptually:
Causal history
↓
Candidate Knowledge
↓
Candidate Lifecycle
↓
Coherent Decision Input
↓
Current Context
↓
Applicability
↓
Candidate Resolution
↓
Physical Verification
↓
Admission Policy
↓
Admission Lease
↓
Fresh Revalidation
↓
Physical Experiment
This entire chain has now been validated in real Minecraft.
This does NOT mean AO is autonomous yet
This preview does not automatically enable candidate selection.
Adaptive Optimization still does not autonomously:
- choose the next modern candidate;
- arm experiments;
- promote candidates;
- quarantine candidates from recommendations alone;
- supersede candidates;
- evolve strategies;
- combine optimization candidates;
- generate new executable candidates;
- replace all legacy optimization authority.
The first operational use of modern causal knowledge remains intentionally narrow:
manual controlled experiment admission.
Why manual admission came first
Allowing the modern architecture to control manual experiments provides a safer intermediate step before autonomous candidate selection.
The user/admin still chooses:
which experiment should be requested.
The modern causal system answers:
whether that experiment is currently valid enough to attempt.
This lets AO exercise real decision authority while keeping:
- candidate selection;
- experimentation rate;
- exploration scope
under explicit human control.
What is now complete?
Adaptive Optimization can now:
Observe
↓
Identify
↓
Diagnose
↓
Run controlled causal experiments
↓
Measure PRE / EXPERIMENT / RECOVERY
↓
Rollback
↓
Evaluate
↓
Persist trustworthy causal history
↓
Aggregate Candidate Knowledge
↓
Persist/rebuild Candidate Knowledge
↓
Evaluate Candidate Lifecycle
↓
Persist/rebuild Candidate Lifecycle
↓
Publish Coherent Decision Input
↓
Capture current runtime context
↓
Compare historical applicability
↓
Resolve exact Candidate IDs
↓
Verify exact physical executor
↓
Probe physical state
↓
Evaluate manual admission
↓
Create a single-use authorization lease
↓
Revalidate immediately before execution
↓
Execute one controlled physical experiment
↓
Rollback
↓
Refresh modern causal knowledge
↓
Restart without replay
The modern causal pipeline is no longer only observational.
It now has its first controlled behavioral authority.
What is still missing?
The largest remaining milestone is no longer:
"Can AO safely consult its causal memory?"
That has now been demonstrated.
The next problem is:
"How should AO decide what deserves experimentation?"
Adaptive Optimization still needs a modern candidate selection system capable of deciding:
- which candidates are relevant to the current bottleneck;
- which candidates already have enough evidence;
- which candidates need more evidence;
- which candidates should not be retested;
- where uncertainty is valuable;
- what experiment cost is acceptable;
- how risk should influence exploration;
- how duplicate experiments should be avoided.
Next previews — Candidate Selection
The next major architecture is expected to begin moving from:
manual candidate choice
toward:
modern candidate recommendation and selection.
This must not be implemented as:
highest predicted FPS wins.
Candidate selection will need to consider multiple factors such as:
- current bottleneck;
- target relevance;
- context applicability;
- lifecycle disposition;
- evidence quantity;
- evidence quality;
- contradictions;
- safety history;
- semantic hazards;
- experiment cost;
- cooldowns;
- recent attempts;
- information value;
- rollback capability;
- physical ownership.
The system should be allowed to choose:
NO_ACTION
when no candidate deserves experimentation.
Candidate selection must remain separate from execution
Even when modern candidate selection exists, selection itself should not become a physical actuator.
The future architecture should preserve a chain such as:
Selection
↓
Admission
↓
Lease
↓
Fresh Revalidation
↓
Lane acquisition
↓
Physical execution
A candidate being selected does not mean it is automatically allowed to run.
This preview's admission system is intended to remain an independent safety boundary.
Future Optimization Value
Once AO can compare multiple candidates, raw FPS improvement will not be enough.
Adaptive Optimization's planned Optimization Value system will evaluate optimization strategies across dimensions such as:
- measured causal performance;
- confidence;
- repeatability;
- safety;
- semantic correctness;
- compatibility;
- context breadth;
- generality;
- long-term stability;
- runtime overhead;
- experiment cost;
- activation cost;
- restart cost;
- rollback reliability;
- blast radius.
This should allow AO to prefer a slightly smaller optimization that is:
repeatable, safe and general
over a larger optimization that is:
fragile, dangerous or highly context-specific.
Strategy competition
Future candidate selection will eventually expand into strategy competition.
Multiple optimization candidates may attempt to solve the same bottleneck.
AO is planned to support concepts such as:
- candidate variants;
- champions;
- challengers;
- descendants;
- parameter mutations;
- strategy combinations;
- dominance pruning;
- supersession.
A successful strategy should become a possible parent for more refined descendants rather than a permanent final answer.
Strategy combinations
Future Adaptive Optimization should also be able to discover when multiple safe primitives work better together.
Examples could include:
CACHE + INVALIDATE
DEDUPLICATE + BATCH
COALESCE + SCHEDULE
MEMOIZE + FAST_PATH
A combination should become its own causal candidate.
It must have:
- its own identity;
- lineage;
- physical vector;
- rollback;
- evidence;
- Candidate Knowledge;
- lifecycle.
A combination should never inherit trust automatically just because its individual components were successful.
Self-correction remains a major future objective
As Adaptive Optimization gains more authority, it also needs the ability to detect when its own decisions were wrong.
A future trusted optimization may later cause:
- instability;
- compatibility problems;
- memory growth;
- semantic bugs;
- delayed regressions;
- unexpected interactions.
The planned response remains:
detect
↓
rollback
↓
quarantine
↓
preserve evidence
↓
diagnose
↓
create corrected descendant when possible
↓
retest
Rollback should happen before attempting to repair an active defective optimization.
Long-term surveillance
Future Candidate Knowledge will need to incorporate evidence collected long after an optimization was originally accepted.
Adaptive Optimization must eventually detect failures that only appear:
- after hours of gameplay;
- after many world loads;
- after death/respawn cycles;
- after dimension changes;
- after reloads;
- after memory accumulation;
- after interaction with other optimizations;
- after configuration changes.
Promotion will never mean:
"this candidate is permanently safe."
It will mean:
"current evidence supports allowing this candidate under these conditions."
That conclusion must remain revocable.
Shared / Federated Knowledge — future architecture
Another planned long-term system is shared causal knowledge between Minecraft instances and modpacks.
AO should eventually be able to transfer information such as:
- candidate identities;
- causal outcomes;
- target descriptors;
- environment descriptors;
- failures;
- quarantines;
- lineage;
- delayed regressions;
- generality evidence.
However:
shared knowledge must never automatically transfer authority.
A candidate trusted in one instance should not silently become trusted in another.
Imported evidence must still pass:
- current context applicability;
- local safety;
- local revalidation;
- local lifecycle authority.
The purpose is to reduce unnecessary relearning without turning another instance's decisions into local permission.
Restart-required candidates remain a separate future pipeline
The currently validated FBB pilot is a LIVE_RUNTIME candidate.
Future optimizations may require:
- bootstrap transformation;
- class-load changes;
- startup-only configuration;
- restart.
Those candidates cannot safely reuse the same lifecycle as a fully live experiment.
They will require:
preflight
↓
durable pending restart
↓
controlled startup
↓
boot verification
↓
runtime validation
↓
provisional result
↓
accept / rollback
Crash-loop prevention and fail-closed recovery will be mandatory.
Open-world discovery remains the final direction
Adaptive Optimization is still not intended to become a finite catalog of manually written optimizations.
Known categories such as:
- rendering;
- entities;
- chunks;
- networking;
- ticking;
- I/O;
- locks;
are useful labels.
They are not intended to permanently define the search space.
The long-term discovery architecture should be able to identify:
- unknown bottleneck families;
- new workload relationships;
- unexpected interactions;
- optimization opportunities the original developer never explicitly listed.
Discovery should remain broad.
Physical intervention should remain controlled.
Current status
The previous preview ended with:
Adaptive Optimization can remember what happened, understand patterns across those experiments, and maintain a modern lifecycle for its candidates.
This preview completes the next major boundary.
Adaptive Optimization can now:
remember
↓
construct coherent causal memory
↓
understand whether historical evidence applies
↓
resolve a candidate to an exact physical implementation
↓
verify its current physical state
↓
decide whether a manually requested experiment is currently admissible
↓
bind that permission to a single-use lease
↓
revalidate the entire decision immediately before execution
↓
perform the controlled experiment
↓
rollback
↓
update causal knowledge
↓
restart without replaying the authorization
This is the first validated bridge between:
Adaptive Optimization's modern causal intelligence
and:
real optimization behavior.
The next challenge is allowing that intelligence to begin deciding which candidate should be considered next, while preserving every safety boundary introduced so far.
This mod has no additional files