Require

Stop the action with a message unless a condition holds. This is how a row action enforces a rule.

Ingredient Family: rowActionsIngredients

Outline Display: Require that {{condition}}, and refuse with this message otherwise: {{message}}
Before refusing, perform: {{onFailure}}

Details

If the condition is false the action stops there: the steps after it do not run, and whoever ran the action – a person at a button, or the model at a Tool – is told the message. Place the Require before the step it is protecting, and write the message for that reader: say what the rule is, not that a check failed. A refusal is audited in its own right: the step writes a Refuse audit line naming the acting user and the message, so a run that stopped on a rule can be found in the log even though nothing was written, read or sent. onFailure runs before the refusal is reported, for compensating work such as writing a review or audit row or setting a flag. Its page content is discarded and any columns it adds are dropped, so a refusal reports its message alone. If onFailure itself fails, the original refusal is still what gets reported and the compensation’s failure is only logged. Its writes survive because a refusal is data and the surrounding transaction still commits; a caller that turned a refusal back into an error would roll them back, but no caller in the library does that. Require checks a value you already have; a scalar it cannot notice as missing. Formulas are total, so a formula over an absent or NULL column evaluates to a default and reads as benign – a Require over a scalar that was never fetched will happily pass. To state an assumption that a row exists, fetch it with Load column from query, which fails the action when the query returns no row; a Require on what you fetched then states the rule about its contents. Lists are the exception, because an absent list evaluates as empty: ALL over it passes and ANY over it fails, for a reason that has nothing to do with the data, so a rule such as “every label supplied is one of the user’s labels” would answer from a list that was never loaded. So when the condition mentions an optional list column and that column is absent at run time, the step does not evaluate the condition at all: it fails with guard input <column> was never loaded, a malfunction rather than a refusal, because the pipeline is wrong and not the data.

Local scope

The parent slot binds these (look up the slot in the parent to see how):

• $table – The table to act on

Settings

Required

• condition : formula (returns bool; required, non-nullable)
  The boolean formula that must be true for the action to continue; [Username] is the user running the action, so a rule about who may act is written here
  Scope: current time as [CURRENTTIMESTAMP], current username as [Username] (only where the handler authenticates: a logged-in page, or the calling user of an MCP tool, including inside its pipeline), all columns of $table (reference as [ColumnName], e.g., [Name], [Price])

• message : constant value (type: text; required, non-nullable)
  The message reported to whoever ran the action when the condition is false; state the rule, e.g. “Messages with the Protected label cannot be relabelled.”

Optional

• onFailure : ingredient slot of rowActionsIngredients($table) (many)
  Compensating action(s) to perform before refusing; omit this to simply refuse