@grepr/cli 1.13.0-2632478 → 1.14.3-a181b29

package/build/dist/docs-index/50b93ca0-3ce5-4254-b135-ca36b786b8f3.txt

@@ -1,225 +0,0 @@
-How a Grepr AI agent records what it concluded, counts recurrences, and searches past investigations, and how to add semantic search.
-
-# Remember past investigations
-
-Without memory, every investigation starts from nothing. An agent that diagnosed a problem last week reaches the same conclusion the same slow way this week, and nobody learns that the problem has now happened five times.
-
-*Memory* changes that. An agent with memory enabled records what it concluded when it reaches a diagnosis, recognizes when a later investigation reaches the same conclusion and counts the recurrence, and searches those records at the start of a new investigation to find out whether it has seen this before.
-
-Both halves show up in the investigation's tool calls. A memory search runs near the start, before the agent has looked at anything else, and the record is written at the end, when it has a diagnosis.
-
-The agent decides what to record and whether something is a recurrence. Grepr does not extract conclusions on its behalf or merge records by similarity, because the investigating agent is the only thing that saw the evidence.
-
-Every agent records memories unless you turn memory off, and every agent can search the memories your organization's agents recorded. Searching by meaning needs a store, which is optional. See [Add semantic search](#enable).
-
-## What an agent records \[#what-recorded]
-
-An agent records at most one memory per investigation, written when it reaches a diagnosis rather than after the fact. Each memory holds:
-
-| Field | What it holds |
-| --- | --- |
-| Title | A short name for the problem. |
-| Symptoms | What was observed. |
-| Root cause | What the agent concluded was responsible. |
-| Root cause confidence | Whether the cause is **confirmed**, **suspected**, or **unknown**. |
-| Ruled out | Causes the agent checked and eliminated, so a later investigation does not repeat that work. |
-| Resolution | What resolved it, or what was attempted. |
-| Significance | How much the conclusion matters. See [Significance](#classification). |
-| Entity tags | The services, pipelines, and environments the memory is about. See [Entity tags](#tagging). |
-| Recurrence count | How many investigations reached this same conclusion. |
-
-An agent can correct its own memory for an investigation while that investigation is running, so an early diagnosis it later disproves does not stay on the record. Correcting a memory does not count as a new recurrence.
-
-### Significance \[#classification]
-
-Significance is how an agent classifies what it found, and a search can filter on it:
-
-| Significance | Meaning |
-| --- | --- |
-| Incident | A real problem was identified. |
-| Observation | Not a problem, but a conclusion worth keeping. |
-| Inconclusive | The agent could not determine whether there was a problem. |
-| Benign | Triaged as no problem. |
-
-Text and timeline searches find benign memories like any other memory, so an agent can notice that a given service has been triaged as benign many times. A semantic search finds a benign memory only when the agent that recorded it made it searchable by meaning. A search that is looking only for real problems can list the significances it wants and leave benign out.
-
-## Add semantic search \[#enable]
-
-Without a store, an agent's memories are found by text and timeline searches. A store adds semantic search, which finds memories by meaning. A store needs somewhere to keep its search index and a model to build that index with, so there are three things to set up.
-
-### Step 1: Create a vector index integration \[#vector-index]
-
-1. On the **Integrations** page, next to the **S3 Vector Index** section heading, click **Add new**.
-2. In the **Add Vector Index** dialog, enter a **Name** and the number of **Dimensions** the embedding model you plan to use produces, then click **Create**.
-
-The dimensions must match the model's output, so choose the embedding model first and use its dimension count. An index's dimensions are fixed after creation.
-
-### Step 2: Create an embedding integration \[#embedding-integration]
-
-Memory embeds each record with a model from an LLM integration that provides embeddings. If you do not have one, create it before you continue. See [_](/integrations/llm).
-
-An agent's reasoning model and its embedding model are separate choices. An agent can reason with one integration and embed with another.
-
-### Step 3: Set the agent's store \[#agent-memory]
-
-1. On the agent's page, go to the **Memories** step.
-2. Under **Semantic search**, select the **Vector index integration**, the **Embedding credentials**, and the **Embedding model**.
-3. Save the agent.
-
-A store is the three settings together: set all of them, or clear all of them. Memories recorded before the agent had a store are found by text and timeline searches only.
-
-When you create an agent and leave its store empty, the agent takes the store your other agents use, if exactly one store is in use among the agents that record memories and you can view both of its integrations. Otherwise the agent has no store until you set one.
-
-Grepr creates the search index when you create the vector index integration in Step 1, and discards the integration if the index cannot be created. Saving the agent then checks that the embedding model actually works against that index, by embedding a test value with it. So a wrong model or an unusable credential stops the save rather than surfacing later as memories that were never indexed.
-
-### Choose an embedding model and keep it \[#embedding-model]
-
-A memory is embedded with the model the agent had when it was recorded, and a query can only be compared against embeddings from the same model. Changing an agent's embedding model therefore cuts its new memories off from the ones it already recorded, as far as searching by meaning is concerned. Treat the choice as long lived.
-
-Using the same model across several agents does not pool their memories into one semantic search. A search by meaning always targets one agent, as described next.
-
-## How an agent searches its memory \[#search-modes]
-
-A search runs in exactly one of three modes, and which mode fits depends on what the agent is trying to find:
-
-| Mode | What it finds | Use it to answer |
-| --- | --- | --- |
-| Semantic | Investigations whose conclusions mean something similar to the query. | Has a problem like this happened before? |
-| Text | Investigations mentioning specific words, using full-text search. | Has this exact error string or identifier come up before? |
-| Timeline | Investigations about given entities, ordered by time. | What has been happening to this service recently? |
-
-Semantic search finds a past incident described in different words, which text search misses. Text search finds a literal, such as an error code or a host name, which semantic search can rank poorly. Timeline search needs entity tags rather than a query.
-
-A semantic search needs the agent it searches to have a store, and returns nothing for an agent without one. When an agent searches without choosing a mode, Grepr uses semantic when the searched agent has a store, and text otherwise.
-
-The modes also differ in how much they cover, which matters when you read an empty result:
-
-* A semantic search covers one agent at a time, because a query is only comparable against embeddings made with that agent's model. An empty semantic result means nothing similar was found within what the search could reach. It is not evidence that the agent recorded nothing similar, and it is not evidence that your organization has not seen the problem. A memory embedded with a model the agent no longer uses is unreachable until it is embedded again, and a search that cannot reach the embedding provider returns empty as well. An agent can also record a routine or benign observation without making it searchable by meaning, so a semantic search never returns it. When an empty result matters, confirm it with a text or timeline search, which read the records directly.
-* A text or timeline search covers every agent in your organization by default, so it is the one to use when you want the organization's whole history.
-
-So to find out whether any agent has seen something, search by text or timeline, or repeat the semantic search against each agent you care about.
-
-A result carries the memory's title, significance, and entity tags along with its recurrence count, how long ago it was recorded, when it was last seen, and whether it is active, recent, or historical. Results are compact by default: the symptoms, root cause, ruled-out causes, and resolution come back only when the search asks for them, or when the agent reads one memory in full by its ID. Each semantic or text result also carries a score that ranks it within that search. A score orders candidates; it does not establish that a past memory is the same incident, which the agent judges from the content.
-
-Search returns three results by default and at most 50, without pagination, and says when more matched than it returned. Narrowing by entity tags or by significance is more effective than raising the limit.
-
-## Entity tags \[#tagging]
-
-Entity tags are what make memories findable by the thing they are about, such as a service, a pipeline, or an environment. Each memory carries two kinds:
-
-* Tags Grepr derives from the triggering signal, which identify the source and the signal type.
-* Tags the agent adds, which name the entities it concluded the memory is about.
-
-Grepr derives its tags using a mapping per signal type, which extracts values from the signal payload by path. The shipped mappings cover the common cases:
-
-| Signal type | Tags derived from the signal |
-| --- | --- |
-| Log pattern | The pipeline, the pattern, and the service, environment, and Kubernetes namespace from the sample log event. |
-| Webhook | The integration, and the service and host from the payload. |
-| Manual | The signal type only. |
-
-The webhook mapping reads the service and host from field names Grepr expects. If your payloads name those fields differently, add a mapping so the tags resolve. On the agent's **Memories** step, under **Entity tags**, add a mapping for the signal type, then add each tag key with the paths to read it from. Grepr tries the paths in order and uses the first that resolves.
-
-Consistent tag values matter more than complete ones. A service tagged `checkout` in some memories and `checkout-svc` in others splits its history in two, and a timeline search finds only half. An agent can ask a search for the tag values already in use in your organization, so an agent that checks before recording reuses existing values rather than inventing new ones.
-
-Case doesn't split a history: `Service=Checkout` and `service=checkout` are the same tag.
-
-## Set how an agent uses its memory \[#policy]
-
-The **Retrieval policy** settings on the agent's **Memories** step tell the agent how much to search and what to record. Grepr adds them to the agent's instructions, so you do not restate them in the agent's own prompt.
-
-| Setting | What it tells the agent | Default |
-| --- | --- | --- |
-| **Search budget per investigation** | How many memory searches to spend in one investigation, from 0 to 10. A budget of 0 tells the agent not to search. | 2 |
-| **Record** | Which conclusions are worth a memory: **Every conclusion**, **Non-benign only**, or **Reusable only**, which keeps only a cause, a fix, or a pattern that is known noise under stated conditions. | Every conclusion |
-| **Extra guidance** | Your own instructions about what this agent should or should not remember, added after the settings above. | None |
-
-The search budget is an instruction, not a limit. Grepr does not count an agent's searches or refuse one past the budget, and an agent can search again when a result gives it a specific reason to. A setting you leave empty or at **Default** follows the default, including if the default changes.
-
-## Hand an agent its related history \[#digest]
-
-With the *related-history digest*, an investigation starts with a short list of memories related to its triggering signals, so the agent recognizes a recurring problem before it spends any of the investigation looking for it. The digest is off by default. To turn it on, on the agent's **Memories** step, under **Related-history digest**, turn on **Send related history with the trigger**.
-
-For each triggering signal, Grepr looks up memories tagged with the signal's pattern. When the pattern has no memories in the window, Grepr looks up memories tagged with the signal's service instead. The lookup covers every agent in your organization and keeps memories last seen within the window, so a problem first recorded long ago that keeps recurring still appears.
-
-| Setting | What it controls | Default |
-| --- | --- | --- |
-| **Window (days)** | How long ago a memory can have last been seen and still be listed, from 1 to 90 days. | 14 |
-| **Max items** | How many memories the digest lists in total, from 1 to 20, shared across the triggering signals. | 5 |
-
-Each line of the digest names the memory's ID, whether the agent recorded it, its significance and confidence, how often it recurred, when it was last seen, and whether it matched by pattern or by service. A memory a person edited or marked wrong says so.
-
-The agent treats a digest that checked every triggering signal as its initial memory check, and searches again only for something the digest did not answer, such as older history. When the lookup could not check everything, the agent is told so and searches memory itself, unless its search budget is 0. That happens when the lookup fails, when a signal has no pattern or service tag to look up, when the trigger carries more than 10 tagged signals, or when more memories matched than **Max items** allows.
-
-The agent reads a listed memory in full before it links its investigation to that memory. A continuation of an earlier investigation does not get a digest, and searches memory itself instead.
-
-## Who can read and write memories \[#scope]
-
-* Reads are organization-wide. Any agent can search any other agent's memories in your organization, including an agent that records none of its own. Operational history is only useful shared, so an agent investigating a service finds what another agent concluded about the same service. Permission is uniform across the modes, but coverage is not: a semantic search still examines one agent at a time. See [How an agent searches its memory](#search-modes).
-* Writes are owner-only. A memory can be written or corrected only by the agent that ran the investigation, so one agent cannot overwrite another's conclusions.
-
-When an agent finds that a past memory describes what it is now seeing, it links its investigation to that memory, which raises the recurrence count rather than creating a near-duplicate record. Each contributing investigation counts once.
-
-Memories outlive the agent that wrote them. Deleting an agent leaves its memories searchable by your other agents.
-
-## Review memories in the UI \[#review]
-
-The **Memories** page in the Agents area lists every agent's memories in your organization, most recently seen first. Filter it by any entity tag, such as a service or an environment, and by agent, significance, verdict, or text, then open a memory to read it in full with links to the investigations it came from. An agent's **Memories** step shows the same list below its memory settings, fixed to that agent.
-
-With permission to edit integrations, you can also correct what an agent concluded:
-
-* **Edit** a memory's title, symptoms, root cause and confidence, ruled-out causes, resolution, significance, or tags. Tags derived from the triggering signal cannot be changed. An edit applies only to the version of the memory you opened, so a change a person or an agent made after you opened it is never overwritten without you seeing it first.
-* **Mark it wrong** with a note explaining why. The memory stays searchable, and agents that find it are told a person rejected its conclusion, so they treat its root cause as ruled out rather than as a match.
-* **Delete** it. Deleting removes the memory and its recurrence links, and the investigations keep their transcripts. If the investigation that recorded it records again, that is a new memory.
-
-Agents see when a person edited a memory or marked it wrong. A later investigation that finds the same incident in a memory you edited counts as a recurrence but does not change its text. An agent does not link an investigation to a memory you marked wrong, and records a memory of its own instead. An investigation whose own memory you edited or marked wrong keeps that memory, so the agent cannot remove your review by linking the investigation to another memory. The investigation that recorded a memory can still update it, because the agent that ran the investigation owns it. An update replaces the text you reviewed, but the memory still shows as edited or marked wrong, and the agent is told that your edit or verdict remains. Agents treat the root cause of a memory you marked wrong as ruled out until you clear the verdict. For a memory you edited, agents are told when you edited it, and that the investigation that recorded it might have updated the text since then.
-
-## Search memories from the CLI \[#cli]
-
-The Grepr CLI searches the same memories an agent does, so you can read what your agents have concluded from a terminal or a script as well as on the **Memories** page.
-
-```bash
-# Find investigations mentioning a literal string
-grepr investigation:memory:search --mode text --query "connection refused" --limit 5
-
-# Find investigations whose conclusions are similar in meaning
-grepr investigation:memory:search --mode semantic --agent-id <agent-id> --query "intermittent ingestion failures"
-
-# See what has been happening to one service lately
-grepr investigation:memory:search --mode timeline --entity-tag entity:service=checkout
-
-# Read one memory in full, with the investigations linked to it as recurrences
-grepr investigation:memory:get <memory-id>
-```
-
-A semantic search needs an agent id, because a query can only be compared inside the index that agent embeds into. Text and timeline searches cover every agent in your organization by default. Timeline searches need at least one entity tag.
-
-Search results are compact by default. To read a result's symptoms, root cause, ruled-out causes, and resolution, pass its investigation id to `investigation:memory:get`, which also lists the most recent investigations linked to it.
-
-To learn more about the CLI, see [_](/cli).
-
-## Frequently Asked Questions
-
-### What does Grepr AI agent memory store?
-
-One memory per investigation, holding a title, the symptoms, the root cause and the agent's confidence in it, the causes it ruled out, the resolution, a significance classification, entity tags, and a count of how many investigations reached the same conclusion.
-
-### What do I need for agent memory?
-
-Nothing for recording and for text and timeline searches: every agent records memories unless you turn memory off. Semantic search needs a store, which is three things: a vector index integration whose dimensions match your embedding model, an LLM integration that supplies the embedding model, and the embedding model name. Grepr creates the search index when you create the vector index integration. Saving the agent then checks that the embedding model works against that index, so a wrong model stops the save.
-
-### How does an agent search its memory?
-
-In one of three modes. Semantic search finds conclusions that mean something similar to the query, and covers one agent at a time. Text search finds specific words, such as an error code. Timeline search finds memories about given entities ordered by time. Text and timeline searches cover every agent in the organization by default.
-
-### Can one Grepr AI agent read another agent's memories?
-
-Yes, permission is organization-wide, so any agent can search any other agent's memories in your organization. Coverage differs by mode: text and timeline searches span every agent by default, while a search by meaning targets one agent at a time, because a query is only comparable against embeddings made with that agent's model. Writes are owner-only.
-
-### Can a Grepr AI agent start an investigation with its related history?
-
-Yes, with the related-history digest, which is off by default. When you turn it on, each investigation starts with up to 5 memories related to its triggering signals, looked up by the signal's pattern and then by its service, among memories last seen in the past 14 days. Both numbers are configurable. A continuation of an earlier investigation does not get a digest.
-
-### How do I read what my agents have remembered?
-
-Open the Memories page in the Agents area to browse every agent's memories, filter them by tag, agent, significance, verdict, or text, and open one in full. An agent's Memories step shows the same list for that agent. You can also search them with the grepr investigation:memory:search command.

package/build/dist/docs-index/50e99ec3-b32a-4a9a-ab16-05a47b779cc1.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/50e99ec3-b32a-4a9a-ab16-05a47b779cc1.txt

@@ -1,17 +0,0 @@
-# AttributeRe2Node
-
-**Type**: `object`
-
-## Properties
-
-- name: attribute (required)
-  type: string
-  description: This is the attribute that is matched against the value of the regex field.
-
-- name: regex (required)
-  type: string
-  description: The regex to match. This is a regex string that is matched against the value of the attribute field.
-
-- name: type (required)
-  type: enum: `attribute-re2-node`
-  description: A node that represents an attribute regex in a parsed query.

package/build/dist/docs-index/515ec57c-a384-4474-bfe6-1c34dff564ef.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/515ec57c-a384-4474-bfe6-1c34dff564ef.txt

@@ -1,30 +0,0 @@
-# Apply masks to samples
-
-**POST** `/v1/masking/mask`
-
-**Operation ID**: `mask`
-**Summary**: Apply masks to samples
-Applies a masking operator's masks to sample log events and returns the masked result for each, so the editor can preview a configuration without deploying it. The operator's predicate gates which logs are masked in production, not how, so it is ignored here and the masks are applied to every sample.
-
-## Tags
-- Masking
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `MaskingRequest`
-
-## Responses
-
-### 200
-
-Sample masked successfully.
-
-- **Content-Type**: `application/json` / `MaskingResponse`
-### 400
-
-The masking configuration is invalid or could not be compiled.
-
-### 401
-
-Unauthorized

package/build/dist/docs-index/51e7c12e-39b5-46c8-9ff1-8f96ecc3bb3c.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/51e7c12e-39b5-46c8-9ff1-8f96ecc3bb3c.txt

@@ -1,11 +0,0 @@
-# UsersUpdate
-
-**Type**: `object`
-
-## Properties
-
-- name: leaderUserIds (required)
-  type: array of string
-
-- name: memberUserIds (required)
-  type: array of string

package/build/dist/docs-index/5208203c-016d-41d8-b08b-20d5776087dc.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/5208203c-016d-41d8-b08b-20d5776087dc.txt

@@ -1,23 +0,0 @@
-# IssueActor
-
-Who made a change to an issue. An agent is named by its own id and the investigation it acted in, never by the service account it authenticated as, since several agents may share one.
-
-**Type**: `object`
-
-## Properties
-
-- name: agentId (optional)
-  type: string
-  description: The agent, for an agent actor; null otherwise.
-
-- name: id (optional)
-  type: string
-  description: The person's user id, the agent's execution principal (its service account's token subject), or `system` for the server.
-
-- name: investigationId (optional)
-  type: string
-  description: The investigation the agent acted in, for an agent actor; null otherwise.
-
-- name: kind (optional)
-  type: enum: `PERSON`, `AGENT`, `SYSTEM`
-  description: A person, an agent, or the server.

package/build/dist/docs-index/52256d01-8896-42ec-8467-de029ebfc9c9.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/52256d01-8896-42ec-8467-de029ebfc9c9.txt

@@ -1,10 +0,0 @@
-# ItemsCollectionVendorImportedException
-
-Collection of vendor imported exceptions
-
-**Type**: `object`
-
-## Properties
-
-- name: items (optional)
-  type: array of `VendorImportedException`

package/build/dist/docs-index/52497071-7a04-4c41-abf8-68ae3f2ebcf0.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/52497071-7a04-4c41-abf8-68ae3f2ebcf0.txt

@@ -1,24 +0,0 @@
-# WriteS3DataWarehouse
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-  description: Name of the integration.
-
-- name: payload (required)
-  type: `S3DataWarehouse`
-
-- name: teamIds (optional)
-  type: array of string
-  description: The team IDs that this integration is associated with.
-
-- name: type (required)
-  type: enum: `s3-data-warehouse`
-  description: The type of the integration. This is used to determine the payload type.
-
-- name: version (required)
-  type: integer
-  description: Version of the integration. Should be increased by one for every new update in order for the write to succeed. Otherwise, a '409 Conflict' will be returned.

package/build/dist/docs-index/525aff76-3465-4c1d-9fbf-c397a5bfdd3d.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/525aff76-3465-4c1d-9fbf-c397a5bfdd3d.txt

@@ -1,13 +0,0 @@
-# FileFormat
-
-Describes the file format to read from.
-
-**Type**: `object`
-
-## Properties
-
-- name: mapper (optional)
-  type: `LogEventMapper`
-
-- name: type (required)
-  type: string

package/build/dist/docs-index/5334779a-8997-4fb0-9780-b68c9c585274.json

@@ -1 +0,0 @@
-{"docType":"doc"}

package/build/dist/docs-index/5334779a-8997-4fb0-9780-b68c9c585274.txt

@@ -1,96 +0,0 @@
-Understand the lifecycle of a Grepr job, including the states and transitions for asynchronous streaming, batch jobs, and job management operations.
-
-# Track the lifecycle of jobs with the Grepr REST API
-
-Grepr makes APIs available to track the lifecycle of jobs through the `state` field returned as part of the Job APIs. The following sections describe the different lifecycles of jobs.
-
-## Asynchronous streaming jobs
-
-These are long-running jobs that are also known as pipelines.
-
-### Create job lifecycle \[#job-create-lifecycle]
-
-The following states describe the lifecycle of an `ASYNCHRONOUS` `STREAMING` job submitted for creation:
-
-* `PENDING`: The job has been submitted for creation but has not reached its desired state yet. Grepr allocates appropriate resources, starts the job, and ensures it's in a healthy state.
-* `RUNNING`: The job is running and processing data.
-* `STOPPED`: The job has been stopped and is not processing data. When it starts again, the job resumes processing with the most recent data received.
-* `FAILED`: The job failed to start. This failure could happen due to some invalid configuration of the job graph or errors in processing data. In this case, you can either resubmit or update the job after correction.
-
-### 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 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.
-
-The following states describe the lifecycle of an `ASYNCHRONOUS` `STREAMING` job submitted for an update. It represents concurrent state transitions of the old and new job versions.
-
-In case of a failure in the new job version, Grepr will roll back to the old job version if `rollbackEnabled` is set to `true`. A new job version (2) is created using the same job graph as job version 0. It will follow the same state transitions as when creating a new job. For more information, see the [API specification](#job-create-lifecycle).
-
-The states in this case will be:
-
-* **Old job version**: 0, job state: `FINISHED`, desiredState: `FINISHED`.
-* **New job version**: 1, job state: `FAILED`, desiredState: `RUNNING`.
-* **Rollback job version**: 2, job state: `PENDING`, desiredState: `RUNNING`.
-
-### Delete job lifecycle
-
-The following states describe the lifecycle of an `ASYNCHRONOUS` `STREAMING` job submitted for deletion:
-
-## Batch jobs
-
-These are potentially short-lived jobs that support querying on user data. These are also defined as job graphs but work on scoped data.
-
-### Asynchronous batch jobs
-
-These support asynchronous operations on user data. Grepr exposes APIs to submit and track the lifecycle of these jobs. Since they're short-lived, updates and deletes are not supported on them. Once submitted, you can use the `GET /jobs` API to track the `state` attribute of the job.
-
-The following state transitions are possible:
-
-One use-case for Async Batch Jobs is backfilling log data, which includes running a job to load data from the Grepr data lake back to your observability platform.
-
-### Synchronous batch jobs
-
-These support synchronous queries on user data. Grepr exposes APIs to submit these jobs and stream the results back to the client. The lifecycle of these jobs is simpler than the streaming jobs in that they are submitted, processed, and then completed. In some cases, where they're running beyond a max amount of time (default 30s), they will be cancelled.
-
-## Frequently Asked Questions
-
-### What does the PENDING state mean for a streaming job?
-
-PENDING indicates the job has been submitted for creation but has not reached its desired state yet. Grepr is allocating appropriate resources, starting the job, and ensuring it reaches a healthy state before transitioning to RUNNING.
-
-### What is the difference between STOPPED and FAILED states?
-
-STOPPED means the job was intentionally stopped and is not processing data, but can be restarted to resume processing with the most recent data. FAILED means the job encountered an error during startup or processing, likely due to invalid configuration or processing errors, and needs correction before resubmission.
-
-### How do job updates work and what are the version transitions?
-
-Job updates are versioned operations. When you submit an update, the old version is retired while the new version is deployed concurrently. Both versions transition through states - the old to FINISHED and the new to RUNNING. If rollbackEnabled is true, the system automatically reverts to the old version on failure.
-
-### What is rollbackEnabled and when should I use it?
-
-rollbackEnabled is a parameter in job update requests that, when set to true, automatically rolls back the job to the previously running version if the new version fails. This ensures minimal downtime in data processing caused by misconfiguration.
-
-### How does automatic rollback work if an update fails?
-
-If a new job version fails and rollbackEnabled is true, Grepr creates a rollback version (version 2) using the same job graph as the previously working version (version 0). The rollback version follows the same state transitions as a new job creation.
-
-### What states can a job enter during deletion?
-
-During deletion, an ASYNCHRONOUS STREAMING job transitions through states like PENDING_DELETE and then FINISHED, ensuring a clean shutdown of the job and proper resource cleanup before the job is fully removed.
-
-### What are the possible state transitions for asynchronous batch jobs?
-
-Asynchronous batch jobs transition through states that track submission, processing, and completion. Unlike streaming jobs, they are short-lived and follow a simpler state progression optimized for query operations.
-
-### Why do synchronous batch jobs have a timeout?
-
-Synchronous batch jobs are designed for real-time queries and have a default maximum execution time of 30 seconds. This timeout prevents long-running queries from blocking the client and ensures responsive performance.
-
-### How should I poll for job status updates?
-
-Use the GET /jobs endpoint to retrieve the current job state and desiredState fields. Poll regularly (every few seconds is typical) until the job reaches its terminal state (RUNNING, FAILED, FINISHED, STOPPED, etc.).
-
-### Can I revert a failed job update to a specific previous version?
-
-If rollbackEnabled was set during the update, Grepr automatically rolls back to the previous working version. If you need to revert to an older version manually, you can submit a new update with the desired configuration from that version.

package/build/dist/docs-index/537b6b6f-d36e-4671-b826-13e0eb2c9efb.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/537b6b6f-d36e-4671-b826-13e0eb2c9efb.txt

@@ -1,11 +0,0 @@
-# AgentMcpIntegrations
-
-**Type**: `object`
-
-## Properties
-
-- name: allowedTools (optional)
-  type: array of string
-
-- name: integrationId (required)
-  type: string

package/build/dist/docs-index/53880834-668e-49f8-85d5-6305189b2d2b.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/53880834-668e-49f8-85d5-6305189b2d2b.txt

@@ -1,8 +0,0 @@
-# ItemsCollectionReadNewRelic
-
-**Type**: `object`
-
-## Properties
-
-- name: items (optional)
-  type: array of `ReadNewRelic`

package/build/dist/docs-index/5388397a-330a-43a0-8a8a-863c2db60dab.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/5388397a-330a-43a0-8a8a-863c2db60dab.txt

@@ -1,24 +0,0 @@
-# Delete a webhook integration
-
-**DELETE** `/v1/integrations/webhooks/{id}`
-
-**Operation ID**: `delete_13`
-**Summary**: Delete a webhook integration
-Deletes a webhook integration. No-op if already deleted.
-
-## Tags
-- Webhook Integration
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 204
-
-Integration deleted successfully
-
-### 401
-
-Unauthorized

package/build/dist/docs-index/53aa0ce7-fac2-4a32-bfa1-200f7c064724.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/53aa0ce7-fac2-4a32-bfa1-200f7c064724.txt

@@ -1,19 +0,0 @@
-# SetIssueLocksRequest
-
-Replaces an issue's locks; people only. A lock kept from before keeps who set it and when; a new one records the caller. Leaving a lock out unlocks it.
-
-**Type**: `object`
-
-## Properties
-
-- name: fields (required)
-  type: array of enum: `PRIORITY`, `ENTITIES`, `EXPIRES_AT`, `ASSIGNEES`
-  description: The fields to keep locked.
-
-- name: labels (required)
-  type: object
-  description: The label locks to keep, keyed by label: `PRESENT` only for a label the issue has, `ABSENT` only for one it does not.
-
-- name: version (required)
-  type: integer
-  description: The version the lock set was read at; a stale one is rejected with 409.

package/build/dist/docs-index/53d7a27f-06f3-4acc-a732-b8097e72914d.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/53d7a27f-06f3-4acc-a732-b8097e72914d.txt

@@ -1,9 +0,0 @@
-# ResetImpactEstimationResponse
-
-**Type**: `object`
-
-## Properties
-
-- name: rowsCleared (required)
-  type: integer
-  description: Number of estimation rows whose cached impact percentage was cleared. Zero when nothing was in scope (no opted-in sink datasets, or no estimation-capable integrations).

package/build/dist/docs-index/544af86e-4c54-467a-87ed-3208265a3a20.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/544af86e-4c54-467a-87ed-3208265a3a20.txt

@@ -1,5 +0,0 @@
-# LatestReadingStrategy
-
-Strategy to read files created after the current job start time
-
-**Type**: `object`

package/build/dist/docs-index/547e1f66-8591-4ab3-a45b-9417e46f566b.json

@@ -1 +0,0 @@
-{"docType":"api"}