Some changes based on the discussion with SME and CS

content/learn/about-pattern-tiers-types.adoc

@@ -12,8 +12,8 @@ aliases: /learn/about-pattern-tiers-types
 :_content-type: ASSEMBLY
 include::modules/comm-attributes.adoc[]
 
-[id="pattern-type"]
-== About the {solution-name-upstream} tiers
+[id="pattern-tiers"]
+== {solution-name-upstream} tiers
 
 The different tiers of {solution-name-upstream} are designed to facilitate ongoing maintenance, support, and testing effort for a pattern. To contribute to a pattern that suits your solution or to learn about onboarding your own pattern, understand the following pattern tiers.
 
@@ -27,8 +27,8 @@ The patterns in this tier might be in a work-in-progress state; and they might h
 
 
 |link:/requirements/tested/[{tested-tier-first}]
-|A pattern categorized under the {tested} tier implies that the pattern might have been recently working on at least one recent version of {rh-ocp}. Qualifying for this tier might require  additional work for the pattern’s owner, who might be a partner or a motivated subject matter expert (SME).
-//Additional work such as?
+|A pattern categorized under the {tested} tier implies that the pattern might have been recently working on at least one recent version of {rh-ocp}. Qualifying for this tier might require additional work for the pattern’s owner, who might be a partner or a motivated subject matter expert (SME).
+
 The patterns in this tier might have a defined business problem with a demonstration. The patterns  might have a manual or automated test plan, which passes at least once for each new {rh-ocp} minor version.
 
 |link:/requirements/maintained/[{maintained-tier-first}]

content/learn/implementation.adoc

@@ -33,12 +33,12 @@ These are optional or desirable features, but their absence does not hinder the
 . Patterns must be useful without all content stored in private Git repositories.
 . Patterns must include a list of names and versions of all the products and projects that the pattern consumes.
 . Patterns must be useful without any sample applications that are private or that lack public sources.
-//AI:why application was styled that way
-Patterns must *not* become useless due to bit rot or opaque incompatibilities in closed source applications.
+
+. Patterns must *not* become useless due to bit rot or opaque incompatibilities in closed source applications.
 . Patterns must *not* store sensitive data elements, including but not limited to, passwords in Git repositories.
 . Patterns must be possible to deploy on any installer-provisioned infrastructure OpenShift cluster (BYO).
-//AI:why Patterns and Managed clusters is styled that way
-We distinguish between the provisioning and configuration requirements of the initial cluster (`Patterns`) and of clusters or machines that are managed by the initial cluster (see `Managed clusters`).
++
+We distinguish between the provisioning and configuration requirements of the initial cluster (`Patterns`) and of clusters or machines that are managed by the initial cluster (`Managed clusters`).
 . Patterns must use a standardized https://github.com/validatedpatterns/common/tree/main/clustergroup[clustergroup] Helm chart as the initial {rh-gitops} application that describes all namespaces, subscriptions, and any other GitOps applications which contain the configuration elements that make up the solution.
 . Managed clusters must operate on the premise of `eventual consistency` (automatic retries, and an expectation of idempotence), which is one of the essential benefits of the GitOps model.
 . Imperative elements must be implemented as idempotent code stored in Git repository.
@@ -78,6 +78,6 @@ For example, Bucket Notification is a capability in the {med-pattern} that could
 . Patterns can consume Operators from established partners (for example, Hashicorp Vault, and Seldon)
 . Patterns can include managed clusters.
 . Patterns can include details or automation for provisioning managed clusters, or rely on the admin to pre-provision them out-of-band.
-//AI:why initial hub clusters was styled that way.
-. Patterns can also choose to model multi-cluster solutions as an uncoordinated collection of `initial hub clusters`
+
+. Patterns can also choose to model multi-cluster solutions as an uncoordinated collection of initial hub clusters.
 . Imperative elements can interact with cluster state or external influences.

content/learn/maintained.adoc

@@ -18,23 +18,23 @@ include::modules/comm-attributes.adoc[]
 
 A pattern categorized under the {maintained} tier implies that the pattern was known to be functional on all currently supported extended update support (EUS) versions of {rh-ocp}. Qualifying for this tier might require additional work for the pattern’s owner who might be a partner or a sufficiently motivated subject matter expert (SME).
 
-[id="nominating-a-community-pattern-to-become-validated"]
-== Nominating a maintained pattern for promotion to a validated pattern
+[id="nominating-a-pattern-for-maintained-tier"]
+== Nominating a pattern for the {maintained} tier
 
-If your {maintained} pattern qualifies or meets the criteria for promotion to a {validated} pattern, submit your nomination to mailto:[email protected][[email protected]].
+If your pattern qualifies or meets the criteria for {maintained} tier, submit your nomination to mailto:[email protected][[email protected]].
 
 [NOTE]
 ====
 Each {maintained} pattern represents an ongoing maintenance, support, and testing effort. Finite team capacity means that it is not possible for the team to take on this responsibility for all {solution-name-upstream}.
 ====
