The visual builder

Where it starts

Press New lookout. It opens on the templates — worked starting points you can adopt as they are — with the three blank starts beneath them: the builder, the editor, and paste. Most rules take the builder; a rule somebody pasted, or one that nests, wants the editor.

Or skip both and start from a template. They come in three groups — stopping waste, backing what already sells, and keeping an eye on something — and every one of them opens in the builder as an ordinary rule you can edit.

The sentence you assemble

The builder lays the rule out as the sentence it is, and every part is a menu.

1. Grain — what kind of thing to look at: target, campaign, ad_group, ad, search_term, negative, product, variant, or gap for rows that do not exist.
2. Scope — which marketplaces. Leave it at all markets unless you have a reason; a rule pinned to one market silently ignores the others.
3. Trigger — manually, on publication, daily or weekly. All four are floors, not clocks.
4. When — the condition chips. Pick a property and the menu already knows its kind: a metric asks for a window (spend(last30)), a static fact does not (match_type). Pick an operator, type a value. Chain more with + and / + or.
5. Then — one action, with its parameters: pause, enable or archive; set, lower or raise a bid or a budget; negate; promote a term; target a product; split a product out; advertise it; tag; report only. The full table is in the language reference. One is the builder's limit, not the language's: a lookout that answers "how bad is it" with a different verb for each degree is written out, because the form has one action row and no way to draw the condition that picks between two.
6. Guardrails — the safety row: minimum clicks, orders and spend, cooldown days, max items per run, max change, and whether to require fresh data.

The catalogue actions — setting a price, editing attributes, adding a product — appear in the menu and build a rule that previews correctly, then decline to queue. You can still make those changes by hand; what is not open yet is letting a rule make them for you, because a catalogue change is much harder to walk back than an advertising one.

What the builder makes impossible

Every menu shows only what exists: properties that are real for the chosen grain, windows the data actually has, values typed to the property's kind. A percent field takes 20%, an enum field offers PAUSED, a money field takes a bare number in the account's own currency.

There is no way to assemble an invalid Lookout from the menus.

That safety is also the boundary. The builder draws groups joined by one connector, and it draws more than people expect — qualifiers upward (its campaign's spend), quantifiers downward (every target inside it), and comparisons of one metric against another. What it has no boxes for is:

• bracketed nesting, like a and (b or c);
• named values — let bindings;
• a period set on a whole group rather than on each condition;
• an operator that is real but not offered for that property's type;
• an action whose value is an expression rather than a number.

A rule using any of those is a code rule.

Preview before you trust it

Preview runs the rule against your data and shows exactly what a run would propose. It is not an approximation: preview and run call the same function, so a preview cannot lie about what a run would do.

You get two lists — the proposals, and the rows the Lookout held back, each named with its reason. Read the held-back list on a new rule. It is the fastest way to learn what your guardrails are actually doing.

Switching surfaces

Every rule is owned by one surface. A builder rule can be read as text at any moment: the printer emits the same rule line for line, and that text parses straight back into the same rule. Nothing is lost in either direction, because the text is a view of the rule rather than a second copy of it.

A code rule works the other way. Its text is the authority, the editor edits it, and the form does not open it. That is not a limitation to work around — it is what stops two versions of one rule from quietly disagreeing.