diff --git a/rfcs/NNNN-cdevents-provider/README.md b/rfcs/NNNN-cdevents-provider/README.md
index 5f56e929..0b0f56e0 100644
--- a/rfcs/NNNN-cdevents-provider/README.md
+++ b/rfcs/NNNN-cdevents-provider/README.md
@@ -17,16 +17,20 @@ Must be one of `provisional`, `implementable`, `implemented`, `deferred`, `rejec
 
 ## Summary
 
-This RFC proposes to add a `Provider` type to the Flux notification-controller API for sending [CDEvents](https://github.com/cdevents).
+This RFC proposes to add a `Provider` type to the Flux notification-controller API for sending
+[CDEvents](https://github.com/cdevents).
 
-When `Provider` objects configured to send CDEvents are alerted by a Flux event, they will utilise an already defined mapping of Flux and CDEvents events to send an appropriate CDEvent payload to a defined URL.
+When `Provider` objects configured to send CDEvents are alerted by a Flux event, they will utilise an already defined
+mapping of Flux and CDEvents events to send an appropriate CDEvent payload to a defined URL.
 <!--
 One paragraph explanation of the proposed feature or enhancement.
 -->
 
 ## Motivation
 
-CDEvents enables interoperability between supported tools in a workflow, and flux is a very popular continuous delivery tool, as such we have received many questions about implementing CDEvents into the tool. The receiver part of this integration is already implemented in flux 2.3.0
+CDEvents enables interoperability between supporte   tools in a workflow, and flux is a very popular continuous delivery
+tool, as such we have received many questions about implementing CDEvents into the tool. The receiver part of this
+integration is already implemented in flux 2.3.0
 <!--
 This section is for explicitly listing the motivation, goals, and non-goals of
 this RFC. Describe why the change is important and the benefits to users.
@@ -34,7 +38,8 @@ this RFC. Describe why the change is important and the benefits to users.
 
 ### Goals
 
-Integrate [CDEvents](https://github.com/cdevents) into Flux with a CDEvents Provider that supports sending CDEvent events.
+Integrate [CDEvents](https://github.com/cdevents) into Flux with a CDEvents Provider that supports sending CDEvent
+events.
 
 <!--
 List the specific goals of this RFC. What is it trying to achieve? How will we
@@ -52,7 +57,10 @@ and make progress.
 
 ## Proposal
 
-Add CDEvents to the list of available `Providers` in Flux Notification controller. The relevant CDEvent sent by the `Provider` will be determined by a pre-defined mapping of Flux events and relevant CDEvents. These CDEvent payloads should have meaningful data from the source event. There will be an initial focus on HelmRelease and related events as the format within Flux for those events is much more consistent.
+Add CDEvents to the list of available `Providers` in Flux Notification controller. The relevant CDEvent sent by the
+`Provider` will be determined by a pre-defined mapping of Flux events and relevant CDEvents. These CDEvent payloads
+should have meaningful data from the source event. There will be an initial focus on HelmRelease and related events as
+the format within Flux for those events is much more consistent.
 <!--
 This is where we get down to the specifics of what the proposal actually is.
 This should have enough detail that reviewers can understand exactly what
@@ -67,7 +75,11 @@ then this section can be replaced with the actual documentation.
 
 Users of multiple CI/CD tools such as Tekton and Flux could use CDEvents as a way to enable interoperability.
 
-For example, a user may want a Tekton `pipeline` to run once a HelmRelease flux resource has succeeded in a Helm install. On successful helm install, Flux will emit an event with reason `InstallSucceeded` which will be mapped to an `Environment.Modified` CDEvent. The CDEvent `Provider` will then send a payload with that CDEvent, which will also contain data from the Flux event, to a CloudEvents broker that Tekton is subscribed to, and trigger a Pipeline Run within Tekton. 
+For example, a user may want a Tekton `pipeline` to run once a HelmRelease flux resource has succeeded in a Helm
+install. On successful helm install, Flux will emit an event with reason `InstallSucceeded` which will be mapped to an
+`Environment.Modified` CDEvent. The CDEvent `Provider` will then send a payload with that CDEvent, which will also
+contain data from the Flux event, to a CloudEvents broker that Tekton is subscribed to, and trigger a Pipeline Run
+within Tekton. 
 
 ![User Stories Tekton](user-stories-provider.drawio.png)
 
@@ -89,7 +101,9 @@ This is a good place to incorporate suggestions made during discussion of the RF
 
 Adding a Flux `Provider` for CDEvents that will send a CDEvent payload upon receiving a flux event from an alert. 
 
-Once an alert is triggered for this provider, it will send a CDEvent that corresponds to the Flux event that caused the alert. This CDEvent will be created using the [CDEvents Go SDK](https://github.com/cdevents/sdk-go). The implementation will include a defined mapping of which Flux events trigger a corresponding CDEvent.
+Once an alert is triggered for this provider, it will send a CDEvent that corresponds to the Flux event that caused the
+alert. This CDEvent will be created using the [CDEvents Go SDK](https://github.com/cdevents/sdk-go). The implementation
+will include a defined mapping of which Flux events trigger a corresponding CDEvent.
 
 The CDEvents broker is not a part of this design and is left to the users to set up however they wish.