MANAGING THE GEN AI LLM ENVIRONMENT

ER/Studio: The Semantic Backbone for Enterprise AI

Generative AI does not eliminate the need for enterprise data architecture. It increases it.

As AI systems reason across applications, data products, documents, analytics, and governance assets, they depend on a consistent understanding of enterprise business meaning. Without that foundation, organizations face semantic drift, conflicting definitions, unreliable analytics, and untrustworthy AI outcomes.

ER/Studio helps organizations build and manage that foundation.

At the center of ER/Studio is the Enterprise Logical Data Model (ELDM), a shared representation of enterprise business concepts, relationships, identifiers, and rules. The ELDM provides a semantic backbone that connects governance, analytics, integration, data products, and AI grounding through a common understanding of business meaning.

Using ER/Studio, organizations can:

• Define and govern shared enterprise business concepts

• Create logical and physical models that reuse and operationalize those concepts

• Support Data Product and Data Mesh initiatives with consistent enterprise semantics

• Use Enterprise Logical Data Models as canonical models for integration and messaging

• Connect data architecture with governance, glossaries, catalogs, and metadata platforms

• Provide trusted semantic context for AI, RAG, and knowledge graph initiatives

As enterprises move from data-centric architectures to AI-centric architectures, the need for governed enterprise semantics becomes increasingly important.

ER/Studio helps organizations turn enterprise meaning into an operational asset.

To learn more at www.erstudio.com

MANAGING THE ENTERPRISE GEN AI LLM ENVIRONMENT:

PRACTICAL RULES OF THUMB

(ROT)

By W H Inmon

Jamie Knowles

Dave Rapien

Generative AI in the corporate environment rests on a foundation of corporate data. The effectiveness, reliability, and trustworthiness of generative AI directly depend on the quality, consistency, and meaning of the data it operates upon. Enterprise generative AI is subject to the most fundamental law of information processing: GIGO. If the underlying data coming from the corporation is inconsistent, ambiguous, fragmented, or poorly governed, the results produced by enterprise generative AI will reflect those same problems.

To successfully use generative AI in the enterprise, organizations must pay careful attention to the many aspects of the corporate data foundation that feeds enterprise generative AI. This foundation of data includes not only structured data, but also documents, policies, reports, metrics, classifications, business rules, metadata, and the semantic relationships that connect them together.

The challenge is that enterprise data exists across many corporate systems, domains, applications, and technologies. Over time, business meaning naturally diverges across such a large and diverse environment. Different systems define the same concepts differently. Business terminology changes. Duplicate entities emerge. Metrics drift. Governance becomes fragmented. As enterprises grow, this semantic entropy accumulates and increasingly affects integration, analytics, governance, and AI reliability.

Enterprise Generative AI amplifies these issues because it operates across large collections of structured and unstructured information simultaneously. AI systems infer meaning probabilistically from the information they are given. Without governed enterprise semantics, AI systems can produce inconsistent, unreliable, and difficult-to-govern answers.

Managing the corporate LLM environment therefore becomes a critical enterprise discipline. The management of tokens within the LLM environment is an important part of this discipline. Large Language Models operate on tokens derived from enterprise content. The volume, quality, structure, and governance of those tokens directly affect processing cost, retrieval quality, semantic consistency, and the reliability of AI-generated results. Minimizing unnecessary or poorly governed content reduces both computational overhead and the propagation of semantic inconsistency within the AI environment. The Large Language Model environment depends not only on prompts and vector databases, but also on the semantic quality, structure, governance, and consistency of the information used to ground AI reasoning.

The Enterprise Logical Data Model – ELDM - plays an important role in this environment. The ELDM provides stable business entities, relationships, identifiers, and definitions that form a semantic backbone for enterprise AI. Business glossaries, ontologies, governance policies, classifications, dimensional models, data products, canonical messages, and AI retrieval systems all become more effective when grounded in shared enterprise business meaning.

