These are reference patterns, not customer claims. Each example assumes the consequential application capability is routed through Guard and that the selected authority is current and verifiable.
A blocked result applies to the mediated capability being evaluated. Deployment architecture must still control any alternate route to the same underlying system.
An automated finance workflow proposes an allocation above the threshold defined by its selected authority, but the required approval evidence is absent.
Result: BLOCK — the mediated finance operation does not proceed.
A repository workflow requests a new file while the selected catalog-3 authority grants only modification for the same path scope.
Result: BLOCK — the repository create operation does not proceed.
An identity-management workflow proposes a role change that is not permitted for the current actor under the selected authority.
Result: BLOCK — the mediated role change does not proceed.
A runtime request references a publication whose contract and receipt identities do not match the selected authority reference.
Result: BLOCK — no usable authority is established.
Ledger identifies supported controls and leaves the remaining source meaning explicit for human review rather than silently converting it.
Result: the published authority remains narrower than the original prose when support is incomplete.
An application request matches the actor, action category, target scope, and required runtime facts in the selected authority.
Result: ALLOW — the observed outcome is recorded as runtime evidence.
Waveframe separates proposed work from approved authority. Ledger publishes the reviewed meaning, the compiler turns that meaning into deterministic contracts, Guard mediates the real application call, CRI-CORE evaluates admissibility, and evidence records the resulting boundary outcome.