Addressed Dan's feedback

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

@@ -21,18 +21,18 @@ The different tiers of {solution-name-upstream} are designed to facilitate ongoi
 |Pattern tier|Description
 
 |link:/requirements/sandbox/[{sandbox-tier-first}]
-|A pattern categorized under the {sandbox} tier provides you with an entry point to onboard to  {solution-name-upstream}. The minimum requirement to qualify for the {sandbox} tier is to start with the patterns framework and include minimal documentation.
+|A pattern categorized under the {sandbox} tier provides you with an entry point to onboard to {solution-name-upstream}. The minimum requirement to qualify for the {sandbox} tier is to start with the patterns framework and include minimal documentation.
 
 The patterns in this tier might be in a work-in-progress state; and they might have been manually tested on a limited set of platforms.
 
 
 |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).
 
-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.
+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}]
-|A pattern categorized under the {maintained} tier implies that the pattern might have been  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 motivated SME.
+|A pattern categorized under the {maintained} tier implies that the pattern might have been 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 motivated SME.
 
 The patterns in this tier might have a formal release process with patch releases. They might have continuous integration (CI) automation testing.
 

content/learn/implementation.adoc

@@ -15,16 +15,16 @@ include::modules/comm-attributes.adoc[]
 [id="technical-requirements"]
 == Technical requirements
 
-Consider these requirements specific to the implementation of all {solution-name-upstream} and their respective tiers.
+Consider these requirements specific to the implementation of all {solution-name-upstream} and their tiers.
 
 The requirements are categorized as follows:
 
 Must::
-These are non-negotiable, core requirements that must be implemented.
+These are nonnegotiable, core requirements that must be implemented.
 Should::
 These are important but not critical; their implementation enhances the pattern.
 Can::
-These are optional or desirable features, but their absence does not hinder the implementation of a  pattern.
+These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
 
 [id="must-implementation-requirements"]
 === Must
@@ -33,12 +33,11 @@ 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.
-
-. 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 *not* degrade due to lack of updates 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).
 +
-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`).
+{solution-name-upstream} 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.
@@ -52,15 +51,13 @@ We distinguish between the provisioning and configuration requirements of the in
 . Patterns should embody the link:https://www.redhat.com/en/products/open-hybrid-cloud[Open Hybrid Cloud model] unless there is a compelling reason to limit the availability of functionality to a specific platform or topology.
 . Patterns should use industry standards and {redhat} products for all required tooling.
 +
-Patterns prefer current best practices at the time of pattern development. Solutions that do not conform to best practices should expect to justify non-conformance or expend engineering effort to conform.
+Patterns require current best practices at the time of pattern development. Solutions that do not conform to best practices should expect to justify non-conformance or expend engineering effort to conform.
 . Patterns should *not* make use of upstream or community Operators and images except, depending on the market segment, where it is critical to the overall solution.
 +
 Such Operators are forbidden to be deployed into an increasing number of customer environments, which limits the pattern reuse. Alternatively, consider to productize the Operator, and build it in-cluster from trusted sources as part of the pattern.
-
 . Patterns should be decomposed into modules that perform a specific function, so that they can be reused in other patterns.
 +
 For example, Bucket Notification is a capability in the {med-pattern} that could be used for other solutions.
-
 . Patterns should use {rh-ansible} to drive the declarative provisioning and management of managed hosts, for example, {rhel-first}. See also `Imperative elements`.
 . Patterns should use {rh-rhacm-first} to manage policy and compliance on any managed clusters.
 . Patterns should use {rh-rhacm} and a https://github.com/validatedpatterns/common/tree/main/acm[standardized RHACM chart] to deploy and configure {rh-gitops-short} to managed clusters.
@@ -78,6 +75,5 @@ 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.
-
 . 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

@@ -39,13 +39,22 @@ In limited cases, the {solution-name-upstream} team may consider taking on that
 The {maintained} patterns have deliverable and requirements in addition to those
 specified for the link:/requirements/tested/[Tested tier].
 
+The requirements are categorized as follows:
+
+Must::
+These are nonnegotiable, core requirements that must be implemented.
+Should::
+These are important but not critical; their implementation enhances the pattern.
+Can::
+These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
+
 [id="must-maintained-tier"]
 === Must
 
 A {maintained} pattern must continue to meet the following criteria to remain in {maintained} tier:
 
 * A {maintained} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements].
-. A {maintained} pattern must only make use of components that are either supported, or easily substituted for supportable equivalents, for example, HashiCorp vault which has community and enterprise variants.
+* A {maintained} pattern must only make use of components that are either supported, or easily substituted for supportable equivalents, for example, HashiCorp vault which has community and enterprise variants.
 * A {maintained} pattern must *not* rely on functionality in tech-preview, or hidden behind feature gates.
 * A {maintained} pattern must have their architectures reviewed by the Product Manager (PM), Technical Product Manager (TPM), or Technical Marketing Manager (TMM) of each {redhat} product they consume to ensure consistency with the product teams` intentions and roadmaps.
 * A {maintained} pattern must include a presentation slides oriented around the business problem being solved and intended for use by the field to sell and promote the solution.
