Answer a request to read one session
When an incident is attributed to your session, your team owner can ask to read that one session. The ask lands on your machine, you see what would leave before you answer, and nothing is sent until you press Grant. No switch answers for you.
Watch it
Read the narration
- 0:00 An incident points at your session.
- 0:02 Your team owner asks to read it.
- 0:06 It lands on your machine, and no switch can answer for you.
- 0:13 Untick what you withhold, and the scrubber counts what it removes.
- 0:17 The button says what will leave, and a denial needs a reason.
- 0:23 Revoke deletes the stored copy.
- 0:25 The Reads column shows what was already read.
Synthetic example. Read the guide
How to
This machine bound to your repoops.ai team, and the session's transcript still on disk. Asking is for the team's managers, from the hosted Cases queue.
- Decide the standing delegation once.
Open Privacy and egress, Requests to read a transcript. Under The standing delegation, which is a different decision, the switch Your team owner may ask you for transcripts is on until you turn it off. Off stops asks reaching this machine, and once mirrored the hosted ask is refused up front. It never revokes a grant you already gave.
- Wait for an ask.
Until one arrives the card reads Nobody has asked to read one of your sessions. Your machine checks on the quarter hour whether a request is waiting and pulls it when one is. A new ask writes the notification A transcript was requested from you and appears under Waiting on you with who asked, which incident, the reason they typed and when it lapses.
- Read the preview and untick what you withhold.
Each prompt-and-reply cycle is a checkbox with its size and the first 240 characters, read from your own machine. A cycle over 4 MiB is marked too large to send and is skipped, never cut short. The button counts as you go: Grant, 9 of 12 cycles is what will leave.
- Press Grant, or Deny with a reason.
Grant drops the unticked cycles, runs the scrubber over the rest, sends the decision with the counts, then sends the scrubbed cycles. Deny opens a field, Why you are denying this: type the reason and press Deny, they see the reason. The owner reads your answer.
- Read the outcome line and the row.
The line says what left, for example Sent 9 of 12 cycles, or why nothing did. The row under What you have already answered carries the state, incident, session, cycles sent, Reads, answered and closes dates.
- Revoke when you want the reading to stop.
Press Revoke on a granted row, then Revoke for good. It closes the hosted reader and deletes the stored copy. It cannot unread what was already read, which is why the Reads column exists.
Use cases
A critical incident a colleague needs to understand
- Situation
- A checkout route started failing after a merge, the incident is attributed to your session, and your owner asks with a reason.
- You do
- Open the request from the notification, read the reason and the cycles, untick the two cycles that were other client work, and press Grant, 10 of 12 cycles.
- You see
- The outcome line reads Sent 10 of 12 cycles. Your row reads granted with a closing date 14 days out. The owner can read those ten cycles, scrubbed, and each open advances Reads on your row.
An ask you decline
- Situation
- The session also holds unrelated work you will not share, and you would rather not be asked for a while.
- You do
- Press Deny and type the reason. Then untick Your team owner may ask you for transcripts.
- You see
- The row reads denied with the date. The owner reads your reason, and their next ask is refused with a sentence saying you turned standing requests off. A grant you gave earlier stays live until you revoke it.
Expected outcome
Next step: The machine is unbound, REPOOPS_CONFIG_SYNC_ENABLED is 0, the delegation is off, or this machine never reported that incident. The [transcript-grants] lines on the app's output name the reason.
Next step: The transcript file is gone or unreadable. Deny still works.
Next step: The session gained a cycle after the preview. Reload and answer again; the request is still open.
Next step: The machine is unbound or the decision did not reach the server. Revoke, fix the binding, and ask the owner to ask again.
Next step: A line in the transcript-grants log failed to parse. Repair or remove it under the repository brain's transcript-grants folder, then reload.
What else to consider
The owner's side: reading a granted transcript
When the grant lands, the Attribution section of the case's record on its case page shows Read the granted transcript, and only to the person who asked; owning the team does not widen it. The reader opens in a slide-over on that page and keeps the terms on screen: who granted it, what it covers, when it closes and how many times you opened it. The cycles run oldest first. Withheld cycles are counted but not placed, because a cycle that was not sent does not send where it sat. Rows that could not be decrypted are counted and shown, never dropped.
Every open writes a transcript.grant.read audit row and advances the Reads count the developer sees. A form below the session queues a lesson to the developer's machine, which writes it through the same capture gate as any other lesson and reports whether it was written or declined with the reason. A revoked, expired, never-granted or not-provisioned grant renders as its own state, not an error. There is no download, and the transcript is never inlined into the incident.
What travels, and when
Before you answer, only the device token on the pull and your delegation answer travel. On Grant: the decision, the session id, the cycle counts and the scrubber's counts, then the ticked cycles after the scrubber, encrypted when the server stores them; this machine holds no key. On Deny: the reason. Nothing else, and no transcript before a grant.
The clocks
An unanswered request lapses after 72 hours and a granted read closes after 14 days. Neither has a control. A lapsed, denied, revoked or expired grant cannot be reopened; a new ask mints a new grant, so the trail shows two requests.
Who can be asked about what
A manager asks from an incident on the hosted Cases queue, one live ask per incident, about the developer the incident names. The team's floor (the hosted admin console at /team/overview, Transcript requests: severity floor, high by default, each change audited) decides which incidents qualify. No hosted code path can write granted; a test asserts it at the source.
What is kept
Every transition appends a row to the repository brain's transcript-grants log, with counts and never cycle text; the delegation keeps its own log. No route deletes either: they record what was in force when something was disclosed. The hosted copy is purged on revoke and on expiry, and the grant row and its audit rows remain. No model call is made anywhere in this feature. Retention windows are on Privacy and retention.