Gates

A gate is a check every record passes through on its way into a list. It can tidy a record, hold it back, or refuse it outright — and it does all of that before the record is indexed, so the thing you did not want never becomes searchable in the first place.

The alternative is what most catalogues do instead: let everything in, then find the problems later. A swear word in a description, a price of −1, a product with no name — each one is discovered by a customer, not by you. A gate moves that check to the door.

Gates belong to your account, but they run on a list. You write the rule once and switch it on for whichever lists should enforce it, from that list’s own Gates page (opened from the shield icon in the list header).

What a gate can do

Every gate reaches one of five conclusions about each record:

Admit — nothing to do; the record goes in as it arrived.
Tidy — a value is rewritten, and the record goes in cleaned up.
Hold back — the record goes in but is hidden from search until you release it.
Refuse — the record is not added at all, and the reason comes back to whoever sent it.
Score — a new value is worked out and stored on the record.

Hold back is worth understanding properly. The record is stored and indexed but marked inactive, so nobody searching your list will see it. It is not lost, and no data is thrown away — it is waiting for you.

The kinds of gate

Tidying is the cleaning that runs on every import: value normalisation, tag-noise stripping, de-duplication and category mapping. These come with your account and are on by default on every list — you do not have to add them. You can turn one off for a list, but you cannot edit, delete or reorder them: the order is fixed because they depend on it, with values normalised before de-duplication runs, or two spellings of the same product stop looking like duplicates.

Filling gaps reads each record’s copy and fills in facets it can infer — vegan, gluten-free, and a category for anything the built-in dictionary missed. It calls a model, so it needs a credential — one of your saved provider keys — and does nothing without one. The credential is set per list: pick it when you add the gate to a list, or later from the gate’s ⋮ menu, then Set credential / Change credential — the same gate can run on two lists on two different keys. If a list already has a cleaning credential, the gap-filler falls back to it until you give it one of its own.

Rules are checks you write yourself, in plain conditions — no AI, no credential, no per-record cost. Each rule says where to look, what to look for, and what to do about it. The conditions are Contains any (the text contains one of your listed words), Equals any, Matches (a pattern you supply), Missing (absent, empty or only spaces) and Out of range (outside the bounds you set — or not a number at all). The actions are Refuse, Hold back, Blank out (the matched text becomes asterisks and the record is kept) and Set.

Set Field to * to check every text field on the record. That is what you want for something like profanity, where the point is that it cannot slip in through a field you forgot to list. Word matching is on whole words, so a rule banning a short word will not reject a record because a longer, innocent word happens to contain it.

Judge gates read each record and decide whether it meets a standard you describe in your own words — “a real product with a description that says what it actually is”, “a review that describes a genuine experience”. They need a credential, because they call a model for every record. You write the standard; there is no rubric to author, no schema to design and no prompt to write.

A record that fails can be held back (the default), refused, or scored but kept when you only want the number. Held back is the default on purpose: a judge is a matter of opinion in a way a word list is not, so a borderline record should come back to be looked at rather than vanish.

Set an output field and every judged record also gets a score from 0 to 100 plus a one-line reason, as ordinary fields you can filter and sort on. A record with nothing to judge — an empty description, placeholder text — is marked unscoreable and left unscored rather than scored zero, so records that said nothing at all do not drag your averages down.

A model having a bad minute never loses a record: a provider failure on one record admits it unjudged and the next import picks it up, and a wrong credential skips the whole gate rather than holding back everything.

The order gates run in

Records meet gates top to bottom: tidying first in its own fixed order, then rules, then the kinds that cost money — filling gaps and judges. You choose the order within your own rules, but you cannot interleave the groups.

That is deliberate. The paid kinds must never run on a record that de-duplication or a rule was about to remove. Fixing the order is what stops a gate you added from quietly raising your bill.

Which records are gated

Gates run on every route into a list: records created one at a time through the API, MCP or the console; bulk creates; file uploads; imports from a media store; feed syncs; and records edited in place — an edit is checked just like a create.

On an edit, a gate does everything it does on the way in: refuse the change (the record keeps the values it had), hold the record back, or rewrite a field — a redaction or tidying rule applies to an edit just as it does to a new record.

Changing a gate is never retroactive. Records already in the list are untouched when you add, edit or delete a gate — a new rule does not remove anything already there, and a deleted gate does not restore anything.

Choosing when a gate runs

By default a gate runs on both new records and edits. You can narrow that per list — a cheap profanity rule on every edit, an expensive judge only on the way in — with the When should it run? checkboxes as you Add a gate, or later from the gate’s ⋮ menu → When it runs…. Turning both off leaves the gate on the list but stops it running, the same as Turn off.

When a record is refused

What you see depends on how the record arrived. Creating one record returns a failure carrying the gate’s own reason, so an API caller or agent is told exactly what to change:

{
  "title": "SearchResults",
  "detail": "This record contains strong language, so it was not added.",
  "status": 400
}

Importing many does not fail the whole import. The records that passed are added, and the ones that were refused are reported with their reasons, alongside the de-duplication and normalisation counts for the same run.

Create a gate

Gates live on your account, so you create them once in Gates in the sidebar — not on a list.

Open Gates in the sidebar and choose Create gate.
Give it a Name — letters, digits and hyphens.
Choose What should it do?, then fill in the words, field, or standard it should check.

A new gate does nothing until you add it to a list (below). It has no credential yet — that is a per-list choice, made when you add it.

Add a gate to a list

Open the list’s Gates page (the shield icon in the list header) and choose Add a gate. Pick the gate from the dropdown; if it is a model gate (Filling gaps or Judge), choose the credential that pays for it on this list — you cannot add one without a credential. The gate definition is shared, so editing it changes every list using it, but the credential and the fields it reads are per list.

Turn a gate off

From the gate’s ⋮ menu on a list’s Gates page:

Turn off leaves the gate on the list but stops it running. Its position shows as — while it is off.
Remove from this list unbinds it entirely and returns it to the list’s Add a gate menu. Other lists are unaffected. Offered for built-ins too — a removed built-in is not silently re-added. Use Turn off instead if you only want it to stop running while it stays on the list.
Delete gate removes it from your account and from every list using it. Built-in gates cannot be deleted.

Notes

A gate that cannot run — a rule that no longer parses, say — is skipped and logged rather than failing the import. A broken check must never become an outage.
Editing a gate advances its version. Lists stay pinned to the version they were attached at until you re-attach.
Gates never see more than the batch in front of them, so a rule cannot compare a record against the rest of your list.