Skip to main content
The Lakehouse is a shared knowledge base that enrichment reads from when filling in your products. It holds structured product data, brand technologies, and the source documents those were extracted from. Enrichment consults the Lakehouse before scraping the open web, so data your organization has already contributed — or that is shared across organizations — can complete a product without another round trip to a brand site. The Lakehouse is a source, not a destination for your catalog: you don’t add sellable products to it directly. You contribute to it by uploading documents — or by editing the extracted records in place — and it feeds enrichment.

​
What the Lakehouse holds

​
extracted product data
Structured product records pulled from uploaded documents — names, brands, and attributes. Enrichment matches these against your catalog products to fill in missing values.
​
brand technologies
Named brand technologies and features (materials, cushioning systems, and the like), with the source document they came from. These enrich the products that reference them.
​
the source files
The uploaded files — spec sheets, catalogs, and similar — that products and technologies are extracted from. Each document keeps a link back to what was derived from it.

​
Documents and extraction

You populate the Lakehouse by uploading documents. Extraction then reads each file and proposes the products and technologies it found.
1

Upload the file

Upload one or more documents and tag them with the brand and category they describe. Each upload is tracked as a Job.
2

Spreadsheets pause for column-mapping review first

For a spreadsheet, MerchantOps reads the header row, proposes how each column maps to a known field, and shows you a preview of the first few rows — then stops and waits. No rows are extracted yet. You confirm or adjust the mapping, and extraction only starts once you do. This is a human-in-the-loop step, distinct from the automatic column mapping used when uploading products.Every spreadsheet pauses here by default. Ticking Auto-process column mapping on the upload lets a high-confidence mapping run straight through; a low-confidence or invalid one still pauses.
3

Extraction runs in the background

With the mapping settled, MerchantOps reads the file and extracts candidate products and technologies, each with a confidence score, tracked as a Job.
4

A product PDF pauses for extraction review

Before anything from a product PDF is written, MerchantOps applies your organization’s ingestion settings. Unless they say otherwise, a document that doesn’t clear the confidence bar stops and waits for a reviewer to approve it — and the default setting stops a great many product PDFs here. The document’s Job sits at Awaiting review until someone resolves it.On the document’s extraction review page you compare each extracted draft against the page it came from, keep or drop it, correct its values, and then either Approve & Commit or reject the document. Only what you approve is written.Approving hands the document off to be written in the background rather than writing it immediately: it reads as approved and committing, and the Job stays open, until that finishes. See After you approve.
5

Extracted data enters the Lakehouse

The approved products and technologies become available to enrichment. A record arrives flagged Needs Review when its extraction confidence is low, or when it carries properties MerchantOps couldn’t match to a known field.
The two pauses are different in kind, and it matters which one you’re looking at. The column-mapping review (spreadsheets) is a gate in front of extraction: nothing has been written or even extracted yet, so adjusting a mapping corrects the instructions rather than undoing a result. The extraction review (product PDFs) is the opposite — an acceptance step after extraction, where you approve or reject a result that already exists but has not been committed.
Uploading documents isn’t the only way to curate the Lakehouse. Lakehouse product records can be edited directly in the product detail view: adjust their properties and technologies, set identifiers such as the vendor ID or catalog key, and attach a catalog link. These actions curate Lakehouse records — the source data enrichment reads from — not the catalog products enrichment fills in.

​
Finding a Lakehouse product

The Lakehouse products list searches on the identifiers you actually work with. One search box covers the product name, its key, the vendor style ID, the vendor style-color ID, and any identifier value on the record — a barcode, a catalog number, a second vendor code. Every one is a case-insensitive partial match, so a fragment is enough. Punctuation and symbols between words are ignored, so you don’t have to reproduce the trademark signs and hyphens a vendor spelled a name with: Typing the symbol yourself still works — nitro™ elite finds the same row — and so does any other separator in its place. Because a record’s key is searched too, a phrase can reach a row through the hyphens in its key even where the displayed name is spelled differently.
Three things the search deliberately does not do:
  • Word order matters. elite nitro does not find DEVIATE NITRO™ ELITE 4 HYROX.
  • A symbol inside a word still has to be typed. mens does not find Men’s, and accents are not folded — cafe does not find Café.
  • Words can’t be run together, or split apart. Which separator you use between them doesn’t matter, but the words themselves have to match: foam 1080 finds Fresh Foam 1080, while foam1080 and foam 10 80 do not.
