Abstract

This paper reconstructs the coordination and execution architecture of JUBAP/Phylons from the 2018 design corpus and the supplied xbot source snapshot. The system did not treat a signal as an executable order. It separated contextual detection, local intent formation, shared-resource authorization, exchange commitment, and realized feedback. The code now verifies a substantial substrate beneath that design: user–exchange credentials, books and currencies, balance snapshots, resource allocations, capital instances, resource-utilization statistics, executable transactions, market-operation lifecycle records, request/response audit logs, an event-driven feed–strategy–broker loop, exchange-neutral order submission through CCXT, order-completion polling, and stop-loss/profit closure through an opposite order. The complete tf15→tf5→tf1 book-supervisor logic, HQ/LQ classification, cross-book netting, sell-first priority, proportional proration, A/B/C/D sale taxonomy, and rich partial-fill ledger remain design-grounded where their full implementation is not present in the supplied snapshot. The contribution is therefore not a claim of autonomous multi-agent trading or investment performance. It is a code-grounded account of an explicit coordination contract: detectors propose; local supervisors size; shared-liquidity governance authorizes; exchange adapters commit; operation records reconcile; and feedback changes the next cycle. This contract is interpretable, testable, and portable to other domains in which many local actors compete for scarce shared resources.

Keywords: multi-agent coordination; expert systems; liquidity orchestration; resource governance; exchange broker; event-driven execution; auditability; replay evaluation

1. The coordination problem

Modern agentic systems often specialize roles before they solve the harder governance problem: how several locally justified actions become a feasible global commitment. In JUBAP, several books could share the same base currency, several detector resolutions could propose actions at the same time, and a sale in one book could release liquidity needed by another. A locally attractive request was therefore not sufficient. The system needed an explicit authority boundary that could see balances, inventory, exchange constraints, and competing requests together.

The historical design answered with a hierarchy of proposals and commitments. Phylons and strategies generated estimates; book supervisors converted them into intents; an exchange broker reconciled the intents under shared balances; and an operations layer converted authorized quantities into orders and feedback. The source snapshot verifies the lower half of this chain and exposes several underused research objects: resource allocations, capital instances, parent–child instance growth, inactive-capital time, persistent order objects, operation status, balance freshness, and request/response provenance.

1.1 Research questions

• Which coordination objects and execution transitions are directly verified in the supplied code?

• How does the design separate proposed quantity, authorized quantity, submitted quantity, and realized outcome?

• How can the design-grounded supervisor and broker policies be reconstructed without confusing them with the verified execution substrate?

• Which invariants make the architecture safe, explainable, replayable, and transferable beyond trading?

1.2 Contributions

• A strict evidence map separating DESIGN-2018, CODE-XBOT, RECON, 2026 interpretation, and OPEN validation work.

• A typed coordination chain from contextual proposal to transaction, market operation, balance update, and feedback.

• Code-grounded reconstruction of resource allocations, capital instances, dead-time statistics, credentials, balances, orders, operation lifecycle, audit logs, event subscriptions, and stop-managed closure.

• Implementation-facing pseudocode for the documented cross-timescale supervisor, exchange broker, proportional allocation, inventory rationale, and replay loop.

• A minimal playable coordination example and a benchmark programme comparing historical centralized, corrected centralized, Contract-Net, and hybrid variants.

• A domain-independent interpretation of the architecture as shared-resource governance rather than a trading-performance claim.

2. Evidence discipline and source map

The paper follows the terminology discipline established in Papers V and VI. A Phylon is a specialized detector, not a factor or a combination; strategies and detector outputs are proposals, while transactions and market operations are commitment objects. The source snapshot is architectural evidence, not a substitute for controlled replay.

3. Historical lineage: knowledge sources, blackboards, and agents

Hearsay-II coordinated heterogeneous knowledge sources through shared state; Contract Net distributed tasks through announcements, bids, and awards; blackboard control separated domain reasoning from the choice of which reasoning step to execute next [1–3]. JUBAP combined related ideas in a centralized operational form. Phylons and strategy rules acted as specialized knowledge sources. Waves, factor states, target outcomes, opportunities, balances, transactions, and market operations formed shared state. Book supervisors proposed locally justified actions, but shared-resource authority remained centralized.

