Abstract

This paper reconstructs the context-construction layer of JUBAP/Phylons from its design documents and the supplied source snapshots. The 2018 architecture did not treat a current numerical value as self-explanatory. It represented the present through price and volume dynamics, event morphology, position inside a wave, order-flow behaviour, cross-market relations, calendar and social context, and geometric support or resistance. The code-grounded contribution is now concrete. The xbot snapshot routes 54 predictive-factor families, dynamically expands TA-Lib candlestick functions, builds quantitative subpf definitions as lower-bounded, upper-bounded and all-pair bounded predicates, ranks them in three ordered series, computes factors in parallel, materializes active state identifiers and target outcomes by wave, and appends Bitcoin factor state to non-Bitcoin contexts. A later JUBAP-PFS snapshot implements streaming relevant-peak confirmation, temporary extrema and recursive event levels with explicit knowledge-time separation. The source register still remains broader than one implementation snapshot: it contains 128 document slots, 84 named entries and a form-factor entry expanding into 61 candlestick candidates. Historically, the system made a rich context vocabulary enumerable, persistent and usable by specialized Phylon detectors and interpretable rule search. Retrospectively, the resulting factor-state configurations can be analysed as early semantic-window candidates. The 2026 Contextual Sufficiency framework formalizes what the earlier architecture did not claim to prove: whether a selected context is sufficient, minimal, stable, uncontaminated and worth its acquisition cost. The relationship is therefore evolutionary and code-grounded, not an anachronistic identity.

Evidence and terminology discipline

The paper uses the following labels throughout:

Code-grounded scope of this edition

The supplied code directly verifies the factor model, 54-family dispatcher, TA-Lib pattern expansion, wave and target persistence, overlapping subpf construction, three ordered predicate series, cross-asset Bitcoin context, parallel/incremental factor materialization, combination and strategy data structures, and a later causal streaming peak engine. Dynamic alignment and the detailed LM 4.x residual learner remain design-grounded where the corresponding complete implementation is not present in the supplied snapshot. The paper makes no trading-return claim and treats the code as architectural evidence, not as a substitute for replay. Companion papers separately own combinatorial search, shared-resource execution, revision-aware rebuilding, and the cross-lineage optimization synthesis.

1. The problem before the terminology

The design problem was not simply to predict a price. The same numerical observation could support different decisions depending on where it occurred, what preceded it, at which temporal resolution it was measured, what other market variables were doing, and whether the current event anchor was provisional or confirmed. The architecture therefore treated meaning as relational. A value became operational only after the system specified its context.

In modern notation, a contextual factor can be represented as:

[DESIGN-2018] The primary factor document repeatedly fixes these elements. For example, wave_shape uses price, transforms it into a ratio of average ascending and descending slopes, evaluates the last 50 true waves, operates at wave resolution, and assigns the result to a predefined control-point interval. volume_coin_market compares a coin-specific normalized volume against the rest of the market, thereby expanding relational scope beyond the focal book. buy_on_the_fly reconstructs urgent order-flow that appeared between order-book observations, thereby adding actor behaviour at the microstructural resolution.

[2026-I] These objects are best interpreted as candidate semantic-context projections. The code adds a decisive refinement: a quantitative factor does not map only to one adjacent bin. It defines a family of nested and overlapping predicates that can express broad, intermediate and narrow contextual descriptions. No single factor necessarily supplies sufficient context; the operational object is formed when selected predicates, event anchors, scales, cross-asset states and exclusions are combined for a declared distinction.

2. The 2018 context-construction architecture

2.1 Data and account topology

[DESIGN-2018 / CODE-XBOT] The data model contains exchanges, books, symbols and currencies. A book binds an exchange, traded currency and base currency. The factor pipeline is evaluated by exchange, book and period, while the code can enrich a non-Bitcoin wave with the contemporaneous Bitcoin factor-state array. This preserves a focal-book decision object while making market-relative context directly operational.

2.2 Targets define the decision distinction

[DESIGN-2018 / CODE-XBOT] Targets are not labels such as “up” or “down” only. The code iterates through configured Target objects and stores, for each wave and target, achievement, maximum gain, time to maximum gain, realized gain after stop or timeout, and duration. The factor system is therefore target-conditioned: the same context can be evaluated against several profit, stop and maximum-time definitions.

Artefact 1 – target evaluation and materialization (code-grounded pseudocode)

for target in Target.objects.all().order_by('profit'):
achieved, gain_max, time_gain_max, gain, time_stop = calcule_target_gain(
open, high, low, close,
profit=target.profit,
perc_stop_loss=target.capital_stop_loss,
perc_stop_gain=target.profit_stop_loss,
stop_duration=target.max_time)
wave_target[target.id] = [achieved, gain_max, time_gain_max, gain, time_stop]
persist(WavesTargets(dt, book, exchange, period, targets=wave_target))

2.3 The typed object chain

2.4 Code-grounded implementation snapshot

[CODE-XBOT] The implementation uses Django/PostgreSQL models for persistent context, Pandas/NumPy and TA-Lib for vectorized factor calculations, Cython kernels for event and target-intensive paths, and a ThreadPool sized to available CPU cores for factor dispatch. The operative chain is explicit: PredictiveFactors defines the measurement and control points; SubPredictiveFactors defines qualitative predicates; dispatch selects one of 54 factor families; WavesPF persists active factor-state identifiers; WavesTargets persists target outcomes; and combination/strategy models consume those arrays.

Artefact 1A – parallel and incremental context materialization (code-grounded pseudocode)

pf_list = active factors overlapping the requested period
for pf in parallel(ThreadPool(cpu_count()), pf_list):
params = ParamsPredictiveFactors[pf]
subpf_series = SubPredictiveFactors.get_series(pf.id, is_bitcoin)
active_ids = dispatch(recent_frame_with_history_padding, full_frame, pf, subpf_series, params)
factor_columns[pf.id] = active_ids

wave_active_state = concatenate(factor_columns)
persist WavesPF(dt, book, exchange, period, predictive_factors=sorted(wave_active_state))
recompute only from the last materialized timestamp, retaining enough history for the longest factor window

3. Temporal and event substrate

3.1 Base waves and grouped timeframes

[DESIGN-2018] The base wave is a configurable time frame, initially one minute. The system also defines waves_n at 5, 10, 20, 40, 80, 150, 300, 600 and 1200 minutes. Each scale carries its own factors and subpf states. The design distinguishes stable completed-day aggregates from a rolling current-day representation whose group boundaries move every minute.

Artefact 2 — static historical and rolling current-day multiresolution state (pseudocode)

# Completed history: fixed daily partitions
for day in completed_days:
materialize_static_waves_n(day, scales=[5,10,20,40,80,150,300,600,1200])

# Current day: rolling partitions anchored at now
on_each_minute(now):
for scale in scales:
current_groups = partition_backwards_from(now, width=scale)
if leading_remainder >= 0.5 * scale:
keep_as_partial_group()
else:
merge_with_first_current_day_group()
compute_current_factor_states(current_groups)

3.2 Retrospective event labels and incremental reconstruction in the xbot snapshot

[DESIGN-2018 / CODE-XBOT] The 2018 design distinguishes presumed and confirmed extrema. In the xbot snapshot, the factor pipeline reconstructs truepeak labels over a recent window using centred price comparisons and a hidden-extremum recovery kernel, then deletes and rematerializes waves and targets from the affected timestamp. This is a retrospective labeling path suitable for historical construction and for a replay baseline, provided decision-time and final labels are kept separate.

Artefact 3 – retrospective event reconstruction and bounded rematerialization

period_truepeak = 21
is_peak = (peak == PEAK) and (high == centred_rolling_max(high, 2*period_truepeak))
is_valley = (peak == VALLEY) and (low == centred_rolling_min(low, 2*period_truepeak))
truepeak = search_truepeak_hidden(high, low, provisional_labels)

apply_change_from_date = last_materialized_timestamp
recompute factor values with history padding before apply_change_from_date
delete WavesPF / WavesTargets from apply_change_from_date
bulk_create reconstructed state and targets

3.3 Causal streaming confirmation and hierarchical levels in the later PFS snapshot

[CODE-PFS] The later PFS snapshot makes knowledge time explicit. calc_peaks_relevant_stream evaluates a possible extremum only after subsequent observations provide local support; it combines immediate left/right dominance with an area-relevance threshold, records the event at its historical position and returns it only when the current index lies within a declared confirmation lag. Higher levels are then created by comparing triples of same-sign child extrema, while separate temporary states represent the still-evolving boundary. The resulting object distinguishes event time from confirmation time and supplies a causal multiresolution anchor hierarchy.

Artefact 4 – streaming confirmation and recursive event levels (code-grounded excerpt)

# Level-1 relevant event, confirmed at current stream index i
side, tf_event = calc_peaks_relevant_stream(
i, price, peaks_level_1, areas,
len_zone=100, perc_relevante=0.05, limit_nconf=15)
if side != IS_NULL:
emit(event_time=tf_event, confirm_time=i, side=side, area=areas[tf_event])

# Level k+1: retain the middle same-sign child only when it dominates
confirmed = calc_peaks_relevant_nivel_stream(
i, price, peaks_level_k_plus_1, peaks_level_k,
len_cercania=8, alternancia=1)

# Temporary boundary maintained separately
calc_peaks_relevant_nivel_tmp_stream(i, price, peaks_level_k_plus_1)

