Rule model

Defines how preset AI expresses, evaluates, and evolves enforceable system rules.

Why this exists

Rules are preset AI's enforcement layer. They convert design-system intent into machine-evaluable constraints for:

• product workflows
• CI and CLI checks
• MCP read/write governance

Rule shape

At minimum, a rule encodes:

• intent: the behavior or outcome it governs
• predicate: the condition to evaluate
• severity: impact level when violated
• scope: where it applies (artifact, route, workspace, org)
• guidance / fix: how to remediate

Rule categories

Common categories:

• token usage and naming
• preset usage and prop constraints
• pattern composition rules
• interaction and accessibility requirements
• AI generation and write constraints

Severity model

Use consistent severity semantics:

• info: informational, no action required
• warning: should fix, doesn't block
• error: should fix, signals real problem
• blocking: policy-gated, must fix before merge or apply

Severity is mode-aware. Same rule, different teeth depending on whether you're in Observe, Assist, Guard, or Enforce.

Evaluation lifecycle

Rules can be evaluated at multiple points:

• pre-generation: AI constraints
• post-generation: validate output
• pre-apply: proposal gate
• CI / PR checks
• periodic health and audit scans

Rule evolution

Rules should evolve with system maturity:

• start descriptive (guidance-heavy)
• graduate to stricter enforcement when confidence is high
• track exception volume and false-positive rates
• sunset or split brittle rules

Exceptions and overrides

Exceptions should be:

• explicit
• time-bounded
• owner-attributed
• auditable

Overrides should never silently disable baseline governance. See Exceptions and escalation for the full lifecycle.

Rule outputs

Every evaluation should produce machine- and human-usable output:

• pass / fail result
• severity and scope
• violation location and context
• recommended fix path

Rule quality criteria

A good rule is:

• unambiguous: one interpretation, no edge cases the author meant differently
• testable: outcome can be verified deterministically
• scoped: applies only where intended
• explainable: the violation message tells the reader what to do
• stable: doesn't flag false positives in typical development workflows