This distinction matters. A component is not an autonomous agent merely because it has a specialized role. JUBAP is best described as centralized multi-actor or agent-like orchestration: local evaluators have bounded objectives and state, while balance ownership, final authorization, and settlement remain governed by account- and exchange-level structures.

4. Typed operational objects and resource topology

4.1 Resource allocation, capital instances, and inactive-capital time

The resource model is more than a generic account balance. ResourceAllocation binds a user, exchange, strategy and base currency to an operation quantity and capital per instance. Instances divide that allocation into free or occupied capital units and allow a child instance to be created from surplus capital. ResourceAllocationStats records capital, instance count, operation count, profit and dead_time—the percentage of time that instances remain inactive because no acceptable opportunity is found.

Artifact 1 — Code-grounded resource-governance objects

[2026-I] dead_time is an unusually useful coordination signal. It distinguishes a strategy that performs poorly while consuming resources from one that leaves allocated capacity unused. In a modern resource governor, dead_time can drive capital reallocation, capacity planning, or a search for complementary opportunities without changing the detector itself.

4.2 Credentials, balances, fees, and audit state

The supplied model places execution under explicit user and exchange boundaries. CredentialExchange stores encrypted API credentials and a sandbox flag. Balance stores currency-specific amounts and freshness. ExchangeCoin stores trading and transfer commission parameters. BitacoraResponse records both the request and the exchange response as structured JSON. These objects create a practical governance perimeter: who may execute, where, with which balance, under which fee model, and with which audit trail.

5. End-to-end architecture and authority boundaries

5.1 Context and strategy substrate

Paper V verifies the lower context layer: exchanges, books, waves, predictive factors, subpf states, target outcomes, cross-asset context and strategy structures. Paper VI verifies the dynamic search layer: support pruning, interaction-constrained positive combinations, negative exceptions, time-budgeted workers and selective active-strategy maintenance. The present paper begins where those papers stop: how a selected proposal is governed as a shared-resource action rather than treated as an automatic trade.

5.2 Proposal, authorization, and commitment

The design’s strongest idea is a progressive reduction of authority. A detector can recommend; a book supervisor can request; a broker can authorize; only an exchange adapter can submit; and only an exchange response can establish the realized state. This prevents model confidence from being confused with ownership of liquidity.

5.3 Four quantities and their implementation correspondence

I_base → I_book → I_ask → I_ordered → I_realized

6. Code-grounded execution and feedback substrate

6.1 Exchange-neutral order creation and balance freshness

ProxyMakeOrder selects a CCXT exchange adapter from the exchange code, loads encrypted user credentials, retrieves free balances, refreshes cached balances after five minutes or on demand, creates market or limit orders, stores the returned exchange order ID in Txn, and records request/response data in BitacoraResponse. This is a concrete commitment boundary: before this call there is an internal proposal; after it there is an external exchange order and a persistent local record.

Artifact 2 — Reduced exchange commitment path

def create_order(user_id, exchange_id, book_id, side, ordertype,
amount, price=None): credentials = CredentialExchange.get(user_id, exchange_id) api = ccxt_adapter(exchange.code, credentials) symbol = Book.get(book_id).as_symbol() response = api.create_order(symbol, ordertype, side, amount,
price) audit_log(request={...}, response=response) if response_has_id(response): return Txn.create( user=user_id, exchange=exchange_id, book=book_id, target_id=response['id'], side=side, ordertype=ordertype, price=resolved_price, amount=amount, ) raise OrderSubmissionError(response)
Status: Faithful reduction of
bot/exchanges/all/proxy_maker_order.py:18–119 and api/orders.py:18–74.
Error handling and market-price resolution are abbreviated for
readability.

6.2 Transaction and market-operation lifecycle

Txn stores the exchange order identity and immutable order intent. MarketOperation links an input transaction to an optional output transaction, a strategy, policy parameters, profit and a lifecycle status. The object is therefore not merely a trade row; it is a two-sided operation envelope that can represent an opening commitment and its eventual closure.

Artifact 3 — Code-grounded order and operation envelope

