Tytan: Interactive Neurosymbolic Construction of Analytic Semantic Schemas from Relational Data

The paper addresses the knowledge-acquisition bottleneck of building semantic layers for databases. As the abstract states:

"From natural-language query interfaces to automated report generation, data analysis tools need a description of the data: the real-world entities it contains, which columns function as measures or identifiers, and how tables connect into units of analysis. Today, this semantic layer is usually written by hand. This is a knowledge-acquisition bottleneck that limits the scalability of analytic systems, keeps nontechnical users dependent on experts, and is itself error-prone."

The authors note that LLM-based agents can misinterpret tables and relationships, and production natural-language-to-SQL systems remain unreliable on real-world databases that do not provide enough semantic information to resolve user intent. Manual semantic layers are hard to scale, fall out of date as databases change, and leave non-technical users dependent on database experts.

The paper presents TYTAN, a system for automatically constructing an analytic semantic schema from a relational database and, when available, a short user-provided description. The system combines symbolic and neural methods:

"TYTAN combines symbolic analysis of the database with LLM-based semantic inference for entity proposal, role assignment, and naming. When the evidence leaves a decision ambiguous, TYTAN asks the user a targeted natural-language question."

The central design principle is that Every LLM proposal is validated against the database: name-and-type matching for column mappings, value-overlap for detecting joins, uniqueness for detecting keys, sample-value evidence for detecting types. Properties computable directly from the database are handled deterministically, and the human-in-the-loop paradigm improves robustness and transparency.

TYTAN's output is an analytic semantic schema called a ring — "a structured, self-constrained JSON artifact that identifies (i) the entities described by the data, (ii) each entity's attributes along with an analytic role (identifier, categorical, metric, or datetime), (iii) join paths connecting entities, (iv) linguistic surface forms (human-friendly names, descriptions grounded in real values, and label templates) that let downstream systems talk about the data and do analytical operations on the data." The ring contains:

• Entities: Real-world concepts mapping to source tables, with a verified id (column or column set uniquely identifying instances).

• Attributes: Each with provenance (source table/columns), physical storage type (isa), an analytic role (Categorical, Datetime, or Numeric, plus an optional Metric tag), a human-friendly name, and a description grounded in example values from the data. The storage type and analytic role are deliberately independent — an insurance ID stored as an integer but would have a Categorical type.

• Relationships: A global list of verified join paths plus per-entity aggregable attributes reachable through those joins, annotated with direction (many-to-one vs. one-to-many).

• Surface forms: Entity/attribute names and a reference template per entity (e.g., " FirstName LastName ").

TYTAN operates in "three interleaved phases: (i) symbolic analysis of the database, (ii) LLM-driven semantic inference over structural evidence to propose a conceptual schema, and (iii) interactive clarification with the user to handle uncertainties. After deterministic profiling, every stage follows the same pattern: LLM proposes, and the deterministic rules verify."

The system first collects tables, columns, declared primary/foreign keys, sample distinct values, cardinalities, and null rates. It also accepts flat files (CSV/Excel) loaded into a relational store, where "there are no primary keys, no foreign keys, and often no reliable column types... every key must be verified for uniqueness against the data, every join must be discovered through value overlap, and column types must be inferred from samples."

The LLM proposes a small set of domain entities and likely attributes from the database description and extracted evidence. Entities are matched to source tables, and attributes to columns. Deterministic cleanup merges entities mapping to the same table and revises names (e.g., a proposed entity named Location may be renamed Wildfire if the table holds one row per wildfire incident). A coverage sweep categorizes unmapped tables as: entity, link table, passthrough table (small lookups whose values remain accessible via joins), or ignore (technical tables). The classifier avoids using ignore unless there is clear evidence that a table has no analytic value. Unmapped columns in assigned tables are added to the corresponding entity.

Declared foreign keys are used directly. Undeclared candidates pass through:

1. Value-overlap: A candidate join whose columns share no values cannot connect any rows and is removed. The check uses all distinct values rather than a sample.

2. Deterministic key-role guards: Excludes source columns that are themselves primary keys, columns classified as Numeric measures (e.g., goals/saves that may overlap sequential IDs), columns that already have a verified reference, and any candidate where a column's values overlap the keys of three or more different tables (all candidates dropped).

