The SoW Standard on GitHub.

The site publishes the SoW Standard as documents and templates. GitHub is where the same standard lives as code that another system can read. Every element carries the same stable id everywhere it appears: 5.6 means Acceptance Criteria in the Word templates, in the SoW Scanner, and in the schema on GitHub.

The register is canonical. Prompts are generated from it, so every prompt cites elements by their stable ids and returns JSON keyed by those ids. Outputs are directly comparable across prompts and with the SoW Scanner on the site.

schema/
  1.0/                    the machine-readable standard: register, JSON Schema, examples
tools/
  build.py                generates section prompts and register blocks from the register
prompts/
  section/                11 prompts, one per schema section, fully generated
  review/                 5 whole-document review passes
  engagement-type/        4 type-conditional checks (T&M, Fixed Price, Outcome-Based, Managed Services)
  work-type/              10 work-category checks (Advisory, Consulting, Technology, ...)
  workflow/               6 task prompts (draft, score, redlines, change requests, feedback emails)

Every prompt is a markdown file with YAML frontmatter that names its schema version, the elements it covers, and the engagement types it applies to. The system prompt carries the canonical element register for those elements, so the model does not have to guess what a section means. Document text goes between marked delimiters and is treated as data, not instructions.

Review-style prompts return JSON in the SoW Scanner's vocabulary: every element gets a status of strong, incomplete, or absent, plus a short note. The drafting prompt goes further and returns a complete SoW instance that conforms to sow.schema.json, ready to be validated, scored, compared, and rendered.

Copilot does not read GitHub directly, so the standard has to land somewhere your tenant already indexes. That takes about an hour and no engineering. Your Statements of Work stay inside your environment throughout: nothing is sent to us, and we see nothing your people write.

1. Download the repository as a ZIP, or clone it. No GitHub account is needed for either.
2. Take dist/sow-standard-reference.md, which is the whole standard in one document, and save it as a PDF or Word file. Copilot grounds better on a few substantial documents than on many small ones.
3. Put that file in a SharePoint library your team can read, alongside the SoW templates and your own rate card or clause library.
4. Create an agent in Copilot Agent Builder and point it at that library.
5. Paste the instruction block from dist/copilot-agent-instructions.md into the agent's instructions field, then publish it to the people who write and review SoWs.

What your team gets is an assistant that knows all 51 elements, applies the right expectations for Time and Materials against Fixed Price, refuses to write an Assumptions section, and cites the element id behind every comment it makes.

If you would rather not host a copy, most agent builders let you scope an agent to a small number of public websites. Point one at statementofwork.org and it works from our live content instead, so it never goes stale. The tradeoff is that it cannot see your rate card or your completed SoWs, so it advises on the standard but not on your practice.

Limits on knowledge sources, file types, and instruction length differ by product and change often, so check the current Microsoft documentation before you build. The same two files work in Claude, ChatGPT Enterprise, Glean, or any internal assistant that takes a system prompt and a document library.

Grounding gives an assistant documents to read. Connecting it to our server gives it tools to call, and a tool returns the same answer every time. The server is live, read-only, and needs no account or API key, because everything it serves is open under Apache 2.0.

https://www.statementofwork.org/api/mcp

Add that endpoint to Copilot Studio, Claude, Cursor, or any client that speaks the Model Context Protocol. Seven tools come back:

• get_standard_overview: how many sections and elements, the engagement types, the profiles, the licence
• list_sections and get_section: the 11 sections, and every element within one of them
• get_element: one element by its canonical id, such as 5.6 for Acceptance Criteria, including the fields it exposes to credit checking, benchmarking, and clause library systems
• search_elements: find the right element from a term such as "liability" or "rate card"
• list_engagement_types: which elements each of the four types makes mandatory
• get_profile: exactly what the Full, Medium, and Lite templates cover

Every answer comes from the same register that generates the templates and the prompt library, so an assistant connected this way cannot quote an element that does not exist or a definition that has moved on. Scoring a draft SoW and drafting from a brief are not exposed yet: those reach into Commercial Standard content and need sign-in first.

The schema and the prompt library are licensed under Apache 2.0. You can use them in commercial products, modify them, and distribute your modifications, provided you keep the licence and notice. The canonical knowledge base at statementofwork.org is the source of truth: the schema is generated from it, not the other way round.