> ## Documentation Index
> Fetch the complete documentation index at: https://checksum.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Onboarding & Proof of Value

> Every Checksum engagement begins with a demo and a Proof of Value (POV) run with our team. You give us access to a test environment and read-only access to your front-end code. We set up the project, tests repository, environments, and first tests for you.

## Talk to sales and book a demo

If you're evaluating Checksum, start by talking to our team. In the demo we walk through your application and testing goals, then agree on a POV scope: which product areas, which environment, and what success looks like.

<CardGroup cols={2}>
  <Card title="Book a demo →" icon="calendar" href="https://checksum.ai/request-demo">
    Meet the Checksum team and see the agent on an app like yours.
  </Card>

  <Card title="Contact your Checksum team" icon="envelope" href="mailto:support@checksum.ai">
    Add a project, environment, or repository, or expand your POV scope.
  </Card>
</CardGroup>

## What is a Proof of Value?

A POV is a time-boxed evaluation where Checksum builds and maintains real tests against your application, so you can judge the results on your own code rather than a sample app. Most of the work in a POV is ours. Your team's main job is to **unblock access before kickoff**, so the evaluation window goes to results instead of waiting on credentials or firewall changes.

<Steps>
  <Step title="Demo">
    We learn about your application, stack, and testing pain points.
  </Step>

  <Step title="Scoping">
    We agree on the product areas, environment, and success criteria for the POV, and set a kickoff date.
  </Step>

  <Step title="Pre-kickoff access">
    You complete the [access checklist](#pre-kickoff-checklist) below. Before kickoff, we verify our Playwright bot and AI can reach your site and that the codebase connection works.
  </Step>

  <Step title="Kickoff">
    We walk through the plan, confirm test users and roles, and start detection on the agreed areas.
  </Step>

  <Step title="POV period">
    Checksum detects flows, generates tests, runs them, and heals them. Tests arrive as pull requests, and bugs appear in the [Feature Health Dashboard](/docs/health-dashboard).
  </Step>

  <Step title="Decision">
    We review results against the success criteria together.
  </Step>
</Steps>

<Tip>
  **Why set up before kickoff?**

  If the access below is in place before the kickoff date, nothing blocks the decision period or our deliverables. The most common cause of a slow POV start is an environment behind a VPN or firewall that hasn't allowlisted our IPs.
</Tip>

## Pre-kickoff checklist

This is everything we need from your team.

* [ ] Shared the **UAT (test) environment URL**
* [ ] Shared **user credentials** for logging in to that URL (one per role you want tested)
* [ ] If behind a VPN/firewall: **allowlisted Checksum's IP addresses**
* [ ] Confirmed nothing blocks automated browsers (bot protection, CAPTCHA, WAF rules) on the UAT environment
* [ ] Connected the **front-end repository** with read-only access (GitHub App approved, or token details sent)
* [ ] Identified someone with **owner/admin** rights on the VCS organization to approve the connection

## 1. Access to the testing environment(s)

To begin testing, we need access to your UAT (test) environment:

| Provide | Why |
| - | - |
| **UAT environment URL** | The application Checksum explores, generates tests against, and runs them on. |
| **User credentials** to log in to that URL | Used by the agent and by test runs. Stored as [test users](/docs/environments#test-users) on the environment. |

Before kickoff, we verify that our Playwright bot isn't blocked and that our AI can reach the site without issues. Please resolve access blockers early, ideally before the POV kickoff date, so they don't delay our deliverables or your evaluation.

### If your environment is behind a VPN or firewall

If your UAT environment sits behind a VPN or similar protection, allowlist Checksum's IP addresses so our AI traffic can reach the site. **Your Checksum contact will send you the addresses to allowlist** as part of pre-kickoff planning.

## 2. Connecting your codebase

Checksum needs **read-only access to your front-end repository**. Our AI agents use the source code as context when they detect and generate new E2E tests, and when they update existing tests that fail at runtime. Without it, the agents can only see the rendered UI. With it, they ground tests in your actual components, routes, and data flows.

### Supported version control systems

| VCS | What to provide |
| - | - |
| **GitHub** | Approve the Checksum bot (GitHub App) |
| **GitLab** | Project ID and Access Token |
| **Azure DevOps** | Organization, Project, Repository, and PAT |
| **Bitbucket** | Workspace, Repository, and Access Token |

### GitHub

Select the repositories that contain the front-end codebase from the Checksum interface:

<Steps>
  <Step title="Log in">
    Sign in at [app.checksum.ai](https://app.checksum.ai).
  </Step>

  <Step title="Open Settings → Git Integration">
    Go to **Settings**, then the **Git Integration** tab.
  </Step>

  <Step title="Click Connect">
    Below **Codebase repository**, click **Connect** and follow the walkthrough.
  </Step>

  <Step title="Approve the GitHub App">
    Approve the Checksum bot (GitHub App) request on GitHub. This may require a user with **owner**-level permissions.
  </Step>
</Steps>

Permissions requested by Checksum's GitHub bot:

* Read access to metadata and repository hooks
* Read and write access to actions, code, issues, and pull requests

<Info>
  **Why write access if the codebase is read-only?**

  The same GitHub App also serves your **tests repository**, where Checksum opens pull requests with generated and healed tests. Checksum **never writes to your code repository**. On a code repo, the effective access is `Metadata: Read`, `Contents: Read`, `Pull requests: Read`. You can limit the app to specific repositories at install time. See the [full permissions table](/docs/git-integration#required-permissions).
</Info>

On GitHub Enterprise Cloud with data residency (`*.ghe.com`)? Follow [GitHub Enterprise](/docs/git-integration#github-enterprise-cloud-with-data-residency) instead.

### GitLab

1. Provide the repository **Project ID**.
2. Create a **Personal Access Token (PAT)** with the minimum permissions:
   * Scopes: `read_api`, `read_repository`
   * Role: `Reporter`

Reference: [GitLab: project access tokens](https://docs.gitlab.com/user/project/settings/project_access_tokens/)

### Azure DevOps

1. Provide the **Organization** name.
2. Provide the **Project** name.
3. Create a **Personal Access Token (PAT)** with the minimum permissions:
   * Code: `Read`

Reference: [Microsoft: use personal access tokens](https://learn.microsoft.com/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate)

<Note>
  Azure DevOps is supported for **code** repositories only. Checksum-managed tests repositories aren't supported on Azure DevOps today, so the tests repository lives with another provider. We'll agree on where during scoping.
</Note>

### Bitbucket

1. Provide the **Workspace** name.
2. Provide the **Repository** name.
3. Create an **Access Token (AT)** with the minimum permissions:
   * Repositories: `Read`
   * Pull requests: `Read`

Reference: [Atlassian: repository access tokens](https://support.atlassian.com/bitbucket-cloud/docs/repository-access-tokens/)

<Tip>
  **That's everything**

  Once the criteria above are met, Checksum can begin. Questions? Reach out to your Checksum contact.
</Tip>

## What Checksum sets up for you

Once access is in place, the Checksum team does the initial project setup. You don't need to install anything to get started.

| We set up | What it is | Change it later |
| - | - | - |
| **Project & API key** | Your Checksum project and its API key, used by the CLI, CI, REST API, and MCP | [API Keys & Authentication](/docs/authentication#your-api-key) |
| **Tests repository** | A Playwright repo scaffolded with `npx checksumai init` (`checksum.config.ts`, login helper, example test). Checksum delivers tests here as PRs. | [Test Repository & Config](/docs/test-repository) |
| **Git integration** | Your code repo (read-only) and the tests repo (read/write) connected | [Git Integration](/docs/git-integration) |
| **Environments & test users** | Your UAT URL, login URL, and the credentials you shared, stored securely per environment | [Environments & Test Users](/docs/environments) |
| **Login verification** | The built-in `example` test, run to prove Checksum can log in to your app | [Verify locally](/docs/test-repository#run-the-suite-on-your-machine) |
| **First detection** | Detection on the POV scope, producing collections of proposed test flows for review | [Detect Test Flows](/docs/detect-tests) |

## After kickoff: what your team does

* **Review pull requests.** Generated and healed tests arrive as PRs in your tests repository. Review and merge them like any other code. See [Review and merge](/docs/generate-tests#review-and-merge).
* **Answer the agent's questions.** Deep-mode sessions ask clarifying questions and wait for you to approve a plan. See [Agent Sessions](/docs/agent-sessions).
* **Triage bugs.** When the agent classifies a failure as an application bug, it appears in the [Feature Health Dashboard](/docs/health-dashboard) for you to confirm or dismiss.
* **Invite teammates and add users.** Add more test users or environments as scope grows. See [Environments & Test Users](/docs/environments).
* **Wire up CI and notifications** when you're ready. See [CI/CD Integration](/docs/ci-integration) and [Notifications & Slack](/docs/notifications-and-slack).

## FAQ

<AccordionGroup>
  <Accordion title="Can we set Checksum up ourselves instead?">
    The pieces are documented ([Test Repository & Config](/docs/test-repository), [Git Integration](/docs/git-integration), [Environments](/docs/environments)), but new projects are created and configured by the Checksum team. Start with a [demo](#talk-to-sales-and-book-a-demo).
  </Accordion>

  <Accordion title="Does Checksum need access to production?">
    No. A POV runs against your UAT/test environment. You can add more environments (e.g. staging) later.
  </Accordion>

  <Accordion title="Do you need our back-end code?">
    The requirement is read-only access to the **front-end** repository. That's what grounds selectors, routes, and flows.
  </Accordion>

  <Accordion title="We use SSO for our own team's sign-in to Checksum">
    Microsoft Entra ID sign-in is supported. See [Microsoft Entra ID SSO](/docs/sso-entra) for what your IT team needs to approve.
  </Accordion>
</AccordionGroup>