anchor.diff:  
   An object reference is when you are referring to the actual instance of an API object, where the object name is important.
   
  -When referring to actual instances of API objects, use link:https://en.wikipedia.org/wiki/Camel_case#Variations_and_synonyms[PascalCase] and mark it up as monospace in backticks (````). Be sure to match the proper object type (or `kind` in Kubernetes terms); for example, do not add an "s" to make it plural. *Only follow this guidance if you are explicitly referring to the API object (for example, when editing an object in the CLI or viewing an object in the web console).*
  +When referring to actual instances of API objects, use link:https://en.wikipedia.org/wiki/Camel_case#Variations_and_synonyms[PascalCase] and mark it up as monospace in backticks (````).
  +
  +[NOTE]
  +====
  +Do not use backticks or other markup in headings.
  +====
  +
  +Be sure to match the proper object type (or `kind` in Kubernetes terms); for example, do not add an "s" to make it plural. *Only follow this guidance if you are explicitly referring to the API object (for example, when editing an object in the CLI or viewing an object in the web console).*
   
   For example:
   
  
positive.code: 
  > You can deploy applications on OKD.
  
  Considering that we use distinct branches to keep content for product versions
  separated, global use of `{product-version}` across all branches is probably
  less useful, but it is available if you come across a requirement for it. Just consider
  how it will render across any branches that the content appears in.
  
  If it makes more sense in context to refer to the major version of the product
  instead of a specific minor version (for example, if comparing how something in
  OpenShift Container Platform 4 differs from OpenShift Container Platform 3),
  just use the major version number. Do not prepend with a `v`, as in `v3` or `v4`.
  
  Do not use markup in headings.
  
  *Do not use internal company server names in command or example output*. See
  suggested host name examples
  https://docs.openshift.com/container-platform/3.11/install/example_inventories.html#multi-masters-single-etcd-using-native-ha[here].
  
  
  == Links, hyperlinks, and cross references
  
negative.code: 
  == Assembly/module file names
  
  Try to shorten the file name as much as possible _without_ abbreviating important terms that may cause confusion. For example, the `managing-authorization-policies.adoc` file name would be appropriate for an assembly titled "Managing Authorization Policies".
  
  == Directory names
  
  If you create a directory with a multiple-word name, separate each word with an underscore, for example `backup_and_restore`. Do not create a top-level directory in the repository without checking with the docs team. In the main OpenShift docs, you can create one level of subdirectories. In the docs for features that are designed to be used with OpenShift, such as Service Mesh and OpenShift virtualization, you can create two levels of subdirectories.
  
  == Assembly/Module titles and section headings
  
  Use sentence case in all titles and section headings. See http://www.titlecase.com/ or https://convertcase.net/ for a conversion tool.
  
  Try to be as descriptive as possible with the title or section headings
  without making them unnecessarily long. For assemblies and task modules,
  use a gerund form in headings, such as:
  
  * Creating
  