capacity_rules verifiedcriticalWritten by the Hub

Four columns decide the whole matching model: which profile, which destination domain, which sending address, which pool. An empty value is a wildcard, so one row can say "this profile for everything", another "this profile for gmail.com from this address". A target belongs to one profile only. Pointing a second profile at a combination that is already taken does not create a competing row — the engine moves the existing one and says so: the console API answered {"result": "stolen", "from": 1}, and the table still held a single row, now owned by the new profile. That is why there is no order column and no priority to resolve: conflicts over the same target cannot exist. Rules that match the same delivery through *different* dimensions do coexist, and then the strictest limit wins (mq5.concept.limit-resolution). For Hub the consequence is a warning rather than a design problem. Writing a rule for a combination an operator had already assigned silently takes it away from their profile, and nothing in the console flags the transfer afterwards. A generator should read the table first and report what it is about to take over.