What's changed: New GH-300 Chapter 3 (data handling & flow = context gathering/prompt building, proxy filtering/post-processing, per-plan data usage/sharing/retention; suggestion lifecycle & LLM limits = context change → generate → present → accept/reject loop, unconfirmed inline candidate, probabilistic generation/knowledge cutoff/context dependence/no correctness guarantee)
3.1Data Handling and Flow
Understand how Copilot uses, flows, and shares data; how input is processed and the prompt is built; and the role of proxy filtering and post-processing.
Using Copilot safely and appropriately requires understanding how data flows. The rough flow is: gather editor context → build the prompt → pass through a proxy/filters → the model generates → post-process and return the suggestion. GH-300 tests this data flow and the role of filtering/post-processing along the way.
3.1.1Input processing and prompt building
To produce a suggestion, Copilot first gathers context—from code near the cursor, open files, and related files—selecting the most relevant information to build the prompt sent to the model. Context is finite and must fit a bounded context window, so what is included vs omitted affects suggestion quality. Files under content exclusion (Chapters 2 and 6) are left out of this context gathering.
3.1.2Proxy filtering and post-processing
The prompt is processed before and after reaching the model. At the proxy stage, filtering occurs—harmful content, known vulnerable patterns, and (per settings) detection of suggestions matching public code (duplication detection, Chapter 6). After the model generates, post-processing formats output and removes unneeded/inappropriate results before returning the final suggestion to the editor. These mechanisms improve output safety and quality.
3.1.3Data usage and sharing
Which data is used, flowed, and retained depends on the plan (individual/Business/Enterprise) and settings. Generally, Business/Enterprise tiers offer enterprise-minded defaults such as not using prompts/suggestions to train the model. Users and admins should review the data-handling policy against their requirements (confidentiality, regulation) and adjust via content exclusion or telemetry settings as needed. Knowing "what is sent where, and what is retained" underpins responsible use (Chapter 1).
Common: (1) Data flow = gather context → build prompt → proxy/filter → model generates → post-process → suggestion. (2) Context must fit a finite context window—what you include affects quality. (3) Proxy filtering (harmful/vulnerable/public-code match) and post-processing (format/remove). (4) Data usage/sharing/retention varies by plan and settings (Business/Enterprise don’t use it for training, etc.).
Watch out: (1) "More context is always better" is false—the context window is finite and irrelevant info lowers quality. (2) Proxy filtering improves safety but is not perfect—output validation is still required. (3) Data handling varies by plan/settings—don’t assume your individual behavior applies to the org. (4) Content-excluded files are used neither as context nor for suggestions.
3.1.4Section summary
- Data flow: gather context → build prompt → proxy/filter → generate → post-process → suggestion
- Context fits a finite window—selection affects quality
- Proxy filtering and post-processing format/remove (improve safety but not perfect)
- Data usage/sharing/retention varies by plan and settings (Business/Enterprise don’t train on it, etc.)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which correctly describes Copilot’s first step before producing a suggestion?
Q2. In the path to the model, which stage filters harmful content and matches with public code?
Q3. Which is a correct understanding of context?
Q4. Which is generally true about data handling for Business/Enterprise plans?
Q5. After the model generates, which stage formats output and removes inappropriate results?
Q6. Because proxy filtering exists, may you skip output validation?