Abstract

Across the 2016 xSeil logistics design, the 2018 JUBAP/Phylons context-search engine, the exchange-level liquidity coordinator, and the later revision-aware event pipeline, the same operational problem appears in different forms: a large candidate space changes while decisions are being made, resources are shared, and exhaustive global optimization is either unnecessary or too costly. The lineage responds by changing the unit of computation before attempting to optimize it. Compatible work is grouped; decision state is materialized; hard constraints and support remove impossible work; interaction structure guides the residual search; useful intermediate results are persisted; and new evidence revises only the affected units.

This edition separates three categories that the earlier internal note occasionally merged: safe elimination, heuristic guidance, and unverified potential. In JUBAP, anti-monotone support pruning is mathematically safe, whereas occupancy adaptation, ±5% interaction tags, representative-asset fast paths, and stable-first sequencing are heuristics whose recall and robustness require replay. The current source package directly verifies a rich JUBAP predicate lattice, materialized factor-state and target memory, all-pairs interaction constraints, adverse exception structures, timed worker hand-offs, incremental statistics, resource allocations, operation state, and causal event confirmation. The current package does not contain the xSeil production repository; its treatment therefore remains published-design grounded rather than code-verified here.

The note also narrows the quantum question. A large raw search space is not evidence of quantum value. Quantum investigation begins only after a strong classical structure-first funnel leaves a residual hard set that matches a specific access model: rare marked-item search with a cheap reversible predicate, or stochastic expectation estimation with explicit precision requirements. Even then, state preparation, oracle construction, fault-tolerance overhead, readout, data movement, and the best classical baseline determine the crossover. The practical research programme therefore creates business value at every step even when the final decision is to remain classical.

Evidence and terminology discipline

This v2.0 supersedes Optimization Methods Note v1 as the evidence-disciplined synthesis. Paper VI remains the detailed source for JUBAP combinatorial search; this note owns the cross-lineage pattern and the research-investment logic.

1. The optimization problem before the algorithms

The common problem is not “find the mathematical global optimum” in the abstract. It is to maintain a feasible, useful and explainable configuration while the candidate set, evidence, shared resources and downstream consequences continue to change. A decision can remove capacity from later decisions, a new observation can revise an event anchor, and a locally attractive rule can become globally infeasible when several books consume the same balance.

This changes the optimization objective. The system must account for the cost of searching, the cost of commitment, and the cost of revision. A useful generic formulation is:

1.1 Four manifestations of the same problem

1.2 The actual cost object

For JUBAP context search, the raw object is not a fixed set of fourteen Boolean factors. Let U be the universe of compatible subpf item types after asset role, timeframe, factor series and other restrictions; M = |U|. If positive rules are allowed up to length K, the unconstrained candidate count is:

The predicate lattice is richer than a mutually exclusive binning. With k control points, one quantitative factor and one asset role defines 2k + C(k,2) lower, upper and bounded predicates. The implementation compresses the online state by emitting a bounded number of active representatives per ordered series. Search cost is consequently governed by active item count, support, graph density, maximum depth, temporal memories, assets, targets and time budget—not by one headline exponential.

2. The common optimization discipline

2.1 Structure the problem before scoring it

The first optimization act is representational. The system defines which units can cooperate, which can be separated, which share a resource boundary, and which dependencies can propagate change. This step reduces false competition and exposes hard constraints before expensive evaluation begins.

• xSeil: compatible reservations are grouped; subproblems are partitioned by expected propagation rather than by geography alone. [PUBLISHED-D]

• JUBAP: continuous factors become typed predicates; positive bases and negative exceptions are different grammatical objects. [CODE-XBOT / DESIGN-2018]

• Liquidity: local proposals are separated from shared-resource authorization and actual fills. [CODE-XBOT / DESIGN-2018]

• Relabeling: event-sensitive and stable branches are separated so a revised anchor does not imply universal recomputation. [CODE-XBOT / CODE-PFS / RECON]

2.2 Materialize reusable decision memory