@@ -58,10 +67,9 @@ A {maintained} pattern must continue to meet the following criteria to remain in
 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.
-+
 
 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
 
 [NOTE]
@@ -72,4 +80,4 @@ The {maintained} patterns *do not* imply an obligation of support for partner or
 [id="can-maintained-tier"]
 === Can
 
-. If you are creating {solution-name-upstream}, you can provide your own SLA.
+* If you are creating {solution-name-upstream}, you can provide your own SLA.

content/learn/sandbox.adoc

@@ -35,6 +35,15 @@ In both scenarios the originating team can choose where to host the primary repo
 == Requirements for the {sandbox} tier
 Consider these requirements for all {sandbox} tier.
 
+The requirements are categorized as follows:
+
+Must::
+These are nonnegotiable, core requirements that must be implemented.
+Should::
+These are important but not critical; their implementation enhances the pattern.
+Can::
+These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
+
 [id="must-sandbox-tier"]
 === Must
 A {sandbox} pattern must continue to meet the following criteria to remain in the {sandbox} tier:
@@ -44,11 +53,9 @@ A {sandbox} pattern must continue to meet the following criteria to remain in th
 * A {sandbox} pattern must include a top-level README file that highlights the business problem and how the pattern solves it.
 * A {sandbox} pattern must include an architecture drawing. The specific tool or format is flexible as long as the meaning is clear.
 * A {sandbox} pattern must undergo an informal technical review by a community leader to ensure that it meets basic reuse standards.
-* A {sandbox} pattern must undergo an informal architecture review by a community leader to ensure that the solution has the right components, and they are generally being used as intended.
+* A {sandbox} pattern must undergo an informal architecture review by a community leader to ensure that the solution has the right components, and they are generally being used as intended. For example, not using a database as a message bus.
 +
-For example, not using a database as a message bus.
-As community leaders, contributions from within {redhat} might be subject to a higher level of scrutiny.
-While we strive to be inclusive, the community will have quality standards and generally using the framework does not automatically imply a solution is suitable for the community to endorse/publish.
+As community leaders, contributions from within {redhat} might be subject to a higher level of scrutiny. While we strive to be inclusive, the community will have quality standards and generally using the framework does not automatically imply a solution is suitable for the community to endorse/publish.
 * A {sandbox} pattern must document their support policy.
 
 [NOTE]

content/learn/tested.adoc

@@ -15,7 +15,7 @@ include::modules/comm-attributes.adoc[]
 [id="about-tested-tier"]
 = About the {tested-tier-first}
 
-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).
+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-pattern-for-tested-tier"]
 == Nominating a a pattern for the {tested} tier
@@ -33,36 +33,45 @@ In limited cases, the {solution-name-upstream} team may consider taking on that
 
 
 [id="requirements-tested-tier"]
-== Requirements
+== Requirements for the {tested} tier
 
 A {tested} patterns have deliverable and requirements in addition to those specified for the link:/requirements/sandbox/[Sandbox tier].
 
+The requirements are categorized as follows:
+
+Must::
+These are nonnegotiable, core requirements that must be implemented.
+Should::
+These are important but not critical; their implementation enhances the pattern.
+Can::
+These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
+
 [id="must-tested-tier"]
 === Must
 
 A {tested} pattern must continue to meet the following criteria to remain in the {tested} tier:
 
-* A {tested} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements]
+* 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} 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 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 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.
 +
 The test plan must define how to validate if the pattern has been successfully deployed and is functionally operational.
-Example: https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment]
-+
+Example: https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment].
+
 //TODO: Convert above link to adoc
 
 * A {tested} pattern must nominate at least one currently supported {rh-ocp} release to test against.
 * A {tested} pattern must ensure the test plan passes at least once per quarter.
-* A {tested} pattern must create a publicly available JSON file (eg. in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and {rh-ocp} version. See link:/learn/test-artefacts/[testing artefacts]
+* A {tested} pattern must create a publicly available JSON file (for example, in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and {rh-ocp} version. See link:/learn/test-artefacts/[testing artefacts].
 
 [NOTE]
 ====
-The {tested} pattern *do not* imply an obligation of support for partner or community operators by Red Hat or the pattern owner.
+A {tested} pattern *does not* imply an obligation of support for partner or community operators by Red Hat or the pattern owner.
 ====
 
 [id="should-tested-tier"]
@@ -79,4 +88,4 @@ Teams creating {tested} pattern can provide their own service level agreement (S
 A technical document for Quality Engineering (QE) team that defines how to validate if the pattern has been successfully deployed and is functionally operational.
 For example, see https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment].
 
-* A {tested} pattern meeting additional criteria can be nominated for promotion to the link:/learn/maintained/[Maintained tier].
+A {tested} pattern meeting additional criteria can be nominated for promotion to the link:/learn/maintained/[Maintained tier].