Abstract

This paper reconstructs the revision-aware event substrate of JUBAP/Phylons from two supplied source snapshots and the historical design corpus. The xbot snapshot implements a retrospective path: local extrema are filtered through centred windows, hidden extrema can be recovered, waves and targets are deleted and rematerialized over a bounded recent interval, predictive factors are recalculated with history padding, and materialized factor-state arrays are replaced from the last stored timestamp. The later JUBAP-PFS snapshot implements a causal streaming path: candidate extrema are confirmed only after subsequent evidence, the event is stored at its historical position while confirmation is emitted at the current stream position, higher event levels are constructed recursively, and temporary extrema are represented separately from confirmed ones. Together, these artifacts expose a research object more precise than a generic “relabeling cascade”: a new observation can revise an earlier event in event time, and that revision can propagate forward through the subset of derived objects that actually depend on the event branch.

The paper therefore separates three layers. First, it documents the code-grounded historical mechanisms. Second, it introduces an implementation-ready, dependency-aware reconstruction with versioned event records, knowledge-time cutoffs, selective invalidation, topological rebuilding, and a cascade-cost ledger. Third, it treats quantum computation as a conditional research option rather than an established advantage. Amplitude amplification or amplitude estimation becomes relevant only after a fixed candidate universe, a reversible marking or sampling oracle, coherent state preparation, error targets, and total resource costs are specified. Event detection, feature construction, dependency traversal, and rebuilding remain classical. The strongest contribution is thus classical and falsifiable: an evolution from retrospective event reconstruction to causal event semantics, plus a concrete benchmark for measuring when revisions matter, how far they propagate, and whether any quantum triage layer could ever cross the engineering cost frontier.

Keywords: event semantics; relabeling; causal replay; knowledge time; dependency graph; incremental recomputation; regime detection; quantum amplitude amplification; amplitude estimation

Evidence and terminology discipline

Contents

• 1. The problem: provisional meaning and historical revision

• 2. Evidence base and corrected object model

• 3. Event-sensitive context architecture

• 4. Retrospective reconstruction and bounded rematerialization in xbot

• 5. Causal streaming confirmation and event levels in JUBAP-PFS

• 6. From event revision to selective relabeling

• 7. Classical-first dependency-aware rebuilding

• 8. Measuring cascades and near-degeneracy

• 9. Conditional quantum triage and the crossover frontier

• 10. Playable implementation and research programme

• Appendices: code map, event schema, claim/evidence ledger, references

1. The problem: provisional meaning and historical revision

A numerical observation does not carry its final structural meaning at the instant it arrives. A local maximum can be a temporary high, a confirmed event, or a child of a later higher-level event depending on subsequent observations. The architecture therefore faces two clocks: event time, where the candidate extremum occurred, and knowledge time, when enough evidence existed to use that interpretation. Mixing those clocks creates leakage in replay; keeping them separate creates a revision problem that must be governed explicitly.

A new observation can change an earlier label in event time. That revision does not move backward through computation. It moves forward through the derivation graph: event -> wave or support -> event-sensitive factor -> qualitative state -> context -> detector or rule -> decision record. The historical timestamp is earlier, but the computational dependencies are downstream. This distinction is central to a precise relabeling model.

1.1 Research questions

• How did the xbot snapshot reconstruct extrema and rematerialize affected waves, targets, and factor-state arrays?

• How does the later PFS snapshot distinguish historical event position from current confirmation time?

• Which context branches are event-sensitive, and which can remain valid after an event revision?

• How should a lineage graph, revision ledger, and replay cutoff be represented so that rebuilding is deterministic and testable?

• What empirical distribution do cascade size, depth, wall-clock cost, and affected decisions follow?

• Under which oracle and resource assumptions could a quantum triage layer outperform the best classical scheduler?

1.2 Contribution

• A code-grounded genealogy from retrospective centred-window labels to causal streaming confirmation and hierarchical event levels.

• A precise separation between event time, confirmation time, materialization time, and decision cutoff.

• A branch-selective dependency model that preserves fixed-window, microstructure, and external context when an event-only branch changes.

• Implementation-ready pseudocode for versioned events, descendant invalidation, topological rebuild, idempotent replay, and cascade accounting.

• A classical benchmark ladder: full rebuild, bounded time-window rebuild, dependency-aware rebuild, and causal append-plus-revision processing.

• A conditional quantum formulation with explicit oracle, state-preparation, precision, confidence, and total-cost gates.

2. Evidence base and corrected object model

