Skip to main content
Form rules are JsonLogic expressions. Most people should never have to write one. The rule assistant takes a sentence — only show this when the request is for equipment and the cost is over a thousand — and produces both the expression and a plain-English statement of what it does. It lives on every rule card, in the Rules tab of the form editor’s inspector.

​
The rule card

Select a field, a row or an element, open Rules, and add a rule. Each rule is a card with:

A header

The property the rule drives, a tick once it has a condition, and a one-line summary of what the condition says.

A Description box

Free text, read by whoever opens the form next. This is the only thing most people will read before trusting the rule.
Below those, two tabs: Generate and Raw.

​
Generate: a sentence into a rule

1

Say what you want in the prompt box

Ordinary language. Type @ to reference a field by name — the picker lists every field in the Record Set, nested ones grouped under their parent, and inserts the correct reference so the rule points at the right thing.
2

Press Generate rule

The assistant is told which property the rule drives, the fields available with their types and any fixed lists of allowed values, and the structure of the form you are editing.
3

It fills in the condition and the description together

On success the rule card updates and confirms Rule generated. The description it writes lands in the Description box; if you had already written one, yours is kept.
4

Check it, then preview it

Read the summary in the card header, then switch to Preview and exercise the rule both ways.
If it cannot turn the prompt into a rule, it says so — Could not build a rule — and the rule is left exactly as it was. Nothing is half-written. Rephrasing more concretely, and naming the fields with @ rather than describing them, is usually enough.

​
Generate a description for a rule that already exists

Once a rule has a condition, a wand button appears beside the Description box. It asks the assistant to read the rule and write out what it does in prose — useful for a rule inherited from someone else, or one written in the Raw tab. This does not change the rule. It only fills in the description.

​
The summary line

Separately from the assistant, every rule card carries a short summary in its header, worked out directly from the condition without asking anything: It is always up to date, because it is derived from the condition rather than stored alongside it — which makes it the honest reading when a hand-edited condition and a stale description disagree.
A condition the summary cannot phrase comes out looking like a function call — contains(notes, "urgent"). Arithmetic and list operators read this way legitimately (+(a, b)), so it is a reason to look rather than proof of a fault. But if a comparison comes out that way, the operator is almost certainly one that does not exist — in which case the rule card will say so in red.

​
Raw: editing the rule directly

The Raw tab shows the rule as JSON — its property, its condition, its description — and applies what you type as you type it. Invalid JSON is flagged and not applied. Use it to adjust a generated rule, to write an operator combination the assistant did not reach for, or to set a bare true / false.
The rule’s internal id is always regenerated from the element and the property it drives. Changing it in the Raw tab has no effect.

​
What it cannot do

The assistant can produce an operator the engine does not have. It is a language model writing JsonLogic, and JsonLogic dialects elsewhere include contains, startsWith and matches, which this engine does not. The rule card flags one when it sees it — a red note naming the operator, above the description — and the rule is then ignored when the form runs rather than obeyed. Read that note before saving, and preview the form to confirm the rule you meant to write is actually firing.
Every generation is a fresh, one-shot request. It does not know about the rule you generated a moment ago on another field, and it cannot be corrected by a follow-up message. To refine, edit the prompt and generate again, or adjust the result in the Raw tab.
The structure it is given covers the form’s rows and the fields placed in them. Fields inside a Repeater, and presentational elements such as headings and alerts, are not described to it. A rule about a repeater’s contents needs checking especially carefully, because the scope rules inside a repeater are unusual — see rules inside a repeater.
It writes the rule you asked for. It will not warn you that hiding a schema-required field blocks submission, that a Visible rule on a card does not clear what is inside it, or that a less than comparison shows the field to everyone who has not answered yet. Those are covered in Form rules.
Nothing is executed during generation. The only place a rule is genuinely exercised before people meet it is the editor’s Preview tab.

​
A working habit

1

Generate

Describe the rule, referencing fields with @.
2

Read the summary line

Not the description — the summary, which is derived from the condition itself.
3

Preview both ways

Make the condition true, then false, and confirm the form does what you meant in both states.
4

Keep the description honest

If you hand-edit the condition afterwards, update the description or regenerate it. A stale description is worse than none — it is the thing the next person trusts.