3.4 Dynamic alignment as an intermediate boundary-selection layer

[POST-2018-D / RECON] A later design note, Alineación Completa, adds a direct anchor-selection procedure on top of the potential and hierarchical-peak machinery. It begins from the base of a selected potential, aligns the potential to the current timeframe, identifies the current sign, searches leftward for an opposite-sign inflection, constructs a bounded ordered set of same-sign candidate peaks, and selects the first candidate satisfying five comparative conditions across the aligned signal R, a higher-resolution or companion signal R+, and price P. If no candidate satisfies all conditions, the procedure abstains and performs no alignment. [The underlying true-peak event substrate is documented in S7.]

This is more than another predictive factor. It changes which historical origin is used to interpret the present. In semantic-window language, it is an explicit candidate boundary selector: the left boundary is not fixed by elapsed time alone but by event level, sign, inflection structure, relational comparisons and an abstention rule.

Artefact 4A — dynamic event-anchored alignment and abstention (pseudocode reconstructed from Alineación Completa)

def dynamic_alignment_base(potential, R, R_plus, price, now, level_k):
base = find_potential_base(potential)
aligned_potential = align_from_base(potential, base, now)

sign = sign_of_first_level_peak_left(
R, aligned_potential, base, level_k
)
inflection = first_level_peak_left(
base, level_k, required_sign=-sign
)

candidates = []
for peak in ordered_level_peaks_left_of(inflection, level_k):
if peak.sign != sign:
break
candidates.append(peak)
higher_level_peak = peak_at_level(peak.time, level_k + 1)
if higher_level_peak is not None:
candidates.append(higher_level_peak)
break

for candidate in candidates: # documented order: left to right
if all(alignment_tests(candidate, now, R, R_plus, price)):
return candidate
return None # explicit abstention

[2026-I] Dynamic alignment is the first artefact in this lineage that explicitly searches for an event-defined historical boundary rather than only constructing features inside predefined supports. It remains an intermediate method: it does not prove minimum contextual sufficiency, globally correct basin selection, robustness, or least-cost acquisition. Those are separate objects of the complete 2026 programme.

4. The predictive-factor vocabulary

The source’s “128 factors” can therefore refer to the register structure rather than a single unambiguous atomic count. This paper preserves all three document views: 128 slots, 84 named entries and 144 atomic named candidates when the 61 candlestick forms are expanded. The supplied xbot snapshot adds a separate implementation view: a dispatcher routes 54 factor families, several of which accept named suffix variants, while pattern_recognition dynamically invokes TA-Lib candlestick functions. Document count and code-dispatch count are different measures and are reported separately.

Code-grounded implementation coverage

4.1 Activity, volume and shock

This family asks how much activity is occurring, whether it is abnormal relative to a local baseline, whether the activity belongs to the focal coin or to the whole market, and whether recent order creation is changing. It contains both direct normalized measures and event-conditioned measures.

Artefact 5 — representative activity factors (pseudocode)

def volume_index(volume_t, recent_volumes):
return (volume_t - mean(recent_volumes[-21:])) / std(recent_volumes[-21:])

def volume_coin_market(coin_index, market_index_ex_btc):
return coin_index / market_index_ex_btc

def bombing(volume_t, recent_volumes):
return abs(volume_t - mean(recent_volumes[-21:])) / std(recent_volumes[-21:])

[CODE-XBOT / 2026-I] volume_index, volume_volatility, bombing, volume_behaviour and the volume-rate families are routed directly by the dispatcher. They are candidate observations of activity intensity, shock and event-conditioned effectiveness. Their later interpretation as regime or fragility descriptors remains an empirical question rather than an assumption.

4.2 Momentum and conventional technical state

[CODE-XBOT] The dispatcher implements conventional indicators as parameterized families rather than one fixed formula per document row. MACD and Bollinger use suffixes to produce qualitative states such as acceleration, sign, crossover, breakout and hot-zone proximity; ROC can be applied to named frame columns; ATR, beta, RSI, stochastic and Williams %R use configurable lookbacks. This turns familiar indicators into typed contextual statements rather than a flat numeric feature vector.

Artefact 6 — state, rate and acceleration features (pseudocode)

macd = ema(price, 26) - ema(price, 12)
macd_accelerating = macd > ema(macd, 9)
macd_upper = macd > 0
roc_price = price_t / price_t_minus_1
roc_price_I = roc_price_t / roc_price_t_minus_1
beta_change_II = beta_7 / beta_21

4.3 Morphology, phase and event structure

[CODE-XBOT] The morphology module calls Cython kernels over truepeak and peak arrays to calculate ascent/descent shape, FUD/FOMO balance, shape change, event regularity, range, wave maturity and maturity-rate families. These factors use event-defined supports and multiple memories rather than only rectangular bar windows. Their inclusion in the dispatcher verifies that morphology was part of the operational context substrate.

Artefact 7 — morphological asymmetry and temporal regularity (pseudocode)

def wave_shape(true_waves, n=50):
asc = mean((w.peak_price - w.valley_price) / (w.peak_time - w.valley_time)
for w in true_waves[-n:])
desc = mean((w.next_valley_price - w.peak_price) / (w.next_valley_time - w.peak_time)
for w in true_waves[-n:])
return asc / desc

def wave_regularity(true_waves, n=7):
durations = inter_peak_durations(true_waves[-n:])
return std(durations) / mean(durations)

[2026-I] wave_shape is a strong example of a semantic transformation: it measures the character of a movement, not merely its level. wave_regularity is a temporal-irregularity descriptor. A relationship with critical slowing down is a hypothesis, not a source-established fact.

4.4 Contextual position and maturity

These factors locate the present relative to recent structural memory. They ask how far the current wave has progressed in price and time, whether its range is expanding or contracting, and how recently the current price was last observed.

Artefact 8 — positional maturity inside the active wave (pseudocode)

def wave_price_maturity(price, last_extremum, expected_range, ascending):
signed_distance = price - last_extremum.price
if not ascending:
signed_distance = price - last_extremum.price # negative in a falling phase
return signed_distance / expected_range

def wave_time_maturity(now, last_extremum_time, expected_duration):
return (now - last_extremum_time) / expected_duration

4.5 Order flow and microstructure

[CODE-XBOT] The Waves model persists order-book volume, count, range, mean, standard deviation and distance fields; the dispatcher converts these into ask/bid divergence, changing divergence, emergent buy/sell activity, weighted distance, dispersion and new-order states. The architecture therefore places participant commitments and liquidity geometry in the same qualitative context space as price and event morphology.

Artefact 9 — emergent order flow and liquidity distance (pseudocode)

def buy_on_the_fly(previous_book, executed_trades, traded_price_range):
resting_volume = previous_book.buy_volume_within(traded_price_range)
executed_volume = executed_trades.buy_volume_within(traded_price_range)
emergent_volume = max(0, executed_volume - resting_volume)
return emergent_volume / max(executed_volume, EPS)

def buy_distance(current_price, buy_orders):
weighted_buy = weighted_mean([o.price for o in buy_orders], [o.quantity for o in buy_orders])
return (current_price - weighted_buy) / current_price

The original “hallacas” explanation is operationally important: the factor intentionally excludes distant resting bids and estimates how much traded volume must have arrived between observations in the actually traded price range. It therefore represents urgency, not total displayed interest.

4.6 Calendar, social and cross-market context

[CODE-XBOT] Hour and weekday are dispatched as qualitative states. Social mention volume is resampled to the book period and compared with historical baselines. Market-relative factors and the Bitcoin enrichment path extend the context beyond the focal series, making relational scope an implemented data-flow property rather than only a conceptual category.

4.7 Geometric support, resistance and symbolic form

The Technical_analysis entry specifies moving-curve hot zones, recursively higher-order extrema, candidate straight lines through pairs of extrema, crossover confirmation and incremental maintenance of line candidates. The form_factors entry expands 61 TA-Lib candlestick patterns into Boolean factor candidates. These are different representation strategies: one builds geometric memory from historical anchors; the other maps local bar configurations to symbolic states.

Artefact 10 — geometric support/resistance memory (pseudocode)

# Incremental straight-line candidate maintenance
for each new confirmed_extremum e:
for prior_extremum p of compatible level and sign:
line = interpolate(p, e)
line.hot_zone = line.price_at(t) ± 7.5%
if not confirmed_crossed_twice(line, later_wave_pairs):
retain(line)

# Heavy historical construction is performed once;
# subsequent updates use only new extrema.

5. Control points and subpf state construction

5.1 From control points to an overlapping predicate lattice

[DESIGN-2018 / CODE-XBOT] Saving a quantitative PredictiveFactors object expands every unique control point c_i into two one-sided predicates, x > c_i and x < c_i, and every ordered pair c_i < c_j into a bounded predicate c_i < x < c_j. The model creates separate definitions for Bitcoin and non-Bitcoin roles. Qualitative factors instead create equality predicates for each declared state. The implemented representation is therefore an overlapping ordinal predicate lattice, not merely a partition into adjacent bins.

Artefact 11 – code-grounded quantitative and qualitative subpf generation