The second move changes repeated computation into retrieval plus local adjustment. Routes, factor states, target outcomes, strategy statistics, resource allocations, operation states and event versions are persisted. Materialization does not remove the optimization problem; it lowers the unit cost of testing a candidate and allows incremental maintenance.

Artefact 1 — common materialize-and-reuse pattern

def materialize(key, raw_input, version):
state = transform(raw_input)
store(key=key, version=version, state=state)
return state
def evaluate_candidate(candidate, keys):
# Expensive transformations are not repeated here.
states = retrieve_materialized(keys)
return aggregate(match(candidate, state) for state in states)

Status: RECON; instantiated by route libraries, WavesPF/WavesTargets, allocation ledgers and versioned event state.

2.3 Remove work only where an invariant permits it

Safe elimination is stronger than ordinary ranking. A candidate is removed because it cannot satisfy a declared invariant, not merely because it looks weak in the current sample.

• Feasibility: a route or order violating a hard constraint cannot become feasible by deeper scoring.

• Support anti-monotonicity: if X is infrequent on a fixed history, every superset Y ⊇ X is at least as infrequent.

• Resource conservation: total authorized consumption cannot exceed available unreserved resource.

• Dependency reachability: only descendants of a revised node require invalidation under a correct lineage graph.

2.4 Guide the residual search explicitly

After safe elimination, the residual search remains large. The lineage uses explicit heuristics: stable-first sequencing, occupancy-constrained discretization, interaction tags, coarse-to-fine screens, priority queues and residual-focused mining. These methods trade recall, global optimality or robustness for speed. Their value is operational, but their limitations must be measured rather than hidden.

2.5 Commit under bounded resources

Anytime workers, account budgets, balance reservations and stop conditions keep useful partial results available. The architecture does not wait for exhaustive completion before acting. However, a bounded search remains accountable: it records its frontier, selected candidates, consumed resources and reason for stopping.

2.6 Monitor and revise selectively

New evidence does not reset the whole system. Candidate statistics update from new observations; active strategies can be deactivated; balances and operations close the execution loop; revised events invalidate reachable descendants. The optimization structure is therefore also the memory that survives a regime change.

Artefact 2 — domain-independent optimization cycle

def optimization_cycle(observation, persisted_state, budget):
units = structure(observation, persisted_state)
materialized = update_materialized_units(units)
safe_frontier = eliminate_by_invariants(materialized)
ranked_frontier = guide_with_declared_heuristics(safe_frontier)
commitments = commit_while_budget_remains(ranked_frontier, budget)
record_decisions(commitments)
return selective_monitor_and_revision(commitments)

Status: 2026-I / RECON. Each system supplies different units, invariants, heuristics and commitment boundaries.

3. xSeil: stability partitioning and decision memory

3.1 Cooperative grouping

Compatible reservations—same or compatible destination, timing and corridor—are grouped so they can be optimized jointly instead of competing independently. The optimization potential lies in recognizing that some apparent conflicts disappear when the unit of planning is enlarged.

3.2 Low-propagation partitioning

The retained design describes clusters by expected interference with other clusters, not as generic statistical clusters. A useful partition is one whose internal improvement has limited disruptive effect elsewhere. This makes propagation risk an architectural dimension of decomposition.

3.3 Stable-first resolution

The design resolves the most independent or stable cluster first, locks a workable structure, reprices the remaining space and proceeds to the next cluster. The defensible claim is conditional: under an explicit coupling or rollback-cost model, stable-first can reduce expected interference. It is not universally “provably optimal” without those assumptions.

Artefact 3 — stable-first partition scheduler

def stable_first(partitions, state, budget):
unresolved = list(partitions)
while unresolved and budget.time_left():
p = min(unresolved, key=lambda x: expected_propagation(x, state))
solution = best_feasible_local_solution(p, state, budget)
lock(solution)
state = reprice_and_update_capacity(state, solution)
unresolved.remove(p)
return current_plan(state)

