Granted transcript

Open the incident on AI incidents → Cases and ask the attributed developer for the session. When they grant it, the incident's Transcript column reads granted and the modal carries a “Read the granted transcript” link. There is no other route in: the reader is addressed by grant, not by session or by repo.

The link is drawn only for the person who asked. Owning the team does not widen it, because the developer answered a question from one colleague about one incident.

• The banner, which does not scroll away. Who granted it, what the grant covers, when it closes, and how many times you have opened it before. A reader who forgets the terms is the failure this whole feature exists to avoid, so the terms stay on screen.
• The cycles, oldest first. A transcript is read forwards, so this is the order the developer worked in rather than the newest-first order the repo-wide Transcripts subtab uses.
• What was withheld. The developer ticked cycles off before answering, and the count travels with the grant. Their position does not: a cycle somebody refused to send does not send where it sat either. So the page tells you how many are missing and says plainly that it cannot tell you where.
• What the scrubber caught. Per-class counts from the redaction pass that ran before the upload. The developer saw these same counts before they answered.
• Rows that could not be decrypted. Counted and named, never dropped. A short session you were not told about is worse than an error.

Opening this page writes a transcript.grant.read row to the team audit log and advances a counter on the grant. The developer sees that counter on their own Data requests tab, with the time of the last open. It is written on the path that decrypts, so there is no way to read the session without leaving the row.

The sidebar carries a lesson form, and it is the same lessons machinery the rest of RepoOps runs on. There is no second store: the one that matters lives on the developer's machine, and the ranker, the guards, the prevention credit and the fold into CLAUDE.md all read that one.

So the form queues a lesson rather than saving one. Your words go to that machine, which writes them through the same capture gate every other lesson passes on its next pull, usually within five minutes. The panel then says what happened to each one.

• Written as a named lesson. It is in the store and can be pointed at. An exact re-observation of a claim already there folds onto that row rather than making a second, and reads the same way.
• Declined, with the reason. The gate rejects placeholder text and anything a guard could not act on. You are told, rather than watching a lesson sit queued for ever.

The three fields are the gate's own: what to watch for, what went wrong, and the fix. A guard candidate is optional and is the name a future guard would carry.

A grant that is not readable renders as its own state, in its own words, not as an error. Nothing went wrong when a developer changes their mind.

• Revoked. The developer ended it and the stored copy was deleted, and the lesson form closes with it. A lesson you already wrote stays: a lesson is your own writing about what happened, not a copy of their session.
• Expired. A granted read closes on its own deadline, 14 days by default, and the stored copy is purged with it. Asking again mints a new grant, so the trail shows two requests rather than one that reopened.
• Not granted. A request still waiting, one that was denied, and one you withdrew all look the same here, because none of them ever moved any prose.
• Not provisioned. A deployment with no raw-store key cannot decrypt anything and never stored anything. That is a deployment setting, not a fact about the grant.

• It is not the repo-wide raw fidelity setting. That is an owner's standing decision about a whole repo, with its own disclosure, and it is deliberately not reachable from an incident.
• It is not an export. There is no download, and the transcript is not inlined into the incident modal, so opening an incident is not itself a read.
• It is not a whole developer's history. One grant, one session, one incident, one clock.

The developer's side of the same grant is documented under Data requests.