AI contribution policy examples and a machine-readable YAML schema
Open-source projects are writing incompatible rules for AI-assisted contributions. This workstream records what projects actually require and proposes a format that tools can read.
The policy gap
Policies are commonly published as prose in contribution guides, issue templates, or separate documents. Contributors must find and interpret each one, while maintainers have no standard field for disclosure, verification, or review expectations.
The catalogue verifies policies against project-controlled sources. It includes projects such as curl, Ghostty, LLVM, and tldraw without treating those examples as a universal sample of open source.
Projects in the catalogue
Compare all 21 policies in one table: stance, disclosure rule, source and date
21 entries so far, each verified against the project's own published policy on its capture date. Stances range from disclosure requirements to outright bans, and one project has closed external pull requests entirely.
AetherSDR (opens in a new tab) · Asahi Linux (opens in a new tab) · Bevy (opens in a new tab) · curl (opens in a new tab) · Fedora (opens in a new tab) · FreeBSD (opens in a new tab) · Gentoo (opens in a new tab) · Ghostty (opens in a new tab) · Godot (opens in a new tab) · Home Assistant (opens in a new tab) · Kubernetes (opens in a new tab) · llama.cpp (opens in a new tab) · LLVM (opens in a new tab) · Mesa (opens in a new tab) · NetBSD (opens in a new tab) · OpenStreetMap (opens in a new tab) · QEMU (opens in a new tab) · Rust (opens in a new tab) · Servo (opens in a new tab) · tldraw (opens in a new tab) · Zig (opens in a new tab)
Design position
- Verification over unreliable detection
- Disclosure over hidden use
- Project choice over one mandatory posture
- Machine-readable fields plus human explanation
What the schema can express
- Whether AI assistance is allowed
- Required disclosure
- Testing and verification expectations
- Project-specific exceptions and references
Review the evidence and proposal
What useful review looks like
The strongest feedback identifies a real project policy that is missing from the catalogue, a field the schema cannot represent, an ambiguity that would confuse contributors, or a verification workflow that maintainers cannot realistically perform.
The next milestone is version 0.2, informed by project and foundation review. Adoption by another project is a stronger success measure than publishing a specification without users.