For your role

Engineering

Build decision systems whose errors reach someone who can change the rule: a log entry for every decision, permissions that expire, and challenges the system has to answer, written as code, not policy.

Which systems this is for

First steps, in order

  1. Check what a workflow is allowed to decide

    Take one workflow through six questions. Get back the permissions nobody can justify, and whether its decisions can be undone.

    Run the delegation audit

  2. Set deadlines for halts and reversals

    Build in a fixed time to halt, deadlines for reversing a decision, and the receipt each decision has to produce.

    Read the standard on halts and deadlines

  3. Log every decision, and check the log

    Log each decision in the format the decision-record standard (STD-07) sets out, including the permission it ran under. Then check an exported log against the schema and the conformance level you claim.

    Check an exported log

What to run, satisfy, and read

The diagnostics that show risk in this role's work, the standards that apply to it, and the reading behind them.

Diagnostics

Standards

Reading

  • What outcomes hide — Why judging a system by outcomes is not enough: also count what people had to adapt to, and whether they could get errors corrected.

What to attend to, and what to have in place

The parts of the method

  • Log the work the system pushes onto people, how long decisions take, and when cases escalate.
  • Build runtime checks that enforce the standards in production.
  • Agree with the system's owners who maintains it and who can roll it back.

Once you adopt

Each line either exists or does not.

  • Set explicit action boundaries for high-risk automations.
  • Require approvals before sensitive sends, deploys, or data writes.
  • Test rollback paths and confirm they work under real load.
  • Log all override actions with named owners and timestamps.

Other roles

If that was not you

  • Policy and compliance — You write the rules the system has to satisfy, or prove to a regulator that it does.
  • Audit and assurance — You verify someone else's claims from the evidence their system emits.
  • Operations — You run the appeals, the incident response, or the queues where the system's errors land.
  • Design — You shape the interface where a person meets the decision.
  • Research — You study these systems and publish about them.
  • Executive — You decide whether to deploy, and you carry the liability when it goes wrong.