This page describes how technical material across 100 lessons is checked before it is published. It is a companion to the editorial policy, which sets the rules; this page describes the mechanics.
The short version: claims are checked against primary documentation, anything that can be validated by a program is validated by a program in the build, and anything that was not executed says so.
Research
Primary sources first. For The Copilot Stack that means GitHub's own product documentation, changelog and release notes, and — for anything about a third-party tool — that vendor's own documentation. Secondary write-ups, including well-regarded ones, are treated as leads to check rather than as evidence.
Every source that establishes a factual claim is listed on the page that makes the claim, with the date it was consulted. An article that names one vendor's documentation as its only source for a comparison against that vendor is not a comparison; the article schema enforces a minimum of two named sources for exactly that reason.
Version verification
GitHub Copilot changes faster than most documentation cycles. Pages that state pricing, plan names, model availability, command syntax or feature support are flagged version-sensitive in their own frontmatter and carry a review interval — as short as seven days for model availability, as long as 180 days for material that rarely moves.
When a page passes its interval, the build fails. Not a warning, not a dashboard: the site cannot be released with a lapsed version-sensitive page until a human re-checks the claims and advances the verification date. That date is shown on every lesson under Last technically verified, separately from Updated, so a typo fix can never imply the pricing was re-checked.
What the build checks
Certain classes of error recur often enough to be worth catching by machine rather than by attention. Each of these runs on every build and fails it:
- Command flags — every CLI flag named in prose must exist in the verified command data, and no retired flag may appear as current.
- Model names — every model named in prose must exist in the structured model data.
- Customization surfaces — no obsolete file location may be presented as current, and no capability may be overstated beyond what the documentation supports.
- Agents and MCP — no client may be shown reading a file it ignores; no example may use a wrong top-level configuration key; retired terminology must always be mapped to current terminology.
- Enterprise policy — precedence must be stated as documented, and no policy may be claimed to govern a surface it does not.
- Security — no credential-shaped literal may appear anywhere in the content, and no absolute safety or compliance claim may be made.
- Links — every internal link must resolve to a route the site actually generates.
- Site claims — the counts the site states about itself must be derived from curriculum data, not typed.
Code
Code is executed where a runner exists for it. Where an example is part of a companion project in this repository, that project is validated by the same commands a reader would run — the test suite for application code, the formatter and validator for infrastructure code, the linter for workflow files.
Where an example illustrates a Copilot interaction rather than a program — a prompt, a chat exchange, a suggestion — it is not executable, and it is not presented as though it were.
Commands
Commands are reviewed before publication against the verified command data described above. Destructive commands are shown with the guard that makes them safe, or not shown. No command that would delete data, overwrite state or spend money appears here without that being stated in the text immediately around it.
Infrastructure
Infrastructure examples are validated, never applied. That means formatting checks, provider-free initialisation, schema validation and plan generation — the operations that prove a configuration is well-formed and internally consistent without creating anything.
No example in this repository provisions cloud resources as part of its validation. A tutorial that bills the reader for running its verification step is a tutorial with a defect.
Screenshots
Screenshots are not fabricated, composited or mocked up. Where a screen cannot be captured honestly, the interface is described in text instead. A rendered approximation of a product UI is a claim about what the product looks like, and it is a claim nobody can verify from the page.
AI assistance
AI is used here in research, drafting and review — which, on a site about AI-assisted development, would be a strange thing to pretend otherwise. It is not treated as an authority. No factual claim reaches publication because a model asserted it; every version-sensitive claim is traced to documentation a reader can open.
The editorial policy states in full where AI is and is not used.
Untested examples
Where an example has not been executed, the page says so. This is the part of a testing methodology that is usually missing, and it is the part that makes the rest of it worth anything: a site that claims every example is tested has told you nothing you can check, whereas a site that marks the untested ones has told you something about all of them.
What we do not claim
- We do not claim every example has been executed. Where it has, the page says so specifically.
- We do not claim coverage of every Copilot surface. GitHub ships faster than any independent site can verify, and pages state their verification date so you can judge the gap yourself.
- We do not claim compliance outcomes. Nothing here makes an organisation SOC 2, GDPR or ISO compliant, and no page will say otherwise.
- We do not claim first-party knowledge. This site is independent of GitHub, Inc. and Microsoft, has no access to unreleased information, and works only from what is publicly documented.
Corrections
Substantive errors are corrected in place, with the verification date advanced and — where the correction changes what a reader should do — a note on the page. Corrections are not made silently, and pages are not quietly withdrawn to avoid making one. The corrections section of the editorial policy describes the process and how to report an error.
Who does this
The Copilot Stack editorial team. That page states plainly what kind of entity that is and what it does not claim to be.