Built-in rules are versioned and documented. Custom rules are data: a path selector plus allowlisted assertions, compiled and run inside the validation worker.
Policy
Policies change only the rules layer. Syntax and schema severities are fixed. Every override is shown on the finding and recorded in reports.
Plain scalars such as yes, no, on, off, y, n are booleans in YAML 1.1 but strings in YAML 1.2. Tools on different versions read different data (the "Norway problem": country: no).
portability
deterministic
warning
warning
Leading-zero numbers octal-ambiguity v1.0.0
Plain numbers with a leading zero (0755) are octal in YAML 1.1 and decimal in YAML 1.2 core.
portability
deterministic
warning
warning
Base-60 numbers sexagesimal-ambiguity v1.0.0
Values such as 1:30 or 22:22 are base-60 integers in YAML 1.1 (90, 1342) and strings in YAML 1.2. Classic port-mapping trap.
portability
deterministic
warning
warning
Other version-dependent scalars profile-divergence v1.0.0
Any other plain scalar that resolves to a different type or value under YAML 1.1 vs 1.2 (e.g. 1_000, timestamps, .5).
portability
deterministic
info
info
Merge key under YAML 1.2 merge-key-profile v1.0.0
<< is a merge key only in YAML 1.1 (or with merge keys enabled). Under 1.2 core it is a plain key literally named "<<".
portability
deterministic
warning
warning
Implicit null values empty-value v1.0.0
A mapping key with no value resolves to null. Often an editing accident.
hygiene
deterministic
info
info
Unused anchor anchor-unused v1.0.0
An &anchor is defined but never referenced by an *alias.
hygiene
deterministic
info
info
Redefined anchor anchor-redefined v1.0.0
The same anchor name is defined twice; later aliases silently refer to the newest definition.
hygiene
deterministic
warning
warning
Non-string keys non-string-key v1.0.0
Mapping keys that resolve to numbers, booleans or null. JSON, many config loaders and JSON Schema need string keys.
portability
deterministic
info
info
Possible secret secret-hint v1.0.0
Heuristic patterns for credentials (AWS keys, private key blocks, GitHub/Slack tokens, password-like keys with literal values). False positives and false negatives are expected; this is a hint, not a secret scanner. Nothing leaves your browser.
safety
heuristic
warning
warning
Custom rule pack — declarative DSL v1
No custom pack. Load the example to see the format.
DSL reference
select: dot path with * (any key/item), ** (any depth), [n] or [*], and "quoted.keys". Example: spec.template.spec.containers[*].image.
assert operators: require, forbid, type, equals, in, notIn, matches, notMatches (ECMAScript regex, u flag, ≤256 chars), min, max, minLength, maxLength, minItems, maxItems, minKeys, maxKeys, unique, uniqueBy, nonEmpty, and combinators all, any, not. Optional when (same operators) limits which matches are checked; expectMatches {min, max} counts matches.
message may use {value}, {path}, {key}, {reason}, {count}. tests: list of {name, yaml, expect: {ruleId: count}}.
Limits: 200 rules, nesting depth 8, 200,000 evaluated nodes per document, worker time budget. Unknown fields or operators reject the whole pack.
Suppressions
None. Add one from a finding’s explanation panel; a reason is required.
Questions
Can a custom rule run code or fetch something?
No. The pack is parsed as YAML and validated against a fixed set of fields and operators. Regular expressions are length-limited and run in a worker that is terminated after the time budget.
Is my YAML uploaded anywhere?
No. Parsing, schema validation, rules, fixes and reports all run in your browser (validation runs in a Web Worker). There is no backend, no account and no content analytics. Drafts and history are stored only in this browser’s IndexedDB, and you can clear them or switch to memory-only mode.