Knowledge Architecture: Ontologies, Entity Resolution and Graph Retrieval

This section sits underneath almost everything else in enterprise AI.

The central proposition is:

An enterprise AI system is only as useful as the data foundation that lets it identify what an entity is, what is true about it, where that truth came from, who is allowed to see it, how current it is, and what evidence supports it.

A vector database does not solve this problem. RAG does not solve this problem. A knowledge graph does not solve it by itself either.

The architecture normally becomes:

Enterprise Sources
        │
        ▼
Ingestion / CDC / Events
        │
        ▼
Parsing + Structural Normalization
        │
        ▼
Semantic Normalization
        │
        ▼
Entity Resolution / Mastering
        │
        ▼
Canonical Knowledge Layer
   ├── Structured facts
   ├── Documents/chunks
   ├── Entities
   ├── Relationships
   ├── Policies
   ├── Entitlements
   └── Evidence / provenance
        │
        ├───────────────┐
        ▼               ▼
 Search / SQL       Graph / Vector
        │               │
        └───────┬───────┘
                ▼
        RAG / Agents / APIs
                │
                ▼
       Decisions + Actions
                │
                ▼
       Operational Evidence

The architectural shift to understand is:

Enterprise knowledge is not merely stored data. It is normalized entities + relationships + evidence + provenance + policy + access semantics.

---

5.1 Structured vs Semi-Structured vs Unstructured Data

Do not define these merely by file format.

Structured data

Data conforms to an explicit schema.

Examples:

customer
--------
customer_id
name
industry
country
status

Usually found in:

• relational databases
• ERP
• CRM
• transaction systems
• data warehouses
• APIs with strongly defined schemas

Its advantage is predictable interpretation.

Its challenge is that different systems often represent the same business concept differently.

For example:

Salesforce: Account
SAP: Business Partner
Billing: Customer
Support: Organization

All four might represent the same enterprise customer.

---

Semi-structured data

Contains structure, but the structure is flexible or self-describing.

Examples:

• JSON
• XML
• event payloads
• API responses
• application logs
• EDI
• configuration
• email metadata

Example:

{
  "customer": {
    "name": "Acme Ltd",
    "region": "IN"
  },
  "products": [...]
}

The challenge is frequently schema variability.

One producer may emit:

{"customerId": 123}

another:

{"customer_id": "123"}

and a third:

{"account": {"id": 123}}

---

Unstructured data

Content where the underlying business meaning is not encoded in a rigid machine-readable structure.

Examples:

• contracts
• PDFs
• emails
• meeting transcripts
• Word documents
• images
• call recordings
• policies
• technical manuals
• support conversations

But "unstructured" is slightly misleading.

A contract contains enormous semantic structure:

Party
 ├── obligations
 ├── rights
 ├── pricing
 ├── effective date
 ├── termination conditions
 └── service levels

The structure simply has to be extracted.

That distinction becomes important in enterprise AI.

#### Architect-level framing

Do not say:

"Structured data goes into databases and unstructured data goes into vector databases."

That is too simplistic.

Instead:

"I would normalize all three into a common knowledge layer where appropriate. Structured records contribute authoritative facts, documents contribute evidence and context, and extracted entities and relationships allow the two worlds to be linked."

---

5.2 Enterprise Data Ingestion

Enterprise ingestion is the process of moving data from operational systems into the data/knowledge platform while preserving enough information to understand and trust it.

Typical sources:

ERP
CRM
Databases
SaaS applications
Object storage
SharePoint
Google Drive
Email
APIs
Event buses
Data warehouses
IoT systems
Logs
Partner feeds
External datasets

A mature ingestion architecture separates several responsibilities.

Source
  │
  ▼
Connector
  │
  ▼
Raw landing zone
  │
  ▼
Validation
  │
  ▼
Normalization
  │
  ▼
Semantic mapping
  │
  ▼
Canonical / knowledge stores

The raw landing zone matters.

Do not immediately destroy the original representation.

You often want:

raw payload
source identifier
source timestamp
ingestion timestamp
schema version
tenant
connector/version
checksum
ACL information

This gives you replayability and provenance.

---

5.3 Batch vs Streaming Ingestion

Batch

Data is processed periodically.

Examples:

nightly SAP extract
hourly CRM sync
daily transaction file
weekly vendor dataset

Good when:

• latency requirements are low;
• sources do not expose events;
• processing is expensive;
• bulk reconciliation matters more than freshness.

Architecture:

Source
  │
scheduled extract
  ▼
Object Storage
  │
  ▼
ETL / ELT
  │
  ▼
Data Platform

---

Streaming

Changes flow continuously or near-real-time.

Examples:

Kafka event
Kinesis event
database CDC event
webhook
application domain event

Architecture:

Producer
   │
   ▼
Event Bus
   │
   ├── consumer A
   ├── consumer B
   └── knowledge pipeline

Good when:

• decisions depend on fresh state;
• high event volumes exist;
• downstream automation must react quickly.

