DEV Community: Yogendra Sharma

Stop Semantic Decay: Why AI Needs an Autonomous Compiler

Yogendra Sharma — Tue, 01 Sep 2026 15:39:35 +0000

Most data systems don't break. They slowly forget.

A definition shifts. A metric gets reused in a new context. An assumption outlives the reason for it. Nothing crashes.

Why this isn't a data quality problem

Data quality tooling checks whether values are within expected bounds. Drift is different — the values are fine. The meaning moved.

Event	Data quality check	Reality
`revenue` now excludes intercompany	Passes	Every trend line has a discontinuity
Churn window changed 30→60 days	Passes	Two teams' numbers stop agreeing
Table repurposed after migration	Passes	Old dashboards read it as if unchanged
New segment definition	Passes	Historical comparisons are meaningless

Every one of those passes every test you have. Dashboards still load. Confidence quietly erodes until someone finally says "I don't trust this number" in a meeting, and nobody can trace when it stopped being true.

Drift is technical debt with no ticket

That's what makes it insidious. Code debt is visible — you can see the TODO, the failing test, the module nobody will touch. Semantic debt has no artefact. It accumulates in the gap between what a definition says and how it's actually used.

What catches it

A behaviour layer — statistical profiles of how concepts are actually queried
Comparison of declared definition against observed usage
Alerting on divergence, not on value ranges
Versioning, so the moment of change is recoverable
Autonomous rebuild, so the fix isn't a quarterly review

The mechanism matters: you detect drift by noticing that usage stopped matching declaration. That signal exists in your query logs already. Almost nobody reads it.

The full breakdown — how drift accumulates, the detection mechanism, and why autonomous maintenance is the only sustainable answer — is here:

👉 Stop Semantic Decay: Why AI Needs an Autonomous Compiler

Originally published at colrows.com/blogs/knowledge-drift-and-semantic-decay

Multi-Tenant Semantic Isolation: Enforcing Tenant Boundaries at Compile Time

Yogendra Sharma — Thu, 27 Aug 2026 15:02:02 +0000

We've been building multi-tenant AI systems and hit a wall most platforms quietly ignore.

Data can be isolated. Meaning cannot — not by the usual mechanisms.

The problem in one sentence

Two tenants define revenue differently. Both are correct. Your semantic layer has to be right twice, simultaneously, without either tenant's definition leaking into the other's answers.

Row-level security doesn't help here. It isolates rows. This is a collision in the definition layer, above the data.

Where naive designs break

Approach	Failure
One shared graph, tenant filter	Tenant A's definition resolves for Tenant B
One graph per tenant	Maintenance cost multiplies by tenant count
Namespace prefixes	Shared concepts get duplicated and drift
Isolation at the API layer	Resolution already happened underneath

Multi-scope resolution

The workable answer is to make scope a first-class dimension of the graph itself: global → datastore → persona → user.

A concept resolves by walking that chain and taking the most specific definition available. Revenue might be defined globally, overridden for a datastore, refined for a persona. Tenant boundaries become a scope level rather than a deployment decision.

Two properties fall out of that:

Compile-time enforcement — an unauthorised cross-tenant resolution fails to compile rather than returning filtered rows
Shared maintenance — a global improvement propagates to every tenant that hasn't overridden it, so you're not maintaining N graphs

Why this matters beyond SaaS

Any organisation with distinct legal entities, regional definitions, or acquired subsidiaries has the same problem internally. "One version of the truth" is usually wrong — you need one version per scope, resolved deterministically, with the boundaries provable.

The full breakdown — the scope resolution model, the compile-time isolation guarantees, and the tenancy architecture — is here:

👉 Multi-Tenant Semantic Isolation: Enforcing Tenant Boundaries at Compile Time

Originally published at colrows.com/blogs/multi-tenant-semantic-isolation

The Enterprise Memory Graph: Why AI-Native Companies Need a Memory They Can Trust

Yogendra Sharma — Thu, 20 Aug 2026 17:12:52 +0000

Every AI vendor is selling memory this year.

Almost none of it can tell you what "active customer" meant last quarter.

Two different problems wearing the same word

