---
title: "Governance"
description: "Who owns each HCP repository, who decides, how a normative change moves from RFC idea to release, and when you may say you implement HCP."
canonical: https://harnesscontextprotocol.io/docs/community/governance
---

# Governance

> Who owns each HCP repository, who decides, how a normative change moves from RFC idea to release, and when you may say you implement HCP.

HCP is an open specification kept by its maintainers in three repositories.
Editorial fixes merge directly, and every normative change goes through an RFC
so the reason for each rule stays on record; to propose one, open an issue
titled `RFC idea: <title>` on `hcp-protocol`.

## Repositories

| Repository | Holds | Licence |
|------------|-------|---------|
| `hcp-protocol` | Normative specification, RFCs, conformance vectors | Apache-2.0 |
| `hcp` | Reference SDK, the `hcpx` CLI, gold packs, executable conformance | MIT |
| `hcp-docs` | This site | Apache-2.0 |

The specification in `hcp-protocol/spec` is the source of truth. This site's
[Specification](/docs/specification) section is regenerated from it, so where
the two differ, the repository wins. Security reports follow
[Security](/docs/community/security), and everything else goes in an issue on
the repository it concerns.

## Roles

| Role | Does | How you become one |
|------|------|--------------------|
| Contributor | Opens issues, PRs and RFCs | Open one |
| Maintainer | Reviews and merges in one repository; triages RFCs | Sustained contribution; nominated by maintainers |
| Spec editor | Owns the text of `spec/`; lands RFC decisions verbatim | Appointed by maintainers |
| Steering | Resolves disputes; approves major versions; owns the roadmap | The founding maintainers at first; expands with implementers |

Once two conforming runtimes exist, the plan is for steering to include at least
one independent runtime implementer.

## Decision making

1. Any maintainer may merge an editorial change: a typo fix or a clarification
   that keeps the meaning.
2. A normative change needs an accepted RFC.
   [When you need an RFC](#when-you-need-an-rfc) lists what counts.
3. A minor version is an accepted RFC that adds optional fields or tightens
   lints, with two maintainer approvals.
4. A major version is an accepted RFC that changes meaning or removes fields,
   with steering approval and a migration note.
5. Disputes run on lazy consensus for seven days and then go to steering, which
   decides by simple majority and records its reasoning in the RFC.

These principles from [Design principles](/docs/introduction/design-principles)
are constitutional, so changing one takes a major version:

- The pack is the unit, and a pack is three files.
- Packs declare; runtimes decide.
- No credentials in packs.
- Sense never executes.
- Sandbox by default.
- Vendor-neutral text.

## RFC process

### When you need an RFC

You need one to add, remove or change the meaning of a field in
`surface.json` or `policy.json`, to add or change a MUST, SHOULD or MAY in the
[Specification](/docs/specification), to add a capability, Binding mode,
adapter kind or land, or to change the exec or result envelope, a lifecycle
stage or an availability flag. Typo fixes, clearer prose, new examples, new
informative sections and SDK-only changes that leave conformance alone need
none.

### Before writing

1. Search the existing RFCs in `hcp-protocol/rfcs/`.
2. Check the [non-goals](/docs/introduction/design-principles#non-goals). If
   your proposal touches one, say so and argue the cost of that boundary.
3. Open an issue titled `RFC idea: <title>` to test interest. Two thumbs from
   maintainers, or one from an implementer, is enough to go ahead.

### Template

Copy `rfcs/0000-template.md` to `rfcs/NNNN-<kebab-title>.md`:

```md
# RFC NNNN — <Title>

- **Status:** Draft
- **Authors:**
- **Replaces:**            <spec section or prior RFC, if any>
- **Tracking:**            <issue link>

## Summary
One paragraph.

## Motivation
What breaks today. Evidence: a pack, a runtime, or a corpus.

## Specification
Normative text, using RFC 2119 keywords, written so it can be pasted into spec/.

## Conformance
Which vectors change or are added (§14.5).

## Compatibility
Minor or major? What happens to 1.x packs and runtimes?

## Drawbacks

## Alternatives
```

The Specification section must be spec text you can paste as it stands, every
new MUST needs at least one conformance vector, and the RFC states its version
impact.

### Lifecycle

```text
Draft ──▶ Review ──▶ Final comment (7 days) ──▶ Accepted ──▶ Implemented ──▶ Active
   │          │                                     │
   └──────────┴───────────── Rejected / Withdrawn ──┘
```

| Status | Meaning |
|--------|---------|
| Draft | PR open; author iterating |
| Review | A maintainer is sponsoring; discussion on the PR |
| Final comment | Seven days; any maintainer may object with reasons |
| Accepted | Merged into `rfcs/`; spec editor lands text in `spec/`; docs regenerate |
| Implemented | Reference SDK ships it; vectors pass |
| Active | Released in a protocol version |
| Rejected | Closed with reasons recorded in the RFC |
| Withdrawn | Closed by the author |

An RFC is accepted when it leaves Final comment with no unresolved objection
and the approvals [Decision making](#decision-making) sets for its version.
Its conformance vectors then go into `packages/sdk/src/conformance.test.ts`,
[Versioning §13.5](/docs/specification/versioning) lists the change, and the
RFC's status is updated in place.

### Accepted RFCs

| RFC | Title | Version | Status |
|-----|-------|---------|--------|
| 0001 | Wrap hardening: named commands, installer family, land `local`, confirm | HCP/1.1 | Accepted, Implemented |
| 0003 | Wrap exec plane: `wrap.workspace` and the local driver | HCP/1.1 | Accepted, Implemented |
| 0008 | HCP/1.1 errata and the `write_stimulus` lint | HCP/1.1 | Accepted, Implemented |

The [Roadmap](/docs/community/roadmap) tracks the drafts and open proposals.

## Vendor neutrality

The specification names roles (host, runtime, hub), never products, and no
company holds a special position in its text. Host guides under
[Adopt in hosts](/docs/hosts) document integration, so they may name products
as examples.

## Trademark

"Harness Context Protocol" and "HCP" as applied to this protocol, the `hcpx_`
wordmark and the `h_` symbol identify the project and conforming
implementations. You may say your implementation "implements HCP/1.1" once it
passes [§14](/docs/specification/conformance), and you may not imply
endorsement.

## Sitemap

- [Documentation](https://harnesscontextprotocol.io/docs)
- [Packs](https://harnesscontextprotocol.io/packs)
- [Glossary](https://harnesscontextprotocol.io/docs/reference/glossary)
- [llms.txt](https://harnesscontextprotocol.io/llms.txt)
- [llms-full.txt](https://harnesscontextprotocol.io/llms-full.txt)
- [OpenAPI](https://harnesscontextprotocol.io/openapi.json)
- [MCP](https://harnesscontextprotocol.io/mcp)