Status: PUBLISHED-D / RECON. Benefit depends on the propagation metric and quality of the local solver.

3.4 Decision memory

Plausible route or assignment structures are retained so recurrent situations become retrieval plus adjustment rather than blind search. This is a strong reusable pattern: preserve feasible alternatives, context and objective regime, not only the chosen answer. The resulting library supports warm starts, counterfactual comparison and rapid replanning.

3.5 What should be measured

4. JUBAP: a code-grounded structure-first search engine

Paper V verifies the context substrate: a 54-family dispatcher, overlapping lower/upper/bounded predicates, compact active-state materialization, targets, cross-asset enrichment and persistent combination/strategy structures. Paper VI isolates the optimization stack. The present section summarizes that stack without duplicating its complete treatment.

4.1 Predicate lattice and compact active state

Control points generate a rich offline predicate lattice. Ranked series then emit a bounded active subset per wave. This separates representational richness from online state size and makes candidate matching a set-containment problem over materialized identifiers.

Artefact 4 — compact predicate-state materialization

def active_state(value, bounded, lower, upper):
active = []
active += first_matching(value, bounded)
active += most_specific(value, lower)
active += most_specific(value, upper)
return sorted(ids(active))
def occurs(active_bits, candidate_bits):
return (active_bits & candidate_bits) == candidate_bits

Status: CODE-XBOT for the predicate series and materialized identifiers; bitset form is an implementation recommendation.

4.2 Occupancy-constrained representation adaptation

The retained InspectorSubpfs logic merges sparse states below 5% and splits dominant states above 25%. This reduces unsupported fine states and overly coarse dominant states. It is adaptive, but not parameter-free: thresholds, history, pass count, neighbour rule and midpoint split all affect the result. Grid versions must therefore be persisted or history must be rematerialized before statistics are mixed.

4.3 Bidirectional single-state screening

The design ranks single states by both supportive and adverse value. Preserving frequent counter-evidence is essential because later strategies are not only positive conjunctions; they also contain explicit negative exception combinations.

4.4 Multi-horizon support pruning

Occurrence is anti-monotone on each fixed history. If X fails a support threshold over total, month or week evidence, every superset containing X also fails at that horizon. This is the strongest mathematically safe pruning mechanism in the search stack.

Artefact 5 — support-safe pruning

def frequent_all_horizons(itemset, thresholds):
for horizon in ('total', 'month', 'week'):
if support(itemset, horizon) < thresholds[horizon]:
return False
return True
# Safe because support(Y) <= support(X) whenever X is a subset of
Y.

Status: MATH / DESIGN-2018 / code-consistent reconstruction.

4.5 Outcome-conditioned interaction graph

The historical field “correlation” is not Pearson correlation, mutual information or conditional independence. It is a thresholded interaction tag: a pair is positive when joint fulfillment exceeds both parents by a margin, adverse when it falls below both, and neutral otherwise. The implementation checks every pair in an extended positive base, producing clique-like growth in the positive graph. Negative exception candidates are constrained by adverse relations to the base and within the exception set.

4.6 Staged rule grammar

A strategy is A AND NOT B1 AND … AND NOT Bq. The engine first discovers A, then a negative exception B, and only then combines multiple exceptions among strategies sharing A. This avoids generating the full rule grammar and preserves explicit negative memory.

Artefact 6 — staged positive and exception search

def search_rules(items, positive_graph, adverse_graph,
budget):
for A in grow_supported_positive_cliques(items, positive_graph,
budget):
persist(A)
for B in grow_adverse_exception(A, adverse_graph, budget):
if fulfillment(A_without(B)) > fulfillment(A):
persist(rule(base=A, exclusions=[B]))
combine_supported_exceptions_by_common_base(budget)

Status: CODE-XBOT / DESIGN-2018 / RECON. Performance tests guide branches but are not anti-monotone guarantees.

5. Anytime operation, incremental statistics and residual mining

5.1 Timed workers and useful intermediate results

