@grepr/cli 1.12.7 → 1.14.3-5fb972a

package/build/dist/docs-index/f1479b37-5079-429a-93d0-8feb96fb4f43.txt

@@ -1,23 +0,0 @@
-# ChatStatusResponse
-
-**Type**: `object`
-
-## Properties
-
-- name: autoApprove (optional)
-  type: boolean
-
-- name: model (optional)
-  type: `ModelConfiguration`
-
-- name: pendingApproval (optional)
-  type: `PendingApproval`
-
-- name: processing (optional)
-  type: boolean
-
-- name: status (optional)
-  type: string
-
-- name: turnIndex (optional)
-  type: integer

package/build/dist/docs-index/f1506aaf-90bc-4b49-b316-871ebb742c3f.json

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

package/build/dist/docs-index/f1506aaf-90bc-4b49-b316-871ebb742c3f.txt

@@ -1,47 +0,0 @@
-# List jobs
-
-**GET** `/v1/jobs`
-
-**Operation ID**: `getJobs`
-**Summary**: List jobs
-Get the list of jobs for your organization based on filters.
-
-## Tags
-- Jobs
-## Parameters
-
-- **since** (optional) - query
-  - Optional reference time to fetch jobs after. The value must represent a valid instant in UTC parseable using DateTimeFormatter.ISO_INSTANT. Eg: 2007-12-03T10:15:30.00Z
-  - Type: string
-- **execution** (optional) - query
-  - Optional filter to fetch jobs of specific execution types
-  - Type: enum: `SYNCHRONOUS`, `ASYNCHRONOUS`
-- **processing** (optional) - query
-  - Optional filter to fetch jobs of specific processing types
-  - Type: enum: `BATCH`, `STREAMING`
-- **latest** (optional) - query
-  - Optional flag to fetch only the latest versions of the jobs
-  - Type: boolean
-- **state** (optional) - query
-  - Optional filter to fetch a subset of states
-  - Type: array of enum: `CREATED`, `PENDING`, `INFRA_UPDATE`, `INFRA_UPDATE_WAIT`, `VERIFYING`, `WAITING`, `RUNNING`, `STOPPED`, `FINISHED`, `FAILED`, `CANCELLED`, `DELETED`, `UPDATING`, `STARTING`, `RESTARTING`, `STOPPING`, `ROLLING_BACK`, `DELETING`
-- **name** (optional) - query
-  - Optional filter to fetch specific jobs by name
-  - Type: array of string
-- **id** (optional) - query
-  - Optional filter to fetch specific jobs by id
-  - Type: array of string
-- **tag** (optional) - query
-  - Optional filter to fetch only jobs carrying every given tag, each as key:value
-  - Type: array of string
-
-## Responses
-
-### 201
-
-Jobs retrieved successfully
-
-- **Content-Type**: `application/json` / `ItemsCollectionReadJob`
-### 401
-
-Unauthorized

package/build/dist/docs-index/f2043320-79c4-457e-8d24-06c77e06fdc4.json

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

package/build/dist/docs-index/f2043320-79c4-457e-8d24-06c77e06fdc4.txt

@@ -1,11 +0,0 @@
-# SkippedInvestigation
-
-**Type**: `object`
-
-## Properties
-
-- name: investigationId (optional)
-  type: string
-
-- name: reason (optional)
-  type: enum: `NOT_FOUND`, `ALREADY_FINISHED`

package/build/dist/docs-index/f248f67a-962b-4f90-8231-8f67d9061551.json

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

package/build/dist/docs-index/f248f67a-962b-4f90-8231-8f67d9061551.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/f2a9fd7e-f506-4b0f-8cfa-5a9337047dbc.json

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

package/build/dist/docs-index/f2a9fd7e-f506-4b0f-8cfa-5a9337047dbc.txt