3. LLM verification: Remaining candidates are checked for semantic plausibility using names, types, and sample values, accepted only when the model assigns confidence above a fixed threshold.

TYTAN also preserves multiple foreign keys between the same table pair (e.g., both matches.home team id and matches.away team id referencing teams).

The system distinguishes storage type from analytic role. Two rules guide the process:

"Evidence may refine, but not override, semantics. If the model assigns a Numeric role and the sampled values are numeric, TYTAN may refine the storage type from string to integer or float. However, a column is not assigned a Numeric role simply because its values contain digits. Zip codes, department codes, and phone numbers are still categorical values and should not be aggregated."

Conversely, assignments that clearly conflict with the data are corrected — e.g., a Numeric role over non-numeric values or a Datetime label on a column with no temporal values is downgraded to Categorical. And: Computable facts are computed directly from the database. The declared column type (the database's own metadata) settles the storage type when it is present. Declarations are checked against observed values before being trusted.

Entity identifiers are verified separately because it's too consequential: every count, join, and group-by downstream depends on it. Declared primary keys are accepted; LLM-proposed keys are checked for uniqueness; when none verify, TYTAN searches candidates (id-like names first, Numeric measures excluded, composite identifiers for fact tables). A key is accepted only if it uniquely identifies the rows.

The LLM generates names and reference templates, then TYTAN checks and cleans them: abbreviations expanded (e.g., cont date → Containment Date), labels derived from column values when the proposed label doesn't match (e.g., CustomerDetails whose values are names → CustomerName), duplicate names resolved, and reference templates validated — If a template is missing or invalid... TYTAN falls back to the entity identifier.

For decisions the evidence cannot settle — e.g., whether an enrollment table is its own entity or a junction — TYTAN asks focused natural-language questions. Four question categories exist: table mapping, column mapping, satyrn type (e.g., whether Age should be an averageable Numeric or a grouping Categorical), and table role (entity/junction/passthrough/ignore). The user may also skip the questions entirely. Each one has a default answer, so the pipeline can complete without any user input.

TYTAN was evaluated on eight databases: seven reference domains (wildfire incidents, school shootings, housing rents, regional income, plus three Spider text-to-SQL benchmark databases: college, hospital, insurance) and one held-out blind test (a live FIFA World Cup 2026 dataset with ten tables and no declared primary or foreign keys of any kind). The evaluation addressed three research questions:

Does the generated schema capture the relevant entities and attributes in the dataset? Across the seven reference domains, TYTAN reaches every entity, attribute, and aggregable attribute in the reference ring, with no misses (Table 1). Table 1 shows 100% coverage (e.g., 4/4 entities, 40/40 attributes, 60/60 aggregables for college; 126/126 attributes for school shooting).

The ring's instructions are executed against the live database: identifier uniqueness over all rows, attribute mapping reachability, join-chain execution, and reference-template resolution. Every claim the ring makes... executed against the live database with 100% pass rates across all domains (Table 2: 1,678 self-generated claims passing for the reference domains; the abstract states 1,678 of 1,678 self-generated claims; the conclusion reports all 3,758 self-generated retrieval tests including the blind test's 2,071 claims). The suite also catches key-selection errors that coverage misses — e.g., a defaulted arbitrary column and a key on a duplicate-laden name column were both flagged and fixed by general deterministic logic.

Role and storage-type agreement against ground-truth rings: semantic roles agree with the reference on 92–100% of matched attributes. Table 3 shows role agreement from 93.9% (college) to 100% and isa agreement from 98.0% to 100%. Checking the underlying data showed the small disagreement is in the reference, not in TYTAN — 21 miscategorized attributes were found where identifier type numerics were found as summable metrics instead of categorical, attributing the error to the reference schema.

The FIFA WC2026 dataset served as a fully blind generalization test: the expectation suite was annotated and frozen before TYTAN ever ran on it. Five independent blind annotators (two humans, three LLMs) wrote expectation lists from the dataset description alone, receiving no schema information. On the first fully autonomous run, TYTAN matched the core entities of all frozen expectation lists and inferred correct identifiers despite no declared keys, but failed in two instructive ways: three spurious joins passed LLM verification (goal/save counts whose small-integer ranges overlap sequential ids), and it also missed three foreign keys. After deterministic, dataset-independent fixes, the pipeline produced 7 entities, with verified keys, 19 joins and a 100% retrieval test pass rate over 2,071 self-generated claims. Table 4 shows Recall is 100% for every annotator and the ≥2-of-3 panel consensus; no expectation item present in the database was missed. The 41 unsatisfiable items did not exist in the dataset, including a Tournament entity expected by all three LLM annotators.

A notable subtlety: the LLM judge initially marked items like tournament year as unsatisfiable because no exact column exists, but human adjudication overturned 13 verdicts — the data is in the database, and the question can be answered through the schema then the item is delivered, counting and aggregation come under the analytics's engine scope. The schema's obligation is to deliver the correct date type, not derived values.

Three fully autonomous runs on four multi-table domains showed join sets agreeing on every pair of run in every domain (Jaccard 1.0), identical entity IDs across all runs (25/25 entity-table pairs), and entity sets identical except for one information-equivalent labeling choice. Residual variance is now confined to semantic typing of the few columns found in the datasets (pairwise role agreement 94–100%).

Stripping metadata from the Spider datasets (creating CSV-equivalent copies) showed that Core Structure survives metadata loss: entity sets, attribute coverage, verified keys (identical on 18 of 19 shared entity tables) and analytic roles remain unchanged. Joins, however, are where metadata has benefits, and the driver is how much the identifier value ranges overlap. Insurance recovered 4/4 FKs, college 8/9, but hospital dropped to 13/25 with four coincidental-overlap joins leak[ing] past the guards. The failure was caught by self-generated tests. Storage-hint agreement drops by design rather than by error, as all the columns in the metadata-stripped datasets are declared as TEXT, but the semantic roles are held at 92-100% throughout.

A second defect audit used a deterministic ground-truth artifact (tables, columns, declared keys, value samples, cardinalities, null rates) with no LLM judgment. Three models audited each ring and a fourth checked the merged report, with findings following a fixed defect taxonomy (D0–D9) mapping onto the three research questions.

TYTAN-generated rings for school shooting and wildfire were loaded into SATYRN, a platform for analytics-augmented generation, which answered analytic questions over live databases end-to-end (e.g., How many fires were there in Illinois in 2020? → In 2020, Illinois experienced a total of 125 wildfires.). The authors emphasize this demonstration validates integration and not analysis quality.

The central finding is the importance of deterministic grounding:

"Most errors we encountered during development occurred when an LLM output was accepted without enough support from the database. Some example failures include: the model proposing joins because two columns had similar names, including example values that were not present in the data, inferring types from column names alone, and selecting keys without checking whether they were unique. Better and more strict prompts did not reliably prevent these errors. Instead, we moved verifiable decisions out of the LLM: values, uniqueness, and column overlap are computed directly, while the model is used for semantic judgments that require domain knowledge."

The results show that removing the declared metadata had little effect on the entities, attributes, keys, and roles produced by the system, suggesting the approach can work with raw CSV exports as well as curated relational databases, while join discovery was more sensitive to missing metadata.

The paper acknowledges several limitations: TYTAN is developed for relational and tabular data — hierarchical formats like JSON require flattening, and knowledge graphs are out of scope. Join discovery is intentionally conservative and may miss relationships where representations differ (numeric ID vs. name). Value-overlap checks assume full database access; with only samples, finding no shared values does not rule out a relationship confidently. Removing metadata increases construction cost by roughly a factor of five. Composite-key discovery uses declared foreign keys to generate candidate combinations, so it is less effective when those declarations are missing. The clarification loop assumes a domain-understanding (though not database-expert) user; the quality of default answers in unattended mode is not separately measured. Finally, the expert reference schemas were written for the same downstream system used in our extrinsic evaluation, SATYRN — usefulness for other consumers has not yet been tested directly.

The paper concludes: "Across eight databa…

Based on the paper, I can improve AI systems in the following specific ways:

