Ship it with proof.
ArcRelease reads the tools you already run and judges every release on the evidence. Shipping past a failure takes a signature. It never sits in your deploy path.
Preflight
Example release · illustrative data
4 pass · 1 warn · 1 fail · 1 not checked
- Release ceremonies2 of 12 still pendingFrom Ceremony ownersWarn
- Risk score34, under the 60 thresholdFrom Gaja risk modelPass
- Open incidentsNone correlated to this releaseFrom PagerDutyPass
- Change freezeNo active freeze windowFrom Freeze windowsPass
- Upstream dependenciesEvery dependency has shippedFrom Release graphPass
- Approvals1 approval still outstandingFrom ApproversFail
- Security findingsNo scan captured for this releaseFrom SnykNot checked


Judged on evidence. Signed when it isn’t clean. Live today
Your tools report
Evidence arrives from what you already connected. No new agent in your pipeline.
Connected today: GitHub, GitLab, Bitbucket, Jenkins, CircleCI, Argo CD, Snyk, SonarQube, PagerDuty, Datadog, Grafana, Jira, Linear, ServiceNow and Freshservice.
Every check gets a verdict
- Pass
- The evidence says it’s clean.
- Warn
- Worth a look before you ship.
- Fail
- Blocks the record until someone signs.
- Not checked
- No data, no opinion. Never counted as a pass.
Proceeding is on the record
An override needs a statement and evidence. The preflight is frozen at that moment, in a log nobody can edit.
release.risk_acceptedstatement · 1 evidence link · failing checks: approvalspreflight snapshotted · immutableWhen it breaks, read it back to the decision. Next
- Incident
- Deployment
- Release
- Pull request
- Commit
- Ticket
- Requirement
- Review
- Ruling
What caused it, who decided, what was checked, what should have caught it. If nothing was checking, that gap becomes the next check. Requirement, review and ruling exist only for changes built through ArcCode.
The front door: start the change here too. Next
ArcCode
Bring the ticket from your tracker, whether Jira, Linear, GitHub or Asana, and the coding tool your team already uses.
- A spec a human always approves
- Coverage checked before any code
- Code review, by a second tool if you choose
- Every call the agent made alone, acknowledged
Project setup
Set a project up once, and every change inherits it.
- PRD, FRD and BRD, every version kept
- Your branching strategy and hotfix path
- Which stages need a human, per project
- The SOP your release must follow
Questions teams ask first
Does ArcRelease sit in our deploy path?
No. Your pipeline deploys. ArcRelease reads evidence and records decisions, and if it is down, nothing stops.
What does “Not checked” mean?
No evidence was captured for that check, so ArcRelease gives no opinion. It is never counted as a pass, and it tells you which tool to connect.
How is the risk score calculated?
A deterministic model adds points for evidence such as failed deploys, open incidents, pending ceremonies, security findings and critical dependent services, each within a fixed cap. Every point is listed with its reason.
What happens if we ship past a failing check?
An admin or release manager signs a statement and attaches at least one evidence link. The preflight is snapshotted at that moment and written to an audit log the database will not let anyone change.
Which tools does ArcRelease read?
GitHub, GitLab, Bitbucket, Jenkins, CircleCI, Argo CD, Snyk, SonarQube, PagerDuty, Datadog, Grafana, Jira, Linear, ServiceNow and Freshservice, with notifications to Slack. ServiceNow change requests are captured today; evaluating them as a gate is next.
Which coding agents will ArcCode support?
ArcCode is next, not live yet. It is designed around the agent your team already uses, such as Cursor, Claude Code or Codex, chosen per stage.
How do we start?
With a 30-day, read-only pilot: connect the tools you already run and see your next release judged.
Start with a 30-day, read-only pilot.
Connect the tools you run today and see your next release judged. Nothing to install in your pipeline.