How it works

One judgment, before and after every production change.

A change is proposed. ChangeGuard AI judges it against the environment it will actually enter and answers SHIP, HOLD or BLOCK with the reasons in plain terms. If it ships, ChangeGuard AI observes what happened and writes that into the same record. If something goes wrong, it proposes the fix within the authority you grant. Nothing about this requires you to change how you deploy.

The flow

Proposed change → environment → judgment → outcome → history

1 · Proposed change

Something is about to go to production

A pull request, a pipeline step, an agent, or a person in the product. ChangeGuard AI takes the description, the artifact, or the actual manifest.

2 · Environment

The live state of where it will land

What is running there right now, what the environment can afford, how healthy it is. Read-only, refreshed continuously.

3 · Judgment

SHIP / HOLD / BLOCK, with reasons

Plain-terms reasons, plus an honest list of the evidence the judgment had and the evidence it did not have.

4 · Deployment & outcome

What actually happened

Your pipeline deploys as it always has. ChangeGuard AI records the result — deployed successfully, or an incident — against the change that caused it.

5 · Remediation & history

Fixed, verified, remembered

A fix is proposed; a person approves it, or your policy does. It is applied, verified, and kept in the permanent record with the judgment and the outcome.

The verdict

What SHIP, HOLD and BLOCK mean

Three answers, each with its reasons. ChangeGuard AI is advisory by default: it states a position and does not prevent execution. In GitHub, a BLOCK fails the pull-request check and a HOLD never does; whether a failed check stops a merge is your branch rule, not ours.

SHIP

ChangeGuard AI sees no reason to hold this change. The evidence it had supports it, and the reasons say which evidence that was.

HOLD

Review first. Something is worth a look — often evidence ChangeGuard AI did not have, which it names. A proposed artifact that has not been independently evaluated is HOLD, never SHIP: missing evidence is never counted as safe.

BLOCK

ChangeGuard AI advises against this change. Judged against live state it would fail or break something — exceed the environment’s memory budget, request more than its own limits allow, contradict what is actually running.

A real BLOCK — the reason, in numbers
A change record with verdict BLOCK: scaling the storefront to 8 replicas would exceed the namespace memory quota — used 256Mi plus a proposed delta of 768Mi exceeds the hard limit of 512Mi.
From a real pull request against a live environment. Valid manifest; wrong in context. Only a judgment against live state catches it.
The evidence

Where the judgment gets its facts

Every reason cites evidence. Every verdict lists what it had and what it did not have, so a judgment made on partial evidence says so.

The proposed change

The description, the artifact, or the actual manifest. From a pull request the workflow sends the changed manifests; by hand you describe the change and name the image.

The environment, live

Connected read-only, refreshed continuously: workloads, quotas, health, what is actually running. Connect centrally through your cloud account with nothing installed, or with a small read-only collector where evidence has to stay local. Either way the judgment is the same.

What happened before

Prior changes to the same target and their outcomes — recalled only when they change the decision, and shown when they do.

Collection details, permissions, and architecture: the documentation. Trust model and boundaries: Security & trust.

After deployment

The loop closes on the same record

Observed outcome

Deployed successfully, or an incident. Attached to the change by the verdict it named — never by whatever happened most recently. A change nothing reported on reads “not reported”, never “safe”.

Remediation, within your authority

Advise (the default): ChangeGuard AI proposes the fix and a person approves or rejects it. Auto (opt-in): it acts within a policy you write — namespaces, fix types, a confidence floor, an hourly cap. Per environment, never account-wide.

Verified before “fixed”

No fix is called successful until real health confirms it. Every fix keeps its approver on record. The watching side of ChangeGuard AI is read-only throughout; write access exists only where you grant it, scoped to the workloads you name.

Change record — SHIP, then what actually happened
A change record showing the judgment before execution (SHIP) and the observed outcome afterwards: deployed successfully, attributed by the verdict it named.
The judgment before execution and the outcome after, on one permanent, shareable record.
Boundaries

What leaves your environment — and what never does

Never leaves

  • Your source code
  • The plaintext values of your secrets
  • Execution authority — fixes run in your environment, scoped by the access you grant

Sent to ChangeGuard AI

  • Environment state (workloads, events, posture)
  • Change metadata and diffs from your pull requests and pipelines
  • Findings you choose to ingest (vulnerability, benchmark, log signals)
Read-only by default, tenant-isolated at the database, and every session short-lived. The full trust model — permissions, egress, isolation, and what the AI analysis can and cannot see — is on the Security & trust page and in the documentation.

Get your first verdict in five minutes

Start free and judge a change by hand — no environment required. Connect one when you want live context; connect GitHub when you want a verdict on every pull request.