Stage-gate model

Purpose

This document describes the AI Conveyor stage-gate model: which stages an initiative passes through, which checks are performed before a transition, which management decisions are made, and what data they rely on.

The model relies on the platform: the business funnel of initiatives, AI product delivery tracks, configurable transition rules, required fields, the similar-initiatives check, tasks, artifacts, and analytics.

Who approves decisions — in the decision framework. Gate logic, criteria, and decision types — on this page.

Core ideas

• Stage — the state of an initiative in the business funnel: new, assessment, delivery, awaiting impact, support, closing, or rejection.
• Stage gate — a check before moving to the next stage. It must be clear, verifiable, and known to participants in advance.
• Transition rule — a platform setting that determines which stage can be moved to from which.
• Required fields — the minimum set of data without which a decision cannot be considered manageable.
• Delivery funnel — the delivery stages within a selected AI product. These stages may differ across AI products.
• Decision — the recorded outcome of a stage gate. At each gate an initiative can have one of four outcomes:
  • advance — the initiative is ready for the next stage;
  • rework — there is potential, but data, an owner, an AI product, or artifacts are missing;
  • stop — the initiative is weak, risky, duplicative, or lacks impact;
  • scale — the result is confirmed and applicable beyond a single process.

A decision must rely on the initiative card, tasks, checks, artifacts, and portfolio analytics.

How it works

An initiative moves along the business funnel:

1. 1New
2. 2Assessment
3. 3Delivery
4. 4Awaiting impact
5. 5On support / Closed

An initiative can be rejected if the value is not confirmed, the risk is too high, there is no data, there is no owner, or there is higher-priority work.

In the platform, these stages correspond to the states NEW, ASSESSMENT, DELIVERY, AWAITING_EFFECT, ON_SUPPORT, CLOSED, and REJECTED.

Stage gates are configured by the AI office administrator through transition rules, required fields, and field visibility. For the transition to delivery, the platform already supports important checks: a product must be selected, the similar-initiatives check must be completed, and the preliminary security review must not have a negative result.

Lifecycle details are covered in the initiative lifecycle.

Stage gate	Related stage
Gate 1	New
Gate 2	Assessment
Gate 3	Delivery
Gate 4	Awaiting impact
Gate 5	Support or closing

---

Stage-gate map

Stage gate	Transition	Key question	Minimum criteria	Decision owner
Gate 1. Registration	problem → new initiative	Is the idea worth recording in the portfolio?	There is a problem, an initiator, a brief description, and an expected impact type	AI office or department head
Gate 2. Admission to assessment	new → assessment	Is there enough data to analyze the initiative?	Basic fields are filled in, the owner is clear, there is no obvious duplicate	AI office
Gate 3. Admission to delivery	assessment → delivery	Is it worth spending team and AI product resources?	An AI product is selected, the similar-initiatives check is done, security has not rejected it, there is an impact hypothesis and a priority	Committee or assigned owner
Gate 4. Start of awaiting impact	delivery → awaiting impact	Is the solution deployed enough to measure the result?	Delivery is complete, there is a process owner, metrics are defined, and the impact review date and data source are set	Initiative owner together with the AI office
Gate 5. Closing or support	awaiting impact → support/closed	Is the impact confirmed and is it clear what to do next?	Actual impact is calculated, there is a decision on closing, support, scaling, or rework	Business owner, finance, AI office
Rejection	any early stage → rejected	Why are we not continuing the initiative?	A reason is stated, the decision history is preserved, and a return or review is proposed if needed	Owner of the current stage

---

Data for the decision

Minimum data at a stage gate:

• a description of the business problem;
• expected impact;
• initiative owner;
• AI product;
• result of the similar-initiatives check;
• priority;
• data and security constraints;
• tasks and delivery status;
• impact review date;
• actual result after adoption.

If the data is insufficient, the correct decision is not to "move forward," but to return the initiative for clarification.

---

Gate 1. Initiative registration

The goal is not to prove value, but to record the idea so that it is not lost and can be assessed.

Minimum input:

• a business problem;
• an initiator;
• a department or process;
• a brief description of the idea;
• a preliminary impact type.

Outcome:

• an initiative card is created;
• the stage is set to "New";
• the initiative is added to the portfolio;
• an initial set of tasks is created if needed.

---

Gate 2. Admission to assessment

The goal is to separate the raw stream of ideas from initiatives worth analyzing in substance.

Minimum criteria:

• the problem is described through a process and a metric;
• there is a business owner or a clear candidate;
• the expected value is stated;
• the initiative is not an obvious duplicate;
• there is no explicit prohibition from security or data.

