# Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation This site has an agentic ask interface you may use to query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.kosmoslabs.ai/index.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. --- # Getting Started What to expect after connecting your systems *** Welcome to Kosmos. This guide walks you through what to expect after connecting your systems. ### How Kosmos Works Kosmos connects to your existing tools to analyze patterns across your delivery and support data. We identify correlations that identify and prevent recurring incidents before they impact your customers. **Supported integrations:** * **Project Management:** Jira, Linear, Azure DevOps * **Source Control:** GitHub, GitLab, Bitbucket, Azure DevOps * **Setup guides:** [GitHub](/product-documentation/connecting-github) · [GitLab](/product-documentation/connecting-gitlab) · [Azure DevOps](/product-documentation/connecting-azure-devops) · [Salesforce](/product-documentation/connecting-salesforce) · [OpenTelemetry](/product-documentation/connecting-opentelemetry-preview) * **Support & ITSM:** Salesforce Service Cloud, ServiceNow, Zendesk, Pylon * **Observability:** OpenTelemetry (Preview) * **Notifications:** Slack, Microsoft Teams **Our methodology:** INGEST → CORRELATE → SURFACE → ACT → LEARN ### What Happens After You Connect #### 1. Initial Sync Once your integrations are connected, Kosmos begins syncing data from your systems. This typically takes 10-30 minutes depending on data volume. #### 2. Historical Baseline Your Kosmos team triggers a 90-day historical analysis of your data to create a baseline. This baseline surfaces patterns your team may have been missing—recurring issues, deployment correlations, and systemic risks. #### 3. Results Presentation Within the first week, your Kosmos team will walk you through the findings, including: * Identified Risk Events and their root causes * Correlations between deployments and incidents * Recommendations for prevention Not every correlation Kosmos finds becomes a Risk Event. Your team will walk you through how that line is drawn, and where to find the correlations that did not cross it. See [How a correlation becomes a Risk Event](/product-documentation/understanding-results#how-a-correlation-becomes-a-risk-event). #### 4. Ongoing Monitoring After the initial analysis, Kosmos continuously monitors your connected systems to detect emerging risks and alert you before issues escalate. When a Risk Event is detected, you'll receive a notification in your configured Slack or Teams channel. ### Your Dashboard After logging in at [app.kosmoslabs.ai](https://app.kosmoslabs.ai/), the home page is organized as an inbox-first view. Kosmos works on phones and tablets as well as desktop, so you can triage from wherever you are: * **Risk Events inbox** — A hero card at the top shows how many Risk Events are waiting for review, with a breakdown by confidence level and how long the oldest one has been open. Click anywhere on the card to go directly to your Risk Events queue. * **Recent activity** — A feed of the latest team actions on Risk Events: who promoted, dismissed, or acknowledged what, and when. AI-surfaced events are highlighted. * **Background activity** — A summary card showing system stats: signals ingested in the last 24 hours, active clusters, connected systems, and when the engine last recomputed. This is informational — the engine manages this automatically. The left navigation gives you access to: * **Risk Events** — Your action queue. Review, promote to RCA, or dismiss. * **RCA Reports** — Confirmed root cause analyses with correlated evidence * **Correlation Library** — The research view of all clusters the engine has surfaced, including the ones that did not become Risk Events and the reason why. Use for context and investigation, not as a starting point for action. * **Integrations** — Status of your connected systems * **Settings** — Field mappings, notification preferences, and configuration * **Settings → Developer** — API keys and webhook endpoints for programmatic access. See [Managing API Keys and Webhooks](/product-documentation/managing-api-keys-and-webhooks). ### Notifications Kosmos sends alerts to Slack or Teams when: * A new Risk Event is detected * An RCA is confirmed Kosmos also sends a Slack alert (not yet available for Teams) if a connected integration disconnects or needs re-authentication, and a follow-up alert once it reconnects—so you can act before it affects your results. Configure your notification channel in Settings → Integrations. ### Getting Help During your trial, your dedicated Kosmos team is your first point of contact. Reach out anytime: * **Email:** * **Your Kosmos contact:** \[Provided during onboarding] ### Next Steps 1. Review your connected integrations in Settings 2. Await your Historical Baseline results (your team will schedule the review) 3. Explore initial Risk Events as they appear in your dashboard *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # Security Overview Machines propose. Humans confirm. That trust model extends to every layer of how Kosmos handles your data — from integration scopes to infrastructure to our path toward SOC 2. **V1.6 · Updated August 2026** {% hint style="success" %} **Read-only by design.** Kosmos requests minimum required scopes across all connected systems. We read signal metadata to surface root cause; we never write to your source systems, and we never duplicate raw data beyond what correlation requires. {% endhint %} *** ## At a Glance * **0** high-severity findings — OWASP ZAP DAST across 247 endpoints (Mar 2026) * **TLS 1.3** encryption in transit * **Read-only scopes** across every connector; no write permission is requested on any connected system * **Fine-grained, per-repository** access for GitHub via the Kosmos GitHub App * **SOC 2 Type 1** report issued July 31, 2026 — request access through our [Trust Center](https://trust.kosmoslabs.ai) * **35 controls** continuously monitored, backed by **25 published internal policies** *** ## Infrastructure & Application Security ### GCP-Native Architecture Kosmos is deployed entirely on Google Cloud Platform. No third-party infrastructure providers are used for compute, storage, or networking. **Services in use:** * **Cloud Run** — stateless API and service execution * **Cloud SQL (PostgreSQL)** — structured signal and correlation data * **Google Cloud Storage** — signal metadata and artifact storage * **DuckDB** — embedded analytical query engine for correlation workloads * **Vertex AI (Gemini 2.5 Flash)** — RCA generation and `text-embedding-004` embeddings ### Encryption * **In transit:** TLS 1.3 across all endpoints and service-to-service calls * **Application layer:** OAuth tokens encrypted before storage * **Secrets:** Managed in GCP Secret Manager with version control and access audit logs ### Authentication * **User sessions:** Firebase Auth; tokens validated on every API call * **Service-to-service:** GCP IAM service accounts; no long-lived credentials shared across services * **Integrations:** OAuth 2.0 for most connectors, with tokens encrypted before storage. GitHub uses the Kosmos GitHub App, authenticating with short-lived installation tokens minted on demand rather than a long-lived stored credential. The app private key is held in GCP Secret Manager and never logged. ### Multi-Tenant Isolation Data is isolated at the application layer. Every record, query, and storage operation is scoped by organization identifier. Tenant boundaries are enforced regardless of storage backend. ### Network Protection, CSRF & Rate Limiting * **Cloud Armor** — public API traffic is protected at the network edge against volumetric and application-layer denial-of-service attacks * State token validation on all OAuth authorization flows * Double-submit cookie pattern on all state-changing requests * IP-based rate limits on all public-facing endpoints * Per-key rate limits on public API requests, with standard rate limit headers on every response ### Audit Trail & PII Redaction Auth events, integration activity, and RCA generation are written to a structured audit trail. Email addresses and credentials are redacted before log emission. *** ## Data Handling ### What Kosmos Reads Signal metadata from connected systems: issues, tickets, commits, messages, and traces. All integrations operate on minimum required, read-only scopes. For source control, Kosmos reads commit and pull request metadata, not the contents of your source code. ### What Kosmos Stores Signal metadata and correlation results only. Kosmos does not duplicate raw source records beyond what correlation requires. Data is stored in Cloud SQL (PostgreSQL), Google Cloud Storage, and DuckDB. ### Data Deletion On contract termination, all customer data is deleted within **30 days**. Hard-delete is available on written request to . ### Subprocessors * **Google Cloud Platform** — compute, storage, networking * **Vertex AI (Gemini 2.5 Flash)** — RCA generation and `text-embedding-004` embeddings * **Firebase Auth** — user authentication A complete subprocessor list including notification providers is available on request. *** ## Connected Systems ### Generally Available Jira · Salesforce · ServiceNow · Zendesk · GitHub · Bitbucket · GitLab · Azure DevOps · Slack · Microsoft Teams · Linear · Pylon ### Preview {% hint style="info" %} **OpenTelemetry** is currently in preview. Supported observability platforms: Datadog, Grafana, Splunk, Dynatrace, AWS CloudWatch, Azure Monitor, Google Cloud Observability, and New Relic. Contact your account team to enable OTel for your organization. {% endhint %} *** ## SOC 2 Certification Path ### ✅ Complete — Mar 2026 · Codebase Security Review OWASP ZAP DAST scan across 247 endpoints. **0 high-severity findings.** ### ✅ Complete — Apr 2026 · Salesforce AppExchange Security Review Kosmos passed the Salesforce AppExchange security review. The managed package is available for installation in production and sandbox Salesforce orgs. [View on AppExchange](https://appexchange.salesforce.com/appxListingDetail?listingId=a0NHu00000srMgrMAE). ### ✅ Complete — May 2026 · P0 Audit Blockers Vendor risk register, data processing agreements (DPAs), and incident response plan finalized. ### ✅ Complete — Jul 31, 2026 · SOC 2 Type 1 Report Issued Point-in-time controls assessment complete, with the report issued July 31, 2026. Request the SOC 2 Type 1 report through our [Trust Center](https://trust.kosmoslabs.ai). ### 🟣 In Progress — Sept 2026 · SOC 2 Type 2 Audit Observation period underway on an accelerated schedule based on scope. Type 2 report targeted September 2026. *** ## Security Contact Security inquiries are answered within **1 business day**. **Email:** Available on request: * SOC 2 Type 1 report * Penetration test results * Data Processing Agreement (DPA) * Security questionnaire responses * Complete subprocessor list ### Trust Center Our [Trust Center](https://trust.kosmoslabs.ai) is the single place for procurement and security reviews. It carries: * **Compliance status** — SOC 2 Type 1, issued July 31, 2026; Type 2 observation period underway * **35 monitored controls** — continuously monitored across our infrastructure and processes, covering access rights, change management, credential management, configuration and patch management, data privacy, and data retention and destruction * **25 internal policies** — including access control and least privilege, vendor and third-party risk, secure configuration and hardening, background screening and on/off-boarding, and backup, business continuity and disaster recovery * **A security FAQ** — short answers to the questions that come up most in security review * **Subprocessor and document requests** — click **Request Access** to request the SOC 2 Type 1 report, our complete subprocessor list, and other controlled documentation Requests are reviewed and answered within **1 business day**. *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # KOSMOS Platform Overview Operational intelligence for customer-impacting incidents. Kosmos connects to the systems your support and engineering teams already use; Salesforce, Jira, GitHub, and others; and correlates signals across them to surface root cause during customer-impacting incidents. What used to take hours of manual investigation surfaces in minutes. Machines propose. Humans confirm. {% embed url="" %} # Understanding Results How to interpret Risk Events and RCA Reports Kosmos analyzes your incident data to surface patterns and prevent recurring issues. Here's how to interpret what you see. ### Key Concepts #### Risk Events A **Risk Event** is Kosmos's machine-generated analysis of a correlation that shows something went wrong in production. Think of these as early warnings that something in your delivery process needs attention. Kosmos correlates signals continuously and only a subset of those correlations become Risk Events. A correlation is promoted when it carries evidence of real customer or production impact, not merely because the correlation is strong. See [How a correlation becomes a Risk Event](#how-a-correlation-becomes-a-risk-event) below for the specific criteria. Correlations that do not meet those criteria are still kept and still searchable in the [Correlation Library](#the-correlation-library). They simply don't page anyone. **Not every Risk Event requires action.** Some may be expected (planned maintenance, known issues). You can dismiss Risk Events that aren't relevant, and Kosmos learns from your feedback. #### RCA Reports An **RCA Report** (Root Cause Analysis) is a **human-confirmed** analysis. When you review a Risk Event and determine it represents a real issue, you promote it to an RCA with one click. The underlying analysis is the same - promotion is a status change that marks it as the official record. **Why this distinction matters:** Machines propose. Humans confirm. Kosmos won't label something as an "official RCA" without your confirmation. This protects you from inaccurate automated outputs being treated as fact. You stay in control. RCA Reports include: * **Summary:** Plain-language explanation of what happened * **Correlated Evidence:** Linked commits, PRs, tickets, and cases * **Timeline:** Sequence of events leading to the issue * **Recommendations:** Suggested preventive actions *** ### Reading the Dashboard #### Risk Events View Risk Events are organized into tabs by status — **Inbox**, **Acknowledged**, and **Dismissed** — replacing the previous dropdown filter. Rows show the pattern, severity, first seen date, and occurrence count at a glance, with pill badges indicating severity and status. | Column | Meaning | | --------------- | ------------------------------------------------- | | **Status** | New, Acknowledged, Dismissed | | **Severity** | High, Medium, Low — based on frequency and impact | | **Pattern** | Description of what Kosmos detected | | **First Seen** | When this pattern first appeared | | **Occurrences** | How many times this pattern has repeated | **Actions you can take on a single Risk Event:** * **Acknowledge** — You're aware and investigating * **Promote to RCA** — Generate a full root cause analysis * **Dismiss** — Not relevant; Kosmos will learn from this **Bulk actions:** Select multiple Risk Events using the checkboxes to acknowledge, dismiss, or promote them in one action. **Acting from Slack:** If your organization enables **Interactive Confirmation in Slack** in the Slack notification settings, Risk Event alerts in Slack carry their own **Promote to RCA** and **Dismiss** buttons, so you can act without opening Kosmos. Promoting from Slack works the same as promoting in the app: if the RCA hasn't been generated yet, Kosmos generates it first and replies in the thread once it's ready to confirm. Dismissing from Slack asks for a reason (False Positive, Insufficient Evidence, Not Actionable, or Other). This setting is off by default, and turning it on switches Risk Event Slack alerts to one message per event rather than batched. *** #### Risk Event Detail Clicking a Risk Event opens the detail view, which uses a two-column grid layout: the main content area on the left, and a side rail with metadata and related signals on the right. **AI-generated summary:** Below the title, Kosmos displays a plain-language paragraph summarizing the correlation — signal count, deployment count, and the time window they occurred in. This is machine-generated and marked with a sparkles icon (✨). **Inline signals and deployments:** The side rail shows the specific signals and deployment cards linked to this Risk Event, so you can see the raw evidence without leaving the page. **Timeline:** A visual event timeline shows the sequence of signals and deployments in chronological order, helping you reconstruct what happened and when. **Sticky action bar:** A persistent bar at the bottom of the page keeps the primary actions (Acknowledge, Promote to RCA, Dismiss) accessible as you scroll through the evidence. **Version history:** When new evidence arrives, Kosmos rebuilds the affected cluster and replaces the existing Risk Event with an updated one. The current Risk Event shows a **Version History** panel listing the events it superseded, and each entry links to that earlier version. An event that has been replaced shows the same relationship from the other side, with a link forward to the version that replaced it. You can trace this in both directions and through more than one replacement, which is useful when you want to see how the engine's understanding of an incident changed as evidence accumulated. Only events whose replacement Kosmos actually recorded show a replacement link; an event that expired for another reason will not. **Explainability view:** Click **Explain correlation** from the detail page to open a side-by-side evidence view at `/risk-events/[id]/explain`. This shows the signal on the left, the deployment on the right, and a center column called "What was found" that lists the specific factors the engine matched on — shared issue keys, time proximity, token overlap, and more. Keywords that appear on both sides are highlighted so you can see exactly what the engine matched. Use this when you need to decide whether to trust a correlation before promoting it. *** #### RCA Report View Each RCA Report includes: **1. Executive Summary** A 2-3 sentence overview suitable for sharing with leadership. **2. Correlated Evidence** Kosmos links related data across your systems: * Jira issues that match the incident pattern * GitHub commits/PRs deployed near the incident time * Salesforce cases from affected customers **3. Root Cause Analysis** AI-generated analysis identifying likely causes, including: * What changed before the incident * Which systems or services were affected * Contributing factors (deployment timing, code changes, config updates) **4. Recommendations** Actionable next steps to prevent recurrence. #### RCA Actions Every action available on an RCA Report is collected in a single actions menu, replacing the row of buttons that previously ran across the top of the report. From the menu you can: * **Export PDF** — Download a formatted report for sharing outside Kosmos * **Export Markdown** — Download the RCA as a Markdown file for use in wikis, GitHub, or Notion * **Export Word** — Download a `.docx` version for stakeholder distribution * **Share** — Copy a link to share with team members * **Print** — Print directly from your browser * **Create Jira Ticket** — Create a follow-up ticket in Jira with the RCA details pre-filled **The menu reflects your connected integrations.** Actions that depend on an integration appear only when that integration is connected and configured for your organization. If your team has not connected Jira, for example, you will not see the option to create a Jira ticket. This keeps the menu limited to actions you can actually complete, so nothing in it leads to a dead end. When you create a Jira ticket from an RCA, the project dropdown lists only the projects you selected during Jira integration setup. Projects that exist in your Jira instance but were not selected for the integration do not appear, so a follow-up ticket cannot be filed into a project Kosmos was never connected to. To change which projects are available, update your selection in Settings → Integrations → Jira. *** ### Providing Feedback Your feedback helps Kosmos learn and improve. You can provide feedback at two levels: **Correlation Feedback** When viewing a correlation, you'll see "Is this correlation accurate?" with three options: * **Correct** — The correlation is valid * **Partial** — Some elements are correct, others aren't * **Wrong** — This correlation isn't meaningful **RCA Feedback** After reviewing an RCA, you can rate: * Was the root cause accurate? * Were the recommendations helpful? * If inaccurate, what was the actual root cause? This feedback feeds into Kosmos's calibration engine. Over time, the system learns your environment's patterns and produces more accurate results. *** ### The Correlation Engine Kosmos's key differentiator is **correlation** - connecting three types of signals that don't speak the same language: * **Customer cases** - Salesforce cases, Zendesk tickets describing symptoms * **Code changes** - Jira tickets, GitHub commits, PRs, deployments * **Service incidents** - Logs, traces, metrics from your infrastructure (Preview) **Example:** > A customer reports an issue in Salesforce. Kosmos correlates this case with a Jira bug logged the same day and a GitHub deployment 2 hours prior. The RCA shows the deployment introduced a regression affecting that customer's use case. This cross-system visibility is what enables prevention, not just faster response. *** ### How a Correlation Becomes a Risk Event Kosmos clusters related signals and deployments on every correlation pass. Promoting one of those clusters to a Risk Event is a separate, deliberate decision, and it is fully deterministic. The same cluster state always produces the same outcome, and no AI judgment is involved in the decision. Four conditions must all be met: **1. Evidence that something actually went wrong.** The cluster needs at least one signal that constitutes real-world impact. There are two kinds: * **A customer case** from Salesforce, Zendesk, ServiceNow, Pylon, or another connected support system. Someone outside your team reported a symptom. * **A production error or anomaly** from your OpenTelemetry data. Your own infrastructure recorded a failure. Either one is sufficient on its own. In both cases the point is the same: something reached the outside world, or your systems recorded a genuine failure, rather than someone having filed a ticket about work in progress. {% hint style="info" %} **If your organization has not enabled OpenTelemetry**, customer cases are currently the only signals that can meet this condition, since OTel is still in Preview. Correlations built purely from tickets, code changes, and deployments will stay in the Correlation Library until a case joins them. Contact your account team if you want OTel enabled. {% endhint %} Two examples of how this plays out: > **Anchored by a customer case.** A Salesforce case arrives reporting that appointment scheduling is failing. Kosmos has already clustered a Jira ticket and a production deployment from the previous evening against the same service. The case supplies the impact evidence, the deployment supplies production attribution, and the cluster becomes a Risk Event with all three attached. > **Anchored by a production error.** No customer has reported anything, but your OTel data shows an error spike in a payments service in production, and a deployment landed twenty minutes earlier. That is enough on its own. The Risk Event appears before the first support ticket does. A Jira, Linear, or Azure DevOps issue does not satisfy this condition on its own, whatever its type. A ticket tells you someone filed something; it does not tell you a customer was affected, or when, or whether the work was ever released. A bug filed internally, a triage placeholder, and a defect logged weeks after the fact all look alike to an integration. Issues from these systems still participate fully in clustering and still carry the narrative that explains a root cause. They just cannot, by themselves, be the reason an alert reaches your team. **2. Production attribution.** At least one member of the cluster has to be attributed to production. A correlation among staging deployments and dev-environment errors stays in the library. For source control, this is what your production branch mapping determines, which is why confirming it during setup matters. **3. Cross-system evidence.** The correlation has to span more than one system. An observability signal only counts toward this if it represents an error or an anomaly; a healthy trace sitting in a cluster is not a second source of evidence. **4. Correlation strength.** The cluster's correlation score has to meet the threshold configured for your organization. The conditions are evaluated in order and the first one that fails is the one reported back to you, so the reason a cluster stayed in the library is always a specific, answerable thing rather than a general "it didn't qualify." #### Clusters can qualify later Every in-window cluster is re-evaluated on every correlation pass. A cluster that sat in the library because nothing showed customer impact becomes a Risk Event automatically as soon as a customer case joins it, with no manual action and no need to go looking for it. This is common in practice. A deployment ships, an internal ticket is filed, and nothing correlates strongly enough to warrant an alert. Two days later a customer reports the symptom, the case lands in the cluster, and the Risk Event appears with the deployment and the ticket already attached as evidence. #### Once promoted, a cluster stays promoted Promoting a Risk Event to an RCA settles the underlying cluster. Kosmos will not generate a fresh Risk Event for the same signals and deployments on a later pass, so a case you have already worked does not come back to your inbox as a new item. *** ### The Correlation Library The **Correlation Library** is a research-oriented view of every cluster the correlation engine has surfaced across your signals and deployments. It is not an action queue — it exists for investigation and context. If you're looking for something to act on, start with Risk Events instead. The library is organized with a filter bar at the top: time window tabs (Last 7 days, Last 30 days, Last 90 days, All time), a system filter, and a score threshold filter. Each row shows the correlation score prominently, along with the title, time range, signal and deployment counts, and which systems are involved. Correlations are divided into **strong** (≥ 50% confidence) and **weak** (< 50% confidence) by a visual separator. Weak correlations are shown in a muted style with a note that no action is recommended. The engine recalculates these clusters automatically as new signals arrive — you don't manage them directly. #### Why a correlation wasn't promoted Every cluster in the library carries a badge explaining which promotion criterion it failed. This is the answer to "why didn't this show up in my inbox?", available without asking anyone: | Badge | What it means | | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **No risk anchor detected** | Nothing in the cluster shows real customer or production impact: no customer case, and no production error from your OTel data. Usually a cluster built only from tickets, code changes, and deployments. | | **Not attributed to production** | Impact evidence exists, but nothing in the cluster reached production. Check your production branch mapping if you expected otherwise. | | **Single source — needs cross-system evidence** | Everything in the cluster came from one system, so there's nothing to correlate against. | | **Correlation strength below threshold** | All other criteria passed, but the correlation is too weak to be confident about. | Use the filter chips to narrow the library to a single reason. Filtering by **No risk anchor detected** is a fast way to see what your team is shipping and tracking that hasn't produced customer impact. Filtering by **Not attributed to production** is usually how a misconfigured production branch mapping surfaces. Clusters that were promoted are marked as such, so you can see what became a Risk Event and what didn't in the same view. #### Deployment Timeline When viewing a Risk Event or RCA, you'll see a visual timeline showing deployments that occurred within ±8 hours of the incident. This helps you quickly identify which releases may have contributed to the issue. The timeline shows: * Your incident at the center * Deployments before and after, with version labels * Time delta between each deployment and the incident * Confidence indicators: High (green), Medium (yellow), Low (gray) Click any deployment marker to see details including version name, release time, change type, and related issues. Use the sort control in the timeline header to switch between newest-first (the default) and oldest-first ordering—useful when you're tracing back to a root cause versus triaging what just happened. You can also switch the timeline to a vertical layout. This can make dense timelines with many closely-spaced events easier to scan. #### Correlation Scores Each correlation displays a percentage score. Click the **ℹ️** icon next to any score to see how it was calculated. Kosmos weights multiple factors: * **Time proximity** — How close the events occurred * **System/entity match** — Same service or component affected * **Issue keys** — Matching ticket references (e.g., KOS-123) * **Text similarity** — Similar descriptions or error messages * **Component overlap** — Shared file paths or services * **Author/assignee match** — Same person involved * **PR number match** — Linked pull requests * **Error pattern family** — Similar error types Higher scores mean more factors aligned. A 25% score typically indicates a single weak match (like text similarity alone), while 70%+ means multiple strong signals converged. #### Evidence Breakdown Each correlation shows *why* Kosmos thinks two events are related. Hover or click on any correlation to see the evidence breakdown: * Which signals contributed to the match * The reasoning behind the correlation * Confidence level for each factor For a deeper view, use the **Explainability** page (see Risk Event Detail above), which shows the full side-by-side evidence for a specific Risk Event. This transparency helps you trust and explain the analysis to stakeholders. *** ### What "Preventative Intelligence" Means Kosmos reduces MTTR **and** prevents incidents from recurring: 1. **Reducing investigation time** - Structured root cause in under 60 seconds, not 2-4 hours 2. **Correlating deployments** with downstream customer cases and incidents 3. **Building organizational memory** - Every confirmed RCA is searchable, so the next on-call doesn't start from zero The goal: fewer incidents, not just faster fixes. *** ### Questions About Your Results? Your Kosmos team will walk you through your initial Historical Baseline findings. If you have questions between scheduled calls, reach out to your dedicated contact or email . # Integration Permissions How Kosmos connects to your systems securely *** Kosmos uses read-only API connections to analyze your data. We never install code in your environment or modify your systems. ### Our Security Approach **Zero-Install Architecture** Kosmos operates entirely outside your infrastructure. We connect through each vendor's standard authorization mechanism: OAuth for most systems, a marketplace app where the vendor requires one (a managed package for Salesforce, a GitHub App for GitHub). Nothing runs inside your environment. **Read-Only Access** We request only the minimum permissions needed to analyze your data. Kosmos cannot create, update, or delete records in your systems. **No Code Deployment** No Kosmos code executes in your Salesforce org, Jira instance, or GitHub repositories. This means: * No security reviews of deployed packages * No impact on your system performance * No maintenance burden on your team *** ### Permissions by Integration #### Salesforce Service Cloud **Setup Required:** Salesforce requires installing our managed package before connecting. See [Connecting Salesforce](/product-documentation/connecting-salesforce) for step-by-step instructions. | Permission | Why We Need It | | ------------------ | ---------------------------------------------------- | | Read Cases | Analyze incident and support ticket patterns | | Read Case Comments | Understand resolution context | | Read Case History | Reconstruct incident timelines | | Read Incidents | ITSM correlation (if Service Cloud Incident enabled) | | Read Users | Attribute incidents to teams | **What we DON'T access:** Opportunities, financial data, custom objects (unless mapped), attachments, or files. **Case fields shown on signals:** Kosmos surfaces each case's **Type**, **Origin**, and **Owner** directly on the signal, using the same Read Cases and Read Users access above. If your organization maps a custom Product field, that appears too. **Salesforce Error Monitoring:** An optional collector that watches your Salesforce org's own audit trail, Data Cloud, event log files, Apex exceptions, and governor limits for errors, so Kosmos can correlate Salesforce-side failures alongside your other signals. Tenant owners and managers can turn it on from the Salesforce integration settings, choose which of the five sources to collect, and set a collection interval from 30 minutes to 7 days. Each source's status (succeeded, partial, failed, or off) reflects its last collection cycle. Available on the same plan as OpenTelemetry ingestion. *** #### Jira | Permission | Why We Need It | | ----------------------- | ----------------------------------------- | | Read Issues | Analyze bugs, incidents, and tasks | | Read Projects | Understand team structure | | Read Comments | Context for root cause analysis | | Write Issues (optional) | Create follow-up tickets from RCA Reports | **What we DON'T access:** Confluence pages, admin settings, user passwords, or billing information. **Note:** Write access is only used when you explicitly click "Create Jira Ticket" from an RCA. Kosmos never creates tickets automatically. *** #### GitHub **Setup Guide:** See [Connecting GitHub](/product-documentation/connecting-github) for step-by-step instructions. Kosmos connects through the **Kosmos GitHub App**, which your organization installs on the repositories you choose. Every permission below is read-only. The app requests no write permission on any resource, so Kosmos cannot modify anything in your repositories even in principle. | Permission | Level | Why We Need It | | ------------- | ----- | ------------------------------------------------------------------------------------------------ | | Metadata | Read | Repository and branch metadata; detects your default branch to prefill production branch mapping | | Contents | Read | Commits and releases, to correlate deployments with incidents | | Pull requests | Read | Identify changes linked to issues | | Issues | Read | Issues, comments, and labels as incident signals | | Deployments | Read | Deployment events and their environment, for production attribution | | Projects | Read | Only requested if project sync is enabled for your organization | **What we DON'T access:** We have no write permission on anything. We do not read secrets, Actions logs, or organization admin settings, and we do not manage webhooks or deploy keys. **Repository scope:** At install time your admin chooses **All repositories** or **Only select repositories**. Kosmos can only see what the installation includes. The repository picker inside Kosmos lists exactly those repositories, so what you see in Kosmos matches the access you actually granted. You can change the selection in GitHub at any time without reconnecting. **Authentication:** The Kosmos GitHub App authenticates with short-lived installation tokens that Kosmos mints and refreshes automatically. There is no long-lived token sitting in our database waiting to be revoked. If the installation is uninstalled or suspended, the integration moves to a needs-re-authentication state and syncing stops. **Upgrading an existing connection:** Organizations that connected GitHub before the app was introduced continue to work during a transition period and see an upgrade prompt on the GitHub card in Kosmos. Upgrading is what narrows access to specific repositories, since the previous model could not do that. Your previous authorization is revoked automatically once the installation succeeds, and your historical signals, correlations, and sync configuration carry over. **Production branches:** During setup, after you select repositories, Kosmos asks you to confirm which branches represent production for each repo. The detected default branch (usually `main`) is prefilled, and you can adjust it if your team ships from a differently named branch such as `develop`. This mapping tells Kosmos which deployments reached production. Kosmos uses the strongest signal available for each deployment event: an explicit environment from the GitHub Deployments API if present, otherwise your branch mapping. Getting the mapping right means Risk Events reflect changes that actually reached your customers rather than treating every merge as a production deploy. You can revisit the mapping later from Settings → Integrations → GitHub. *** #### Bitbucket | Permission | Why We Need It | | ---------------------------- | --------------------------------------------------------------- | | Read Commits | Correlate deployments with incidents | | Read Pull Requests | Identify changes linked to issues | | Read Repositories (metadata) | Understand codebase structure | | Read Branches (metadata) | Detect your default branch to prefill production branch mapping | **What we DON'T access:** Source code contents, pipeline secrets, or admin settings. **Production branches:** Bitbucket setup includes the same production branch confirmation step described under GitHub above. For Bitbucket, Kosmos will also use a pipeline deployment step name when one is present, before falling back to your branch mapping. *** #### GitLab **Setup Guide:** See [Connecting GitLab](/product-documentation/connecting-gitlab) for step-by-step instructions. Both GitLab.com and self-managed instances are supported. | Permission | Why We Need It | | ------------------------ | ------------------------------------------- | | Read Issues | Analyze issues as incident signals | | Read Merge Requests | Identify changes linked to issues | | Read Commits | Correlate deployments with incidents | | Read Pipelines | Correlate pipeline runs with incidents | | Read Deployments | Attribute deployment events to environments | | Read Projects (metadata) | Scope sync to selected projects | **Authentication:** GitLab uses OAuth 2.0. You'll be redirected to your GitLab instance to authorize the connection. Access tokens expire every two hours and Kosmos refreshes them in the background. **What we DON'T access:** Source code contents, CI/CD variables and secrets, container registries, admin settings, or billing information. **Note:** You can restrict sync to specific projects and choose which data types to sync from Settings → Integrations → GitLab after connecting. *** #### ServiceNow | Permission | Why We Need It | | -------------------- | -------------------------------- | | Read Incidents | Analyze ITSM incident patterns | | Read Change Requests | Correlate changes with incidents | **What we DON'T access:** CMDB data, knowledge articles, admin settings, or user credentials. **Field Mapping:** After connecting, you can map your custom ServiceNow fields to Kosmos. This ensures RCAs include context from your organization's specific incident data. **Sandbox Support:** You can connect a sandbox instance (dev/test/uat) for evaluation before granting production access. *** #### Zendesk | Permission | Why We Need It | | ------------------ | ------------------------------------------- | | Read Tickets | Analyze support ticket patterns | | Read Custom Fields | Include your organization's ticket metadata | **What we DON'T access:** User passwords, billing information, admin settings, or Guide/Help Center content. *** #### Pylon | Permission | Why We Need It | | ------------------------ | ------------------------------------------------ | | Read Issues | Analyze support issues and tasks | | Read Messages (optional) | Include conversation context for deeper analysis | **Authentication:** Pylon uses API key authentication. You provide your Pylon API key when connecting. **What we DON'T access:** Internal notes marked private, billing data, or admin settings. *** #### Linear | Permission | Why We Need It | | ------------------------ | ------------------------------------------------------- | | Read Issues | Analyze bugs and tasks as incident signals | | Read Issue State | Understand resolution status and workflow stage | | Read Issue Labels | Classify issues by type and priority | | Read Teams | Scope sync to selected teams; understand team structure | | Read Assignees | Attribute issues to team members | | Read Relations | Link related issues for cross-reference correlation | | Read Attachments | Extract linked Jira and GitHub issue keys | | Read Comments (optional) | Include conversation context for deeper analysis | **Authentication:** Linear uses OAuth 2.0. You'll be redirected to Linear to authorize the connection. **What we DON'T access:** Cycles, roadmaps, projects, documents, admin settings, or billing information. **Note:** You can restrict sync to specific teams from Settings → Integrations → Linear after connecting. *** #### Azure DevOps | Permission | Why We Need It | | ---------------------------------- | ---------------------------------------------------------- | | Read Work Items | Analyze bugs, issues, and tasks as incident signals | | Read Work Item Types | Understand item classification across process templates | | Read Work Item Comments (optional) | Include conversation context for deeper analysis | | Read Projects | Scope sync to selected projects; understand team structure | | Read Teams | Attribute work items to teams | **Authentication:** Azure DevOps uses OAuth 2.0 via Microsoft Entra. You'll be redirected to Microsoft to authorize the connection. **What we DON'T access:** Source code, repositories, pipelines, test plans, wiki pages, admin settings, or billing information. **Note:** You can restrict sync to specific projects and work item types from Settings → Integrations → Azure DevOps after connecting. *** #### OpenTelemetry (Preview) **Setup Guide:** See [Connecting OpenTelemetry](/product-documentation/connecting-opentelemetry-preview) for step-by-step configuration instructions. Kosmos can ingest OpenTelemetry data to correlate observability signals (traces, logs, metrics) with your incidents and deployments. | Data Type | Why We Need It | | --------- | --------------------------------------- | | Traces | Correlate service errors with incidents | | Logs | Identify error patterns and anomalies | | Metrics | Detect performance degradation | **Authentication:** API key authentication. Generate a unique API key from Settings → Integrations → OpenTelemetry. **Setup:** Configure your OpenTelemetry Collector to export to the Kosmos OTLP endpoint. Example configs provided for Grafana Agent, Datadog Agent, and generic OTLP exporters. **Preview Status:** This integration is in Preview. Core functionality is stable, but we're actively refining the experience based on customer feedback. *** #### Slack / Microsoft Teams (Notifications) | Permission | Why We Need It | | ------------- | --------------------------------------------------------- | | Post Messages | Send Risk Event and RCA alerts to your configured channel | **What we DON'T access:** Message history, user data, private channels, or any channel other than the one you configure. **Note:** Notification integrations are optional. You can use Kosmos without connecting Slack or Teams. Integration health alerts (disconnect and reconnect notifications) are currently sent via Slack only; Teams support for these alerts is not yet available. *** ### Data Handling * **Encryption:** All data encrypted in transit (TLS 1.3) and at rest (AES-256) * **Retention:** Data retained only while your account is active * **Location:** Hosted on Google Cloud Platform (US regions) * **Compliance:** SOC 2 Type 1 report available on request; SOC 2 Type 2 in progress; DPA available upon request ### Revoking Access You can disconnect any integration at any time from Settings → Integrations. Revoking access immediately stops data sync. To request data deletion, contact . ### Questions? If your security team needs additional documentation, we're happy to provide: * Security questionnaire responses * Data Processing Agreement (DPA) * Architecture diagrams Contact your Kosmos team or email . *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai) © 2026 Kosmos AI Labs, Inc. # Integration Limits System limits and rate constraints by integration *** Kosmos applies sensible limits to ensure reliable performance across all connected systems. This page documents current limits by integration. ### Why Limits Exist During the 90-day Historical Baseline and ongoing sync, Kosmos ingests data from multiple systems. Limits prevent: * Exceeding provider API rate limits * System overload with very large repositories or orgs * Slow sync times that delay your results Most customers never hit these limits. If you do, they're configurable—talk to your Kosmos team. *** ### GitHub | Limit | Default | Notes | | ---------------------- | ------------ | ----------------------------------- | | Repositories displayed | 50 | In configuration screen; adjustable | | Max items per sync | 10,000 | Across all repos | | Items per repository | 500 | Per sync cycle | | Commits per repo | 500 | Most recent | | Pull requests per repo | 200 | Most recent | | API rate limit | \~5,000/hour | GitHub's standard limit | **What this means:** For most teams, Kosmos captures your full deployment history. Very large monorepos or orgs with 100+ active repos may need limit adjustments. *** ### Bitbucket | Limit | Default | Notes | | ---------------------- | ------- | ------------------------------- | | Repositories displayed | 200+ | Paginated; all repos accessible | | Commits per repo | 500 | Most recent | | Pull requests per repo | 200 | Most recent | **What this means:** Kosmos paginates through all repositories in your workspace. Very large workspaces with 200+ repos are fully supported. *** ### Jira | Limit | Default | Notes | | --------------------- | ------- | ----------------------- | | Max results per query | 5,000 | Jira API constraint | | Page size | 100 | Per API request | | Max projects | 100 | In configuration screen | **What this means:** Covers the vast majority of Jira instances. If you have 5,000+ issues in a 90-day window, we'll capture the most recent. *** ### Salesforce | Limit | Default | Notes | | -------------------- | ------- | ---------------- | | Max records per sync | 5,000 | Cases, incidents | | Batch size | 200 | Per API request | **What this means:** Sufficient for most Service Cloud implementations. High-volume support orgs (10K+ cases/quarter) may need adjustments. *** ### ServiceNow | Limit | Default | Notes | | -------------------- | ------- | -------------------------- | | Max records per sync | 5,000 | Incidents, change requests | | Page size | 100 | Per API request | **What this means:** Covers most ITSM implementations. High-volume environments may need adjustments. *** ### Zendesk | Limit | Default | Notes | | -------------------- | ------- | --------------- | | Max tickets per sync | 5,000 | Support tickets | | Page size | 100 | Per API request | **What this means:** Sufficient for most support organizations. *** ### Pylon | Limit | Default | Notes | | ------------------- | ------- | ---------------------------- | | Max issues per sync | 5,000 | Support issues and tasks | | Message enrichment | Opt-in | Configurable per integration | **What this means:** Covers most Pylon implementations. Message enrichment can be enabled for deeper context. *** ### Linear | Limit | Default | Notes | | ------------------- | ------- | --------------------------------------- | | Max issues per sync | 5,000 | Most recent, across all selected teams | | Page size | 50 | Per GraphQL request | | Comments per issue | 20 | Most recent (when comment sync enabled) | **What this means:** Covers the vast majority of Linear workspaces. Very high-volume teams with 5,000+ updated issues in a sync window may need limit adjustments. *** ### Azure DevOps | Limit | Default | Notes | | ----------------------- | ------- | ----------------------------------------- | | Max work items per sync | 5,000 | Most recent, across all selected projects | | Batch size | 200 | Per API request | | Max projects displayed | 100 | In configuration screen | | Comments per issue | 20 | Most recent (when comment sync enabled) | **What this means:** Covers most Azure DevOps organizations. Very large organizations or projects with high change velocity may need limit adjustments. *** ### OpenTelemetry (Preview) | Limit | Default | Notes | | ------------------- | ------------- | ------------------------- | | Data retention | 7 days | Raw traces, logs, metrics | | Correlation cadence | 15 minutes | Batch processing interval | | Request rate | 1,000 req/min | Per customer | | Payload size | 5 MB | Per request | **What this means:** OTel data is processed in 15-minute batches for correlation. Raw data is retained for 7 days; correlation metadata is retained with your other signals. *** ### Adjusting Limits All limits are configurable. If you're hitting a limit that affects your results, contact your Kosmos team. Common adjustments: * Increasing repository count for large GitHub orgs * Extending record limits for high-volume Salesforce orgs * Adjusting sync frequency for real-time needs *** ### FAQ **Q: Will I lose data if I hit a limit?** No. Kosmos captures the most recent data up to the limit. Older records outside the limit aren't deleted—they're just not synced. **Q: How do I know if I'm hitting a limit?** Your Kosmos team monitors sync health and will proactively reach out if limits are affecting your results. **Q: Can limits be increased?** Yes. Limits are configurable per customer. Higher limits may increase sync time but won't affect platform stability. **Q: Do limits affect real-time monitoring?** No. Limits primarily apply to the initial Historical Baseline. Ongoing monitoring processes new data as it arrives. **Q: How long does the Historical Baseline take?** Typically under 10 minutes for 90 days of data. Very large datasets may take longer; your Kosmos team will keep you informed. **Q: What about rate limits from the providers (GitHub, Jira, Salesforce)?** Kosmos respects provider rate limits automatically. We batch requests and throttle as needed to avoid hitting provider limits. *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # Managing API Keys and Webhooks Create and manage public API keys and webhook endpoints *** Kosmos gives you programmatic access to your account through the public API, and push notifications through webhooks. Both are managed in the app, so you can set them up without involving the Kosmos team. API keys and webhook endpoints live in **Settings → Developer**, separate from **Settings → Integrations**. Integrations are the systems Kosmos reads from to build correlations. Developer settings are how your own systems talk to Kosmos. *** ### API Keys #### Creating a key 1. Go to **Settings → Developer** 2. Click **Create API Key** 3. Give the key a name that identifies what will use it 4. Choose an expiration: **30, 60, 90, or 180 days**. 90 days is the default. 5. Click **Create** **The plaintext key is shown exactly once.** Copy it and store it in your secret manager before closing the dialog. Kosmos stores only a hash, so there is no way to retrieve the value again. If you lose it, rotate the key and store the replacement. There is no scope selector when creating a key. Every key is granted the full set of available scopes: | Scope | Grants | | ------------------------ | ---------------------------------------------- | | `whoami:read` | Read-only access to your organization identity | | `knowledge_objects:read` | Read-only access to Knowledge Objects | The identity endpoint reports the scopes a given key resolves to; see the API reference below for its exact path. A tenant can hold **20 active keys** at a time. Creating a twenty-first is rejected until you revoke one. Key creation and revocation are themselves rate-limited per tenant. #### Reviewing your keys The key list shows each key you own with: * **Status** — Active, Expired, or Revoked * **Last used** — when the key last authenticated a request, or an indication that it has not been used yet * **Rotation lineage** — if a key was created by rotating an older one, or has since been rotated into a newer one, the related key is named directly so you do not have to infer history from timestamps Plaintext values never appear in this list. #### Rotating and revoking * **Rotate** — issues a replacement key and revokes the old one. The new plaintext value is shown exactly once, same as creation. The old record is kept and linked to its replacement. * **Revoke** — invalidates the key with no replacement. Both actions are permanent and cannot be undone. A revoked key stops authenticating within seconds; propagation is near-instant but bounded by a short credential cache interval, so allow a moment before testing that a revoked key is actually dead. Anything still using the old key will start receiving authentication errors, so update your systems before rotating a key in active use. Rotate and revoke are unavailable for keys that are already Revoked or Expired. Those states are terminal. #### Expiration Keys are deactivated automatically once they pass their expiration date. The check runs every few minutes, so a key expires promptly rather than at an exact timestamp. Once deactivated, requests using it return `401`. Kosmos warns you before a key expires: at 14, 3, 1, and 0 days out. The warning is sent to your connected Slack channel; if Slack isn't connected, or the Slack message can't be delivered, Kosmos emails the key's owner instead. Plan rotation ahead of the expiration date. Nothing in Kosmos extends the life of an existing key. #### Admin management Tenant admins see and manage every API key in the tenant, not just their own. Admins can rotate or revoke any key using the same flows. Every API key action, creation, rotation, and revocation, produces an audit record capturing the actor, the key, your tenant, and a timestamp. When an admin acts on a key belonging to another user, the record captures both the acting admin and the key's owner. There is no delete action separate from revocation. Revoked keys are retained indefinitely to support audit and SOC 2 requirements. They are excluded from the default view and remain reachable through the **Revoked** filter. *** ### Authenticating Requests Public API keys are prefixed `kosmos_api_` and passed as a bearer token: ``` Authorization: Bearer kosmos_api_... ``` The public API is served from `api.kosmoslabs.ai`. An identity endpoint is available to confirm a key is working; it returns the tenant context and the scopes the key resolves to. See the API reference below for its path. Responses you should expect to handle: | Condition | Response | | ---------------------------------------------------- | -------- | | Missing, malformed, unknown, expired, or revoked key | `401` | | Per-key rate limit exceeded | `429` | Every authenticated request produces an audit record capturing the key identifier, tenant, endpoint, method, response status, timestamp, and client IP. #### Rate limit headers Rate limit state is returned on every response, not only on rejections, so you can back off before you are throttled: | Header | Meaning | | ----------------------- | ---------------------------------------- | | `X-RateLimit-Limit` | Requests permitted in the current window | | `X-RateLimit-Remaining` | Requests left in the current window | | `X-RateLimit-Reset` | When the window resets | The default limit is **60 requests per 60-second window**, roughly one request per second. Limits resolve in order: a per-key override if one is configured, then your tenant default, then this global default. If your workload needs more headroom, contact your Kosmos team about a per-key override. Read `X-RateLimit-Remaining` rather than assuming the default, since the limit applied to your key may differ from it. #### API reference The full OpenAPI 3.0 specification is published and requires no authentication to read. It is the source of truth for available endpoints, request and response shapes, and paths. Point your tooling or client generator at it. The spec contains only public endpoints; internal endpoints are excluded. Ask your Kosmos team for the spec URL if you cannot locate it. **A public API key is not an OpenTelemetry ingest key.** If you are configuring an OTel collector, you need the key generated under **Settings → Integrations → OpenTelemetry**, which is a separate credential with a different prefix and a different header. See [Connecting OpenTelemetry](/product-documentation/connecting-opentelemetry-preview). *** ### Webhooks Webhooks let Kosmos push events to your systems instead of you polling for them. #### Registering an endpoint 1. Go to **Settings → Developer** 2. In the webhooks section, click **Register Endpoint** 3. Enter the URL that should receive deliveries 4. Select the events you want delivered 5. Save A unique signing secret is generated and shown once when the endpoint is registered. Store it; you will need it to verify deliveries. #### Available events | Event | Fires when | | ---------------------- | ---------------------------------- | | `risk-event-created` | Kosmos surfaces a new Risk Event | | `risk-event-promoted` | A Risk Event is promoted to an RCA | | `risk-event-dismissed` | A Risk Event is dismissed | #### Verifying deliveries Every delivery carries an HMAC signature in the `X-Kosmos-Signature-256` header, so you can confirm a payload came from Kosmos and not a third party posting to your URL. The signature is an HMAC-SHA256 hex digest of the **raw request body**, computed with your signing secret, formatted as `sha256=`. To verify a delivery: 1. Take the raw request body exactly as received. Do not parse, re-serialize, or reformat it first; any change to the bytes changes the digest and the check will fail. 2. Compute `HMAC-SHA256(signing_secret, raw_body)` as a hex digest. 3. Prefix it with `sha256=` and compare it to the header value using a constant-time comparison. 4. Reject the delivery if the values do not match. ```python import hashlib import hmac def verify(raw_body: bytes, header_value: str, signing_secret: str) -> bool: digest = hmac.new( signing_secret.encode(), raw_body, hashlib.sha256 ).hexdigest() return hmac.compare_digest(f"sha256={digest}", header_value) ``` Use a constant-time comparison such as `hmac.compare_digest` rather than `==`, so the check does not leak information through timing. #### Delivery and retries Failed deliveries are retried with exponential backoff. Kosmos records the outcome of each attempt, including the target URL, response status, timestamp, and attempt count, so a delivery problem can be traced rather than guessed at. #### Testing an endpoint Send a test delivery to any endpoint you own to confirm it is reachable before relying on it for real events. The result reports whether the delivery succeeded, the HTTP status your endpoint returned, and the response time, so you can debug a failure without leaving Kosmos. #### Managing endpoints You see and manage the endpoints you registered. Deleting or disabling one stops all further deliveries to it. Tenant admins see and manage every endpoint in the tenant and can delete any of them. This matters when an endpoint goes stale or is compromised and the person who registered it is unavailable. Webhook subscriptions are scoped to your tenant and cannot be viewed or triggered from another tenant. #### Payload contents Payloads currently carry enough to identify the event type and the resource that triggered it. **Treat the payload shape as provisional.** It is being expanded, and the schema is expected to change before it is stable, so build against the event type and fetch the detail you need from the API rather than depending on payload fields. We will document the payload schema here once it is settled. If you are building against it now, your Kosmos team can walk you through the current shape and flag changes before they ship. *** ### Questions? Contact your Kosmos team or email . *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # Connecting OpenTelemetry (Preview) Step-by-step guide to connecting OpenTelemetry observability data *** This guide walks you through sending OpenTelemetry (OTel) data to Kosmos for correlation with your incidents and deployments. ### Overview Kosmos ingests traces, logs, and metrics via the OpenTelemetry Protocol (OTLP). Once connected, Kosmos correlates observability signals with your other data sources to surface root causes faster. **Preview Status:** This integration is in Preview. Core functionality is stable, but we're actively refining the experience based on customer feedback. *** ### Prerequisites * An OpenTelemetry Collector deployed in your environment * Network access from your collector to `https://ingest.kosmoslabs.ai` * Admin access to Kosmos to generate an API key *** ### Step 1: Generate Your API Key 1. In Kosmos, navigate to **Settings → Integrations** 2. Find the **OpenTelemetry** card and click **Configure** 3. Click **Generate API Key** 4. Copy both: * **OTLP Endpoint (Host):** `https://ingest.kosmoslabs.ai` * **Traces:** `https://ingest.kosmoslabs.ai/v1/traces` * **Metrics:** `https://ingest.kosmoslabs.ai/v1/metrics` * **Logs:** `https://ingest.kosmoslabs.ai/v1/logs` * **API Key:** Your unique key (starts with `kos_`) Keep your API key secure. You can regenerate it at any time, but doing so will invalidate the previous key. *** ### Step 2: Configure Your Collector Add Kosmos as an exporter in your OpenTelemetry Collector configuration. Select the config for your platform below. #### Generic OTLP Exporter Works with any OpenTelemetry Collector distribution. ```yaml exporters: otlphttp/kosmos: endpoint: https://ingest.kosmoslabs.ai headers: X-Kosmos-API-Key: "${KOSMOS_API_KEY}" service: pipelines: traces: exporters: [otlphttp/kosmos] logs: exporters: [otlphttp/kosmos] metrics: exporters: [otlphttp/kosmos] ``` *** #### Grafana Agent / Grafana Alloy ```yaml traces: configs: - name: kosmos remote_write: - endpoint: ingest.kosmoslabs.ai:443 headers: X-Kosmos-API-Key: ${KOSMOS_API_KEY} protocol: grpc tls: insecure: false logs: configs: - name: kosmos clients: - url: https://ingest.kosmoslabs.ai/v1/logs headers: X-Kosmos-API-Key: ${KOSMOS_API_KEY} ``` *** #### Datadog Agent Datadog Agent receives OTLP locally, then forward to Kosmos via a sidecar collector. In your `datadog.yaml`: ```yaml otlp_config: receiver: protocols: grpc: endpoint: 0.0.0.0:4317 ``` Then run a standalone OTel Collector with the generic config above to forward to Kosmos. *** #### Splunk OpenTelemetry Collector Add Kosmos as an additional exporter in your Splunk OTel config: ```yaml exporters: otlphttp/kosmos: endpoint: https://ingest.kosmoslabs.ai headers: X-Kosmos-API-Key: "${KOSMOS_API_KEY}" service: pipelines: traces: exporters: [sapm, otlphttp/kosmos] # Keep Splunk, add Kosmos logs: exporters: [splunk_hec, otlphttp/kosmos] metrics: exporters: [signalfx, otlphttp/kosmos] ``` *** #### Dynatrace Export from Dynatrace OneAgent via OpenTelemetry. Add to your OTel Collector config: ```yaml receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 exporters: otlphttp/kosmos: endpoint: https://ingest.kosmoslabs.ai headers: X-Kosmos-API-Key: "${KOSMOS_API_KEY}" service: pipelines: traces: receivers: [otlp] exporters: [otlphttp/kosmos] logs: receivers: [otlp] exporters: [otlphttp/kosmos] ``` Configure Dynatrace OneAgent to export OTLP to this collector's endpoint. *** #### AWS Distro for OpenTelemetry (ADOT) Add Kosmos exporter to your ADOT config (`otel-config.yaml`): ```yaml exporters: otlphttp/kosmos: endpoint: https://ingest.kosmoslabs.ai headers: X-Kosmos-API-Key: "${KOSMOS_API_KEY}" service: pipelines: traces: receivers: [otlp, awsxray] exporters: [awsxray, otlphttp/kosmos] # Keep X-Ray, add Kosmos metrics: receivers: [otlp] exporters: [awsemf, otlphttp/kosmos] # Keep CloudWatch, add Kosmos ``` For ECS/EKS, set the `KOSMOS_API_KEY` environment variable in your task definition. *** #### Google Cloud Ops Agent The Ops Agent doesn't natively support custom OTLP exports. Deploy a sidecar OTel Collector: 1. Install the OpenTelemetry Collector alongside Ops Agent 2. Configure Ops Agent to send OTLP to localhost:4317 3. Configure the OTel Collector with the generic config above Alternatively, use Cloud Run or GKE with the standard OTel Collector. *** #### Azure Monitor (Application Insights) Azure Monitor exports via the Azure Monitor OpenTelemetry Distro. Add a sidecar collector: ```yaml receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 exporters: otlphttp/kosmos: endpoint: https://ingest.kosmoslabs.ai headers: X-Kosmos-API-Key: "${KOSMOS_API_KEY}" service: pipelines: traces: receivers: [otlp] exporters: [otlphttp/kosmos] logs: receivers: [otlp] exporters: [otlphttp/kosmos] ``` Configure your application's OpenTelemetry SDK to export to both Azure and this collector. *** #### New Relic New Relic supports OTLP natively. Add Kosmos as a secondary destination via a collector: ```yaml exporters: otlphttp/newrelic: endpoint: https://otlp.nr-data.net headers: api-key: "${NEW_RELIC_LICENSE_KEY}" otlphttp/kosmos: endpoint: https://ingest.kosmoslabs.ai headers: X-Kosmos-API-Key: "${KOSMOS_API_KEY}" service: pipelines: traces: exporters: [otlphttp/newrelic, otlphttp/kosmos] logs: exporters: [otlphttp/newrelic, otlphttp/kosmos] ``` *** ### Step 3: Test the Connection 1. Deploy your updated collector configuration 2. Return to Kosmos **Settings → Integrations → OpenTelemetry** 3. Click **Test Connection** 4. Verify the status changes: * **Pending** → Waiting for first data * **Receiving** → Data arriving, processing * **Active** → Connection established and healthy The **Last Data Received** timestamp shows when Kosmos last ingested data from your collector. *** ### Step 4: Verify in the Observability Tab Once connected, navigate to **Observability** in the left sidebar. You'll see: * Connected OTel data sources * Recent traces, logs, and metrics * Correlation status with your other signals The Observability tab shows a **(Preview)** label indicating this feature is still being refined. *** ### What Kosmos Does With Your Data Kosmos processes OTel data in 15-minute batches to: 1. **Extract error signatures** from traces and logs 2. **Correlate with incidents** in Jira, Salesforce, ServiceNow, etc. 3. **Link to deployments** from GitHub/Bitbucket 4. **Surface in RCAs** as supporting evidence Raw OTel data is retained for 7 days. Correlation metadata is retained with your other signals. *** ### Troubleshooting **Connection stays "Pending"** * Verify your collector can reach `https://ingest.kosmoslabs.ai` * Check that your API key is correctly set in the `X-Kosmos-API-Key` header * Confirm your collector is actually sending data (check collector logs) **"Unauthorized" errors** * Regenerate your API key in Kosmos * Ensure the header format is `X-Kosmos-API-Key: kos_xxxxx` **"Rate limited" errors** * Default limit is 1,000 requests/minute per customer * Consider batching more data per request (up to 5MB per payload) * Contact your Kosmos team if you need higher limits **Data not appearing in correlations** * OTel data is processed in 15-minute batches * Check the Observability tab to confirm data is arriving * Correlations appear when OTel signals match incidents in your connected systems *** ### Revoking Access To stop sending data to Kosmos: 1. Remove the Kosmos exporter from your collector configuration 2. In Kosmos, go to **Settings → Integrations → OpenTelemetry** 3. Click **Revoke API Key** Revoking the API key immediately rejects any further data from that key. *** ### Data Access For details on what Kosmos ingests and retains, see [Integration Permissions](/product-documentation/integration-permissions) and [Integration Limits](/product-documentation/integration-limits). *** ### Questions? Contact your Kosmos team or email . *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # Connecting GitHub Step-by-step guide to connecting GitHub *** This guide walks you through connecting GitHub to Kosmos. Kosmos connects to GitHub through the **Kosmos GitHub App**. You install the app on your organization and choose exactly which repositories it can see. The app requests read-only permissions and cannot write to your repositories. ### Prerequisites * Permission to install a GitHub App on your organization. In most organizations this is an owner or an admin. If you are not an admin, you can still start the install and GitHub will send it to an owner for approval. * Admin access to Kosmos to configure the integration *** ### Step 1: Start the Connection 1. In Kosmos, navigate to **Settings → Integrations** 2. Find the **GitHub** card and click **Connect** 3. You are redirected to GitHub to install the Kosmos app If you already have a GitHub connection from before Kosmos moved to the GitHub App, the card shows an upgrade prompt instead. See [Upgrading an existing GitHub connection](#upgrading-an-existing-github-connection) below. *** ### Step 2: Choose Your Repositories On the GitHub installation screen, select the account or organization you want to connect, then choose the repository scope: * **All repositories** gives Kosmos read access to every current and future repository in the organization * **Only select repositories** limits Kosmos to the repositories you pick Most teams choose **Only select repositories** and add the repositories that produce the deployments they care about correlating. Review the requested permissions, then click **Install**. All permissions are read-only. For the full list and what each one is used for, see [Integration Permissions](/product-documentation/integration-permissions#github). You can change the repository selection at any time in GitHub, under your organization's **Settings → GitHub Apps → Kosmos → Configure**. You do not need to reconnect in Kosmos after changing it. **If your installation needs approval:** when a non-admin starts the install, GitHub holds it pending an owner's approval. Kosmos shows the connection as pending until an owner approves it, then completes automatically. *** ### Step 3: Select Repositories to Sync Once the installation completes, you are returned to Kosmos and the repository picker appears. The picker lists only the repositories included in your installation, so what you see in Kosmos matches what the app can actually access. Select the repositories you want Kosmos to sync and click **Save**. If a repository you previously selected for sync is later removed from the installation in GitHub, Kosmos flags it in your sync configuration rather than failing quietly on the next sync. *** ### Step 4: Confirm Production Branches After repository selection, Kosmos asks you to confirm which branches represent production for each repository. * The detected default branch (usually `main`) is prefilled * Adjust it if your team ships from a differently named branch, such as `develop` * You can add more than one branch per repository This mapping tells Kosmos which deployments reached production, which in turn determines whether a correlation is eligible to become a Risk Event. See [How a correlation becomes a Risk Event](/product-documentation/understanding-results#how-a-correlation-becomes-a-risk-event) for why this matters. Kosmos uses the strongest signal available for each deployment event: an explicit environment from the GitHub Deployments API when present, and otherwise your branch mapping. You can revisit the mapping later from **Settings → Integrations → GitHub**. *** ### Step 5: Verify the Connection Once saved, Kosmos begins syncing commits, pull requests, issues, and deployment events from your selected repositories. Navigate to the **Signals** tab to confirm events are flowing in from your connected repositories. *** ### Upgrading an existing GitHub connection If your organization connected GitHub before Kosmos moved to the GitHub App, your existing connection keeps working during a transition period, and the GitHub card in Kosmos shows a prompt to upgrade. Upgrading is worth doing sooner rather than later. The older connection model could not limit access to specific repositories, so upgrading is what narrows Kosmos to the repositories you choose. To upgrade: 1. Go to **Settings → Integrations** and click the upgrade prompt on the **GitHub** card 2. Complete the installation steps above 3. Your previous authorization is revoked automatically once the installation succeeds Your historical GitHub signals, existing correlations, and sync configuration carry over. Repositories that remain in scope keep their production branch mapping. *** ### Revoking Access **From Kosmos:** Settings → Integrations → GitHub → Disconnect **From GitHub:** Your organization's **Settings → GitHub Apps → Kosmos → Uninstall**. Uninstalling the app immediately ends Kosmos's access to every repository in that installation. Because Kosmos authenticates as an installed app rather than holding a long-lived token, removing the installation is sufficient. There is no separate token left active afterward. *** ### Troubleshooting **Connection shows as pending** * An owner still needs to approve the installation. Check your organization's pending GitHub App requests. **A repository is missing from the picker** * The repository is not part of your installation. Add it in GitHub under **Settings → GitHub Apps → Kosmos → Configure**, then return to the Kosmos repository picker. **Integration shows "needs re-authentication"** * The installation was uninstalled or suspended in GitHub. Reinstall the app from the GitHub card in Kosmos. **Deployments are correlating but not treated as production** * Check your production branch mapping in **Settings → Integrations → GitHub**. If a deployment's merge target is not listed as a production branch and GitHub sends no explicit environment, Kosmos treats it as non-production. *** ### Data Access For details on what Kosmos reads from GitHub, see [Integration Permissions](/product-documentation/integration-permissions#github). All access is **read-only**. Kosmos never creates, updates, or deletes anything in your repositories. *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # Connecting GitLab Step-by-step guide to connecting GitLab *** This guide walks you through connecting GitLab to Kosmos. Kosmos supports both **GitLab.com** and **self-managed GitLab instances**. ### Prerequisites * A GitLab account with access to the projects you want to sync * Admin access to Kosmos to configure the integration *** ### Step 1: Start the Connection 1. In Kosmos, navigate to **Settings → Integrations** 2. Find the **GitLab** card and click **Connect** 3. A dialog appears asking for your GitLab instance URL *** ### Step 2: Enter Your Instance URL * **GitLab.com:** Leave the default `https://gitlab.com` as-is and click **Continue** * **Self-managed GitLab:** Replace the default with your instance URL (e.g., `https://gitlab.yourcompany.com`) and click **Continue** Kosmos validates the URL before proceeding. Private IP addresses and non-HTTPS URLs are not accepted. *** ### Step 3: Authorize via OAuth 1. You'll be redirected to your GitLab instance 2. Review the requested permissions and click **Authorize** 3. You'll be returned to Kosmos with the connection established GitLab OAuth tokens expire every 2 hours. Kosmos automatically refreshes them in the background — you won't need to reconnect. *** ### Step 4: Select Projects After connecting, Kosmos displays a project selector. * Choose the specific projects you want Kosmos to sync * Leave the selection empty to sync all projects you have access to Click **Save** when done. *** ### Step 5: Configure Sync Settings In the sync configuration modal, you can enable or disable each data type: | Data Type | What Kosmos syncs | | -------------- | ---------------------------------------------- | | Issues | GitLab issues, used as signals for correlation | | Merge Requests | Merge requests linked to deployments | | Commits | Commit history for deployment correlation | | Pipelines | Pipeline runs correlated with incidents | | Deployments | Deployment events tied to incidents | All types are enabled by default. Adjust as needed and click **Save Settings**. *** ### Step 6: Verify the Connection Once saved, Kosmos begins syncing data from your selected GitLab projects. Navigate to the **Signals** tab to confirm events are flowing in from your connected instance. *** ### Revoking Access **From Kosmos:** Settings → Integrations → GitLab → Disconnect **From GitLab:** User Settings → Applications → Revoke Kosmos access *** ### Data Access For details on what Kosmos reads from GitLab, see [Integration Permissions](/product-documentation/integration-permissions#gitlab). All access is **read-only**. Kosmos never creates, updates, or deletes any records in your GitLab instance. *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # Connecting Azure DevOps Step-by-step guide to connecting Azure DevOps *** This guide walks you through connecting Azure DevOps to Kosmos. Kosmos connects to Azure DevOps Boards to sync work items — bugs, tasks, stories, features, and other issue types — as signals for correlation. ### Prerequisites * An Azure DevOps account with access to the organization you want to sync * Admin access to Kosmos to configure the integration *** ### Step 1: Start the Connection 1. In Kosmos, navigate to **Settings → Integrations** 2. Find the **Azure DevOps** card and click **Connect** 3. A dialog appears asking for your Azure DevOps organization name *** ### Step 2: Enter Your Organization Name Enter your Azure DevOps organization name — this is the name that appears in your URL at `dev.azure.com/{organization}`. For example, if your Azure DevOps URL is `https://dev.azure.com/contoso`, enter `contoso`. Click **Continue** to proceed. *** ### Step 3: Authorize via Microsoft Entra ID 1. You'll be redirected to Microsoft to authorize the connection 2. Sign in with your Microsoft account if prompted 3. Review the requested permissions and click **Accept** 4. You'll be returned to Kosmos with the connection established Azure DevOps access tokens expire approximately every hour. Kosmos automatically refreshes them in the background — you won't need to reconnect. *** ### Step 4: Configure Sync Settings After connecting, you can configure which data Kosmos syncs: **Projects** Select the specific Azure DevOps projects you want Kosmos to analyze. Leave the selection empty to sync all projects in your organization. **Work Item Types** Choose which work item types to include (e.g., Bug, Task, Story, Feature, Epic). By default, all types are synced. **Additional options:** * **Sync Comments** — Include work item comments for deeper context in correlations * **Sync Links** — Include linked work items to surface related issues Click **Save Settings** when done. *** ### Step 5: Verify the Connection Once saved, Kosmos begins syncing work items from your Azure DevOps organization. Navigate to the **Signals** tab to confirm work items are flowing in from your connected organization. *** ### Revoking Access **From Kosmos:** Settings → Integrations → Azure DevOps → Disconnect **From Microsoft:** [My Apps](https://myapps.microsoft.com/) → Find the Kosmos app → Remove access, or via your Azure Entra ID admin portal *** ### Data Access For details on what Kosmos reads from Azure DevOps, see [Integration Permissions](/product-documentation/integration-permissions#azure-devops). All access is **read-only**. Kosmos never creates, updates, or deletes any records in your Azure DevOps organization. *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # Connecting Salesforce Step-by-step guide to connecting Salesforce Service Cloud *** This guide walks you through connecting Salesforce Service Cloud to Kosmos. ### Prerequisites * Salesforce org with Service Cloud enabled * Kosmos managed package installed in your Salesforce org * `Kosmos Salesforce Connector Access` permission set assigned to the connecting user *** ### Step 1: Install the Managed Package Install the Kosmos managed package in your Salesforce org before connecting. The package is listed on the [Salesforce AppExchange](https://appexchange.salesforce.com/appxListingDetail?listingId=a0NHu00000srMgrMAE) and can be installed directly using the links below: | Environment | Install Link | | -------------- | ---------------------------------------------------------------------------------------------------- | | **Production** | [Install Package](https://login.salesforce.com/packaging/installPackage.apexp?p0=04tg500000051GPAAY) | | **Sandbox** | [Install Package](https://test.salesforce.com/packaging/installPackage.apexp?p0=04tg500000051GPAAY) | During installation: 1. Select **Install for Admins Only** 2. After installation completes, navigate to **Setup → Permission Sets** 3. Assign the `Kosmos Salesforce Connector Access` permission set to the user who will authorize the connection *** ### Step 2: Connect Salesforce to Kosmos 1. In Kosmos, navigate to **Settings → Integrations** 2. If Salesforce Service Cloud shows as connected, click **Disconnect** first * When prompted, select **Disconnect** or **Disconnect and Delete Data** 3. Click **Connect Integration** on the Salesforce Service Cloud card 4. Select your environment: * **Production** — Your live Salesforce org * **Sandbox** — For testing before production * **Custom Domain** — If your org uses a custom Salesforce domain 5. Click **Continue to Salesforce** 6. Log in with your Salesforce credentials 7. Click **Allow** to grant Kosmos read-only access *** ### Step 3: Configure Field Mapping After connecting, Kosmos displays the field mapping screen. * **Default mapping** works for most standard configurations * To map a custom field: 1. Select the Salesforce field from the dropdown 2. Map it to the corresponding Kosmos field (e.g., map **Account ID** to **Account/Contact**) * Click **Save Mapping** when complete *** ### Step 4: Configure Sync Settings 1. Enable **Automatic Sync** 2. Set **Sync Frequency** to your preferred interval (recommended: **6 Hours**) 3. Select all **6 signal type checkboxes** 4. Select **All** in each of the two picklists 5. Click **Save Settings** *** ### Step 5: Verify the Connection Once saved, Kosmos begins syncing Case Signals from your Salesforce org. Navigate to the **Signals** tab to confirm Case Signals are flowing in from your connected org. *** ### Revoking Access **From Kosmos:** Settings → Integrations → Salesforce → Disconnect **From Salesforce:** Setup → Connected Apps OAuth Usage → Kosmos → Block or Revoke *** ### Data Access For details on what Kosmos reads from Salesforce (Cases, CaseComments, CaseHistory, Incidents), see [Integration Permissions](/product-documentation/integration-permissions#salesforce-service-cloud). All access is **read-only**. Kosmos never creates, updates, or deletes any records in your Salesforce org. *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # Privacy Policy How Kosmos collects, uses, and protects your data *Last updated: July 17, 2026 · Effective: July 2026* *** ### 1. Introduction Your privacy is important to us. This policy explains how we handle your data. This Privacy Policy describes how Kosmos AI Labs, Inc. ("Kosmos," "we," "us") collects, uses, and shares personal information when you use our website and Services. ### 2. Information We Collect #### Information You Provide * **Account information:** Name, email address, company name, job title, and professional credentials provided during registration. * **Payment information:** Processed securely by our payment processor; we do not store full payment card details. * **Communications:** When you contact us, request support, or participate in surveys or research. * **System & Telemetry Data:** As part of our INGEST and CORRELATE phases, we process read-only technical logs, API metadata, and system performance metrics you provide to the platform. This data is governed by our Data Processing Agreement and used solely to deliver the Services. #### Information Collected Automatically * **Usage data:** Features used, actions taken, time spent, and interactions with the platform. * **Device and technical information:** Browser type, operating system, IP address, and referral URLs. * **Cookies:** See the "Cookies" section below. ### 3. How We Use Your Information We use your information to: * Provide, maintain, and improve the Services, including executing the preventative intelligence lifecycle (INGEST, CORRELATE, SURFACE, ACT, and LEARN) * Enable API access so you can retrieve your data and integrate the Services with your own systems * Process transactions and send related confirmations * Send technical notices, security alerts, and support messages * Respond to your comments, questions, and requests * Monitor and analyze trends, usage, and performance of the Services * Detect, investigate, and prevent fraudulent, unauthorized, or illegal activity * Train and improve our AI models (in aggregated, anonymized form — see "AI and Model Training" below) * Comply with applicable legal obligations #### AI and Model Training Because the Kosmos platform uses AI and machine learning to deliver preventative intelligence, we adhere to the following principles: * **Purpose limitation:** Customer Data is used solely to deliver the Services to that Customer. * **Anonymization for model improvement:** Where we use operational data to train or improve our general AI models, such data is first aggregated and anonymized so that individual Customer patterns are not identifiable. * **Opt-out:** Customers who do not wish their data to be used for general model training may opt out by contacting us at . * **Automated decisions:** Our platform generates AI-driven Root Cause Analysis (RCA) findings, risk scores, and recommendations. These outputs are informational and are not substitutes for human judgment. We do not make legally or similarly significant decisions about individuals solely by automated means. You retain full control over how you act on AI-generated outputs. ### 4. Data Sharing & Third Parties We do not sell your personal information. We may share information with: * **Service providers:** Third-party vendors who perform services on our behalf (e.g., cloud hosting, analytics, payment processing) solely to operate, support, and improve the Services. These vendors are bound by data processing agreements and may only use your data for specified purposes consistent with this Privacy Policy. * **Professional advisors:** Lawyers, auditors, and consultants under confidentiality obligations, as needed to operate our business. * **Legal compliance:** When required by law, regulation, legal process, or governmental request, or to protect the rights, property, or safety of Kosmos, our users, or the public. * **User-authorized third-party access:** When you use third-party products to access the Services via our API, as described in our API Usage Terms. * **Business transfers:** In connection with a merger, acquisition, financing, reorganization, or sale of all or substantially all of our assets, subject to the acquirer's agreement to honor this Privacy Policy. #### Cookies We use cookies and similar tracking technologies to: * Keep you logged in to the Services * Remember your preferences and settings * Understand how you and others use our Services * Measure the effectiveness of our features and communications * Improve the Services over time For detailed information about the cookies we use and how to manage or opt out of them, see our Cookie Policy. #### Analytics and Experimentation We use analytics tools to understand how visitors interact with our website, measure marketing effectiveness, and run controlled experiments on our pages. These tools process data we collect as a data controller from website visitors and prospects (including email addresses provided on marketing forms), which is distinct from Customer Data processed under our Data Processing Agreement. A current list of analytics tools and third-party processors is available upon request at . You can opt out of analytics cookies at any time via our Cookie Policy or by adjusting your browser settings. ### 5. Data Retention We retain personal information for as long as necessary to provide the Services and fulfill the purposes described in this policy, unless a longer retention period is required or permitted by law. Upon termination of your subscription, we will make Customer Data available for export for 30 days, after which it will be deleted. You may contact us for specifics regarding retention periods for particular data categories. #### Security We implement appropriate technical and organizational security measures — including encryption in transit and at rest, strict internal access controls, and regular security reviews — designed to protect your information against unauthorized access, alteration, disclosure, or destruction. However, no method of transmission over the Internet or electronic storage is 100% secure. We encourage you to use strong passwords and notify us promptly of any suspected unauthorized access to your account. In the event of a data breach affecting your personal information, we will notify you and applicable regulators as required by law. ### 6. Your Rights & Choices Depending on your location, you may have the right to: * Access the personal information we hold about you * Correct or update inaccurate information * Request deletion of your personal information * Object to or request restriction of certain processing activities * Receive a copy of your data in a structured, portable format (data portability) * Withdraw consent where processing is based on consent To exercise any of these rights, contact us at . We will respond to verified requests within 30 days (or within the period required by applicable law). #### California Residents (CCPA/CPRA) Under the California Consumer Privacy Act (CCPA) and California Privacy Rights Act (CPRA), California residents have the following additional rights: * **Right to know:** The right to know what personal information we collect, use, disclose, and sell (we do not sell personal information). * **Right to delete:** The right to request deletion of personal information we have collected, subject to certain exceptions. * **Right to correct:** The right to request correction of inaccurate personal information. * **Right to opt out:** We do not sell or share personal information for cross-context behavioral advertising. * **Right to non-discrimination:** We will not discriminate against you for exercising your CCPA rights. To submit a California privacy rights request, contact us at . We will respond within 45 days, with a possible 45-day extension where reasonably necessary. **Categories of personal information collected:** Identifiers (name, email, IP address); commercial information (subscription and payment records); internet and network activity (usage data, logs); and professional information (company name, job title). **Purposes for collection:** Service delivery, product improvement, security, legal compliance, and communications. We do not sell personal information to third parties. #### European and UK Residents (GDPR/UK GDPR) For individuals located in the European Economic Area (EEA) or United Kingdom, we process personal information on the following legal bases: * **Performance of a contract:** Processing necessary to deliver the Services you have subscribed to. * **Legitimate interests:** Processing for fraud prevention, security, product improvement, and communications about the Services, where those interests are not overridden by your rights. * **Consent:** Where we rely on your consent (e.g., for optional marketing communications), you may withdraw it at any time. * **Legal obligation:** Processing required by applicable law. You have the right to lodge a complaint with your local data protection supervisory authority. A list of EU supervisory authorities is available at . The UK supervisory authority is the Information Commissioner's Office (ICO) at . #### International Data Transfers Kosmos is based in the United States. If you access our Services from outside the United States, your personal information may be transferred to and processed in the United States or other jurisdictions. For transfers of personal data from the EEA or UK to the United States, we rely on appropriate safeguards, including Standard Contractual Clauses (SCCs) as approved by the European Commission, or other transfer mechanisms in accordance with applicable law. Details are available in our Data Processing Agreement. #### Data Privacy Framework (DPF) Kosmos AI Labs, Inc. complies with the EU-U.S. Data Privacy Framework (EU-U.S. DPF) and the UK Extension to the EU-U.S. DPF as set forth by the U.S. Department of Commerce. Where applicable, Kosmos adheres to the EU-U.S. DPF Principles with regard to personal data received from the European Union and the United Kingdom. If there is any conflict between the terms in this Privacy Policy and the EU-U.S. DPF Principles, the Principles shall govern. To learn more about the DPF Program, visit . * **Independent recourse:** In compliance with the DPF, Kosmos commits to cooperate with EU data protection authorities and the UK ICO regarding unresolved complaints about our handling of personal data received under the DPF. * **FTC enforcement:** Kosmos is subject to the investigatory and enforcement powers of the U.S. Federal Trade Commission (FTC). * **Binding arbitration:** Individuals may, under certain conditions, invoke binding arbitration to address complaints not resolved through other dispute resolution mechanisms, as provided under Annex I of the DPF Principles. * **Government access:** Kosmos may be required to disclose personal data in response to lawful requests by public authorities, including to meet national security or law enforcement requirements. #### Anti-Spam Kosmos does not send unsolicited commercial communications. All marketing emails are sent only to recipients who have opted in to receive them, in compliance with applicable law including the CAN-SPAM Act and GDPR. Every marketing email includes a functional unsubscribe link. If you believe you have received an unsolicited message referencing Kosmos, please report it to . #### Children The Services are designed for business use by adults. We do not knowingly collect personal information from children under 13 (or under 16 in the EEA). If we become aware that we have inadvertently collected such information, we will delete it promptly. If you believe we have collected information from a minor, please contact us at . #### Changes to This Policy We may update this Privacy Policy from time to time. We will notify you of material changes by posting the updated policy on our website and revising the "Last updated" date at the top of this page. For significant changes, we will provide at least 30 days' advance notice via email or a prominent notice on our platform. Continued use of the Services after the effective date constitutes acceptance of the revised policy. ### 7. Contact Us For questions about this Privacy Policy, to exercise your data rights, or to submit a data subject request: **Kosmos AI Labs, Inc.** 1918 N. Mendell St. Chicago, IL 60642 *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc. # Terms of Service Terms governing your use of Kosmos *Last updated: July 17, 2026 · Effective: July 2026* *** ### 1. Introduction Please read these terms carefully before using our services. This agreement ("Agreement") is between Kosmos AI Labs, Inc. ("Kosmos," "we," "us") and the entity or person agreeing to these terms ("Customer," "you"). By using our services, you agree to these terms. ### 2. Services #### 2.1 Platform Access Kosmos provides a preventative intelligence platform that automates Root Cause Analysis (RCA) and Risk Event detection through an INGEST, CORRELATE, SURFACE, ACT, and LEARN lifecycle (the "Services"). We grant you a non-exclusive, non-transferable license to access and use the Services during your subscription term for your internal business purposes. #### 2.2 Service Level We commit to platform availability as described in our Service Level Agreement. #### 2.3 Support We provide commercially reasonable support during your subscription via email () and your dedicated support channel. ### 3. Customer Responsibilities #### 3.1 Account Security You are responsible for maintaining the confidentiality of your account credentials and for all activities that occur under your account. Notify us immediately of any unauthorized access or suspected breach. #### 3.2 Authorized Users You may permit your employees, contractors, and agents to access the Services. You are responsible for their compliance with this Agreement. Account sharing between individual users is prohibited. #### 3.3 Acceptable Use You agree not to: * Use the Services for any unlawful purpose * Reverse engineer, decompile, disassemble, or attempt to extract the source code of the Services * Interfere with or disrupt the integrity or performance of the Services * Share access credentials with competitors of Kosmos * Use automated tools to scrape, extract, or harvest data from the Services * Sublicense, resell, or transfer your access rights to third parties * Introduce malicious code, viruses, or harmful components into the Services * Use the Services to process data in a manner that violates applicable law or the rights of any third party We may suspend or terminate your access immediately for violations of this section. #### 3.4 Your Data You retain ownership of all data, logs, telemetry, and other content you upload or provide to the Services ("Customer Data"). You grant us a limited license to use Customer Data solely to provide, maintain, and improve the Services for your account. You represent that (a) you have all necessary rights to provide the Customer Data to us, and (b) your Customer Data does not infringe or violate the rights of any third party. #### 3.5 System Data Requirements As part of the INGEST and CORRELATE phases, you agree to provide only read-only access to the technical logs, API metadata, and system performance metrics necessary for the Services. You are responsible for ensuring that any data you provide complies with your own security policies and applicable law. ### 4. Fees and Payment #### 4.1 Fees Fees are specified in your Order Form. All fees are in U.S. dollars, non-cancelable, and non-refundable except as expressly stated in this Agreement or required by applicable law. #### 4.2 Commitment Period All subscriptions have a minimum 12-month commitment period regardless of billing frequency. Whether you pay monthly, quarterly, or annually, you are obligated to pay for the full commitment period specified in your Order Form. #### 4.3 Payment Terms Payment is due as specified in your Order Form. We may suspend access for accounts more than 30 days past due after providing written notice. #### 4.4 Price Changes We may adjust fees at renewal by providing at least 60 days' written notice before the end of the then-current subscription term. #### 4.5 Taxes Fees exclude taxes. You are responsible for all applicable sales, use, VAT, GST, and similar taxes, except for taxes based on our net income. ### 5. Term and Renewal #### 5.1 Subscription Term Your subscription begins on the start date specified in your Order Form and continues for the term specified therein. #### 5.2 Renewal Subscriptions automatically renew for successive one-year periods unless either party provides written notice of non-renewal at least 30 days before the end of the current term. #### 5.3 Termination for Cause Either party may terminate this Agreement if the other party materially breaches this Agreement and fails to cure such breach within 30 days of written notice describing the breach in reasonable detail. #### 5.4 Effect of Termination Upon termination or expiration, your right to access the Services ends immediately. We will make your Customer Data available for export for 30 days following termination, after which we will delete it, unless applicable law requires a longer retention period. #### 5.5 Refund Upon Termination for Cause If you terminate this Agreement due to our uncured material breach, we will refund a pro-rata portion of any prepaid fees covering the unused portion of the subscription term. ### 6. Intellectual Property #### 6.1 Our IP We own all rights, title, and interest in and to the Services, including all software, algorithms, models, documentation, and improvements. Nothing in this Agreement transfers any ownership of our intellectual property to you. #### 6.2 Feedback If you provide feedback, suggestions, or ideas regarding the Services, we may use such feedback without restriction or obligation to you. #### 6.3 Aggregated and Anonymized Data We may collect and use aggregated, anonymized data derived from your use of the Services to improve our products, develop benchmarks, and refine our AI models. This data will not identify you, your users, or your systems individually. Customers who do not wish their data used for general model training may opt out by contacting us at the address below. ### 7. Confidentiality Each party agrees to protect the other party's confidential information using at least the same degree of care it uses to protect its own confidential information (and no less than reasonable care), and not to disclose such information to third parties except as necessary to perform this Agreement or as required by law (with notice where permitted). This obligation survives termination of this Agreement for a period of three (3) years. ### 8. Data Protection We process personal data in accordance with our Data Processing Agreement and Privacy Policy. To the extent you provide us with personal data of EU/EEA or UK individuals, the Data Processing Agreement governs such processing and is incorporated herein by reference. ### 9. Warranties and Disclaimers #### 9.1 Our Warranty We warrant that the Services will perform materially as described in our documentation during your subscription term. If we breach this warranty, we will use commercially reasonable efforts to correct the non-conformity. If we cannot do so within a reasonable time, you may terminate the affected portion of the Services and receive a pro-rata refund for the remaining prepaid term. #### 9.2 Your Warranty You warrant that (a) you have the authority to enter into this Agreement on behalf of the Customer entity, and (b) your use of the Services will comply with all applicable laws and regulations. #### 9.3 Disclaimer EXCEPT AS EXPRESSLY STATED IN SECTION 9.1, THE SERVICES ARE PROVIDED "AS IS." WE DISCLAIM ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. The Services are tools designed to assist with your operational intelligence and risk management program. We do not guarantee that use of the Services will prevent any particular incident, outage, or adverse event. You remain solely responsible for your operational decisions and outcomes. #### 9.4 AI Features Disclaimer The Services utilize artificial intelligence and machine learning to perform Root Cause Analysis, risk event detection, and predictive recommendations. We do not warrant the accuracy, completeness, or reliability of AI-generated outputs, including RCA findings, risk scores, or recommended actions. You are responsible for reviewing and validating all AI-generated output before relying on it for operational or business decisions. AI outputs are informational and do not constitute professional advice. ### 10. Indemnification #### 10.1 By Kosmos We will defend you against third-party claims alleging that the Services, as provided by us and used in accordance with this Agreement, infringe a third party's intellectual property rights, and pay damages finally awarded (or settlements we approve in writing). If such infringement is likely or determined, we may, at our option: (a) modify the Services to be non-infringing, (b) procure a license for your continued use, or (c) terminate your subscription with a pro-rata refund of prepaid fees. #### 10.2 By Customer You will defend us against third-party claims arising from (a) your Customer Data, (b) your breach of this Agreement, or (c) your violation of applicable law, and pay damages finally awarded against us (or settlements you approve in writing). #### 10.3 Conditions Indemnification obligations require: (a) prompt written notice of the claim, (b) sole control of the defense and settlement (provided no settlement imposes liability or admission on the indemnified party without consent), and (c) reasonable cooperation at the indemnifying party's expense. ### 11. Limitation of Liability #### 11.1 Exclusion of Consequential Damages NEITHER PARTY WILL BE LIABLE TO THE OTHER FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES, INCLUDING LOSS OF PROFITS, LOSS OF DATA, LOSS OF GOODWILL, OR BUSINESS INTERRUPTION, ARISING OUT OF OR RELATED TO THIS AGREEMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. #### 11.2 Liability Cap EACH PARTY'S TOTAL CUMULATIVE LIABILITY ARISING OUT OF OR RELATED TO THIS AGREEMENT WILL NOT EXCEED THE TOTAL FEES PAID OR PAYABLE BY CUSTOMER IN THE TWELVE (12) MONTHS IMMEDIATELY PRECEDING THE EVENT GIVING RISE TO THE CLAIM. #### 11.3 Exceptions The limitations in Sections 11.1 and 11.2 do not apply to: * (a) either party's breach of its confidentiality obligations; * (b) either party's indemnification obligations under Section 10; * (c) Customer's payment obligations; or * (d) Customer's violations of Section 3.3 (Acceptable Use). ### 12. General #### 12.1 Force Majeure Neither party is liable for delays or failures in performance resulting from causes beyond that party's reasonable control, including natural disasters, acts of war or terrorism, labor disputes, government actions, internet or infrastructure outages, or acts of third-party service providers. This section does not excuse payment obligations. #### 12.2 Assignment You may not assign this Agreement or any rights hereunder without our prior written consent, except in connection with a merger, acquisition, or sale of all or substantially all of your assets. Any purported assignment in violation of this section is void. We may assign this Agreement freely. #### 12.3 Governing Law and Dispute Resolution This Agreement is governed by the laws of the State of Illinois, without regard to its conflict of law principles. Any disputes will be resolved exclusively in the state or federal courts located in Cook County, Illinois. Each party consents to personal jurisdiction in those courts. #### 12.4 Entire Agreement This Agreement, including all Order Forms, the Data Processing Agreement, and any referenced policies (SLA, Privacy Policy), constitutes the entire agreement between the parties with respect to its subject matter. It supersedes all prior and contemporaneous proposals, negotiations, representations, and agreements. #### 12.5 Amendments We may update these terms by posting a revised version at kosmoslabs.ai/legal/terms. We will provide at least 30 days' written notice of material changes. Continued use of the Services after the effective date of a change constitutes your acceptance. #### 12.6 Notices Notices to us must be sent to or: Kosmos AI Labs, Inc. 1918 N. Mendell St. Chicago, IL 60642 We may send notices to the email address associated with your account. #### 12.7 Severability If any provision of this Agreement is found to be unenforceable, that provision will be modified to the minimum extent necessary to make it enforceable, and the remaining provisions will remain in full force and effect. #### 12.8 Waiver Our failure to enforce any provision of this Agreement will not constitute a waiver of our right to enforce it in the future. #### 12.9 Export Compliance You agree to comply with all applicable export control and trade sanctions laws and regulations, including the U.S. Export Administration Regulations (EAR) and programs administered by the U.S. Office of Foreign Assets Control (OFAC). You represent that you are not located in, and are not a national or resident of, any country subject to U.S. trade sanctions, and that you are not on any U.S. government restricted party list. #### 12.10 Anti-Corruption Each party represents that it has not received or been offered any illegal or improper bribe, kickback, payment, gift, or thing of value from the other party in connection with this Agreement. ### 13. Contact Questions about these terms? Contact us at . *** **Questions?** Contact | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/) © 2026 Kosmos AI Labs, Inc.