openshift · dfitzmau · Oct 29, 2025 · Oct 24, 2025
diff --git a/contributing_to_docs/tools_and_setup.adoc b/contributing_to_docs/tools_and_setup.adoc
@@ -1,5 +1,6 @@
 [id="contributing-to-docs-tools-and-setup"]
 = Install and set up the tools and software
+
 :icons:
 :toc: macro
 :toc-title:

diff --git a/modules/recommended-node-host-practices.adoc b/modules/recommended-node-host-practices.adoc
@@ -2,6 +2,7 @@
 //
 // * post_installation_configuration/node-tasks.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="recommended-node-host-practices_{context}"]
 = Recommended node host practices
 

diff --git a/modules/recommended-scale-practices.adoc b/modules/recommended-scale-practices.adoc
@@ -2,6 +2,7 @@
 //
 // * scalability_and_performance/recommended-performance-scale-practices/recommended-control-plane-practices.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="recommended-scale-practices_{context}"]
 = Recommended practices for scaling the cluster
 

diff --git a/modules/red-hat-marketplace-features.adoc b/modules/red-hat-marketplace-features.adoc
@@ -2,6 +2,7 @@
 //
 // * applications/red-hat-marketplace.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="red-hat-marketplace-features_{context}"]
 = Red Hat Marketplace features
 

diff --git a/modules/registry-authentication-enabled-registry-overview.adoc b/modules/registry-authentication-enabled-registry-overview.adoc
@@ -2,6 +2,7 @@
 //
 // * registry/index.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="registry-authentication-enabled-registry-overview_{context}"]
 = Authentication enabled Red Hat registry
 

diff --git a/modules/registry-integrated-openshift-registry.adoc b/modules/registry-integrated-openshift-registry.adoc
@@ -3,6 +3,7 @@
 //* registry/registry-options
 //* registry/index.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="registry-integrated-openshift-registry_{context}"]
 = Integrated {product-registry}
 

diff --git a/modules/registry-operator-configuration-resource-overview-aws-s3.adoc b/modules/registry-operator-configuration-resource-overview-aws-s3.adoc
@@ -2,6 +2,7 @@
 //
 // * registry/configuring-registry-storage-aws-user-infrastructure.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="registry-operator-configuration-resource-overview-aws-s3_{context}"]
 = Image Registry Operator configuration parameters for AWS S3
 

diff --git a/modules/registry-operator-configuration-resource-overview-gcp-gcs.adoc b/modules/registry-operator-configuration-resource-overview-gcp-gcs.adoc
@@ -2,6 +2,7 @@
 //
 // * openshift_images/configuring-registry-operator.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="registry-operator-configuration-resource-overview-gcp-gcs_{context}"]
 = Image Registry Operator configuration parameters for {gcp-short} GCS
 

diff --git a/modules/registry-operator-configuration-resource-overview-openstack-swift.adoc b/modules/registry-operator-configuration-resource-overview-openstack-swift.adoc
@@ -2,6 +2,7 @@
 //
 // * registry/configuring_registry_storage/configuring-registry-storage-openstack-user-infrastructure.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="registry-operator-configuration-resource-overview-openstack-swift_{context}"]
 = Image Registry Operator configuration parameters for {rh-openstack} Swift
 

diff --git a/modules/registry-operator-distribution-across-availability-zones.adoc b/modules/registry-operator-distribution-across-availability-zones.adoc
@@ -2,7 +2,7 @@
 //
 // * openshift_images/configuring-registry-operator.adoc
 
-
+:_mod-docs-content-type: REFERENCE
 [id="registry-operator-distribution-across-availability-zones_{context}"]
 = Image Registry Operator distribution across availability zones
 

diff --git a/modules/registry-quay-overview.adoc b/modules/registry-quay-overview.adoc
@@ -2,6 +2,7 @@
 //
 // * registry/index.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="registry-quay-overview_{context}"]
 = {quay} registries
 

diff --git a/modules/registry-removed.adoc b/modules/registry-removed.adoc
@@ -13,6 +13,7 @@
 // * registry/configuring_registry_storage/configuring-registry-storage-baremetal.adoc
 // * registry/configuring_registry_storage/configuring-registry-storage-vsphere.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="registry-removed_{context}"]
 = Image registry removed during installation
 

diff --git a/modules/sample-windows-workload-deployment.adoc b/modules/sample-windows-workload-deployment.adoc
@@ -2,6 +2,7 @@
 //
 // * windows_containers/scheduling-windows-workloads.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="sample-windows-workload-deployment_{context}"]
 = Sample Windows container workload deployment
 

