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: 
  == 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 too long. For assemblies and task modules,
  use a gerund form in headings, such as:
  
  * Creating
  
negative.code: 
  Do not use "Overview" as a heading.
  
  Do not use backticks or other markup in headings.
  
  === Discrete headings
  
  If you have a section heading that you do not want to appear in the TOC (like if you think that some section is not worth showing up or if there are already too many nested levels), you can use a discrete (or floating) heading:
  
  http://asciidoctor.org/docs/user-manual/#discrete-or-floating-section-titles
  
  A discrete heading also will not get a section number in the Customer Portal build of the doc. Previously, we would use plain bold mark-up around a heading like this, but discrete headings also allow you to ignore section nesting rules (like jumping from a `==` section level to a `====` level if you wanted for some style reason).
  
  To use a discrete heading, just add `[discrete]` to the line before your unique ID. For example:
  
  ----
  [discrete]
  