Skip to content

Operating pattern

Policy check before action

Check policy immediately before action, then require a permitted next step when the proposed action is changed or stopped.

Use when

A recommendation may be analytically sound yet impermissible when authority is exercised.

Operating contract

Authority, evidence, and stopping conditions.

Job to control
A reasonable recommendation can still violate policy when it is put into action.
Division of work
The pack proposes an action. A policy check returns allow, modify, flag, or block. The pack continues, changes course, or hands off.
Control point
Run the applicable policy at the consequential action and make every intervention return an executable next state.
Evidence retained
Proposed action, policy and version, allow/modify/flag/block result, effect on the action, and exception owner.
Human ownership
Own policy, approve exceptions, and review interventions that materially change the outcome.
Trade-off
A late gate can create rework; an early-only gate can miss changed context. Place it where authority could actually be exercised.

Case sequence

  1. 01

    Propose action

  2. 02

    Apply policy

  3. 03

    Allow or intervene

  4. 04

    Choose a permitted next step

  5. 05

    Record the effect

Failure watch

Control intent and failure modes.

Control intent

Controls that arrive after the fact and packs that continue after an action has been stopped.

Failure modes

  • 01Checking too late
  • 02Treating a stopped action as a system failure
  • 03Claiming one example proves a control works everywhere

Applied in Cadre

Packs using this operating design.

Each pack narrows the pattern to a specific financial-services decision and names the seam that remains under human review.