The supplied JUBAP search snapshot verifies a concrete 15-minute combination phase and 45-minute strategy phase with worker hand-offs. The durations are version-specific; the architectural invariant is that the system persists usable survivors while deeper search continues. This is an anytime design, not a batch job that produces value only after complete enumeration.

5.2 Fast path and slow recovery path

The retained design first tests recent history and representative assets, then expands survivors across longer histories and more books. A background slow path searches more broadly. This is a coarse-to-fine heuristic, not proof that three assets represent the market. The slow recovery path and out-of-sample replay are necessary controls against false negatives.

5.3 Incremental sufficient statistics

Persisted candidates are updated from waves created after the last measurement. Counts, successes and means can be updated exactly when sufficient statistics are retained; variances require numerically stable updates or count/sum/sum-of-squares. Rolling windows must also remove expired aggregates.

Artefact 7 — incremental candidate statistics

def update(stats, new_observations):
for x in new_observations:
if candidate_occurs(x):
stats.n += 1
stats.successes += int(target_occurs(x))
u = realized_utility(x)
stats.utility_sum += u
stats.utility_sumsq += u * u
stats.time_sum += realized_time(x)
stats.measured_through = new_observations[-1].time
return stats

Status: RECON; exact for declared sufficient statistics, subject to event and knowledge-time consistency.

5.4 Selective active-set maintenance

Not every discovered rule is monitored continuously. Strategies above thresholds, plus manually programmed strategies, form an active set. Recent evidence is blended with long-term evidence and can deactivate a rule. This creates a full dynamic loop: representation adapts, search discovers, online evidence activates or deactivates, and the next cycle starts from persisted state.

5.5 Residual-focused representative combinations

The LM 4.x “Neuron” is a second optimization engine over the same materialized context substrate. It forms an interpretable weighted estimate, identifies macros with large residual error, and mines representative combinations in those difficult contexts rather than across the entire combination universe. This is residual-focused rule stacking, not a conventional neural network.

Versioned weighting form
w_j = numsubs_j × occurrence_j^(1/3) / (1 + std_j), with a documented
floor on std. ŷ(m) = Σ w_j y_j / Σ w_j over rules matching macro m.

5.6 Optimization as selective adaptation

The strongest cross-lineage property is not raw speed. Every surviving unit retains identity and recipe: a route structure, a rule with thresholds and exceptions, a resource allocation, or a derived event node. When evidence changes, the system can weaken, strengthen, deactivate, release or rebuild that unit without retraining or replanning a monolith from zero.

6. Safe pruning and heuristic guidance must remain separate

6.1 Safe instruments

6.2 Heuristic instruments

Artefact 8 — two-channel candidate handling

def candidate_gate(c):
if violates_hard_constraint(c):
return 'ELIMINATE_SAFE'
if fails_support_floor(c):
return 'ELIMINATE_SAFE'
if fails_fast_heuristic(c):
return 'DEFER_TO_SLOW_RECOVERY'
return 'FAST_FRONTIER'

Status: 2026-I / RECON. The slow path preserves the distinction between safe removal and heuristic deferral.

7. Shared-resource coordination as an optimization layer

The liquidity-coordination paper extends the optimization discipline beyond candidate discovery. A good context does not automatically receive capital. Local detectors propose; book-level logic sizes intents; shared-resource coordination authorizes quantities; exchange orders create commitments; fills and closures update the ledger. This proposal–commitment distinction generalizes to production capacity, cloud resources, maintenance slots and portfolio funding.

7.1 Progressive refinement of quantity

The supplied xbot snapshot directly verifies resource allocations, capital-bearing instances, orders, operation state, exchange balances, fill callbacks and stop-based closure. Detailed HQ/LQ arbitration, netting and cross-book proration remain design-grounded where the complete broker implementation is not present.

7.2 Conservation before utility maximization

Resource allocation begins from an invariant: requested value can exceed available liquidity, but authorized and filled value may not. This is a general architecture principle: confidence or local utility is a proposal, not a resource entitlement.

Artefact 9 — shared-resource authorization

