Text-Only Blueprint Schema Overview

• Text-Only Blueprint Schema is a method that converts latent structures into explicit, editable text representations to guide generation and summarization.
• It leverages plan-based conditional generation with interactive editing operations to improve factual consistency and control over outputs.
• Empirical evaluations in query-focused summarization, schema linking for Text-to-SQL, and tool compilation show improved performance and model efficiency.

Searching arXiv for the cited paper and closely related work on plan-based conditional generation and textual blueprint-style representations. Across the cited works, a text-only blueprint schema denotes an explicitly textual intermediate representation that externalizes structure before a downstream act of generation, querying, or interpretation. In query-focused summarization, Huot et al. define the blueprint as a sequence of questions or question–answer pairs that specifies what to say and in what order, and they expose it as an editable artifact in a web browser-based demonstration (Huot et al., 2023). Related work applies comparable text-first schemata to schema linking for Text-to-SQL, compilation of JSON tool schemas into model-friendly text, minimalist representation of hierarchical structure, text-based software modeling, and grammar extraction from raw text into model-agnostic conceptual structure (Glass et al., 23 Jan 2025, Cao et al., 2024, Sakizli, 4 May 2026, Chapin, 2017, Grönninger et al., 2014, Chabin et al., 12 Dec 2025). This suggests that the notion is not a single fixed syntax, but a family of representations whose common purpose is to make latent structure legible, editable, and operational.

1. Conceptual scope and lineage

The literature uses “blueprint” in several technically distinct but structurally related senses. In plan-based conditional generation, the blueprint is a plan over content units. In Text-to-SQL, it is a pruned schema or linked subset of a schema, often augmented with role information. In tool-use systems, it is a compiled textual rendering of machine-oriented JSON schemas. In structural notation and software modeling, it is a textual encoding of hierarchical or typed structure that replaces or supplements graphical or verbose symbolic forms (Huot et al., 2023, Glass et al., 23 Jan 2025, Sakizli, 4 May 2026, Chapin, 2017, Grönninger et al., 2014).

Setting	Blueprint form	Immediate objective
Query-focused summarization	Question sequence or question–answer sequence	Guide summary content and order
Text-to-SQL	Pruned DDL, linked schema, role summary	Focus SQL generation on relevant schema
Agentic tool use	Structured text compiled from JSON schema	Improve tool interpretation and reduce tokens
Textual structural notation	Minimal punctuation, typed nodes, separators	Represent hierarchy compactly in text
Model extraction from text	Model-agnostic grammar and instance structure	Align raw text with database models

Two earlier lines of work supply important antecedents. Grönniger et al. argue that text-based modeling offers information density, speed of creation and evolution, integration of heterogeneous languages, automatic deterministic formatting, platform and tool independence, version-control friendliness, and direct support for parser generators such as ANTLR, MontiCore, and Xtext (Grönninger et al., 2014). “Efficient Textual Representation of Structure” then pushes the idea further toward formal minimalism through a three-symbol bracket system, a universal closing bracket, separator tokens, typed nodes, run-length and block-length encoding, and indentation controls; the same paper adapts these ideas into a “blueprint-style schema for technical drawings” (Chapin, 2017). Together, these works frame text not merely as a serialization target but as a primary medium for structural reasoning.

2. Plan-based blueprints in conditional generation

In the formulation summarized by Huot et al., let $d \in V^\ast$ denote the tokenized input consisting of a user query plus one or more retrieved documents, let $s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$ denote the generated summary, and let $b$ denote the blueprint plan (Huot et al., 2023). In the “text-only” question–answer version, the plan is a flat sequence

$b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$

typically linearized as

$b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$

In the interactive question-only variant, the answers are dropped and the plan becomes

$b = [q_1, q_2, \dots, q_m].$

Iterative planning refines the granularity further: if the summary is segmented into sentences $s_1, \dots, s_n$, then each sentence $s_i$ has its own sub-blueprint

$$b_i = [(q_{i1}, a_{i1}), \dots, (q_{i k_i}, a_{i k_i})],$$

and the full plan is $b = [b_1, b_2, \dots, b_n]$ (Huot et al., 2023).

All three variants use a standard Transformer encoder–decoder and factor the joint probability as

