> ## Documentation Index
> Fetch the complete documentation index at: https://docs.jaasskills.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Level model

> Modeled on CIS Benchmark tiering and GitHub's secret-scanning split

Guardrails run as a genuinely separate service — its own repo, its own REST API (`GET /catalog`, `POST /scan`, `GET /healthz`) — with no scanning logic or rule catalog vendored into the registry. Structural validation confirms a package is well-formed; guardrails are a second, independent gate for *content* risk that runs immediately after, before any archive is written.

| Level              | Directory             | Posture                                                      | Enforcement |
| ------------------ | --------------------- | ------------------------------------------------------------ | ----------- |
| **1 — Baseline**   | `level-1-baseline/`   | Every publish, no opt-out                                    | `BLOCK`     |
| **2 — Standard**   | `level-2-standard/`   | On by default; a tenant admin may disable individual checks  | `WARN`      |
| **3 — Advanced**   | `level-3-advanced/`   | Off by default; opt-in                                       | `WARN`      |
| **4 — Regulatory** | `level-4-regulatory/` | Off by default; opt-in; heavier, lower-confidence heuristics | `WARN`      |

Only Level 1 rules may set `mandatory: true`. The guardrails service itself force-runs every mandatory rule regardless of what a caller's `/scan` request asks for — a caller can never disable one by omission or bug, because enforcement lives in the service, next to the catalog, not in the caller.

The registry owns a separate, narrower thing: *which configurable checks a tenant has opted into* (file-backed per-tenant guardrail policy) — a tenant-administration concern tied to its own auth/RBAC model, not something the content-scanning service needs to know about.