finos · mindthegab · Feb 21, 2026 · Feb 21, 2026 · Feb 21, 2026 · Feb 21, 2026
diff --git a/...ub/ISSUE_TEMPLATE/Project-Archiviation.md → .github/ISSUE_TEMPLATE/Project-Archival.md b/...ub/ISSUE_TEMPLATE/Project-Archiviation.md → .github/ISSUE_TEMPLATE/Project-Archival.md
@@ -20,15 +20,15 @@ Upon submission of this proposal, the FINOS team will follow the checklist repor
 -----
 
 ## Confirm archivation
-- [ ] Validate [reasons for project archival](https://community.finos.org/docs/governance/Software-Projects/maturity/archived)
+- [ ] Validate [reasons for project archival](/docs/governance/lifecycle-stages/archived)
 - [ ] Discuss request with FINOS Leadership team
 - [ ] Get in touch with Project Lead. If she/he agrees with the request, then move forward
 - [ ] (if applicable, and on a case to case basis) communicate project archival, reasons for archival and implications of archival to the project community
 
 ## Archive GitHub repositories
 - [ ] Collect all GitHub repository for a given project, from FINOS metadata; iterate the following steps on each of them:
     - [ ] Remove all users and teams from `Member Access` repository settings
-    - [ ] Update badge on `README.md` to [Archived](https://community.finos.org/docs/governance/software-projects/maturity/archived/#badge) (linking to https://community.finos.org/docs/governance/Software-Projects/maturity/archived)
+    - [ ] Update badge on `README.md` to [Archived](https://community.finos.org/docs/governance/lifecycle-stages/archived/#badge) (linking to https://community.finos.org/docs/governance/lifecycle-stages/archived)
     - [ ] Add a note at the top of the README file, stating: _This project is archived, which means that it's in read-only state; you can download and use this code, but please be aware that it may be buggy and may also contain security vulnerabilities. If you're interested to restore development activities on this project, please email help@finos.org_
     - [ ] Hit the `Archive` button on GitHub, by accessing the Settings repository page using `finos-admin` credentials
     - [ ] Open ticket to LF Support in order to update Project definition:

diff --git a/.github/ISSUE_TEMPLATE/Project-Incubation.md b/.github/ISSUE_TEMPLATE/Project-Incubation.md
@@ -0,0 +1,11 @@
+---
+name: "\U0001F58AProject Incubation"
+about: To Promote a FINOS Labs into an Incubating Project
+title: Project Incubation Request
+labels: ''
+assignees: maoo, TheJuanAndOnly99
+
+---
+# TBC
+
+This issue should be used for projects in Labs requesting to enter Incubation
diff --git a/.github/ISSUE_TEMPLATE/Software-Project-Contribution.md b/.github/ISSUE_TEMPLATE/Software-Project-Contribution.md
@@ -98,7 +98,7 @@ As a project onboarding into FINOS, you will need to familiarize yourself and yo
  - [FINOS overview](https://www.finos.org/hubfs/An%20Introduction%20to%20FINOS.pdf) (if necessary)
  - [FINOS Maintainers cheatsheet](https://community.finos.org/docs/finos-maintainers-cheatsheet/)
  - [FINOS Project/Standards Governance](https://community.finos.org/docs/governance)
- - [FINOS Project Lifecycle](https://community.finos.org/docs/governance/Software-Projects/project-lifecycle)
+ - [FINOS Project Lifecycle](https://community.finos.org/docs/governance/project-lifecycle)
 
 ## Record The Contribution (FINOS Infra)
 - [ ] (optional) Identify and Assign FINOS Strategic Advisor
@@ -162,7 +162,7 @@ Before the FINOS team can onboard your project, there are a few housekeeping tha
     - [ ] `CONTRIBUTING.md`
     - [ ] `LICENSE` (replace `{}` placeholders)
     - [ ] Ensure that the proper project governance is in the CONTRIBUTING.md file
-- [ ] [All incubating criteria](https://community.finos.org/docs/governance/Software-Projects/project-lifecycle#incubating) are checked and documented below
+- [ ] [All incubating criteria](https://community.finos.org/docs/governance/lifecycle-stages/incubating) are checked and documented below
 
 _Add documentation here_
 
@@ -188,7 +188,7 @@ This is performed by FINOS Infra once the three previous stages are complete, wi
 - [ ] The codebase doesn’t have any unfriendly licenses across direct and transitive libraries
 - [ ] (optional - if a build system is provided) The build process runs successfully
 - [ ] The codebase doesn’t include any patent or copyright that conflicts with FINOS Governance and bylaws (to be validated with FINOS Legal team)
-- [ ] [All incubating criteria](https://community.finos.org/docs/governance/Software-Projects/project-lifecycle#incubating) are met (review documentation provided above)
+- [ ] [All incubating criteria](https://community.finos.org/docs/governance/lifecycle-stages/incubating) are met (review documentation provided above)
 
 ## Code transfer 
 - [ ] Transfer all code assets as GitHub repositories under github.com/finos

diff --git a/docs/collaboration-infrastructure.mdx b/docs/collaboration-infrastructure.mdx
@@ -113,13 +113,13 @@ Although GitHub doesn't directly support the concept of a "project" (a group of
 #### Building and testing
 The build is an end-to-end process that converts source code into reusable artifacts, something that we will refer to as deployable units, which is developed by the project team and hosted in the github repository. It is a particularly important task, as it can centralise and trigger several automated sub-tasks, such as version control, code testing, quality and compliance reports and more.
 
-A working build process is key to implement more automated processes, such as release, <a href={useBaseUrl('/docs/development-infrastructure/continuous-integration/intro')}>Continuous Integration</a> and automated deployments; it is also a requirement for [project Graduation](/docs/governance/Software-Projects/project-lifecycle#graduated).
+A working build process is key to implement more automated processes, such as release, <a href={useBaseUrl('/docs/development-infrastructure/continuous-integration/intro')}>Continuous Integration</a> and automated deployments; it is also a requirement for [project Graduation](/docs/governance/lifecycle-stages/graduated).
 
 #### Versioning
 Versioning is the process to establish a format to a project version and the rules to update it, preferably integrating with automated build and release systems; the Foundation mandates the use of [Semantic Versioning](https://semver.org/) ("semver") throughout a project's lifecycle:
 
 - for Incubating projects, version numbers must be less than 1.0.0
-- for [Graduated](/docs/governance/Software-Projects/project-lifecycle#graduated) projects, version numbers can be 1.0.0 or greater
+- for [Graduated](/docs/governance/lifecycle-stages/graduated) projects, version numbers can be 1.0.0 or greater
 
 Every project team is encouraged to define specific criteria by which the MAJOR, MINOR and PATCH components of the semver scheme will be used (keeping in mind the general guidelines semver itself mandates), since this helps to provide clarity to consumers.
 

diff --git a/docs/finos-maintainer-cheatsheet.mdx b/docs/finos-maintainer-cheatsheet.mdx
@@ -41,7 +41,7 @@ The below table lists maintainers' responsibilities and available resources. Ple
 
 | Maintainer Responsibility | How FINOS supports you |
 |:---|:---|
-| **Grow project maturity and community** | Virtually all FINOS hosted projects are expected to strive towards, and ultimately attain, [Graduated status](/docs/governance/Software-Projects/project-lifecycle#graduated). The FINOS team supports projects in this journey through: <ul><li> **operational enablement**: see the [LFX Project Control Center](https://lfx.linuxfoundation.org/tools/project-control-center)</li><li>**community marketing & engagement support**: Participation and/or feature your project in the [FINOS Newsletter](https://www.finos.org/newsletter), [FINOS Community Blog](https://www.finos.org/blog), [Open Source in Finance Podcast](https://podcasts.apple.com/us/podcast/finos-open-source-in-finance-podcast/id1512371068), [FINOS events](https://www.finos.org/hosted-events) including the [Open Source Strategy Forum (OSSF)](https://events.linuxfoundation.org/open-source-strategy-forum/)</li><li>[Request the creation](https://github.com/finos/community/issues/new?assignees=mcleo-d&labels=comms-channel-request&template=Communication_channel_request.md&title=) of a [FINOS Slack](https://finos-lf.slack.com/) Channel or enable GitHub Team Discussions for your FINOS Project or SIG. </li></ul> |
+| **Grow project maturity and community** | Virtually all FINOS hosted projects are expected to strive towards, and ultimately attain, [Graduated status](/docs/governance/lifecycle-stages/graduated). The FINOS team supports projects in this journey through: <ul><li> **operational enablement**: see the [LFX Project Control Center](https://lfx.linuxfoundation.org/tools/project-control-center)</li><li>**community marketing & engagement support**: Participation and/or feature your project in the [FINOS Newsletter](https://www.finos.org/newsletter), [FINOS Community Blog](https://www.finos.org/blog), [Open Source in Finance Podcast](https://podcasts.apple.com/us/podcast/finos-open-source-in-finance-podcast/id1512371068), [FINOS events](https://www.finos.org/hosted-events) including the [Open Source Strategy Forum (OSSF)](https://events.linuxfoundation.org/open-source-strategy-forum/)</li><li>[Request the creation](https://github.com/finos/community/issues/new?assignees=mcleo-d&labels=comms-channel-request&template=Communication_channel_request.md&title=) of a [FINOS Slack](https://finos-lf.slack.com/) Channel or enable GitHub Team Discussions for your FINOS Project or SIG. </li></ul> |
 | **Run Project Meetings** | Project maintainers are welcome to engage with their project community through project meetings. If they choose to do so, maintainers are responsible for creating meeting agendas, recording meeting attendance and publishing meeting minutes. <ul><li>[Follow FINOS Meeting Procedures from the FINOS Community Governance Repository.](/docs/governance/meeting-procedures)</li><li>[Run Project Meetings from GitHub Issues using the Meeting Attendee Tracker Action.](/docs/collaboration-infrastructure#meeting-minutes)</li></ul> |
 | **CI/CD** . | Project maintainers are responsible for integrating Continuous Integration and Continous Deployment into their FINOS project builds: <ul><li>[Use the FINOS Open Developer Platform for Continuous Integration and Deployment.](/docs/development-infrastructure/continuous-integration/intro/)</li></ul> |
 | **Documentation** | Maintainers are responsible for publishing project documentation from their project's GitHub Repositories to FINOS Project Websites. <ul><li>[Use Docusauraus and GitHub Actions for Publishing Project Documentation.](/docs/development-infrastructure/project-documentation#docusaurus)</li></ul> |

diff --git a/docs/governance/Project-Lifecycle.md b/docs/governance/Project-Lifecycle.md
@@ -0,0 +1,44 @@
+---
+id: project-lifecycle
+title: Lifecycle introduction
+---
+
+# Introduction
+
+FINOS projects are categorized according to the FINOS Project Lifecycle: each project is required to clearly display their Lifecycle Stage in the form of a badge in their README.md.
+
+The Project Lifecycle is maintained by the [FINOS Technical Oversight Committee](https://github.com/finos/technical-oversight-committee) and serves as a recognition of governance transparency, community health, in addition to functional (features) and non functional (security, best practices, etc) maturity of the project with respect to its stated goals and roadmap. 
+
+> **NOTE:** The FINOS Lifecycle was updated in 2026 to reflect evolution of the foundation and now aligns closely with the [CNCF maturity model](https://github.com/cncf/toc/blob/main/process/README.md). 
+
+# Why is the Project Lifecycle needed?
+
+  * **For Consumers:** The lifecycle is designed to help users easily determine which projects are appropriate for their use, whether it be experimentation or production use. 
+ * **For Maintainers:** The lifecycle gives FINOS maintainers a roadmap for progressing their projects towards increasing levels of maturity. 
+ * **For FINOS Staff:** The lifecycle gives FINOS staff a way to offer access to different benefits (and therefore incentives) to projects which are more appropriate for their lifecycle stage.
+
+# FINOS Lifecycle Stages
+
+Projects in FINOS can be in one of the following lifecycle stages: 
+
+| Badge | Lifecycle Stage Details                                              | What does it signal to consumers?                                                                                                                                                              |
+| ----- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|   <img src="https://raw.githubusercontent.com/finos/contrib-toolbox/master/images/badge-forming.png" width="150" padding-left="20"  />    | [Forming](/docs/governance/lifecycle-stages/forming)       | This stage is for projects can optionally start for a limited time in a **Member-only private repo** to gauge its viability and interest across Members, ahead of being open to the world.     |
+|   <img src="https://raw.githubusercontent.com/finos/contrib-toolbox/master/images/badge-labs.png" width="150" />    | [Labs](/docs/governance/lifecycle-stages/labs)             | This stage is the default entry point for all FINOS projects which **are in an initial exploratory or experimental phase** while still hosted in a neutrally governed space overseen by FINOS. |
+|   <img src="https://raw.githubusercontent.com/finos/contrib-toolbox/master/images/badge-incubating.png" width="150" />    | [Incubating](/docs/governance/lifecycle-stages/incubating) | This stage is for projects with high potential in early growth phase in terms of their functionality, maturity, and community sustainability.                                                  |
+|   <img src="https://raw.githubusercontent.com/finos/contrib-toolbox/master/images/badge-graduated.png" width="150"/>    | [Graduated](/docs/governance/lifecycle-stages/graduated)   | This stage is the highest maturity stage, for active projects with healthy and diverse contributor and adopter communities                                                                     |
+|   <img src="https://raw.githubusercontent.com/finos/contrib-toolbox/master/images/badge-archived.png" width="150"/>    | [Archived](/docs/governance/lifecycle-stages/archived)     | This stage is for projects that, while potentially still highly valuable, are no longer actively maintained.                                                                                   |
+
+Please review individual lifecycle stage pages for detailed information about what each stage represents for consumers, what are the criteria and ongoing requirements for projects to be in a lifecycle stage and instructions for maintainers how to apply for each stage.
+
+# FINOS Lifecycle Governance
+
+Per [TOC responsiblities](https://github.com/finos/technical-oversight-committee/blob/main/operations/governance.md#responsibilities), the [TOC](https://github.com/finos/technical-oversight-committee/) is responsible for:
+
+- Maintaining and evolving all lifecycle stages definitions
+- Approve lifecycle transitions (or new contributions) to the Incubating, Graduated and Archived stages
+- resolve any potential dispute that may occur between project maintainers and who is proposing an archival transition
+
+The FINOS Staff is responsible for:
+
+- Accepting new projects into Labs stage according to the [FINOS Labs](/docs/governance/lifecycle-stages/labs) requirements
diff --git a/docs/governance/README.md b/docs/governance/README.md
@@ -71,11 +71,11 @@ Documents produced or contributed as part of the SIG will be contributed and mad
 # Project Lifecycle and steering
 
 ## Project Lifecycle
-Software projects follow the [Project Lifecycle](/docs/governance/Software-Projects/project-lifecycle), a useful tool for consumers and contributors to quickly evaluate maturity, activity, and quality. Projects may begin in either the "Labs" or "Incubating" state, graduate to "Graduated", and finally may move to the "Archived" state (from either Labs, Incubating, or Graduated) if they are no longer actively developed.
+Software projects follow the [Project Lifecycle](/docs/governance/project-lifecycle), a useful tool for consumers and contributors to quickly evaluate maturity, activity, and quality. Projects may begin in either the "Labs" or "Incubating" state, graduate to "Graduated", and finally may move to the "Archived" state (from either Labs, Incubating, or Graduated) if they are no longer actively developed.
 
-The TOC approves lifecycle transitions following objective criteria detailed for [Incubating](/docs/governance/Software-Projects/project-lifecycle#incubating) and [Graduated](/docs/governance/Software-Projects/project-lifecycle#graduated) projects.
+The TOC approves lifecycle transitions following objective criteria detailed for [Incubating](/docs/governance/lifecycle-stages/incubating) and [Graduated](/docs/governance/lifecycle-stages/graduated) projects.
 
-Some projects may optionally start in a time-bound pre-incubation stage called *Formation*, which is typically restricted to FINOS Members or at the discretion of the project lead. [Forming projects](/docs/governance/Software-Projects/project-lifecycle) might not be publicly visible until entering Incubation when they will be fully open sourced.
+Some projects may optionally start in a time-bound pre-incubation stage called *Formation*, which is typically restricted to FINOS Members or at the discretion of the project lead. [Forming projects](/docs/governance/project-lifecycle) might not be publicly visible until entering Incubation when they will be fully open sourced.
 
 ## Project Metrics 
 Live metrics of Project activity and contributions across all FINOS collaboration systems are publicly available in [FINOS Project Activity Dashboard](https://metrics.finos.org).

diff --git a/docs/governance/Software-Projects/Contribution-Compliance-Requirements.md b/docs/governance/Software-Projects/Contribution-Compliance-Requirements.md
@@ -45,7 +45,7 @@ The `CONTRIBUTING` file contains basic instructions to prospective contributors
 Please note that Github will prompt this content when a user creates an issue or pull request, you can read more on [GitHub Contributing Guidelines](https://github.com/blog/1184-contributing-guidelines).
 
 #### Source code license headers
-For [Graduated](/docs/governance/Software-Projects/project-lifecycle#graduated) projects, it's recommended that each source code file should include a license header comment. Most projects use the standard Apache-style header. Note that all copyright notices should go into a separate single `NOTICE.md` file at the root level (i.e., same level as `README.md` and `CONTRIBUTING.md`) of the GitHub/GitLab repository.
+For [Graduated](/docs/governance/lifecycle-stages/graduated) projects, it's recommended that each source code file should include a license header comment. Most projects use the standard Apache-style header. Note that all copyright notices should go into a separate single `NOTICE.md` file at the root level (i.e., same level as `README.md` and `CONTRIBUTING.md`) of the GitHub/GitLab repository.
 
 ```
 SPDX-License-Identifier: Apache-2.0