The earlier draft usefully identified revision as a computational problem, but Papers V and VI now provide a more precise ontology. A predictive factor is not a Phylon. A subpf is a qualitative predicate generated from a factor. A combination is a conjunction of subpf states. A strategy adds explicit negative combination exceptions. A Phylon is a specialized detector that consumes this context substrate for a declared prediction problem and timeframe. The revision paper uses that typed chain throughout.

2.1 Four timestamps, not one

3. Event-sensitive context architecture

Paper V verifies that the context vocabulary is heterogeneous. Morphology, maturity, event regularity, and some range descriptors depend directly on peak/wave structure. Conventional fixed-window indicators can be recomputed from raw bars without a truepeak hierarchy. Order-flow and liquidity geometry originate in order-book and trade data. Calendar, social, market-cap, and Bitcoin-role context have distinct relational sources. All branches are materialized into a common state space, but they do not share the same revision dependency.

3.1 Formal context dependency

Let a materialized context at decision time t be a set of active predicates assembled from several source branches:

C_t^(v) = C_event,t^(v_e) union C_fixed,t^(v_f) union C_micro,t^(v_m) union C_external,t^(v_x)

A revision to event version v_e does not imply that v_f, v_m, or v_x changed. The rebuilt context receives a new aggregate version v, but unaffected branch states can be reused if their source versions and timestamps remain valid. This is the key computational potential of explicit lineage: explainability can reduce work when dependencies are precise.

4. Retrospective reconstruction and bounded rematerialization in xbot

The xbot snapshot contains two related reconstruction paths. WavesQuerySet.frames builds a recent market frame, calculates local extrema, filters them through centred rolling maxima/minima, computes wave fields and configured target outcomes, and replaces Waves and WavesTargets from a bounded apply_change_from_date. For minute periods the window begins five hours before the last persisted wave; for longer periods it begins twenty-four hours before. This is a coarse but operational invalidation boundary.

Artefact 1 — bounded retrospective wave and target replacement

last = Waves(...).order_by('-dt').first() lookback = 5 hours if period is minute-based else 24 hours apply_change_from_date = last.dt - lookback peak = local_extrema(high, low) truepeak = centred_extrema(peak, window=2 * period_truepeak) wave_fields = calculate_wave_state(truepeak, market, order_book) targets = evaluate_all_configured_targets(open, high, low, close) transactionally: delete Waves and WavesTargets from apply_change_from_date bulk_create reconstructed waves and targets
Status: CODE-XBOT / RECON from
bot/models/waves.py: frames. The source uses a concrete recent-time
boundary and transactional delete/bulk-create persistence.

This design has practical value. It avoids relying on a permanently frozen interpretation of the recent boundary, keeps the stored wave table internally coherent, and supplies a deterministic historical reconstruction baseline. It does not preserve decision-time causality because centred extrema use observations to the right of the historical event. That is acceptable for final-label construction provided replay does not expose the final label before it was knowable.

4.1 Hidden-extremum recovery and alternating event structure

The factor-materialization path recalculates truepeak and invokes search_truepeak_hidden. The Cython routine scans the provisional labels, tracks the lowest point after a peak and the highest point after a valley, and inserts the most extreme opposite event when two consecutive labels have the same sign. This preserves an alternating event sequence while recovering extrema hidden by the first filtering pass.

Artefact 2 — hidden-extremum recovery (simplified from the Cython routine)

for label at i: if label == PEAK and last_label == PEAK: recovered[index_lowest_since_last_peak] = VALLEY elif label == VALLEY and last_label == VALLEY: recovered[index_highest_since_last_valley] = PEAK elif label changes sign: reset the opposite-extremum search else: update the lowest or highest hidden candidate
Status: CODE-XBOT / RECON from
performance_c/predictives_factors/truepeak.pyx:
search_truepeak_hidden.

4.2 Incremental factor-state replacement

WavesQuerySet.calcule_subpf starts from the last persisted WavesPF timestamp. For each active factor it retains enough history for the configured lookback, dispatches calculations in a CPU-sized thread pool, materializes active subpf identifiers, optionally appends contemporaneous Bitcoin-role state, deletes WavesPF records from the change timestamp, and bulk-creates the replacement state. The result is incremental in output while still carrying historical padding for transformations.

Artefact 3 — history-padded incremental factor materialization

