Policy as code means your rules get the same lifecycle as your software.
Your rules get the change control software has had for decades: versions, review, promotion, rollback and an audit trail. Nobody has to write a program to change a threshold.
Built into the Swiftward service you run. A changed rule goes live when you promote it, without redeploying Swiftward.
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 Three conditions on the event, a verdict, a reason the user sees, and the case it opens. You can read it without being an engineer, and the person who owns the policy can write it.
In many policy engines, policy is a programming language, and every threshold change is a ticket for an engineer. That is why your rules are out of date: the person who knows what a 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.