Before explaining a change in a Copilot chart, write down the question, reporting period and client evidence that a reviewer would need.
GitHub's October 6, 2026 notice concerns IDE releases using the Copilot SDK for agents. Agent activity was omitted or misattributed to CLI; earlier implementations were unaffected. Billing did not change. Missing history cannot be restored, earlier CLI attribution cannot be untangled, and CLI users need no update. VS Code 1.139.0 and later is fixed; other client fixes remain planned.
Source: GitHub's October 6 attribution announcement
Record the fix that actually exists for each client
Check the announcement's client-specific release table when preparing an update; a planned release is not a shipped fix.
A version below the fixed release is not enough to establish impact. Record the affected status only when you have supporting release evidence.
Use an existing approved device inventory or ask the responsible administrator to confirm the versions. Keep the review inside your organization's access and privacy rules; it does not require collecting prompts, source code or employee-by-employee performance scores.
Make a client-and-report review card
Copy the following fields into your existing internal tracker. One row should describe one client group and reporting question, rather than mixing every IDE into a single “updated” checkbox.
| Field | What to enter |
|---|---|
| Question | The exact chart or field being investigated, and the decision it was meant to support. |
| Report identity | Enterprise or organization scope, report type, UTC start and end dates, export time and approved evidence location. |
| Client group | IDE and extension names, observed versions, observation time, and the inventory's coverage or known omissions. |
| Release evidence | Official fix reference, whether it has shipped, and whether this group's affected status is confirmed or unknown. |
| Change record | Approved rollout owner, verified installation date and remaining clients. Leave unperformed actions blank. |
| Observation plan | A completed post-update UTC day to examine, a later report recheck, and the person responsible. |
| Result and limit | What the fresh report shows, what remains unverified, and the next decision or check. |
GitHub's field reference places the most recently detected versions inside each per-user totals_by_ide entry. The nullable last_known_ide_version object contains ide_version and sampled_at; last_known_plugin_version contains plugin, plugin_version and sampled_at. These version objects are absent from aggregate breakdown rows. A sampled timestamp may itself be null.
That makes the observation date part of the evidence. A recent export containing an old version sample does not establish today's installed version. Preserve “not observed” separately from a recorded value. Never substitute a blank version with the fleet's intended standard.
Keep the historical gap visible
Retain uncertain periods with an explanation of how you identified them. If the start is unknown, record that. Preserve the original export; do not invent replacement values or reassign activity between categories.
For example, a fictional internal note could say: “Evidence and limits are linked below. The next review has an owner and a date.” Keep the note beside the chart so its reader can find the underlying card.
Separate a finished update from a finished observation
Confirm the installed version through your normal software-management process. Then identify a full UTC day after that confirmed change for a fresh report review. Avoid treating the day of a staggered rollout as a clean before-and-after boundary.
The documentation currently gives different freshness guidance: the usage-metrics overview says two full UTC days after a day closes, while the reconciliation guide says data typically finalizes within three. For this review card, wait three full UTC days after the selected day closes before the planned recheck. That is a conservative editorial procedure, not a guarantee or a new GitHub service commitment.
As an example of the calendar arithmetic, a selected day of October 8 UTC closes at the start of October 9. Three full UTC days then run through October 11; the planned recheck starts October 12 UTC. Use your actual dates, not this example, in the card.
Do not silently change telemetry preferences, bypass a proxy or expand access to make a chart look complete. If the authorized administrator identifies a policy or network limitation, record it and route the decision to the owner.
Compare the same question on both sides
Keep the population, scope, field definition and reporting window explicit. If people joined or left the group, or clients changed at different times, list that alongside the comparison. Keep a reporting comparison separate from any assessment of staff performance.
GitHub's coverage documentation explains that server-side signals can establish active users even when richer client-side details are unavailable. A user can therefore appear in active totals while feature or lines-of-code breakdowns remain empty. Inspect the particular field you need; a populated headline total is not a completeness certificate for every breakdown.
For an unresolved discrepancy, use a short decision path:
- Version not established: return to the inventory owner. Do not infer installed software from a target policy.
- Fixed release not yet available: retain the qualification and set a release-note recheck.
- Observation day still recent: retain the pending result until the planned data recheck.
- Fresh report still insufficient: compare the report identity and client evidence, then ask the authorized owner to investigate. Do not declare the issue resolved because the update installed.
Close with a qualified reporting handoff
Finish the card with three short statements: what is known, what is still unknown, and when someone will look again. Write each statement from the evidence on the card. A blank result field means the review still has work to do; assign it rather than letting it disappear into a general completion label.
This is a documentation-based review workflow, not a test of a live organization's Copilot deployment. Its purpose is to keep a measurement change from becoming an unsupported story about adoption. The best outcome is a report whose scope and limitations another person can understand without reconstructing your investigation.