last_state = last WavesPF timestamp for predictive_factor in parallel(active_factors): lookback = max(configured_timeperiod, 30) frame = history_before(last_state, at_least=2 * lookback) active_ids = dispatch(frame, full_frame, factor,
ordered_subpf_series) factor_columns[factor.id] = active_ids state = concatenate(factor_columns) if focal asset is not Bitcoin and enrichment is enabled: state += contemporaneous_Bitcoin_role_state delete WavesPF from last_state bulk_create replacement materialized states
Status: CODE-XBOT / RECON from
bot/models/waves.py: calcule_subpf.

5. Causal streaming confirmation and event levels in JUBAP-PFS

The later PFS snapshot makes knowledge time explicit. calc_peaks_relevant_stream examines the current direction, finds a candidate extremum since the last relevant opposite-sign event, measures local dominance and an area-relevance condition, removes inferior same-sign candidates when cleaning is enabled, and returns the event only when the current observation lies within a declared confirmation-lag limit. The event is therefore attached to tf_event but becomes known at stream index i.

Artefact 4 — causal relevant-event confirmation

5.1 The API proves the two-time model

In app/peaks/view.py, each confirmed event produces three points. peak_conf is written with the current tuple timestamp and stream index i. peak and peak_area are written with timestamps[tf_peak] and the historical event index. This is direct evidence that confirmation and event position are separate semantic coordinates.

Artefact 5 — emitted confirmation and historical event points

items = [ {ts: current_timestamp, attr: 'peak_conf', index: i, value: side}, {ts: event_timestamp, attr: 'peak', index: tf_event, value: side}, {ts: event_timestamp, attr: 'peak_area', index: tf_event, value:
area}, ]
Status: CODE-PFS from app/peaks/view.py:
ApiView.get.

5.2 Confirmed higher levels and temporary boundary states

calc_peaks_relevant_nivel_stream constructs a higher level from three same-sign child extrema. The middle peak survives when it dominates the left and right peers; proximity and alternation checks can remove or insert neighboring events. calc_peaks_relevant_nivel_tmp_stream separately maintains the still-evolving boundary, including temporary peak and valley codes. This supplies a useful architecture for revision-aware reasoning: immutable confirmed interior events and revisable temporary frontier events can be governed differently.

Artefact 6 — recursive level confirmation and separate temporary frontier

# Higher confirmed level left, middle, right = last_three_same_sign(child_level) if middle dominates left and right: confirm middle at level k+1 remove inferior peers enforce proximity and alternation rules # Temporary frontier last_confirmed = last event at level k+1 if a better same-sign extremum appears: replace the frontier event elif the opposite move persists beyond len_cercania: emit a temporary opposite-sign event
Status: CODE-PFS / RECON from
calc_peaks_relevant_nivel_stream and
calc_peaks_relevant_nivel_tmp_stream.

5.3 Versioned event record

Artefact 7 — implementation-facing event schema

6. From event revision to selective relabeling

A revision is a transition from one event version to another: temporary -> confirmed, confirmed -> superseded, changed historical position, changed level, or changed parent relation. The event may be earlier in event time than the observation that caused the transition. The computational propagation, however, follows dependency edges forward.

6.1 Formal dependency graph

Let D = (V, E) be a directed acyclic derivation graph. Nodes can represent source slices, event versions, waves, factor values, subpf states, context snapshots, combinations, strategies, Phylon outputs, or decision proposals. An edge u -> v means that v was materialized using u. For a revised root r, the affected set is:

A(r) = {v in V : there exists a directed path r -> v}

The cascade size is |A(r)|, its depth is the maximum path length from r, and its weighted cost is the sum of measured rebuild costs over affected nodes. These are empirical quantities. The current source snapshots support a coarse time-bounded rebuild; a complete lineage graph is the research mechanism that makes the cascade explicit and selectively executable.

6.2 Revision types

6.3 What is not yet established

The earlier draft proposed that cascade sizes are heavy-tailed and that every final signal stores a complete peak-level recipe. Both are valuable, testable hypotheses. The supplied snapshots do not yet contain the instrumentation required to establish them. The code verifies bounded rematerialization and event/state objects; the complete distribution and the node-level decision-to-event lineage are OPEN research objects. This boundary strengthens the programme because it converts a narrative claim into a measurable experiment.

7. Classical-first dependency-aware rebuilding

The first research implementation should improve the classical baseline before considering quantum triage. Four rebuild modes provide a clean ladder: full historical reconstruction; legacy bounded time-window replacement; dependency-aware descendant rebuild; and causal append-only processing with explicit revision records. Each mode can consume the same event, factor, state, and target contracts.

7.1 Lineage index and invalidation

Artefact 8 — dependency-aware invalidation

