@grepr/cli 1.8.7 → 1.8.8-4c5226e

package/build/dist/docs-index/{ea88554f-4c25-4068-a4ea-a3c17d4240f8.txt → 512490f6-dbbe-4b6b-9db9-09040526af16.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/{13f16cca-0011-4a3d-84fd-9e19b1a5c3a5.txt → 8687e55b-b74a-4af1-a83a-880a5b688caa.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 these credentials to obtain an access token for API authentication.
+You use 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/{138e34a0-a9d7-4e31-957a-7e2870bd9df1.txt → 949096a8-f905-4c41-9380-5a4dcd9e9fe6.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
 {

package/build/dist/docs-index/{e3eba04f-a24d-40b3-865b-0ec44b4d8734.txt → 9758c20f-e9aa-4a20-9764-db33820b4ac2.txt}

@@ -42,7 +42,7 @@ The SQL transform is ideal when you need to perform complex data transformations
   * Format conversion: Converting logs for compatibility with downstream systems.
   * Batch preparation: Aggregating and preparing data for batch analytics.
 
-## How does the SQL transform process data?
+## How does the SQL transform process data? \[#sql-transform-processing]
 
 The SQL transform processes data through one or more SQL statements. You specify SQL statements that define the data structure after processing, and the SQL transform processes the input data to transform it into those structures. You can configure the transform to send the results of running the SQL statement to either:
 

package/build/dist/docs-index/{33cf4559-d46a-4926-89a8-565017ee25c1.txt → ac6e5904-1fbf-4965-aa82-545ae1b3bec4.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 & access settings: Update organization and access settings.
+* Organization and 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:

package/build/dist/docs-index/{31d01b27-1f00-4388-81cb-6546a5623d61.txt → c3618f4d-a530-4cd4-9f4b-b44061ac494d.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).