• Deterministically verify every LLM-generated schema proposal against the live database. Instead of trusting LLM outputs, the system will automatically check column mappings by name-and-type matching, validate joins via value overlap over all distinct values, verify keys by uniqueness over all rows, and confirm types using actual sample values. Any proposal that fails the data check is rejected or corrected.

• Separate physical storage type from analytic semantic role. The improved system can recognize that an integer column may be a categorical identifier, not a metric. It will refuse to mark zip codes, phone numbers, or department codes as Numeric just because they contain digits. It can also refine storage types (e.g., string to integer) only when the sampled values support it, and downgrade impossible roles (e.g., Datetime label on non-temporal values) to Categorical.

• Verify entity identifiers before using them. The system can find a valid primary key for every entity by searching candidate columns, rejecting non-unique columns, excluding numeric measures, and considering composite keys for fact tables. This ensures counts, joins, and group-by operations downstream are correct.

• Filter join candidates with deterministic guards before LLM semantic verification. The system will drop joins whose columns share no values, exclude source columns that are principal keys or numeric measures, avoid ambiguous columns overlapping three or more tables, and only accept LLM-verified joins above a confidence threshold. This prevents spurious joins like goal counts overlapping sequential IDs.

• Build a self-constrained analytic schema (ring) with provenance and retrievability. The improved system can output entities, attributes with analytic roles, verified join paths with direction, and human-friendly names/descriptions grounded in real data. It can also generate self-checking retrieval tests—identifier uniqueness, attribute reachability, join execution, reference-template resolution—and run them against the database to guarantee every claim in the schema is executable.

• Ask targeted clarification questions only when the evidence is ambiguous. The system can identify decisions the database cannot settle (e.g., is this table an entity or a junction table?) and ask the user a focused natural-language question with a sensible default, allowing fully autonomous operation when needed.

• Operate reliably on raw CSV-like data with no declared keys, foreign keys, or reliable types. By computing uniqueness, value overlap, and type evidence directly from data, the system can still construct accurate semantic layers for flat files, with entity sets, keys, and roles preserved even when metadata is stripped.

• Catch and correct its own errors via a deterministic expectation suite. The system can run thousands of self-generated retrieval claims against the source data, flagging key-selection errors, broken joins, and unreachable attributes, then fix them using general deterministic logic without human intervention.

• Separate schema construction from analytical derivation. The system will provide the correct date type, entity, and join to answer a question like “tournament year,” even when no exact column exists, because the answer is derivable through the schema; the downstream analytics engine handles counting and aggregation.

With these improvements, the AI system can automatically build reliable analytic semantic schemas from relational or flat data, answer natural-language queries over live databases with fewer misinterpretations, recover from missing metadata, self-audit its outputs, and reduce dependence on manual database expertise—while keeping a human in the loop only for genuinely ambiguous semantic choices.

From natural-language query interfaces to automated report generation, data analysis tools need a description of the data: the real-world entities it contains, which columns function as measures or identifiers, and how tables connect into units of analysis. Today, this semantic layer is usually written by hand. This is a knowledge-acquisition bottleneck that limits the scalability of analytic systems, keeps non-technical users dependent on experts, and is itself error-prone. We present TYTAN, a system for automatically constructing an analytic semantic schema from a relational database and, when available, a short user-provided description. TYTAN combines symbolic analysis of the database with LLM-based semantic inference for entity proposal, role assignment, and naming. When the evidence leaves a decision ambiguous, TYTAN asks the user a targeted natural-language question. We evaluate TYTAN on eight databases spanning real-world and benchmark domains along the three axes that define a schema's functional utility: (i) coverage, are all important entities and features captured?; (ii) retrieval correctness, do the schema's instructions actually reach the data; and (iii) characterization accuracy, are semantic types correct? Across the seven reference domains, TYTAN reaches every entity, attribute, and aggregable feature of the expert-corrected reference schemas (100% coverage). Additionally, 100% of its retrieval instructions execute correctly (1,678 of 1,678 self-generated claims), and semantic roles agree with the reference on 92-100% of matched attributes. Checking the underlying data showed the small disagreement is in the reference, not in TYTAN. On a held-out blind test (a live, ten-table database with no declared keys), TYTAN recovers the full entity structure with verified keys and satisfies 100% of the satisfiable expectations of five independent blind annotators.