Rule Coordination · ScaleSKUs MCP Academy #19

One rule reduces a bid because recent orders are weak. Another tries to increase it because a different performance signal looks strong. How do you stop your automation from fighting itself? Begin by asking ScaleSKUs to inspect the existing rules and schedules before proposing another one. In this lesson we review overlap, priority, cooldowns and action limits for a walnut strategy.

The aim is to understand how decisions interact at the same entity, not simply create more rules. Request the saved settings separately from your proposed settings, and ask which coordination mechanisms the system actually supports for each type of operation. The checked account contains a disabled weekly keyword cleanup rule. It examines fourteen days, requires at least twenty clicks and five hundred rupees of spend, and looks for zero orders.

Its proposed action is a ten percent bid decrease with a five-rupee minimum. It has priority one hundred, a twenty-four-hour cooldown and an approval requirement. These are the existing settings, not a recommendation to copy them into every account. Because the rule is disabled, it does not currently create an active collision. However, enabling it alongside another overlapping bid rule could create a future coordination problem that deserves review beforehand.

The important follow-up is whether priority controls every kind of action in one universal order. The verified answer is narrower: a lower priority number acts first for overlapping operations of the same type. That does not establish a universal sequence across negatives, bid increases, bid decreases and budget changes. Do not build your strategy around an imagined orchestration feature. Ask which entity and operation each rule can affect, then identify overlaps explicitly.

A negative target can change the traffic that a bid rule later evaluates, even when the two rules are not competing to write the same field. A cooldown can help avoid repeated changes before the previous action has had time to produce useful evidence. It is not a substitute for a mature reporting window, and it should fit the action and the business.

A proposed weekly bid review might use a longer cooldown than the existing twenty-four hours. That is a design choice to evaluate, not a saved setting or a universal best practice. Ask how cooldowns interact with approval and execution history. If several rules can affect the same product or campaign, check whether the protection applies across those actions or only within an individual rule.

The planning discussion includes example safeguards such as limiting bid movement, limiting budget increases and capping actions per run. Keep those examples clearly marked as proposed. Before saving anything, replace them with limits that fit the seller's margins, inventory, growth priorities and budget authority. We have not been given a verified advertising-cost target for this business, so we should not insert a convenient default.

A sensible automation plan says which business input is missing and who can supply it. It also explains how a reviewer can reject an action whose numerical condition is met but whose product context makes it inappropriate. Use the four verified walnut campaigns as the proposed scope and leave the unresolved campaign outside it. Then ask for an overlap review between the existing cleanup rule and the proposed strategy.

List affected entity types, operations, conditions, cooldowns and approval requirements. Check day-parting schedules too: a schedule can influence a budget or bid independently of the rule you are reviewing. The account currently has no active day-parting schedules in the checked result, but that should be rechecked when the strategy is deployed. Keep current configuration, potential future conflict and proposed mitigation in separate columns so the team can act on each correctly.

The final output should be a coordination brief, with the real objective, verified scope, operation boundaries, proposed limits, approval steps and review dates. Explain what happens if two conditions are satisfied together, and which behaviour still needs validation in a preview. Start with a controlled approval-based run and inspect the proposed actions before widening the scope. For practice, compare two rules that might touch the same keyword.

Identify whether they change the same field, whether priority applies, and whether their evidence windows allow a meaningful review. Good automation is a coherent decision process, not a collection of individually plausible rules.