Goal Summary:

Over time, a few new criteria have been introduced into the policy editor with inconsistent section placement, while some section names are by themselves wrong. In addition, it has always been unclear what we mean exactly by "XXX-time policy criteria" since the criteria itself it not tied to a stage. Instead the criteria is tied to a domain, such as "Image Criteria", and "Workload criteria" 

This lack of clarity and inconsistency creates a confusion which builds up to the "1,000 cuts" frustration that customers have shared with us numerous times. It makes it harder to learn and leverage our policy capabilities.

The correct Criteria domain naming is summarized in the following diagram:

In addition to some misleading guidance and confusing terminology, the most notable issues are:

1. Service Account criteria is called "Kubernetes Access". This term is not sufficiently descriptive. It feels as if we stopped shy of calling it RBAC b/c we know that we don't actually have RBAC criteria and somehow found a middle ground.  Instead we can just call it "Service Account"
2. Unexpected Network Flow is a runtime criteria that appears in the UI under the Workload related (Deploy stage) "Networking" section 
3. User-Pod interaction is called “Kubernetes events” in the UI. However "Kubernetes Events" is an engineering oriented term which does not reflect the capability. To make things worse "Kubernetes Events" is used, again,  for a different section altogether,  when authoring a runtime Audit Log policy.

Goals and expected user outcomes:

The outcome can be broken down to several related but independent goals:

1. Correct the specific names and placement of the offending items.
2. Replace the introductory guidance about lifecycle stages and fix related bug
3. Introduce a visual separation of the criteria domains 

It is highly desired that we accomplish all goals, but the 1st and 2nd goals are mostly string changes which should be a tiny effort. For goal 3 we may want the UX team to weigh in and we can then evaluate alternatives.

Objectives for goal 1: criteria  placement and order

The entire order is captured in this spreadsheet  
For clarity, the section/subsection summary is repeated below. In case of mismatch the above spreadsheet is the source of truth.

Objectives for goal 2: a clear terminology and better workflow 

Update the explanation in the UI about Lifecycle stages 

The source of truth for these changes is the UX issue https://issues.redhat.com/browse/HPUX-835 

Acceptance Criteria:

A list of specific needs or objectives that a feature must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.

<enter general Feature acceptance here>

Success Criteria or KPIs measured:

A list of specific, measurable criteria that will be used to determine if the feature is successful. Include key performance indicators (KPIs) or other metrics., etc. Initial completion during Refinement status.

<enter success criteria and/or KPIs here>

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios together with user type/persona. Initial completion during Refinement status.

<your text here>

Out of Scope (Optional):

High-level list of items that are out of scope. Initial completion during Refinement status.

<your text here>