---

Do not confuse streaming with "better"

The architectural question is:

How stale can this information safely become?

A contract library may tolerate 15-minute ingestion.

Fraud detection may not tolerate 15 seconds.

A useful classification is:

Reference knowledge         → hours/days
Operational reporting       → minutes/hours
Agent operational context   → seconds/minutes
Real-time control           → milliseconds/seconds

Different data classes deserve different ingestion architectures.

---

5.4 CDC: Change Data Capture

CDC captures changes occurring in an operational database without repeatedly rereading the whole database.

Instead of:

SELECT * FROM orders;

every five minutes, CDC observes:

INSERT order 145
UPDATE customer 983
DELETE address 212

Usually by reading database transaction logs.

Examples of mechanisms include:

• MySQL binlog
• PostgreSQL WAL
• SQL Server transaction log
• Oracle redo logs

Typical architecture:

Operational DB
     │
 transaction log
     ▼
CDC Connector
     │
     ▼
Event Stream
     │
     ├── Data warehouse
     ├── Search
     ├── Cache
     └── Knowledge graph

#### Advantages

• lower source database load;
• near-real-time synchronization;
• captures deletes;
• preserves change sequence;
• useful for event-driven architectures.

#### Architectural problems

CDC does not automatically produce business events.

This:

customer.status:
PENDING → ACTIVE

may represent:

CustomerApproved

but CDC itself knows nothing about that semantic meaning.

Therefore:

Database change
       ↓
CDC event
       ↓
Semantic transformation
       ↓
Domain event / knowledge update

is often necessary.

#### Interview trap

"Would you use CDC for everything?"

No.

CDC is useful when database-level state changes are the appropriate integration boundary. Explicit domain events are usually better when applications can produce them because they capture business intent, not merely storage changes.

---

5.5 Data Normalization

Normalization here is broader than relational database normalization.

It means converting representations into consistent technical formats.

Examples:

"India"
"IND"
"IN"
"india"

become:

country_code = IN

Dates:

15/08/26
2026-08-15
15-Aug-2026

become:

2026-08-15

Currency:

₹
INR
Rs.

becomes:

currency = INR

Other normalization includes:

• units;
• encoding;
• telephone formats;
• addresses;
• timestamps;
• enum values;
• identifier formats.

This is primarily syntactic normalization.

---

5.6 Semantic Normalization

Much more important.

Semantic normalization answers:

Do these differently represented things mean the same thing?

For example:

client
customer
account
buyer
subscriber

may all map to some shared concept:

Party / Customer

Similarly:

SKU
material
item
product code

may represent:

Product

This is where ordinary ETL starts becoming enterprise knowledge architecture.

Example:

Source A:

{
 "cust_no": 927,
 "legal_name": "Acme Pvt Ltd"
}

Source B:

{
 "accountId": "927",
 "accountName": "ACME PRIVATE LIMITED"
}

Canonical meaning:

Customer
  identifier
  legal_name

Semantic normalization enables:

• cross-system integration;
• enterprise search;
• knowledge graphs;
• analytics;
• AI reasoning;
• reusable agents.

---

5.7 Canonical Data Models

A canonical model defines a stable enterprise representation of important business concepts.

Without one:

CRM Customer
ERP BusinessPartner
Billing Account
Support Organization

each downstream consumer must understand every source system.

You get:

N sources × M consumers

transformations.

With canonicalization:

CRM ─────┐
ERP ─────┤
Billing ─┼──► Canonical Customer ──► consumers
Support ─┘

Each system maps to the shared model.

---

Example canonical entity

Customer
--------
customer_id
legal_name
display_name
customer_type
country
status
identifiers[]
addresses[]
relationships[]
source_references[]

A canonical model does not necessarily mean one giant database schema.

It can mean a stable semantic contract across:

• APIs;
• events;
• graphs;
• data platforms;
• AI systems.

---

The dangerous approach

Trying to build:

"The universal enterprise data model."

This becomes a giant abstraction nobody can evolve.

Better:

Core model
  │
  ├── Party
  ├── Product
  ├── Agreement
  ├── Asset
  └── Event
Domain extensions
  │
  ├── Healthcare
  ├── Banking
  ├── Manufacturing
  └── Telecom

More on this under vertical extensions.

---

5.8 Ontologies

An ontology describes the meaning of concepts and relationships in a domain.

A schema might say:

Customer {
    customer_id
    name
}

An ontology can express:

Customer IS-A Party
Customer MAY-HAVE Contract
Contract GRANTS Entitlement
Entitlement APPLIES-TO Product
Organization OWNS Account

Ontology therefore captures:

concepts
relationships
constraints
semantic meaning

---

Ontology vs data model

A data model asks:

How should the data be represented?

An ontology asks:

What does the concept mean and how does it relate to other concepts?

This becomes particularly useful where agents must reason across multiple systems.

---

5.9 Taxonomies

A taxonomy is primarily a classification hierarchy.

