Graph Builder: Techniques & Applications

• Graph Builder is a term for systems that transform raw data or intent into graph-structured representations using incremental, adversarial, or visual methods.
• These systems optimize intermediate representations to boost outcomes in applications such as adversarial games, visual query construction, and design of interactive charts.
• Challenges include balancing resource constraints, user interface efficiency, and achieving optimal graph quality, which spurs ongoing research and innovation.

The expression Graph Builder appears in several distinct technical settings. In graph theory it commonly denotes a player called Builder who incrementally grows, selects, or marks graph structure under adversarial or random rules; in database and human–computer interaction research it denotes a graphical query builder that lets users construct queries visually; and in recent visualization and machine learning systems it denotes software that builds chart specifications, SVG graphics, e-graphs, or heterogeneous graphs from higher-level intent or tabular schemas (Gunderson et al., 2022). This plurality of uses suggests that the term functions less as a single standardized formalism than as a recurrent role label for systems that transform partial intent, evolving state, or raw data into graph-structured or graph-mediated artifacts.

1. Terminological Scope

A concise way to situate the major uses of the term is to distinguish the object being built and the constraints under which it is built.

Usage	Built object	Representative papers
Graph-theoretic Builder	Growing graph, marked vertex set, or accepted-edge subgraph	(Gunderson et al., 2022, Klavžar et al., 2023, Lichev, 2022)
Graphical query builder	Visual predicate graph, SQL query, or SPARQL query	(Gorczynska et al., 2022, Kabir et al., 2012)
Visualization or chart builder	Vega-Lite chart, iterative visualization state, or SVG composition	(Tian et al., 2023, Wang et al., 2024, Chen et al., 2024)
Automatic graph constructor	Heterogeneous graph schema or e-graph	(Chen et al., 25 Jan 2025, He et al., 2023)

Across these uses, the builder role is characterized by incrementality, representation choices, and downstream objectives. In some papers the objective is explicitly adversarial, as in winning conditions based on burning density or general position size; in others it is usability, such as faster and more accurate query construction; and in others it is downstream model quality, such as graph machine learning performance or extracted program cost (Chen et al., 25 Jan 2025). A common structural pattern is that the builder does not merely emit a final artifact once, but instead navigates a sequence of intermediate states, each of which constrains later choices.

2. Builder in Adversarial Growth and Burning Processes

In adversarial graph burning, Builder is the player that grows a connected nested graph sequence $G_0 \subseteq G_1 \subseteq G_2 \subseteq \dots$ while an Arsonist chooses fire sources (Gunderson et al., 2022). The process is played in discrete rounds $n=1,2,\dots$. At round $n$, Builder adds exactly $f(n)$ new vertices and edges incident to these to obtain a connected graph $G_n$; fire then spreads to all neighbours of burning vertices; finally Arsonist chooses a new vertex $v_n$ and declares it burning. If $B_n$ is the burning set at the end of round $n$, the lower and upper burning densities are

$$\underline{\delta}(G,v)=\liminf_{n\to\infty}\frac{|B_n|}{|V(G_n)|}, \qquad \overline{\delta}(G,v)=\limsup_{n\to\infty}\frac{|B_n|}{|V(G_n)|},$$

and, when the limit exists,

$$\delta(G,v)=\lim_{n\to\infty}\frac{|B_n|}{|V(G_n)|}.$$

The central threshold result is stated for polynomial growth. If $n=1,2,\dots$0, then Arsonist has a winning strategy when $n=1,2,\dots$1, while Builder has a winning strategy when $n=1,2,\dots$2 (Gunderson et al., 2022). The refined statement gives an Arsonist-win regime when there exists $n=1,2,\dots$3 such that

$n=1,2,\dots$4

and a Builder-win regime when $n=1,2,\dots$5. The critical exponent is therefore $n=1,2,\dots$6.