The rules of thumb contained in this document are intended as practical guidance for the practitioner responsible for implementing and managing generative AI in the corporation. They are based on decades of experience in data architecture, data warehousing, governance, integration, and enterprise modeling, adapted for the realities of modern AI systems.

These rules are intentionally practical, concise, and experience-based. They are not theoretical academic principles. They are operational observations intended to help organizations reduce semantic inconsistency, improve AI trustworthiness, lower integration and governance cost, and create a more stable foundation for enterprise AI.

Ultimately, trustworthy enterprise generative AI depends on trustworthy enterprise meaning.

The following collection of rules of thumb (ROT) are a compendium of best practices in the management of the LLM environment.

LLM Management Rules of Thumb

This booklet is a guideline for understanding and implementing LLM’s in the corporation.

1. Rule Of thumb: an ontology typically contains less than ten taxonomies.

Explanation: if an ontology contains more than ten taxonomies, the data becomes increasingly more difficult to work with and understand.

2. Rule Of thumb: the taxonomies in an ontology all relate in some form or the other to the subject/focus of the ontology.

Explanation: all taxonomies relate in some way or the other to the subject of the ontology. However, the relationship of the taxonomies to the subject/focus of the ontology can be quite different from each other.

3. Rule Of thumb: There may or may not be a relationship between the elements of the taxonomies in an ontology to each other.

Explanation: some taxonomies have a natural intersection with other taxonomies inside an ontology. Other taxonomies have a limited or no relationship to the elements found in other taxonomies found in an ontology.

4. Rule Of thumb: All of the elements in a taxonomy have the same or very similar relationship to the subject/focus of the taxonomy.

Explanation: If the subject/focus of the taxonomy is type of car, bread, soccer, and world peace do not belong in the taxonomy.

5. Rule Of thumb: if the subject/focus of the ontology domain is restricted, than the elements of the taxonomies that are in the ontology have the same domain restrictions.

Explanation: if the ontology subject/focus was North American landscape then a taxonomy in the ontology would not include the Nile, Amazon or the Mekong Delta. These rivers are not in North America.

6. Rule Of thumb: minimizing the number of taxonomies is a good practice.

Explanation: There are an infinite number of ways to make a classification. The LLM analyst tries to keep the number of taxonomies that are developed to the smallest number possible. This is to simplify and streamline the LLM environment.

7. Rule of thumb. Generic taxonomies can save huge amounts of time.

Explanation: Some taxonomies can be generic, such as accounting and finance taxonomies. These taxonomies can be used generically across lots of industries, saving unneeded time for development and maintenance.

8. Rule of thumb. Ontologies and taxonomies require ongoing maintenance.

Explanation: Most developers forget that ontologies and taxonomies require periodic maintenance. The good news is that after the ontology or taxonomy is created, existing maintenance is incremental or marginal.

9. Rule Of thumb: Do not attempt to build your LLM on a one time, grab everything basis.

Explanation: for many reasons building the tokens inside the LLM is an ongoing proposition, not a one time do it and finish effort. There are many reasons for this –

Business changes

New material keeps appearing

There is a lot of material to be entered in any case

Source material comes from a wide variety of sources

10. Rule Of thumb: Do not enter extraneous text – non business related text - into your RAG to be converted to tokens,

Explanation: when extraneous text – non business related text - is entered into the LLM, the result is that the amount of resources needed to execute queries grows to be quite large. In addition, extraneous text increases the chances of hallucinations. In order to make analytical processing efficient, the only text that should be used as a source for an LLM is business based text.

11. Rule of thumb. A log should be kept for exactly what source data was used to load the LLM.

Explanation: At a later point in time it may be necessary to remove text from an LLM. If a log is not kept of the text that was loaded into an LLM, it is not going to be possible to find the text that needs to be removed.

12. Rule Of thumb: When text is presented to the LLM for entry, the source of the text should always be attached to the text itself.

Explanation: some generative AI can keep track of the source of text. If there is ever any question as to the veracity of the text, it must be captured and presented to generative AI at the moment that text is prepared to enter the LLM.

