...

<Describe which user roles are related to the problem AND the solution, e.g. admin, deployer, node owner, etc. If you need to define a new role in your design, make that very clear. Remember this is about what a user is thinking when interacting with the system before and after this design change. This section is not about a UI, it's more abstract than that. This section should explain all the aspects of the proposed feature that will surface to users.>

Note to John W: the following user stories differ somewhat from the "conditioning" use cases in the overview. Applying user roles to the requirements helps focus the design by pointing to the point in part of the system where the requirement should be addressed. 

...

As an application deployer, I want to avoid nodes that have certain known security vulnerabilities (could be specific vulnerabilities or any).

As a device owner, I want to apply a security policy to the node before any applications are deployed.

As a device owner, I want OH to assess the condition of the device before allowing an agent to be installed.

As an application developer, I want OH to assess the condition of the device before allowing my application to be deployed.

As an application developer, I want to install system packages on the host OS before my application is deployed, and remove them when my application is in undeployed. Do we really really want to do this?

Command Line Interface

<Describe any changes to the hzn CLI, including before and after command examples for clarity. Include which users will use the changed CLI. This section should flow very naturally from the User Experience section.>

...