diff --git a/draft-ietf-scitt-architecture.md b/draft-ietf-scitt-architecture.md
index 373db56c..2d629393 100644
--- a/draft-ietf-scitt-architecture.md
+++ b/draft-ietf-scitt-architecture.md
@@ -326,11 +326,14 @@ The SCITT architecture consists of a very loose federation of Transparency Servi
 In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs.
 Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document {{-COMETRE}}.
 
-This section describes at a high level, the three main roles and associated processes in SCITT:
-
-* Issuers and Signed Statements
-* Transparency Service and the registration process
-* Relying Parties of the Transparent Statements and the Receipt validation process
+{{fig-concept-relationship}} illustrates entities and processes that comprise a Transparency Service independent of any one use case. There are three main entities and their associated processes in SCITT:
+
+* Issuers that use Statements about Artifacts and their credentials to create Signed Statements
+* Transparency Services that register Signed Statements and Transparent Statements and in doing produce Receipts
+* Relying Parties that
+  * collect Receipts of Signed Statements for subsequent registration of Transparent Statements;
+  * retrieve Transparent Statements for analysis of Statements about Artifacts themselves (e.g. verification);
+  * or replay all the Transparent Statements to check for the consistency of the Transparency Service's Append-only Log (e.g. auditing)
 
 ~~~aasvg
  .----------.