Original text:
independent of protocol or use case. The text below summarizes the activities conducted by the roles <del> illustrated in dataflow. </del>  <del> An Attester creates Evidence that is conveyed to a Verifier. </del>  <del> A Verifier uses the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers, by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester.  This procedure is called the appraisal of Evidence. </del>  <del> Subsequently, the Verifier generates Attestation Results for use by Relying Parties. </del>  The Appraisal Policy for Evidence might be obtained from the Verifier Owner via some protocol mechanism, or might be configured into the Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism. <del> A Relying Party uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions.  This procedure is called the appraisal of Attestation Results. </del>  The Appraisal Policy for Attestation Results might be obtained from the Relying Party Owner via some protocol mechanism, or might be some other mechanism. See messages for further discussion of the conceptual messages shown <del> in dataflow. </del>  3.1. As shown in twotypes-env, an Attester consists of at least one <del> Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and compositedevice.  Other examples may exist.  All compositions of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations. </del>  Claims are collected from Target Environments.  That is, Attesting Environments collect the values and the information to be represented

Reviewer comments:
The word 'device' is used dozens of times throughout the document. However, it often doesn't imply 'device' but rather a component of the device. RFC4949 defines 'system component' as: system component (I) A collection of system resources that (a) forms a physical or logical part of the system, (b) has specified functions and interfaces, and (c) is treated (e.g., by policies or specifications) as existing independently of other parts of the system. (See: subsystem.) (O) /ITSEC/ An identifiable and self-contained part of a TOE. Usage: Component is a relative term because components may be nested; i.e., one component of a system may be a part of another component of that system. Tutorial: Components can be characterized as follows: A "physical component" has mass and takes up space. A "logical component" is an abstraction used to manage and coordinate aspects of the physical environment, and typically represents a set of states or capabilities of the system. This definition seems appropriate for most of the places where 'device' is used. Alternatively, 'system' could be used if 'system component' would be to narrow.
I think that we struggled a lot to arrive at the compromise of saying "device". I agree with you that there are composite devices which contain "system components". But, if we do the direction of using that term, we will lose readers and lose comprehension. I do not agree with this proposal. If it is unclear that "device" is a role, then I guess we could add that to the Terminology.
If I were to be pedantic about what a device is using capital letter names, it is both, it's an entity (that performs the role). The Architecture is a description while normative drafts are more precise / formal descriptions or definitions. I don't feel strongly about it. But some people seem to feel strongly that device is used too much. Does it make sense to talk about how we use 'device' and refer to 4949 system component as being roughly equivalent?
We could say one time early in the text that we mean "system component" when we mean device, but for the sake of simplicity use device as a representative concept throughout the document.
Makes sense.

Revised text:
independent of protocol or use case. The text below summarizes the activities conducted by the roles  <ins> illustrated in dataflow.  Roles are assigned to entities.  Entities are often system components RFC4949, such as devices.  As the term device is typically more intuitive than the term entity or system component, device is often used as a illustrative synonym throughout this document. </ins>  <ins> The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier. </ins>  <ins> The Verifier role is assigned to entities that use the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers, by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester.  This procedure is called the appraisal of Evidence. </ins>  <ins> Subsequently, the Verifier role generates Attestation Results for use by Relying Parties. </ins> The Appraisal Policy for Evidence might be obtained from the Verifier Owner via some protocol mechanism, or might be configured into the Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism.  <ins> The Relying Party role is assigned to entities that uses Attestation Results by applying its own appraisal policy to make application- specific decisions, such as authorization decisions.  This procedure is called the appraisal of Attestation Results. </ins> The Appraisal Policy for Attestation Results might be obtained from the Relying Party Owner via some protocol mechanism, or might be some other mechanism. See messages for further discussion of the conceptual messages shown  <ins> in dataflow.  Section terminology provides a more complete definition of all RATS roles. </ins> 3.1. As shown in twotypes-env, an Attester consists of at least one  <ins> Attesting Environment and at least one Target Environment co-located in one entity.  In some implementations, the Attesting and Target Environments might be combined into one environment.  Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and compositedevice.  Other examples may exist. All compositions of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations. </ins> Claims are collected from Target Environments.  That is, Attesting Environments collect the values and the information to be represented