def register(node_id, parents, version, event_time,
knowledge_time): nodes[node_id] = Node(version, event_time, knowledge_time,
status='CURRENT') for parent in parents: dependents[parent].add(node_id) def invalidate_from(revised_node): queue = [revised_node] affected = set() while queue: parent = queue.pop() for child in dependents[parent]: if child not in affected: nodes[child].status = 'STALE' affected.add(child) queue.append(child) return affected
Status: RECON. This is the minimal classical
mechanism required to measure and schedule a relabeling
cascade.

7.2 Deterministic rebuild and context reassembly

Artefact 9 — topological rebuilding under a knowledge cutoff

def rebuild_revision(revision, decision_cutoff): affected = invalidate_from(revision.superseded_event_id) for node_id in topological_order(affected): parents = resolve_parent_versions( node_id, known_by=decision_cutoff, ) rebuild(node_id, parents, algorithm_version=current_algorithm) context = reassemble_context( event_branch=current_event_version, fixed_branch=reuse_if_valid(), micro_branch=reuse_if_valid(), external_branch=reuse_if_valid(), ) return context, cascade_metrics(affected)
Status: RECON. Stable branches are reused only
when source, algorithm, grid and knowledge versions remain
compatible.

7.3 Invariants

7.4 Scheduler potential

Once cascade metrics exist, a classical scheduler can rank pending revisions by expected operational impact rather than raw size alone. A useful priority function can combine predicted rebuild cost, affected active decisions, staleness age, event level, uncertainty margin, and resource availability. This is already a meaningful research contribution: revision-aware scheduling for explainable event-driven models.

priority(r) = w1 * predicted_cost(r) + w2 * active_exposure(r) + w3 * staleness(r) + w4 * level(r)

8. Measuring cascades and near-degeneracy

The distribution of relabeling cost should be measured before it is characterized. Instrumentation must record both structural and operational consequences. A large descendant count can be cheap if descendants are cached; a small cascade can be costly if it reaches an active high-stakes decision. The benchmark therefore separates topology, compute, latency, and decision impact.

8.1 Revision ledger

8.2 Testable hypotheses

8.3 Near-degeneracy margin

A deterministic peak comparison does not by itself require Monte Carlo or quantum estimation. A stochastic discrimination problem appears only when the candidate label depends on noisy measurements, sampled scenarios, uncertain thresholds, or a probability of future confirmation. The benchmark should therefore define a measurable gap, for example the difference between the estimated probability that two competing event hypotheses will remain valid.

Delta = | P(H1 remains valid | evidence) – P(H2 remains valid | evidence) |

Classical and quantum sample-complexity comparisons are meaningful only for this declared stochastic quantity, under matched error and confidence requirements.

9. Conditional quantum triage and the crossover frontier

The classical architecture remains the system of record. Event detection, PFS confirmation, factor calculation, lineage traversal, invalidation, rebuilding, persistence, and online decision use are data-dependent engineering tasks and remain classical. Quantum computation enters only as a possible offline triage or estimation service over a fixed problem instance.

9.1 Candidate Q1: rare cascade-critical revision search

Suppose a fixed batch contains N candidate revisions or revision–dependency hypotheses, M of which satisfy a deterministic criticality predicate f(r)=1. If f can be implemented as a reversible oracle and candidate preparation is efficient, amplitude amplification can find a marked candidate in O(sqrt(N/M)) oracle calls, compared with O(N/M) expected random classical checks. This is a query-complexity candidate, not an end-to-end advantage: the oracle may itself require expensive graph data loading, arithmetic, or partial simulation.

Artefact 10 — required oracle contract for Q1

9.2 Candidate Q2: probability of a large cascade

For a declared stochastic model, define p_r = P(cost(r, omega) > B), where omega indexes uncertain source corrections, parameter draws, or future evidence scenarios. Classical Monte Carlo needs O(1/epsilon^2) samples for additive error epsilon under standard bounded-variance assumptions; canonical amplitude-estimation formulations use O(1/epsilon) coherent oracle queries. The comparison is relevant only if one can coherently prepare the scenario distribution and reversibly evaluate the threshold event.

p_r = E_omega [ 1{ cascade_cost(r, omega) > B } ]

9.3 Candidate Q3: stochastic near-degenerate discrimination

If two event or regime hypotheses are separated by a probability or expectation gap Delta, classical sampling typically scales as O(1/Delta^2) to resolve the sign at fixed confidence, while amplitude-estimation-style access can reduce the query dependence to O(1/Delta). This statement does not accelerate a direct deterministic comparison of two stored prices. It applies only to a sampled or probabilistic evidence model with coherent oracle access.

