diff --git a/docs/operational-model/advanced.md b/docs/operational-model/advanced.md
new file mode 100644
index 0000000..0421148
--- /dev/null
+++ b/docs/operational-model/advanced.md
@@ -0,0 +1,67 @@
+# Operational Model - RHEL - Advanced
+If you are wonder what an operational model is, [you should start by reading this introduction](https://redhat-cop.github.io/rhel-good-practices/operational-model/intro/).
+
+# Overview
+Zoom into this picture for details.
+
+![Overview](assets/rhel-operational-model.jpg)
+
+# People
+* **Solution architects** - To offload the many discussions on how to do different things with your operating system platform, it makes a lot of sense to have one or several Solution Architects which focuses on helping users implement their systems.  
+
+## Community of practice
+There are many different names for this, for example Centre of Excellence, DevOps Dojo, or etc. It's simply a community which you build around your platform. Here we describe resources related to people and your community.
+
+* **Gamification** - You have implemented gamification practices which boosts contribution in your community.
+* **Contribution princes** - You celibrate contribution to the degree that you have a small budget for contribution prices.
+* **Chat channels per domain** - Your community has grown so large that you now need to split chat channels per technical domain.
+* **Re-ocurring meetings per domain** - Your community is too large for a single community of practice meeting. You also now have meeting specific for special technical domains such as cloud, specific security.
+* **SLA for responses** - To ensure that people are not left in a vaccum with their problems, you aim to answer all questions in your chat chanels within a specific time.
+
+## RHEL Platform processes
+Processes related to the Red Hat Enterprise Linux standard platform itself.
+
+## Onboarding process
+An overview of a common onboarding process can be viewed below. Please note that the graphics describes all three advancement levels of onboarding.
+![Overview](assets/rhel-onboarding.jpg)
+
+The steps for the Advanced version of the onboarding follows:
+
+* **Skill based training** (Onboarding for experienced/un-experienced) There is a specific onboarding process for people who are already experienced with modern development practices and Red Hat Enterprise Linux. This allows highly experienced individuals to get started more quickly.
+
+## Development processes
+Processes related to the development of your RHEL platform.
+
+* **Infra as code** - As you develop and define your RHEL Platform, you use infrastructure-as-code concepts. This is a requirement to allow for advanced controls of the development and security of the standard.
+* **Complete test coverage (Unit, Functional, Integration)** - All aspects of your standards is covered by tests. This allows you to quickly pinpoint complex issues as your develop your standard, inroduce new major releases and more.
+* **Continous deployment and testing of platform** - When you make a change to your standard, it automatically deploys test instances and performs testing on them. This allows you to navigate complicated issues in the standard where something breaks further down the line.
+* **Automated RPM builds** - You have an automated RPM build system which ties into the automatic and continous deployment and testing of your platform.
+* **Advanced supply chain security** - The development process of your standard has advanced security compliance such as [SLSA Level 3](https://slsa.dev/).
+* **Ansible, Terraform, etc** - To deploy a complete fresh instance of your RHEL platform in an automated fashion you do well in using an automation framework, such as Ansible or Terraform.
+
+## RHEL architecture
+Architectural decisions related to Red Hat Enterprise Linux.
+
+### Infrastructure design
+Infrastructure related decisions.
+
+* **Self healing system** - The installed instances of RHEL will self heal in case of known issues related to Availability or Security are detected. This can be accomplished with things such as Event Driven Ansible which is a part of Ansible Automation Platform, or 3rd party SIEM or monitoring platforms.
+* **Ansible Automation Platform** - Your requirements for automation and scale of your installed base of RHEL instances means that you would be well off in investing in a general purpose automation platform. The most popular configuration management tool is Ansible, and [the premier central automation platform is called Ansible Automation Platform.](https://www.redhat.com/en/technologies/management/ansible). This allows your to streamline development of your platform, moving automation previously defined elsewhere, as Ansible automation. It will also decrease overall technical risk for your platform and allow you to focus your time on things which matters more.
+* **Military Grade Security** - Security standards such as CIS Level 2 are not good enough. Creating automatic hardening which can withstand persitent threat groups requires the most strictest security hardening, including SELinux MLS mode, Integrity Measurement Architecture, etc, and agressive automatic security responses.
+* **Advanced image build system** - When you need to support a broader range of RHEL installation images, you need to invest more in your image build system. It needs to be able to continously generate images, also integrated to your automatic RPM build system - if you have one.
+
+### RHEL design
+Design of your Red Hat Enterprise Linux standard.
+
+* **Application platform specific post configuration** - Your platform automatically applies post configuration specific to different application platforms such as different databases, application servers, etc.
+* **Fully unattended installations** - When a new instance of your standard starts up, nothing more is needed to be done as it relates to your platform. That includes configuring all related systems, such as CMDB systems, change management systems, and so on.
+* **Multi-platform support** - You support multiple hardware-, virtualization- and cloud platforms.
+* **RHEL Image mode** - Your RHEL platform also supports RHEL Image mode.
+
+## Development tool chain
+Features related to the development tool chain.
+
+* **Complete test coverage (Unit, Functional, Integration)** - You need tools which supports the complete testing of your platform. That can be done using the automation, infra as code and CI/CD features of your platform. It may also be accomplished with 3rd party tools test platforms.
+* **RPM Build system** You need a system which can automatically build RPMs. Either a custom implementation using rpm-build tools, mock, or a more proper platform such as [Koji](https://koji.build/).
+* **Advanced supply chain security** - You need to select tools such can support advanced supply chain security standards such as [SLSA](https://slsa.dev).
+* **Ansible, Terraform, etc** - You need more advanced automation capabilities to be able to automatically deploy your standard, such as Ansible or Terraform.
diff --git a/docs/operational-model/assets/rhel-onboarding.jpg b/docs/operational-model/assets/rhel-onboarding.jpg
new file mode 100644
index 0000000..67668ea
Binary files /dev/null and b/docs/operational-model/assets/rhel-onboarding.jpg differ
diff --git a/docs/operational-model/assets/rhel-operational-model.jpg b/docs/operational-model/assets/rhel-operational-model.jpg
new file mode 100644
index 0000000..974ba8b
Binary files /dev/null and b/docs/operational-model/assets/rhel-operational-model.jpg differ
diff --git a/docs/operational-model/intro.md b/docs/operational-model/intro.md
new file mode 100644
index 0000000..138dbb5
--- /dev/null
+++ b/docs/operational-model/intro.md
@@ -0,0 +1,26 @@
+# What is an operational model?
+
+Hello and welcome. This is a good practice based operational model for Red Hat Enterprise Linux. This model is for people who wants inspiration for how you can run and manage a Linux standard platform based on Red Hat Enterprise Linux.
+
+This model covers good practices and should not be read as a list of things you always need to do. Different organizations are different.
+
+The model, which covers people, process, technology, service management and strategy is divided between three different advancement levels (1-3). Access these different levels via the menu on the top of this page.
+
+It’s likely that your best fit is a mix of the different levels (MVP, 2.0, Advanced).
+
+1. Minimal Viable Product (MVP)
+
+The MVP version of a platform definition is a common good practice starting point, which we can build on. Due to the limitation in regards to automation, this works for a limited install base of servers. We are weighing things such as ease-of-adoption and standardization against effort to implement. Instead of creating a so-called “big bang release”, which requires significant investments in regards to effort and people, we ensure we have just enough platform features to provide our platform for some first real life use-cases.
+
+[Read more here.](https://redhat-cop.github.io/rhel-good-practices/operational-model/mvp/)
+
+2. Two point zero (2.0)
+
+Once there has been some real degree of success and adoption of the platform, it’s time to fine tune the definition for it to be able to meet the requirements of the future. Focus is on more advanced platform and adoption related capabilities. We spend more time standardizing things such as how we develop, install and configuration the platform, an investment which is required as the burden of compliance otherwise threatens to grind our organization to a halt. The features we now build reduces the effort regarding maintenance and compliance, and allows us to maintain a much larger install base of Linux installation.
+
+[Read more here.](https://redhat-cop.github.io/rhel-good-practices/operational-model/twozero/)
+3. Advanced
+
+A lot of focus now goes into making sure the platform install base can grow to significant scales and make more signficant business impact. Our platform is one of the key technologies used in our organization and needs to be able to cater for much stricter requirements. At the same time we need to spend increased effort on the community we have built around our Linux platform. Some final technical capabilities are put in place to ensure we can meet any type of business requirements.
+
+[Read more here.](https://redhat-cop.github.io/rhel-good-practices/operational-model/advanced/)
diff --git a/docs/operational-model/mvp.md b/docs/operational-model/mvp.md
new file mode 100644
index 0000000..ffb6f5c
--- /dev/null
+++ b/docs/operational-model/mvp.md
@@ -0,0 +1,79 @@
+# Operational Model - RHEL - Minimal Viable Product
+If you are wonder what an operational model is, [you should start by reading this introduction](https://redhat-cop.github.io/rhel-good-practices/operational-model/intro/).
+
+# Overview
+Zoom into this picture for details.
+
+![Overview](assets/rhel-operational-model.jpg)
+
+# People
+* It is common that the people who operate and maintain the platform has other jobs and do not work dedicated on the platform. Or it could simply just be a group of people with system admin type jobs. Even though we do not yet require a dedicated platform owner or platform engineering team, we should already start thinking about that.
+
+## RHEL Platform processes
+Processes related to the Red Hat Enterprise Linux standard platform itself.
+
+* **Incident management** - We need a standard process for managing technical incidents for the platform. Who should people contact if something goes wrong with their Linux server? And what will we do if something breaks?
+* **Life Cycle Management** - It is important that we communicate when we plan to update our platform. This in a form of a life-cycle management plan. At this point, if you do not know much about this, you can copy the Red Hat Enterprise Linux life-cycle management plan, which you find here: [Red Hat Enterprise Linux Life Cycle](https://access.redhat.com/support/policy/updates/errata)
+* **Backup and recovery** - We need to have a standard process for doing backups and recovering from those backups. Life cycle management and incident management depends on this.
+* **Patch Management** - We need a process for how to patch our RHEL installations. This can include moving between minor releases of RHEL, but not major releases as that is a special workflow. In part this process needs to cover how you identify systems which needs to be patched and then how the system is patched. Initially, this will be a manual process, later on, this becomes an automated process.
+* **Capacity management** - How do we monitor the utilization of an installed RHEL server, and act as we need to expand the capacity? Put in place a process to deal with this. It's normal that the process at this point is manual.
+* **Subscription management** - How do you keep track of your Red Hat Enterprise Linux subscription usage? If your systems can conntact to Red Hat's services, then you will be able to manage your subscriptions via [Red Hat's online Subscription Management page](https://access.redhat.com/management). You should create a process for keeping track of utilization, so that you can order more subscriptions, before you actually run out. You can reach out to your Red Hat account team to get help with designing such a process.
+
+## Onboarding process
+* **Manual onboarding** - The onboarding process is commonly not automated. When new people or teams get onboarded, the people who works with the platform are responsible for this process. This process is very simple in its nature, lacking assessment of who and what is onboarded and training. Because of this - what people end up doing with their systems, and how they will manage them, is very different. If you need to onboard more than a few teams, you should have more advanced.
+
+An overview of a common onboarding process can be viewed below. Please note that the graphics describes all three advancement levels of onboarding.
+
+![Overview](assets/rhel-onboarding.jpg)
+
+The steps for the MVP version of the onboarding process follows:
+* **Users provided access to landing page** - The landing page is referenced and described in the overall operational model. It is a page where users can go and get information such as platform documentation, descriptions of process (such as the onboarding process itself) and documentation and training materials/links.
+* **LDAP groups created** - If your organization is using an LDAP solution for identity, create some standard LDAP groups which you can connect to the your RHEL installations. It's good if you create some type of standard naming here, such as: rhel-(system-name)-(team name)-admin, rhel-(system-name)-(team name)-user, etc. The team in question can then own these groups and do user management themselves.
+* **Users added to group** - Users are added to the groups in question. This may be done by the team who are being onboarded.
+* **RBAC configuration created on servers** - You now put in place the required RBAC related configuration on your server, as it relates to things such as sudoers, ssh, pam, sssd, etc. 
+
+## Development processes
+* There are no standardized processes yet, related to how we are developing our RHEL platform. That also puts some limitations for how much we can scale at this point, as that would risk racking up a lot of technical debt. As an example, if we have to perform a lot of changes to our RHEL standard, that will take a lot of time and effort, while it's likely that those changes will not be applied consistently across our installed base.
+
+## RHEL architecture
+Architectural decisions related to Red Hat Enterprise Linux.
+
+### Infrastructure design
+Infrastructure related decisions.
+
+* **Availability** - We need to design our platform so that it can meet our requirements for availability. That may mean that we need to support to run on a specific server or virtualization platform, or support specific storage configurations related to SAN.
+* **Security** - We need to design our platform so that it also meets requirements for security, that includes hardening practices for RHEL, supporting network segmentation, 3rd party security tools, etc.
+* **Monitoring** - To ensure availability and security, some type of monitoring needs to be put in place. How do you know if utilization of CPU, memory or storage goes through the roof? How do you know that your backup client or security related services are running? Monitoring.
+* **Repository management** - If your systems can connect to Red Hat's YUM repositories, then this item is resolved. Please note that when you do update your systems, they will be updated to whatever latest versions are available. If you want control over what version of software gets installed on your RHEL servers, or if your systems cannot be connected to Red Hat provided YUM repositories, then you need to decide how you will manage the RHEL yum repositories yourself. Via some 3rd party system or by simply synchronizing related repositories to some local NFS or HTTP server?
+* **Subscription management** - If your systems can conntact to Red Hat's services, then you will be able to manage your subscriptions via [Red Hat's online Subscription Management page](https://access.redhat.com/management). If this is not the case, you should invent some custom temporary mean to count how many subscriptions are currently used, perhaps by development a document for this purpose.
+
+### RHEL design
+Design of your Red Hat Enterprise Linux standard.
+
+* **Package baseline** - You have to decide what packages should be a part of your RHEL standard installation. Red Hat has some standard RHEL package definitions such as core, base, which can inspire you. Also, if you have a look at a standard RHEL KVM or Cloud images, that can also be used for inspiration.
+* **User management** - How will you do users management in your RHEL standard? Will you allow the use of local users? Will you mandate the use of service accounts for automation? You better decide these things now, before you have hundreds of servers.
+* **Authentication** - If you allow local users, this is simple. But if you don't, then there will be some type of central system which will authenticate users.
+* **Identity** - If you allow local users, this is simple. If you don't then again you need to decide on a central system which validates the identity of users.
+* **RBAC** - This relates to configuring who gets access to do what. Will everyone have root access? Or will only some people have this? This is where you decide on any separation of duty enforcements and configure related services such as sssd, sshd, sudoers, pam, etc.
+* **Installation** - Decide on how to install Red Hat Enterprise Linux. Starting off with your RHEL Linux standard platform, it is not unusual that people manually installs RHEL. With that said, nowdays it's also common that you start off with some automated installation, using standard RHEL images you download and built in virtualization or cloud features such as cloud init.
+* **Manual patch management** - In the beginning of your RHEL journey, it's not uncommon that patch management is a manual process. You still need to decide on how to do patching though. This includes the process of making patches available to your systems, ensuring backups are in place, installing updates, testing so that nothing broke, etc. If this process is not automated it soon becomes very painful to scale the numbers of your installed based of RHEL. So prioritize automating this later on.
+
+## Development tool chain
+Features related to the development tool chain.
+
+* **Git organization** - How do you organize things such as related automation, in your version control system? Do you gather all repositories in the same group, or something else?
+* **Git repository structure** - If you end up maintaining a lot of different respositories, it may be a good idea to decide how these repositories should work. Will you commit everything straight to the main branch, or will you have [a more refined git branching strategy](https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy)?
+
+## Onboarding
+Technology implementations related to onboarding.
+
+* **Landing page** - When someone gets onboarded to your platform. They need a place to start their onboarding process. This is typically a wiki page or webpage maintained by the core platform team.
+* **Platform documentation** - A common part of a technical platform implementation, you have documentation which decribes to other people how the platform works.
+* **Link collection** - A good way to help people who get onboarded is by maintaining a list of useful links.
+
+# Platform management 
+Administrative features which helps with the development or maintenence of the platform.
+
+* **Service Level Agreement** - Select what different SLAs your platform should support.
+* **Operational Level Agreement** - Select what different OLAs your platform should support (if you use OLAs).
+* **Feature planning** - Make sure that as you plan and prioritize the different capabilities of your platform. A good start is to benchmark yourself against the model and then prioritize the different features across the MVP, 2.0 and Advanced levels. Except for creating more structure for the platform building process - this allows you to communicate detailed information about future feature, to the users of the platform.
diff --git a/docs/operational-model/twozero.md b/docs/operational-model/twozero.md
new file mode 100644
index 0000000..e9c6118
--- /dev/null
+++ b/docs/operational-model/twozero.md
@@ -0,0 +1,96 @@
+# Operational Model - RHEL - Minimal Viable Product
+If you are wonder what an operational model is, [you should start by reading this introduction](https://redhat-cop.github.io/rhel-good-practices/operational-model/intro/).
+
+# Overview
+Zoom into this picture for details.
+
+![Overview](assets/rhel-operational-model.jpg)
+
+# People
+* It is common that the people who operate and maintain the platform has other jobs and do not work dedicated on the platform. Even though we do not yet require a dedicated platform owner or platform engineering team, we should already start thinking about that.
+
+## Community of practice
+There are many different names for this, for example Centre of Excellence, DevOps Dojo, or etc. It's simply a community which you build around your platform. Here we describe resources related to people and your community.
+
+* **Community of practice core team** - This is commonly made up by the product owner and platform engineers, but as you have created a community of practice (devops dojo, center of excellence, etc), you may want to invite some people from your community to take on leading roles.
+* **Community of practice members** - The community consists of people who are interested in automation and your platform. You gotta catch em all to get get a strong and growing community, but it's good to start small, as there is a lot to learn here.
+* **Chat channel** - Community of pratice members needs a place where they can talk to each other.
+* **Re-ocurring meeting** - Schedule a meeting every other week or weekly, where people can share and interact with each other.
+
+## RHEL Platform processes
+Processes related to the Red Hat Enterprise Linux standard platform itself.
+
+* **Disaster recovery** - We ensure we have a functioning process for Disaster Recovery. When sigificant parts of the organization depends on our platform, we need this. This is a fairly complicated process it relates to rebuilding your complete RHEL standard platform, including potential systems you use to create it with, depending on what disaster scenario you are mitigating. 
+* **Upgrading** - It's now time for you to get a dedicated process for how to manage upgrades between major releases of Red Hat Enterprise Linux. There are many options available, either [by using LEAPP](https://www.redhat.com/en/resources/leapp-explained-detail) or by having an approach where you install new servers which you then migrate to.
+* **Automated onboarding** - The process for onboarding should be an automated one, this allows us to quickly onboard new teams and reduce shadow IT created by people tired of waiting for things.
+* **Assessment of teams and workloads** - When you onboard new teams it's important that you do some type of assessment of what type of workload will run on their servers. Workloads are an important source of requirements for things such as availability, capacity and security. You can start small and simply just interview new teams, or have them submit some standard information as a part of the onboarding process.
+* **Training** - You now do standard training for people who you onboard. What is that standard training? You decide.
+
+## Onboarding process
+* **Automatic onboarding** - n order to speed up the onboarding process, it is key that you automate as much as possible. This will also decrease the risk that something is not properly configured, such as RBAC configuration in AAP. It's important that people do not have to wait too long, as that risks create shadow IT, where people simply install Linux themselves.
+
+An overview of a common onboarding process can be viewed below. Please note that the graphics describes all three advancement levels of onboarding.
+
+![Overview](assets/rhel-onboarding.jpg)
+
+The steps for the 2.0 version of the onboarding process follows:
+* **Automated onboarding** - Configuration required to provide access to a new team is performed automatically. This includes creation of LDAP groups, adding users and configuring systems to provide access to the newly onboarded team.
+* **Initial assessment of workload** - As new team are onboarded you need to do assessments of the team and their workloads to be able to provide a good service and speed up adoption.
+* **Requirements assessment** - Ask the team some simple questions related to what they will actually run on their Linux instances. Depending on what they answer, it may be good to add new features to your platform, to support their workload. As an example, if the team requires PCI DSS compliance, you may add PCI DSS hardening in your Red Hat Enterprise Linux standard, and get Red Hat Satellite to get simplified compliance reporting.
+* **Training assessment** - Just providing someone a tool, without any instructions about how to use it will hurt standardization and securiry and can create all sorts of long term challenges. Assess what type of training the new team needs.
+* **DevOps training required** - It is common that newly onboarded teams needs training related to modern practices to manage Linux, this may include things such as: version control, testing, CI/CD and such. This will be key for them to understand. If you fail to catch this type of training requirement that will negatively impact overall standardization for your installed base.
+* **Linux training required** - Does the team getting onboarded need training related to how Red Hat Enterprise Linux works? It's good if you have some hands-on training regarding that, as an operating system is a complicated thing which no person can be expected to understand without training.
+* **Training** - This is the delivery of the training. If you cannot deliver this yourself, many companies, including Red Hat - has training available.
+
+## Development processes
+Processes related to the development of your RHEL platform.
+
+* **Documentation** - You have requirements related to what you should document regarding your platform features.
+* **External contributions** - How do people outside of the RHEL platform team contribute features to the standard? That should be allowed as it creates cross team collaboration and puts the users of RHEL in the driving seat for the standard they use.
+* **Testing** - When you have developed a new feature in your RHEL standard, how do you test it? Initially this may be a semi-manual process, where you do an installation and see if it was successful. As you move forward, this will have to be automated.
+* **CI/CD** - In order to automate your development processes, you need CI/CD. But how do you work with CI/CD? That is what this process describes.
+* **RHEL best practices** - It's common that you have a standard for how to write a programming language, based on best practices. In the same way, there are best practices for how to do things in Red Hat Enterprise Linux. Sit down and consider what design principles and best practices are and then document it. This will help people who contributes to your standard as well.
+
+## RHEL architecture
+Architectural decisions related to Red Hat Enterprise Linux.
+
+### Infrastructure design
+Infrastructure related decisions.
+
+* **Capacity mangement** - What happens if a system runs out of resources such as CPU, memory, disk or even network bandwidth? Design your standard so that you can easily extend these resources. This commonly requires some cross-team collaboration with teams who manages these resources.
+* **Insights management** - Red Hat Insights is included in each RHEL subscription. It provides you with a host of information. About the patch state of systems, known vulnerabilities. Also, are you tired of working reactively? It can also provide you advise on how to work proactively to ensure that issues which may become problems - does not.
+* **Image build system** - If you install RHEL by creating a system from an image, such as virtual machine template or etc, then you will need a system dedicated to building such images. Also, if you are to use Red Hat Enterprise Linux Image Mode (RHEL 9.6+, 10+), you will need a system to build those images. [Learn more about that here](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux-10/image-mode). 
+* **Red Hat Satellite** - It's not uncommon that this is something you get immediately for your first release, and there are some good reasons for that. Red Hat Satellite helps with a host of challenges related to subscription management, repository management, automation and compliance reporting. [Learn more about Red Hat Satellite, here.](https://www.redhat.com/en/technologies/management/satellite)
+* **Security compliance (PCI DSS, CIS, etc)** - Sooner or later, most organizations needs to comply with some specific security standard. For you, that likely means you need to cater for that, including providing hardening and compliance reporting for your RHEL platform. But how? You can for example use Red Hat Satellite and Ansible Automation Platform for this.
+
+### RHEL design
+Design of your Red Hat Enterprise Linux standard.
+
+* **Security baseline** - Before you have hundreds of RHEL servers installed, you should create a security baseline which hardens the security posture of you platform. This may also include specific hardening profiles you create for specific security compliance with standards such as PCI DSS, CIS, HIPAA, etc.
+* **Automated post config** - All the things which you have done manually after installing RHEL, are now things which you need to automate. If you do not do this, you will not be able to scale your install base without some very significant issues. This is also how you can make the consumption of your standard simpler than running off to some cloud provider, by applying all needed configuration for a specific system - automatically. This is also key as it relates to security compliance and hardening - that it is done immediately as the system is created.
+* **Kickstart** - If you are installing a lot of systems on baremetal servers, it's time for you to consider automating that. If you cannot use image based installations, you will for Red Hat Enterprise Linux use kickstart to accomplish this. Red Hat Satellite supports kickstart installations, if you do not have a system for this already.
+* **Image building** - If you are delivering your standard in the form of virtual machine or container images, then you to design your standard for these purposes.
+* **Automated patch management** - In order to be able to scale your install base to serveral hundreds of systems - while you at the same time patch these systems on a regular basis - you need automated patch management. Systems such as Red Hat Satellite or Ansible Automation Platform can help you accomplish this.
+
+## Development tool chain
+Features related to the development tool chain.
+
+* **IDE** - This is not a hard requirement, but if you standardize what Integrated Development Environment (VSCode, vim, etc), then that may help people later on as you perform more and more development type tasks in the maintenence of your platform.
+* **CI/CD** - In order to automate your development processes, you need CI/CD. But what CI/CD platform should you use for this? Decide!
+* **Testing** - Decide how you will technically perform tests of you RHEL standard platform. Will you use some automation which installs your standard on a loop and does some integration tests after each loop? Do you have some standard test platform which should be used? Being able to prove that your standard is intact as you release new version of it is vital for almost any advanced features, so don't skip this.
+* **Building** - As it relates to shipping software to RHEL, if you are not using containers, you should be using RPMs. The challenge is that not many people know how to build RPMs, so it may be a good thing for you to provide a system where users of the platform can more easily build their RPMs.
+* **Security gates** - Related to the creation of your standard, it's increasingy a common requirement that you have secured the development process. This is done by introducing security gates which for example automatically signs or cryptographically validates resources built or used.
+* **Deployment** For you to be able to automatically test your standard, it needs to be deployed automatically. But how? Perhaps using some automation tool, such as Ansible or Terraform - which are triggered from your RHEL Platform development CI/CD pipeline.
+
+## Onboarding
+Technology implementations related to onboarding.
+
+* **Landing page** - When someone gets onboarded to your platform. They need a place to start their onboarding process. This is typically a wiki page or webpage maintained by the core platform team.
+* **Platform documentation** - A common part of a technical platform implementation, you have documentation which decribes to other people how the platform works.
+* **Link collection** - A good way to help people who get onboarded is by maintaining a list of useful links.
+
+# Platform management 
+Administrative features which helps with the development or maintenence of the platform.
+
+* **RHEL Success Plan** - There is a basic success plan in place for the platform, outlining what KPIs we want to impact. We are often lacking performance monitoring for these KPIs.
+* **KPIs (Master doc)** - You have a document describing KPIs which we monitor, if they are not a part of the overall AAP success plan. 
diff --git a/mkdocs.yml b/mkdocs.yml
index dceb571..4028962 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -40,6 +40,11 @@ nav:
   - Security:
     - Welcome to security: security/welcome.md
     - Certificate management: security/certificate-management.md
+  - Operational Model:
+    - "What is an operational model": operational-model/intro.md
+    - "Minimal Viable Product": operational-model/mvp.md
+    - "2.0": operational-model/twozero.md
+    - "Advanced": operational-model/advanced.md
 markdown_extensions:
   - admonition
   - pymdownx.details