PreviewRule
Report what a candidate rule would change, without saving it.
The candidate is slotted into the workspace’s live rule set — replacing an
existing rule when id names one — and the whole resolution is run over
every check, so scope, priority, explicit categories and producer-declared
categories are all honoured. The response separates the candidate’s raw
reach from its real effect, which are rarely the same number.
Preview a rule before saving it: one that matches broadly can recategorise a large part of a workspace in a single sweep.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Body
Which checks the candidate would apply to.
- attributes
- expression
Set to an existing rule's id to preview an edit to it — the candidate replaces that rule during resolution, so the result reflects the change rather than the addition of a second rule. Omit to preview a new rule.
The dimension the candidate would categorise along.
CATEGORY_DIMENSION_UNSPECIFIED, CATEGORY_DIMENSION_TECHNICAL, CATEGORY_DIMENSION_GOVERNANCE Scope the candidate would be saved with. Defaults to RULE_SCOPE_WORKSPACE.
RULE_SCOPE_UNSPECIFIED, RULE_SCOPE_GLOBAL, RULE_SCOPE_WORKSPACE Title the candidate would be saved with. Does not affect the outcome.
200The category the candidate would assign.
1 - 200Priority the candidate would be saved with. It participates in resolution exactly as it would once saved, so previewing at the wrong priority reports the wrong impact.
-1000000 <= x <= 1000000How many check ids to return in each of the response's samples — it caps
affected_entity_ids and explicit_category_entity_ids independently, so
either may come back at this size. Defaults to 100, and may be 0 for
counts only. The counts are always exact whatever this is set to.
0 <= x <= 1000Response
Success
Checks whose predicate the candidate matches at all — its raw reach, whether or not it ends up winning them.
Checks whose effective category on the candidate's dimension would actually change. This is the rule's real impact. It equals newly_categorised_count + reassigned_count, and matched_count equals this plus unchanged_count.
Of the affected checks, how many have no category on this dimension today.
Of the affected checks, how many already have a different category that the candidate would take over. Worth a second look before saving.
Checks the candidate matches whose effective category would not change. The three fields below say why, and add up to this one.
A sample of the affected checks, ordered by entity id.
True when the sample was cut short by sample_size.
Of the unchanged checks, how many a rule of higher priority already wins, so the candidate never gets to assign anything. Raise the candidate's priority to take these over.
Of the unchanged checks, how many carry a category set explicitly on the check, or declared by the tool that produced it. Either outranks every rule, so these are the checks the candidate looks like it covers and does not — no priority will win them. Clear the explicit category to hand a check back to the rules.
Of the unchanged checks, how many the candidate does win, assigning the category the check already has. Nothing to do about these; the rule is simply agreeing with what is there.
A sample of the checks counted in explicit_category_count, ordered by
entity id — the ones worth showing a customer, because a rule that reads
as covering them does not.
True when that sample was cut short by sample_size.