> ## 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.
# Rulesets
> What a governance ruleset is, and how to create, configure, test, and delete the rulesets that define the standards your services must meet.
A ruleset is the unit of standard-setting in Tyk Governance. This page covers what a ruleset contains and the workflows for managing them in Tyk Dashboard.
For a guided walkthrough that creates a ruleset from a template and reads its first result, see the [Quick Start](/tyk-governance/quick-start). For how a ruleset finds the services it governs, see [Scoping Rulesets to Services](/tyk-governance/scoping-rulesets).
## What a Ruleset Is
A governance ruleset is a set of rules and standards that services must adhere to. Rulesets define the requirements for service design, security, documentation, and operational characteristics. They act as executable policies that codify your organization's service governance expectations.
## Ruleset Components
Every ruleset is composed of:
* **Rules**: Individual checks that validate specific aspects of a service definition.
* **Severity Levels**: Each rule carries a severity of Error, Warn, or Info that determines how strongly the rule's outcome affects compliance. See [Severity and Compliance](/tyk-governance/core-concepts#severity-and-compliance).
* **Validation Functions**: The specific logic used to evaluate service definitions against rules. Tyk Governance ships with built-in functions covering the common cases.
* **Remediation Guidance**: Per-rule "How to fix" guidance authored alongside the rule itself, displayed inline against any service that fails the rule.
Two examples of individual rules:
```yaml theme={null}
# Security rule requiring HTTPS for server URLs
hosts-must-use-https:
description: All server URLs MUST use the https protocol
severity: error
given: $.servers[*].url
then:
function: pattern
functionOptions:
match: "^https://"
howToFix: "Update server URLs in your API definition to use the https scheme."
```
```yaml theme={null}
# Ensure rateLimit is configured under upstream
rate-limit-exists:
description: Ensure rateLimit exists under upstream
severity: error
given: "$['x-tyk-api-gateway'].upstream"
then:
field: rateLimit
function: truthy
howToFix: "Add a rateLimit configuration under x-tyk-api-gateway.upstream."
```
Rulesets can be customized to meet organizational needs and evolve as service best practices and security requirements change.
## Spectral Compatibility
Tyk Governance rulesets are compatible with the [Spectral ruleset format](https://docs.stoplight.io/docs/spectral/e5b9616d6d50c-rulesets), a widely adopted linting and governance standard. This compatibility offers several advantages:
* **Familiar Format**: Teams already using Spectral can migrate their existing rulesets without rewriting them.
* **Ecosystem Integration**: You can use the broader ecosystem of pre-built Spectral rules.
* **High-Performance Execution**: Tyk Governance executes rulesets using the Vacuum engine, a high-performance Go-based linter that is fully compatible with the Spectral ruleset format and significantly faster than Spectral on large service specifications.
The Spectral-compatible format allows declarative rule definitions with a `given` and `then` structure, built-in functions, and detailed error messaging.
## Create a Ruleset
Tyk Governance offers two paths for creating a ruleset, both accessed through the **+ Create new ruleset** wizard.
### From a Template
Templates are pre-built rulesets. They give teams a runnable starting point on day one, rather than requiring rules to be authored from scratch. The wizard takes you through:
1. **Define basic information**: name, description, Deployment Warning toggle, and API Categories.
2. **Choose starting point**: select **Start from template**.
3. **Browse templates**: choose from the templates available in your environment.
4. **Review and edit**: the template's JSON loads into the editor. Adjust as needed.
For what each shipped template enforces, see [Ruleset Templates](/tyk-governance/ruleset-templates). For a step-by-step walkthrough with screenshots, see the [Quick Start](/tyk-governance/quick-start).
### From Your Own Definition
If you already maintain Spectral rulesets, or you want to write one from scratch, choose **Start with your own definition**. You then have two sub-options.
**Import from file.** Upload a `.json` or `.yaml` Spectral-compatible ruleset.
**Paste ruleset definition.** Paste or write the ruleset directly into the editor.
## Configure a Ruleset
Click any ruleset in the list to open its detail page and click **Edit**, or select **Edit** from the Actions drop-down. The page has two tabs.
### Basic Settings
The default tab. From here you can adjust:
* **Status**: Inactive, which does not evaluate services, or Active, which evaluates all mapped services.
* **Name**: Required, and unique within the organization.
* **Description**: Long-form description.
* **Link ruleset to services (Category)**: Multi-select. The ruleset evaluates services in any of the selected categories.
* **Deployment Warning toggle**: Off by default. When on, saving a non-compliant service in a matching category produces a soft warning at deploy time. See [The Deployment Warning](/tyk-governance/remediate-issues#the-deployment-warning).
### Raw Definition
The Raw definition tab exposes the full ruleset JSON in an editor. Use this tab to edit individual rules, change severities, adjust JSONPath selectors, edit `howToFix` text, or add and remove rules.
When you save changes on either tab, all services governed by this ruleset are re-evaluated automatically in the background.
## Test a Ruleset Against a Service
Beyond the continuous evaluation that drives a service's actual compliance status, Tyk Governance provides a test mode for previewing how a ruleset would behave against a service, without affecting that service's compliance status.
Test runs are available from two entry points:
* **From the ruleset's detail page**, described below. Select any service and run the current ruleset against it. Use this when you are authoring the ruleset.
* **From the Governance tab on a service**. Run any ruleset against that one service. Use this when you own the service. See [Service Compliance](/tyk-governance/service-compliance#see-compliance-for-a-service).
To run a test from the ruleset's detail page:
1. Open the ruleset's detail page.
2. In the Test ruleset panel, select a service from the dropdown.
3. Click **Run ruleset**.
4. Review the issues returned, graded by severity.
In both cases the results are for preview only. They are not stored as part of the service's compliance status, do not affect the Governance tab's banner counts or per-ruleset compliance scores, and do not trigger background re-evaluation. What you see is informational guidance, not a recorded evaluation.
Test runs are useful for:
* **Reviewing a ruleset before activating it**: run a draft ruleset against a representative service to see what would be flagged, then refine the rules before linking the ruleset to a category.
* **Iterating on rule severity or definitions** while editing the Raw definition.
* **Spot-checking an individual service** against a ruleset that is not currently linked to its category.
## Find a Ruleset in the List
The Rulesets list page shows every ruleset in your organization. Use the search bar to filter by name and the category dropdown to filter by API Category.
The list shows, for each ruleset:
* **Status**: Active or Inactive. Inactive rulesets do not evaluate services.
* **Name**: Click to open the ruleset's detail page.
* **Category**: The API Categories the ruleset is linked to.
* **Deployment Warning**: Whether the warning toggle is on or off.
* **Last updated**: When the ruleset was most recently modified.
* **Actions**: View or edit the ruleset.
## Delete a Ruleset
Click **Edit Ruleset**. A delete button appears at the top right. A confirmation modal then opens to confirm the deletion.
## Run a Ruleset From a Pipeline
Once a ruleset is linked to a category, you can also run it against an API definition from your CI/CD pipeline, before that API is ever imported into Tyk Dashboard. See [CI/CD Governance Checks](/tyk-governance/cicd-checks).
## Best Practices
* **Start with templates.** The OWASP API Security and Vacuum-Recommended templates cover most baseline cases without requiring custom authoring.
* **Use clear, actionable `howToFix` text.** When a rule fires, the API owner should be able to act on the guidance immediately.
* **Keep rulesets focused.** A ruleset of 200 mixed-purpose rules is harder to maintain than three rulesets of 60 each, organized by domain such as security, design, and documentation.
* **Use the test sandbox before activating.** Run a draft ruleset against representative services before linking it to live categories, especially when promoting rules to Error severity.
* **Assign clear ownership.** Document which team or individual owns each ruleset, so changes go through a sensible review.
## FAQ
Governance ships two curated templates, OWASP API Security and OpenAPI design standards, giving you a ready-to-use starting point you can customize. Writing your own ruleset from scratch, or importing an existing Spectral ruleset, gives you full control when your standards do not map closely to either template.
No, there is no limit.
Yes. Editing a ruleset automatically triggers re-evaluation of every service it governs via linked categories. It is not something you need to trigger manually.
No. A service can be linked to any number of rulesets at once, and each is evaluated and reported independently. A separate limit of 20 applies only to the CI/CD sandbox endpoint; see Limits in the Governance Evaluation API reference.
Yes. Creating, editing, and deleting rulesets are all recorded in Tyk Dashboard's existing audit log.
No. Testing a ruleset from the sandbox does not change the service's actual compliance status.