13. Rule Of thumb: if at all possible the context of the text that is being entered into the LLM needs to be captured.

Explanation: Having the context of the text being entered into the LLM is a first and important step in the removal of hallucinations from the results being presented to the end user.

14. Rule Of thumb: Buffer management of queries can reduce the cost of the query. But buffer management has to be invoked on every query and does not stop the processing of extraneous data.

Explanation: Query buffer management does reduce the cost of query processing in LLM query processing. And query buffer management should be done. But query buffer management does nothing to prevent extraneous text from entering the LLM and only applies when iterative query processing is done.

15. Rule Of thumb: Removing stop words before they arrive in the RAG has only a minimal effect on the reduction of resources consumed during LLM query processing.

Explanation: Stop word editing should be done before raw text is sent to the RAG. But removing stop words has only a very marginal effect on the reduction of the cost of LLM query processing.

16. Rule of thumb. Reducing the text that goes into the LLM by removing extraneous text before entry has the potential of reducing hallucinations by up to 80%.

Explanation: Extraneous text entered into an LLM increases the odds of hallucinations by an order of magnitude.

17. Rule Of thumb: Preparing text for entry into an LLM can be done either on the cloud or on premise.

Explanation: text that contains private data should be processed on premise. But text that is not private is easier and less expensive to be processed on the cloud.

18. Rule Of thumb: It is a good idea to keep a log of the text used to feed the LLM. The log should identify the document, the date and who conducted the loading of text into the LLM.

Explanation: It may be necessary to reprocess the loading of the text. It is useful to know the specifics of the loading of text that has occurred.

19. Rule Of thumb: editing and refining text at the moment of loading into the RAG and removing extraneous text greatly clarifies and focusses the results that are generated.

Data Modeling Rules of Thumb

A collection of practical enterprise data modeling principles focused on logical modeling, semantic consistency, and business understanding for enterprise AI.

1. Rule Of thumb: The semantic backbone is the foundation of trustworthy enterprise AI.

Explanation: Without explicit business context, AI systems infer meaning probabilistically, often producing inconsistent or incorrect answers. An ELDM is an ideal implementation of this.

2. Rule Of thumb: Every data asset should follow a design process of logical model to physical model to code.

Explanation: This process ensures that business meaning, architectural standards, and governance are established before implementation begins. It also creates approval gates that confirm requirements are understood and met before progressing to the next stage.

3. Rule Of thumb: A logical data model should describe the business, not the application.

Explanation: Applications change frequently. Core business concepts change slowly.

4. Rule Of thumb: If the business cannot read the model, the model is too technical.

Explanation: Logical models exist to validate understanding before implementation begins.

5. Rule Of thumb: Every entity should represent a business concept with a clear definition.

Explanation: Tables are technical structures. Entities represent real business meaning.

6. Rule Of thumb: A model with duplicate entities usually reflects duplicate thinking.

Explanation: Multiple versions of the same concept create confusion, inconsistency, and reconciliation problems later.

7. Rule Of thumb: Reusable architectural patterns derived from the Enterprise Logical Data Model create consistency across the enterprise.

Explanation: Using common business structures, naming standards, and integration patterns improves interoperability, governance, maintainability, and shared understanding.

8. Rule Of thumb: The Enterprise Logical Data Model should describe business concepts before analytic structures.

Explanation: Star schemas and data vaults optimize implementation and delivery. The enterprise model defines the underlying business meaning they are built from.

9. Rule Of thumb: Business users should not need a decoding guide to read a model.

Explanation: Clear attribute names improve communication, governance, integration, and long-term maintainability.

10. Rule Of thumb: Attribute names should describe business meaning, not system implementation.

Explanation: Names like “Customer Status Code” are useful. Names like FLG1 or TXT_FIELD_7 are not.

11. Rule Of thumb: The enterprise model should survive technology migrations.

Explanation: A good logical model remains stable even when databases and platforms change.

12. Rule Of thumb: Relationships are often more important than attributes.

Explanation: Businesses operate through interactions between concepts, not isolated pieces of data.

