Data requests

Two different decisions, kept apart on purpose:

• A delegation is permission to ASK. It is a standing switch at the bottom of the page.
• A grant is permission to READ one session, for one incident, for a bounded time. It is the answer to one asking.

Collapsing the two would turn "you may ask me" into "you may read anything". A grant covers the session named on the request and expires on its own.

Each waiting request shows five things: who asked, which incident, which session, the reason they typed, and when the ask lapses if nobody answers it.

• The preview is per cycle. Every prompt-and-reply pair in the session is a row with a checkbox. Untick anything you do not want to send. The button re-counts as you go, so the number on it is what will actually leave.
• What you exclude never leaves the machine. Only the COUNT travels, so the reader sees a gap where the excluded cycles were rather than a seamless story.
• The redaction counts are shown before you decide. The scrubber runs over what you send and the page tells you how many values of each class it will remove. You see the counts, never the values.
• Denying asks for a reason, and the person who asked sees it. A refusal with no reason reads as a system fault rather than a decision.

A granted row keeps a Revoke button for as long as the grant is live. Revoking deletes the stored copy and closes the reader.

A grant also closes on its own. An unanswered request lapses after three days, and a granted read closes after fourteen. Both are team-overridable, and the row shows the date.

• Your team owner may ask you for transcripts.Permission to ask. Turning it off stops the asking; it does not revoke a grant you already gave, which you do on the row itself.
• Auto-grant for critical incidents attributed to me.Off by default. On, a critical incident attributed to you sends the session without asking first, with the same redaction pass and the same clock. You can still revoke, and every read is still recorded. It changes WHEN you are asked, not what is sent.

Your machine pulls. Nothing is pushed to it, and the hosted side cannot reach in. While the app is running it checks for new requests about every five minutes, on the same schedule as the other settings it syncs, so an ask usually appears here within a few minutes of being made.

• Only the question travels. A request carries who asked, why, which incident, and when it expires. No transcript moves in either direction at this point, and none moves at all until you grant one.
• An unlinked machine asks for nothing. If this install is not connected to a team, the check does not run and makes no network request. You can turn it off entirely with REPOOPS_CONFIG_SYNC_ENABLED=0, which also stops the other settings syncs.
• A request about an incident this machine never saw is skipped, not guessed. Your machine matches an ask to its own record of the incident. If it has none, the request does not appear here rather than appearing against the wrong session.
• An outage changes nothing. A failed check writes nothing at all, so it can never look like an answer you did not give.

An owner or admin starts the ask from an incident in the hosted dashboard, on the Cases queue under AI incidents. Opening an incident there shows them six things and no more: its severity, its repo, whether it came from an agent session, who it is attributed to, the confidence band behind that attribution, and how many times it has been seen. No prompt, no excerpt, no transcript. A Transcript column on the queue shows them where each ask stands, so the state you set is the state they read.

• They cannot ask about everything. An incident with nobody attributed to it, or with no agent session behind it, or below the team's severity floor, offers no request at all, and the page says which of the three it is. The floor starts at high.
• They cannot choose who gets asked. The developer is resolved from the incident on the server. Naming somebody in the request is not possible, so an ask can never arrive pointing at the wrong person.
• They cannot ask twice at once. One live request per incident. Asking again after you answer creates a new request, which you answer again.
• They see who said the incident was yours. If a case was attributed to you by a colleague's machine rather than your own, the incident says so before they ask. That is often innocent, because a colleague's checkout sees the same commit, and it is shown rather than hidden either way.
• There is no override. The repo-wide raw fidelity setting exists and is a different decision, made by an owner about a repo, with its own disclosure. It is not reachable from an incident.

• The decision is made on your machine. The hosted side mirrors your answer so an owner can see it; no hosted code path can grant on your behalf. That is enforced in code and tested, not just stated here.
• Every move is recorded twice, once in the local append-only log beside your brain and once in your team's audit trail, including each time somebody opens a transcript you granted.
• Asking again is a new question. A denied, revoked or expired grant is final; a second ask creates a new request that you answer again.
• If the store cannot be read, the page says so and shows nothing as granted, rather than guessing.