Rehearsals must show the specific actions that would fire

What it is

A rehearsal is worth what it shows. Abstract feedback — "rule valid", "syntax OK", "would trigger 1 automation" — is close to useless: it verifies that the rule runs, not that it is right. An effective rehearsal must land on a device-level action list: "would run: porch light to 100% and hold 10 minutes; send notification 'door opened' to Mum's phone". The user checks that list against intent, and only then activates.

The line between abstract and concrete is single: can the user get from what is shown to a judgement of "is this what I wanted?" "Would trigger" cannot reach that judgement; "what it does when triggered, to which device, with what parameters, notifying whom" can.

Why it happens

Why device-level specificity? Because nearly every rule error hides along the mapping chain from condition to action, and abstract feedback folds that chain away:

• Wrong target: the condition is right, the device is wrong (porch light vs living-room light) — visible only in a device-level list.
• Wrong parameter: right device, wrong value (10% vs 100% brightness) — visible only when parameters are expanded.
• Wrong scope: "all lights" versus "this light" is the most silent ambiguity in rule languages; a list that enumerates "living room, dining room, bedroom…" settles it at a glance.
• Wrong order and contention: execution order among actions, and overrides against other rules — comparable only item by item.

Abstract "valid" certifies the syntactic layer; all four error classes are semantic, and pass syntax untouched. A rehearsal that reports only "valid" does what the user already knew (a successful save already said the syntax was fine) and lets the actual verification task idle.

There is also a cognitive mechanism: comparison needs anchors. To judge "is this what I want", users compare the shown content item by item against remembered intent — an unexpanded list gives working memory no anchor, and the judgement degrades to global intuition ("feels about right"). But intuition is precisely what already erred during rule creation; using it to verify is putting the defendant on the bench.

Where it stops holding

• Specificity has a reading-cost ceiling. Rules with a dozen actions (whole-house shutdown) make item-by-item display its own burden; the right form is grouped summary with expansion ("lights off ×12 (expand)") — not folding everything into one number, and not dumping every detail either.
• "Would fire" carries only the certainty of the rehearsal type. Replay says "would have fired 4 times last month" — a statistical statement, not a promise; wording must stay honest ("based on last month's data"), because overstated certainty manufactures new misplaced trust.
• Concrete actions are not physical consequences. The list shows "socket off", not "the running dryer cycle will be interrupted" — the consequence layer (what this means for what is happening at home) exceeds an action list's expressive range; heavy-consequence rules need separate warnings, not a list expected to speak for itself.
• Notification actions have a privacy boundary in how they are previewed. "Would notify Mum" should not render the full message text to everyone present — the rehearsal's own display must respect its audience.

Applying it

• Fix rehearsal output to a three-part list: when the condition holds (times and sources), the actions that would run (devices, parameters, order), and the notifications that would go out (to whom, content summary) — each part expandable, the action part expanded by default.
• Make scope ambiguity explicit: when an action targets a group, enumerate the members ("all lights = living room, dining, bedroom, hallway"); group membership changes rule behaviour, and that coupling should be visible in the list itself.
• For notification actions, render one real sample (a genuine template with demo values in the placeholders) — the notification is its wording to its recipient, and "send notification" in the abstract verifies nothing.
• For multi-rule interaction, list the other rules in the same scene: "this condition also triggers 'eco mode'; the two conflict on the AC, and eco currently wins by priority" — rules never act alone, and single-rule rehearsal misses the contention.
• How to check: after reading the list, have users paraphrase "what will this rule do" and compare with the actual rule — where paraphrase omissions coincide with collapsed list items is where specificity is insufficient; after launch, track which fields post-rehearsal edits touch (device? parameter? scope?) — those are the places display is already saving people.

Related

• Same group: Z5.07.1 Rules need a rehearsal before going live, without touching real devices · Z5.07.3 Without a test environment, side effects surface only in live runs · Z5.07.4 Rehearsals must cover boundary conditions, not just the happy path
• Nearby: Z5.02 Rule conflicts · Z5.04.3 Natural-language descriptions must be verifiable
• Search terms: preview · action preview · rule verification · specificity