Skip to main content
Category: Model Lifecycle & MLOps

Concept Phase

Also known as: Concept Stage, Concept Design Phase
Simply put

The concept phase is typically the first phase of a project, where an initial idea is developed and examined to determine whether the project is worth pursuing. During this phase, the design and key characteristics of the proposed product or project can still change substantially before later commitments are made. It generally covers early tasks such as defining the concept, justifying the project, and checking that it aligns with broader goals.

Formal definition

In many project and engineering lifecycle models, the concept phase is the initial phase in which ideas are refined from first thought into a viable project and assessed for whether the project should proceed. As commonly defined, it may encompass the project concept, the business case or justification, and strategic alignment, and in some frameworks feeds into subsequent feasibility, definition, and development activities. It is characterized by high design flexibility, as aspects such as function, materials, and detailing remain subject to change before decisions are locked in during later stages. Note that phase terminology and boundaries vary across methodologies and sectors; this entry reflects general project-management and engineering usage in the cited evidence and does not describe any AI-specific or regulatory definition.

Why it matters

The concept phase matters because decisions made at the outset of a project shape everything that follows, and the flexibility available at this stage rarely returns once later commitments are made. As reflected in the cited evidence, aspects such as a product's function, materials, colour, aesthetic, and detailing remain open to change during the concept phase, but once a design is chosen in later phases it typically cannot be altered without significant cost or disruption. This makes the concept phase the point of greatest leverage for influencing outcomes at the lowest cost of change.

Establishing whether a project is worth pursuing at all is a core purpose of this phase. By examining the project concept, its justification or business case, and its strategic alignment before substantial resources are committed, organizations can avoid advancing initiatives that do not align with broader goals. Getting this evaluation right early reduces the likelihood of committing to work that later proves unviable.

Note that the concept phase as described here reflects general project-management and engineering usage. It is not an AI-specific or regulatory construct, and readers should not assume that the phase boundaries or terminology described here map onto any particular AI governance or model risk management lifecycle without separate confirmation.

Who it's relevant to

Project managers
Those responsible for guiding a project through its lifecycle use the concept phase to establish whether a project should proceed and to capture its justification and strategic alignment before later commitments are made.
Engineers and product designers
Engineering and design professionals rely on the concept phase to refine ideas into viable projects while design flexibility remains high, since function, materials, and detailing can still change substantially before later phases lock in the design.
Business case owners and sponsors
Sponsors and those developing the business case use the concept phase to test whether a proposed project aligns with broader goals and is worth pursuing before resources are committed.

Inside Concept Phase

Use Case Definition
An articulation of the intended purpose, business objective, and scope of the proposed model or AI system, typically framed before development begins to establish what problem the system is meant to solve and where it will and will not be applied.
Preliminary Risk Assessment
An early-stage evaluation of the inherent risk associated with the intended use, often considering factors such as materiality, complexity, and potential impact on stakeholders. As commonly defined, this focuses on inherent risk before controls are designed, not residual risk.
Regulatory and Governance Scoping
An initial identification of which governance policies, oversight structures, and potentially applicable regulatory expectations may bear on the intended system. Whether specific frameworks apply depends on jurisdiction and sector, so scoping typically flags candidates rather than confirming obligations.
Feasibility and Data Considerations
A high-level assessment of whether suitable data, methods, and resources are likely to be available to support the intended use, without yet committing to a specific technical approach or validation activity.
Stakeholder and Accountability Identification
An early mapping of roles and ownership, which in many governance structures distinguishes first-line development and business ownership from second-line oversight, so accountability is assigned before design proceeds.

Common questions

Answers to the questions practitioners most commonly ask about Concept Phase.