@@ -1,43 +0,0 @@
-# AthenaAgentSessionsSource
-
-**Type**: `object`
-
-## Properties
-
-- name: datasetId (required)
-  type: string
-  description: The ID of the dataset to read data from.
-
-- name: end (required)
-  type: string
-  description: End of time interval to query data for.
-
-- name: limit (optional)
-  type: integer
-  description: The maximum number of rows to process
-
-- name: name (required)
-  type: string
-
-- name: offset (optional)
-  type: integer
-  description: Offset on the number of rows to process
-
-- name: query (required)
-  type: `query`
-
-- name: sortOrder (optional)
-  type: enum: `ASCENDING`, `DESCENDING`, `UNSORTED`
-  description: The order in which the rows should be sorted by
-
-- name: start (required)
-  type: string
-  description: Start of time interval to query data for.
-
-- name: type (required)
-  type: enum: `athena-agent-sessions-source`
-  description: Returns grouped agent session summaries through Athena.
-
-- name: variables (optional)
-  type: object
-  description: Variables that can be used to modify the query while parsed

package/build/dist/docs-index/f34c12c1-048d-4a15-8df7-c75d6d7df72f.json

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

package/build/dist/docs-index/f34c12c1-048d-4a15-8df7-c75d6d7df72f.txt

@@ -1,26 +0,0 @@
-# LlmUsageWindow
-
-**Type**: `object`
-
-## Properties
-
-- name: end (optional)
-  type: string
-
-- name: investigationsQueued (optional)
-  type: integer
-
-- name: investigationsRunning (optional)
-  type: integer
-
-- name: start (optional)
-  type: string
-
-- name: tokensLimit (optional)
-  type: integer
-
-- name: tokensReserved (optional)
-  type: integer
-
-- name: tokensUsed (optional)
-  type: integer

package/build/dist/docs-index/f36c3fd7-01fd-4ec3-a6c9-e330393a500a.json

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

package/build/dist/docs-index/f36c3fd7-01fd-4ec3-a6c9-e330393a500a.txt

@@ -1,17 +0,0 @@
-# Delete a Grepr API Key
-
-**DELETE** `/v1/apikey`
-
-**Operation ID**: `deleteGreprApiKey`
-**Summary**: Delete a Grepr API Key
-## Tags
-- Grepr API Key
-## Responses
-
-### 204
-
-API key deleted successfully
-
-### 401
-
-API key is invalid

package/build/dist/docs-index/f3b01e85-7554-4ecd-be1b-63062457c32e.json

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

package/build/dist/docs-index/f3b01e85-7554-4ecd-be1b-63062457c32e.txt

@@ -1,40 +0,0 @@
-# Pause or resume an agent's pipeline subscription
-
-**PUT** `/v1/agents/{id}/pipelines/{jobId}/state`
-
-**Operation ID**: `setPipelineState`
-**Summary**: Pause or resume an agent's pipeline subscription
-Sets one subscription to PAUSED or ACTIVE. While paused, new signals from the pipeline are dropped for this agent, and the pipeline keeps marking new patterns as sent. Investigations already queued still run. The running pipeline is not restarted.
-
-## Tags
-- Agents
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-- **jobId** (required) - path
-  - Type: string
-
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `StateChangeRequest`
-
-## Responses
-
-### 204
-
-State set (or already set)
-
-### 400
-
-The state is not ACTIVE or PAUSED
-
-### 401
-
-Unauthorized
-
-### 404
-
-Agent not found, or not subscribed to the pipeline

package/build/dist/docs-index/f3e656ed-af23-4a5e-96f6-4cbd77dbbae6.json

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

package/build/dist/docs-index/f3e656ed-af23-4a5e-96f6-4cbd77dbbae6.txt