diff --git a/modules/samples-operator-configuration.adoc b/modules/samples-operator-configuration.adoc
@@ -2,7 +2,7 @@
 //
 // * openshift_images/configuring_samples_operator.adoc
 
-
+:_mod-docs-content-type: REFERENCE
 [id="samples-operator-configuration_{context}"]
 = Cluster Samples Operator configuration parameters
 

diff --git a/modules/scheduling-virtual-hardware-update-on-vsphere.adoc b/modules/scheduling-virtual-hardware-update-on-vsphere.adoc
@@ -2,6 +2,7 @@
 //
 // updating/updating_a_cluster/updating-hardware-on-nodes-running-in-vsphere.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="scheduling-virtual-hardware-update-on-vsphere_{context}"]
 = Scheduling an update for virtual hardware on vSphere
 

diff --git a/modules/sdpolicy-logging.adoc b/modules/sdpolicy-logging.adoc
@@ -2,6 +2,7 @@
 //
 // * osd_architecture/osd_policy/osd-service-definition.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="sdpolicy-logging_{context}"]
 = Logging
 {product-title} provides optional integrated log forwarding to Amazon CloudWatch (on AWS) or {gcp-full} Logging (on {gcp-short}).

diff --git a/modules/sdpolicy-monitoring.adoc b/modules/sdpolicy-monitoring.adoc
@@ -2,6 +2,7 @@
 //
 // * osd_architecture/osd_policy/osd-service-definition.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="sdpolicy-monitoring_{context}"]
 = Monitoring
 

diff --git a/modules/sdpolicy-networking.adoc b/modules/sdpolicy-networking.adoc
@@ -2,6 +2,7 @@
 //
 // * osd_architecture/osd_policy/osd-service-definition.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="sdpolicy-networking_{context}"]
 = Networking
 

diff --git a/modules/sdpolicy-platform.adoc b/modules/sdpolicy-platform.adoc
@@ -3,6 +3,7 @@
 //
 // * osd_architecture/osd_policy/osd-service-definition.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="sdpolicy-platform_{context}"]
 = Platform
 

diff --git a/modules/sdpolicy-security.adoc b/modules/sdpolicy-security.adoc
@@ -2,6 +2,7 @@
 //
 // * osd_architecture/osd_policy/osd-service-definition.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="sdpolicy-security_{context}"]
 = Security
 

diff --git a/modules/sdpolicy-storage.adoc b/modules/sdpolicy-storage.adoc
@@ -3,6 +3,7 @@
 //
 // * osd_architecture/osd_policy/osd-service-definition.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="sdpolicy-storage_{context}"]
 = Storage
 

diff --git a/modules/security-build-designing.adoc b/modules/security-build-designing.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-build.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-build-designing_{context}"]
 = Designing your build process
 

diff --git a/modules/security-build-inputs.adoc b/modules/security-build-inputs.adoc
@@ -2,21 +2,18 @@
 //
 // * security/container_security/security-build.adoc
 
+:_mod-docs-content-type: PROCEDURE
 [id="security-build-inputs_{context}"]
 =  Securing inputs during builds
 
-In some scenarios, build operations require credentials to access dependent
-resources, but it is undesirable for those credentials to be available in the
-final application image produced by the build. You can define input secrets for
-this purpose.
+In some scenarios, build operations require credentials to access dependent resources, but it is undesirable for those credentials to be available in the final application image produced by the build. You can define input secrets for this purpose.
 
-For example, when building a Node.js application, you can set up your private
-mirror for Node.js modules. To download modules from that private
-mirror, you must supply a custom `.npmrc` file for the build that contains
-a URL, user name, and password. For security reasons, you do not want to expose
-your credentials in the application image.
+For example, when building a Node.js application, you can set up your private mirror for Node.js modules. To download modules from that private mirror, you must supply a custom `.npmrc` file for the build that contains
+a URL, user name, and password. For security reasons, you do not want to expose your credentials in the application image.
 
-Using this example scenario, you can add an input secret to a new `BuildConfig` object:
+Using this example scenario, you can add an input secret to a new `BuildConfig` object.
+
+.Procedure
 
 . Create the secret, if it does not exist:
 +
@@ -25,8 +22,7 @@ Using this example scenario, you can add an input secret to a new `BuildConfig`
 $ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc
 ----
 +
-This creates a new secret named `secret-npmrc`, which contains the base64
-encoded content of the `~/.npmrc` file.
+This creates a new secret named `secret-npmrc`, which contains the base64 encoded content of the `~/.npmrc` file.
 
 . Add the secret to the `source` section in the existing `BuildConfig` object:
 +

