# Semantic layer & context engineering | Dan Kornberg

**Every team had its own map of Wix. I built one everyone could share.**

A semantic layer that ties Wix's product names to the code, copy, data, and people behind them, so colleagues and AI agents work from the same context.

- About 1,070 code projects, 158 catalog domains, and 89 glossary domains in one map
- Validated on three domains by their owners and the data team
- Reproducible: five staged pipelines, regenerated rather than edited by hand

Role: AI Strategist, Wix. Also called "Product Knowledge & AI Context System."

## The problem

At Wix, "domain" could mean a product surface, the code a team owns, or even who reports to whom. Developers, writers, analysts, and marketing each carved up the product differently, and the same area went by different names in data tables, the CMS, GitHub, HR systems, and internal tools.

## The gap

Before agents, content changes went through the CMS, so a writer always made them. Once PMs had agents with access to the code, anyone could change content, design, even data tables, often outside their expertise. To do a task right, an agent needs to know which domain it's in: its glossary and banned terms, what users complain about, which repos to touch, and which help articles to keep in sync.

## What I did

I spotted the gap while building the glossary checker: there was no way to tell an agent "you're working on this domain, here's everything relevant." I talked to developers, data engineers, and analysts to learn which systems each team used and where they actually connect. Developers wanted the map built around their repos, analysts around their tables. I pushed for one shared map.

## The anchor

The glossary was the cleanest system Wix had: terminology first, with official names that matched the product. From each glossary domain I found the repos, then the code owners, then the data tables. The first version used the official data catalog as the spine instead. That broke for about 70% of user-facing domains, because the catalog lists the data team as the owner, not the team that owns the UI. So I flipped it: the CMS, where Wix's product strings live, became the spine for code and copy, and the catalog the spine for naming.

> "The glossary, like the US dollar being kind of the currency that everything else is pegged to."

## How it works

1. Start from a glossary domain: its official terms are the anchor.
2. Seed discovery from the CMS: find the code packages that hold the domain's strings.
3. Subagents sort each candidate package into include, related, or drop, and pull out the product flows. Everything is combined into one map per domain.
4. A second pass starts from the confirmed packages, finds nearby projects that keyword or semantic search would miss, and suggests glossary gaps. Suggestions never overwrite the map.
5. An alignment step records typed relationships between domains: parent, child, sibling, depends-on, integrates-with. Together they work as a knowledge graph.
6. Each domain map is published to a page employees can search and check.

Five staged pipelines, each a Cursor skill plus a Python script. They cache their results, and a fresh run reproduces everything exactly. The map is versioned in git, regenerated and validated rather than edited by hand.

## Result

Management approved it, and it was validated on three domains, one of them Partners. Owners from those domains, plus data engineers and analysts, confirmed the maps were accurate, mapped in a way neither data nor engineering had done before. Senior data and product people were excited about it.

## What it's for

The semantic layer is the bedrock of Wix's context engineering effort: agents from different teams speak the same language and can hand work to each other. A user-facing term can be traced across data tables, internal systems, repos, the CMS, and the TMS, and I designed notifications for a domain's owners when another team's change touches their area. The point of all of it: content written automatically, at scale, and cleanly.

It all started from the glossary: [Writers Guild Glossary System](../glossary/).

## My role

- Spotted the gap while building the glossary checker
- Talked to developers, data engineers, and analysts to learn which systems each team used and where they connect
- Architected the semantic layer and its five pipelines, and ran them
- Chose the glossary as the anchor, and flipped the spine when the data catalog didn't hold
- Worked closely with the data teams, and filled the gaps between their systems
- Designed automated refreshes, validation, and owner notifications for the infra team

Tools: Python, Cursor, Codex, Claude Code, MCP, OpenMetadata, GitHub.

## Questions a hiring manager might ask

**Why anchor on the glossary?** It was the cleanest system Wix had: terminology first, with official names that matched the product. Every other system could be tied back to it.

**How did you know the maps were right?** Owners from three domains, plus data engineers and analysts, checked them and confirmed they were accurate.

**What was the hardest part?** Getting teams to share one map. Every team wanted its own system at the center. And when the data catalog didn't hold up as the spine, I had to flip the approach.

Contact: dankornberg@gmail.com · linkedin.com/in/dan-korn