Example:

Product
├── Software
│   ├── Security
│   ├── Analytics
│   └── ERP
└── Hardware
    ├── Server
    └── Network

Or:

Incident
├── Security
│   ├── Malware
│   └── Unauthorized Access
└── Operational
    ├── Availability
    └── Performance

Taxonomies help with:

• classification;
• navigation;
• metadata;
• search;
• reporting;
• policy application.

#### Taxonomy vs ontology

Taxonomy
"X belongs under Y"
Ontology
"X is a type of Y,
 X can own Z,
 Z may grant A,
 A conflicts with B..."

Ontology has much richer semantics.

---

5.10 Entity Resolution

One of the most important topics here.

Entity resolution determines whether records referring to apparently different things actually refer to the same real-world entity.

Example:

Acme Ltd
ACME LIMITED
Acme Pvt. Ltd.
ACME - India
GSTIN 27ABC...
CRM ID 9081
ERP BP 14592

Are these the same organization?

Entity resolution may use:

#### Deterministic matching

GSTIN exact match
PAN match
account ID mapping
email exact match

#### Probabilistic/fuzzy matching

name similarity
address similarity
phone similarity
domain similarity
location
relationship context

For example:

name similarity        .92
address similarity     .84
domain match           1.00
GST match              1.00
--------------------------------
entity confidence       .98

Then:

source records
      │
      ▼
entity resolution
      │
      ▼
Enterprise Entity 4873

---

Do not hide ambiguity

Bad:

Acme Ltd = Acme Holdings

Good:

candidate link:
record_342 → entity_4873
confidence = .81
method = fuzzy_match
status = review_required

This is extremely important in AI systems.

Probabilistic inference should not silently become authoritative master data.

---

5.11 Master Data Concepts

Master data represents relatively stable, shared business entities used across many processes.

Examples:

• customer;
• supplier;
• product;
• employee;
• organization;
• location;
• asset.

MDM solves questions such as:

Which customer record is authoritative?
What happens when Salesforce says the customer's name is X but SAP says Y?

---

Golden record

A common misconception:

MDM creates one perfect row.

Better interpretation:

MDM provides a governed representation of an entity assembled from multiple source records using matching, survivorship and stewardship rules.

Example:

Legal Name       ← ERP
Sales Segment    ← CRM
Billing Address  ← Billing
Risk Rating      ← Risk System

The golden record can therefore be compositional.

---

Survivorship rules

Example:

legal_name:
    Government registry > ERP > CRM
phone:
    Verified customer update > CRM > historical billing
risk_status:
    Risk system only

This is far better than:

last update wins

because timestamps do not tell you authority.

---

5.12 Entity Linking

Entity resolution generally compares records.

Entity linking commonly connects mentions appearing in text or other content to known entities.

Example contract:

"Acme shall purchase 4,000 licences..."

NLP extracts:

"Acme"

Entity linking identifies:

"Acme"
     ↓
EnterpriseCustomer:4873

Now the document is connected to structured knowledge.

Customer:4873
    │
    ├── HAS_CONTRACT ── Contract:992
    │
    ├── OWNS_ACCOUNT ── Account:212
    │
    └── MENTIONED_IN ── Document:882

This is how structured and unstructured knowledge start converging.

---

5.13 Knowledge Graphs

A knowledge graph represents entities and their relationships explicitly.

Instead of merely storing:

Customer table
Contract table
Product table

you can represent:

[Acme]
   │ HAS_CONTRACT
   ▼
[Contract 784]
   │ GRANTS
   ▼
[Entitlement 12]
   │ FOR
   ▼
[Analytics Product]

---

5.14 Nodes, Edges and Properties

In a property graph:

Nodes

Entities:

Customer
Contract
Product
Employee
Asset
Policy
Invoice

Edges

Relationships:

OWNS
PURCHASED
SIGNED
DEPENDS_ON
LOCATED_IN
REPORTS_TO
GRANTS
VIOLATES

Properties

Attributes:

Customer:
  name = "Acme"
  country = "IN"
SIGNED:
  effective_date = "2026-01-01"

Graph representations are particularly effective when relationships themselves carry meaning.

---

5.15 Graph Traversal

Graph traversal means following relationships.

Question:

Which production applications depend on servers containing certificates owned by teams reporting to this business unit?

Relational systems may require several joins.

Graph traversal:

BusinessUnit
  ↓ HAS_TEAM
Team
  ↓ OWNS
Certificate
  ↓ INSTALLED_ON
Server
  ↓ HOSTS
Application

This makes graph systems useful for:

• dependency analysis;
• IAM;
• fraud networks;
• organizational relationships;
• supply chains;
• configuration management;
• commercial relationships;
• compliance.

---

5.16 Graph Queries

Common graph query paradigms include:

• Cypher-style property graph queries;
• Gremlin-style traversal;
• SPARQL for RDF.

Conceptually:

MATCH
(Customer)-[:HAS_CONTRACT]->(Contract)
          -[:GRANTS]->(Entitlement)
          -[:FOR]->(Product)
WHERE Customer.id = 4873
RETURN Product, Entitlement

The important point is not memorizing syntax.

Understand when graph queries provide value:

When the question is fundamentally relationship-centric or multi-hop.

---

5.17 Graph + Vector Retrieval

Graphs and vectors solve different retrieval problems.

#### Vector search

Excellent for:

"What passages are semantically similar to my question?"

#### Graph retrieval

Excellent for:

"What entities are connected to this customer through these relationships?"

Combining them creates much stronger enterprise retrieval.

Example:

User asks:

"What support obligations apply to Acme's analytics deployment?"

Step 1: resolve:

Acme → Customer:4873

Step 2: graph traversal:

Customer
 ↓ HAS_CONTRACT
Contract
 ↓ COVERS
Analytics Product

Step 3: retrieve linked documents/chunks:

Contract clauses
SLA
Support policy
Amendments

Step 4: vector/reranker retrieval within those authorized documents.

This is much better than vector-searching the entire document corpus.

The graph provides scope.

Vectors provide semantic relevance.

---

5.18 GraphRAG

GraphRAG is an architectural family rather than merely "putting a graph beside RAG."

The idea is to use entity/relationship structure to improve retrieval and reasoning.

Simplified pipeline:

Documents
   │
   ▼
Entity / relation extraction
   │
   ▼
Knowledge graph
   │
   ├── Entity relationships
   ├── Document links
   └── summaries / communities
        │
Question │
   │     │
   ▼     ▼
Entity identification
   │
Graph traversal
   │
Relevant subgraph
   │
Relevant evidence/chunks
   │
   ▼
LLM

---

When GraphRAG helps

Questions like:

"How is this supplier related to previous incidents?"
"Which customers might be affected if dependency X fails?"
"What agreements, subsidiaries and entitlements are connected to this account?"

These require relationships.

Plain vector similarity may retrieve individually relevant documents while missing the connection between them.

---

When GraphRAG is overkill

Question:

"What is the password reset procedure?"

If one policy document directly answers it, good vector retrieval may be sufficient.

Architectural principle:

Use graph structure when relationships materially affect the answer. Don't add a graph merely because GraphRAG sounds sophisticated.

---

5.19 Data Lineage

Lineage tells you how data moved and transformed.

Example:

SAP.customer_name
       │
       ▼
raw_customer.name
       │
normalize()
       ▼
canonical_party.legal_name
       │
       ▼
Customer Knowledge Graph Node
       │
       ▼
Agent Response

Lineage helps answer:

Where did this value come from?
What transformations produced it?
Which downstream systems are affected if this field changes?
What data was used to generate this AI result?

For enterprise AI, lineage increasingly needs to extend to:

Source
 → extraction
 → transformation
 → chunk
 → embedding
 → retrieval
 → prompt
 → model
 → answer

---

5.20 Provenance

Lineage and provenance overlap but should not be treated as identical.

#### Lineage

How did this data move and transform?

#### Provenance

What is the origin and authority of this information?

Example:

Fact:
Acme subscription expires 2026-12-31
Provenance:
  source = Contract 784
  clause = 7.2
  extracted_at = ...
  extraction_model = ...
  extraction_confidence = .97
  reviewed_by = ...

Another system may say:

CRM:
expiry = 2027-01-31

Provenance allows the system to reason about the conflict rather than silently picking one.

---

5.21 Confidence Scoring

Do not create one vague field called:

confidence = 0.87

without knowing what it means.

Several different confidences exist.

Extraction confidence
Entity-resolution confidence
Source reliability
Freshness confidence
Cross-source agreement
Classification confidence
Inference confidence

For example:

Claim:
"Acme is entitled to 5,000 API calls/day"
Extraction confidence       .97
Entity-link confidence      .99
Source authority             1.0
Freshness                    .91
Cross-source agreement       .82

These signals may contribute to a final trust score, but retaining the components is valuable.

---

5.22 Evidence Modelling

Instead of merely storing a fact:

customer.status = ACTIVE

model:

Claim
  │
  ├── supported_by → Evidence A
  ├── supported_by → Evidence B
  └── contradicted_by → Evidence C

For example:

Claim:
Customer is entitled to premium support.
Evidence A:
Contract clause 12.4
Evidence B:
Subscription record 932
Contradicting Evidence:
CRM flag says STANDARD

This creates a much more defensible system.

---

A useful conceptual model

ENTITY
  │
  └── has FACT / CLAIM
             │
             ├── evidence
             │     ├── source
             │     ├── location
             │     ├── timestamp
             │     └── extraction
             │
             ├── confidence
             ├── validity period
             └── authority

Now an agent can answer:

"I believe X because Contract 784 clause 12.4 grants it, effective 1 January 2026."

rather than:

"My vector database found something similar."

This is a major maturity difference.

---

5.23 Trust Controls

