Decision Framework
Purpose
This document sets out who makes decisions in the AI Conveyor and at what level: on initiative transitions, portfolio priorities, resources, exceptions, risks, and impact confirmation.
The goal of the framework is to remove ad-hoc "let's sort it out in chat" and replace it with a clear system: a decision has an owner, criteria, a trail on the initiative card, and consequences for the portfolio.
Core ideas
- A decision must be tied to a stage. For a new initiative, a decision by the AI office is enough, while before delivery a stricter control is required.
- Transitions must be verifiable. If a rule can be expressed through a mandatory field, a similar-initiative check, or the chosen product, it should be configured in the platform.
- A committee must not replace criteria. A collegial body is needed for contested and costly decisions, not for every card movement.
- Rejection is a normal outcome. The conveyor should cut off weak, duplicate, and risky initiatives before they consume the team's resources.
- Exceptions are acceptable, but must leave a trail. If an initiative is allowed through against a rule, the reason and the exception owner are recorded.
How it works
Decisions are made at three levels:
| Level | Which decisions it makes | Where it is reflected |
|---|---|---|
| Operational | creating an initiative, clarifying the card, assigning tasks, returning for rework | initiative card, tasks, change history |
| Portfolio | priority, admission to delivery, resource allocation, deferred initiatives | business funnel, prioritization matrix, analytics |
| Control | risk, security, data, architecture, exceptions, impact confirmation | stage gates, artifacts, sign-offs, impact report |
Related sections: stage gate model, value realization.
Decision matrix
| Decision | Who prepares | Who approves | Minimum conditions |
|---|---|---|---|
| Create an initiative | Initiator or AI assistant | Initiator / AI office | There is a problem, a description, and an expected type of impact |
| Move to assessment | AI office | AI office or domain lead | The card is sufficiently filled in, there is no obvious duplicate |
| Choose a product | AI office, product owner | Product owner or AI office | The product fits the task class and has a delivery route |
| Admit to delivery | AI office, project lead | Portfolio committee or designated owner | There is a product, a similar-initiative check, an impact hypothesis, and no negative security decision |
| Change priority | AI office | Portfolio committee / sponsor | There is a rationale for value, urgency, and resources |
| Reject an initiative | Stage owner | AI office or decision owner | A rejection reason is given |
| Move to awaiting impact | Project lead | Business owner and AI office | The solution is adopted, metrics and the impact review date are defined |
| Close an initiative | Business owner | AI office / finance for significant impact | The impact is calculated or the closure reason is recorded |
| Accept an exception | Exception initiator | Governing body or sponsor | There is a risk, a reason, a validity period, and an accountable owner |
Connection to the platform
In the platform, decisions are supported through:
- the business funnel of initiatives;
- permitted transitions between stages;
- mandatory fields by stage;
- checks for similar initiatives;
- preliminary security review;
- product selection and the product delivery track;
- initiative tasks;
- roles and access rights;
- portfolio and risky-initiative analytics.
A stage change must not happen by simply editing a card field. It must go through a controlled transition, so that the system can apply the rules and preserve the history.
Rights and accountability
Minimum accountability model:
- the initiator is accountable for the initial description of the problem;
- the business owner is accountable for the significance of the problem and impact confirmation;
- the AI office is accountable for card quality, funnel rules, priorities, and methodology;
- the project lead is accountable for advancing the initiative and the tasks;
- the product owner is accountable for feasibility within the product;
- security is accountable for constraints on data processing and solution use;
- the architect is accountable for integration, reliability, and conformance to the target architecture;
- finance confirms significant economic impact;
- the portfolio committee resolves conflicts of priorities, resources, and exceptions.
Exception rules
An exception is permission to move an initiative forward despite an unmet standard rule.
An exception is acceptable only if:
- an exception owner is named;
- a reason is described;
- a validity period is defined;
- the risk is clear;
- there is a compensating action;
- the decision is saved in the initiative's history.
Examples of acceptable exceptions:
- a strategic initiative moves to assessment with an incomplete financial model;
- delivery starts before the final architectural sign-off, but only in an isolated environment;
- the impact is reviewed later due to process seasonality.
An unacceptable exception:
- letting an initiative into delivery without a product, an owner, a similar-initiative check, and an understanding of the data.
Anti-patterns
A bad decision model looks like this:
- all decisions are made by one person without criteria;
- a committee convenes for every minor card;
- transitions are done manually without history;
- rejection reasons are not recorded;
- initiatives get high priority because of the initiator's status;
- security and architecture are only brought in right before launch;
- impact is confirmed with "users liked it".
A good decision model does the opposite: it sets criteria in advance, automates simple checks, and leaves the human decision where there is genuine uncertainty.