As code means the lifecycle. Not the language.
Versions, review, promotion, rollback, an audit trail. Borrowed from software, which solved this decades ago. It does not mean someone has to write a program to change a threshold.
Rules only, so changing one needs no release.
Read this and tell us what it does
first_time_destination_review:
all:
- path: "event.type"
op: eq
value: "transfer_intent"
- path: "event.data.destination_known"
op: eq
value: false
- path: "event.data.amount_usd"
op: gte
value: "{{ constants.unknown_destination_amount_floor }}"
effects:
verdict: flagged
response:
reason: "First-time destination above threshold"
actions:
- action: unknown_destination_case You just did, and you are not an engineer on this project. That is the entire argument. Conditions on the event, a verdict, a reason the user will see, and the case it opens.
If you have looked at a policy engine before, you have seen the other kind: policy is a programming language, and every threshold change is a ticket. That is why your rules are out of date: the person who knows what the rule should say cannot write it, and the person who can is working on something else.
Who is allowed to do what
| Right | Typically held by |
|---|---|
| Edit a draft | the policy owner: risk, compliance, trust and safety |
| Move it to candidate and measure it | the same person |
| Promote it to production | a separate right, granted separately |
Every edit is recorded against the person who made it.
Still readable to your engineers
It is a text file. It lives in your repository if you want it to, gets reviewed in a pull request if that is how you work, and diffs like anything else.