Rules that tell you, and never stop you
Every team has a list of things that keep going wrong: a live article whose author is still a draft, a product with no image, a page nobody has touched in two years. Usually that list lives in somebody’s head. Here it is a rule the CMS evaluates for you — and the whole design rests on it never being allowed to refuse a save.
For whoever is responsible for the state of the content, rather than for one record
A rule is a filter you already know how to write
You narrow the records list until it shows the problem — published, English, no cover image. Then you save that filter as a rule and give it a severity. There is no second query language, no expression syntax and nothing new to document.
That is not a convenience, it is the correctness argument. The rule stores the exact filter the list was carrying, and it is evaluated through the same code the list runs. A rule can therefore only ever mean what the list means by the same filter — the two cannot drift, because there is only one of them.
It works in both directions. "Save this list filter as a rule" is one click, and every finding links straight back into the records list showing exactly what it matched, so you can go and fix them.
A filter narrowing a records list to fourteen of 1,046 records, saved as a named rule with a severity, producing fourteen findings that update as content changes.
No severity has authority
There are three severities — info, warn and error — and error is louder than warn. That is the entire difference between them. An alarm never blocks a save and never blocks a publish, at any level, and there is no setting that changes it.
This is the decision the whole feature is built around. The moment a severity could refuse a publish, it and the content type’s own validation would be two competing authorities on whether a record is valid — and sooner or later they disagree, in front of somebody on a deadline, with no way to tell which one is right.
So the line is drawn once: things that genuinely must not ship belong in the schema, where validation enforces them and the publish button greys out. Everything that is worth saying but not worth refusing over belongs here. Being unable to block is what makes an alarm safe to write on a hunch.
Three ways a rule gets checked
Between them they cover content that is being worked on and content that is not.
| When | What it covers |
|---|---|
| On every change | An entry is saved, published, unpublished, deleted or restored, and the rules that could care are re-evaluated for it. |
| On demand | Creating a rule scans immediately, and editing its filter forces a rescan before the response returns — so the findings never describe the previous condition. |
| On a timer | A background sweep, hourly by default. This is the one that catches "not updated in two years" — an entry matches that precisely because nothing is happening to it, so no change will ever arrive to notice. |
A rescan that hits its ceiling logs a warning rather than reporting a clean scan of a truncated set. A correctness tool that quietly checks less than you asked is worse than one that admits it.
The parts that make it trustworthy
- Findings close themselves
- "This live article links to a draft author" is a fact about the article, but the fix arrives as an event about the author. Publishing the author re-checks the entries pointing at them, so the finding closes on its own. Without that, the rule would open correctly and never clear.
- A broken rule says so
- If a filter stops parsing — a field was renamed out from under it — the rule is marked broken, skipped, and shown as broken. A rule that silently matched nothing would look exactly like everything being fine, which is the worst thing a tool like this can do.
- You cannot mute one record
- That existed and was deliberately removed. An alarm is either right about a record or wrong about it; silencing them one at a time is a way of living with a bad rule. Narrow it or switch it off — both are visible to the next person.
- History survives a fix
- A finding that clears keeps the date it was first seen. If the same record starts matching again it is the same finding reopening, not a new one that looks like it appeared today — so "this has been coming back for three months" is a question with an answer.
- Editors see them, admins write them
- Reading findings is granted to contributors and viewers, because they show up inline in the entry editor and an editor who cannot see them cannot act on them. Writing the rules is admin-only: a rule is editorial policy, not an edit.
- The assistant can read them
- "What is wrong with this workspace right now" is a question you can ask in the chat. Each finding carries the entry it is about, so the natural next request is to open one and fix it.
The week after a migration
Four thousand articles arrived from the old system and roughly none of them have alt text on the hero image. You do not want to block the team from publishing while that is sorted out, and you do not want to forget about it either. One rule, severity warn, and the number is on the screen every day until it is zero — going down as people work, without anybody keeping a spreadsheet.
Questions before you write the first one
Can I make one that does block publishing?
No, and that is not a setting we left out — it is the design. If a condition must stop a publish, put it in the content type’s validation, where the publish gate enforces it and the button tells the editor why.
Will it email me?
Not by itself. Findings live in the admin — on the alarms page, as a column on the records list, and in the entry editor — and on the findings endpoint, which is what to poll if you need to be told. The content change that triggered an evaluation is also a webhook event you can subscribe to, so a receiver can ask the findings endpoint the moment an entry is published. A finding on its own is not a webhook event kind, and there is no alarm-specific digest.
What does it cost on a big library?
The change path only looks at rows that just changed. The sweep is the one that touches whole collections, so it is the one with ceilings on it — how many entries a scan may examine, how many it reads at a time, and how often it runs. All four are settings.
What happens to findings when I delete a record?
A soft delete resolves them, because the record can come back and its history has to come back with it. Purging it deletes them, because there is nothing left to point at.
Next
Every feature is included, free
The core is MIT licensed and every feature is in it — none of them is paid-only. Community runs free in production; a plan buys room and governance, not a different product.