Clarification/context

Some added context and clarification around the definitions of green/amber

Author: iw-ezequiel

quality-checks.md

@@ -26,10 +26,12 @@ All of these checks are important, even where their purpose overlaps with other
 We rate our applications against each of these checks as follows:
 
 * Green = the quality check is applied frequently and consistently (in practice this typically means [automated](./patterns/automate-everything.md) via [continuous integration / continuous deployment](./practices/continuous-integration.md)), the output of the check is a quality gate (as opposed to just a warning / for information), and the tolerances for that quality gate (e.g. code coverage %) are agreed and understood
-* Amber = the quality check is applied, but not all conditions for green are met - for example the check generates warnings that may or may not be acted on
+* Amber = the quality check is applied, but not all conditions for green are met - for example the check generates warnings that may or may not be acted on, or is executed on an ad-hoc basis and cannot offer a consistent quality gate guarantee
 * Red = the quality check is not applied
 * N/A = the quality check is not applicable
 
+There may be further nuances to these definitions, and the sections detailing each check can expand considerably on the criteria as required. Everyone is encouraged to contribute to those, and discuss how they can be best be tailored.
+
 ## Tracking progress
 
 We recommend tracking progress on an Engineering Quality dashboard, for example: