English
JapaneseAsk most executives where their organization’s most valuable information lives, and they will point to the data warehouse. The more honest answer is: somewhere else. The detail that settles a warranty dispute, prices a risk, or explains a recurring defect usually sits in a contract, an inspection report, an email thread, or a photograph, not in a tidy database row.
This is the defining challenge of enterprise AI. Linking unstructured and structured data (connecting what lives in documents and images to the records in your core systems) is what separates an AI that can reason over your whole business from one that only sees half of it. This article sets out how that linking actually works: extraction, ontology mapping, and entity resolution. Done well, it is what grounds probabilistic AI in deterministic business knowledge.
Why Most Enterprise Value Is Locked in Unstructured Data
Most of the information that drives decisions sits outside structured systems: free-text claim notes, contracts, technical manuals, emails, inspection reports, and increasingly images, from damage photographs and parts to engineering drawings and scanned forms. This is unstructured data.
Your core systems, by contrast, hold structured data: transactions and master records arranged in rows and columns. The problem is not that either source is deficient. It is that they live in separate worlds, while the questions that matter most to the business routinely span both.
Two Data Streams, One Asymmetry
Enterprise data flows as two parallel streams, structured and unstructured, but the two are not handled symmetrically.
Structured data already carries meaning. A VIN identifies a vehicle; a customer ID identifies a customer. Such records can connect to an ontology almost as they are. Unstructured data is different: a person can read it, but its meaning is not explicit to a machine. Before it can join the same model, that meaning has to be extracted.
That work proceeds in three stages: extraction, mapping, and entity resolution. Each matters and skipping any one of them is where most initiatives quietly fail.
Step 1: Extracting Meaning from Text, Documents, and Images
The right extraction technique depends on the input.
Text (emails and free-text notes) yields to named-entity recognition and relation extraction, increasingly augmented by large language models that turn prose into subject-predicate-object triples. From “a warranty claim on a Corolla,” a system can derive a small graph of facts. This is the principle behind GraphRAG, which builds a knowledge graph directly from text.
Documents (forms, contracts, claim sheets) need more than OCR. Document AI understands layout, capturing keys and values, tables, and the relationships between fields. Cubastion uses Azure Document Intelligence (Form Recognizer) to extract data field by field, including from scanned PDFs and handwriting.
Images (damage photographs, parts, drawings) call for multimodal models that infer attributes and condition: the location of damage, the type of a component, a symbol on a schematic. Images are also the least forgiving input, which is precisely why confidence scoring and verification, discussed below, matter most here.
Whatever the source, the output converges on a common intermediate representation: entities, attributes, and relationships. That shared form is the entry point to everything that follows.
Step 2: Mapping to an Ontology
Raw extractions arrive messy. “Warranty” appears in different spellings and languages; a single concept fragments into near-duplicates. An ontology (a predefined schema of the concepts and relationships your business actually uses) gives those fragments a place to land.
Extracted terms are mapped to the ontology’s canonical classes and properties. Synonyms and variants collapse into a single concept, so that data from every source aligns on the same meaning. Without that schema, extraction produces noise; with it, the same output accumulates as coherent, reusable knowledge.
Step 3: Entity Resolution Is Where the Linking Happens
This is the heart of the matter. Entity resolution, also called record linkage, resolves an entity pulled from a document to its canonical identifier on the structured side (a VIN, a customer ID, a part number) and binds both to the same real-world thing. This is what “linking” actually means.
In practice it runs in stages: blocking narrows the field of comparison; candidate generation surfaces plausible matches; matching combines deterministic keys (an exact VIN) with probabilistic similarity (names and addresses that vary in spelling); and a merge step consolidates confident matches while holding ambiguous ones, with a confidence score, for human review.
Only after this step do the two streams become a single graph. Extraction and mapping alone do not link anything. It is resolution to a shared identifier that finally makes a document and a database record point to the same entity.
The Reference Architecture
The end-to-end picture is two streams converging on one semantic layer. Structured data connects as entities almost directly. Unstructured data connects only after extraction, mapping, and resolution. Both meet on the ontology and knowledge graph, and only there do large language models and AI agents reason over the combined whole.
The distinction matters. The path is not data → AI, nor even data → ontology → AI. For unstructured sources it is data → extraction → mapping → resolution → ontology → AI. That extra stage is the work most organizations underestimate.
Engineering for Reality: Confidence, Provenance, and Governance
Extraction is never perfect, least of all with images, handwriting, and poor scans. The discipline lies in keeping flawed extractions out of the graph in the first place. Four controls make that possible: confidence scores that flag uncertain results for review; a human-in-the-loop path for the ambiguous cases; provenance, so every fact records the exact document and location it came from; and governance, deciding deliberately what sensitive content is ingested and what is not. Provenance, in particular, is the foundation of the explainability and auditability that any regulated enterprise will demand.
One principle underpins all of it: do not attempt everything at once. Scope to a single use case, integrate only the sources that case requires, and prove the result before expanding.
How Cubastion Implements the Semantic Layer
Cubastion builds this linking layer in live enterprise environments. Document AI and OCR (Azure Document Intelligence / Form Recognizer) structure forms and documents; Engineering.IA combines structured filtering with semantic search; and AI-CMS manages the lifecycle of technical documentation and parts information. Each is a component of the same goal: unifying unstructured and structured data on a single layer of meaning.
The Bottom Line
Linking unstructured and structured data is not magic. It is a repeatable process of extraction, mapping, and entity resolution, with an ontology as the connective layer beneath it. When information that was trapped in documents and images finally sits on the same graph as your core records, AI can reason over the entirety of your enterprise knowledge rather than a convenient slice of it.
The semantic layer is often sold as a way to organize structured data. Its real value is the opposite: it is what lets you finally put your unstructured data to work.
