Open standard

Governance

How ChangeSpec is maintained, evolved, and licensed.

Who is behind ChangeSpec

ChangeSpec is authored and maintained by Roboticforce Inc. (Steve Leggett, founder). The specification is published under the Apache 2.0 license.

Roboticforce Inc. operates the ChangeSpec.com web index, the reference implementations, and the vendor registry. The spec itself is in a public GitHub repository under the changespec organization, and contributions are governed by the process described below.

The long-term intent is to transfer stewardship of the specification to a neutral standards body or foundation once the spec has demonstrated adoption. The CloudEvents project's path through CNCF is the reference model. This is not a commitment on a timeline - it is a stated direction.

License

The ChangeSpec specification text, JSON Schema, and all normative materials are licensed under the Apache License, Version 2.0.

This means you may freely use, modify, distribute, and build upon ChangeSpec without restriction, including in commercial products, without requiring permission or attribution beyond the license terms.

The reference implementations are licensed under the MIT License.

SPDX identifier
SPDX-License-Identifier: Apache-2.0

Contributing to the spec

Contributions to the specification take the form of GitHub Issues and Pull Requests on the changespec/spec repository.

Types of contributions

Clarifications and editorial fixes
Typos, unclear language, and inconsistencies in the existing text. Submit as a PR with a description of the ambiguity being resolved. No RFC required.
New optional fields
Proposals for new optional fields added in a minor release. Submit a GitHub Issue with: the field name, type, semantics, use case motivation, and at least two examples. Maintained by the working group with a 30-day comment period.
New category or severity values
Proposals to extend the category or severity taxonomy. Same process as optional fields. Must not redefined existing values.
New namespace registrations
Submit a PR adding your namespace to namespaces.yml with the namespace name, package registry URL, and a rationale. Merged on review without a comment period for non-conflicting additions.
Breaking changes (major version proposals)
Proposals requiring a major version bump. Must be filed as an Issue marked major-proposal at least 12 months before any target release date. Requires consensus from active implementers.

Decision process

For minor releases: decisions are made by the spec maintainer (Roboticforce Inc.) with input from a working group of active implementers. The working group forms organically as implementations mature. Current working group members are listed in GOVERNANCE.md in the spec repository.

For major releases: consensus-based. No major release proceeds without documented agreement from at least three independent implementations.

Versioning commitment

ChangeSpec follows the versioning rules defined in Section 11 of the specification. In plain terms:

  • Patch releases (1.0.1): Clarifications and typos only. No behavior changes. Published without advance notice.
  • Minor releases (1.1): New optional fields and extended enums. Backward compatible. Announced at least 30 days before release with a draft for comment.
  • Major releases (2.0): Breaking changes only. Minimum 12-month deprecation period for 1.x. Published with a migration guide.

The current spec version is 1.1. v1.1 adds the retraction category, do_not_install, provenance_invalidated, last_known_good_version, and signing key separation requirements (Section 7.6). Feedback from implementers and the community will drive the 1.2 roadmap.

ChangeSpec 1.0 events are valid for the lifetime of the 1.x series. Consumers built against 1.0 will continue to work when receiving 1.1 or 1.2 events from producers, per the backward compatibility rules.

Trademark policy

"ChangeSpec" is a name used by Roboticforce Inc. for this specification and its reference implementations. We have not registered a trademark. The following uses are welcome without any approval:

  • Describing conformance with the specification ("compatible with ChangeSpec 1.0")
  • Naming a library that implements the specification ("changespec-go", "changespec-py")
  • Academic, educational, and non-commercial reference

The following require written approval from Roboticforce Inc.:

  • Use of "ChangeSpec Certified" in product names, marketing materials, or compliance attestations
  • Use of the ChangeSpec name in a way that implies official endorsement by Roboticforce Inc.
  • Domain registrations using the ChangeSpec name

"ChangeSpec Certified" is a reserved mark. A certification program for compliant implementations is under development. Contact [email protected] for inquiries.

Vendor registry

The ChangeSpec vendor registry maps no-namespace vendor IDs (e.g., anthropic, stripe) to canonical vendor identities. The registry prevents ID collisions between different entities using the same common name.

To register a vendor ID, open a Pull Request adding an entry to registry/vendors.yml in the spec repository. Include: the vendor ID, the canonical legal entity name, the official domain, and a contact email. Registry submissions are reviewed within 5 business days.

The registry is append-only. Vendor IDs, once assigned, are not reassigned.

Contact