@@ -1,124 +0,0 @@
-Learn how to use Grepr's AWS PrivateLink endpoint service to send data to Grepr over private AWS networking instead of the public internet.
-
-# Securely forward observability data to Grepr with AWS PrivateLink
-
-You can securely send your observability data to Grepr over private AWS networking using Grepr's PrivateLink endpoint service. The endpoint service is available in the `us-east-1` region.
-
-AWS PrivateLink lets a service provider offer a service to other AWS accounts through an *endpoint service*. An endpoint service makes the provider's service available in an AWS Region without exposing it to the public internet. The AWS account that uses an endpoint service is a *service consumer*. Grepr is the service provider for its ingestion endpoint service, and your AWS account is the service consumer.
-
-As a service consumer, you connect to the Grepr endpoint service by creating an *interface VPC endpoint* in your own virtual private cloud (VPC). The interface endpoint provisions network interfaces with private IP addresses in the subnets you specify, and traffic to the endpoint service flows through those interfaces over the AWS private network.
-
-Connecting to Grepr through PrivateLink provides the following benefits:
-
-* Ingest traffic stays on the AWS private network and never traverses the public internet, which reduces your exposure to network-based threats.
-* You can send data to Grepr without an internet gateway, a NAT device, or public IP addresses for your ingest traffic.
-* Keeping traffic on the AWS private network can reduce data transfer costs compared to routing ingest traffic over the public internet.
-
-## Requirements \[#requirements]
-
-To connect to Grepr's PrivateLink endpoint service, you must have:
-
-* An AWS account with a VPC in the `us-east-1` region.
-* Your VPC must span at least one of the following availability zones: `use1-az1`, `use1-az2`, or `use1-az6`.
-* The VPC must have private DNS enabled. Enabling private DNS on the endpoint lets the private ingestion URL resolve to the interface endpoint from your VPC.
-* One or more subnets in those availability zones to host the interface endpoint network interfaces.
-* Permission in your AWS account to create interface VPC endpoints and security groups.
-* The private ingestion URL from the Grepr integration that's used to create sources in your pipelines.
-* To use Terraform to configure your VPC requires the Terraform CLI version 1.0 or later.
-
-## Set up your VPC \[#set-up-vpc]
-
-To connect to Grepr's endpoint service, create an interface VPC endpoint in your VPC that points to the endpoint service.
-
-The following Terraform configuration looks up the subnets in the supported availability zones, creates a security group that allows TLS traffic to the endpoint, and creates the interface VPC endpoint:
-
-```hcl
-data "aws_subnets" "endpoint" {
-  filter {
-    name   = "vpc-id"
-    values = [var.consumer_vpc_id]
-  }
-  filter {
-    name   = "availability-zone-id"
-    values = ["use1-az1", "use1-az2", "use1-az6"]
-  }
-}
-
-resource "aws_security_group" "ingestion_endpoint" {
-  name        = "grepr-ingestion-privatelink"
-  description = "Egress to the Grepr ingestion PrivateLink endpoint service over TLS:443."
-  vpc_id      = var.consumer_vpc_id
-
-  ingress {
-    from_port   = 443
-    to_port     = 443
-    protocol    = "tcp"
-    cidr_blocks = [var.consumer_vpc_cidr] # callers inside the VPC reaching the ENIs
-    description = "TLS from in-VPC clients to the interface endpoint ENIs."
-  }
-
-  egress {
-    from_port   = 0
-    to_port     = 0
-    protocol    = "-1"
-    cidr_blocks = ["0.0.0.0/0"]
-  }
-}
-
-resource "aws_vpc_endpoint" "ingestion" {
-  vpc_id              = var.consumer_vpc_id
-  service_name        = "com.amazonaws.vpce.us-east-1.vpce-svc-096296e52f78a0df0"
-  vpc_endpoint_type   = "Interface"
-  subnet_ids          = data.aws_subnets.endpoint.ids
-  security_group_ids  = [aws_security_group.ingestion_endpoint.id]
-  private_dns_enabled = true # required for clients to resolve "*.ingest.private.grepr.ai"
-  tags                = { Name = "grepr-ingestion-endpoint" }
-}
-```
-
-Replace `var.consumer_vpc_id` with your VPC ID and `var.consumer_vpc_cidr` with the configured CIDR blocks for your VPC.
-
-After you apply the configuration, the interface endpoint connects to Grepr's endpoint service. When the endpoint reaches the `Available` state, you can send data to Grepr through it.
-
-## Use the private ingestion URL \[#use-private-url]
-
-To send data to Grepr through your interface endpoint, configure your collector or agent with the *private ingestion URL* instead of the public ingestion URL. The private ingestion URL has the same format as the public ingestion URL, with `.private` inserted after the `ingest` host segment:
-
-`https://<integration-id>-<org-id>.ingest.private.grepr.ai`
-
-The token and path are the same as the public ingestion URL, so only the host changes. To get the private ingestion URL from the Grepr UI:
-
-* On the details page for your pipeline, click **Sources** in the left pane. The **Sources** pane lists both a **Public** and a **Private** ingest URL, each with its own copy button. Copy the **Private** ingest URL.
-* Alternatively, on the **Integrations** page, open the menu on the vendor card for your integration and select **Copy Private Ingestion URL**.
-
-After you copy the private ingestion URL, set it as the ingestion URL in your collector or agent configuration. To learn more about configuring a collector or agent to send data to a Grepr ingestion URL, see [Configure vendor and storage connections](/integrations).
-
-## Frequently Asked Questions
-
-### What is an AWS PrivateLink endpoint service?
-
-An AWS PrivateLink endpoint service is a service that a provider makes available to other AWS accounts within a Region without exposing it to the public internet. Grepr publishes an endpoint service for ingestion. As a service consumer, you connect to it by creating an interface VPC endpoint in your own VPC, and traffic flows over the AWS private network.
-
-### What is a service consumer in AWS PrivateLink?
-
-A service consumer is the AWS account that uses an endpoint service published by a provider. When you connect to Grepr over PrivateLink, your AWS account is the service consumer and Grepr is the service provider.
-
-### What are the benefits of connecting to Grepr over AWS PrivateLink?
-
-Ingest traffic stays on the AWS private network and never traverses the public internet, which reduces exposure to network-based threats. You can send data to Grepr without an internet gateway, NAT device, or public IP addresses for ingest traffic, and keeping traffic on the AWS private network can reduce data transfer costs.
-
-### Which AWS Regions and availability zones does Grepr's PrivateLink endpoint service support?
-
-Grepr's PrivateLink endpoint service is offered in the us-east-1 region. Your VPC must span at least one of the availability zones use1-az1, use1-az2, or use1-az6.
-
-### What is the format of the private ingestion URL?
-
-The private ingestion URL has the same format as the public ingestion URL, with .private inserted after the ingest host segment, for example, https\://\<integration-id>-\<org-id>.ingest.private.grepr.ai. The token and path are the same as the public ingestion URL, so only the host changes.
-
-### Where do I find the private ingestion URL?
-
-You can copy the private ingestion URL from the Grepr UI. On the details page for your pipeline, click Sources in the left pane and copy the Private ingest URL. You can also open the menu on the vendor card for your integration on the Integrations page and select Copy Private Ingestion URL.
-
-### Why does my private ingestion URL fail to resolve?
-
-The private ingestion URL resolves to your interface endpoint only when private DNS is enabled on the endpoint. Make sure private_dns_enabled is set to true on the interface VPC endpoint, and confirm that the endpoint is in the Available state.

