@grepr/cli 1.8.7-808c275 → 1.8.7

package/build/dist/docs-index/{59e58125-f51c-4c5a-b3b5-5f57cd2fc37f.txt → 138e34a0-a9d7-4e31-957a-7e2870bd9df1.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 page provides guidance on using the Grepr REST API in your scripts and clients to create and manage Grepr jobs.
+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.
 
 Grepr jobs are composed of a directed graph of operations that process log data. Each job has:
 
@@ -10,8 +10,6 @@ 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.
@@ -210,7 +208,7 @@ Process live data with rate limiting for testing:
 
 ### Production pipeline (asynchronous streaming)
 
-A complex production pipeline based on the Grepr reference implementation:
+Complex production pipeline based on our reference implementation:
 
 ```json
 {

package/build/dist/docs-index/{498bd2cd-a418-4645-bdd7-14291fc5407d.txt → 13f16cca-0011-4a3d-84fd-9e19b1a5c3a5.txt}

@@ -9,7 +9,7 @@ The credentials consist of:
 * **client ID**: A unique identifier for your service account.
 * **client secret**: A secret key to authenticate your service account.
 
-You use these credentials to obtain an access token for API authentication.
+You use these these credentials to obtain an access token for API authentication.
 
 The exception to the access restrictions for the Grepr APIs is the `POST /v1/triggers` endpoint to create external triggers.
 

package/build/dist/docs-index/{cfd720d5-973d-43fe-bd46-1b12b3a26c79.txt → 31d01b27-1f00-4388-81cb-6546a5623d61.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. 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.
+* `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.
 
 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/{56f3a00d-b5cf-4a1d-8fb0-a2c3580b23a1.txt → 33cf4559-d46a-4926-89a8-565017ee25c1.txt}

@@ -88,7 +88,7 @@ There are two types of system logs that track user activity in the Grepr platfor
 * Roles: Create, update, and delete roles.
 * API keys: Create or delete API keys.
 * Service accounts: Create, update, and delete service accounts. Regenerate service account secrets.
-* Organization and access settings: Update organization and access settings.
+* Organization & access settings: Update organization and access settings.
 * External triggers: Create, update, and delete external triggers.
 
 Audit log contents vary by event type. Depending on the operation, an audit log entry might include information such as: