anchor.diff:  
   `GET /v2/service_usage_events`
   
  -For documentation on the response information, see the [api docs](http://apidocs.cloudfoundry.org/latest-release/service_usage_events/list_service_usage_events.html)
  +For documentation on the response information, see the [api docs](http://apidocs.cloudfoundry.org/latest-release/service_usage_events/list_service_usage_events.html).
   
   #### Event States
   
  -Service Usage Events have the following valid states: 'CREATED', 'DELETED', and 'UPDATED'.  These signify the desired state of the service.
  +Service Usage Events have the following valid states: 'CREATED', 'DELETED', and 'UPDATED'. These states signify the desired state of the service.
   
  -#### Managed Service Instances vs User Provided Service Instances
  +#### Managed Service Instances vs User-Provided Service Instances
   
  -Service Usage Events include the `service_instance_type` field to distinguish between managed service instances (service instances backed by a broker) and user provided service instances. You will likely not need to consider user provided service instances for billing purposes.
  +Service Usage Events include the `service_instance_type` field to distinguish between managed service instances (service instances backed by a broker) and user-provided service instances. You will likely not need to consider user-provided service instances for billing purposes.
   
   ## Using Usage Events
   
  +### Ordering Usage Events
  +The order of events returned from the API are guaranteed to match the sequence of events that occurred in the system.
   
  -### Ordering Usage Events
  -Order of events returned from the API are guaranteed to match the sequence of events that occurred in the system.
  -
  -The timestamps on events should not be used to sequence events.  They may come from different cloud controller instances whose time could be slightly mismatched.  Unless you're billing on the millisecond, they will be precise enough for normal usage.
  +The timestamps on events should not be used to sequence events. They may come from different Cloud Controller instances whose time could be slightly mismatched. Unless you are billing on the millisecond, they will be precise enough for normal usage.
   
   ### Querying For Events
  -To only fetch events you have not yet seen, use the `after_guid` query parameter. This will only return usage events that occurred after the event with the provided guid.
  +To only fetch events that you have not yet seen, use the `after_guid` query parameter. This will only return usage events that occurred after the event with the provided guid.
   
   Example:
   
  
positive.code: 
  `GET /v2/app_usage_events`
  
  For documentation on the response information, see the [api docs](http://apidocs.cloudfoundry.org/latest-release/app_usage_events/list_all_app_usage_events.html)
  
  #### Event States
  App Usage Events have the following valid states: 'STARTED', 'STOPPED', and 'BUILDPACK_SET'.
  
  Multiple 'STARTED' events can occur in a row, so as to indicate updates to the app - you can parse the response to determine the specific difference.  
  
  Multiple 'STOPPED' events cannot occur without 'STARTED' events in-between them.  
  
  The App Usage Events with the 'BUILDPACK_SET' state do not represent an actual application state; They instead signify that a buildpack has been used for the application. This can be used by operators who wish to charge for buildpack usage.
  
  
  ### Service Usage Events
  
  
negative.code: ---
  
  ## Usage Events
  Cloud Foundry operators can use usage events to construct billing information for apps and service instances.
  
  Despite being similar in name, usage events are different from Cloud Foundry audit events (`/v2/events`). You should not use the audit events stored in the events table for billing purposes. Audit events are recorded regardless of the action succeeding and are not guaranteed to be in the correct order.
  
  ### App Usage Events
  
  App Usage Events provide information about when users create, delete, and update apps. They also include information about the app to enable operators to bill based on resource usage.
  
  App Usage Events expire after 31 days by default. This is configurable using the cf-release manifest property `cc.app_usage_events.cutoff_age_in_days`.
  
  