Skip to content

Operating pattern

Test before changing operations

A pack may propose an operating change; a separate backtest determines whether the evidence supports it.

Use when

An operating pack can propose a change but must not validate or adopt its own proposal.

Operating contract

Authority, evidence, and stopping conditions.

Job to control
Optimization can make an operating metric look better while silently weakening coverage or control performance.
Division of work
One step proposes a change. A backtest compares it with non-negotiable limits. Only clear support can produce an adopt recommendation; people still control any production change.
Control point
A separate backtest and non-negotiable limits determine whether the committed proposal may advance.
Evidence retained
Committed candidate, comparison basis, limit results, limitations, recommendation, and accountable approval.
Human ownership
Approve production change and decide marginal results or changed risk appetite.
Trade-off
The gate slows iteration and is useful only when the test represents the control outcome the change must preserve.

Case sequence

  1. 01

    Propose change

  2. 02

    Run the backtest

  3. 03

    Check hard limits

  4. 04

    Record a recommendation

  5. 05

    Preserve the test record

Failure watch

Control intent and failure modes.

Control intent

Self-certification, metric gaming, and trading away a costly true positive for lower workload.

Failure modes

  • 01Letting the proposer judge its own work
  • 02Optimizing a proxy
  • 03Automatically adopting a marginal result

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.