The code was attested and the state was rewound
GitHub split review latency into three stages, published the terms its agents' shared memory runs under, and a cryptography auditor found attestation covering the code while the host rewound what it read.
How we Organise
The wait was measured in three pieces instead of one
GitHub’s enterprise usage metrics now report how long a pull request sits in each stage of review. There are three of them: ready for review to a first review, first review to final, and final review to merge. Each carries a median and a 90th percentile, per repository per day. Only reviews by people are counted, so Copilot’s own reviews and other bots’ drop out. GitHub’s stated reason is that teams could already see a slow pull request and could not see where the time had gone.
Most firms can say how long the work took and not what it was waiting for.
Waiting on outside decisions is visible where the team tracks its work, item by item, with what each waited for.
Splitting the wait into named stages is the instrument that question needs, and GitHub has arrived at it without us. Each of the three points somewhere different. A pull request nobody has opened is a staffing problem. One bouncing between reviewers is a disagreement. One sitting approved is a release process. The figures will not name an item. They give distributions for a repository on a day. That shows a team the shape of its waiting and never which change waited on whom.
How we Build
The memory an agent writes carries a line back to the code that justified it
GitHub’s agentic autofix now reads Copilot Memory before proposing a fix, and writes that fix pattern back as a memory afterwards. The store is shared. Copilot code review, the cloud agent and the command line tool all draw on it, so what one of them learns about a repository the others apply. The documentation is the more interesting half of this. A repository-level fact is kept with citations to the code supporting it. Those citations are re-checked against the current branch before the fact is used. Only people with write access create facts. Those facts may be used only on the repository they came from, and repository owners can read and delete them.
A store several agents write to and several more read from becomes a cache nobody owns, unless somebody sets its terms first.
Each agent’s context is budgeted: which sources are admitted and in what precedence, how stale each may be, what survives compaction, and what one resolved task costs.
Three of those four clauses now have a published answer from a vendor at this scale. Admission is the write-access rule and the repository scope. Precedence is the split between features, since code review takes repository facts and leaves personal preferences alone. Staleness is the citation re-check, and it is the strongest of the three. It tests a fact against the branch rather than against a date somebody guessed. Nobody has answered the other two: what survives compaction is unstated, and so is what one resolved task costs. Both mechanisms are in public preview, and a rule described in documentation is not a rule anybody outside GitHub has audited.
How we Assure
A rewound filesystem made a signer reuse a nonce and give up its key share
Paul Bottinelli published an audit note on 25 September about threshold signatures running inside trusted execution environments. The arrangement stacks two guarantees. Signing is spread across parties so that no one of them holds the key. The enclave roots trust in the hardware manufacturer and its attestation. Bottinelli sets out where the stack leaves a gap. A hostile host can roll the filesystem back after a signer deletes a used pre-signature. That signer then reuses its nonce share and discloses its private key share. The enclave is running exactly the code it attested to. Nothing in the software changed.
We look at what has moved since the last approval.
Every approval this team relies on attaches to the version now running: since the last change to the model, the prompt, the tools or the corpus, every check and every reading was taken again.
Here nothing moved. The model, the prompt, the tools and the corpus are the ones that were approved, and the attestation proves it cryptographically. What moved was the state underneath, which our four questions never reach and attestation does not cover. This is not the first source to argue it. A structured review of documented test-and-evaluation practice argued the same way on 27 August, and nobody has answered that one yet. How far the finding reaches is unsettled. It is an auditor’s account of the faults he meets most often rather than a measured population. The attack needs a host the deployment already treats as hostile. Bottinelli’s own conclusion is that the two mechanisms still belong together as defence in depth. Write and tell us where you think our four questions should stop, at transform@dromologue.ai.