9.4 Total-cost gate

Every candidate must pass an engineering crossover, not merely an asymptotic query comparison. Let c_prep be state-preparation cost, q the quantum query count, c_oracle the reversible oracle cost, c_other diffusion/uncomputation/error-control cost, and c_read the readout/repetition cost. Let n and c_sample be the matched classical sample count and per-sample cost. Quantum use is justified only when total cost, latency, and error targets all cross the frontier.

C_Q = c_prep + q * (c_oracle + c_other) + c_read < C_C = n * c_sample

10. Playable implementation and research programme

The system can be made tractable for external researchers through a small reference package rather than the entire historical platform. The package needs a stream of prices, a causal event engine, a retrospective final-label engine, a small set of event-sensitive and stable factors, versioned context snapshots, a lineage index, and a revision scheduler. This preserves the core research object while avoiding claims about proprietary trading performance.

10.1 Minimal reference loop

Artefact 11 — end-to-end revision-aware reference loop

for observation in stream: append_raw_observation(observation) confirmations = causal_event_engine.update(observation) for confirmation in confirmations: event_version = persist_event(confirmation) affected = lineage.invalidate_superseded(event_version) rebuilt = rebuild_topologically(affected,
known_by=observation.time) context = assemble_versioned_context(rebuilt, stable_branches) detectors.evaluate(context) revision_ledger.record(event_version, affected, rebuilt) # Offline verification path final_labels = retrospective_engine.reconstruct(full_history) compare_causal_and_final_labels(final_labels, revision_ledger)
Status: RECON. The loop is deliberately
domain-light and can be exercised with synthetic or public time
series.

10.2 Playable toy revision

1. At t=3, the stream records a temporary peak at event_time=2. A morphology factor and subpf state depend on that event; fixed-window RSI and calendar state do not.

2. At t=5, a higher same-sign value causes the frontier event to be superseded. The revision record links event v2 to event v3.

3. The lineage index invalidates the wave, morphology factor, subpf state, context snapshot and matching detector output. RSI and calendar nodes remain current.

4. Affected nodes are rebuilt in topological order using only event versions confirmed by t=5.

5. The revision ledger records descendant count, depth, wall-clock cost and whether the detector proposal changed.

10.3 Core experiments

10.4 Publication contribution

Recommended contribution.
A code-grounded technical
history of revision-aware event semantics: retrospective bounded
reconstruction in xbot; causal event/confirmation separation and
hierarchical frontier states in JUBAP-PFS; a dependency-aware benchmark
for relabeling cost; and a resource-accounted, conditional quantum
triage programme.

This contribution remains valuable even if every quantum crossover is unfavorable. The classical result is an inspectable architecture for causal replay, selective recomputation, explainability, and adaptation under changing event boundaries. The optional quantum work then has a disciplined role: identify precisely which measured workloads, if any, justify reversible search or estimation.

Appendix A. Code-grounded implementation map

Appendix B. Reference event and lineage schema

Artefact 12 — minimal relational schema

Appendix C. Claim and evidence ledger

References

[P1] JUBAP. Predictive Factors. Internal design catalogue, 2017–2019 corpus.

[P2] JUBAP. JUBAP, Libro Blanco. Internal design specification, 2018 corpus.

[P3] JUBAP. PHYLONS 1–7 with LM 4.x + Operations Simulator 3. Internal design specification, 20 June 2018.

[P4] Abril Palma, I. From Predictive Factors to Semantic Windows. Code-grounded working paper v1.0, July 2026.

[P5] Abril Palma, I. Dynamic Combinatorial Search for Semantic Windows. Code-grounded working paper v2, July 2026.

[C1] JUBAP/xbot. Supplied private source snapshot. Code anchors C-X1 to C-X3.

[C2] JUBAP-PFS. Supplied private source snapshot. Code anchors C-P1 to C-P5.

[1] Grover, L. K. A Fast Quantum Mechanical Algorithm for Database Search. Proceedings of STOC, 1996, 212–219.

[2] Brassard, G., Høyer, P., Mosca, M., and Tapp, A. Quantum Amplitude Amplification and Estimation. Contemporary Mathematics 305, 2002, 53–74.

[3] Montanaro, A. Quantum Speedup of Monte Carlo Methods. Proceedings of the Royal Society A 471, 2015, 20150301.

[4] Suzuki, Y. et al. Amplitude Estimation without Phase Estimation. Quantum Information Processing 19, 2020, 75.