Governance

Org-level API governance in Spec0 — Spectral linting rulesets today, with naming, breaking-change, and source policies on the roadmap.

API governance in Spec0 is configured per organisation under Settings → API governance. Today that means one shipped capability — Spectral linting rulesets — with several policy types planned. This page documents what's live and what's coming, honestly labelled.

Only Spectral rulesets below are implemented end-to-end. The other policy types are visible in the dashboard as placeholders and are not yet enforced — they're listed under Roadmap so you know what to expect.

Spectral rulesets (live)

Spec0 lets an org define and manage Spectral rulesets centrally, so every team lints against the same standards. Built-in rulesets (spectral:oas, spectral:asyncapi, spectral:arazzo) are always available; custom org rulesets require a Pro plan.

Managing rulesets

From Settings → API governance → Spectral rulesets you can create, edit, preview, and delete named rulesets. One default ruleset is always present and can't be deleted — it backs the org's baseline linting.

Linting against them from the CLI

The rulesets you configure are what spec0 lint uses:

# Lint against your org's configured ruleset
spec0 lint ./openapi.yaml --org-ruleset

# Lint against a specific local ruleset file
spec0 lint ./openapi.yaml --ruleset ./my-rules.yaml

# Upload a local ruleset as the org config (Pro)
spec0 lint ./openapi.yaml --save-ruleset ./my-rules.yaml

spec0 lint reports a quality score and findings. In CI, use --min-score <0-100> or --strict to fail the build (exit code 7) when a spec falls below your bar:

spec0 lint ./openapi.yaml --org-ruleset --min-score 80

How it relates to publishing

Linting is a separate step from publishing — spec0 push / spec0 publish don't run the org ruleset for you. Run spec0 lint in CI before you publish (or use --strict on push, where supported) to gate on lint quality yourself. The same lint score surfaces to agents via the get_api_health MCP tool.

Roadmap

These appear under Settings → API governance as placeholders. They are not yet enforced — documented here so the intent is clear, not as shipped behaviour:

Naming policy — operationId patterns, path-segment casing, schema casing. (Today you can model many of these as Spectral rules.)
Breaking-change policy — make breaking-change detection a tunable, org-level gate on the publish path. Today breaking changes are recorded but not gated; enforcement lives in your CI.
Required fields — promote today's soft warnings into configurable hard gates.
Versioning rules — semver discipline, major-version path requirements, deprecation soak windows.
Spec sources — constrain where specs may be published from (Git, manual upload, runtime).

See ADR-0026 for the breaking-change-policy direction.