Decisions:

• move to assessment;
• return for clarification;
• reject with a reason;
• merge with a similar initiative.

Platform support:

• the initiative card;
• the similar-initiatives check;
• required fields by stage;
• the transition history.

---

Gate 3. Admission to delivery

This is the key stage gate. This is where the initiative stops being an idea and starts consuming team, product, and infrastructure resources.

Minimum criteria:

• an AI product is selected;
• the similar-initiatives check is done;
• the preliminary security review does not have a negative result;
• the impact hypothesis is clear;
• a priority is stated;
• a project lead or person responsible for moving it forward is assigned;
• the immediate delivery tasks are defined.

In the platform, the transition to delivery should be blocked if an AI product is not selected or the mandatory similar-initiatives check is not done. If the preliminary security review has a negative result, the initiative should not proceed to delivery without a separate decision.

Decisions:

• admit to delivery;
• send back to rework the assessment;
• change the product;
• defer due to lack of resources;
• reject.

---

Gate 4. Start of awaiting impact

The goal is to make sure the solution is not just developed, but ready to verify the result within the business process.

Minimum criteria:

• the required stage of the delivery track is complete;
• the solution is available to users or embedded in the process;
• a process owner is assigned after rollout;
• the baseline value, target value, and actual metrics source are defined;
• the impact review date is stated;
• operational constraints and risks are recorded.

Decisions:

• move to awaiting impact;
• keep it in delivery for rework;
• move to support without impact only as an exception;
• reject the delivery if the solution is not fit for use.

Platform support:

• the product delivery track;
• the initiative tasks;
• the expected impact date;
• analytics on overdue initiatives awaiting impact.

---

Gate 5. Closing, support, or scaling

The goal is not to close a card for the sake of a clean registry, but to make a management decision based on the actual result.

Minimum criteria:

• the impact is calculated using an agreed methodology;
• it is clear which part of the impact is attributable specifically to the initiative;
• the financial or business owner has confirmed the calculation;
• a decision is made on the further mode: close, support, scale, rework, or stop.

Decisions:

• close as a goal achieved;
• move to support;
• scale to other processes or departments;
• return to delivery for rework;
• close without confirmed impact, with a reason.

---

Rejecting an initiative

Rejection is a normal outcome of AI Conveyor. The system should screen out weak, risky, and duplicate initiatives before they start consuming resources.

Typical reasons:

• the business problem is not confirmed;
• there is no owner;
• the impact is too small;
• there is no available data;
• a duplicate is found;
• the security or compliance risk is too high;
• there is no suitable AI product;
• the initiative does not pass the portfolio priority.

If the required rejection-reason field is enabled in the settings, the platform should require a reason to be filled in before moving to the rejected state.

---

Rules of a good stage gate

A good stage gate and a good decision at it:

• checks readiness for the next stage, not the form;
• has a decision owner;
• relies on card data, tasks, and artifacts;
• can be verified in the platform;
• does not require an unnecessary committee for obvious decisions;
• leaves a trace in the initiative history;
• is understandable to any participant a month after it was made;
• has explicit criteria and affects the next step.

A bad stage gate and a bad decision:

• requires a document for the document's sake;
• has no explicit criteria;
• depends on a verbal agreement;
• lets through initiatives without an owner and metrics;
• blocks progress without a clear reason;
• is made verbally, without a reason or link to the card;
• depends only on the initiator's status;
• leaves no trace in the system.

---

Minimum configuration in the platform

For a working version of the conveyor, it is enough to configure:

• the allowed business-funnel transitions;
• the required fields for the "Assessment," "Delivery," and "Awaiting impact" stages;
• the rule for selecting a product before delivery;
• the rule for the mandatory similar-initiatives check;
• the rejection-reason rule;
• field visibility by stage;
• product delivery tracks for the key AI products;
• the list of roles allowed to change an initiative's stage.

Even this minimum already turns a registry of ideas into a manageable mechanism for selection, delivery, and impact confirmation.

Link to AI ConveyorMethodologyAI Conveyor

The role of the AI assistant

The AI assistant can prepare recommendations at a stage gate:

• which fields are not filled in;
• gather missing fields through a dialogue;
• bring a vague description into the structure of a card;
• why the initiative is similar to another;
• which AI product may fit;
• which risks are worth checking;
• what is blocking the transition;
• how to phrase the decision for the stage gate;
• propose a problem statement and an impact hypothesis.

But the final decision is made by a person or a designated body. The AI assistant must not substitute for the decision owner or approve transitions on its own.

More about the platform