Gates

A check every record passes on its way into a list — refuse a record with no price, blank out a swear word — run before the record is stored.

• Gates belong to your account; they run on a list.
• Written once, switched on per list from that list’s Gates page (shield icon in the list header).

What a gate can do

Every gate reaches one of five conclusions about each record:

Outcome	What happens
Admit	The record goes in as it arrived.
Tidy	A value is rewritten; the record goes in cleaned up.
Hold back	Stored and indexed, but marked inactive and hidden from search until you release it.
Refuse	Not added at all; the reason goes back to whoever sent it.
Score	A new value is worked out and stored on the record.

The kinds of gate

Tidying is the cleaning that runs on every import, on by default on every list:

• Standard dates — see below.
• Value normalisation — one spelling per value, so “UNITED KINGDOM” becomes “United Kingdom”.
• Tag-noise stripping — removes internal tags shoppers should not see.
• De-duplication — collapses repeated records into one.
• Category mapping.

You can turn one off per list; you cannot edit, delete or reorder them. Values are tidied before de-duplication, and dates standardised before anything else rewrites a value.

Standard dates stores dates written in any format — one file can carry both 2009-06-04T00:00:00 and 25-07-2007 — as one standard date, so ranges, sorting and filtering work.

• Day-first or month-first is worked out per column: a first number over 12 (25-07-2007) means day-first, a second number over 12 means month-first.
• Nothing proves it either way — the column is left exactly as it arrived. Set it yourself from the gate’s ⋮ menu, then How it reads dates….
• Year-first (2009-06-04) is always read year-first, whatever you choose.
• Date columns are found automatically — any column holding nothing but dates. One non-date value leaves the whole column alone. Name columns in the same dialog to narrow it.
• A value it cannot read is left as it arrived — never dropped, never refused.

Filling gaps fills blank facet values from what a record says about itself: a description saying “suitable for vegans” sets the vegan facet, and anything the built-in category dictionary could not place gets a category worked out for it.

• Only fills a gap — a facet value already on the record is left alone.
• Needs a credential (a saved provider key) for its AI model. With none on the gate and none on the list it never runs and never costs anything; the row says so.
• On by default, like the tidying gates.
• Credential is per list — set or change it from ⋮ → Set credential / Change credential. One gate can run on two lists on two keys.
• A list’s cleaning credential is used if it has one, until you give the gate its own.

Rules are checks you write yourself — no AI, no credential, no cost per record.

Condition	Applies when
Contains any	The text contains one of your listed words.
Equals any	The value matches one of your listed values.
Matches	The text matches a pattern you supply.
Missing	The field is absent, empty, or only spaces.
Out of range	The number is outside your range — or is not a number.

Action	Effect
Refuse	The record is not added.
Hold back	Added, but hidden from search.
Blank out	The matched text becomes asterisks; the record is kept.
Set	The field is overwritten with a value you choose.
Build	The field is built from the record’s other fields — see below.

• The first rule that applies decides; the rules below are skipped — so a Blank out above a Refuse means “clean this up rather than lose it”.
• Build is the exception: it carries on, so a record whose name had to be built still passes everything below.
• Field * checks every text field on the record.
• Matching is on whole words, so a banned short word will not reject a record for a longer, innocent word containing it.

Building a field from other fields

A record needs a name, and a row without one is skipped. A Build rule writes that field from the ones the row does have, paired with the Missing condition: when name is Missing, Build it from {sub_building_name} {building_number} {thoroughfare}, {post_town}, {postcode}.

• A blank field takes its separator with it. No sub_building_name gives 19 Fettercairn Rise, London, W1A 7AE, not , 19 Fettercairn Rise…. Any separator works, and where a blank sits between two others one survives: {a} - {b} - {c} with an empty middle gives Alpha - Charlie.
• Punctuation inside a value is never touched — Unit 3 - Kestrel Estate keeps its hyphen.
• It never overwrites a value a record already has — that comes from the Missing condition, decided per row, not per file.
• If every field it reads is blank, nothing is written and the row is still skipped, with a reason.
• Words you type are kept. Flat {flat} at {road} with no flat gives Flat at Fettercairn Rise. Only punctuation is tidied away.
• There is no if/then logic — each {field} is swapped for its value and nothing more. A pattern that changes shape per record must be built in a script first.
• Order matters. A build rule reads whatever earlier rules have written, so put it below any rule that tidies the fields it depends on.
• Do not read the name column in its own pattern. A column used as the name is moved into the name, so a gate on a list whose name comes from title cannot write {title}.

The order an import uses for the name: the Name field set on the import, then a column called name, title, label, display_name or heading, then this gate. If none answer, the row is skipped and counted.

Two ways to create one, both offering the column names as buttons (post_town or postTown):

• The account’s Gates page → Create gate → Build a missing field from other fields. Pick the field and write the pattern; the dialog previews it against real records from a list you choose, including rows it cannot build.
• Upload a file with no name column: the import’s confirm step offers to build it, creating the gate, adding it to the list and running the import in one step.

Capture media downloads the images your records point at, once, on the way in, and rewrites the field to a path in your media store, so everything afterwards — including rebuilding an image-search vector — reads a copy you own.

