The supplier sets out how its QMS will apply to a given product, application or service: the life cycle model, how the project is organised, the activities, procedures and deliverables, who is responsible for showing fitness for intended use, and what supplier quality assurance does. These quality requirements are written down, reviewed, approved, made available and followed, whether in a quality plan or in other supplier documents. Prototypes may be built to clarify requirements or to explore risky areas such as the user interface, key algorithms, general suitability or performance; the aims are set beforehand, the prototype is judged against them, and there is a defined, controlled route for feeding the lessons back in, which Agile provides through its ceremonies, backlog control, tools and sprint reviews.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.