Decisions
Everything that needs a human lands in one place: the decision inbox. Each decision comes with kanman's recommendation and a few clear options.
kanman works on its own until it reaches something it should not decide alone. Then it stops and asks. All of these questions land in one place, the decision inbox, so nobody has to watch chat threads, PR comments and tracker notifications to find out what kanman is waiting for.
Open Decisions in the main navigation. The badge shows how many decisions are pending. Each decision has its own page at app.kanman.ai/<workspace>/decisions/<decision-key>, for example dec-4h2k.
What a decision looks like
Every decision has:
- a title that says what is being asked, for example Raise budget for this run?
- a body with kanman’s reasoning and the context: the story, the run, the gate output or the policy rule involved
- a recommendation: the option kanman would choose, shown after I recommend:
- 2 to 4 options, each one a concrete action
kanman writes “I” in decisions. It is one teammate, not a group of bots.
The inbox has the tabs Pending and Resolved and can be filtered by kind and sorted by age. Weekly team reports you have not opened yet are shown above the tabs.
Kinds of decisions
| Kind | When it comes up | Options |
|---|---|---|
| Plan approval | The policy requires approval of the plan before code | Approve plan, Request changes, Reject |
| Policy exception | A run needs something the policy denies, for example a denied path or a repository that is not allowed | Allow once, Reject |
| Question | The executor asked a question it cannot answer from the story | The answers kanman offers, or Answer and Stop this run |
| Budget stop | A run reached its budget | Raise to twice the run budget, Abandon |
| Scope change | The change is larger than max_changed_files or max_changed_lines allow |
Narrow the change, Allow this size once, Reject |
| Check failed | kanman could not write an acceptance spec that runs, fails before the change and tests the real app | Write the spec again, Keep it in Refining |
| Verification failed | The rework attempt failed the gate as well | Retry once more, Abandon the run |
| Diff guard | The implementation changed the acceptance spec | Revert spec changes and retry, Reject |
| Repeated gate failure | A gate failed more often than the failure budget allows | Retry with my guidance, Retry as is, Stop this run |
| Merge approval | All checks passed, but the change is larger than the auto-merge limit | Merge, Do not merge |
| Main branch is red | CI on your main branch turned red; kanman holds its automatic merges | Keep holding merges while main is fixed, Release the merge hold |
| Revert approval | A pull request from a kanman run is the likely cause of a red main branch, and kanman opened a revert | Merge the revert pull request, Close the revert and fix forward |
| Maintenance proposal | A maintenance finding is not on the team’s allowlist | File as story, Dismiss |
| Strategy proposal | Maintenance mode proposes a feature based on your STRATEGY.md |
Start intake, Decline |
A decision is never created for transient failures such as a network error; kanman retries those on its own (see Runs).
Note
Decision titles, bodies and most option labels are written in English for now. The options of plan approvals, policy exceptions, scope changes and budget stops follow your language setting.
Example: a denied path
The Balanced preset denies infra/**. If a run’s change touches infra/alarms.tf, the run stops with status Blocked by policy and the run page says Path infra/alarms.tf is not allowed by policy Balanced. The decision offers Allow once and Reject, and kanman recommends Reject: the rule exists for a reason, and an exception only applies to this run.
If you choose Reject with the note “Infra changes go through ops”, the run ends and the story returns to Backlog with your note as a comment. The audit log gets a policy_decision entry with the result denied and a decision_resolved entry with your name.
Who can answer
Every member of the workspace can answer decisions. Options that end or reject something ask for an optional note before you confirm; approvals take one click. Answers record who decided, when, how (the app, Slack, MCP or the API) and the note.
When you answer, kanman continues right away: a plan approval starts implementation, a raised budget resumes the run, a rejection returns the story with your note.
What kanman decides alone
Not every choice is a decision for you. kanman sorts each choice into one of three authority levels:
- AUTO: it acts and logs it.
- NOTIFY: it acts and records a notice.
- ESCALATE: it stops and asks in the decision inbox.
The table is fixed and deterministic, and a team can only make kanman more careful, never less. See Policies, presets and authority levels.
Statuses
| Status | Meaning |
|---|---|
| Pending | Waiting for an answer. Decisions do not expire; the run waits until someone answers |
| Resolved | Answered |
| Superseded | No longer needed because the situation resolved itself, for example main turned green again |
Notifications
kanman tells you about new decisions in two ways:
- the badge on Decisions in the app
- a message in the team’s Slack channel with buttons to answer, if your workspace has Slack connected. See Answer decisions from Slack
You can also answer a decision on the team’s Intake page or in a Slack thread by replying, for example “approve dec-4h2k”.
Related
Last updated: January 1, 0001
Open kanman