$s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$0

In the end-to-end blueprint, the decoder autoregressively generates the flattened blueprint first and then, in the same pass, the summary tokens, so that if the concatenated output is renamed $s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$1, then

$s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$2

In the iterative blueprint, planning and generation are interleaved sentence by sentence, yielding

$s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$3

The interactive question-only blueprint retains the end-to-end architecture but masks out answers during fine-tuning; at inference time, the user may edit or supply the questions before generation of $s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$4 (Huot et al., 2023).

The reported implementation instantiates all three variants from LongT5, using the XL (3 B) checkpoint, fine-tuned on the AQuaMuSe query-focused multi-document summarization dataset. Inputs and outputs are capped at 4 096 and 512 tokens, respectively. On held-out AQuaMuSe examples, Narayan et al., as summarized in the demo description, report $s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$5–$s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$6 ROUGE-L points over a T5 baseline with no planning, a $s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$7–$s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$8 relative improvement in QA-based consistency F1, and further factual-consistency gains of up to $s = s_1 s_2 \dots s_{\lvert s \rvert} \in V^\ast$9 absolute when filtering out Q&A pairs whose answers are not grounded in $b$0 before summary generation (Huot et al., 2023).

3. Editing operations and interactive control

A defining feature of the Text-Blueprint system is that the blueprint is not only generated but directly manipulable. If the plan is written as $b$1, where each $b$2 is either a Q&A pair or a question, then the demo exposes three primitive operations: deletion, insertion, and reordering (Huot et al., 2023). Deletion removes indices $b$3 and yields

$b$4

Insertion adds a new element $b$5 at slot $b$6:

$b$7

Reordering applies a permutation $b$8:

$b$9

In practice, the interface allows drag-and-drop reordering of Q&A rows (Huot et al., 2023).

After each edit, the updated plan $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$0 is sent back to the same decoder, and because $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$1 appears as a forced prefix, the model generates a new summary $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$2 consistent with the revised plan. This mechanism makes the relation between plan edits and summary changes explicit rather than implicit. Huot et al. illustrate the effect with two examples. For the prompt “Why is the sky blue?”, deleting the pair about “What is the Sun?” removes an incorrect clause about “light being scattered by the Sun,” and inserting a new Q&A about the Sun appearing low at dusk produces an additional sentence about red or orange skies at sunset. For “What is the Titanic known for?” in the interactive question-only model, appending questions about the 1997 film causes the regenerated summary to include a paragraph on the film mentioning Kate Winslet and Leonardo DiCaprio (Huot et al., 2023).

The demo therefore treats the blueprint as both a planning formalism and a user interface abstraction. The paper’s reported interpretation is that small manual edits to $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$3 yield immediate and predictable changes in $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$4, improving faithfulness and user satisfaction (Huot et al., 2023). A plausible implication is that the blueprint functions as a controllable boundary object between human intention and autoregressive decoding.

4. Database-oriented blueprint schemas

In Text-to-SQL, the blueprint concept shifts from content planning to schema focusing. “Extractive Schema Linking for Text-to-SQL” defines the task input as a natural-language question $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$5 and a full database schema $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$6 expressed in DDL, and the output as a subset $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$7 marked as relevant to $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$8, with fine-grained roles for each column: SELECT, JOIN, CONDITION, GROUP, and ORDER (Glass et al., 23 Jan 2025). The method appends a tagged list of candidate columns of the form « table_name.column_name » after the full DDL and question, extracts the final hidden vectors at the « and » markers, concatenates them into $b = [(q_1, a_1), (q_2, a_2), \dots, (q_m, a_m)],$9, and applies a linear projection

$b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$0

Binary cross entropy is used against ground-truth role labels derived from gold SQL. Relevance is then thresholded by a logit threshold $b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$1, and the threshold is selected by maximizing $b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$2, with the paper noting that $b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$3 at peak $b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$4 gave the best end-to-end SQL accuracy and a Spearman $b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$5 (Glass et al., 23 Jan 2025).

