Reading the card

Every investigation ends with a card posted to your Slack thread. This page explains what each block means, so you can read a report the way it was meant to be read — as a set of checkable claims, not a verdict to take on trust.

A finding

I pulled the thread — here’s the culprit. The p95 latency alert on checkout-api traces to the 14:02 deploy (rev checkout-api-00042, commit a1b2c3d). The new revision dropped the connection pool to 2 (DB_POOL_SIZE unset — was 10). Errors started 90 s after rollout: [log query] · [revision diff] · [metric].

Proposed fix: restore DB_POOL_SIZE=10 in the service config and redeploy. Confidence: high — error onset matches rollout to the minute, and the pool-exhaustion stack trace appears 214×.

The blocks, in order

1. Verdict — the finding, stated first and in one sentence. Bobby leads with the answer, not the process that produced it.
2. Context — which tenant, which project, which alert policy fired.
3. Evidence — every claim names its evidence, as a named link, not a bare URL: “log query”, “revision diff”, “metric”. A console deep link is only ever included when Bobbin can construct it deterministically from its own tool calls — never invented by the model, because an invented link that looks plausible is worse than no link.
4. Proposed fix — always framed as a suggestion, never an instruction. A runnable command only appears at high confidence; below that, Bobby gives direction without a command to paste. Bobbin cannot apply anything itself — read-only, permanently — so applying a fix is always your action.
5. Confidence — a word, with a reason attached, never a score and never a colour. “High” means the evidence lines up in more than one independent way (timing and a stack trace, in the example above); a lower confidence says so and states what is missing.
6. What was checked — the full list of what Bobby examined, whether or not it turned out to matter. This is what makes the time-saved claim verifiable rather than asserted: you can follow every link Bobby used and see the same evidence yourself.

The honest miss

When the evidence runs out, Bobby says so, with the same structure: what was checked, the leading hypothesis if there is one, and exactly what would confirm it.

I couldn’t determine the culprit. I checked the deploy history (no release in the last six hours), error groups (none new), and the metric timeline (latency rose gradually over 40 minutes, not a step change). No single cause stands out. Leading hypothesis: a slow memory leak — the heap graph is climbing across the window. Confirming it would need a longer observation window than this alert covers.

Confidence: low. What I checked: [log query] · [metric range] · [deploy history] · [error groups].

This is a good outcome, not a failure. Every AI product claims accuracy; the useful question is what it does when the evidence runs out. A confident wrong guess costs more trust than an honest “I don’t know, here is what I ruled out” — and an honest miss and a confirmed finding render with equal weight everywhere in the product, never as a lesser or apologetic result. If Bobbin only ever posted confident findings, that would be evidence it was hiding uncertainty, not evidence it had none.

Verifying a report yourself

Every read behind a card is attributable in your own Cloud Audit Logs — see Verify access for the exact query. Nothing in a card is a claim you have to take on trust; it is a claim you can check.