Trust controls determine which information can be relied upon and under what conditions.

Possible controls include:

#### Source authority

Signed Contract > CRM Note
Regulatory Feed > User Comment
ERP Ledger > Spreadsheet Copy

#### Freshness

Some knowledge expires.

pricing       → 24 hours
employee role → 1 hour
contract      → until superseded
policy        → valid_from / valid_to

#### Approval

AI-extracted claim
      ↓
pending
      ↓
human validation
      ↓
authoritative

#### Cross-source consistency

ERP   says ACTIVE
CRM   says ACTIVE
Billing says ACTIVE

high agreement.

Versus:

ERP says ACTIVE
Billing says TERMINATED

requires reconciliation.

#### ACL controls

Evidence must remain subject to the authorization of its source.

An AI platform must not make:

private HR document
      ↓ extraction
      ↓ graph
      ↓ globally visible fact

This is a classic security failure.

Authorization needs to propagate into derived knowledge.

---

5.24 Data Quality

Common data-quality dimensions:

#### Completeness

Are required values present?

#### Accuracy

Does the value reflect reality?

#### Consistency

Do systems agree?

#### Validity

Does the value conform to business rules?

#### Uniqueness

Are duplicate entities present?

#### Timeliness

Is the data sufficiently fresh?

#### Referential integrity

Do references point to valid entities?

---

AI makes poor data quality more dangerous

Traditional analytics may expose:

NULL customer segment

An LLM may confidently rationalize inconsistent records and produce an apparently coherent answer.

Therefore enterprise AI needs explicit quality signals.

Example:

Customer 4873
completeness      94%
identity_conf     99%
freshness         61%
conflicts         2

This can influence agent behavior.

IF critical conflict exists
THEN
    require human confirmation

That is the connection between data architecture and AI governance.

---

5.25 Schema Evolution

Enterprise schemas change continuously.

Suppose:

Customer v1
-----------
customer_id
name

becomes:

Customer v2
-----------
customer_id
legal_name
display_name
classification

Systems cannot all migrate simultaneously.

You need:

• versioned schemas;
• backward compatibility;
• migration policies;
• adapters;
• schema registry where appropriate;
• default handling;
• additive change preference.

---

Events are particularly sensitive

Once an event has been published:

{
  "event": "CustomerCreated",
  "customerId": 42
}

hundreds of consumers may depend upon it.

You cannot safely mutate its meaning casually.

Think:

Schema v1
Schema v2
Compatibility Rules
Consumers

---

Knowledge schemas evolve too

Your ontology may initially say:

Customer → HAS_CONTRACT → Contract

later you discover:

Customer
  ↓ MEMBER_OF
CustomerGroup
  ↓ SIGNS
MasterAgreement

Knowledge architecture must support extension without destroying existing semantics.

---

5.26 Vertical / Domain Extensions

Do not build entirely separate enterprise models for every industry.

But do not force all industries into one over-generalized model either.

Use layers.

FOUNDATIONAL ONTOLOGY
Party
Organization
Person
Agreement
Product
Asset
Event
Location
Policy
Evidence
        │
        ▼
DOMAIN EXTENSION

Example healthcare:

Person
  ↓
Patient
Agreement
  ↓
Consent
Event
  ↓
ClinicalEvent
Asset
  ↓
MedicalDevice

Banking:

Party
 ↓
Customer
Agreement
 ↓
LoanAgreement
Asset
 ↓
Account
Event
 ↓
Transaction

Telecom:

Customer
Subscription
SIM
Device
Plan
UsageEvent

This allows shared platform capabilities while preserving domain semantics.

---

5.27 Commercial Data Foundation

A commercial enterprise has many systems:

CRM
ERP
CPQ
Billing
Support
Contracts
Product catalog
Usage systems
Partner systems
Email/documents

Each contains part of the commercial truth.

The commercial knowledge foundation needs to unify concepts such as:

Party
├── Person
└── Organization
Customer
Account
Contact
Product
Offer
Price
Subscription
Agreement
Contract
Order
Entitlement
Invoice
Payment
Interaction
Case
Asset
Service
Policy
Usage
Operational Event
Evidence

Then relationships:

Customer
  ├── HAS_ACCOUNT
  ├── SIGNED → Contract
  ├── PURCHASED → Offer
  ├── OWNS → Asset
  ├── HAS → Subscription
  ├── RECEIVES → Entitlement
  ├── GENERATED → Invoice
  └── RAISED → SupportCase

This becomes the commercial semantic layer above fragmented systems.

---

5.28 Why This Matters

Suppose an agent receives:

"Can Acme receive a replacement for this equipment?"

Without a commercial knowledge foundation, the agent may need to independently query:

CRM
ERP
contract repository
product system
warranty system
support system

and reconcile everything itself.

That is fragile.

Instead:

Acme
 ↓ owns
Asset A52
 ↓ purchased_under
Contract C91
 ↓ grants
Entitlement E72
 ↓ governed_by