The resulting text-only blueprint schema $b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$6 is constructed by printing, for each selected table, a minimal CREATE TABLE statement listing only the selected columns and any PRIMARY/FK constraints among them, followed by a “Role Summary” section. On Spider, the reported execution accuracies are 78.7% dev / 77.3% test for the full schema, 77.3% / 79.0% for generative schema linking, 81.2% / 81.4% for coarse ExSL, and 82.4% / 83.0% for fine-grained ExSL; on BIRD, the corresponding total execution accuracies are 59.7% for generative schema linking, 61.9% for ExSL_c, and 63.2% for ExSL_f. The method is also reported as $b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$7 faster than sampling from a generative schema linker (Glass et al., 23 Jan 2025).

RSL-SQL broadens the blueprint idea into a robust schema-linking framework. It defines linked subsets from Forward Schema Linking and Backward Schema Linking, evaluates them with Non-Strict Recall and Strict Recall Rate, and prunes schema elements by a token-overlap threshold $b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$8, typically $b = q_1; a_1; q_2; a_2; \dots; q_m; a_m.$9–$b = [q_1, q_2, \dots, q_m].$0 (Cao et al., 2024). The paper reports improving the recall of pattern linking through forward and backward pruning to achieve a strict recall of 94% while reducing the number of input columns by 83%. It then hedges linking risk by voting between a full mode and a simplified mode enhanced with contextual information, and adds a multi-turn self-correction loop. On the BIRD and Spider benchmarks, it reports 67.2% execution accuracy on BIRD and 87.9% on Spider using GPT-4o (Cao et al., 2024).

A complementary database-side perspective appears in “The Case for Text-to-SQL Friendly Logical Database Design,” which treats LLM-friendly logical design as an optimization target and proposes three semantics-preserving transformations: schema abstraction $b = [q_1, q_2, \dots, q_m].$1 through logical views, schema partitioning $b = [q_1, q_2, \dots, q_m].$2 through workload-aware pruning, and schema renaming $b = [q_1, q_2, \dots, q_m].$3 through descriptive identifiers (Zhang et al., 2 Jun 2026). The three operators compose, the best transformation varies modestly across pipelines and models, and the full $b = [q_1, q_2, \dots, q_m].$4 combination is reported as consistently improving; the paper reports gains of up to 4.2% in execution accuracy (Zhang et al., 2 Jun 2026). Taken together, these works treat the blueprint not as generated prose but as a textual schema surface optimized for model consumption.

5. Tool-schema compilation and minimalist textual structure

In agentic LLM deployments, TSCG moves the blueprint idea to the API boundary. The system compiles JSON-based tool schemas from frameworks such as OpenAI Function Calling, Anthropic Tool Use, and MCP into token-efficient structured text, with no model access, fine-tuning, or runtime search (Sakizli, 4 May 2026). The paper presents eight deterministic operators: four token-reducing operators—Semantic Density Maximization, Delimiter-Role Optimization, Tokenizer-Aligned Syntax, and Constraint-First Layout—two structure-reordering operators—Causal-Forward Ordering and Causal Access Score—and two token-expanding operators—Selective Anchor Duplication in Fragility mode and the Causal Closure Principle (Sakizli, 4 May 2026). For well-formed schema collections, the formal compression bound is stated as at least 51%, while practical savings are reported in the 61–75% range; balanced-profile savings are reported as 50–72% (Sakizli, 4 May 2026).

The benchmark results are framed as evidence that representation change, not only compression, matters. On TSCG-Agentic-Bench, TSCG is reported to restore Phi-4 14B from 0% to 84.4% accuracy at 20 tools and to 90.3% at 50 tools, while format-versus-compression decomposition is reported as reducing $b = [q_1, q_2, \dots, q_m].$5 from 0.88 to 0.03, establishing representation change as the dominant mechanism. The paper also identifies three operator-response profiles—operator-hungry, operator-sensitive, and operator-robust—and states that for models under 10B, adding structure-reordering operators harms accuracy, motivating a conservative profile that uses only token-reducing operators (Sakizli, 4 May 2026).