Conversational memory stores what was said. Enterprise memory has to store what was true — and when it stopped being true.

	Conversational memory	Enterprise memory graph
Unit	Message, summary, embedding	Typed entity, metric, relationship
Question answered	"What did we discuss?"	"What was true, when, for whom?"
Consistency	Best-effort	Versioned and reproducible
Governance	Usually none	Policy attached to the concept
Failure mode	Forgets	Silently disagrees with itself

That last row is the dangerous one. A system that forgets is annoying. A system that quietly returns numbers computed under two different definitions is a trust problem you find out about in a board meeting.

The failure nobody instruments

A definition changes in April. Nothing breaks. Dashboards still load, queries still return. But every answer produced after that date quietly disagrees with every answer before it, and no one can say which was right.

There's no exception, no alert, no failed test. Just an accumulating divergence.

What makes it a memory rather than a cache

Typed entities and relationships, so structure is explicit rather than inferred
Versioned, so a historical answer can be rebuilt exactly
Point-in-time reproducible — the property that turns memory into evidence
Drift-detecting, so a stale definition is surfaced rather than discovered
Governed, so entitlement travels with meaning

If you can't reconstruct what a metric meant on a specific date, you don't have memory. You have a cache with good marketing.

The full breakdown — the graph architecture, versioning model, and how point-in-time reproduction works — is here:

👉 The Enterprise Memory Graph: Why AI-Native Companies Need a Memory They Can Trust

Originally published at colrows.com/blogs/enterprise-memory-graph

The Decline of Metadata Tools: Why You Need a Semantic Compiler

Yogendra Sharma — Tue, 18 Aug 2026 15:02:01 +0000

The metadata catalog category consolidated in 2025 and almost nobody wrote the post-mortem.

It wasn't a product failure. The ROI case never closed.

The original promise, and why it was reasonable

Document the estate, and analysts stop wasting weeks finding data. Lineage for impact analysis, ownership for accountability, classification for compliance. Alation, Collibra and Atlan are genuinely good at all of that.

Why the payback didn't arrive

Problem	Consequence
Value tracks description freshness	Freshness requires manual work with no owner
Coverage decays quietly	Nobody notices until trust is gone
Describes, doesn't enforce	A documented rule isn't a control
Human-shaped output	Fine for someone who can ask a colleague

A catalog's usefulness is a function of how current it is. Keeping it current is unglamorous, unassigned work — so coverage decays, trust follows, and the renewal conversation gets difficult.

What actually broke the model

Not a competitor. LLMs made "query the data" everyone's job overnight.

A description adequate for a human who could ask a colleague for clarification is nowhere near adequate for an agent that won't. Ask a catalog what net revenue is and you get prose someone typed in 2023. Ask whether this agent may query it and it has no opinion at all.

Where the spend is going

To layers that enforce rather than describe: definitions typed and executable, relationships proven rather than annotated, policy that runs rather than policy that's documented, and drift detected automatically because nobody updates a wiki.

The catalog told you what you have. The semantic layer decides what happens next.

The full breakdown — the consolidation history, why the ROI never closed, and what replaces the category — is here:

👉 The Decline of Metadata Tools: Why You Need a Semantic Compiler

Originally published at colrows.com/blogs/decline-of-metadata-tools

Data Products Are Dead: The Era of Semantic Products

Yogendra Sharma — Thu, 13 Aug 2026 17:58:14 +0000

Data products solved ownership. They solved pipelines. They never solved meaning.

In a world where humans, dashboards, copilots and agents all query at once, a static data product collapses.

What data products got right

Clear ownership, defined contracts, discoverability, SLAs. Those were real advances over an undifferentiated lake, and the operating model they introduced was correct.

Where they stop

Assumption	Why it breaks
Consumers are known in advance	Agents ask unanticipated questions
A contract is a schema	A schema says nothing about what a field means
Definitions live in documentation	Documentation decays silently
One product per domain	Real questions cross domains
Governance is upstream	Agents reach the data through new doors

The second row is the crux. A data contract will guarantee the revenue column exists, is a decimal, and arrives by 06:00. It guarantees nothing about whether it includes intercompany, at what recognition point, in which currency.

What replaces them

