A rule uses supported fields and actions to decide label behaviour. Plain-English authoring proposes a condition for you to review. A compilation result does not change production or publish a release.
Define the requirement first
Identify which supported field decides the outcome, its exact values and the action required. Include what should happen when the condition does not match or a value is missing.
For example, a customer-specific layout requirement needs the actual customer identity or code the workflow supplies. Avoid ambiguous language such as “special customers” without a defined field or list.
Save the intended change
- Open Rules and select the appropriate draft and condition target.
- Check the displayed source rule and actions before editing.
- Describe when the selected rule should match, using the supported catalogue fields.
- Save the intent. Check that the saved revision is current before compiling.
Saving new intent and accepting a proposed condition are separate actions. Merely changing the text does not silently replace the saved condition.
Compile and review
Use the compilation control for the saved intent when authoring is available. The request can run in the background. Follow its receipt and current status; repeatedly submitting new requests is not a progress check.
Read the result. It may ask for clarification or report an unsupported or invalid requirement. Resolve the stated issue rather than assuming every plain-English request can become a valid rule.
For a successful proposal, read the restatement, required fields, target condition and proposed actions. Compare them with your original requirement and the saved rule. Complete the review acknowledgement and note before accepting the proposal into a new draft revision.
A proposal for old or changed work may no longer be acceptable. Reload and review the current revision; do not accept an old result just because it previously succeeded.
Check the actions too
A correct condition with the wrong layout, derived value or quantity is still the wrong label. Where the editor offers typed actions, check their targets and parameters. If the requested action is not supported, escalate the requirement instead of encoding a misleading condition.
Prove the behaviour
Open the examples workflow. Set independent inputs and expected outcomes, including a matching case, a non-matching case, relevant boundaries and a required refusal. Save, verify and inspect the resulting proofs and decision information.
Use examples and releases to freeze and hand the change to the Reviewer. Production continues using its active approved release until a new one is published.