Is the Concept Phase the point where a model is validated?
No. The Concept Phase precedes independent validation. In many model risk management frameworks, this early stage is concerned with articulating the intended use, business objective, and theoretical or conceptual soundness of a proposed model or approach, not with the formal, independent validation of a built model. Validation—commonly understood as an independent assessment of whether a model is fit for its intended purpose—typically occurs later in the lifecycle once a model has been developed. Conflating the Concept Phase with validation can obscure the separation of duties that many frameworks expect between development and independent review.
Does completing the Concept Phase mean the model risk has been eliminated?
No. No phase of a model lifecycle eliminates risk; the Concept Phase is a measure that helps identify and reduce risk early rather than remove it. Even a well-reasoned conceptual foundation leaves residual risk, and inherent risk in the proposed use case persists into later phases. The purpose of activities at this stage is typically to surface potential issues—such as unsuitable assumptions, data limitations, or a mismatch between the proposed approach and the business problem—so they can be managed, not to certify that the resulting model will be sound.
Who is typically involved in the Concept Phase, and how does it relate to the lines of defense?
Involvement varies by organization and framework. In many structures, business owners and model developers (commonly associated with the first line of defense) lead the articulation of the use case and proposed approach, while governance or risk management functions (often associated with the second line) may provide early input or challenge. The specific roles, and whether independent review is engaged at this stage, depend on an organization's governance design and risk appetite, so this description should not be read as a universal requirement.
What documentation is commonly produced during the Concept Phase?
Documentation practices differ across frameworks and sectors. Organizations frequently capture the intended business purpose, the problem the model is meant to address, the proposed methodology or approach, key assumptions, anticipated data sources, and known limitations or alternatives considered. This early record can support later stages such as development and independent review by establishing what the model was intended to do. The exact artifacts and their formality depend on organizational policy and the assessed risk of the proposed use.
How does the Concept Phase inform the risk assessment of a proposed model?
The Concept Phase can provide inputs to an early or preliminary risk assessment by clarifying the intended use, materiality, and potential consequences of the proposed model. In many frameworks, this early understanding of inherent risk—the risk before controls are applied—helps determine the level of scrutiny, validation rigor, and oversight the model may warrant later. The assessment made at this stage is typically preliminary and subject to revision as the model is developed and more is known.
How do decisions made in the Concept Phase connect to later lifecycle stages?
Choices articulated during the Concept Phase—such as the intended purpose, methodology, and assumptions—commonly set the reference points against which later development, testing, and independent review are conducted. For example, the stated intended use often frames what later validation seeks to confirm, and documented limitations may be revisited during monitoring. Because these later stages depend on a clear conceptual foundation, gaps or ambiguities left unresolved at this stage can propagate downstream, though the specific dependencies vary by framework and organization.

Common misconceptions

The concept phase is where model validation begins.
Validation is an independent assessment of a built model against its intended purpose and typically occurs later in the lifecycle. The concept phase generally addresses intended use, feasibility, and preliminary risk framing rather than validating or verifying a model that does not yet exist.
Risk identified in the concept phase is the final risk rating of the system.
Early-stage assessment usually characterizes inherent risk based on intended use, before controls are designed and applied. Residual risk, which reflects the effect of controls, is typically determined later and can differ substantially from the initial framing.
Completing the concept phase means governance and compliance requirements are settled.
The concept phase typically scopes candidate governance and potentially applicable regulatory expectations rather than confirming binding obligations. Applicability often depends on jurisdiction, sector, and how the system evolves, so requirements are commonly revisited as the work matures.

Best practices

Document the intended use, scope, and explicit out-of-scope boundaries at the outset, so later stages can test whether the system is used only as intended.
Frame the early assessment in terms of inherent risk driven by intended use and materiality, and avoid recording it as a final or residual risk rating.
Identify and assign accountability early, distinguishing business or development ownership from independent oversight roles rather than blurring them.
Scope potentially applicable governance policies and regulatory expectations as candidates to confirm later, using qualified language where applicability depends on jurisdiction or sector.
Capture assumptions about data availability, feasibility, and methods so they can be revisited and challenged as the design phase proceeds.
Record open questions and known limitations from the concept phase so they carry forward into design, development, and later validation activities.