Home/Platform/Gaja AI preflight
Pillar 3 of 6

GO, NO-GO or CONDITIONAL, with its reasons attached

Gaja is Sanskrit for elephant, and an elephant never forgets. Gaja remembers every release your teams have shipped and every incident that followed — which is why its verdict arrives with reasons attached rather than a score you are asked to trust.

In short

What is a Gaja preflight verdict?

A Gaja preflight verdict is GO, NO-GO or CONDITIONAL computed in seconds from ceremony state, the dependency graph, freeze windows, historical incident rate and blast radius — with every reason cited to the ticket, commit or past incident it rests on.

The problem

Why a risk score is not enough.

“

The tool gave us a number. Nobody could tell me what the number meant or what to do about it.

“

We overrode the score twice and it never learned anything from being wrong.

“

A blocked release with no way forward just becomes an argument in a meeting.

Gaja AI

Memory is the product, not a feature.

A Gaja verdict is not a model guessing from scratch. It is a comparison against what happened the last time this service shipped in this shape, and every claim traces back to the fact underneath it.

94%
preflight accuracy
Design target from product modelling. Not yet measured in production. As of July 2026.
Every reason cites its signal: "security sign-off outstanding" links to the gate and its owner; "this service failed twice in six weeks" links to the two incidents.
You are allowed to disagree. A cited reason can be argued with, corrected or overridden — and the override is recorded with your reason.
A wrong verdict is diagnosable: usually a stale gate, a bad edge or an incident on the wrong service. Fix the signal, the verdict corrects.
CONDITIONAL returns a route through: ship the API change now, hold the schema migration until the freeze lifts.
Advisory by default. Most teams compare verdicts against outcomes for a few releases before enforcing anything.
How it works

What actually happens.

01

Gather the signals

Ceremony state, the dependency graph, active freezes, historical incident rate and blast radius for the release.

02

Compare against history

Gaja weighs this release against what happened the last times this service shipped in a similar shape.

03

Return a cited verdict

GO, NO-GO or CONDITIONAL in seconds, each reason linked to the signal behind it.

04

Learn from the outcome

Confirmed incidents and overrides become history that weighs on the next verdict.

Who this is for
Release ManagerEngineering LeaderSRE / On-call
Reads from
JiraGitHubPagerDutyDatadogJenkins

Gaja reads what your tools emit and returns a verdict your pipeline can choose to gate on. It is never in the deploy path.

FAQ

Gaja AI, answered.

No. The point of Gaja is the opposite: every verdict arrives as reasons in plain language, each naming its source, so you can follow every claim back to the fact underneath it.

You override it with a reason, and the override is recorded. A wrong verdict is almost always a stale gate, a bad dependency edge or an incident attributed to the wrong service — fix the signal and the verdict corrects.

Only if you wire the check into branch protection. By default it is advisory; teams compare its verdicts against real outcomes before enforcing.

Related capabilities

Incident correlation
From alert to the pull request that caused it, in about ten seconds.
Read more →
Release risk analytics
DORA four keys, decomposed by service and team.
Read more →

Stop guessing at go/no-go.

Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.

See the platform

Free plan · ten minute setup · we reply in one to two business days