diff --git a/modules/security-build-knative.adoc b/modules/security-build-knative.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-build.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-build-knative_{context}"]
 = Building Knative serverless applications
 

diff --git a/modules/security-build-management.adoc b/modules/security-build-management.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-build.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-build-management_{context}"]
 = Managing builds
 

diff --git a/modules/security-build-once.adoc b/modules/security-build-once.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-build.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-build-once_{context}"]
 = Building once, deploying everywhere
 

diff --git a/modules/security-container-content-external-scanning.adoc b/modules/security-container-content-external-scanning.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-container-content.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="security-container-content-external-scanning_{context}"]
 = Integrating external scanning
 

diff --git a/modules/security-container-content-inside.adoc b/modules/security-container-content-inside.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-container-content.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-container-content-inside_{context}"]
 = Securing inside the container
 

diff --git a/modules/security-container-content-scanning.adoc b/modules/security-container-content-scanning.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-container-content.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-container-content-scanning_{context}"]
 = Security scanning in {op-system-base}
 

diff --git a/modules/security-container-content-universal.adoc b/modules/security-container-content-universal.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-container-content.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-container-content-universal_{context}"]
 = Creating redistributable images with UBI
 

diff --git a/modules/security-deploy-continuous.adoc b/modules/security-deploy-continuous.adoc
@@ -2,12 +2,10 @@
 //
 // * security/container_security/security-deploy.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-deploy-continuous_{context}"]
 = Automating continuous deployment
 
-You can integrate your own continuous deployment (CD) tooling with
-{product-title}.
+You can integrate your own continuous deployment (CD) tooling with {product-title}.
 
-By leveraging CI/CD and {product-title}, you can automate the process of
-rebuilding the application to incorporate the latest fixes, testing, and
-ensuring that it is deployed everywhere within the environment.
+By leveraging CI/CD and {product-title}, you can automate the process of rebuilding the application to incorporate the latest fixes, testing, and ensuring that it is deployed everywhere within the environment.
diff --git a/modules/security-deploy-image-sources.adoc b/modules/security-deploy-image-sources.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-deploy.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="security-deploy-image-sources_{context}"]
 = Controlling what image sources can be deployed
 

diff --git a/modules/security-deploy-signature.adoc b/modules/security-deploy-signature.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-deploy.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-deploy-signature_{context}"]
 = Using signature transports
 

diff --git a/modules/security-deploy-trigger.adoc b/modules/security-deploy-trigger.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-deploy.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-deploy-trigger_{context}"]
 = Controlling container deployments with triggers
 

diff --git a/modules/security-hardening-how.adoc b/modules/security-hardening-how.adoc
@@ -2,8 +2,8 @@
 //
 // * security/container_security/security-hardening.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-hardening-how_{context}"]
-
 = Choosing how to harden {op-system}
 
 Direct modification of {op-system} systems in {product-title} is discouraged. Instead, you should think of modifying systems in pools of nodes, such as worker nodes and control plane nodes. When a new node is needed, in non-bare metal installs, you can request a new node of the type you want and it will be created from an {op-system} image plus the modifications you created earlier.

diff --git a/modules/security-hardening-what.adoc b/modules/security-hardening-what.adoc
@@ -2,8 +2,8 @@
 //
 // * security/container_security/security-hardening.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-hardening-what_{context}"]
-
 = Choosing what to harden in {op-system}
 ifdef::openshift-origin[]
 For information on how to approach security for any {op-system-base} system, see the link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9#Security[Security] category in the Red{nbsp}Hat Enterprise Linux 9 documentation.

diff --git a/modules/security-hosts-vms-openshift.adoc b/modules/security-hosts-vms-openshift.adoc
@@ -2,8 +2,10 @@
 //
 // * security/container_security/security-hosts-vms.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-hosts-vms-openshift_{context}"]
 = Securing {product-title}
+
 When you deploy {product-title}, you have the choice of an
 installer-provisioned infrastructure (there are several available platforms)
 or your own user-provisioned infrastructure.

diff --git a/modules/security-hosts-vms-rhcos.adoc b/modules/security-hosts-vms-rhcos.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-hosts-vms.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-hosts-vms-rhcos_{context}"]
 = Securing containers on {op-system-first}
 

diff --git a/modules/security-hosts-vms-vs-containers.adoc b/modules/security-hosts-vms-vs-containers.adoc
@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-hosts-vms.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-hosts-vms-vs-containers_{context}"]
 = Comparing virtualization and containers