Builder’s structural freedom is broad: the only hard constraints are exact addition of $n=1,2,\dots$7 vertices per round, connectedness of each $n=1,2,\dots$8, and preservation of the old induced subgraph. Yet Theorem 3 shows that Builder can, without loss of generality, restrict to trees; removing edges slows burning and cannot increase burning density. In the linear and superlinear regime, Builder’s canonical winning strategy is to extend a single path by attaching all $n=1,2,\dots$9 new vertices to one end. If $n$0 for sufficiently large $n$1, this yields

$n$2

so the burning fraction is bounded away from $n$3 by a constant depending on $n$4.

The same paper also emphasizes that regular growth assumptions matter. Outside polynomial-like regimes, oscillatory choices of $n$5 can produce cases where neither player wins, and one can construct examples with $n$6 and $n$7. This directly rules out any simple monotone intuition that “more builder resources always settle the game,” and it motivates open questions about monotonicity in Builder’s resources and whether building a path is always optimal.

3. Builder in Positional and Random Graph Games

A different graph-theoretic use appears in Builder–Blocker general position games, where Builder and Blocker alternately mark vertices while the marked set must remain in general position (Klavžar et al., 2023). A set $n$8 is in general position if no shortest path of $n$9 passes through more than two vertices of $f(n)$0; equivalently, there are no distinct $f(n)$1 with

$f(n)$2

If Builder moves first, the resulting optimum-play size is the Builder-game general position number $f(n)$3; if Blocker moves first, it is the Blocker-game general position number $f(n)$4. Both satisfy

$f(n)$5

The builder role here is not graph growth but adversarial set construction. The paper determines exact values for several graph classes. For complete multipartite graphs $f(n)$6 with $f(n)$7,

$f(n)$8

For trees, the asymmetry between player orders is especially sharp: because trees are bipartite, $f(n)$9 for every nontrivial tree, while in the Blocker-first game the paper proves

$G_n$0

and characterizes exactly the trees achieving equality. More broadly, the difference $G_n$1 can be arbitrarily large. This contrasts with domination-game phenomena where changing the starting player alters the result by at most $G_n$2.

An online random-graph variant uses Builder in yet another precise sense. In the random graph with restricted budget, the edges of $G_n$3 are ordered uniformly at random and revealed one by one; Builder must decide online whether to accept each edge (Lichev, 2022). A $G_n$4-strategy sees only the first $G_n$5 edges and accepts at most $G_n$6 of them. The main result proves that for every fixed $G_n$7, if

$G_n$8

then there exists a $G_n$9-strategy such that asymptotically almost surely the final accepted graph is spanning and $v_n$0-connected. This settles a conjecture of Frieze, Krivelevich and Michaeli. Here Builder’s task is budgeted selection rather than unconstrained construction, and the result is notable because $v_n$1 accepted edges is asymptotically the minimum scale forced by minimum-degree considerations.

4. Graphical Query Builders

In database and semantic-web research, Graph Builder usually denotes a visual system for constructing queries without directly writing the target formal language. A domain-specific example is GraphicalQueryBuilder for spatial–temporal–spectral transmitter data (Gorczynska et al., 2022). The system has an Angular client-side graphical front-end and a Django + PostgreSQL backend. A query is visually composed through domain-native views: a map for spatial predicates, an hours-of-operation axis for temporal predicates, and a log-scale frequency axis for spectral predicates. Inclusion and exclusion are shown in green and red, and users combine predicates with AND/OR selectors. The backend translates the visual query specification into SQL and returns results as JSON.

The paper’s evaluation used 10 professionals from the industry partner, each performing four tasks: two with Microsoft Access and two with GraphicalQueryBuilder. Average time with Access was approximately 4 minutes per task; average time with GraphicalQueryBuilder was approximately 2.5 minutes per task, about a 40% reduction in time. First-attempt accuracy improved from $v_n$2 with Access to $v_n$3 with GraphicalQueryBuilder, an improvement of 40 percentage points. The paper identifies current limitations as relatively flat support for AND/OR, lack of bracketed nesting, limited direct manipulation outside the map, and absence of built-in CSV export.