A semantic product: the same ownership discipline, but the unit is a governed concept rather than a dataset.

Typed and versioned, so active customer has one definition with a history
Relationships proven, not documented — join paths are part of the product
Policy attached to the concept, travelling into every query
Self-maintaining, with drift detection instead of a quarterly review
Consumable by humans and agents through the same compiled path

Data products made data available. Semantic products make it usable by machines that can't ask a colleague for clarification — which is now most of your query volume.

The full breakdown — the semantic product model, how it composes with mesh thinking, and the migration path — is here:

👉 Data Products Are Dead: The Era of Semantic Products

Originally published at colrows.com/blogs/data-products-are-dead-long-live-semantic-products

Multi-Hop Query Understanding: The Deterministic Compiler Approach

Yogendra Sharma — Thu, 06 Aug 2026 13:43:21 +0000

The hardest business questions aren't about metrics. They're about relationships.

If your BI tool can't explain why something happened, it isn't intelligence — it's reporting.

What multi-hop actually means

"Why did EMEA churn spike after the March pricing change?"

That's not one lookup. It's a traversal: pricing change → affected accounts → support ticket volume → response latency → churn events, each hop joined on a different key, several crossing system boundaries.

Single-hop tools answer what. Multi-hop is required for why, and almost every analytics stack is single-hop underneath.

Why LLMs alone don't close it

Hop count	What the model must get right
1	One table, one filter
2	One join — usually inferable
3+	Join order, cardinality, grain, and which of several paths is correct

Errors compound. A 90% chance of a correct hop is a 73% chance of a correct three-hop answer, and the output looks identical either way. There's no error bar on a confident paragraph.

The compiler approach

Treat the question as something to be compiled, not generated:

Parse intent into a typed representation
Resolve each concept against the versioned semantic graph
Enumerate candidate paths, then prove one — cardinality-aware, or fail
Inject policy predicates for the caller
Emit dialect-perfect SQL

Step 3 is where multi-hop is won or lost. A generator picks a plausible path. A compiler proves the path exists and is unique for the requested grain, and refuses when it isn't.

That refusal is the feature. An honest "this question is ambiguous — did you mean recognised or booked revenue?" is worth more than a confident wrong causal story.

The full breakdown — the traversal architecture, cardinality handling, and worked multi-hop examples — is here:

👉 Multi-Hop Query Understanding: The Deterministic Compiler Approach

Originally published at colrows.com/blogs/multi-hop-query-understanding-the-new-frontier-of-bi

Fine-Grained Data Access Control: Precision & Security

Yogendra Sharma — Tue, 04 Aug 2026 14:59:57 +0000

Most enterprises secure the dashboard and leave the query wide open.

By the time your access filter fires, the data has already left the warehouse.

Why tool-level controls don't travel

Row and column rules bolted onto a BI tool protect exactly one surface. The moment an AI agent reaches the same warehouse through a different door — an MCP server, a notebook, a REST call — those rules don't come with it.

So teams do what's available: duplicate datasets per audience, maintain parallel views, and accept that the copies drift.

Attach policy to meaning, not storage

	Tool-level ACLs	Compile-time predicates
Attached to	Reports, folders, views	Entities, metrics, relationships
Travels to new consumers	No — re-implement per tool	Yes — it's part of the concept
Unauthorised request	Filtered result	Fails to compile
Rows read	Then hidden	Never read
Audit artefact	Access log	The SQL, with predicates inline

The third row is the security boundary. "Filtered afterwards" means the query ran with full privileges and something downstream decided what you were allowed to see.

What precision looks like in practice

RBAC gets you role membership. ABAC adds attributes — region, cost centre, clearance, purpose of use. Row and column predicates then narrow the actual result at compile time, per person, per question.

One governed query path serves every persona and returns a different, correct slice to each. No shadow copies to reconcile, and no separate governance implementation per tool.

That's the difference between preventing a breach and documenting one.

The full breakdown — the policy model, how RBAC and ABAC compose, and the predicate injection mechanics — is here:

👉 Fine-Grained Data Access Control: Precision & Security

Originally published at colrows.com/blogs/fine-grained-data-access-control-precision-security