Paper deep dive
Argonaut: Interactive Visual Exploration for Distributed Optimization
Srijoni Majumdar, Chuhao Qin, Evangelos Pournaras
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 8/1/2026, 1:06:41 AM
Summary
The paper introduces Argonaut, a lightweight, containerized dashboard for interactive, visual exploration of distributed discrete-choice optimization in decentralized settings. It addresses the lack of observability in existing black-box optimization methods by enabling human-in-the-loop interaction. Users can upload datasets, construct agents and options, modify decision spaces, and run multiple algorithm backends (brute-force or iterative decentralized) to inspect local and global objectives. The system is built on a Node.js/React frontend with Python/Java backends, supporting scalability up to 5600 agents and 1M solutions, demonstrating improved solution optimality through guided exploration.
Entities (18)
Relation Signals (17)
Argonaut → builtwith → Node.js
confidence 95% · Built on a Node.js interface
Argonaut → builtwith → React
confidence 95% · This layer is a React frontend on a Node.js stack
Argonaut → builtwith → Python
confidence 95% · extensible Java and Python optimization backends
Argonaut → builtwith → Java
confidence 95% · extensible Java and Python optimization backends
Argonaut → implements → Distributed Discrete-Choice Optimization
confidence 95% · We present Argonaut... that enables interactive, visual exploration of the entire search process for multi-agent discrete-choice optimization
Argonaut → manages → Agents
confidence 95% · construct agents and options
Argonaut → deployedas → Docker
confidence 90% · Argonaut is containerized, packaging its runtime and dependencies into a single portable unit
Argonaut → manages → Plans
confidence 90% · construct agents and options... plans per agent
Argonaut → manages →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Distributed discrete-choice optimization in decentralized settings is often hard to explore and navigate: disentangling what other agents choose, how their choices are interdependent, and how they collectively reach a global objective quickly becomes intractable as the system scales. The major limitation is observability of the search process. Existing methods are largely centralized and offer limited support, visualizing only the final solution or providing algorithm backends over a fixed dataset, so how a solution is reached stays a black box. We present Argonaut, a lightweight, containerized optimization dashboard that enables interactive, visual exploration of the entire search process for multi-agent discrete-choice optimization in decentralized settings. Users upload datasets, construct agents and options, modify the decision space and its parameters on the fly, and run multiple algorithm backends to inspect how each configuration shapes local agent decisions and the resulting global objective. By uniting system construction, optimization, and analysis in one interactive loop, the first of its kind, Argonaut makes distributed discrete-choice optimization a human-in-the-loop process rather than a one-shot, black-box computation. We evaluate Argonaut on real-world household-electricity, shared-mobility, and sensor-data-exchange datasets scaling to 5600 agents and up to 1M solutions under brute force. Built on a this http URL interface with extensible Java and Python optimization backends, it maintains a typical runtime of 200 agents over 100 decision attributes in under 30 seconds.
Tags
Links
- Source: https://arxiv.org/abs/2607.27946v1
- Canonical: https://arxiv.org/abs/2607.27946v1
Trouble viewing inline? Open PDF directly →
Full Text
35,286 characters extracted from source content.
Expand or collapse full text
Argonaut: Interactive Visual Exploration for Distributed Optimization Srijoni Majumdar1, Chuhao Qin1, Evangelos Pournaras12 Abstract Distributed discrete-choice optimization in decentralized settings is often hard to explore and navigate: disentangling what other agents choose, how their choices are interdependent, and how they collectively reach a global objective quickly becomes intractable as the system scales. The major limitation is observability of the search process. Existing methods are largely centralized and offer limited support, visualizing only the final solution or providing algorithm backends over a fixed dataset, so how a solution is reached stays a black box. We present Argonaut, a lightweight, containerized optimization dashboard that enables interactive, visual exploration of the entire search process for multi-agent discrete-choice optimization in decentralized settings. Users upload datasets, construct agents and options, modify the decision space and its parameters on the fly, and run multiple algorithm backends to inspect how each configuration shapes local agent decisions and the resulting global objective. By uniting system construction, optimization, and analysis in one interactive loop, the first of its kind, Argonaut makes distributed discrete-choice optimization a human-in-the-loop process rather than a one-shot, black-box computation. We evaluate Argonaut on real-world household-electricity, shared-mobility, and sensor-data-exchange datasets scaling to 5600 agents and up to 1M solutions under brute force. Built on a Node.js interface with extensible Java and Python optimization backends, it maintains a typical runtime of 200200 agents over 100100 decision attributes in under 3030 seconds. I Introduction Distributed discrete-choice optimization underpins several real-world problems, including scheduling, routing, and resource allocation. Each agent selects a preferred option from a finite set while collectively aiming to optimize a global objective. As agents and options scale, the decision space grows exponentially, making it increasingly difficult to work out how individual choices shape collective behavior. Decentralized settings make this harder still, as agents lack a complete view of one another’s preferences and so of the decision space as a whole. The missing piece is the observability of the entire optimization process: how each agent chooses a plan, when that choice can change, how their choices are interdependent, and how they shape the global objective. This observability makes optimization practical and scalable for the real-time shared-resource decisions in energy, transport, mobility, logistics, and urban infrastructure [35, 29]. It leverages human oversight to steer the process through interventions, e.g., tuning parameters, restricting the decision space, or adjusting the global objective [40, 4, 16], helping agents align on power use, routes, or parking at critical moments, and preventing the disruption that would otherwise follow. Figure 1: Argonaut: Black-Box optimization to visual interactive human in the loop exploration Existing methods offer only a limited view of the process. Some tag whether a solution is a global optimum, letting users re-run the optimization with different parameters to escape a local one, but only for centralized algorithms over a small decision space [5, 15]. Others specifically visualize only the final solution or provide flexible execution through multiple algorithm backends, but only over a fixed set of datasets [37, 8, 9]. The available support thus remains fragmented, lacking an end-to-end observability of the individual and collective agent behavior across the optimization process. We introduce Argonaut111Argonaut—Cloud-hosted service at https://argonautsim-382548405389.us-central1.run.app/ with video [https://youtu.be/NMoVSavMvd8] to run. Running on localhost: code and instructions at https://github.com/TDI-Lab/Argonaut for MacOS, Linux, and Windows. to bridge this gap, bringing multiple discrete-choice optimization paradigms for decentralized settings into a single, lightweight, containerized dashboard. It supports brute-force search over the full decision space; tree-structured decentralized iterative methods that coordinate agents to converge to a solution; and a combination of the two, which ranks that solution against the global optimum found by brute-force search. Argonaut enables human-in-the-loop optimization by uniting construction, optimization, and analysis in one loop, thereby transforming the optimization process from a black box into an observable, interactive, and visual one (Figure 1). Users upload datasets, construct agents and options, prune or edit the decision space on the fly, and run alternative algorithms over the same configuration, intervening to improve the optimality of the solution. We perform a cross-domain evaluation of Argonaut, running brute-force and decentralized search over real-world household-electricity, shared-mobility, and data-sharing datasets, alongside synthetic ones, ranging from 7070 to 56005600 agents with 6464 to 144144 decision scenarios and up to 11M solutions under brute force. Over multiple runs, we test correctness, scalability, and effectiveness: the cloud-hosted service maintains a typical runtime (on localhost) of under 3030 seconds for 200200 agents over 100100 decision attributes on minimal computing resources, guided exploration improves solution optimality on average by 24.87%24.87\%, and non-experts reach near-optimal solutions on par with domain experts. This paper makes three contributions: (i) The first platform of its kind to make the entire optimization process observable and steerable in decentralized settings. (i) A lightweight, portable, and customizable design, a containerized runtime with algorithm-agnostic APIs to configure multiple backends, deployable in the cloud or on standalone systems. (i) A fast and computationally efficient engine, well suited for integration into standard transaction frameworks for operational decisions such as load balancing and scheduling in city infrastructure. The remainder of this paper is organized as follows. Section I reviews related work on optimization visualization. Section I describes the design of Argonaut, including decision-space construction, optimization, and analysis. Section IV details the implementation and deployment. Section V reports the evaluation, and Section VI concludes. I Related Work Prior work on observability in discrete-choice optimization falls into four lines of work, each covering only part of the problem. First, proposed methods tag each achieved solution only by whether it is a global optimum, without any ranking, letting users re-run the search to escape a local optimum; this supports human-guided search, but with only limited interactive control [5, 15]. Second, algorithm-specific tools such as SwarmViz [13] visually monitor particle swarm optimization methods [10, 17] and map high-dimensional Pareto fronts to lower dimensions for trade-off comparison, but remain bound to a particular algorithm, objective structure, or offline setting. Third, some methods use visual steering to configure machine-learning algorithms through hyperparameter tuning and design-space exploration [34, 33, 41]. A fourth line of work covers general optimization software and solvers, including OR-Tools [8], HeuristicLab [11], IOHanalyzer [37], Gurobi [9], and branch-and-bound visualizers [27], as well as decentralized solvers such as COHDA [12] and DCOP methods [42]. These bring multiple algorithm backends into one tool but mostly over fixed datasets, and return only final solutions without interactive inspection of the optimization process. Discrete-choice modeling tools [1, 18] mostly help with choice modeling and estimating model parameters from data rather than navigating the combinatorial decision space of coordinated agents. Across these tools, support is mostly applicable for centralized settings and lacks an end-to-end view, offering no account of how discrete choices are formed, pruned, traversed, and balanced across local and global objectives, which is critical for decentralized systems. Argonaut addresses this gap as lightweight, software that supports the full construct–optimize–analyze loop for discrete-choice optimization. Table I summarizes this comparison across seven capabilities spanning centralized and decentralized settings. TABLE I: Comparison of existing optimization visualizers and software against Argonaut. ✓ indicates support, ✗ indicates no support, and NA means not applicable. Capability Human-guided search [5, 15] Algorithm/dataset- specific [13, 10, 17] Machine-learning specific [34, 33] Standard solvers/ benchmarks [8, 9, 37] Argonaut Parameter modeling ✓ ✗ ✓ ✓ ✓ Global-optimum detection ✓ ✗ ✓ ✗ ✓ Visualization of final solution ✓ ✓ ✓ ✗ ✓ Multiple algorithm backends ✓ ✗ ✗ ✓ ✓ Local & global analysis ✗ ✓ ✗ ✗ ✓ Decentralized multi-agent support ✗ ✗ NA ✗ ✓ Construct–optimize–analyze loop ✗ ✗ ✗ ✗ ✓ I Design of Argonaut I-A Optimization Problem We model a typical socio-technical system as a set of agents A=a1,…,anA=\a_1,…,a_n\, where each agent ai∈Aa_i∈ A is an autonomous decision-making unit, such as a household, vehicle, shipment, station, or user [30]. Each agent aia_i holds a finite set of plans Pi=pi1,…,pikP_i=\p_i1,…,p_ik\, its feasible options, i.e., those satisfying the agent’s local constraints, such as capacity or availability. Every plan describes what an agent would do across a set of decision attributes, such as how much power to draw at each time step, how to allocate a resource, or what demand to place. Formally, a plan pij∈Pip_ij∈ P_i is a d-dimensional vector, with one value per attribute. A collective solution s=(p1,…,pn)s=(p_1,…,p_n) is then one choice of plan per agent, and the set of all such combinations forms the decision space =P1×P2×⋯×PnS=P_1× P_2×·s× P_n, of size ||=∏i=1n|Pi||S|= _i=1^n|P_i|. Three objectives evaluate a collective solution. The global objective measures system-level inefficiency through nonlinear measures such as residual sum of squares and root mean square error, which quantify how closely the collective outcome matches a target global objective bound, or variance, which captures imbalance across agents, resources, or time [14]. These are nonlinear because cost grows disproportionately with imbalance: e.g., in an energy grid, a few households drawing power at the same peak minute strains the network far more than the same demand spread out, and in transport, vehicles converging on one road cause congestion that rises steeply with load. The local objective measures per-agent discomfort, how far an agent’s selected plan sits from its preferred one, e.g., a household shifting its laundry to an off-peak hour, or a driver taking a longer route to ease congestion. The unfairness objective measures how unevenly this discomfort is spread across agents, so that no single household or driver bears all the inconvenience [39]. Argonaut combines these into a single total cost C, weighted by agent-controlled trade-off parameters α,β,γ≥0α,β,γ≥ 0 with α+β+γ=1α+β+γ=1, which set their priority. The goal is to find a feasible collective solution that minimizes C. Argonaut explores this decision space in two modes. (i) Brute force search. It constructs the full decision space S as the Cartesian product of every agent’s plan set, evaluates the total cost C of each collective solution s∈s , and returns the one with the lowest cost, which is the global optimum. (i) Iterative decentralized search. The agents coordinate over successive iterations to refine their choices. In each iteration, every agent aia_i selects the plan from its set PiP_i that minimizes the total cost C, given the current plans of the other agents. This repeats until the objectives stabilize, converging to a near-optimal, or the optimal solution. When complete search is tractable, its global optimum serves as the reference against which any optimality gap of the iterative solution is measured. Figure 2: Schematic architectural view of Argonaut, showing the construct–optimize–analyze loop from decision-space construction, through algorithmic optimization, to interactive visual analytics. (a) Construct component of Argonaut, Pre-configured dataset: (A,Pi,d)(A,\P_i\,d), Number of agents: n=|A|n=|A|, Agent selection mode: subset A′⊆A A, Plans per agent: |Pi|=p|P_i|=p with d Decision attributes, Algorithm type: optimizer over S, Search configuration: brute force / iterative / both, Iteration count: T iterations, Children per node: tree branching factor c, Simulation count: R runs, Objective weights: trade-off parameters (α,β,γ)(α,β,γ) and the local and global objectives and cost functions. (b) Analyzer component of Argonaut, interface for interactive, iteration-by-iteration analysis of costs, convergence, plan changes, and comparative optimization outcomes. Figure 3: Construct and analyzer components of Argonaut. I-B Argonaut Figure 2 shows the architecture of Argonaut. Construct (Figure 3a). Users can define, remove, and edit on the fly the number of agents A=a1,…,anA=a_1,…,a_n, their plans PiP_i, the decision attributes d, and the objectives and trade-off parameters that form the decision space S. Optimize (Figure 2). Argonaut supports multiple algorithmic backends, such as brute-force search, brute-force search with pruning or centralized or decentralized iterative search with multiple algorithms available within each paradigm. A configurable input space is designed to support these multiple backends, combine and compare algorithms and also ranking iterative solutions against the global optimum from brute-force search. Analyze (Figure 3b). Argonaut brings multiple interactive views of the optimization process into one place, covering cost, convergence, optimality, and solution comparison. These views show how global, local, and unfairness costs evolve, how plan selections change across iterations, and how local–global trade-offs are balanced, making the search process more transparent and interpretable. This separation keeps Argonaut algorithm-agnostic and extensible while preserving a continuous construct–optimize–analyze loop (full workflow illustrated in Figure 4). Figure 4: Decision space exploration sequence in Argonaut, showing how users configure parameters, translate them into optimizer ready inputs, execute algorithms, inspect offline visual analytics, and iteratively refine the balance between global performance, fairness, and local cost. IV Implementation of Argonaut Argonaut is engineered around three goals: it should be lightweight, highly portable, and customizable. Construction Layer (Frontend & Translation). This layer is a React frontend on a Node.js stack [26, 20, 36]: React manages the interactive controls (topology, agents, plans, objective weights, cost and iteration views), Node.js serves assets with non-blocking I/O to stay responsive during optimization, and Vite [36] compiles the frontend into static assets, keeping it lightweight. A translation API, a Python module behind a lightweight REST endpoint, then serializes the frontend state into a normalized JSON [26] schema (agents, plans, constraints, objectives, trade-off weights, topology and algorithm) and converts it into the input format each algorithm requires, decoupling encoding so one decision space can drive different solvers, the key to customizable design. Optimization Layer (Solver Backend). In our design, algorithmic backends may be implemented in heterogeneous languages, each encapsulated by a language-specific solver wrapper exposing a uniform REST [7] endpoint. Each wrapper derives from a common base via minimal customization, yielding a language-agnostic, portable, and extensible system. Visualization API (Rendering Engine). The execution traces and topologies are converted into interactive analytics using Python NetworkX [21]. NumPy computes layouts [25], Matplotlib renders reproducible figures [19], and pandas processes .csv.csv logs and tabular summaries [28]. Analysis Layer (Interactive Views): The analysis layer is supported by a lightweight Node.js interface that serves interactive views using dynamic tagged pointers for easy iteration-level analysis [26, 20, 36]. Deployment (Containerized Runtime). Argonaut is containerized, packaging its runtime and dependencies into a single portable unit [3] that is highly portable and thus can be deployed both in the cloud and in standalone systems. A multistage Docker build separates the Node.js build environment from the production server, so the final container holds only the compiled front end and static resources [6], keeping it lightweight. NGINX [6] serves the interface and visualization output as static content through a thin production server [22]. Figure 5: Computation load run in Argonaut, matching that reported for I-EPOS [30]. Scaling of total computations (ap2a\,p^2), critical path (p2⌈log2a⌉p^2 _2a , the longest dependent chain of operations), and communication (p⌈log2a⌉p _2a ) with the number of agents, for plans p∈10,20,40p∈\10,20,40\, run for 10 simulations and 40 iterations. Logarithmic tree depth keeps critical path and communication modest despite steep growth in total computation. V Evaluation For the proof-of-concept evaluation, we use synthetic and domain-specific discrete-choice datasets to assess the correctness, scalability, and effectiveness of Argonaut. The synthetic benchmark contains 10001000 agents, each with 1616 plans and 100100 decision attributes. Attribute values are drawn from a Gaussian distribution [38] and shaped as ya,p,d=xa,p,dcos(2πfpd+ϕa)y_a,p,d=x_a,p,d (2π f_pd+ _a), giving each agent a distinct cosine-wave structure. This dataset is used to test both brute-force search, up to 11M solutions, and decentralized iterative search. The real-world domain-specific datasets [31] cover energy management (56005600 agents, 1010 plans, 144144 intervals), sensor data-sharing (7272 agents, 33 privacy-aware plans, 6464 attributes), and shared mobility (23002300 agents, 22–5050 plans, 9898 bike stations). Figure 6: Argonaut keeps decentralized optimization within practical runtime limits (shown here for localhost), ranging from 2626 seconds to 2828 minutes across up to 50005000 agents and 4040 plans per agent, while brute force already takes 110110 minutes for only 77 agents and 66 plans. Agents: a∈200,500,1000,2000,5000a∈200,500,1000,2000,5000, plans per agent: p∈10,20,40p∈10,20,40, with 100100 decision attributes. We instantiate Argonaut with (i) a brute-force search that enumerates all feasible collective solutions to return the global optimum [23] (i) I-EPOS, a collective learning algorithm [30] for iterative decentralized optimization, as a representative backend. I-EPOS is chosen for its fully decentralized design and low computational and communication overhead, making it suitable for interactive visual exploration. Figure 7: Optimality-gap improvement is highest when changing the target global objective bounds. Optimality-gap improvement (%) per configuration change across 44 runs for 44 runs experts and 44 non-expert users on 44 datasets (6464 runs per group). Cost-function and decision-attribute changes yield the largest improvement, while the number of plans and trade-off parameters have little effect, and the pattern holds across expertise. The optimality gap is g=(C−C∗)/C∗g=(C-C^*)/C^*, where C is the achieved total cost and C∗C^* the optimal solution from decentralized iterative search; improvement is the reduction in g after the change. Correctness and Scalability: Argonaut passes correctness tests across both the centralized brute-force and decentralized tree-based optimization modes. Component-level checks for data loading, plan parsing, objective computation, tree construction all pass successfully [2, 32]. Across 2424 independent runs, the solutions exported by Argonaut match independently executed reference algorithms exactly, verified with a similarity-checker script [24]. This holds for the brute-force mode over decision spaces up to 6060K solutions in cloud and 1M solutions in localhost machines, and for the decentralized tree-based mode over 10001000 to 56005600 agents, 22 to 5050 plans, and 6464 to 144144 decision attributes, while varying the number of iterations, objectives, topology structures, and trade-off parameters. Having established correctness, we next examine how Argonaut scales, using the computation load it reports when running the I-EPOS tree-based decentralized optimizer [30]. Figure 5 decomposes it into total computation, the critical path (the longest dependent chain of operations), and communication cost. At a=5000a=5000 agents and p=40p=40 plans, total computation reaches 8×1068× 10^6 operations, while the critical path stays at 2.08×1042.08× 10^4 and communication at 520520. Total work scales with agents and plans, but coordination depth and communication stay orders of magnitude smaller, matching the figures reported for I-EPOS. Figure 6 reports the measured runtime across configurations. The tree-based optimization ranges from 28s28\,s at (a,p)=(200,10)(a,p)=(200,10) with 100100 decision attributes to roughly 28min28\,min at (5000,40)(5000,40), increasing significantly with the number of plans (pairwise p=0.034p=0.034 for 1010 vs. 2020, p=0.0056p=0.0056 for 1010 vs. 4040, and p=0.024p=0.024 for 2020 vs. 4040). The algorithm stage dominates, on average 7.6×7.6× longer than the visualization API and 7.4×7.4× longer than rendering, with the latter two within a few percent of each other. We conduct scalability testing for brute-force search across decision spaces of increasing size: 5×1045× 10^4 collective solutions take approximately 110110 minutes, while 10610^6 solutions take up to 4444 hours. Its algorithm stage accounts for ≈99%≈ 99\% of runtime, running 111×111× longer than the visualization API and 934×934× longer than rendering; these differences are significant (p=0.0027p=0.0027 algorithm vs. visualization, p=0.00045p=0.00045 visualization vs. rendering). On average, across comparable configurations, brute force is roughly ⟨85⟩× 85 × slower than the decentralized tree-based method, confirming its scalability advantage. Localhost vs Cloud: Argonaut is also cross-software compatible and the reported runtimes (Figure 6) are measured on localhost across MacOS, Linux, and Windows (e.g. 4-core/8-thread CPU and 16 / 32 GB RAM). Argonaut is also available as a cloud-hosted service on Google Cloud Run using free credits; its runtime is on average approximately 40% slower, as the minimal free-tier instance (512512 MiB memory, 0.080.08 vCPU) shares resources with co-located workloads. Hosting it there tests the portability of the containerized design to the cloud, and adds flexibility for evaluation. Within Cloud Run, paid usage scales up to 88 vCPU and 3232 GiB memory; in limited experiments this yields a 34%34\% reduction in visualization time and 45%45\% in rendering time, and the containerized design ports directly to larger instances on Compute Engine, GKE, or clouds such as AWS to recover localhost-level performance. We will explore this in future for a production release on integration with transactional systems. Effectiveness: To test the effectiveness of Argonaut, we evaluate it with four expert and four non-expert participants across four datasets: household electricity, sensor data sharing, shared mobility, and a synthetic Gaussian dataset. Each group performs 6464 runs (4×4×44× 4× 4) in total using decentralized iterative search, covering four datasets and four runs per dataset. In each run, a participant observes and interactively explores the optimization process in Argonaut, changes one control variable, either the trade-off parameters, the number of plans, or the target global objective bounds, and evaluates whether the edited decision space improves the solution rank by moving it closer to the global optimum, i.e., by reaching a lower-cost solution than the previous one. On average, across these 6464 runs for each group (Figure 7), Argonaut reduces the optimality gap by up to 35.3%35.3\%, with an average reduction of 24.87%24.87\%, reaching the global optimum exactly in 12.56%12.56\% of cases. Changing the target global objective bounds yields a statistically significant improvement over changing the number of plans (p=0.0045p=0.0045) and the trade-off parameters (p=0.0003p=0.0003), while the improvement from changing the number of plans over the trade-off parameters is not statistically significant (p=0.073p=0.073). The mean difference between expert and non-expert users is also not statistically significant (p=0.0894p=0.0894), confirming that Argonaut makes effective optimization accessible to newcomers as well as experts. These results are based on 64 runs per group; a larger-scale user study is a direct and important extension we plan for future work. VI Conclusions We presented Argonaut, a lightweight, containerized, and highly customizable platform for interactive and visual exploration of distributed discrete-choice optimization. By supporting multiple algorithmic backends and uniting construction, optimization, and analysis in one interactive loop, Argonaut enables users to observe and navigate optimization runs within seconds to a few minutes, making it practical for prompt shared-resource management decisions in smart-city infrastructure. Guided by these views, users could improve solution optimality on average by 24.87%24.87\% across domains such as energy, mobility, transport, and logistics. Ongoing work extends Argonaut to additional backends, including decentralized iterative search under varying network topologies and brute-force search with pruning via Gurobi [23]. Building on this, our next step is to develop an explainability layer that surfaces why the search behaves as it does, particularly by detecting and explaining when and why an agent changes its selected plan during convergence. This will move Argonaut from observable optimization toward fully explainable, human-in-the-loop decision-making, while also enabling the analysis of how such behaviours change in the presence of adversarial agents and how they can impact the overall optimization process. Acknowledgment This work is funded by UKRI Future Leaders Fellowship (MR/W009560/1): Digitally Assisted Collective Governance of Smart City Commons–ARTIO’ and UKRI Impact Acceleration Account grant (IAA4148): Collective Learning Optimization Algorithm. The google cloud credits are funded by UKRI AI Super Connector Fellowship from Imperial College London. References [1] Apollo Choice Modelling Apollo: An R Package for the Estimation and Application of Choice Models. Note: https://w.apollochoicemodelling.com/Accessed: 2026-06-18 Cited by: §I. [2] E. T. Barr, M. Harman, P. McMinn, M. Shahbaz, and S. Yoo (2014) The oracle problem in software testing: a survey. IEEE transactions on software engineering 41 (5), p. 507–525. Cited by: §V. [3] O. Bentaleb, A. S. Belloum, A. Sebaa, and A. El-Maouhab (2022) Containerization technologies: taxonomies, applications and challenges. The Journal of Supercomputing 78 (1), p. 1144–1181. Cited by: §IV. [4] C. Blum and A. Roli (2003) Metaheuristics in combinatorial optimization: overview and conceptual comparison. ACM computing surveys (CSUR) 35 (3), p. 268–308. Cited by: §I. [5] F. Colella, P. Daee, J. Jokinen, A. Oulasvirta, and S. Kaski (2020) Human strategic steering improves performance of interactive optimization. In Proceedings of the 28th ACM conference on user modeling, adaptation and personalization, p. 293–297. Cited by: §I, TABLE I, §I. [6] Docker Multi-stage Builds. Note: https://docs.docker.com/build/building/multi-stage/Accessed: 2026-06-24 Cited by: §IV. [7] R. T. Fielding (2000) Architectural styles and the design of network-based software architectures. University of California, Irvine. Cited by: §IV. [8] Google OR-Tools: Operations Research Tools. Note: https://developers.google.com/optimizationAccessed: 2026-06-18 Cited by: §I, TABLE I, §I. [9] Gurobi Optimization, LLC Gurobi Optimizer. Note: https://w.gurobi.com/Accessed: 2026-06-18 Cited by: §I, TABLE I, §I. [10] Z. He and G. G. Yen (2016) An improved visualization approach in many-objective optimization. In 2016 IEEE congress on evolutionary computation (CEC), p. 1618–1625. Cited by: TABLE I, §I. [11] Heuristic and Evolutionary Algorithms Laboratory HeuristicLab: An Environment for Heuristic and Evolutionary Optimization. Note: https://github.com/heal-research/HeuristicLabAccessed: 2026-06-18 Cited by: §I. [12] C. Hinrichs, S. Lehnhoff, and M. Sonnenschein (2013) COHDA: a combinatorial optimization heuristic for distributed agents. In International Conference on Agents and Artificial Intelligence, p. 23–39. Cited by: §I. [13] G. Jornod, E. Di Mario, I. Navarro, and A. Martinoli (2015) SwarmViz: an open-source visualization tool for particle swarm optimization. In 2015 IEEE congress on evolutionary computation (CEC), p. 179–186. Cited by: TABLE I, §I. [14] D. S. K. Karunasingha (2022) Root mean square error or mean absolute error? use their ratio as well. Information Sciences 585, p. 609–629. Cited by: §I-A. [15] G. W. Klau, N. Lesh, J. Marks, and M. Mitzenmacher (2010) Human-guided search. Journal of Heuristics 16 (3), p. 289–310. Cited by: §I, TABLE I, §I. [16] L. Kotthoff (2016) Algorithm selection for combinatorial search problems: a survey. In Data mining and constraint programming: Foundations of a cross-disciplinary approach, p. 149–190. Cited by: §I. [17] H. Lee and Y. Kim (2019) Visualizing swarm behavior with a particle density map. In Proceedings of the Genetic and Evolutionary Computation Conference Companion, p. 415–416. Cited by: TABLE I, §I. [18] P. Mariel, D. Hoyos, J. Meyerhoff, M. Czajkowski, T. Dekker, K. Glenk, J. B. Jacobsen, U. Liebe, S. B. Olsen, J. Sagebiel, and M. Thiene (2021) Software. In Environmental Valuation with Discrete Choice Experiments, SpringerBriefs in Economics, p. 125–129. External Links: Document Cited by: §I. [19] Matplotlib Developers matplotlib.pyplot.savefig. Note: https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot.savefig.htmlAccessed: 2026-06-24 Cited by: §IV. [20] Meta Open Source React: Components and Props. Note: https://w.w3schools.com/react/react_components.aspAccessed: 2026-06-24 Cited by: §IV, §IV. [21] NetworkX Developers NetworkX Documentation. Note: https://networkx.org/documentation/stable/Accessed: 2026-06-24 Cited by: §IV. [22] NGINX Serving Static Content. Note: https://docs.nginx.com/nginx/admin-guide/web-server/serving-static-content/Accessed: 2026-06-24 Cited by: §IV. [23] J. Nievergelt (2000) Exhaustive search, combinatorial optimization and enumeration: exploring the potential of raw computing power. In International Conference on Current Trends in Theory and Practice of Computer Science, p. 18–35. Cited by: §V, §VI. [24] A. S. M. Noor, F. Yunus, H. J. Liang, and N. F. M. Zin (2017) Programming similarity checking system. Journal of Telecommunication, Electronic and Computer Engineering (JTEC) 9 (3-5), p. 89–94. Cited by: §V. [25] NumPy Developers NumPy Documentation. Note: https://numpy.org/doc/stable/Accessed: 2026-06-24 Cited by: §IV. [26] OpenJS Foundation About Node.js. Note: https://nodejs.org/en/aboutAccessed: 2026-06-24 Cited by: §IV, §IV. [27] O. Y. Ozaltın, B. Hunsaker, and T. K. Ralphs (2007) Visualizing Branch-and-Bound Algorithms. Note: https://optimization-online.org/2007/09/1785/Accessed: 2026-06-18 Cited by: §I. [28] pandas Developers IO Tools. Note: https://pandas.pydata.org/docs/user_guide/io.htmlAccessed: 2026-06-24 Cited by: §IV. [29] E. Pournaras and J. Espejo-Uribe (2016) Self-repairable smart grids via online coordination of smart transformers. IEEE Transactions on Industrial Informatics 13 (4), p. 1783–1793. Cited by: §I. [30] E. Pournaras, P. Pilgerstorfer, and T. Asikis (2018) Decentralized collective learning for self-managed sharing economies. ACM Transactions on Autonomous and Adaptive Systems (TAAS) 13 (2), p. 1–33. Cited by: §I-A, Figure 5, Figure 5, §V, §V. [31] E. Pournaras (2019-04) Agent-based Planning Portfolio. External Links: Link, Document Cited by: §V. [32] N. Rachatasumrit and M. Kim (2012) An empirical investigation into the impact of refactoring on regression testing. In 2012 28th IEEE international conference on software maintenance (icsm), p. 357–366. Cited by: §V. [33] P. Ramu, P. Thananjayan, E. Acar, G. Bayrak, J. W. Park, and I. Lee (2022) A survey of machine learning techniques in structural and multidisciplinary optimization. Structural and Multidisciplinary Optimization 65 (9), p. 266. Cited by: TABLE I, §I. [34] S. P. Thole and P. Ramu (2020) Design space exploration and optimization using self-organizing maps. Structural and Multidisciplinary Optimization 62 (3), p. 1071–1088. Cited by: TABLE I, §I. [35] B. Turan, V. Hemmelmayr, A. Larsen, and J. Puchinger (2024) Transition towards sustainable mobility: the role of transport optimization. Central European Journal of Operations Research 32 (2), p. 435–456. Cited by: §I. [36] Vite Building for Production. Note: https://vite.dev/guide/buildAccessed: 2026-06-24 Cited by: §IV, §IV. [37] H. Wang, D. Vermetten, F. Ye, C. Doerr, and T. Bäck (2020) IOHanalyzer: Detailed Performance Analyses for Iterative Optimization Heuristics. Note: https://arxiv.org/abs/2007.03953Accessed: 2026-06-18 Cited by: §I, TABLE I, §I. [38] L. Wang, L. Xu, D. Zhao, Y. Yao, and D. Song (2015) FPGA-based design and implementation of arterial pulse wave generator using piecewise gaussian–cosine fitting. Computers in Biology and Medicine 59, p. 142–151. Cited by: §V. [39] B. Western and D. Bloome (2009) 9. variance function regressions for studying inequality. Sociological Methodology 39 (1), p. 293–326. Cited by: §I-A. [40] R. Xin, S. Pu, A. Nedić, and U. A. Khan (2020) A general framework for decentralized optimization with first-order methods. Proceedings of the IEEE 108 (11), p. 1869–1889. Cited by: §I. [41] D. Yadav, P. Ramu, and K. Deb (2025) Handling objective preference and variable uncertainty in evolutionary multi-objective optimization. Swarm and Evolutionary Computation 94, p. 101860. Cited by: §I. [42] W. Yeoh, A. Felner, and S. Koenig (2010) BnB-ADOPT: an asynchronous branch-and-bound dcop algorithm. Journal of Artificial Intelligence Research 38, p. 85–133. Cited by: §I.