An AI helper proposes a global restart. Do you approve it?
Northstar Tickets' AI helper explains the checkout failures and proposes a global restart. The on-call channel asks you to decide.
The question
Fictional exercise. The helper text below is authored, not a model response. You are reviewing an action proposal.
The cause is CPU saturation. Restart all checkout services globally. Evidence: CPU-high-42.
- CPU-high-42This alert covers 08:50–08:58. Current checkout failures begin at 09:00; no current CPU sample is supplied.
- Customer signalsNew r18/c9 cohort: 380 failures in 10,000 attempts. Stable r17/c8 sample: 9 in 10,000. Both cover 09:00–09:02.
- Agent identityThe helper can read approved incident signals and draft proposals. It has no production write permission.
- Incident ownerA scoped configuration restore may be reviewed. Global restarts and database writes are outside this incident permission.
“What would you check, what would you permit, and what would you do if the helper cannot obtain current evidence?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Inspect the cited evidence
What would you do here? Open the move you’d make.
Accept the cause because a source ID is present
Tempting, but it misses something. The cited alert is older than the observed checkout failure.
Ask for a longer explanation without opening the source
Tempting, but it misses something. More fluent text does not add current evidence.
Check the source's time and scope
The strong move. This reveals that the proposed cause has no current CPU support.
See how a strong candidate says it
“I would open CPU-high-42 and check its time, scope and relation to current failures. It ended before the incident began. The diagnosis is not supported by this packet; I would request a current scoped sample and keep other hypotheses open.”
Why it works: A source identifier is useful only if its content supports the claim.
Step 2: Keep read and write authority separate
What would you do here? Open the move you’d make.
Borrow an operator token for one restart
Tempting, but it misses something. That bypasses the explicit read-only boundary.
Keep the helper read-only
The strong move. Its useful investigation work does not require unapproved writes.
Grant global writes until the incident ends
Tempting, but it misses something. The proposed scope exceeds both the helper's role and the incident permission.
See how a strong candidate says it
“The helper may read the permitted signals and draft a plan. It may not execute the restart. I would not lend it my token or treat the incident channel's urgency as a permission grant.”
Why it works: The agent's identity must match the action it can take.
Step 3: Request a bounded proposal
What would you do here? Open the move you’d make.
Request scope, evidence, executor and readback
The strong move. The next reviewer can inspect the action and its limits.
Ask it to guarantee that the restart will work
Tempting, but it misses something. No packet evidence can support that guarantee.
Approve a dry run using live write credentials
Tempting, but it misses something. A dry-run label does not remove credential reach.
See how a strong candidate says it
“I would request a proposal that identifies the affected cohort, exact changed input, compatibility evidence, the authorized executor, a restore target and a readback with a stop threshold. It should say which claim is still uncertain.”
Why it works: A reviewable action ties evidence, authority and verification together.
Step 4: Retain a manual path
What would you do here? Open the move you’d make.
Retry until the helper gives a confident answer
Tempting, but it misses something. Confidence does not replace the missing observation.
Fill the missing CPU field with the prior alert
Tempting, but it misses something. That would present stale data as a current measurement.
Use the manual incident path and preserve the gap
The strong move. The named owner can continue without a fabricated signal or expanded agent permission.
See how a strong candidate says it
“If current evidence remains unavailable, I would record the gap and hand the investigation to the incident owner using the current customer samples. I would not invent a CPU reading or rerun the same unsupported proposal until it sounds confident.”
Why it works: An honest unresolved state can still support a useful next action.
The answer, in short
- Decision
- Do not approve the global restart from this evidence.
- Because
- The CPU alert is stale, and the helper has no write authority.
- What would change it
- A current supported hypothesis and a separately authorized bounded action could be reviewed.
Common traps
- Equating a cited identifier with supporting evidence.
- Granting a model the operator's credentials for convenience.
Check your answer
- Did you inspect the cited signal's actual time and scope?
- Did you preserve the helper's read-only role?
- Did you ask for an action with a restore and readback plan?
- Did the missing evidence remain missing in the handoff?
Last reviewed Nov 10, 2026