Rule-Catalog Review (YAML)

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Review a migration with versioned rules: missing required rollback blocks, while a missing summary advises. Teaching SAFE-1 and DOC-1 cannot both become fail-on-any-concern without losing policy meaning.

Mechanism

Establish rule authority, revision, stable IDs, applicability, predicates and failure actions. Validate YAML structure, then execute or manually apply actual predicates. Return pass/fail/needs_review with evidence per rule; unknown does not pass. Aggregate blocking and advisory items separately and retain revision. A keyword in prose is not substantive compliance.

Bad example

Fail whenever the review mentions a concern, or treat the existence of YAML as completed enforcement.

Good example

Evaluate teaching rules-v1: SAFE-1 checks required rollback and fails with block; DOC-1 checks summary and fails with advise. Return rule ID, version, verdict and evidence. Unavailable evidence means needs_review rather than pass. Preserve different actions in aggregation.

Why the change matters

Rule data makes policy, checking and consequences inspectable. Stable identity and version tie decisions to the standards actually used rather than impressions or file presence.

Observable expectation

Teaching configuration:

version: rules-v1
rules:
  - id: SAFE-1
    check: rollback_present
    on_fail: block
  - id: DOC-1
    check: summary_present
    on_fail: advise

Rollback with no summary gives advice; missing rollback blocks; unreadable input needs review. Duplicate IDs and unknown checks produce configuration errors.

Limits

No frozen source is confirmed; this configuration is an independent teaching construction. YAML is neither enforcement nor authorization. Predicates need reliable implementation and semantic checks; rollback effectiveness exceeds mere presence. Projects must define conflicts, scope and permissions.