package/build/dist/docs-index/f41cebfb-c21a-4c60-8f75-a835f9d5a532.json

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

package/build/dist/docs-index/f41cebfb-c21a-4c60-8f75-a835f9d5a532.txt

@@ -1,17 +0,0 @@
-# AttributeWildcardNode
-
-**Type**: `object`
-
-## Properties
-
-- name: attribute (required)
-  type: string
-  description: The attribute name
-
-- name: type (required)
-  type: enum: `attribute-wildcard-node`
-  description: A node that represents an attribute wildcard in a parsed query.
-
-- name: wildcard (required)
-  type: string
-  description: The term to match. This is a wildcard string that contains wildcards

package/build/dist/docs-index/f4433e94-4a67-4b96-a070-b8a5aafb6e17.json

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

package/build/dist/docs-index/f4433e94-4a67-4b96-a070-b8a5aafb6e17.txt

@@ -1,15 +0,0 @@
-# TemplateInput
-
-Input values for instantiating a template.
-
-**Type**: `object`
-
-## Properties
-
-- name: draft (optional)
-  type: boolean
-  description: Whether to enable draft mode for the template. In draft mode, the template will receive an additional 'draft' variable with value 'true'. The template should then produce a job graph that includes draft outputs.
-
-- name: values (optional)
-  type: object
-  description: Map of variable names to their values.

package/build/dist/docs-index/f476e775-e29c-4b43-a415-b99447c85fd7.json

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