add use cases so brandon is happy

Signed-off-by: vsoch <vsoch@users.noreply.github.com>

docs/proposals/PROPOSAL_F.md

@@ -105,6 +105,84 @@ A similar spec for an HPC-oriented container might look like the following:
 
 As stated previously, the granularity of metadata provided is up to the compatibility interest group. The degree to which each metadata attribute is used is up to the plugin or tool within the context of a specific use case.
 
+## Requirements
+
+Taken from [REQUIREMENTS](../REQUIREMENTS.md). Points that have:
+
+- `TOOL RESPONSIBILITY` would be possible by a custom tool.
+- `AGNOSTIC`: the proposal is agnostic to the specific point (can be decided by working group)
+
+### Image Author
+
+- [x] As an image author, I want to update compatibility independently without having to re-release and re-distribute my image.
+- [x] As an image author, I want to have the freedom to express any compatibility that is necessary for my container to run on the host.
+  - [x] Including conditional compatibility, such as a container running on AMD CPU and intel CPU having different requirements.
+  - [x] Including must have/nice to have compatibility.
+  - [x]  Matching finer grain platform definitions.
+- [x] As an image author, I want to use a provided tool to verify the compatibility spec I wrote against the schema.
+- [ ] As an image author, I would like to create a single compatibility description that is common to a group of images (`TOOL RESPONSIBILITY`).
+- [ ] As an image author, I want to be able to specify in my manifest that my multi-platform image has a compatibility spec which should be consulted `AGNOSTIC`.
+- [ ]  As an image author, I want to be able to include compatibility specifications from base layers that I inherited from `TOOL RESPONSIBILITY` that can derive path of base layers
+- [x] As an image author, I want to ensure that runtimes without image compatibility gracefully fall back to running a usable image.
+
+### Domain Architect
+
+- [x] As a domain architect I want a process to share my knowledge about \<niche topic\> compatibility with some compatibility interest group.
+- [x] As a domain architect I don't want to have to understand containers or develop tools for them to share this knowledge.
+
+### Tool Writer
+
+- [x] As a tool writer, I want to get the compatibility spec without pulling the image layer blobs.
+- [x] As a tool writer, I would like to have a library for reading image compatibility so that I can write my own software that takes action based on the spec, e.g.:
+  - [x] custom k8s scheduler, admission webhooks, runtime classes etc.
+- [x] As a tool writer, compatibility validation could be integrated into non-runtime tools.
+- [x] As a tool writer, I want to be able to write tools (that use compatibility specs) that have non-standard applications (e.g., checking individual layers).
+
+### System Runtime Administrator
+
+- [x] As a system runtime administrator, I want to check whether a container is compatible with the nodes I am going to run it on using the provided tool.
+- [x] As a system runtime administrator, I would like to fetch additional documentation for understanding specific settings in the compatibility spec.
+- [ ] As a system runtime administrator, selecting which image to run should only require pulling the Index manifest, and parsing the descriptors listed.
+  Additional API calls to the registry should not be required.
+- [ ] As a system runtime administrator, I want to validate whether all running applications in the cluster are compatible with a new operating system (or new operating system version) or not before migrating. `TOOL RESPONSIBILITY`
+- [ ] As a system runtime administrator, I want to validate whether all running applications in the cluster are compatible with new hardware (cpu, gpu, nic etc.) or not before migrating `TOOL RESPONSIBILITY`.
+- [ ] As a system runtime administrator, I want to use annotations to schedule for the appropriate resources (we do not have annotations, we have metadata attributes in the artifact).
+- [x] As a system runtime administrator, the runtime should not need to know about all possible types of hardware.
+- [ ] Perhaps hooks could be added for users to inject their own image selection criteria on a given host, or annotations could be injected `TOOL RESPONSIBILITY`.
+
+### Deployment Engineer
+
+- [ ] As a deployment engineer, I want to parse an image index and find the “optimal” image for the cluster node I am aiming to run the image on `AGNOSTIC`.
+That includes being able to:
+  - Discover the image that fits the selected host.
+  - Find the best match from the nodes and images I have available.
+  - Determine that the image is not fitting the selected host.
+- [x] As a deployment engineer, I want the image compatibility check to be performed without downloading or executing the referenced image layers.
+- [x] As a deployment engineer, I should be able to add the compatibility to images already being used in production, especially for the images released before image compatibility wg was created.
+- [x] As a deployment engineer, I want to be able to specify the version and variant of an application or other user specific configuration (e.g. MPI), and not only hardware/kernel details in the compatibility specification.
+- [ ] As a deployment engineer, I want my compatibility spec runtime to be able to select the best possible runtime available on a node (e.g. runc vs nvidia vs wasm) `TOOL RESPONSIBILITY`
+- [x] As a deployment engineer, I want to be able to rank the images in a multi-platform image so that the runtime can know which one to choose when more than one image is compatible with the runtime environment.
+- [x] As a deployment engineer, I want to reuse community projects so that I don't duplicate and integrate the functionality of the already existing tools.
+
+### Registry Maintainer
+
+- [x] As a registry user or operator I want to have a common way of inspecting information about image compatibility to enable users to find an image that best matches their system.
+- [x] As a registry operator (or user that has no control over their registry implementation), I want any compatibility changes to not depend on registry server changes or upgrades.
+
+### OCI Specification Maintainer
+
+- [x] As a spec maintainer, I want the solution to avoid breaking other specs (confidential images, image signing, existing implementations for runtimes picking images).
+- [x] As a spec maintainer, I don't want the spec to update for new hardware devices, kernel releases, or other external dependencies.
+- [x] As a spec maintainer, I don't want to overlap significantly with solutions from other specs (like SBOMs).
+
+### Security Administrator
+
+- [x] As a security administrator, I want predictable behavior from runtimes, which does not change based on unsigned content. _(runtimes should ignore unsigned or untrusted artifacts if signed images are required, even if the image itself is signed by a trusted authority)_
+- [x] As a security administrator, I want to ensure the compatibility spec cannot be used to escalate privileges beyond what is requested by the deployment engineer.
+- [x] As a security (or more generally, XYZ) researcher, I want to annotate a container (separately) with my niche jargon of metadata.
+- [x] As a security administrator, I want to know that image compatibility cannot be used to circumvent image signing.
+- [ ] As a security administrator I want to catalog SBOMs of compatible images to put into a report about software used by my group / institution `TOOL RESPONSIBILITY`
+
 ## References
 
 - [Original planning document](https://docs.google.com/document/d/1nRUuW9i7NRdYXrUr8DQXLMETXwP1J9rw3TbpLTU9yho/edit)