def save_predictive_factor(factor):
C = sorted(unique(float(x) for x in factor.control_points))
for asset_role in (BITCOIN, NON_BITCOIN):
if factor.is_quantitative:
for c in C:
get_or_create(SubPF(pf=factor, gt=c, lt=None, asset_role=asset_role)) # x > c
get_or_create(SubPF(pf=factor, gt=None, lt=c, asset_role=asset_role)) # x < c
for c_i, c_j in combinations(C, 2):
get_or_create(SubPF(pf=factor, gt=c_i, lt=c_j, asset_role=asset_role)) # c_i < x < c_j
else:
for q in factor.qualitative_states:
get_or_create(SubPF(pf=factor, eq=q, asset_role=asset_role))

5.2 Three ordered predicate series and compact active-state materialization

[DESIGN-2018 / CODE-XBOT] SubPredictiveFactors.get_series classifies quantitative predicates into three ordered series: A for bounded intervals, B for lower-bounded predicates and C for upper-bounded predicates. SQL rank() assigns a consecutive order inside each series. At evaluation time the factor pipeline selects at most one active state from each series, so a rich definition space is compressed into a small per-wave state array. With k unique control points, one asset role defines 2k + C(k,2) quantitative predicates; Bitcoin and non-Bitcoin variants together define k(k+3), before timeframe or factor multiplication.

Artefact 12 – three-series ranking, matching and compact materialization

series(subpf) =
A if gt is not null and lt is not null # bounded interval
B if gt is not null and lt is null # lower-bounded
C if gt is null and lt is not null # upper-bounded

rank A by (gt, lt); rank B by descending gt; rank C by ascending lt

for each wave value x:
active = []
active += first matching bounded predicate in series A
active += most-specific satisfied lower predicate in series B
active += most-specific satisfied upper predicate in series C
persist active identifiers in WavesPF.predictive_factors

5.3 Adaptive occupancy-constrained discretization

[DESIGN-2018 / retained implementation excerpt] The later InspectorSubpfs design adapts the expert grids. A state occurring in more than 25% of macros is split at its midpoint; a state below 5% is merged with the lower-occurrence adjacent state. This is not parameter-free: the 5%, 25%, iteration count and neighbour rule are parameters. It is best described as occupancy-constrained adaptive discretization.

Artefact 13 — adaptive subpf occupancy control (retained code excerpt)

cpdef evaluate(self, int bucles=4): for ...: if pars[i][num_cases] < total * PERCMIN: # < 5%: too sparse merge_with_smaller_neighbour(i) if pars[i][num_cases] > total * PERCMAX: # > 25%: too coarse add_control_point_at_midpoint(i) Status: source/code excerpt; retain line-level verification
against the selected repository snapshot.

5.4 Long–short baseline mixing

[DESIGN-2018 / retained LM excerpt] The Phylon learning design normalizes variables against a blend of historical and last-week statistics. The intention is clear: compare a current candidate with both long-run and recent confirmed examples. [2026-I] The later theory treats this as a mixed-memory estimator whose stabilizing effect and regime-contamination bias can be quantified rather than assumed.

Artefact 14 — blended long- and short-memory normalization (retained code excerpt)

norm = (raw - ((all_avg + week_avg) / 2)) / ((all_std + week_std)
/ 2) Status: source/code excerpt; retain line-level verification
against the selected repository snapshot.

6. Materialized semantic state, combinations and targets

6.1 Compute once, retrieve repeatedly

[DESIGN-2018 / CODE-XBOT] The implementation separates raw wave fields, factor-state arrays and target arrays into persistent models. Waves carries market, microstructure, phase and event fields; WavesPF stores the sorted predictive_factors identifiers for each exchange/book/period/timestamp; WavesTargets stores the target-outcome vectors. Candidate evaluation can therefore operate over reusable qualitative state and target memory instead of recomputing every transformation for every rule.

Artefact 15 – persistent wave, factor-state and target objects

Waves(dt, exchange, book, period,
open, high, low, close, volume,
order_book_statistics..., peak, truepeak, phase...)

WavesPF(dt, exchange, book, period,
predictive_factors=[subpf_id_1, subpf_id_2, ...])

WavesTargets(dt, exchange, book, period,
targets=[[order, target_id, achieved,
gain_max, time_gain_max, realized_gain, time_stop], ...])

combination_occurs(C, wave_state) := all(required_state_is_matched(s, wave_state) for s in C)

6.2 Cross-asset context enrichment and incremental refresh

[CODE-XBOT] Subpf definitions are duplicated by asset role. For a non-Bitcoin book, the pipeline can calculate the contemporaneous BTC-USDT context, align it by timestamp and append the Bitcoin state identifiers to the focal asset’s state array. The same routine also avoids full historical recomputation: it starts from the last materialized timestamp and includes a history pad based on the longest factor lookback.

Artefact 15A – relational context enrichment

if focal_book is BTC-USDT:
use Bitcoin-role subpf definitions
elif with_bitcoin:
focal_ids = calculate_subpf(focal_book, role=NON_BITCOIN)
btc_ids = calculate_subpf(BTC_USDT, role=BITCOIN)
aligned_state = focal_ids + btc_ids
else:
aligned_state = calculate_subpf(focal_book, configured_role)

persist sorted(aligned_state) by timestamp

6.3 Positive contexts and negative exceptions

The strategy representation is one positive base combination plus a list of combinations that must not occur. If A, B, C and D are combinations, the rule is:

This architecture is stronger than a flat conjunction because it preserves negative neighbourhood memory: the system can represent not only what usually accompanies success, but what invalidates an otherwise promising context.

6.4 Empirical quality measures

7. Specialized Phylons and the learning machine

7.1 What a Phylon is

[DESIGN-2018] The PHYLONS 1-7 document defines four components: predictive-factor inputs supplied by ETL; categorization into sub states; a supervised-learning “Neuron” mechanism; and target variables carrying an _est suffix. [CODE-XBOT] The supplied source directly verifies the lower substrate consumed by such detectors – factor dispatch, state materialization, targets, combinations and strategy structures. A Phylon is therefore a specialized explanatory detector built on verified context machinery, not a single factor or combination.

7.2 Reversal and recharge are different distinctions

The reversal detector asks whether the first current candidate will confirm as the structural extremum. Recharge asks whether an already confirmed extremum will be superseded by a better same-sign extremum after an intervening opposite-sign event. The latter is a near-degenerate second-extremum problem in operational terms, but no quantum or asymptotic claim is required for the historical contribution.

7.3 The “Neuron” as an interpretable rule ensemble

[DESIGN-2018] The Neuron 3/4 design is not a conventional neural network. It estimates target variables from weighted subpf and representative combinations, measures residual error, mines explicit conjunctions associated with difficult contexts and repeats while compute remains. The supplied jubap-neuron service snapshot confirms later architectural separation of the learning service; the detailed residual-learning algorithm in this edition remains grounded primarily in the LM 4.x design source.

Artefact 16 — LM 4.x weighted rule ensemble and residual-driven refinement (pseudocode faithful to the design formula)

# Documented LM 4.x weighting form
if std_increment < 0.02:
std_increment = 0.02
weight = num_subs * occurrence**(1/3) / (1 + std_increment)

estimated_variable = sum(weight_j * value_j for j in matching_rules) / sum(weight_j for j in matching_rules)

predictive_error = (estimated_increment - realized_increment) / estimated_increment
mine_representative_combinations(macros_with_large_abs_error, sizes=[2,3])
repeat_if_compute_budget_remains()

Later levels add exact-match representative combinations and soft similarity to historically bad macros. Meta-pfs recalibrate the predicted increment using estimated error, realized-error history, positivity and phase memory. These mechanisms are better described as residual calibration and interpretable rule stacking than as hidden-layer neural computation.

7.4 Search and adaptation under a compute budget

[DESIGN-2018 / CODE-XBOT] The Libro Blanco divides search into three phases: build positively interacting combinations; add adverse exception combinations; then combine strategies sharing the same positive base. The xbot learning_machine modules verify time-budgeted workers, persistent combination/strategy models and pairwise admissibility checks. The complete code-grounded optimization treatment – including clique-like positive growth, structured negative exceptions and anytime execution – is developed separately in Paper VI v2.1.

Artefact 17 — bounded three-phase context search (pseudocode)

while process_timer.not_expired():
# Phase I: positive combinations
grow candidates with states that improve fulfillment and meet occurrence floors
periodically persist candidates with utility > 1

# Phase II: negative exceptions
for base A:
add B only if B is negatively interacting with A
retain A - B only if complementary fulfillment improves and support remains adequate

# Phase III: multiple exceptions
combine strategies sharing A while joint synergy remains positive

update statistics incrementally from waves since last review

7.5 Evidence boundary and companion papers

This paper owns the representation and detector substrate: observations, event anchors, factors, subpf predicates, materialized state, target-conditioned context and the formal bridge to semantic windows. Dynamic Combinatorial Search for Semantic Windows, code-grounded v2.1, owns the detailed combinatorial search architecture. Revision-Aware Event Semantics and Relabeling Cascades, code-grounded v2.0, owns causal revision, dependency-aware rebuilding, cascade measurement and the conditional quantum-triage question. From Expert-System Knowledge Sources to Exchange-Level Liquidity Orchestration, code-grounded v2.1, owns the proposal-to-commitment coordination and execution-feedback boundary. Optimization Methods Across the Lineage, code-grounded v2.0, provides the cross-system synthesis. The True-Peak technical note owns the full event-engine genealogy. This separation keeps the present article complete without repeating every downstream algorithm.

8. From empirical contexts to semantic windows

8.1 The defensible evolutionary claim

