What this module is for

Use Activity Tag Rules to configure player tag changes associated with tracked activities. Operators define an activity, an add/remove tag action, priority, active state, and optional condition data. Treat condition testing and live application as separate paths: the estimator understands the current form condition keys, while the live rule model does not prove equivalent evaluation for those keys.

Main surfaces

• Activity Tag Rules / List is the operational inventory for all saved rules.
• Activity Tag Rules / Create is the create flow, including clone-from-existing behavior.
• Activity Tag Rules / Edit is the grouped editor that can update at most the add and remove rule IDs retained by the list row.
• Activity Tag Rules / Detail is the inspection surface with estimate, run, and delete actions.
• Activity Tag Rules / Applications is the recent audit trail shown inside the detail page.

What operators need to know first

• The list groups stored rules by normalized name, activity, and nearby priority. A visible row retains at most one Add ID and one Remove ID, but duplicate source rows are not prevented and later matches can overwrite earlier retained IDs.
• The create and edit screens can save either one stored rule or two stored rules depending on whether Add Tag, Remove Tag, or both sections are enabled.
• The form exposes conditions only for FAILED_WITHDRAWAL, SUCCESS_WITHDRAWAL, SUCCESS_DEPOSIT, and FAILED_DEPOSIT.
• Test Conditions and Estimate Impact query activity/user history with the current form condition keys. A successful estimate proves estimator matching only; it does not prove that live events enforce the same condition set.
• Live tag mutation is event-driven and evaluates one activity/user context at a time; it is separate from the manual Run control.
• The live model currently evaluates only minCount, maxCount, minAmount, maxAmount, and timeFrame. Those keys are not offered by the current form, while the form's transaction/user condition keys are implemented in the estimator. Until the product code is aligned, do not rely on a passing form test as a guarantee of live filtering.
• Run Rule and list Run currently validate an active saved rule and return zeroed counters. They do not enumerate users, mutate tags, or create application rows in the traced implementation.

The verified ownership for this module is in the admin service. Supporting condition-option data uses the shared payment-method source; no casino-side dependency was required for the currently verified operator surfaces.

Important caveats

• The source stores these rules in auto_tag_rules, even though the operator-facing wording is Activity Tag Rules.
• The estimate query and live event evaluator are different implementations with different supported keys.
• The detail page shows only the latest applications requested by the page, not an unlimited full-history screen.
• Application rows are not a complete event audit. Condition-failed and missing-user outcomes return skipped results in memory but do not create application rows.
• The rule screens do not provide a durable action-history view for create, update, delete, or Run. Use Applications only as recorded tag outcomes, not as an audit of those operator actions.