A search that is nothing but symbols — ™ on its own — is taken literally and finds the records carrying that character.
When a row matches on something the table isn’t showing — a barcode, say — a muted line under the product name tells you which field matched and with what value, so a result never looks unexplained. Alongside the search:
  • Sortable columns on product name, brand, style ID, style-color ID and extraction confidence.
  • Column filters: brand as a searchable multi-select, and name, style ID and style-color ID as “contains” filters. The name filter ignores symbols between words exactly as the search box does; the two style ID filters match literally, punctuation included, so type those identifiers the way they are stored — or use the search box, which applies the symbol-blind rule to them as well. Where your organization has more brands than the popover lists, it says so rather than truncating silently.
  • Level stays in the header because it changes which columns render. While a search is running it automatically widens to all levels — the page tells you it is “searching all levels” — so a matching variant isn’t hidden by a level you set earlier. Choose a level explicitly during a search and that choice is respected; clear the search and your previous level comes back.
Your search and filters here are remembered between visits, like the other list pages — see Search and filters.

​
Finding a Lakehouse product from an agent

The MCP server’s search_lakehouse_products tool asks the same question two different ways, and which one you get depends on whether you supply identifiers. See MCP server for connecting one.
​
no identifiers
A search term, a brand_key, a product_level, or any combination of them. This is the paginated catalog browse — the same text matching the list above uses, so symbols between words are ignored here too.
​
with identifiers
identifiers — for example {"vendor_style_id": "1127929"} — finds the records carrying that identifier value. A search term alongside it is applied as a product name filter, not as a second identifier: both conditions have to hold.
An identifier plus a search term previously returned name matches regardless of their identifiers. The identifier half of that combination was dropped, so asking for an identifier that exists nowhere together with a name still came back with every product whose name matched — which reads as a confident answer rather than an empty one. Both halves now apply. If an agent has told you a Lakehouse record carries a particular vendor ID and you have not re-checked it since, ask again.
Two limits are worth knowing before you ask an agent to page through results:
  • An identifier lookup does not paginate. It returns up to 50 matching records in one answer and ignores any page size or offset. If a lookup comes back at 50, narrow it — add a name term — rather than asking for the next page.
  • brand_key and product_level cannot be combined with identifiers. The tool refuses that combination and says so, rather than quietly returning results with the brand or level filter ignored. Either drop the identifiers and filter by brand and level, or keep the identifiers and narrow with a name term instead.
MCP clients cache the list of tools and their descriptions. Reconnect the connector to pick up the corrected wording — an agent working from a cached description may still believe search is a plain substring match.

​
Needs Review: what “Mark reviewed” and “Reject” actually do

A record flagged Needs Review offers two actions, and they are not two flavors of “done”:
​
clears the flag
You checked the record and the data is good. The Needs Review pill goes away and the record shows as reviewed, with who reviewed it and when.
​
keeps the flag lit
You checked the record and the data is wrong. Rejecting asks for a reason, records who rejected it and why — and deliberately leaves the Needs Review pill lit. A reject means “this record is wrong, someone fix it”, not “resolved” or “hidden”.
Rejecting does not remove a record from the Needs Review queue and does not delete it. The record stays in the Lakehouse, still flagged, with your reason attached — visible on the record as “Rejected by … — reason”. Mark reviewed is the only action in the record view that clears the flag, so the usual path after a reject is: someone corrects the record, then marks it reviewed.
Documents themselves always belong to the organization that uploaded them. Whether the data extracted from them is shared more broadly is controlled by your sharing settings, below.

​
Per-org sharing

The Lakehouse can be shared across organizations, and what you share is configurable. By default, product and technology data is shared, while MAP pricing data is kept private. Changing a sharing setting affects future writes only — data already contributed keeps the sharing decision it was written with. Manage this at Lakehouse sharing settings.

How enrichment works

How enrichment consults the Lakehouse before the open web.

MAP policies

The pricing data the Lakehouse can hold, kept private by default.

Ingestion settings

Decide when an extracted PDF pauses for approval before it is written.

Sharing settings

Choose what your organization shares into the Lakehouse.

Uploading products

Adding sellable products to your catalog, as opposed to the Lakehouse.