-//NOte sure about the following bits - needs discussion
+
 For this reason we have designed the tiers and our processes to facilitate this to occur outside of the team by any sufficiently motivated party, including other parts of Red Hat, partners, and even customers.
 
 In limited cases, the {solution-name-upstream} team may consider taking on that work, however, it is recommended that you contact the team at least 4 weeks prior to the end of a given quarter for the necessary work to be considered as part of the following quarter's planning process.
 
 
 [id="requirements-maintained-tier"]
-== Requirements
+== Requirements for the {maintained} tier
 
 The {maintained} patterns have deliverable and requirements in addition to those
 specified for the link:/requirements/tested/[Tested tier].
@@ -54,12 +54,12 @@ A {maintained} pattern must continue to meet the following criteria to remain in
 * A {maintained} pattern must fix breakage in timely manner.
 * A {maintained} pattern must document their support policy.
 +
-//Needs review by legal?
+
 The individual products used in a {solution-name-upstream} are backed by the full {redhat} support experience conditional on the customer's subscription to those products, and the individual products`s support policy.
 +
 Additional components in a {solution-name-upstream} that are not supported by {redhat}; for example, Hashicorp Vault, and Seldon Core, require a customer to obtain support from that vendor directly.
 +
-//very motivated? will we or won't we?
+
 The {solution-name-upstream} team is will try to address any problems in the {validated-patterns-op}, and in the common Helm charts, but cannot not offer any SLAs at this time.
 +
 //TODO: Create an aDoc version of our support statement slide

content/learn/sandbox.adoc

@@ -18,8 +18,8 @@ include::modules/comm-attributes.adoc[]
 
 A pattern categorized under the {sandbox} tier provides you with an entry point to onboard to the {solution-name-upstream}. The minimum requirement to qualify for the {sandbox} tier is that you must start with the patterns framework and include minimal documentation.
 
-[id="onboarding-existing-implementations"]
-== Onboarding existing implementations
+[id="nominating-a-pattern-for-sandbox-tier"]
+== Nominating a pattern for the {sandbox} tier
 
 //TODO: A short note on the value of converting existing implementations
 
@@ -33,7 +33,6 @@ In both scenarios the originating team can choose where to host the primary repo
 
 [id="requirements-sandbox-tier"]
 == Requirements for the {sandbox} tier
-// should this be sandbox tier?
 Consider these requirements for all {sandbox} tier.
 
 [id="must-sandbox-tier"]

content/learn/tested.adoc

@@ -17,10 +17,10 @@ include::modules/comm-attributes.adoc[]
 
 The {tested} tier provides you with additional collateral and reassurance that the pattern was known to be recently working on at least one recent version of {rh-ocp}. Inclusion in this tier requires some additional work for the pattern's owner - which might be a partner or a sufficiently motivated subject matter expert (SME).
 
-[id="nominating-a-community-pattern-to-become-maintained"]
-== Nominating a tested pattern for promotion to a maintained pattern
+[id="nominating-a-pattern-for-tested-tier"]
+== Nominating a a pattern for the {tested} tier
 
-If your {tested} pattern qualifies or meets the criteria for promotion to a {validated} pattern, submit your nomination to  mailto:[email protected][[email protected]].
+If your pattern qualifies or meets the criteria for {tested} tier, submit your nomination to mailto:[email protected][[email protected]].
 
 [NOTE]
 ====
@@ -45,11 +45,9 @@ A {tested} pattern must continue to meet the following criteria to remain in the
 * A {tested} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements]
 * A {tested} pattern must be meaningful without specialized hardware, including flavors of architectures not explicitly supported.
 +
-Qualification is a {solution-name-upstream} TOC decision with input from the pattern owner.
-//AI: What's TOC?
+Qualification is a {solution-name-upstream} Technical Oversight Committee (TOC) decision with input from the pattern owner.
 * A {tested} pattern must have their implementation reviewed by the patterns team to ensure that it is sufficiently flexible to function across a variety of platforms, customer environments, and any relevant verticals.
-* A {tested} pattern must include a standardized architecture drawing, created with (or at least conforming to) the PAC tooling
-//AI: What's PAC
+* A {tested} pattern must include a standardized architecture drawing, created with (or at least conforming to) the standard {solution-name-upstream} tooling
 * A {tested} pattern must include a written guide for others to follow when demonstrating the pattern
 * A {tested} pattern must include a test plan covering all features or attributes being highlighted by the demonstration guide. Negative flow tests (such as resiliency or data retention in the presence of network outages) are also limited to scenarios covered by the demonstration guide.
 +