TL;DR. The instinct in catalog and integration tooling right now is to point a large model at every matching problem. A NeSy 2026 paper on enterprise data mapping measures what that instinct costs: LLM-only matching scored F1 0.08 on a benchmark with structural decoys, while the same models behind a hard admissibility gate built from schema metadata scored 0.66. The gate shrank the candidate space roughly 480x before any model ran, and a small model inside it matched a frontier model used without it at roughly 28x lower inference cost. The accuracy was in the constraints all along, and the constraints are things your databases already declare.
Every data team now runs some version of the same job: given attributes in one system, find the corresponding attributes in another. Catalog enrichment, mapping one provider's feed onto an internal schema, aligning two ERPs after an acquisition, wiring a semantic layer to physical tables. The 2026 default answer is to embed everything, retrieve nearest neighbors, and let a model decide. It demos beautifully, because the failure mode is invisible in a demo.
The failure mode has a precise shape. A large model matching unit_price will happily land on a column that holds prices in a different currency, at a different granularity, or as a formatted string, because at the level of names and descriptions the match is excellent. The authors of Constraint-Guided Enterprise Data Mapping with Large Language Models (Monka, Anantharam, Vo Minh, and Halilaj, accepted at NeSy 2026) call these "fluent yet operationally invalid correspondences": mappings that read correctly and break the moment data flows through them. Enterprise records make this worse than the academic setting, with semi-structured payloads, implicit attributes, and unit or granularity mismatches that no name-level similarity can see.
Filter first, rank second
The paper's method, constraint-guided mapping, has three stages, and the order is the argument. First, admissibility constraints are derived from schema metadata: types, units, structural invariants, the facts that make a candidate possible or impossible regardless of how semantically similar it looks. Second, candidate generation runs restricted to what those constraints admit, with a cascade relaxation that widens the constraint set only when it would otherwise be empty, so noisy metadata degrades the filter gradually instead of breaking it. Third, and only then, neural ranking with bounded LLM disambiguation runs inside the surviving feasible set.
The framing worth stealing is that constraints act as hypothesis-space operators, not post-hoc validators. Most production pipelines that use constraints at all use them backwards: generate matches with a model, then check the output. That still pays full model cost on the whole space, still lets the model anchor on a fluent-but-wrong candidate, and produces rejections rather than better candidates. Applied before generation, the same constraints change what the model is asked: not "which of these ten thousand columns matches?" but "which of these handful of admissible columns matches?"
The gate runs before the model, so most of the space is never sent to one.
The ablation is the headline
On a controlled benchmark built with structural decoys, near-matches designed to be semantically plausible and structurally wrong, hard admissibility cut the candidate space by about 480x without dropping the ground-truth answer. The layer-by-layer ablation then locates the lift: the gate, not the LLM, is the decisive layer, taking F1 from 0.08 to 0.66, and the result holds across models. The paper also reports the operational corollaries: a small model with constraints matching a frontier model without them at about 28x lower inference cost, transfer across seven enterprise datasets, and expert mapping effort down roughly 7x against spreadsheet workflows.
Treat the specific numbers as one benchmark's numbers. The direction, though, is consistent with what anyone who has run matching in production has half-noticed: the model is rarely wrong about semantics, it is wrong about validity, and validity was never the model's job. A ranking layer cannot recover information the candidate generator threw away, and an unconstrained generator throws away nothing, which is the problem. Feeding a model everything means asking it to rediscover, per query and per token, facts your schema states once.
This is a version of an argument we made about tuning models for database work: the instinct to fix data problems in the model keeps losing to fixing them in the structure around the model. It also cuts against the RAG-everything pattern in current catalog tooling, where declared metadata is flattened into text chunks so an LLM can read it back probabilistically. Flattening a foreign key into prose and retrieving it by similarity turns a hard fact into a soft one, then spends model capacity trying to make it hard again.
Your database already wrote the constraints
The practical question is where admissibility constraints come from, and the unglamorous answer is that most of them are sitting in the systems being matched. A Postgres schema declares types and nullability. Foreign keys and uniqueness constraints fix the referential structure and cardinality. CHECK constraints encode accepted ranges and enumerations. Statistics describe value distributions cheaply. Units and granularity, the two killers in enterprise mapping, live less reliably in column comments and naming conventions, which is exactly the gap a catalog is supposed to close by recording them as structured fields rather than tribal knowledge.
Where the schema is honest, constraint extraction is a query. Where it is not, and legacy estates are full of integer columns with no keys and meaningful codes, the constraints have to be recovered before they can gate anything. That recovery is a discipline of its own, and it is the same one we described for reverse engineering an undocumented schema: profile values, mine join patterns from query logs, and grade every inferred relationship by confidence. The cascade-relaxation idea gives recovered constraints a natural home, since a low-confidence constraint can sit in an outer relaxation layer where it prunes candidates without ever being able to empty the feasible set on its own.
The metadata pipelines are already converging on making this material available. dbt Core 2.0 turned its artifacts into queryable Parquet precisely so downstream tools can ask narrow structural questions instead of parsing a blob, and a strict spec means what lands in those artifacts was actually enforced. A catalog that ingests constraints as constraints, rather than as documentation strings, is holding the highest-leverage input to every matching job it will ever run.
What this changes in a pipeline
For a team building or buying matching, the paper converts into four concrete design moves.
Make constraint extraction a first-class pipeline stage, with the same monitoring as ingestion. If the gate is the decisive layer, its inputs decide your accuracy ceiling before any model choice does.
Put the budget in the metadata, not the model tier. The cost result says a small model inside a feasible set beats a large one outside it. Matching runs continuously as schemas and providers evolve, so this is a recurring bill, and 28x on a recurring bill is an architecture decision.
Log the gate, not just the match. A constraint-filtered decision is auditable in a way a raw model score is not: the pipeline can state which constraints admitted a candidate and which relaxation layer it needed. When a mapping later breaks, that trace distinguishes "the constraint was wrong" from "the model chose badly", which are different fixes owned by different people.
Treat relaxation as a state worth alerting on. A match that only exists because the cascade widened is a match your metadata could not justify at full strictness. That is precisely the item a reviewer should see first, and a place where a human answer should flow back into the catalog as a new constraint.
None of this makes the model unnecessary, and the paper does not claim it does. Inside the feasible set, semantic disambiguation is real work that symbolic filters cannot do, and F1 0.66 on decoy-heavy enterprise data still leaves a third of the problem needing review. The claim is narrower and more useful: every point of accuracy you can get from structure is cheaper, more stable, and more explainable than the same point bought from a bigger model.
Where Datapace fits
This paper describes the mechanism that makes a context layer pay for itself: governed metadata used as an operator on what a model is allowed to consider, not as prose for it to read. That operator is what Datapace is building for Postgres estates. In our OpenMetadata analysis we argued catalogs are being rebranded as context layers; constraint-guided matching is the concrete test of whether a context layer is real, because a filter, unlike a description, has to be correct. Datapace records the constraint-shaped facts about your Postgres schemas, validated by the people who own them, and serves them over MCP so an agent's hypothesis space arrives pre-narrowed the way CGM's feasible sets are. If your matching or your agents currently ask a frontier model questions your schema already answers, book a call.
Sources
- Sebastian Monka, Pramod Anantharam, Thien Vo Minh, Lavdim Halilaj, Constraint-Guided Enterprise Data Mapping with Large Language Models, arXiv:2608.24218, accepted at NeSy 2026 (method stages, cascade relaxation, 480x candidate-space reduction, F1 0.08 to 0.66 ablation, 28x cost result, transfer and effort figures).
- dbt Labs, We are re-building dbt-docs for speed & scale, dbt-core discussion #13080 (queryable metadata artifacts as the emerging catalog input).
- knowledge-fusion, LLMatch, an open-source LLM schema matching pipeline (representative of current LLM-first matching architecture).