Governance

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#

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

Roles#

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 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 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, 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. 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:

# 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#

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

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

Accepted RFCs#

The 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 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, and you may not imply endorsement.