The JSON params field creates an extension point for policy metadata such as stop thresholds, policy version, risk limits, request lineage or the strategy state that justified the operation. A modern reconstruction should make those fields explicit and immutable at commitment time.

6.3 Event-driven feed, strategy, broker, and observer loop

Artifact 4 — Event subscriptions in the generic motor

for strategy in strategies: strategy.set_feed(feed) strategy.set_broker(broker) motor.on_start(strategy.on_start) feed.on_feed(strategy.on_bars) broker.on_fill(strategy.on_order_fill) motor.start() while not stopped: feed.update_bars() sleep(heartbeat)
Status: Reduced from trader/motor.py:5–42,
trader/observer.py:2–40 and trader/strategy.py:9–35. The generic broker
emits a fill event immediately; concrete exchange execution is handled
elsewhere in the snapshot.

The same observer abstraction can drive live or historical feeds. That symmetry is scientifically valuable: a reconstruction can replay identical strategy and coordination code against a deterministic event stream, while replacing only the exchange adapter and fill model.

6.4 Stop-managed closure through the opposite order

The supplied stop observer provides the clearest complete feedback path. An API order can create an ACTIVE MarketOperation with stop-loss and stop-profit parameters. A long-running worker subscribes to order-book updates, retrieves active operations for the affected book, checks whether the opening order is fully completed, calculates stop conditions, submits the opposite limit order, links it as output, and marks the MarketOperation COMPLETED. This verifies a closed control loop from commitment to monitored exit.

Artifact 5 — Reduced stop-observer closure loop

for operation in active_operations(exchange, book): opening = operation.input stops = evaluate_stop_loss_and_profit(opening, market_history,
operation.params) if stops.triggered: if not exchange_order_is_complete(opening.target_id): continue closing_side = opposite(opening.side) closing = create_limit_order( book=opening.book, side=closing_side, amount=resolved_closing_amount, price=executable_price, ) operation.output = closing operation.status = COMPLETED operation.save()
Status: Faithful reduction of
api/orders.py:47–62, bot/management/commands/worker_stoploss.py:11–21
and bot/strategies/observer_stop.py:140–247.

6.5 Auditability as an architectural capability

BitacoraResponse stores exchange request and response payloads with user, exchange, type and timestamp. Together with Txn.target_id and MarketOperation.input/output, this creates the basis for deterministic incident reconstruction: what was requested, what the exchange returned, which local order record was created, which operation it belonged to, and how it was eventually closed. This auditability is a direct business and governance capability, not only a debugging convenience.

7. Design-grounded supervisor and exchange-broker policy

The historical corpus specifies a richer coordination policy than the supplied execution snapshot implements end to end. The correct treatment is not to discard it, nor to call it code-verified. It should be preserved as an executable reconstruction over the verified order, balance and operation objects.

7.1 Cross-timescale quantity scheduling

The book supervisor processes the fifteen-minute Phylon first, uses its recent requested quantity to adjust the five-minute instance when phases agree, and then uses the five-minute result to adjust the one-minute instance. This is not majority voting. It is hierarchical gain scheduling: slower context changes the authority granted to a faster detector.

I_book,5 ← I_book,5 × I_ask,15(last) / I_buy,15

I_book,1 ← I_book,1 × I_ask,5(last) / I_buy,5

Research potential.
Cross-scale gain scheduling can
be compared with majority voting, independent scale budgets, Bayesian
model averaging, and a constrained portfolio of detector authorities
while holding the underlying detector outputs fixed.

7.2 Buy sizing and sale rationale

The documented buy request combines adjusted book capital, optimal-point confidence, estimated dispersion, utility, stop-loss, optimal price and timing through a power-law heuristic. The formula is best treated as a versioned policy rather than a theorem. More importantly, sales are separated by reason, preserving why inventory is released.

Artifact 6 — Reconstructed reason-preserving sell request

def supervisor_sell_request(macro, inventory, policy): q_a = signal_exit_quantity(macro) if macro.sell_signal else 0 q_b = min(wave_profit_quantity(macro),
inventory.profitable_current_wave) q_c = min(remnant_profit_quantity(macro),
inventory.profitable_remnant) quantity = max(q_a, q_b + q_c) reason = choose_reason(q_a, q_b, q_c) if quantity == 0 and protective_condition(macro): quantity = fallback_exit_quantity(macro, policy) reason = 'D' return BookIntent(side='sell', quantity=quantity, reason=reason, utility=macro.utility_est)
Status: RECON from PHYLONS section D.3.2. The
code is intentionally interface-oriented so that reason, quantity and
policy version remain explicit.