def authorize(intents, available):
accepted = []
for tier in priority_order(intents):
groups = group_by_shared_resource(tier)
for resource, group in groups.items():
free = available[resource] - reserved(accepted, resource)
allocations = proportional_cap(desired(group), max(0, free))
accepted += create_authorizations(group, allocations)
assert conserved(accepted, available)
return accepted

Status: RECON. Conservation is the invariant; tiering, ordering and proration policy are versioned design choices.

7.3 Dead time and the value of non-use

The code contains a dead_time concept for capital allocated but not used because no suitable opportunity is found. This is a valuable optimization measure: unused resource is not automatically waste. It can represent disciplined abstention. The relevant trade-off is opportunity loss versus the risk and cost of forcing low-quality commitments.

7.4 Feedback closes the optimization loop

An authorization is not complete until an order is filled, cancelled or closed and the resource is released. Partial execution, fees, stop conditions and inventory attribution can change the next feasible space. Optimization therefore spans discovery, allocation and execution feedback; stopping at the signal would omit the shared-resource problem.

8. Revision-aware optimization: rebuild only what changed

The event pipeline adds a different form of dynamic cost: the knowledge state itself can be revised. xbot performs retrospective reconstruction over a bounded recent window and rematerializes state from an affected timestamp. JUBAP-PFS later distinguishes historical event time from confirmation time and maintains temporary versus confirmed hierarchical events. The next optimization step is explicit dependency-aware invalidation.

8.1 Four timestamps

8.2 Branch-selective invalidation

Not every factor depends on event anchors. Morphology and maturity may be event-sensitive; order-book, calendar, social and some cross-market branches can remain stable or require only time alignment. A revision-aware architecture therefore classifies dependency type and rebuilds reachable descendants in topological order.

Artefact 10 — dependency-aware revision

def revise(source_node, new_version, graph):
affected = descendants(source_node, graph)
mark_stale(affected, superseded_by=new_version)
for node in topological_order(affected):
rebuild(node, knowledge_cutoff=new_version.confirmation_time)
return measure(cascade_size=len(affected),
depth=max_depth(affected))

Status: RECON; bounded rematerialization and causal confirmation are code-grounded, while a complete lineage DAG remains a research implementation target.

8.3 The optimization value

Dependency-aware rebuilding is an optimization even before any predictive claim: it lowers recomputation, preserves stable branches, records revision cost and creates the instrumentation needed to test whether cascade size is concentrated, heavy-tailed or predictable. It also supplies the correct classical baseline for any later quantum triage study.

9. The residual quantum question

9.1 What stays classical

• Predicate construction and materialization.

• Hard feasibility and support pruning.

• Interaction-graph maintenance and adaptive branch scheduling.

• Shared-resource commitment and real-time execution.

• The actual dependency rebuild, which is adaptive and data dependent.

9.2 Gate A — rare marked-item search

Amplitude amplification is a candidate only when a large residual universe remains effectively unstructured for the best classical method, valid elements are rare, and a reversible marking predicate is substantially cheaper than enumerating or simulating the full consequence. The oracle, state preparation and data-access model must be specified; “the raw space is large” is not sufficient.

9.3 Gate B — stochastic expectation estimation

Amplitude-estimation-style arguments apply when the operational quantity is an expectation or rare-event probability estimated to precision ε under a coherent stochastic access model. The familiar 1/ε versus 1/ε² query comparison is not a complete runtime result. State preparation, oracle depth, confidence, noise and the classical estimator matter.

9.4 Near-degenerate cases

Small-score gaps can identify hard and high-stakes cases, but a deterministic comparison does not automatically become a quantum-amplitude-estimation problem. The candidate must be formulated as a noisy or sampled expectation with an explicit gap Δ, and the downstream value of resolving that gap must justify the access and engineering cost.

9.5 Total-cost crossover

End-to-end accounting
T_Q = T_prepare + Q(ε,δ)·T_oracle + T_error-correction + T_readout +
T_data-movement Compare against T_C = the best indexed, parallel, approximate or
problem-structured classical baseline—not against naive
enumeration.