WarrantyPolicy P18

Then supporting evidence:

Contract C91 clause 8.4
Purchase order 827
Asset registration event
Warranty policy v7

Now the agent has structured commercial context plus evidence.

That is far more powerful than simply giving an LLM access to six APIs.

---

5.29 Entitlement Modelling

An entitlement represents:

What a subject is allowed to receive, access, consume or demand because of some underlying commercial or policy relationship.

Examples:

Customer may use Product X
Customer receives 24×7 support
Employee may access application Y
Customer receives 10,000 API calls/month
Machine is covered by warranty
Subscriber may use premium feature

A strong model might contain:

Entitlement
-----------
entitlement_id
subject
resource / capability
effect
quantity / limit
unit
valid_from
valid_to
conditions
source_agreement
source_clause
policy
status
evidence

Example:

Entitlement E912
subject:
    Customer 4873
capability:
    PremiumSupport
effect:
    ALLOW
valid:
    2026-01-01 → 2026-12-31
condition:
    Product = Enterprise Analytics
source:
    Contract 784 / Clause 12.4

---

Do not conflate entitlement with RBAC

RBAC:

Role: Administrator
Permission: delete_user

Commercial entitlement:

Customer Acme
may create up to 200 users
because Subscription 582 grants this capability.

They intersect, but they are not the same concept.

The system could calculate:

Commercial Entitlement
        +
Identity Permission
        +
Runtime Policy
        =
Effective Authorization

That is a sophisticated architecture pattern.

---

5.30 Policy Modelling

Policies encode rules that influence decisions.

Example:

Enterprise customers receive replacement equipment without approval if the asset is under warranty and the replacement cost is below ₹50,000.

Do not store that merely as prose if an agent must operationalize it.

Potential representation:

Policy P22
applies_to:
    EnterpriseCustomer
conditions:
    warranty_status = ACTIVE
    replacement_cost < 50000
effect:
    APPROVE
obligation:
    create_return_request
exception:
    suspected_fraud = true
valid_from:
    2026-01-01
version:
    4

---

Policy model concepts

You should know:

Policy
Rule
Condition
Effect
Obligation
Exception
Priority
Scope
Jurisdiction
Version
Validity
Evidence requirement

Effects often resemble:

ALLOW
DENY
REQUIRE_APPROVAL
ESCALATE
REQUIRE_EVIDENCE

---

Deterministic policy around probabilistic AI

This ties directly into the core architecture principle.

LLM:
"This request appears eligible."
          ↓
Policy Engine:
Contract active?       YES
Entitlement present?   YES
Cost below threshold?  YES
Fraud flag?            NO
          ↓
ALLOW

The LLM interprets the request.

The deterministic control layer determines whether the action is permitted.

That is the architecture you want to be able to defend.

---

5.31 Operational Evidence Modelling

This goes beyond logging.

Logging says:

API called at 14:03

Operational evidence says:

What happened, why did it happen, what information was considered, which rule authorized it, and what outcome resulted?

Example:

Decision D7281
request:
    Replace Asset A52
actor:
    ServiceAgent 92
decision:
    APPROVED
basis:
    Entitlement E912
policy:
    WarrantyPolicy v7
evidence:
    Contract 784
    AssetRegistration 721
    SupportCase 192
decision_time:
    2026-08-15T10:22
model:
    classifier-v8
policy_version:
    7
outcome:
    ReplacementOrder 882

Now the enterprise can reconstruct the decision.

This matters enormously for:

• audits;
• disputes;
• regulated decisions;
• debugging agents;
• customer support;
• compliance;
• evaluation;
• root-cause analysis.

---

5.32 Event vs Evidence

Do not confuse them.

An event says:

ReplacementApproved

Evidence explains:

Why?
By whom?
Based on what?
Under which rule?
Using which data?
With what confidence?
What subsequently happened?

You may model:

Operational Event
      │
      ├── CAUSED_BY
      ├── AUTHORIZED_BY
      ├── SUPPORTED_BY
      ├── PRODUCED
      └── AFFECTED

This is extremely graph-friendly.

---

5.33 Evidence Should Ideally Be Append-Oriented

For important decision records, you usually do not want:

UPDATE decision SET reason = ...

and lose what originally happened.

Prefer immutable or append-oriented records:

DecisionCreated
EvidenceAttached
DecisionApproved
DecisionReversed

giving:

T1 → request
T2 → evidence gathered
T3 → policy evaluated
T4 → decision made
T5 → human override
T6 → final action

That supports replay and audit.

---

5.34 Putting the Entire Architecture Together

Consider this real-world question:

"Can Acme add another 50 users without paying more?"

The raw enterprise environment might contain:

Salesforce
SAP
Stripe/billing
Contract PDFs
Product catalogue
Usage telemetry
Support notes

#### Step 1: ingestion

Salesforce ── API
SAP ───────── CDC
Contracts ─── document ingestion
Usage ─────── events

#### Step 2: normalization

