# Maplith for product and catalogue teams

How the AI agent a catalogue team already uses sees why returns climb on a product, and where the same product goes by two codes or two prices — shown on fictional companies’ exports.

The catalogue is the fact every other system borrows: the shop sells from it, the ads point at it, the helpdesk answers from it. When it is incomplete or duplicated, the cost turns up somewhere else — as a return, a wrong price, a join that misses. Your agent can trace it back — if it knows where each fact lives and how the systems join. Maplith gives it exactly that.

Acme Commerce is a fictional web shop built for our demo: the company, its people, its customers, the device brands, the suppliers and the competing chains are all invented, and nothing in the data comes from any customer.

Fjeldrev Outdoor ApS is a fictional web shop built as a test company: the company, its people and its customers are all invented, and nothing in the data comes from any customer.

## Between the systems

Recurring problems between the catalogue and the systems that borrow from it.

- **Products nobody can tell the fit of.** In the worked example three active products have an empty compatibility field, and the refunds on them lean to “does not fit”: the reason sits in the catalogue, the refunds in the shop and the questions in the helpdesk. (Acme Commerce · in its exported data.)
- **The same product under two codes.** In the worked example seven products were re-listed in the shop under new codes while the catalogue kept the old ones, so a join from sales to the catalogue misses exactly those. (Acme Commerce · in its exported data.)
- **One item, two prices.** In the worked example a re-import duplicated two products, each copy under the same code at a different price, and both copies were selling. A scan of the exports raised it as a finding, with the order lines on each copy. (Fjeldrev Outdoor ApS · raised by a scan of its exports.)

## Workflows

The workflow below is told in full on the e-commerce page, where its worked example lives. Everything in it ships today.

### Returns that do not fit

Refunds on a few products lean to “does not fit”, and the reason sits in another system.

**Without Maplith.** Refunds sit in the shop with a reason, fit questions sit in the helpdesk, and which device a product fits sits in the catalogue. In the worked example three active catalogue products have an empty compatibility field; forty-four helpdesk conversations tagged does-it-fit name one of them, and their refunds lean heavily to “does not fit” where the shop’s refunds are otherwise spread evenly across reasons. No single system shows that, and an agent reading them one by one has to guess how they join.

**With Maplith:**

1. **Your rules** — A rule the shop writes: **refunds over the last seven days above a number it chooses — per product.**
2. **Signals** — When a product crosses it, a `rule_fired` signal names the product and the count.
3. **Ask** — `ask`: “why could returns be rising on this product, and what does the map know about it?” The answer cites the objects and joins it rests on with their measured rates, any open finding on the product, and what the map could not establish.
4. **The map** — The map shows where the product’s compatibility lives and how the catalogue joins the shop — and where two systems spell the same product differently, the join says how many rows do not match rather than guessing.
5. **The action gate** — `request_action` for an operation the shop declared — for example, opening a task for the catalogue owner — decided by the key’s policy.
6. **Record and value** — `record_action` writes what was done, so the next firing’s context shows it.

Worked example: [Acme Commerce](/industries#acme) — told in full on [Maplith for e-commerce](/industries/e-commerce#returns-climb).

## The pieces

| Piece | Tool | What it gives the agent | Status |
|---|---|---|---|
| The map | `get_object` | Where each thing lives and how the systems join, with the rate Maplith measured for every join it could test. | live |
| Your rules | — | Conditions the business writes from the map’s own names, judged for each product, order or other group it chooses. | live |
| Signals | `list_signals` | What needs doing, as typed events to poll instead of re-reading the map. | live |
| Ask | `ask` | One question in plain language, answered from the map with citations — never from rows. | live |
| The action gate | `request_action` | Allowed, pending a person, or denied — before the agent acts, with a grant good once. | live |
| Record and value | `record_action` | What was done, so the next judging does not raise it as though nobody had looked — and counted in “What you got”. | live |

## The worked examples

- **[Acme Commerce](/industries#acme)**, a web shop selling phone and tablet accessories. Its situations are in twelve months of exported data, checked against the files by a script with no model involved. These pages say what is in the data, and publish no score for what a scan of it finds. [Maplith for e-commerce](/industries/e-commerce).
- **[Fjeldrev Outdoor ApS](/industries#fjeldrev)**, a web shop selling outdoor gear. The findings quoted from it come from a recorded scan of its exports. There is no public map or key for it.

Every department: [Solutions](/solutions). The worked examples: [Worked examples](/industries).