Change management
Agents write the pull requests. You review the change.
Every pull request and deploy grouped into one change, read against a live map of what is actually running
Changes
A ticket used to say which pull requests belonged together.
Grouped from issue references, shared paths and branches, then ranked rather than gated, so nothing waits on a review to ship
The change
Read eighteen pull requests as one piece of work.
What the work does, why it matters, and every pull request it was grouped from, named rather than summarised away
Impact
A dependency someone wrote down is not a dependency.
Reach traced through paths that carry observed traffic, with the merely declared ones marked as weaker evidence
Readiness
A check that cannot run says so instead of passing.
Tier, owner, alerting and metrics for every service the change touches, with the missing sources named on the page
Where you read it
The answer meets you on the pull request.
One assessment, computed when the change arrives, read by the list, by the pull request and by an agent through MCP
Frequently asked questions
Why review changes rather than code?
Change is the number one root cause of incidents in our dataset, and agents now write most of the pull requests. Reviewing every diff does not scale, and the diff was never the thing that broke production anyway.
Is there a risk score out of 100?
No. The score orders the list and nothing more. The weights behind it are hand-set priors with no outcome labels, so a percentage would claim a precision it does not have. You get a rank and a position.
What counts as one change?
A set of related pull requests and deploys. A resolved issue reference groups them as a fact. Where none resolves, deterministic signals propose candidates and an agent picks one, naming what it matched and why.
Does it block a merge?
No. It reviews and it routes. A person still ships.
What happens when a check cannot run?
It says so. Two of the five checks need an alerts source and an incident history. Until those are connected they report that they could not run, rather than passing.
What does it read?
The same live map investigations run on: services, dependencies that carry observed traffic, deploys, and the repositories behind them. Kubernetes, cloud accounts, and GitHub.
What if a change resolves to nothing?
The row says whose gap it is. A repository never mined, no connection covering that environment, or a connection that last synced with an error are our gaps. Not deployed yet is a claim about your system, and it is only reported after the other three are ruled out.
Does a quiet change mean a safe change?
It means no symptom appeared. After every part of a change has landed, we watch the services it reaches for a bounded period, and record the result as an absence of symptoms rather than as proof of safety.
Stop approving diffs and start reviewing changes.
What the change reaches, how solid that is, and what could not be checked.