Enterprise Semantic Layer

The situation

The company had a large Snowflake estate, dozens of operational systems, and a mandate to put AI in front of business users. Every team defined headcount, backlog, and project margin a little differently. An agent asked a simple question would get a confident answer built on the wrong table.

Nobody owned the layer between raw data and the questions people actually ask. That was the job.

What I built

I started with an inventory: 70+ databases, which ones mattered, who owned them, and where the same concept lived twice. From that I designed a mirror architecture that lands 60+ source tables into a governed layer with consistent keys, then models facts, dimensions, and metrics on top.

The semantic views are the product. Fifteen of them, three in production, eight for business domains, four standalone, covering HR, recruiting, workforce planning, project quality, and preconstruction. Each metric has a definition, an owner, and a query path an auditor can follow. Cortex Agents read the views directly, so 1,000+ fields are available to AI without anyone writing SQL.

Alongside the modeling I built the decision-support patterns that sit on top: workflow cycle times, quality signals, and staffing pressure expressed as governed KPIs with human review designed in.

The outcome

Agents stopped guessing. Questions about capacity, pipeline, and quality return the same number the finance team reports, with the logic visible. The architecture decisions I framed at the leadership level became the governance framework the program runs on, and that framework is what unblocked production rollout.

Why it matters

Enterprise AI programs stall on data, rarely on models. A semantic layer is the unglamorous piece that makes every downstream agent, dashboard, and self-service tool trustworthy. Build it once, govern it well, and the rest of the stack moves fast.

Stack