Best Practices for Making Legacy Data Semantic and AI-Ready

Overview

Many legacy data models distribute the meaning of a single business instance across multiple tables, codes, joins, reference data sets, and application rules. A Person, Customer, Product, Application, Service, Vendor, or Contract may not be understandable from one row alone.

AI retrieval should not be expected to reconstruct that meaning at query time. Instead, the enterprise should prepare a whole Semantic Instance Document in advance and feed that document into the indexing process used by enterprise search, vector databases, RAG pipelines, or AI agents.

A Semantic Instance Document should include the instance identity, Semantic ID, display name, natural-language description, important Semantic Attributes, derived Semantic Traits, governed Semantic Relationships, source lineage, refresh date, sensitivity classification, ownership, and approval metadata. This pattern complements Building and Using Enterprise Knowledge Models with AI-Generated Data Graphs, which explains how structured knowledge can be compiled and used by AI.

semantic_id: customer.acme-manufacturing

legacy_id: CUST-004817

display_name: Acme Manufacturing

description: Acme Manufacturing is an active strategic customer in the Northeast region.

relationships:

\- customer.acme-manufacturing is managed by person.jane-smith

\- customer.acme-manufacturing uses product.enterprise-support-plan

Figure: Semantic Instance Document Generation Flow shows how fragmented relational data is joined, reconstructed, semantically enriched, and transformed into one governed AI-consumable document before indexing and AI retrieval.

Figure: Runtime Join vs Prebuilt Semantic Instance Document shows why prebuilt Semantic Instance Documents provide faster, more consistent, and better-governed AI context than repeated query-time joins and runtime reconstruction. Whenever possible, favor prebuilt semantic documents over runtime joins.

Examples

The following illustrate this step in practice.

Example 1: A complete application document is generated containing its Semantic ID, owner, lifecycle status, business capabilities, vendors, technologies, data stores, risks, controls, lineage, and source references.

Example 2: A customer document combines approved identity data, active products, service history, preferences, consent restrictions, and related contracts into one governed representation for AI retrieval.

Best Practice

Generate whole Semantic Instance Documents for important Noun Types before indexing them into vector databases, search indexes, or AI retrieval systems.

Benefit(s)

AI receives complete, readable context at retrieval time. The enterprise avoids making AI perform fragile runtime joins, while still preserving source systems as the authoritative systems of record.

Best Practice

Include Semantic ID, legacy identifiers, display name, description, Semantic Attributes, Semantic Traits, Semantic Relationships, lineage, sensitivity, refresh date, and governance metadata in each Semantic Instance Document.

Benefit(s)

The retrieval object becomes understandable, traceable, filterable, and governable. AI is less likely to retrieve an orphaned fragment that lacks enough context to support a reliable answer.

Best Practice

Generate separate but linked sub-documents when a whole instance is too large for effective retrieval or chunking.

Benefit(s)

Large instances can be split into controlled retrieval objects, such as customer overview, customer contracts, customer products, and customer support history, while each sub-document still preserves the parent Semantic ID and enough context to avoid orphaned retrieval.

Best Practice

Treat Semantic Instance Documents as generated AI-ready representations, not as systems of record.

Benefit(s)

This keeps authority in the source systems while still giving AI a prepared semantic view that is suitable for search, vector indexing, traversal, and reasoning.