ACME LTD
Acme Limited
Customer 0192
Account 772
        ↓
Customer:4873

#### Step 3: semantic model

Customer:4873
  ↓ HAS_SUBSCRIPTION
Subscription:938

#### Step 4: entity linking

Contract text:

"Customer shall be entitled to 500 active users..."

linked to:

Customer:4873
Product:EnterpriseAnalytics

#### Step 5: entitlement extraction

Entitlement:
    capability = ActiveUsers
    quantity = 500
    valid_to = 2027-03-31

#### Step 6: operational state

Usage:

active_users = 427

#### Step 7: policy

requested increase = 50
427 + 50 = 477
477 <= entitlement 500

#### Step 8: answer

Agent:

"Yes. Acme currently has 427 active users against a contractual entitlement of 500, leaving capacity for 73 additional users."

#### Step 9: evidence

Response carries:

Contract C74 clause 11
Subscription S938
Usage snapshot U9821
Policy version P12

This is what an enterprise knowledge architecture looks like when carried all the way through.

It isn't just RAG.

---

5.35 Four Different "Truths" You Must Keep Separate

This is a useful concept.

Enterprise systems frequently have:

#### 1. Source truth

What Salesforce says

#### 2. Mastered truth

Our enterprise resolution of the customer entity

#### 3. Contractual truth

What the signed agreement legally grants

#### 4. Operational truth

What is actually happening right now

Example:

CRM:
Premium customer
Contract:
Standard support
Billing:
Premium support charged
Operational support system:
Premium queue enabled

Which is correct?

Potentially all four accurately describe different aspects of reality.

The architecture must preserve this nuance instead of flattening everything into:

support_level = PREMIUM

This is why provenance and evidence matter.

---

5.36 A Strong Enterprise Knowledge Object

A powerful abstraction to have in your head is:

FACT / CLAIM
-----------
subject
predicate
object/value
valid_from
valid_to
source
evidence
authority
confidence
tenant
ACL
created_at
observed_at
status

Example:

subject:
    Acme
predicate:
    HAS_SUPPORT_LEVEL
value:
    PREMIUM
source:
    Contract 784
evidence:
    Clause 12.4
valid_from:
    2026-01-01
valid_to:
    2026-12-31
authority:
    CONTRACTUAL
confidence:
    1.0

Now enterprise AI can reason over facts instead of blobs of text.

---

5.37 Important Architectural Trade-offs

Relational vs Graph

Use relational systems where:

• transactions dominate;
• schema is predictable;
• aggregate queries dominate.

Use graphs where:

• relationships dominate;
• multi-hop questions matter;
• schemas are heterogeneous/evolving.

Often you need both.

---

Graph vs Vector

Vector:
similarity
Graph:
relationship

Use both when enterprise questions need both.

---

Central canonical model vs source-specific models

Too little canonicalization:

integration chaos

Too much:

enterprise mega-model that nobody can change

Aim for:

stable shared concepts
+
domain extensions
+
source adapters

---

Authoritative facts vs inferred knowledge

Never silently promote:

LLM extraction

into:

authoritative enterprise fact

Track:

extracted
inferred
verified
authoritative
disputed
superseded

---

5.38 Interview Traps

#### "Would you put all enterprise data into a knowledge graph?"

No.

The graph should represent entities and relationships for which graph semantics provide value. Large transactional datasets may remain in relational, lakehouse or analytical systems and be referenced from the graph.

---

#### "Does RAG remove the need for MDM?"

No.

RAG can retrieve:

Acme Ltd
ACME Limited
Acme Holdings

but it does not reliably determine whether these are the same enterprise entity.

Entity resolution and MDM remain fundamental.

---

#### "Does a knowledge graph replace a vector database?"

No.

Graphs answer relationship questions.

Vectors answer semantic similarity questions.

Enterprise retrieval often benefits from both.

---

#### "Why can't the LLM perform semantic normalization dynamically?"

Because downstream systems need stable and reproducible semantics.

An LLM may assist mapping:

cust
client
account

to Customer, but authoritative mappings need governed semantics.

---

#### "Why is provenance important if the answer is correct?"

Because enterprise systems must frequently answer:

How do you know?
Which source said that?
Was that source authorized?
Was it valid at the time?
Which evidence led to this decision?

Correctness without traceability is insufficient for many enterprise systems.

---

5.39 What You Should Know Cold

Be able to explain these distinctions instantly:

Concept	Core question
Normalization	Is the representation consistent?
Semantic normalization	Do different representations mean the same thing?
Canonical model	What shared representation do we use?
Taxonomy	How do we classify things?
Ontology	What do things mean and how are they related?
Entity resolution	Are these records the same real-world entity?
Entity linking	Which known entity does this mention refer to?
MDM	What governed representation of the entity should the enterprise use?
Knowledge graph	How are entities and facts related?
Vector search	What content is semantically similar?
Lineage	How did this data arrive here?
Provenance	Where did this fact originate and with what authority?
Evidence	What supports this claim or decision?
Confidence	How certain are we and about what?
Entitlement	What is this party allowed to receive/use/do?
Policy	Under what rules may an action occur?
Operational evidence	What happened and why?

