Original text:
Transparency Services.  To register a Signed Statement, the Transparency Service performs the following steps: <del> Issuer Key Discovery The Transparency Service MUST perform DID resolution of the Issuer's key and store evidence of the lookup. This step may require that the service retrieves the Issuer DID in real-time, or relies on retrieving cached resolution. Signature verification The Transparency Service MUST verify the signature of the Signed Statement, as described in RFC 9360, using the signature algorithm and verification key of the Issuer DID document. Signed Statement validation The Transparency Service MUST check that the Signed Statement includes a Statement payload and the protected headers listed above.  The Transparency Service MAY additionally verify the Statement payload format and content. </del>  <del> Apply Registration Policy For named policies, the Transparency Service MUST check that the required Registration info attributes are present in the headers and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and may use information contained in the attributes of named policies. </del>  <del> Register the Signed Statement to the append-only log. Return the Transparent Statement, which includes the Receipt. </del>  Details about generating Receipts are described in Receipt. The last two steps may be shared between a batch of Signed Statements

Reviewer comments:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Revised text:
Transparency Services.  To register a Signed Statement, the Transparency Service performs the following steps:  <ins> The Transparency Service MUST perform DID resolution of the Issuer's key and store evidence of the lookup.  This step may require that the service retrieves the Issuer DID in real-time, or relies on retrieving cached resolution. </ins>  <ins> The Transparency Service MUST verify the signature of the Signed Statement, as described in RFC 9360, using the signature algorithm and verification key of the Issuer DID document. </ins>  <ins> The Transparency Service MUST check that the Signed Statement includes a Statement payload and the protected headers listed above.  The Transparency Service MAY additionally verify the Statement payload format and content. For named policies, the Transparency Service MUST check that the required Registration info attributes are present in the headers and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and may use information contained in the attributes of named policies. Register the Signed Statement to the append-only log Return the Transparent Statement, which includes the Receipt </ins> Details about generating Receipts are described in Receipt. The last two steps may be shared between a batch of Signed Statements