13. Rule Of thumb: If an entity has no business key, the business may not truly understand it.

Explanation: Natural business identifiers reveal real-world meaning and integration points.

14.Rule of thumb: A well-understood business entity usually has more than one business identifier.

Explanation: Customers, products, and accounts are often identified differently across operational systems, requiring alternate business keys for integration.

15. Rule Of thumb: Connecting a business glossary to the Enterprise Logical Data Model creates a governed semantic backbone.

Explanation: The glossary contributes definitions, synonyms, policies, and rules, while the model contributes structure, relationships, and integration context.

16. Rule Of thumb: Normalization clarifies meaning before denormalization optimizes performance.

Explanation: Understanding should come before optimization.

17. Rule Of thumb: A data warehouse should integrate business concepts, not merely copy source systems.

Explanation: The purpose of warehousing is harmonization, not replication.

18. Rule Of thumb: A logical model should resolve business ambiguity before physical design begins.

Explanation: Physical databases cannot fix unclear business definitions.

19. Rule Of thumb: The same business term should not mean different things in different models.

Explanation: Semantic consistency is essential for analytics, governance, and AI.

20. Rule Of thumb: Good modelers ask business questions, not database questions.

Explanation: The goal is understanding the business before choosing technology structures.

21. Rule Of thumb: A many-to-many relationship usually hides an important business process.

Explanation: Intersection entities often reveal transactions, events, or activities the business cares about.

22. Rule Of thumb: History should be modeled deliberately, not accidentally.

Explanation: Temporal requirements become expensive when ignored early.

23. Rule Of thumb: Every model should have a clearly defined scope.

Explanation: Unbounded models quickly become unmanageable and politically contentious.

24. Rule Of thumb: Master data should appear once in the enterprise model.

Explanation: Core business entities should be standardized before downstream systems multiply variations.

25. Rule Of thumb: If two entities differ only by department name, they probably should not be separate entities.

Explanation: Organizations often duplicate structures instead of generalizing concepts properly.

26. Rule Of thumb: Naming standards matter more in enterprise models than in physical databases.

Explanation: Enterprise models are communication tools used across teams and over long periods of time.

27. Rule Of thumb: A logical model should be stable enough to outlive projects.

Explanation: Projects are temporary. Enterprise meaning is long-term.

28. Rule Of thumb: Data models are negotiation tools as much as design tools.

Explanation: Modeling exposes disagreements in business understanding early, when they are cheaper to resolve.

29. Rule Of thumb: The first version of the model is always wrong.

Explanation: Modeling is an iterative process of discovery and clarification.

30. Rule Of thumb: Business requirements should be validated in a logical model, not a physical schema.

Explanation: Physical models contain technical implementation details that distract from the business meaning stakeholders are trying to confirm.

31. Rule Of thumb: A model that mirrors the source system too closely probably is not integrated.

Explanation: Enterprise integration requires abstraction beyond operational structures.

32. Rule Of thumb: Optional relationships deserve scrutiny.

Explanation: Excessive optionality often hides weak business rules or unclear processes.

33. Rule Of thumb: Good data models reduce meetings.

Explanation: Clear shared definitions eliminate repeated debates about meaning and structure.

34. Rule Of thumb: Ontologies work best when grounded in stable enterprise business structures.

Explanation: Enterprise logical models provide the enduring business entities and relationships that ontologies, glossaries, and AI systems build upon.

35. Rule Of thumb: AI should not be grounded on a business glossary alone.

Explanation: Glossaries define terms, but enterprise models provide the structural relationships and context needed for reliable reasoning.

36. Rule Of thumb: Data governance is strongest when aligned to the Enterprise Logical Data Model.

Explanation: Policies, classifications, stewardship, and business rules become more consistent when attached to shared enterprise business structures.

37. Rule Of thumb: Enterprise models provide the structural context that governance tools often lack.

Explanation: Logical models expose relationships, hierarchies, and integration paths needed for trustworthy analytics and AI.