Operating
Configuring Creance
Risk tiers, device groups, time windows, approval routing — and a 90-day ramp you should actually follow.
Creance is the deterministic engine that decides whether Kestrel may act. It contains no model output. The rules are human-authored, versioned, diffed, and every change is written to Flightlog.
Risk tiers
| Tier | Meaning | Maximum autonomy available |
|---|---|---|
| Tier 0 | Read-only or trivially reversible | Unattended |
| Tier 1 | Reversible service-level change | Unattended |
| Tier 2 | System change with a tested rollback | Unattended, explicit grant only |
| Tier 3 | High blast radius or irreversible | Approval required, always |
Four outcomes
- Execute unattended — Kestrel acts and records it.
- Execute and notify — Kestrel acts and tells a human it did.
- Require approval — a human with a named role decides.
- Never — a hard denial. Deny always wins over any other match.
Precedence
Deny always wins. Otherwise, more-specific scope beats less-specific. The console shows the resolution order on every rule and names which other rules interact with it. Silent precedence is how security policy interfaces cause incidents.
The recommended 90-day ramp
Most customers want permission to go slowly, and you will trust us more for offering it. This is the ramp our design partners follow.
| Weeks | Posture | What you are learning |
|---|---|---|
| 1–4 | Fully Hooded. Nothing executes. | Is the diagnosis right? Compare Kestrel’s recommendation against what your tech actually did. Fix your device correlation rate here. |
| 5–8 | Approve-each on Tier 0 only. | How often do you agree? Watch the historical evidence counts build on the approval cards. |
| 9–12 | Unattended Tier 0 during business hours, on one device group. | What happens with no human in the loop? Read Flightlog daily for the first week. |
| 13+ | Widen by group, then by tier — one change at a time. | Run the simulator before every widening. It replays your own last 30 days against the draft. |
Use the simulator before every change
Before saving any policy change, ask: given this policy, what would have happened over the last 30 days? The simulator replays historical incidents from Flightlog against the draft and shows the itemised diff — how many actions that required approval would now run unattended, how many would now be blocked, and the ten most impactful specific cases.
This turns an anxious abstract decision into an evidence-backed one. Do not widen a rule without running it.
Operational hygiene
- Exclude your executive and VIP device group from unattended execution. Every enterprise does this and there is no downside.
- Set rate limits per device and per group. They are your circuit breaker when a bad vendor push hits 300 machines at once.
- Set time windows in device-local time, not tenant time. A fleet across four timezones with tenant-time windows will act at 3am somewhere.
- Require device health for anything above Tier 0. Acting on an already-unhealthy machine is how one problem becomes two.
- Turn on the second-approver requirement for policy changes if you have a change-advisory board. It maps directly to a SOC 2 control.