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.
- 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
- Repos
- Owners
- Data tables
- CMS
- TMS
- Help articles
01 · The problem
Nobody agreed on what a “domain” was.
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.
02 · The gap
Agents needed a map, and there wasn't one.
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. And 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?
- Which help articles to keep in sync?
03 · What I did
Everyone wanted their own system at the center.
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.
04 · The anchor
I pegged everything to the glossary.
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.”
First try: the data catalog as the spine
~70% of user-facing domains got the wrong ownerThe flip: the glossary and the CMS as the spine
Owners matched the teams that own the UI05 · How it works
One domain at a time, mapped the same way every time.
For each domain, the research starts from its glossary terms, finds the code packages behind them, and has subagents sort each one into include, related, or drop. A second pass catches nearby projects that search would miss and suggests missing glossary terms, as suggestions only. Then it records how domains relate and publishes a page employees can search. Each of the five pipelines is a skill plus a Python script, and a fresh run reproduces everything exactly.
Try it: pick an example domain and map it.
-
1 anchor
Start from the domain's glossary terms
-
2 discover
Find the code packages behind them
-
3 sort
Subagents sort each package
-
4 second pass
Catch what search missed; suggest only
-
5 publish
One searchable page per domain
Example domains, packages, owners, and tables, not Wix's real map.
06 · Result
Three domains, mapped right for the first time.
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.
- Confirmed by domain owners
- Confirmed by data engineers
- Confirmed by analysts
- Approved by management
07 · What it's for
One map, so a change in one place can be traced everywhere.
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.
- Repos
- Owner notified
- Data tables
- CMS
- TMS
- Help articles
08 · Where it started
It all started from the glossary.
The glossary gave the map its anchor: one official name for every part of the product, owned and approved by the people who know it best.
Related project
Writers Guild glossary system →
More detail
How it works, step by step
- Start from a glossary domain: its official terms are the anchor.
- Seed discovery from the CMS: find the code packages that hold the domain's strings.
- Subagents sort each candidate package into include, related, or drop, and pull out the product flows. Everything is combined into one map per domain.
- 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.
- An alignment step records typed relationships between domains: parent, child, sibling, depends-on, integrates-with. Together they work as a knowledge graph.
- 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 regenerated and validated, never edited by hand, and it's versioned in git.
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
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.