Change:
independent of protocol or use case. The text below summarizes the activities conducted by the roles <del> illustrated in dataflow. </del> <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> <del> An Attester creates Evidence that is conveyed to a Verifier. </del> <ins> The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier. </ins> <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> <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> <del> Subsequently, the Verifier generates Attestation Results for use by Relying Parties. </del> <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. <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> <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

Discussion:
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.