---

5.40 The Architect-Level Answer

If someone asks:

"How would you build the data foundation for an enterprise AI platform?"

A strong response is roughly:

I would not start with embeddings. I would start by defining the enterprise entities and decisions the AI needs to understand. I would ingest structured, semi-structured and unstructured sources while retaining raw data, source identity, timestamps, ACLs and provenance.

>

I would then separate syntactic normalization from semantic normalization. Important cross-system concepts such as customer, product, contract and asset would map into a canonical model, with entity resolution or MDM where several systems refer to the same real-world entity.

>

Documents would remain evidence rather than being flattened into facts. I would extract and link entities, facts and relationships into the knowledge layer while retaining the source document, clause or record that supports each claim.

>

Retrieval would then use the appropriate mechanism: SQL for structured facts, vector retrieval for semantic content, graph traversal for relationships, and hybrid graph/vector retrieval for multi-hop knowledge questions.

>

Above that I would model provenance, confidence, validity, data quality, access controls and source authority so agents can distinguish a signed contract from an informal CRM note.

>

For operational agents, I would additionally model entitlements and policies explicitly, put deterministic controls around actions, and record the evidence and policy basis for each material decision.

That answer demonstrates considerably more architecture maturity than:

"We'll put the documents into a vector database and use RAG."

---

5.41 The Compressed Mental Model

I would reduce this entire section to this chain:

                    ENTERPRISE REALITY
Systems ───────────────────── Documents
   │                              │
   ▼                              ▼
Structured facts            Unstructured evidence
   │                              │
   └─────────────┬────────────────┘
                 ▼
          ENTITY RESOLUTION
                 │
                 ▼
         COMMERCIAL KNOWLEDGE
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
    Entities   Relations  Evidence
       │         │         │
       └────┬────┴────┬────┘
            ▼         ▼
      Entitlements   Policies
            │         │
            └────┬────┘
                 ▼
             DECISION
                 │
          deterministic gate
                 │
                 ▼
              ACTION
                 │
                 ▼
        OPERATIONAL EVIDENCE

And the key proposition becomes:

The agent should not have to reconstruct the enterprise from raw APIs every time it receives a task. The data foundation should already know the enterprise's entities, relationships, entitlements, policies and evidence. The agent reasons over that governed knowledge and operates inside deterministic controls.

That is the important connection between enterprise data architecture and agent architecture.

---

5.42 Exit-Test Questions

You should be able to answer these without preparation:

• What is the difference between data normalization and semantic normalization?
• Why would an enterprise need a canonical data model?
• What problems can an enterprise canonical model create if taken too far?
• Explain ontology vs taxonomy vs schema.
• What is entity resolution?
• How would you resolve customer identities across CRM, ERP and billing?
• What is a golden record, and does it have to exist physically in one database?
• Explain survivorship in MDM.
• What is the difference between entity resolution and entity linking?
• Why would you use a knowledge graph?
• When would you not use a knowledge graph?
• Why doesn't a vector database replace a graph?
• Give an example where graph + vector retrieval is better than either alone.
• What is GraphRAG?
• When is GraphRAG unnecessary?
• What is the difference between lineage and provenance?
• How would you preserve provenance through an AI pipeline?
• What does "confidence" mean for an extracted enterprise fact?
• How would you model conflicting evidence?
• What controls prevent an AI-extracted fact from becoming authoritative accidentally?
• What data-quality dimensions matter for an AI system?
• How would you evolve a canonical schema without breaking consumers?
• How would you design core enterprise models with domain-specific extensions?
• What belongs in a commercial data foundation?
• What is an entitlement?
• How is an entitlement different from an RBAC permission?
• How would you model policy so agents cannot simply interpret the policy however they want?
• What is operational evidence?
• Why isn't ordinary logging enough for an enterprise AI decision?
• How would you reconstruct exactly why an agent performed a consequential action six months later?
• If CRM, ERP and a signed contract disagree, which one is the truth?
• How do you prevent restricted source information from leaking through derived graph facts?
• Where should probabilistic AI stop and deterministic controls begin?
• How would you model the statement "Acme can use 500 seats until March 2027 because Contract X grants that entitlement"?
• Design the data flow from a contract PDF arriving in SharePoint to an agent safely enforcing one of its commercial terms.

For this section, questions 31–35 are the architect-level ones. If you can answer those cleanly, you aren't merely remembering definitions; you're demonstrating that you understand how the pieces form an enterprise knowledge system.

---

Related reading

• Data Readiness for Enterprise AI: What Ready Actually Means, the executive-facing version of this readiness problem.
• RAG in Production: What Breaks at Enterprise Scale, what happens downstream when this foundation is missing.
• Database Ownership in Microservices, who owns a fact when several services believe they do.