Getting started with Veripsa Core

Install once, then keep working as usual. Veripsa reacts to matching GitHub activity automatically.

Install Veripsa Core from GitHub. During install, pick which repositories it can access. You can grant a single repo, a hand-picked set, or All repositories. The App uses minimal operational metadata to run advisory checks; your file contents are never stored. See the Privacy Policy for the data boundary in full.

What happens next. On the first push to the default branch (or shortly after install on a quiet repo, on the next push you make), Veripsa Core prepares advisory context from main. Processing time depends on repository size and GitHub delivery timing. Until processing finishes, new PRs may temporarily show Unknown. That's expected.

What to do. Nothing special. Keep working. Matching pull requests receive checks after install.

No agent-side setup. Installation is complete at this point. Checks and comments appear from GitHub activity whether a human, Codex, Claude Code, or another tool opened the PR. If you later want a merge-capable agent to interpret the advisory consistently, use the optional agent guidance — nothing needs to be installed or run on the agent side.

Open a pull request as you normally would. Within a short while, Veripsa Core posts a check on the PR. The check reports one of four states; they are advisory by default — they tell you what was observed, not what you must do.

• Clear. No collision was found with the other open pull requests Veripsa Core can see on this repository.
• Heads up.This PR may clash with another open PR. It's worth a look before you land.
• Wait in line. Likely overlap was found, and Veripsa Core suggests this PR may need to wait behind related work. It is a suggestion, never a hard block on its own.
• Unknown.Veripsa Core can't tell. The comment names the reason explicitly: (a) the PR adds a brand-new path that isn't on mainyet, so there's no prior signal to compare against, or (b) the file is in a language or file type Veripsa doesn't cover yet. (A third short-lived case, ingest still warming up right after install, resolves on its own.) Unknownis an honest “don't know,” not a claim that there's no collision.

What to do. Read the verdict. Click into the check to see why it flagged the PR — which files overlap and which other open PR it relates to. Normal advisory use requires no CLI command or acknowledgement. Do not turn the check into a required gate until you have seen enough examples on your own repository.

The core scenario is two open PRs touching related code at the same time. When this happens, Veripsa Core can surface it on both PRs and suggest an advisory land order, such as landing one PR first, rebasing the other, then re-checking.

What to do. Use the suggested order as a decision aid. You can wait, rebase, or continue with your existing merge process. Do not change policy from one example.

Honest caveats. Veripsa Core coordinates pull requests withineach repository — a PR in one repo will not warn against a PR in a different repo, even on the same GitHub account. If your collision is across repos, the App can't help you yet. Cross-repository coordination is on the roadmap and isn't a current claim.

This is not an installation step and is not needed for ordinary advisory use. If your team wants to record that it deliberately proceeded past a Wait in line, Veripsa supports an explicit GitHub-label acknowledgement.

After a human has reviewed the specific overlap and decided to land, add the veripsa-ack label to the pull request to record that decision. The label is an exception signal, not a routine per-PR action.

• The label means “I have seen this snapshot of the collision and chosen to land.” It is an acknowledgement, not an approval. It does not assert that the collision is resolved, that the other PR will adapt, or that a code review has happened.
• If the overlapping work changes after you ack, Veripsa Core can surface the contention again and ask for a fresh acknowledgement.
• The ack is a per-PR action, applied by whoever has write access to the repo. It's designed to be visible — the label appears in the PR's history so reviewers and future readers can see that a Wait in line was overridden deliberately.

When to use it. Only when the team deliberately wants an auditable override. Waiting, rebasing, or continuing through your existing advisory workflow does not require an ack ceremony.

Up to this point Veripsa Core has been advisory: it posts a check, you read it, you decide. Review several examples from your own repository before you let the check gate a merge.

Only if you want Veripsa Core to be a hard gate on the merge — i.e. one of the required checks that must pass before GitHub will let a PR merge — configure it in a GitHub ruleset or branch protection, not in the App. Veripsa alone never blocks the merge button. Consider these consequences before you flip the switch:

• Plan dependency. Branch protection on private repositories is available on Pro / Team / Enterprise plans, not on Free. On Free, the check is always advisory on private repos and can be marked required on public repos. The matrix is in the main Docs page.
• The ack is your safety valve. Once the check is required, a Wait in line becomes a merge-blocking signal until you add the veripsa-ack label. Make sure the team knows the label exists, what it means (acknowledgement, not approval), and who is expected to use it.
• Unknown is advisory even when required. Unknownresolves the check to a state that won't block your merge by itself — you review the PR as you normally would. The required-check setting doesn't turn Unknown into a hard block, because that would punish honesty.
• Merge queues.If you use GitHub merge queue, Veripsa Core re-checks the batched commit and reports an advisory verdict on the queue entry, so a required Veripsa check doesn't deadlock the queue. See the main Docs page, section Webhook and event surface, for the events involved.

Honest default. Required-check is optional. It should be a later decision made after reviewing enough verdicts on your own repository. There's no penalty for never flipping the switch; the App is useful as an advisory signal whether or not it gates the merge.

Common states and how to read them.

A few expectation boundaries:

• Veripsa Core is not an AI code reviewer. It does not store, retain, display, or use source file bodies for code review. It looks only at which open pull requests touch overlapping parts of the repository.
• Veripsa Core is not a merge queue. It does not serialise your merges or hold PRs for you. It surfaces collisions and a suggested order; you (or your merge queue) decide what actually lands.
• Veripsa Core does not coordinate across separate repositories today. It coordinates open PRs within one repository, even when multiple repositories belong to the same GitHub account.
• The App never hard-blocks a merge by itself. Whether its check gates a merge is entirely controlled by your branch-protection rules.

If Veripsa Core isn't the right fit, uninstall it from your GitHub settings. Uninstalling stops all processing and purges the content-free working set for your account — see the Privacy Policy for the deletion details. During early access there is no paid subscription or separate checkout to cancel; uninstalling is enough to stop coverage.

• Optional agent guidance for Codex, Copilot, and Claude-style agents — only if you want merge-capable agents to interpret the advisory consistently. Core already works without this step.
• Docs — full reference: current coverage notes, plan matrix, webhook surface, and triage guidance.
• Free access — free while in early access, with fair-use limits that protect the shared service.
• Privacy — the content-free data boundary in detail.
• Support— how to reach us if a verdict looks wrong or setup doesn't match this guide.