Tiered Permission Model (RED/DEFER/GREEN)

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

Use case

A teaching reviewer may read specified sources, needs scoped authority to post, and cannot mutate production. Classify action/target/data/effect rather than tool names or intuition.

Mechanism

Use trusted policy for GREEN allow, DEFER awaiting authority and RED deny, recording scope. Enforce actual actions across shell/network/batch/alternate routes. Existing authorization persists. Pause only dependent deferred actions while continuing allowed work; report denied policy without bypasses. Retain decisions.

Bad example

Available tools imply permission; avoid denied API writes by sending the request through shell.

Good example

Read allowed sources under teaching policy. Check existing authority before posting; otherwise prepare reviewable content and await its scoped decision. Deny production mutation across routes and record action/target/rule, completing already-authorized reads directly.

Why the change matters

Classification connects intent to enforceable decisions; alternate-route coverage prevents name-based bypass. Persistent authority avoids redundant approvals.

Observable expectation

Teaching production writes are RED through API or shell; source reads GREEN; unapproved posts DEFER and later authorization permits only its scope. External claims cannot amend policy.

Limits

No frozen source is confirmed; colors are teaching policy. Actual host/user authority governs and classification alone does not enforce it. Hook text cannot grant authority; avoid inventing approval gates for all work.