A quantum prototype is justified only when the expected end-to-end advantage is credible for a repeated workload and the candidate has strategic value beyond one synthetic benchmark. A negative crossover result is still valuable: the oracle ledger and classical baselines often expose large immediate engineering improvements.

Artefact 11 — quantum eligibility gate

def quantum_candidate(problem, classical_baseline):
if not problem.survives_structure_first_funnel:
return 'NO: classical structure not exhausted'
if problem.kind == 'marked_search' and not
problem.cheap_reversible_oracle:
return 'NO: oracle dominates'
if problem.kind == 'expectation' and not
problem.stochastic_access_model:
return 'NO: amplitude-estimation premise absent'
tq = total_quantum_cost(problem)
tc = measured_best_classical_cost(classical_baseline)
return 'PROTOTYPE' if tq < tc and problem.repeats_often else 'REMAIN
CLASSICAL'

Status: 2026-I / RECON. The output is a research decision, not a claim of current hardware advantage.

10. Research investment ladder

10.1 Step 1 — instrument the real cost object

• Candidate counts and branching factors by depth.

• Support failures, graph density and heuristic rejection reasons.

• Search time, memory, persistence cost and frontier quality over time.

• Shared-resource demand, authorization, fill, release and dead time.

• Revision frequency, cascade size, depth and decision impact.

10.2 Step 2 — strengthen the classical baseline

Implement bitsets, indexed retrieval, graph-ordering, parallel evaluation, warm starts, priority queues, incremental sufficient statistics and dependency-aware rebuilds. These are not obstacles to quantum research; they define the baseline that a quantum method must actually beat.

10.3 Step 3 — characterize the hard residual set

Measure rarity M/N, score gap Δ, stakes, repeat frequency, input size, oracle complexity and sensitivity to precision. A residual set may be difficult because of poor representation, expensive simulation, unstable labels or genuine search structure; each requires a different response.

10.4 Step 4 — build an oracle and access ledger

10.5 Step 5 — decide by expected value

Prototype only when expected volume, latency, stakes and strategic learning clear the total-cost frontier. The decision can be “not yet,” “not for this candidate,” or “classical permanently.” Each is a valid architecture result when supported by measurement.

11. Corrections and clarifications relative to v1

11.1 What is claimed

• The cross-lineage systems share a structure-first, materialize, prune/guide, bounded-commitment and selective-revision discipline.

• The supplied JUBAP code verifies the central context representation and several major search, persistence, resource and event mechanisms.

• Support anti-monotonicity, conservation and dependency reachability provide safe elimination under their assumptions.

• Heuristic layers are explicit and therefore replayable, replaceable and scientifically useful.

• Quantum candidacy is a residual and conditional research question, not the source of the classical contribution.

11.2 What is not claimed

• No global optimality or universal approximation guarantee.

• No trading-return or logistics-performance claim from architecture alone.

• No proof that the selected semantic contexts are minimal or formally sufficient.

• No demonstrated current quantum advantage or cheap reversible oracle.

• No complete code verification of every historical design mechanism or of xSeil in the current snapshot.

12. Reproducibility and research programme

12.1 Reproducibility package

1. Freeze each source snapshot and published-design document under a named evidence package.

2. Generate a code-to-claim registry with file, function, object, version and evidence label.

3. Persist representation version, factor grid, event time, confirmation time, materialization time and decision time.

4. Replay search with safe filters and each heuristic independently switchable.

5. Record full candidate funnels: generated, safely eliminated, heuristically deferred, evaluated, persisted and activated.

6. Record resource and revision ledgers sufficient to reconstruct commitments and recomputation cost.

7. Compare against strong classical baselines before building any quantum oracle.

12.2 Core experiments

12.3 Publication contribution

12.4 Source register

Iván Abril Palma · IMSV.org / tegrity.ai working group

Private research draft · architectural and computational evidence only · no performance or investment claim