A semantically oriented precursor is the Graphical Query Builder in Opportunistic Sensor Networks, which builds RDF-like query graphs from ontologies and compiles them to SPARQL (Kabir et al., 2012). The system parses an OWL file using Jena, extracts classes, subclasses, and properties, and exposes them in a Java Swing interface. Queries are represented as nodes and labeled edges corresponding to RDF triple patterns, such as

$v_n$4

The translation rule is direct: node variables become SPARQL variables, edges become triple patterns in the WHERE clause, and selected output nodes become variables in the SELECT clause. The prototype supports up to 12 nodes on the canvas, has been tested with Pizza ontology, Wine ontology, and a custom sensor ontology, and does not yet report a formal usability study.

Taken together, these systems show two stable design traditions. One represents queries through domain-specific visual metaphors such as maps, timelines, and frequency bands; the other represents them through explicit graph patterns aligned with RDF and SPARQL. This suggests that graphical query builders can be understood as visual compilers whose input language is not free-form natural language but a constrained graphical syntax grounded either in data semantics or ontology structure.

5. Chart and Visualization Builders

A more recent use of the term concerns systems that build visualizations from natural language, GUI state, or optimization objectives. ChartGPT treats chart generation from abstract natural language as a six-stage reasoning pipeline: column selection, row filtering, aggregation, chart type, visual encodings, and sort (Tian et al., 2023). The mapping

$v_n$5

is decomposed into six sub-functions, and the model used in the system is FLAN-T5-XL fine-tuned on a custom dataset of 1,916 $v_n$6 triplets, including 236 data tables from 133 databases, 605 charts, and 1,916 utterances. The dataset is designed to include abstract utterances that are incomplete or implicit rather than fully specified. The interface exposes intermediate outputs from each reasoning step so that users can inspect and modify selected columns, filters, aggregations, marks, encodings, and sort order.

Data Formulator 2 addresses a related problem from the standpoint of iterative exploratory authoring (Wang et al., 2024). Its central interaction primitive is the Concept Encoding Shelf, a shelf-configuration interface where users drag existing fields to channels or type names of future fields that do not yet exist. DF2 uses Vega-Lite templates for chart types, natural language instructions for data semantics, and LLM-generated Python code for transformation. Its second major contribution is Data Threads, a history structure in which data versions are first-class nodes and charts are attached artifacts. In a user study with eight participants, all participants successfully created all 16 target visualizations across two challenging analysis sessions. Average time for the college-majors task was less than 20 minutes, and the movies task took about 33 minutes on average. The study reports that participants developed different iteration styles, including incremental refinement and restarting from the original dataset with succinct prompts.

ChartOptimiser shifts the builder role from specification generation to task-driven design optimization (Wang et al., 14 Apr 2025). For single-group bar charts it defines an eight-dimensional style space over aspect ratio, axis label font size, data label font size, bar width, bar colour, highlight bar colour, label rotation, and chart orientation. The core objective is

$v_n$7

combining white space ratio, colour preference, text legibility, and task-driven saliency, with experimentally used weights $v_n$8, $v_n$9, $B_n$0, and $B_n$1. Bayesian optimization with a Gaussian-process surrogate and Expected Improvement searches this design space. On 12 bar charts and four tasks—finding the extreme value, retrieving a value, comparing two values, and computing a derived value—ChartOptimiser ranked first in clarity and task-solving ease and second in aesthetics overall; the authors also discuss accessibility and content localisation as practical applications.

A plausible implication of these systems is that a chart builder is increasingly less a one-shot chart recommender than a layered pipeline: structured chart specification, automated transformation, and task-aware design optimization are being treated as separable components rather than a single monolithic generation step.

6. Automatic Graph Construction, E-graph Building, and SVG Composition

In graph machine learning, the term can refer to automatic graph construction from tabular data. AutoG formalizes tabular input as

$B_n$2

and the target heterogeneous graph as

$B_n$3

