Design RFCs
A decision that shapes the framework — a new trust boundary, a new install mechanism, a rule every skill has to obey — gets written down before it is built. These are those documents: the reasoning, the alternatives that were rejected, and what adopting the design commits the project to.
An RFC is a record, not a manual. Once one is implemented, the rules it settled live in the docs describing the thing itself; the RFC stays behind as the explanation of why those rules are the way they are.
The RFCs
| RFC | Title | Status |
|---|---|---|
| RFC‑AI‑0002 | Secure Agents setup | Implemented |
| RFC‑AI‑0003 | Privacy-aware LLM routing for foundation private information | Provisional — pending ASF Privacy VP / Legal |
| RFC‑AI‑0004 | Principles of agentic interaction for open-source maintainers | Implemented |
| RFC‑AI‑0005 | Framework taxonomy | Implemented |
| RFC‑AI‑0006 | Trusted external skill sources | Partially implemented (Phase A) |
| RFC‑AI‑0007 | Selective snapshot — fetch only the chosen skill families | Proposed |
| RFC‑AI‑0008 | The coordinator role — multi-hop relay of security reports | Draft |
Every RFC carries its own Status of this document section. That section is the authoritative one if this table has fallen behind.