The 2018 architecture operationalized a context-search problem before the later terminology existed. The code now verifies the core representation: parameterized measurements, event and fixed-time supports, an overlapping predicate lattice, compact materialized wave state, relational Bitcoin enrichment, targets and interpretable context structures. The 2026 framework supplies a formal language for asking whether one of those code-realizable contexts is sufficient, minimal, stable and cost-effective. The later theory therefore formalizes the object exposed by the implementation rather than retrospectively changing its historical semantics.

8.2 A formal bridge

Let a candidate context W select a set of factor-state predicates. In the code-grounded representation, each quantitative factor can contribute lower, upper or bounded interval relations, and the selected state can include both focal-asset and Bitcoin-role predicates. Dynamic alignment may additionally select an event-defined left boundary.

This bridge preserves both achievements. The 2018 system made a rich context enumerable and executable. The 2026 programme asks which parts of that context are actually necessary and when mixed history or unstable anchors make the distinction unreliable.

9. What the 2018 system did not yet prove

10. Verification and research programme

10.1 Reproducibility package

• Freeze the supplied xbot and JUBAP-PFS snapshots as named evidence packages and record file/function anchors for every claim.

• Build a generated factor-to-code registry from the 54-family dispatcher, its suffix variants and the 84-entry design register.

• Reconstruct every experiment twice where relevant: retrospective event labels and causal event-time/confirmation-time labels.

• Persist raw value, active subpf identifiers, asset role, grid version, target outcome and knowledge time in the benchmark dataset.

• Use the code-grounded v1.1 architecture as the faithful reference and a separately named research implementation for modern baselines; do not attach predictive-performance claims before controlled replay.

10.2 Core experiments

10.3 Publication contribution

The strongest publication claim is not that the factor set generated profitable trades. It is that a historical system defined and substantially implemented a structured, multiresolution and interpretable context vocabulary; expanded continuous factors into overlapping ordinal predicates; compressed them into materialized active state; enriched local context with market-relative state; and connected the result to specialized detectors and explicit rule search. The code makes the 2018-to-2026 bridge falsifiable because the historical representation can now be reimplemented, replayed and compared with fixed windows, adaptive windows, modern time-series features and formal minimum-context criteria.

Appendix A. Complete predictive-factor registry

This appendix preserves every named entry in the 128-slot source register. Long descriptions are condensed only where the main paper reconstructs the mechanism. Timeframe and control-point fields are retained. Code status is now grounded against the supplied xbot dispatcher and modules: “direct dispatcher” identifies an explicit family route; “family/suffix route” identifies a documented factor implemented through a parameterized family; “data-field substrate” identifies a factor whose source quantity is persisted in Waves but whose dedicated transform is not directly routed; and “design-grounded” means no direct factor route was found in the supplied snapshot. These labels describe snapshot coverage, not product quality.

A.1 Named factor entries

A.01 volume_index

Definition: (tfn volume – Avg 21 tfn volume) / std 21 tfn volume

Design rationale: Indica el cambio de volumen normalizado (en índice) con respecto al volumen promedio. Para las olas, el volume_index se calcula (tomando solo truepeaks): (ola volume – Avg 21 olasvolume) / std 21 olas volume

Control points / state type: 0.1, 0.25, 0.5, 0.75, 0,85, 1, 1.10, 1.20, 1.30, 1.40, 1.5, 1.75, 2, 2.5, 3, 4, 5, 10, 15, 20, 30, 50, 75, 100, 150, 300

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.02 volume_index_accumulated

Definition: Acumulado / Avg acumulado

Design rationale: EN FASE DESCENDENTE: Para cada wave alejado 25 Tfn o más (zona de confirmación) de un true pico si éste es el true peak más cercano: Buscamos los valles anteriores al wave y posteriores al pico. Si no hay ninguno, volume_index_accumulated=0 Valle = De los valles encontrados, tomamos el de menor precio si el precio es menor a wave.price. Si no es menor, volume_index_accumulated=0 Contamos num de Tf desde el valle. Recopilamos: Acumulado = Suma de volúmen de los tfn desde el valle al wave, ambos incluídos Avg Acumul…

Control points / state type: 0.1, 0.25, 0.5, 0.75, 0,85, 1, 1.10, 1.20, 1.30, 1.40, 1.5, 1.75, 2, 2.5, 3, 4, 5, 10, 15, 20, 30, 50, 75, 100, 150, 300, -0.1, -0.25, -0.5, -0.75, -0,85, -1, -1.10, -1.20, -1.30, -1.40, -1.5, -1.75, -2, -2.5, -3, -4, -5, -10, -15, -20, -30, -50, -75, -100, -150, -300

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.03 volume_coin_market

Definition: volume_index_coin / volume_index_market (excluding bitcoin)

Design rationale: Es la relación entre el índice de volumen de la moneda y del mercado excluyendo Bitcoin. Nota que medimos la capitalización de la moneda y de todas las monedas no en el exchange sino en el mercado total de criptos para todos los exchanges

Control points / state type: 0.1, 0.25, 0.5, 0.75, 0,85, 1, 1.10, 1.20, 1.30, 1.40, 1.5, 1.75, 2, 2.5, 3, 4, 5, 10, 15, 20, 30, 50, 75, 100, 150, 300

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.04 volume_behaviour

Definition: Tomando las últimas 150 olas: Avg volume_index para los valles verdaderos / Avg volume_index para los falsos valles

Design rationale: Mide la relación entre el aumento de volumen y su capacidad para producir un valle verdadero, es decir, cambiar una tendencia de descendente a ascendente. Para las olas, el volume_index se calcula (tomando en este apartado tanto picos-valles verdaderos como falsos: (ola volume – Avg 21 olasvolume) / std 21 olas volume

Control points / state type: 0.5, 0.75, 0.85, 1,1.10, 1.20, 1.30, 1.40, 1.5, 1.75, 2, 2.5, 3, 4, 5, 10, 15

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.05 macd

Definition: MACD (26tfn EMA – 12tfn EMA)

Design rationale: http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:moving_average_convergence_divergence_macd

Control points / state type: – 1.5, -1.25, -1.15, -1, -0.9, -0.8, -0.7, -0.55, -0.4, -0.2, 0, 1.5, 1.25, 1.15, -1, 0.9, 0.8, 0.7, 0.55, 0.4, 0.2, 0,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.06 macd_accelerating

Definition: True if MACD (26tfn EMA – 12tfn EMA) > SIGNAL (9 tfn EMA)

Design rationale: http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:moving_average_convergence_divergence_macd

Control points / state type: Boolean

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.07 macd_upper

Definition: True if MACD (26tfn EMA – 12tfn EMA) > 0 else False

Design rationale: http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:moving_average_convergence_divergence_macd

Control points / state type: Boolean

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.08 macd_crossover

Definition: True if 26tfn EMA superó a 12tfn EMA en los últimos 15 tfn, False if 12tfn EMA superó a 26tfn EMA en el último ciclo ascendente. Else null

Design rationale: http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:moving_average_convergence_divergence_macd Ciclo ascendente: periodo desde el último valle verdadero Recuerda que un valle es verdadero hasta que se demuestre lo contrario

Control points / state type: NullBoolean

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.09 macd_center_crossover

Definition: True if MACD superó a signal en los últimos 15 tfn, False si signal superó MACD en el último ciclo ascendete, else null

Design rationale: http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:moving_average_convergence_divergence_macd Ciclo ascendente: periodo desde el último valle verdadero Recuerda que un valle es verdadero hasta que se demuestre lo contrario

Control points / state type: NullBoolean

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.10 macd_divergence

Definition: True if If MACD está reduciéndose (MACD del tfn es menor que MACD del tf anterior ) y signal está aumentando. False If MACD está aumentando (macd del tfn es mayor que MACD del tf anterior ) y signal está reduciéndose. Else Null

Design rationale: http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:moving_average_convergence_divergence_macd

Control points / state type: NullBoolean

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.11 rsi

Definition: RSI del tfn

Design rationale: No long rationale supplied.

Control points / state type: Los que actualmente ya tienes en el sistema

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.12 bollinger_upper_bound

Definition: True if precio está en la upper band de bollinger (es decir entre la línea media que es la SMA a 21 días y la superior que es la SMA + 2 desviaciones típicas) False si está en la lower band

Design rationale: No long rationale supplied.

Control points / state type: Boolean

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.13 bollinger_breackout

Definition: Si estamos en la banda superior de bollinger: True si el precio en último pico cruzó la banda. Es decir precio último pico > 21 EMA + 2 STD. Si estamos en la banda inferior de bollinger: True si estamos si el precio en último valle cruzó la banda. Es decir precio último valle < 21 EMA – 2 STD Else False

Design rationale: No long rationale supplied.

Control points / state type: Boolean

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.14 bollinger_hot_zone

Definition: Si el valor absoluto de: banda superior menos precio es menor de un cuarto de la desviación típica de 21EMA, then True Si valor absoluto de precio menos 21 EMA es menor de un cuarto de la desviación típica de 21EMA, then True Si el valor absoluto de: banda inferior menos precio es menor de un cuarto de la desviación típica de 21EMA, then True Else False

Design rationale: Indica si nos encontramos cerca de una resistencia o soporte de las bandas de bollinger. Consideramos cerca o una hot zone estar a algo menos de media desviación típica (esto es STD de 21 EMA entre tres) Una zona caliente es donde los precios suelen cambiar bruscamente.

Control points / state type: Boolean

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.15 volume_volatility

Definition: Std 21tfn volume / Avg 21 tfn volume

Design rationale: Es la desviación típica en los últimos 21 time frames dividido entre la media en esos time frames. Indica qué tanto fluctúa el volumen normalmente a lo largo de los periodos

Control points / state type: 0.10, 0.25, 0.5, 0.75, 1,1.25, 1.5, 2, 3, 5, 10

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.16 volume_dispersion

Definition: (count tfn entre los últimos 21 en qué valor absoluto del (volumen – Avg volume 21 tfn) > STD )/ 21) / 0. Ello es equivalente a: Calculamos Avg volume (últimos 21 tfn) Calculamos std volume (últimos 21 tfn) Para cada uno de los últimos 21 tfn, contamos cuantos de ellos Abs (tfn-volume – avg volume) > std volume. Dividimos este count entre 0.

