--- title: "KYE Protocol™ — Working groups | Open governance, six tracks, RFC process" description: "KYE Protocol™ working groups. Six open WGs — KYE™ Core, Open Banking, Agent Governance, Evidence & Audit, Capability Profile, Compliance Mapping" url: https://kyeprotocol.com/working-groups/ lang: en source: "KYE Protocol" --- > KYE Protocol™ working groups. Six open WGs — KYE™ Core, Open Banking, Agent Governance, Evidence & Audit, Capability Profile, Compliance Mapping Open governance # Where the protocol gets shaped. KYE Protocol™ is governed in the open. Six working groups meet on GitHub Discussions; minutes and decisions are public; profile and endpoint changes land via a four-stage RFC process. Membership is open to anyone with operational expertise in the relevant domain — you do not need to be a partner, a customer, or a contributor today. Six working groups ## One per surface that needs deep domain input. [**KYE™ Core** Spec evolution: vocabulary, schemas, runtime, state model, decision codes, audit chain. _github discussions →_](https://github.com/KYE-Protocol/Discussions/discussions) [**Open Banking** Consent, delegated payment-initiation, PSD3 / DORA / EU AI Act binding, agent purchasing. _github discussions →_](https://github.com/KYE-Protocol/Discussions/discussions) [**Agent Governance™** MCP capability profiles, agent identity, model + tool cards, runtime governance. _github discussions →_](https://github.com/KYE-Protocol/Discussions/discussions) [**Evidence & Audit** Audit-chain integrity, evidence-pack format, OSCAL projection, public-key replay. _github discussions →_](https://github.com/KYE-Protocol/Discussions/discussions) [**Capability Profile** First-class capability schemas, parameter-level scopes, attenuation rules. _github discussions →_](https://github.com/KYE-Protocol/Discussions/discussions) [**Compliance Mapping** 289 controls across 249 frameworks; KYE™ Compliance Mapping Rail™; OSCAL emit. _github discussions →_](https://github.com/KYE-Protocol/Discussions/discussions) Cadence ## Async first, sync where necessary. - **Primary venue** — GitHub Discussions on `KYE-Protocol/Discussions`. Every WG has a top-level category. Threads are the default; meetings are the exception. - **Sync calls** — scheduled when an active WG needs to convene; 60 minutes, recorded, minutes posted. Open to any participant. Times rotated across timezones. - **Decisions** — rough consensus on the discussion thread, then rubber-stamped on the next sync. Two-maintainer-approval required for spec changes. - **Working artefacts** — PRs land in the relevant public mirror repo (`kyeprotocol.com/schemas/`, `kyeprotocol.com/developers/api/`, `kyeprotocol.com/compliance/`, etc.). CI must be green. Working-group charter ## What every WG agrees up front. Each WG operates under a published charter. The charter is intentionally short — the goal is to constrain scope, not to write process for its own sake. 1. C1 **Scope.** Which parts of the spec the WG owns. Boundaries with adjacent WGs. 2. C2 **Decision rule.** Rough consensus + two-maintainer approval. Disputes escalated to the cross-WG council. 3. C3 **Membership.** Open. Recognised participants are listed; voting members named. 4. C4 **Conflict-of-interest.** Members disclose vendor affiliations. Decisions favouring one vendor are flagged. 5. C5 **Code of conduct.** The [Contributor Covenant](https://github.com/KYE-Protocol/.github/blob/main/CODE_OF_CONDUCT.md) applies. Maintainers enforce. RFC process ## Four stages from idea to landing. 1. RFC-1 **Open a discussion.** File a GitHub Discussion in the relevant WG. Describe the gap, the proposed shape, the worked example. The WG decides whether to charter the work. 2. RFC-2 **Spec PR.** Once the WG has consensus, open a PR with the schema + OpenAPI op + at least one example. IP-safety scan must pass. 3. RFC-3 **Conformance fixture.** Add at least one black-box fixture under the conformance pack. CI must pass against the fixture. 4. RFC-4 **Sign-off.** Two WG maintainers approve. Schema gets a stable `$id`. Profile lands in the next minor release. **Security disclosures** bypass the RFC track. See [SECURITY.md](https://github.com/KYE-Protocol/.github/blob/main/SECURITY.md). Foundation track ## Neutral governance at v2.0. v1.0 governance lives in the KYE Protocol™ project. The intentional path at v2.0 is to move governance to a neutral foundation — Linux Foundation or OpenWallet Foundation are the working candidates — with a royalty-free IP grant, an unchanged trademark policy, and the existing WGs preserved as foundation working groups. The trademark policy and proprietary track are documented on the [legal page](https://kyeprotocol.com/legal/). Join ## Open by default. The fastest way to engage: open a GitHub Discussion in the WG that matches your domain. The slowest way: wait for an invitation. There is no invitation; the WGs are open. [GitHub Discussions →](https://github.com/KYE-Protocol/Discussions/discussions) Get in touch first [Engagement model](https://kyeprotocol.com/engage/) Adjacent reading ## Where to go next. [Protocol →](https://kyeprotocol.com/protocol/) [Vocabulary](https://kyeprotocol.com/vocabulary/) [Roadmap](https://kyeprotocol.com/roadmap/) [Partners](https://kyeprotocol.com/partners/) [Certification](https://kyeprotocol.com/certification/) ## Ready to see your AI agents flagged? Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/) Canonical KYE™ surfaces referenced on this page: [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE™ Conformance Pack™](https://kyeprotocol.com/compliance/) · [KYE Protocol™](https://kyeprotocol.com/).