Code change:
obtained via some other mechanism such as being configured in the Verifier by an administrator. <ins> For example, for some claims the Verifier might check the values of claims in the Evidence against constraints specified in the Appraisal Policy for Evidence.  Such constraints might involve a comparison for equality against reference values, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. Such reference values might be specified as part of the Appraisal Policy for Evidence itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy for Evidence.  The actual data format and semantics of a known-good value are specific to claims and implementations.  There is no general purpose format for them or general means for comparison defined in this architecture document.  Similarly, for some claims the Verifier might check the values of claims in the Evidence for membership in a set, or against a range of values, or against known- bad values such as an expiration time.  These reference values may be conveyed to the Verifier as part of an Endorsement or as part of Appraisal Policy or both as these are the two input paths to the Verifier. </ins> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy

Related discussion:
text: I think it should go further to say that Endorsements can include values that are static (intrinsic) that don’t require attestation, but can be asserted about a class of device, platform, entity and appraised according to an appraisal policy for Evidence (Even though the claims don’t appear in Evidence). While I think it is possible to interpret the existing wording according to the above understanding, it is also possible to interpret it differently. Therefore, the section should be improved. I also think the first sentence (and definition in terminology) are insufficient. While “An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device’s signing capability.” – is correct, it is insufficient because it is also a statement about the devices Attesting Environment ability to collect claims securely.
Given that this Architecture document will serve as a guide to additional work that is needed from RATS wg to define data schema, interfaces for an interoperable implementations of verifiers with endorsements from multiple vendors to be compared with evidence from different implementation of attesters, isn't it worthwhile creating a hook in this document for scope of work needed to tackle it in future documents? If yes this document should define KGV, the types of KGVs that can be endorsed or defined in attestation policy, a need for data schema for each type of KGV and a set of interfaces to fetch/publish it deferred to a future document. Similar to claims encoding formats specified in section 8, a specification needed but deferred to future document for KGV endorsement formats would be useful.
A google search for "known good values" yields some mention in the Cisco trust center and a few books on security. Linux IMA mentions "good measurements" once that I could find. So there's some use of the term out there and it seems worth mentioning along with RIM. It is also a very descriptive term that is probably immediately clear to the user.