Design rationale: ¿Porqué dividimos entre 0.? Porque en una distribución normal, un % de los casos, el volumen se encuentra por encima o por debajo de la desviación típica, sin embargo, si la moneda fue bombeada nos encontraremos una distribución no normal con un número de casos mucho menor. Al final si volume_dispersion < 1, probablemente la moneda fue bombeada

Control points / state type: 0.10, 0.25, 0.5, 0.75, 1, 1.25, 1.5, 2, 3, 5

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.17 bombing

Definition: abs (tfn volume – Avg 21 tfn volume) / std volume 21 tfn

Design rationale: Si la moneda está siendo bombeada en este preciso time frame la tendrá un diferencia de volumen con respecto a la media mayor que la desviación típica

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20, 30, 45

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.18 form_factors LIST

Definition: LIST CDL2CROWS Two Crows CDL3BLACKCROWS Three Black Crows CDL3INSIDE Three Inside Up/Down CDL3LINESTRIKE Three-Line Strike CDL3OUTSIDE Three Outside Up/Down CDL3STARSINSOUTH Three Stars In The South CDL3WHITESOLDIERS Three Advancing White Soldiers CDLABANDONEDBABY Abandoned Baby CDLADVANCEBLOCK Advance Block CDLBELTHOLD Belt-hold CDLBREAKAWAY Breakaway CDLCLOSINGMARUBOZU Closing Marubozu CDLCONCEALBABYSWALL Concealing Baby Swallow CDLCOUNTERATTACK Counterattack CDLDARKCLOUDCOVER Dark Cloud Cover CDLDOJI Doji CDLDOJISTAR Doji Star CDLDRAGONFLYDOJI Dragonfly Doji CDLENGULFING Engulfing Pattern CDLEVENINGDOJISTAR Evening Doji Star CDLEVENINGSTAR Evening Star CDLGAPSIDESIDEWHITE Up/Down-gap side-by-side white lines CDLGRAVESTONEDOJI Gravestone Doji CDLHAMMER Hammer CDLHANGINGMAN Hanging Man CDLHARAMI Harami Pattern CDLHARAMICROSS Harami Cross Pattern CDLHIGHWAVE High-Wave Candle CDLHIKKAKE Hikkake Pattern CDLHIKKAKEMOD Modified Hikkake Pattern CDLHOMINGPIGEON Homing Pigeon CDLIDENTICAL3CROWS Identical Three Crows CDLINNECK In-Neck Pattern CDLINVERTEDHAMMER Inverted Hammer CDLKICKING Kicking CDLKICKINGBYLENGTH Kicking – bull/bear determined by the longer marubozu CDLLADDERBOTTOM Ladder Bottom CDLLONGLEGGEDDOJI Long Legged Doji CDLLONGLINE Long Line Candle CDLMARUBOZU Marubozu CDLMATCHINGLOW Matching Low CDLMATHOLD Mat Hold CDLMORNINGDOJISTAR Morning Doji Star CDLMORNINGSTAR Morning Star CDLONNECK On-Neck Pattern CDLPIERCING Piercing Pattern CDLRICKSHAWMAN Rickshaw Man CDLRISEFALL3METHODS Rising/Falling Three Methods CDLSEPARATINGLINES Separating Lines CDLSHOOTINGSTAR Shooting Star CDLSHORTLINE Short Line Candle CDLSPINNINGTOP Spinning Top CDLSTALLEDPATTERN Stalled Pattern CDLSTICKSANDWICH Stick Sandwich CDLTAKURI Takuri (Dragonfly Doji with very long lower shadow) CDLTASUKIGAP Tasuki Gap CDLTHRUSTING Thrusting Pattern CDLTRISTAR Tristar Pattern CDLUNIQUE3RIVER Unique 3 River CDLUPSIDEGAP2CROWS Upside Gap Two Crows CDLXSIDEGAP3METHODS Upside/Downside Gap Three Methods

Design rationale: Estas fórmulas están tomados de la librería TA LIB. Crearemos 1 factor predictivo por cada fórmula

Control points / state type: Boolean

2026 semantic role: Geometric or symbolic representation of recurring local forms

A.19 roc_price

Definition: (price/prevPrice)

Design rationale: Rate of Change es una medida del cambio del precio en los dos últimos tfn. Nota que no usamos exáctamente la fórmula del TA LIB

Control points / state type: 0.5, 0.75, 0.8, 0.85, 0.875, 0.9, 0.92, 0.94, 0.95, 0.96, 0.97, 0.98, 0.99, 1, 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.08, 1.1, 1.25, 1.35, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.20 roc_price_I

Definition: (roc_price/prev roc_Price)

Design rationale: Rate of Change I es una medida del cambio en el cambio del precio en los dos últimos tfn. Sería conceptualmente similar a la derivada del cambio de precio. Mide la aceleración o desaceleración del crecimiento del precio aun donde no hay corte de las líneas MACD

Control points / state type: 0.5, 0.75, 0.8, 0.85, 0.875, 0.9, 0.92, 0.94, 0.95, 0.96, 0.97, 0.98, 0.99, 1, 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.08, 1.1, 1.25, 1.35, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.21 roc_volume

Definition: (volume/prevVolume)

Design rationale: Rate of Change es una medida del cambio del volumen en los dos últimos tfn. Nota que no usamos exáctamente la fórmula del TA LIB

Control points / state type: 0.5, 0.75, 0.8, 0.85, 0.875, 0.9, 0.92, 0.94, 0.95, 0.96, 0.97, 0.98, 0.99, 1, 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.08, 1.1, 1.25, 1.35, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.22 roc_volume_I

Definition: (roc_volume/prev roc_volume)

Design rationale: Mide la aceleración o desaceleración en el cambio de volumen.

Control points / state type: 0.5, 0.75, 0.8, 0.85, 0.875, 0.9, 0.92, 0.94, 0.95, 0.96, 0.97, 0.98, 0.99, 1, 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.08, 1.1, 1.25, 1.35, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.23 balance_power

Definition: TA LIB balance of power

Design rationale: https://mrjbq7.github.io/ta-lib/func_groups/momentum_indicators.html https://tradingsim.com/blog/balance-of-power/

Control points / state type: 0.1, 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.5, 3, 4

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.24 wave_shape(pendiente a la edicion de las olas)

Definition: Avg (pendiente ascendente / pendiente descendente) last

Design rationale: El propósito es medir la pendiente relativa de los dos lados de las olas para saber si las olas decrecen más rápido que crecen o al revés. Para ello, en las últimas 50 olas calculamos: Pendiente ascendente = promedio de incremento de precio entre cada valle y cada pico dividido entre promedio de tiempo entre cada valle y cada pico: (precio pico – precio valle) / ( hora pico – hora valle) pendiente descendente = igual que la pendiente ascendente pero entre picos y valles (precio valle – precio pico) / ( hora valle…

Control points / state type: 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.5, 3, 4,

2026 semantic role: Shape, phase, hierarchy, and temporal regularity of the event structure

A.25 fud_fomo_balance(pendiente por las olas)

Definition: All pendiente ascendente / True pendiente ascendente

Design rationale: True pendiente ascendente es la pendiente ascendente del whave_shape tal como la hemos calculado anteriormente All pendiente ascendente es la pendiente ascendente del whave shape calculado tanto tomando picos y valles verdaderos como falsos Un fud_fomo_balance > 1 significa que un aumento muy rápido de precio (mucho FOMO) produce cambios no duraderos (= un pico verdadero) en cambio, incrementos más progresivos en el precio (con menos FOMO) produce cambios duraderos ( = picos falsos, que no caen tanto como un pico…

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3,

2026 semantic role: Shape, phase, hierarchy, and temporal regularity of the event structure

A.26 whave_shape_change_I(pendiente por olas)

Definition: wave_shape last / wave_shape last

Design rationale: Si el wave_shape_change es mayor que 1 significa que las olas se están están cambiando su forma y cada vez crecen más rápido. El mercado puede reaccionar al alza en cualquier momento, especialmente si estamos cerca de una zona de resistencia.

Control points / state type: 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4,

2026 semantic role: Shape, phase, hierarchy, and temporal regularity of the event structure

A.27 whave_shape_change_II(pendiente por olas)

Definition: wave_shape last olas / wave_shape last olas

Design rationale: Si el wave_shape_change es mayor que 1 significa que las olas se están están cambiando su forma y cada vez crecen más rápido. El mercado puede reaccionar al alza en cualquier momento, especialmente si estamos cerca de una zona de resistencia.

Control points / state type: 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4,

2026 semantic role: Shape, phase, hierarchy, and temporal regularity of the event structure

A.28 day_time

Definition: Hora del día

Design rationale: La hora del día tiene influencia en los comportamientos de volumen y precios

Control points / state type: Creamos 1 subpf por cada hora: 00:00 a 01:00 etc

2026 semantic role: External, calendar, or relational scope beyond the focal series

A.29 week_day

Definition: Día de la semana

Design rationale: El día de la semana tiene influencia en los comportamientos de volumen y precios

Control points / state type: Creamos 1 subpf por cada día: Lunes, Mártes, etc

2026 semantic role: External, calendar, or relational scope beyond the focal series

A.30 ascendent

Definition: True si el precio del tfn es mayor que el del tfn anterior, Null si es igual.

Design rationale: No long rationale supplied.

Control points / state type: Null Boolean

2026 semantic role: Shape, phase, hierarchy, and temporal regularity of the event structure

A.31 price_forecast

Definition: price_forecast (5 tfn) / wave_n.price

Design rationale: Usamos la función de TA LIB Time Series ForeCast https://www.tradingtechnologies.com/help/x-study/technical-indicator-definitions/time-series-forecast-tsf/ https://mrjbq7.github.io/ta-lib/

Control points / state type: 0.25, 0.5, 0.75, 0.8, 0.85, 0.875, 0.9, 0.92, 0.94, 0.95, 0.96, 0.97, 0.98, 0.99, 1, 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.08, 1.1, 1.25, 1.35, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.32 true_peaks_rate

Definition: En los últimos 50 tfn, número de picos + valles verdaderos dividido entre el número de picos + valles totales (falsos o verdaderos)

Design rationale: Es una medida de volatilidad. Un valor cercano a 1 indica certidumbre en las tendencias del mercado, mientras que un valor bajo indica incertidumbre. Un valor alto, da menos exactitud al cálculo del fud_fomo_balance

Control points / state type: 0.15,0.25, 0.5, 0.65, 0.75, 0.85, 1,

2026 semantic role: Shape, phase, hierarchy, and temporal regularity of the event structure

A.33 wave_regularity(pendientes por olas)

Definition: last : (Std (tiempo entre un pico verdadero y el siguiente) / Avg (tiempo entre un pico verdadero y el siguiente))

Design rationale: Es el promedio de la desviación típica de la duración de las olas (tiempo entre un pico verdadero y el siguiente) dividido entre el promedio de esa duración. Cuanto más alta sea la wave regularity, significa que las olas tienen una duración menos regular. Es una medida de la volatilidad e incertidumbre del mercado.

Control points / state type: 0.1, 0.25, 0.5, 0.75, 0.85, 1, 1.25, 1.5, 2, 2.5, 3, 4, 5,

2026 semantic role: Shape, phase, hierarchy, and temporal regularity of the event structure

A.34 wave_regularity_I

Definition: (Std (tiempo entre un pico verdadero y el siguiente last 7 olas verdaderas) / Avg (tiempo entre un pico verdadero y el siguiente last 7 olas verdaderas)) / (std tiempo ola verdadera completa / avg tiempo ola verdadera completa)

Design rationale: tiempo ola verdadera completa = tiempo entre un pico verdadero y el siguiente

Control points / state type: 0.1, 0.25, 0.5, 0.75, 0.85, 1, 1.25, 1.5, 2, 2.5, 3, 4, 5,

2026 semantic role: Shape, phase, hierarchy, and temporal regularity of the event structure

A.35 ask_buy_divergence

Definition: ask_buy_divergence= Avg (ask-buy)/price last 10 tfn

Design rationale: Monitoreamos cada minuto el valor (ask-buy)/price y lo guardamos en el wave del tf. Si las posturas de compra y venta son más coincidentes, es decir, hay menos diferencia entre ask y buy

Control points / state type: 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.36 ask_buy_change

Definition: ask_buy_divergence last tf / ask_buy_divergence last 10 tf

Design rationale: Si es menor que 1, significa que las órdenes de compra y venta se están volviendo más coincidentes, es decir, hay menos diferencia entre ask y buy que el promedio

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.37 buy_on_the_fly

Definition: buy on the fly / total buy orders

Design rationale: Son las órdenes que no estaban en el libro de órdenes activas y fueron negociadas (aparecieron después en el history) Es un índice: volumen de órdenes negociadas que no se encontraban en el libro de órdenes activas ¿Para qué nos sirve ésto? Es muy probable que las órdenes que no son conditional_bought sean órdenes que se pusieron directamente al precio ask o buy, esto implica que ese mercado se está “calentando” y la gente quiere comprar o vender a cualquier precio. Iván Abril, [28.12.17 12:31] Imagínate, en el momento 1 hay 1000 personas que quieren comprar a 10 bolívares Iván Abril, [28.12.17 12:32] pongamos que son hallacas Iván Abril, [28.12.17 12:32] Y hay otras 1000 personas que quieren comprar hallacas pero a 500 bolivares Iván Abril, [28.12.17 12:32] Luego en el momento 2 nos dicen que se compraron 1500 hallacas al precio de 1000 Iván Abril, [28.12.17 12:33] ¿Cuantas hallacas se compraron «on the fly»? Iván Abril, [28.12.17 12:33] 1500 – 1000 = 500 hallacas con the fly Iván Abril, [28.12.17 12:33] ¿Qué porcentaje de hallacas…

Control points / state type: 0.05, 0.15, 0.25, 0.35, 0.5, 0.75, 0.85, 1,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.38 sell_on_the_fly

Definition: sell on the fly / total sell orders

Design rationale: No long rationale supplied.

Control points / state type: 0.05, 0.15, 0.25, 0.35, 0.5, 0.75, 0.85, 1,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.39 social_networks_post

Definition: Total social networks posts last 24 hours / Avg daily social network post last month

Design rationale: No long rationale supplied.

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20, 30,

2026 semantic role: External, calendar, or relational scope beyond the focal series

A.40 social_networks_post_I

Definition: Avg social networks posts last 7 days / Avg daily social network post last 2 month

Design rationale: No long rationale supplied.

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20, 30,

2026 semantic role: External, calendar, or relational scope beyond the focal series

A.41 social_networks_searchs(pendiente por buscar api de búsquedas)

Definition: Total social networks searchs last 24 hours / Avg daily social network searchs last month

Design rationale: No long rationale supplied.

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20, 30,

2026 semantic role: External, calendar, or relational scope beyond the focal series

A.42 social_networks_searchs_I

Definition: Avg social networks searchs last 7 days / Avg daily social network searchs last 2 months

Design rationale: No long rationale supplied.

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20, 30,

2026 semantic role: External, calendar, or relational scope beyond the focal series

A.43 last_time_actual_price

Definition: Time frames desde la última vez que se alcanzó el precio actual / 300

Design rationale: Tiempo desde la última vez que se alcanzó el precio actual. Si es la segunda vez en poco tiempo que llega al precio actual, posiblemente durante la primera ya se limpiaron las acciones condicionales de los robots. Si nunca se alcanzó el precio actual (estamos en máximo histórico) entonces, last_time_actual_price = 100

Control points / state type: 0.05, 0.15, 0.25, 0.35, 0.5, 0.65, 0.85, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 30, 100

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.44 rising_trades

Definition: (Num de órdenes negociadas al alza / num de órdenes negociadas a la baja) en el tf

Design rationale: Num de órdenes negociadas al alza / num de órdenes negociadas a la baja. Una orden negociada al alza significa que fue negociada por un precio igual o superior que la anterior orden del history Pongamos que: 5,8,6,7,8,9 Cuantos de estos son mayores que el anterior 8,7,8,9.,total 4 E inferiores: 6, total 1 = > Rising trades = 4/1

Control points / state type: 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5, 8,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.45 range

Definition: porcentaje promedio que variaron las anteriores olas. range = (precio del true peak de la ola – precio del valle verdadero de la ola ) / precio del valle verdadero de la ola range = Avg range ( todos, última semana, últimas 7 olas, últimas 2 olas) Así promediamos el range para que se vaya ajustando a la duración de las olas que el mercado está acostumbrado a observar.

Design rationale: No long rationale supplied.

Control points / state type: 0.01, 0.025, 0.05, 0.1, 0.15, 0.2, 0.25, 0.5, 0.75,

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.46 range_change

Definition: range últimas 15 waves / avg(range (total + semana))

Design rationale: No long rationale supplied.

Control points / state type: 0.2, 0.3, 0.5, 0.7, 0.8, 0.9, 1, 1.1, 1.2, 1.3, 1.5, 1.75, 2, 3, 5

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.47 range_change_double

Definition: range last 2 waves / range last 15 waves

Design rationale: Indica si se está formando un triángulo o un triángulo invertido, o bien, hay estabilidad en las olas del book.

Control points / state type: 0.2, 0.3, 0.5, 0.7, 0.8, 0.9, 1, 1.1, 1.2, 1.3, 1.5, 1.75, 2, 3, 5

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.48 range_change_market_I

Definition: range change I book / range change I market

Design rationale: Indica si la formación es específica para esta moneda o si está ocurriendo en todo el mercado.

Control points / state type: 0.2, 0.3, 0.5, 0.7, 0.8, 0.9, 1, 1.1, 1.2, 1.3, 1.5, 1.75, 2, 3, 5

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.49 range_change_market

Definition: range change book / range change market

Design rationale: Indica si la formación es específica para esta moneda o si está ocurriendo en todo el mercado.

Control points / state type: 0.2, 0.3, 0.5, 0.7, 0.8, 0.9, 1, 1.1, 1.2, 1.3, 1.5, 1.75, 2, 3, 5

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.50 wave_price_maturity

Definition: ((precio actual – last truepeak.price)/ precio último valle verdadero) / range

Design rationale: Es el punto donde se encuentra el precio actual con respecto a la ola promedio. Iván Abril, [04.03.18 19:25] Esto es medio complejo pero necesario para «dibujar» las olas y poder hacer los pf siguientes: No pueden dar dos true picos o truevalles consecutivos. Si, por ejemplo, te aparecen dos truepicos seguidos, debes buscar el valle de menor precio entre los dos, y ese lo nombras como truevalle confirmado. Eso lo puedes hacer en los históricos para que haya orden pico-valle-pico-valle, etc Y, en tiempo real, sin necesidad de que se den los dos true picos seguidos: Si el wave 100 es truepico y el wave 140 tiene un precio superior al 100, debemos marcar como truevalle confirmado el menor valle entre los waves 100 y 140. Eso es porque sabemos que después del 100 comenzó a bajar (por lo menos hasta el 125) y luego volvió a subir «bastante», por lo tanto, debe haber un valle (=cambio de tendencia) significativo entre los dos puntos que lo tenemos que poner como truevalle para poderlo estudiar en los pf. Si no hacemos eso, no se dibujan la…

Control points / state type: -0.05, -0.1, -0.2, -0.3, -0.5,- 0.7,- 0.8, -0.9, -1, -1.1, -1.2, -1.3,- 1.5,- 1.75, -2, -3, -5,0, 0.05, 0.1, 0.2, 0.3, 0.5, 0.7, 0.8, 0.9, 1, 1.1, 1.2, 1.3, 1.5, 1.75, 2, 3, 5

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.51 wave_time_maturity

Definition: Calculamos el range_time = tiempo promedio que duraron las anteriores olas. range = (datetime del true peak de la ola – datetime del valle verdadero de la ola ) range_time = Avg range_time (s todos, última semana, últimas 7 olas, últimas 2 olas) Así promediamos el range_time para que se vaya ajustando a la duración de las olas que el mercado está acostumbrado a observar. wave_time_maturity = (datetime actual – datetime último valle verdadero) / range_time

Design rationale: No long rationale supplied.

Control points / state type: 0.05, 0.1, 0.2, 0.3, 0.5, 0.7, 0.8, 0.9, 1, 1.1, 1.2, 1.3, 1.5, 1.75, 2, 3, 5

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.52 roc_wave_maturity

Definition: (roc_price / roc_volume) / Avg (roc_price / roc_volume) para el control point

Design rationale: Calculamos promedio entre roc_price / roc_volume para cada 2-control points del wave_price_maturity Ejemplo: para olas entre 0.1 y 0.2 de wave_price_maturity el promedio de roc_price / roc_volume es 0.01 etc.. Se puede realizar de dos formas: Calculando el Avg (roc_price / roc_volume) Calculando el coeficiente de correlación lineal y poniéndolo en el denominador. Indica el incremento promedio que tiene un aumento de volumen en un incremento del precio. Después, para la wave actual calculamos el price_wave_maturity…

Control points / state type: 0.5, 0.75, 0.8, 0.85, 0.875, 0.9, 0.92, 0.94, 0.95, 0.96, 0.97, 0.98, 0.99, 1, 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.08, 1.1, 1.25, 1.35, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5,

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.53 roc_price_maturity

Definition: (roc_price + roc_price_I) / Avg (roc_price + roc_price_I) para el control point

Design rationale: Calculamos promedio (roc_price + roc_price_I) para cada 2-control points del wave_price_maturity Ejemplo: para olas entre 0.1 y 0.2 el promedio de (roc_price + roc_price_I) es 0.01 etc.. Se puede realizar de dos formas: Calculando el Avg (roc_price + roc_price_I) Calculando el coeficiente de correlación lineal y poniéndolo en el denominador. Indica el incremento promedio que tiene un aumento de volumen en un incremento del precio. Después, para la wave actual calculamos el price_wave_maturity, el (roc_price + roc_…

Control points / state type: 0.5, 0.75, 0.8, 0.85, 0.875, 0.9, 0.92, 0.94, 0.95, 0.96, 0.97, 0.98, 0.99, 1, 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.08, 1.1, 1.25, 1.35, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5,

2026 semantic role: Relative position inside the active wave or against recent structural memory

A.54 buy_distance

Definition: Diferencia (en índice) entre el precio promedio de las órdenes de compra y el precio actual: (actual_price – avg_buy ) / actual_price

Design rationale: Avg buy = Hacemos el precio promedio de las órdenes de compra considerando la cantidad de cada una de ellas Avg ( precio * cantidad) Actual price = Tomamos el wave.price que es (hight+low+close)/3

Control points / state type: -0.2, -0.06, -0.03, -0,015, -0.010, -0.007, -0.005, -0.003, -0.0015, 0, 0.3, 0.2, 0.1, 0.06, 0.04, 0.03, 0.02, 0,015, 0.013, 0.010, 0.007, 0.005, 0.003, 0.0015

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.55 sell_distance

Definition: Diferencia (en índice) entre el precio promedio de las órdenes de venta y el precio actual: ( avg_sell – actual price ) / actual_price

Design rationale: Avg sell = Hacemos el precio promedio de las órdenes de venta considerando la cantidad de cada una de ellas Avg ( precio * cantidad) Actual price = Tomamos el wave.price que es (hight+low+close)/3

Control points / state type: -0.2, -0.06, -0.03, -0,015, -0.010, -0.007, -0.005, -0.003, -0.0015, 0, 0.3, 0.2, 0.1, 0.06, 0.04, 0.03, 0.02, 0,015, 0.013, 0.010, 0.007, 0.005, 0.003, 0.0015

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.56 buy_distance_std

Definition: STD (actual_price – buy) / buy_distance

Design rationale: Nota que (actual_price – avg_buy ) = Avg (actual_price – buy ) STD (actual_price – buy) = La desviación típica entre el precio actual y las órdenes de compra Entonces, buy_distance_std = STD (actual_price – buy) / avg (actual_price – buy)

Control points / state type: 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.57 sell_distance_std

Definition: STD (sell – actual_price) / sell_distance

Design rationale: STD (sell – actual_price) / avg (sell – actual_price)

Control points / state type: 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.58 average_true_range

Definition: Normalized Average True Range last 21 tfn (NATR)

Design rationale: https://mrjbq7.github.io/ta-lib/func_groups/volatility_indicators.html

Control points / state type: 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.59 average_true_range_change

Definition: Average True Range last 7 tfn / Average True Range last 21 tfn

Design rationale: https://mrjbq7.github.io/ta-lib/

Control points / state type: 0.25, 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.60 beta

Definition: Beta last 100 tfn

Design rationale: https://mrjbq7.github.io/ta-lib/

Control points / state type: 0.25, 0.5, 0.75,0.85, 1, 1.1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.61 beta_II

Definition: Beta last 7 tfn

Design rationale: https://mrjbq7.github.io/ta-lib/

Control points / state type: 0.25, 0.5, 0.75,0.85, 1, 1.1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.62 beta_change_I

Definition: Beta last 21 tfn / Beta last 100 tfn

Design rationale: https://mrjbq7.github.io/ta-lib/

Control points / state type: 0.25, 0.5, 0.75,0.85, 1, 1.1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.63 beta_change_II

Definition: Beta last 7 tfn / Beta last 21 tfn

Design rationale: https://mrjbq7.github.io/ta-lib/

Control points / state type: 0.25, 0.5, 0.75,0.85, 1, 1.1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.64 ascendent_wave

Definition: No short definition supplied.

Design rationale: Indica si estamos en una ola ascendente o descendente => Ascendente se refiere a si el último true peak fue un valle Y descendiente si fue un pico.

Control points / state type: NullBoolean

2026 semantic role: Shape, phase, hierarchy, and temporal regularity of the event structure

A.65 count_new_buy_orders

Definition: Número de órdenes de compra nuevas / número de órdenes de compra totales

Design rationale: Se verifican como nuevas, las que no se encontraban en wave anterior

Control points / state type: 0.05, 0.1, 0.2, 0.3, 0.5, 0.7, 0.8, 0.9, 1,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.66 count_new_buy_orders_change

Definition: count_new_buy_orders / Avg count_new_buy_orders last 25 tf

Design rationale: Se verifican como nuevas, las que no se encontraban en wave anterior

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.67 buy_distance_new

Definition: Buy_distance for new buy orders

Design rationale: No long rationale supplied.

Control points / state type: -0.2, -0.06, -0.03, -0,015, -0.010, -0.007, -0.005, -0.003, -0.0015, 0, 0.3, 0.2, 0.1, 0.06, 0.04, 0.03, 0.02, 0,015, 0.013, 0.010, 0.007, 0.005, 0.003, 0.0015

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.68 buy_distance_new_std

Definition: Buy_distance_std for new buy orders

Design rationale: No long rationale supplied.

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.69 count_new_buy_orders_0.085

Definition: count_new_buy_orders_+0.0085_higth / count_new_buy_orders_+0.0085_low

Design rationale: Realizamos el count_new_buy_orders para las órdenes de compra con un precio mayor a precio actual * 1.0085 / los inferiores al precio indicado 1.0085 es un 0.85% que es el target inicial

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.70 count_new_sell_orders

Definition: Número de órdenes de venta nuevas / número de órdenes de venta totales

Design rationale: Se verifican como nuevas, las que no se encontraban en wave anterior

Control points / state type: 0.05, 0.1, 0.2, 0.3, 0.5, 0.7, 0.8, 0.9, 1,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.71 count_new_sell_orders_change

Definition: count_new_sell_orders / Avg count_new_sell_orders last 25 tf

Design rationale: Se verifican como nuevas, las que no se encontraban en wave anterior

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.72 sell_distance_new

Definition: sell_distance for new sell orders

Design rationale: No long rationale supplied.

Control points / state type: -0.2, -0.06, -0.03, -0,015, -0.010, -0.007, -0.005, -0.003, -0.0015, 0, 0.3, 0.2, 0.1, 0.06, 0.04, 0.03, 0.02, 0,015, 0.013, 0.010, 0.007, 0.005, 0.003, 0.0015

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.73 sell_distance_new_std

Definition: sell_distance_std for new sell orders

Design rationale: No long rationale supplied.

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.74 count_new_sell_orders_0.085

Definition: count_new_sell_orders_+0.0085_higth / count_new_sell_orders_+0.0085_low

Design rationale: Realizamos el count_new_sell_orders para las órdenes de venta con un precio mayor a precio actual * 1.0085 / los inferiores al precio indicado 1.0085 es un 0.85% que es el target inicial

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Participant behaviour and liquidity configuration at the finest operational resolution

A.75 volume_new_buy_orders

Definition: Volumen órdenes de venta nuevas / volumen de órdenes de venta totales Volumen = precio * cantidad

Design rationale: No long rationale supplied.

Control points / state type: 0.5, 0.75, 0.8, 0.85, 0.875, 0.9, 0.92, 0.94, 0.95, 0.96, 0.97, 0.98, 0.99, 1, 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.08, 1.1, 1.25, 1.35, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.76 volume_new_buy_orders_change

Definition: volume_new_buy_orders / Avg volume_new_buy_orders last 25 tf

Design rationale: Se verifican como nuevas, las que no se encontraban en wave anterior

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.77 volume_new_buy_orders_0.085

Definition: volume_new_buy_orders_+0.0085_higth / volume_new_buy_orders_+0.0085_low

Design rationale: Realizamos el volume_new_buy_orders para las órdenes de compra con un precio mayor a precio actual * 1.0085 / los inferiores al precio indicado 1.0085 es un 0.85% que es el target inicial

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.78 volume_new_sell_orders

Definition: Volumen de órdenes de venta nuevas / número de órdenes de venta totales

Design rationale: Se verifican como nuevas, las que no se encontraban en wave anterior

Control points / state type: 0.5, 0.75, 0.8, 0.85, 0.875, 0.9, 0.92, 0.94, 0.95, 0.96, 0.97, 0.98, 0.99, 1, 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.08, 1.1, 1.25, 1.35, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12,

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.79 volume_new_sell_orders_change

Definition: volume_new_sell_orders / Avg volume_new_sell_orders last 15 tf

Design rationale: Se verifican como nuevas, las que no se encontraban en wave anterior

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.80 volume_new_sell_orders_0.085

Definition: volume_new_sell_orders_+0.0085_higth / volume_new_sell_orders_+0.0085_low

Design rationale: Realizamos el volume_new_sell_orders para las órdenes de venta con un precio mayor a precio actual * 1.0085 / los inferiores al precio indicado 1.0085 es un 0.85% que es el target inicial

Control points / state type: 0.25, 0.5, 0.75, 0.85, 1, 1.15, 1.25, 1.5, 1.75, 2, 2.5, 3, 4, 5,

2026 semantic role: Activity intensity, abnormality, or volume-conditioned context

A.81 Technical_analysis

Definition: No short definition supplied.

Design rationale: CÁLCULO DEL ÍNDICE DE SOPORTE-RESISTENCIA DE LAS LÍNEAS CURVAS Líneas curvas = Para cada wave_n calculamos el SMA 7, 21, 50, 100, 200 y la EMA 7, 21, 50, 100, 200 y la TEMA 7, 21, 50, 100, 200 hot zone I de la línea curva= precio de la línea móvil +- 7.5 % Para cada línea curva tomamos las parejas de truepeak = True, es decir un valle y un pico verdadero consecutivos del wave_40 Si pico1, valle1, pico2, valle2, pico3, valle3. Las parejas sería: pico1-valle1 valle1-pico2 pico2 -valle3 etc… De cada pareja: Tomamos el truepeak de la pareja más cercana a la línea. Eliminamos de la lista los repetidos y los ordenamos (el más antiguo primero) Al costado de cada truepak, le ponemos un valor, el primero tiene valor 1, el segundo 1.05, el siguiente 1.05*1.05. Así, caca uno tiene el valor del anterior elevado a 1.05 Para cada truepeak de la serie que hemos construído, verificamos: Si el truepeak de parejas que se encuentran ambas por encima o por debajo de la línea curva y ninguna de ellas en la Hot Zone, calculamos soporte -resistencia = (l…

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20, 30, 45

2026 semantic role: Geometric or symbolic representation of recurring local forms

A.82 arbitrage

Definition: (book.exchange_leader.price – book.price)/book.price

Design rationale: Diferencia de precio entre el del exchange líder y el exchange actual. Los pf los calculamos para el exchange líder, sin embargo, podemos probar éste pf

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20, 30, 45

2026 semantic role: External, calendar, or relational scope beyond the focal series

A.83 arbitrage_bitso

Definition: (BTC.exchange_leader.price – bitso.price)/bitso.price

Design rationale: Diferencia de precio en Bitcoin entre el exchange líder y Bitso. En momentos en los que el mercado está muy caliente, el diferencia es mayor

Control points / state type: 0.5, 0.75, 1, 1.25, 1.5, 1.75, 2, 2.25, 2.5, 3, 4, 5, 8, 12, 20, 30, 45

2026 semantic role: External, calendar, or relational scope beyond the focal series

A.84 sar

Definition: (price- parabolic sar) / price

Design rationale: https://www.quantopian.com/posts/parabolic-sar-using-ta-lib

Control points / state type: 0.01, 0.02, 0.03, 0.05, 0.07, 0.1, 0.2, 0.5, -0.01, -0.02, -0.03, -0.05, -0.07, -0.1, -0.2, -0.5,

2026 semantic role: Directional state, rate, acceleration, volatility, or band position

A.85 Reserved factor slots

The source contains 44 blank “Name:” entries with generic timeframe and control-point placeholders. They are preserved as evidence that the register was designed for extension, but they are not counted as specified factors and are not assigned retrospective semantic roles.

Appendix B. Candlestick-pattern factors expanded from form_factors

The form_factors entry states that one predictive factor should be created for each TA-Lib form formula. The code verifies the intended mechanism generically: a factor name of the form pattern_recognition__FUNCTION selects the matching function from TA-Lib’s Pattern Recognition group, calculates its symbolic output and materializes the corresponding qualitative subpf state. The 61 source-listed patterns are therefore supported through one dynamic implementation route rather than 61 handwritten functions.

Appendix C. Code-grounded artefact and implementation map

C.1 Canonical source snapshot and remaining validation work

• Treat xbot-master as the primary 2018 implementation snapshot for factor, wave, target and rule-search substrate.

• Treat jubap-pfs-main as a later source snapshot for causal relevant-peak confirmation and recursive streaming levels.

• Generate the factor-to-code register automatically from tree_predictive_factor, suffix families and the Appendix A names.

• Add golden tests for each dispatcher family, each subpf series and Bitcoin/non-Bitcoin enrichment.

• Replay retrospective and causal event labels separately; preserve event_time and confirm_time.

• Validate dynamic alignment against a future implementation without conflating it with the complete 2026 boundary framework.

• Benchmark adjacent bins against the implemented overlapping predicate lattice and equalize compute budgets.

• Keep detector-specific LM formulas versioned by source rather than merging formulas across historical releases.

Appendix D. Source and claim traceability

Appendix E. Code-grounded implementation map

The following map identifies the implementation units on which the code-grounded claims in this edition rest. It is intentionally architectural: it records what each source unit makes operational without turning the paper into a software defect report.

Conclusion

The JUBAP/Phylons architecture deserves study because it made contextual meaning an explicit and substantially implemented computational object. The supplied code verifies a heterogeneous factor dispatcher, event and microstructure substrate, overlapping ordinal predicate lattice, compact wave-level state, target-conditioned outcomes, relational Bitcoin enrichment, persistent rule objects and a later causal streaming event hierarchy. The documents add specialized reversal and recharge Phylons, adaptive representation, dynamic alignment and residual learning. Together they describe a clear technical evolution: expert-defined observations became code-realizable contextual predicates; predicates became materialized and searchable decision memory; experience modified resolution and rule composition; and the 2026 programme formalized the unresolved questions of sufficiency, minimality, stability, contamination and cost. The research contribution is not that every designed factor or later theorem is already proven. It is that the historical architecture is concrete enough to reproduce, benchmark and falsify as an early implementation of semantic context construction.

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