@grepr/cli 1.8.7 → 1.8.8-78a5368

package/build/dist/docs-index/{ea88554f-4c25-4068-a4ea-a3c17d4240f8.txt → 0c31b920-f0be-4d3b-8be5-896ad7161fb8.txt}

@@ -19,7 +19,7 @@ The following states describe the lifecycle of an `ASYNCHRONOUS` `STREAMING` job
 
 ### Update job lifecycle
 
-Job updates in Grepr are versioned. An update, therefore, means Grepr will update the state for both the version getting retired and the version getting deployed concurrently. Grepr additionally allows users to specify a `rollbackEnabled` parameter while updating the job. If set to `true`, Grepr will roll back the job to a potentially running previous version in case of a failure. You can use this parameter to ensure minimal downtime in data processing in case of a misconfiguration.
+Job updates in Grepr are versioned. An update, therefore, means Grepr will update the state for both the version getting retired and the version getting deployed concurrently. Grepr additionally allows you to specify a `rollbackEnabled` parameter while updating the job. If set to `true`, Grepr will roll back the job to a potentially running previous version in case of a failure. You can use this parameter to ensure minimal downtime in data processing in case of a misconfiguration.
 
 A successful update job request will return a `202 Accepted` response with the updated job details and a bump in the job's version number.
 

package/build/dist/docs-index/{31d01b27-1f00-4388-81cb-6546a5623d61.txt → 4b57f602-0819-447f-adf9-1f1038d060e0.txt}

@@ -109,9 +109,9 @@ As an example, the UI sets up the rule engine to kick off a backfill job when a
 
 A trigger kicks off a one or more conditions. Triggers may continue to fire, and that would extend the activation time of the associated conditions. Each trigger has a unique identifier and is one of these types:
 
-* `Event Trigger`: This trigger is activated by a matching predicate on an event. The predicate is provided by the user as part of the rule engine configuration.
-* `External Trigger`: This trigger is activated by an external source, for example, an alert from an observability tool. These will allow users to feed external stimuli into the rule engine to take appropriate actions.
-* `Trace Sampling Trigger`: This trigger allows users to make sure that complete sets of log messages would be available in the observability tool for a sample set of traces. A trace can be a user ID, a request ID, an actual trace ID, or anything that the user wants to consider an "execution identifier". This trace ID can be an attribute or a tag.
+* `Event Trigger`: This trigger is activated by a matching predicate on an event. You provide the predicate as part of the rule engine configuration.
+* `External Trigger`: This trigger is activated by an external source, for example, an alert from an observability tool. External triggers let you invoke rules from external systems, such as an observability monitor or alert.
+* `Trace Sampling Trigger`: This trigger lets you ensure that complete sets of log messages are available in the observability tool for a sample set of traces. A trace can be a user ID, a request ID, an actual trace ID, or anything that you want to consider an "execution identifier". This trace ID can be an attribute or a tag.
 
 You can find the object model specification for the various trigger types in the [API specification](/apis/api-spec#tag/Triggers).
 

package/build/dist/docs-index/{138e34a0-a9d7-4e31-957a-7e2870bd9df1.txt → 81a78aa3-dfe9-4845-91cf-70456bd0001d.txt}

@@ -2,7 +2,7 @@ Learn to create and manage jobs using the Grepr REST APIs, including using the A
 
 # Create and manage jobs with the Grepr REST API
 
-This guide helps developers build programs that create and manage Grepr jobs using our REST APIs. You can run a Grepr job synchronously or asynchronously, and as a batch or streaming operation.
+This page provides guidance on using the Grepr REST API in your scripts and clients to create and manage Grepr jobs.
 
 Grepr jobs are composed of a directed graph of operations that process log data. Each job has:
 
@@ -10,6 +10,8 @@ Grepr jobs are composed of a directed graph of operations that process log data.
 * **Processing Type**: `BATCH` or `STREAMING`.
 * **Job Graph**: A collection of vertices (operations) and edges (data flow connections).
 
+To learn more about the Grepr processing model and jobs, see [_](/grepr-platform/grepr-model).
+
 ## Authentication
 
 All job operations require authentication using Bearer tokens. See [Authenticate to Grepr REST APIs](/apis/authentication) for details on obtaining access tokens.
@@ -208,7 +210,7 @@ Process live data with rate limiting for testing:
 
 ### Production pipeline (asynchronous streaming)
 
-Complex production pipeline based on our reference implementation:
+A complex production pipeline based on the Grepr reference implementation:
 
 ```json
 {