These results resonate with the older formal literature on textual structure. “Efficient Textual Representation of Structure” proposes that a single colon can replace a pair of brackets, that closing bracket types do not need to repeat opening types, and that commas and semicolons can encode close-open patterns at different depths. Its blueprint-style schema for technical drawings combines the three-symbol brace system, typed openings via $</code>, commas for siblings, semicolons for assemblies, run-length escape <code>\n</code>, and indentation controls, with the stated rationale that punctuation is minimized while types and attributes remain clearly distinguished (<a href="/papers/1706.00862" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Chapin, 2017</a>). This suggests that TSCG’s compilation strategy belongs to a broader tradition in which textual surface form is itself a design parameter.</p> <h2 class='paper-heading' id='schema-induction-from-text-advantages-and-recurring-limitations'>6. Schema induction from text, advantages, and recurring limitations</h2> <p>ArchiTXT approaches the problem from the opposite direction: instead of writing a blueprint to guide a model, it derives a blueprint schema from raw text. The method defines a model-agnostic schema as an attribute grammar</p> <p>$b = [q_1, q_2, \dots, q_m].$6

where $b = [q_1, q_2, \dots, q_m].$7 is the finite set of meta-nonterminals, $b = [q_1, q_2, \dots, q_m].$8 the finite set of meta-terminals, $b = [q_1, q_2, \dots, q_m].$9 the production rules with semantic rules, $s_1, \dots, s_n$0 the start symbol, and $s_1, \dots, s_n$1 the attribute assignment over synthesized and inherited attributes (Chabin et al., 12 Dec 2025). The schema is expressed in terms of four universal data-model concepts—Property, Group, Relation, and Collection—and is extracted from semantically enriched syntax trees in which named entities are lifted into internal nodes labeled PropX. The pipeline enriches and simplifies parses, extracts a grammar by quotient-tree construction, computes equivalence classes by sub-tree similarity, rewrites the forest iteratively to satisfy expected Prop → Group → Relation → Collection patterns, and returns a grammar conforming to the meta-model (Chabin et al., 12 Dec 2025).

On 100 documents of the CAS clinical-cases corpus, comprising about 1 800 sentences and 8 098 manually annotated entities across 10 types, the paper reports convergence typically within 20–40 iterations. At $s_1, \dots, s_n$2 and $s_1, \dots, s_n$3, the reported scores are coverage $s_1, \dots, s_n$4 versus 0.74 for a naive baseline, AMI = 0.46, cluster completeness $s_1, \dots, s_n$5, number of productions $s_1, \dots, s_n$6 versus 128, group overlap 0.20 versus 0.30, and redundancy score $s_1, \dots, s_n$7 versus 0.19 (Chabin et al., 12 Dec 2025). The paper explicitly characterizes the result as “blueprint only” because the extracted symbols need not match ontology names until a post-mapping phase (Chabin et al., 12 Dec 2025).

Across the literature, several recurring benefits and caveats appear. Text-based modeling emphasizes information density, keyboard-centric authoring, seamless language composition, deterministic formatting, platform independence, and standard diff/merge behavior (Grönninger et al., 2014). At the same time, the literature repeatedly warns that textual blueprints involve real trade-offs. ExSL stresses precision–recall control because missing a relevant column may make correct SQL impossible, whereas including too many columns mainly bloats context (Glass et al., 23 Jan 2025). RSL-SQL notes that schema linking can omit necessary elements and disrupt database structural integrity (Cao et al., 2024). ArchiTXT identifies parameter sensitivity, auto-generated nonterminal names, target-model tuning, normalization, and incrementality as open challenges (Chabin et al., 12 Dec 2025). TSCG shows that operator behavior is model-dependent and that some structure-reordering operators should be disabled for certain model classes (Sakizli, 4 May 2026). The structural-notation literature adds a broader caution: minimalism does not mean obfuscation, and transforms should remain familiar enough for human readers to decode reliably (Chapin, 2017).

A common misconception is that a text-only blueprint schema must be a single standardized syntax. The surveyed work does not support that view. In one setting, the blueprint is a question list; in another, a minimal CREATE TABLE subset plus role summary; in another, a compiled tool signature; in another, an attribute grammar extracted from text (Huot et al., 2023, Glass et al., 23 Jan 2025, Sakizli, 4 May 2026, Chabin et al., 12 Dec 2025). A more defensible generalization is that a blueprint schema is any textual representation deliberately designed to expose the structural factors a downstream model would otherwise have to infer implicitly.