Governance artifacts you can adopt as-is

# Decision record template

Assigns a named decision owner, reversal power, burden limit, and appeal path.
No system output goes out without someone who answers for it.

## What it commits you to — record how each one is met

- [ ] Every decision has a named owner.
      Evidence:
- [ ] Who can reverse a decision is explicit.
      Evidence:
- [ ] A challenge has a deadline for an answer and a stated procedure.
      Evidence:

## How to use

1. Fill this out before deployment for any decision that can cut off someone's benefit, care, housing, credit, or pay.
2. Put the way to challenge the decision on the screen or letter that delivers it.
3. Treat the reversal deadline as an operational commitment, not a target.

If no one will sign as the owner, the decision has none, and nothing it decides should go out.

# Reversal deadline template

Sets the longest a decision may stay wrong after someone has challenged it.
Reversal is treated as an operating requirement.

## What it commits you to — record how each one is met

- [ ] Error states must be recoverable within bounded time.
      Evidence:
- [ ] Escalation is clock-driven, not discretionary.
      Evidence:
- [ ] "Pending" cannot be unbounded.
      Evidence:

## How to use

1. Set a reversal deadline for each decision class, and say what event starts its clock.
2. Define escalation steps for when a deadline is missed.
3. Publish internal dashboards for time to reverse and time in harm.

If you cannot set a deadline for a decision class, nothing bounds how long a wrong decision in it can stand.

# Halt authority table

Defines who can halt a system or one of its decision paths, who can pause a single case, under which conditions, and on what timeline.
Includes the escalation ladder: who is reached next, and by when, if the first role does not act.
Stoppability becomes an authority a named role holds and can use.

## What it commits you to — record how each one is met

- [ ] Halt authority is explicit and role-bound.
      Evidence:
- [ ] Halt conditions are pre-declared.
      Evidence:
- [ ] Escalation occurs by clock, not permission.
      Evidence:

## How to use

1. Assign halt roles and backup roles, and the escalation step above each.
2. Define the halt criteria for each failure state, and the kill switch or other mechanism that carries out each halt.
3. Run a tabletop where the first move is a halt.

If a halt needs someone's permission first, name that person. They hold the halt authority, whatever the table says.

# Challenge playbook

Defines what counts as a challenge, what evidence rules apply, and how resolution is time-bounded.
What can be challenged, by whom, and how is defined in operational terms.

## What it commits you to — record how each one is met

- [ ] Challenges are recognized as system inputs.
      Evidence:
- [ ] Evidence rules are explicit and consistent.
      Evidence:
- [ ] Time bounds are binding.
      Evidence:

## How to use

1. Define "challenge" in operational terms.
2. Set evidence rules that do not require perfect legibility.
3. Bind the challenge queue to the reversal deadline and its clock.

If you cannot say what counts as a challenge, any challenge can be handled as a complaint and closed.

# Harm receipt format

Specifies what you owe a person your system got wrong: an admission, the reasons, the remedy, and the date it arrives.
An unanswered error counts as a missed deadline.

## What it commits you to — record how each one is met

- [ ] Repair obligations are explicit.
      Evidence:
- [ ] The person gets a remedy by a stated date.
      Evidence:
- [ ] The person does not have to prove the system wrong.
      Evidence:

## How to use

1. Issue a harm receipt whenever you find a decision that hurt someone was wrong.
2. Include remedy path, time bounds, and escalation contact.
3. Log harm receipts as governance events, not support tickets.

If an error cannot be given a receipt, the person it harmed has nothing to cite when they ask for the remedy.