Skip to main content
A ruleset is never bound to a specific service. It is bound to one or more API Categories, and it evaluates every service carrying one of those categories. This page covers that mechanism, because it decides which of your services governance actually touches.

​
How a Ruleset Finds Its Services

Tyk Governance uses Tyk Dashboard’s existing API Categories as the mechanism for scoping rulesets to services. When a ruleset is created or edited, one or more categories can be linked to it. Any service tagged with a matching category is automatically evaluated against that ruleset. This means:
  • A ruleset applies to every service that carries one of the ruleset’s linked categories, not to a hand-picked list of services.
  • Adding or removing a category, either on a ruleset or on a service, changes which services the ruleset evaluates. No manual re-binding is required.
  • A single service can be evaluated by multiple rulesets, for example one for security, one for design, and one for a specific business domain, by tagging the service with the relevant categories.

​
Linking a Ruleset to an API Category

Categories are set on a ruleset in two places, and both do the same thing:
  • In the creation wizard, at the Basic Info step. See Quick Start Step 3.
  • On an existing ruleset, under Edit on the Basic settings tab, in the Link ruleset to services (Category) multi-select. See Configure a Ruleset.
A ruleset saved as a draft holds its category links but evaluates nothing. Scope takes effect when the ruleset becomes Active.

​
What Happens When Categories Change

Because scope is derived rather than fixed, a change on either side re-derives it, and re-evaluation follows automatically: For active services these run as background re-evaluations, and compliance status updates on its own when they complete. See When Evaluation Runs. The consequence worth planning for: a service’s compliance status can change without its owner touching it, because someone else changed a ruleset or a category. That is expected behavior, not a fault. See When a Ruleset Change Breaks You.

​
Scoping Patterns

Three patterns cover most organizations. Organization-wide baseline. One category applied to every service, with a single security or design ruleset linked to it. Every service is held to a common minimum. This is the simplest starting point, and the easiest to reason about when results are unexpected. Per-domain standards. A category per business domain or per exposure level, such as public, internal, or payments, each with its own ruleset. Stricter standards apply where the risk is higher, without imposing them everywhere. Services commonly carry both a baseline category and a domain category, and are evaluated against both rulesets. Opt-in adoption. A dedicated category that teams add to their own services when they are ready to adopt a new standard. The ruleset exists and is active, but only reaches services whose owners opted in. Useful for introducing a demanding standard without a portfolio-wide result on day one. To preview the outcome before opting in, use the test panel rather than the category: see Test a Ruleset Against a Service. Because scoping is category-driven, keeping categories narrow also keeps re-evaluation windows short. A ruleset change re-evaluates every service sharing its categories.

​
Why a Service Is Not Being Evaluated

Work through these in order:
  1. Is the ruleset Active? A draft or inactive ruleset evaluates nothing, even with categories linked. Check the Status column in the Rulesets list.
  2. Do the categories match exactly? The service must carry a category that is linked on the ruleset. A near-miss name is a miss.
  3. Is the service active? Evaluation is triggered by deploying a service to the gateway. A service that has not been saved has nothing recorded against it yet.
  4. Has the background evaluation finished? Re-evaluation after a ruleset or category change is asynchronous. Large definitions can take a few seconds, and very large ones up to about ten. See Evaluation Performance.
  5. Do you have permission to see it? The Deny level on the Rulesets Governance permission group hides the feature entirely. See Roles and Access.
If all five check out and the service still shows no result, run the ruleset against the service directly from the test panel. A test that returns issues while the Governance tab shows none points at scope or evaluation state rather than at the rules themselves.