Risk tiers
Set how carefully each kind of change is handled, from a typo fix to a schema change. kanman puts every change on a tier, shows it on the story and holds to the tier where it starts work and merges.
Not every change needs the same care. Risk tiers let you say, once, what each kind of change needs before it ships. kanman puts every change on a tier and works by that tier’s rules.
Where you start
Every team starts with kanman’s three standard tiers. At first they are shown only: kanman puts each change on a tier and notes what it would have held back, but holds nothing back.
| Tier | For example | What kanman may do | What it needs |
|---|---|---|---|
| Routine | Docs and comments, copy changes, a small fix inside one module | Works on its own | Automated checks and an independent review |
| Standard | A new endpoint, a changed workflow, a dependency update | Works on its own | One person approves the merge request |
| Sensitive | A schema change, an infrastructure change | Starts once a lead approves the plan | One person approves the merge request |
Two rules hold from the start: when the tier is unclear, the higher one applies, and kanman has no access to production systems.
Set your own tiers
Tell kanman in the team chat how your organisation wants changes handled, in your own words. kanman turns it into tiers and proposes them as one card that shows what changes compared with today, line by line. A workspace admin applies it for the whole workspace, a lead for one team, each with one tap, and either can undo it the same way. A team can make the workspace’s tiers stricter, never looser.
For example, Example Corp tells kanman: “Two levels. Anything under ops/ or touching infrastructure is guarded: kanman only proposes, two people approve and a person merges. Everything else is normal.” kanman proposes a policy with two tiers, Normal and Guarded, and the path and infrastructure signals that put a change on Guarded.
Each tier can say:
- What kanman may do: work on its own, start once a plan is approved, or only propose (a draft merge request or a runbook).
- Who approves the plan: a team member, a lead, an admin or a named person, and whether the plan must link a documented design decision.
- How many people approve the merge request, and whether the reviewer must be someone other than the plan’s approver.
- Whether a person reviews what the tests really test, or what users will see (with kanman’s screenshots).
- Whether people merge and deploy instead of kanman.
- What puts a change on the tier at least: paths, and what the change shows, such as a migration, sign-in code, cryptography, secrets, infrastructure, a weakened or empty test, or a change to what users see.
Rules for every change are available too, and off until you turn them on: a person releases every change, each merge request explains the change in plain words, customer-facing changes pass their readiness checks first, and a prototype label for repositories, branches or stories.
What you see
- On every story, one quiet chip with its tier. Hover or tap it to see why: kanman’s reasons and what the change showed.
- In the merge request, the tier with its reasons and a label, for the tiers where you want it.
- In the chat, kanman’s plan as a question pinned for the people who may approve it. When kanman holds something back, it says what is needed next.
- In Team settings, under Budget and limits › Risk tiers, your tiers as a short ladder.
How the tiers hold
kanman reads every change itself. When a change shows more than first thought, its tier goes up and work pauses until the plan is approved again. Once your tiers are in force, kanman starts no coding before an approved plan where a tier asks for one, merges only with the approvals the tier needs (from different people, never bots), and leaves to people what a tier reserves for them. Each change’s record, with its tier, reasons, approvers and checks, is kept for your audits. See Audit export.
Related pages
Last updated: January 1, 0001
Open kanman