> ## Documentation Index
> Fetch the complete documentation index at: https://tyk-joancamostyk-patch-19.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Scoping Rulesets to Services

> How Tyk Governance uses API Categories to decide which services a ruleset evaluates, common scoping patterns, and how to diagnose a service that is not being evaluated.

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](/platform-management/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](/tyk-governance/quick-start#step-3-add-basic-information-and-scope-it).
* On an existing ruleset, under **Edit** on the **Basic settings** tab, in the **Link ruleset to services (Category)** multi-select. See [Configure a Ruleset](/tyk-governance/rulesets#basic-settings).

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:

| Change                                | Effect                                                                                                    |
| ------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| A category is added to a ruleset      | Every service in that category is evaluated against the ruleset                                           |
| A category is removed from a ruleset  | Those services are no longer evaluated against it, and its issues no longer count toward their compliance |
| A service gains a category            | The service is evaluated against every active ruleset linked to that category                             |
| A service loses a category            | Rulesets that reached the service only through that category stop applying                                |
| A ruleset is activated or deactivated | An inactive ruleset evaluates nothing, whatever its category links                                        |

For active services these run as background re-evaluations, and compliance status updates on its own when they complete. See [When Evaluation Runs](/tyk-governance/core-concepts#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](/tyk-governance/remediate-issues#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](/tyk-governance/rulesets#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](/tyk-governance/service-compliance#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](/tyk-governance/core-concepts#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.