7.3 Netting, quality tiers, lexicographic priority, and proration

Every coordination cycle collects requests from books sharing an exchange. Opposing requests for the same book are netted. Surviving requests are classified into high quality, low quality or rejected according to declared utility thresholds. Sales are processed before purchases because they can release inventory and base-currency capacity. HQ precedes LQ. Scarce coin or base-currency balances are then allocated proportionally within the current tier.

q_net(b) = q_buy(b) − q_sell(b)

x_i = d_i if Σ_j d_j ≤ B; otherwise x_i = B × d_i / Σ_j d_j

Artifact 7 — Playable exchange-level arbitration

def coordinate_exchange_batch(requests, balances, policy): requests = net_opposing_intents_by_book(requests) requests = classify_quality(requests, policy) accepted = [] for side in ('sell', 'buy'): for tier in ('HQ', 'LQ'): for resource, group in group_by_scarce_currency(requests, side,
tier): available = balances.available(resource) - reserved(accepted,
resource) desired = tier_adjusted_values(group, policy) allocations = proportional_cap(desired, max(0, available)) accepted += authorize(group, allocations, resource, tier) return accepted
Status: DESIGN-2018 / RECON. For purchases,
grouping must use the base currency consumed; for sales, it uses the
coin inventory released. Thresholds and multipliers are policy
parameters.

The lexicographic form has a governance advantage: priorities are visible. A modern optimizer could express the same problem as a linear, convex or auction-based allocation, but an opaque scalar objective would hide whether the system values inventory release, signal quality, fairness, concentration, latency or cost. The historical policy makes that ordering inspectable.

7.4 What kind of multi-agent system is this?

The most precise description is centralized multi-actor or agent-like orchestration. The system benefits from specialization while deliberately centralizing the scarce resource. This is not a limitation to hide; it is a design choice that can be tested against distributed alternatives.

8. Inventory, fills, and feedback: verified substrate and implementation frontier

The full potential of the architecture appears when fills are treated as events rather than binary results. An authorization may become several fills; each fill changes balances and open inventory; the remaining reservation may stay active, be repriced, or be cancelled. The supplied snapshot provides the exchange order identity and lifecycle envelope needed to build this richer ledger, but it does not yet justify claiming that the complete partial-fill accounting is code-verified.

Artifact 8 — Recommended event-sourced execution state

9. A minimal playable reference implementation

The architecture can be made understandable and testable without recreating the entire trading system. The following contracts isolate coordination from forecasting. A replay can supply synthetic proposals, balances and fills, allowing the broker policy to be changed while all detector outputs remain frozen.

Artifact 9 — Minimal coordination contracts

Artifact 10 — One deterministic coordination cycle

def coordination_cycle(proposals, balances, exchange,
policy): net = net_by_exchange_book(proposals) classified = classify(net, policy) # Inventory-releasing actions change the feasible set first. sell_auth = allocate_sales(classified, balances, policy) balances.reserve(sell_auth) buy_auth = allocate_buys(classified, balances.after_expected_sales(),
policy) balances.reserve(buy_auth) orders = [exchange.submit(a) for a in sell_auth + buy_auth] fills = exchange.reconcile(orders) balances.apply(fills) return fills
Status: RECON. A causal replay should replace
“after_expected_sales” with the precise historical rule: reserve only
what the policy permits and apply actual released liquidity only after
realized fills.

9.1 Small numerical example

Assume two HQ buy intents share USDT. Book A requests 700 and Book B requests 600. Available USDT is 1,000. A sale processed first can release 200. Proportional allocation makes the policy’s effect transparent:

The example does not evaluate trading quality. It shows a coordination property: sequencing inventory release before purchase allocation changes the feasible resource set and reduces unserved demand. The same example can be replayed with first-come-first-served, equal shares, utility-weighted proration, an auction, or a concentration-constrained optimizer.

10. Coordination invariants and governance tests