• Off until you switch it on. It sits on every list’s Gates page from the start, labelled Off, and is turned on from the ⋮ menu.
• Fields are optional — blank means every resource field on the list (fields carrying links, such as image URLs); the row says so while it runs.
• Anything that is not an http/https URL is left untouched; anything that is not an allowed file type is refused — images only, unless you allow video.
• The destination is the list’s media store, which every list has; the dialog names it as you add the gate. Set the folder, a size limit and the file types to accept.
• If a download fails: leave (the default), hold back or refuse.
• Running it twice is free — the stored name comes from the source URL, so a captured file is not downloaded again and a field already holding a path is left alone.
• Video is off unless you turn it on; switch it on and the size limit rises to match. Left off, video files are skipped.
• Existing records need Backfill on the list’s gates page — a gate only sees records arriving.

Judge gates decide whether each record meets a standard you describe in your own words — “a real product with a description that says what it actually is”. You write the standard and nothing else: no judge instructions, no fields, no prompt.

• Needs a credential — it calls an AI model for every record.
• A record that fails can be held back (the default), refused, or scored but kept when you only want the number.
• Set an output field and every judged record gets a score from 0 to 100 plus a one-line reason, as ordinary fields you can filter and sort on.
• Nothing to judge — an empty description, placeholder text — is marked unscoreable and left unscored rather than scored zero.
• A provider failing on one record admits it unjudged, and the next import picks it up. 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 capture media, then the kinds that cost money — filling gaps and judges. You choose the order within your own rules; you cannot mix the groups.

Which records are gated

Every route into a list: records created one at a time through the API, MCP or the console; bulk creates (many records in one API call); file uploads; imports from a media store; feed syncs; and records edited in place.

• On an edit a gate can refuse the change (the record keeps the values it had), hold the record back, or rewrite a field.
• Nothing is retrospective. Records already in the list are untouched when you add, edit or delete a gate.

Choosing when a gate runs

By default a gate runs on both new records and edits. Narrow it per list with the When should it run? checkboxes as you add the gate, or later from ⋮ → When it runs…. Turning both off is the same as Turn off.

When a record is refused

Creating one record returns a failure carrying the gate’s own reason:

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

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

Create a gate

Where you create it decides who it belongs to. Choosing wrong costs nothing — delete it and make it again elsewhere.

• Gates in the sidebar → Create gate makes an account gate: your library, addable to as many lists as you like, each with its own credential and fields. A profanity rule, a “is this a real product” standard or a required-field check belongs here.
• A list’s Gates page → Create a gate makes a gate that belongs to that list: it runs only there, is not in your library, and is deleted with the list. A rule building a name from street_number and thoroughfare belongs here — this is what an import creates when a file has no name column.

Either way:

1. Give it a Name — letters, digits and hyphens, unique across your whole account, including gates that belong to a list.
2. 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; its credential is a per-list choice made then.

What a list’s Gates page shows

• The table is every gate that runs on this list, top to bottom, in the order records meet them.
• On by default, rather than On, marks a gate that came with your account and has been there since the list was created.
• Not running on this list, under the table, is everything else available here, with what each does and an Add button: your account gates plus any gate belonging to this list. A gate belonging to another list is never offered, and nothing there costs anything until you switch it on.

Add a gate to a list

Press Add beside the gate you want, under Not running on this list. A model gate (Filling gaps or Judge) cannot be added without choosing the credential that pays for it on this list. The gate definition is shared, so editing it changes every list using it; 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. This is how you stop a gate that is on by default, and the list remembers it.
• Remove from this list returns it to Not running on this list, leaving other lists alone. Not offered for an On by default gate, since removing it would only restore the default.
• Delete gate removes it from your account and from every list using it. Built-in gates cannot be deleted.

Deleting a list deletes its own gates; every account gate it used is left as it was, still running on any other list.

Changing a gate that lists are already using

• Editing a gate moves it to a new version, and each list stays on the version it was on when the gate was added.
• Bump moves one list onto the current version: records arriving are judged by it, while records already there keep the old version’s values, stamped with the version that made them.
• Switching a gate off, reordering it or changing its credential does not move the version a list is on. Only a bump does.
• Backfill works out the values of records already in the list again, for gates that work out a value — refusing and rewriting are one-way. It spends your credential once per record, and skips records already at the new version, so re-running after a failure costs nothing for the ones that succeeded.

Being told what a gate did

Three webhook events cover the outcomes an import’s response cannot show:

• searchresult.rejected — a gate refused a record.
• searchresult.quarantined — a gate held a record back.
• gate.backfill-completed — a backfill finished or failed.

Subscribe to searchresult.rejected if you run feeds — a scheduled sync has no caller, so a feed that starts failing a rule stops being carried with nothing to say so. One message per record, capped at 200 per import; the full counts are on the import’s own report.

Notes

• A gate that cannot run — a rule that can no longer be read, say — is skipped and logged rather than failing the import. It counts as a failure, never a rejection: those records went through unchecked.
• Gates never see more than the batch in front of them, so a rule cannot compare a record against the rest of your list.
• Model gates are held to a fixed pace per account, so a feed syncing far more often than intended cannot use up your provider key’s allowance.