Rejected Ambiguous Scalars
To avoid YAML 1.1/1.2 resolver differences, v1 rejects ambiguous scalar-looking values in string fields:
- Boolean/null words (
yes,no,null) - Timestamp-like values (
2026-08-11) - Numeric forms: sexagesimal (
1:20), leading-zero (012), hexadecimal (0x1f), octal (0o12), exponent notation
Policies must use explicit, quoted identifiers. This eliminates cross-runtime ambiguity.
Controlled Condition Surface
The policy language supports a bounded set of condition types — keeping it analyzable and implementable in both Python and Rust without a full regex engine or filesystem access:
| Condition Type | Description |
|---|---|
args_match |
Portable pattern grammar (not regex). Supports literals, ., * applied to preceding, boundary anchors ^/$, and escaping \, ., *, ^, $ |
path_pattern |
Lexical pattern matching. * matches any character sequence including /. Does NOT resolve links, normalize paths, or act as sandbox boundary |
time_window |
Absolute UTC windows with inclusive start, exclusive end (start <= now < end) |
Decision Priority (Deterministic Chain)
When multiple rules match, resolution follows this chain:
- A matching
denywins across scopes - Otherwise, the rule with the most target fields wins (most specific)
- Equal-specificity rules use action priority:
require_approval > throttle > redirect > allow > log - Remaining ties retain YAML declaration order
- If no rule matches,
global.default_actionapplies (defaults toallowif omitted)
Why These Constraints Matter
- Determinism: No hidden regex behavior or filesystem access
- Cross-runtime implementability: Same logic in Python and Rust
- Analyzability: Policy decisions are predictable and auditable