Everything here is advisory and read-only. Nothing in this guide changes your workloads (the sample incident happens in a scratch namespace you create and delete). ChangeGuard does not act on your cluster until you explicitly opt into remediation.
Minute 0–5 — Verify the install
Three checks and you know everything is healthy:Both roll out successfully, and in app.changeguard.ai your cluster appears in Fleet with the connection indicators green (“Agent connected”, “Workloads detected”).
Minute 5–10 — Read your score, run a pre-flight — and meet the Advisor
1
Open Safe to Ship?
Your cluster already has a CSC Score — a deterministic 0–100 read of deploy readiness. Every point ties to a concrete signal you can inspect.
2
Run a pre-flight check
You get SHIP / HOLD / BLOCK with the score and reasons. It’s advisory — a recommendation, never an enforced block.
3
Look for the Advisor's read
Where the Engineering Advisor is enabled , its note appears with the verdict: the read a senior engineer would give, led by what’s true in your cluster right now, honest about what it can’t see.
Two things that are correct, not broken: if the Advisor has nothing material to add, it stays silent — restraint is the feature. And if you don’t see the Advisor at all, that’s expected — it’s Early Access; contact us to join.
Minute 10–15 — See your first change
Deploy something, tweak a config, or let a GitOps sync flow in — ChangeGuard is already recording every deployment, config, and GitOps change across the fleet.The change appears in ChangeGuard with what actually changed — the commit and diff, not just “a deploy happened.”
Minute 15–25 — Trigger a sample incident, safely
Now the part worth the price of admission: watch a failure get correlated to the change that caused it. Do this in a scratch namespace so it touches nothing real:Within a few minutes, an incident appears for
sample-api — linked to the image change you just made. Cause, not just symptom.Minute 25–30 — Open the investigation: understanding, evidence, opinion
Open the incident before you clean up.1
Read the Current Understanding
Where incident context is enabled, the incident opens with the Current Understanding — the shared, maintained read of what’s happening right now: what changed, what it broke, and where things stand. What a teammate joining mid-incident needs, without scrolling the history.
2
Check the evidence
The root cause comes with cited evidence — the events, the failing rollout, and the change that shipped it. Claims trace to records, not vibes.
3
Read the proposed fix — and how to verify it
ChangeGuard proposes the fix and states the verify criteria. It applies nothing at the default autonomy level — this is advice you act on.
4
Look for the Opinion
Where the Engineering Opinion is enabled (Early Access), you’ll also see ChangeGuard’s owned position: belief, confidence, tradeoffs, and what would change its mind.
Every incident also carries an append-only activity timeline — your audit trail of what was observed and decided.
Set your comfort level
ChangeGuard’s autonomy is a dial, not a switch: Observe → Advise → Approve → Auto, default Advise.You’ve now seen the loop
In 30 minutes: a verified install, a scored cluster, a pre-flight verdict, a real change with its diff, a failure correlated to its cause, an evidence-cited investigation — and, where enabled, the Understanding, Opinion, and Advisor that turn it into a teammate.Understand the concepts
What CSC Score, Change Intelligence, and the autonomy model really mean.
Operate it day-to-day
Health checks, upgrades, notifications, and keeping the collector happy.
Wire in your tools
GitOps, CI gates, and notifications — what each reads, writes, and needs.
Review permissions
Exactly what ChangeGuard can and cannot see or do in your cluster.