These invariants turn architecture into a test suite. They are more durable than any particular threshold. A replay implementation should reject a coordination policy that violates conservation or causality even if its simulated return appears attractive.

11. Research programme and implementation opportunities

11.1 Controlled coordination benchmark

11.2 Metrics

• Feasibility: overdrafts, double reservations, oversold inventory, invalid pair conversions and unreconciled balances.

• Coordination value: authorized high-quality demand, low-quality demand, unserved utility, released liquidity and dead_time.

• Execution: fill ratio, time to fill, cancellations, residual reservations, slippage, fees and open inventory.

• Risk: concentration, turnover, exposure duration, stop frequency and policy-induced leverage.

• Systems cost: decision latency, messages, database writes, deterministic replay and recovery after adapter failure.

• Governance: attributable rationale, policy-version coverage, causal-time compliance and reconstructability.

11.3 Ablations

• Remove netting or sell-before-buy priority.

• Collapse HQ and LQ into one tier or vary the HQ multiplier.

• Replace proportional allocation with first-come-first-served, equal shares, utility weights or an auction.

• Remove cross-timescale gain scheduling.

• Remove reason-coded exits or negative-evidence filtering.

• Treat orders as binary instead of partial-fill event streams.

• Disable dead_time-driven reallocation and parent–child instance growth.

11.4 Underused software potential

11.5 Transfer beyond liquidity management

The architecture is domain-independent whenever many local actors share a scarce resource and execution reveals the final state. SignalProposal becomes a demand proposal; BookIntent becomes a local resource request; BrokerAuthorization becomes a governed allocation; Txn becomes an external commitment; MarketOperation becomes a lifecycle record. The same pattern applies to cloud capacity, manufacturing slots, maintenance windows, logistics capacity, energy dispatch, programme budgets and application-portfolio investment.

12. Publication contribution and conclusion

The strongest publication claim is not that JUBAP produced profitable trades or that it implemented a fully autonomous multi-agent market. It is that the architecture made shared-resource authority explicit. The design distinguished detector evidence, local requests, exchange-level authorization and realized execution; the supplied code verifies many of the persistent and event-driven objects needed to operationalize that distinction.

The code-grounded contribution is concrete: encrypted user–exchange credentials, balance freshness, books and currencies, resource allocations, capital instances, inactive-capital statistics, transactions, market-operation lifecycle, request/response audit logs, exchange-neutral submission, event subscriptions, order-completion checks, and stop-managed closure. The design-grounded contribution is equally valuable when labelled correctly: multiscale supervisors, reason-preserving exits, intent netting, quality tiers, sell-first arbitration and proportional allocation.

The next step is a faithful replay package, not a stronger narrative claim. By freezing detector outputs and varying only the coordination policy, the programme can measure when centralized arbitration is simpler and safer, when distributed bidding adds value, and which parts of the historical design generalize to other resource-governance domains.

Appendix A. Code-grounded implementation map

Appendix B. Canonical artifact interfaces

Appendix C. Claim and evidence ledger

References

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

[P2] JUBAP. PHYLONS 1 to 7 with LM 4.x + Operations Simulator 3. Internal design specification, version 2.4, 20 June 2018.

[P3] JUBAP. Predictive Factors. Internal factor catalogue, 2017–2019 corpus.

[P4] JUBAP. Operations_2018-09-15_16-14-08.xls and related simulation ledger artifacts.

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

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

[C1] JUBAP/xbot. Supplied private source snapshot. Code paths enumerated in Appendix A.

[1] Erman, L. D., Hayes-Roth, F., Lesser, V. R., and Reddy, D. R. The Hearsay-II Speech-Understanding System: Integrating Knowledge to Resolve Uncertainty. ACM Computing Surveys 12(2), 1980, 213–253.

[2] Smith, R. G. The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver. IEEE Transactions on Computers C-29(12), 1980, 1104–1113.

[3] Hayes-Roth, B. A Blackboard Architecture for Control. Artificial Intelligence 26(3), 1985, 251–321.

[4] Xiao, Y. et al. TradingAgents: Multi-Agents LLM Financial Trading Framework. arXiv:2412.20138, 2024. Used only as a contemporary comparison.