What a catalog playbook is

Playbook holds your content preferences: language, tone, vocabulary and structure. Checks holds the requirements that determine whether a product raises a finding. Both apply to one selected store.

It is not a stop on the loop. It is what the loop reads.

The loop runs stations: your catalog is watched, findings are raised, drafts are written, reviewed, applied, and the next scan says whether the change held. The playbook is not one of those stations. It stands beside the loop as reference material — and three stations read it every time they run.

Checks + Playbook store rules + published preferences
  1. Sync
  2. Scan what is a finding
  3. Draft what the model is told
  4. Review what the reviewer sees
  5. Apply
  6. Proof

publishing a playbook queues a fresh scan of the whole catalog

Three dashed edges, three real readings. The line back to the scan is what publishing costs.

Checks owns the full-description minimum

This is the reading people forget, because it happens before any AI is involved. The thin-description check needs a line to measure against, and somebody has to draw it.

Enter a minimum and enable the control in Checks. Without that decision, the length control is off. Other products never move this boundary. Playbook can set a preferred maximum, but cannot set a second minimum. Saving or publishing a conflicting range is refused.

An explicit minimum in Checks stays the same before and after an unrelated catalog import. BEFORE AN UNRELATED IMPORT the minimum chosen in Checks AFTER AN UNRELATED IMPORT the shortest description you are willing to publish — it stands until you move it
The same requirement before and after an import. Only a decision in Checks moves the minimum.

It decides what the model is told

When a finding has an AI proposal, the playbook in force is part of what the model is given, alongside the product's own data:

  • Voice. The tone you write in and the shopper you write for.
  • Vocabulary. Words you prefer, and words that must never appear in a draft — each one able to carry the word to write in its place.
  • Claims. Promises your catalog is not allowed to make.
  • Shape. For a title, the pattern to follow and the components that pattern has to carry.
  • Length. Preferred ranges for other fields and the full-description maximum; its minimum comes from Checks.
  • Language. The language the draft is written in.

Language earns its own line. A draft in the wrong language is unusable however good the copy is, and the fields that most often need drafting — an empty description, a missing alt text — are exactly the ones that give a model nothing to infer a language from. Your playbook's answer wins; where it gives none, the site language your connector synced stands in.

Everything the playbook says reaches the model as data, never as instructions — the same footing your catalog's own text stands on.

It decides what the reviewer sees

Two checks run on a finished draft, and neither takes the model's word for anything.

  • A forbidden word is caught deterministically. Whole words, case-insensitive, measured on the plain text a shopper would read rather than on the markup around it. Where you gave a replacement, the note names it — so it says what to write, not only what is wrong.
  • Length leaves a note, not a wall. Soft limits never reject a draft. For a description the scanner's own threshold speaks first: a reviewer about to accept a description the next scan would flag again hears about it here, rather than from the next scan.

Publishing is an event, not a save

A playbook version is immutable and carries the name of whoever put it in force. Publishing one does three things at once, because the work already on your register was measured with the ruler you just replaced.

Publishing queues a fresh scan, sends assessments written under superseded rules back for a re-run, and reopens dismissed opportunities. You publish version · name · timestamp The whole catalog is scanned again the register stops answering to the numbers you replaced Assessments written under the old rules go back for a re-run field by field — move your title rules and the descriptions stand Dismissed opportunities open again the “no thanks” was about the rules you just replaced
You see the bill before you commit to it: how much work goes back for a re-run, and how many dismissals reopen. Republishing rules identical to the ones in force is refused rather than charged for.

What a playbook does not do

  • It does not reject a draft for its length. A soft limit is a note for whoever is reading.
  • It reaches five fields and no others: title, description, short description, SEO title, SEO description.
  • It does not censor facts. Forbidden words speak about prose, not about a brand name or an attribute value the catalog itself carries.
  • It changes nothing in WooCommerce by itself. Every applied change still carries an authority and a receipt — a named account decided it, through a door we record.
  • Retiring a playbook returns the store to neutral defaults. It does not bring an older version back.

Where it lives

Playbook is one of the panel's reference screens, beside the loop rather than on it. You can write and publish one there, and so can an agent you connected — the same four moves either way: read the rules in force, save a draft, discard it, put it in force.

A playbook does not add a step to the loop. It replaces the ruler the loop already measures with — and because what was measured is written down, changing the ruler means measuring again.

Not connected yet? The scan is free.

Create an account, connect your WooCommerce store and what this article describes runs on your real products.

No card required. The free plan never writes to WooCommerce.