(Chen et al., 25 Jan 2025). The system uses an LLM to transform an input relational schema into a graph schema through actions such as connecting columns, generating new tables, and altering primary-key status, then scores candidate schemas with downstream GNN performance. The benchmark comprises 8 datasets and 12 tasks. The experiments show that graph quality is critical to downstream performance and that AutoG can generate high-quality graphs that rival those produced by human experts; the paper states that AutoG achieves approximately 98.5% of expert performance on 9 tasks.

A different builder problem arises in equality saturation. MCTS-GEB observes that when an e-graph is not saturated, the phase-ordering problem reappears during construction, because the partially built e-graph does not represent all rewrite opportunities (He et al., 2023). The paper formulates e-graph construction as an MDP whose actions are rewrite rules and whose default reward is

$B_n$4

It then applies Monte Carlo Tree Search, specifically WU-UCT for parallel MCTS, to plan graph-building actions under a node budget. Evaluation in two domains shows that MCTS-GEB can outperform state-of-the-art rewrite systems by up to 49x, while the optimisation can generally take less than an hour.

A visually oriented builder appears in SVGBuilder, which generates colored SVGs from text through a component-based autoregressive Transformer (Chen et al., 2024). Instead of emitting raw SVG code token by token, the model generates a sequence of components, each encoded by a component index, geometric transform, and RGB color. To support this, the paper introduces ColorSVG-100K, a dataset of 100,000 graphics described as the first large-scale dataset of colored SVGs. Relative to optimization-based approaches, SVGBuilder generates SVGs up to 604 times faster. The paper explicitly notes that the same component-based machinery can be re-oriented to build diagrams or graphs from text.

These builder architectures differ in output—heterogeneous graphs, e-graphs, SVG scenes—but share a common design principle: the build process itself is treated as an optimization target. The representation being built is not assumed given in advance; rather, schema design, rewrite scheduling, or component sequencing is optimized because it determines the quality of later inference, extraction, or rendering.

7. Benchmarks, Limits, and Open Directions

Research on graph builders is accompanied by explicit evidence that current systems remain constrained. In graph burning, outside regular growth regimes there may be draws, and the paper closes with open questions on monotonicity in Builder’s resources and whether building a path is always optimal (Gunderson et al., 2022). In Builder–Blocker general position games, the order of play can change the outcome arbitrarily, and the authors conjecture that decision versions of the B- and B′-games are PSPACE-complete (Klavžar et al., 2023). These results show that even when Builder is formally defined, its power can depend delicately on graph class, growth rule, and move order.

In applied systems, the limitations are different. GraphicalQueryBuilder currently has relatively flat AND/OR support, no bracketed nesting, and limited direct manipulation outside the map; the sensor-network SPARQL builder remains a prototype with form-based node creation and no formal usability study (Gorczynska et al., 2022). ChartGPT presently supports seven chart types and a restricted transformation space, while Data Formulator 2 reports performance issues with very large datasets or many charts and motivates richer history views and more explicit AI clarification (Tian et al., 2023). AutoG depends on semantic column names and on an oracle based on downstream model performance; graph quality remains task-relative rather than captured by a universal standalone score (Chen et al., 25 Jan 2025).

A complementary limitation is exposed by GRAB, a benchmark for graph analysis by large multimodal models (Roberts et al., 2024). GRAB contains 2170 questions, 4 tasks, and 23 graph properties, and the highest performing model attains only 21.7% overall accuracy under strict exact-match evaluation. The paper reports 0% accuracy for all models on the Functions category under that metric. This suggests that building graph-capable assistants remains bottlenecked not only by construction and interface design, but also by weak underlying graph-reading and quantitative reasoning.

Across these literatures, a recurring pattern is that builder performance depends on the fit between representation and objective. In graph games the objective is formal winning behavior; in query systems it is correctness and authoring efficiency; in visualization systems it is iterative usability and task-solving ease; and in graph machine learning it is downstream predictive performance. The resulting diversity is not accidental. It indicates that Graph Builder has become an umbrella term for systems in which graph-structured representations are not merely consumed but actively designed, revised, and optimized as part of the problem itself.