Every company that ships software, publishes an API, or maintains terms of service creates a stream of changes that downstream consumers need to know about.
Today there is no universal system for communicating those changes. Changelogs are scattered across GitHub releases, blog posts, migration guides, and Slack channels. There is no consent-based push channel from publisher to subscriber. There is no structured format that a developer, an AI agent, or a compliance workflow can consume without parsing natural language.
The result is predictable: developers miss breaking changes. Enterprise teams have no audit trail for vendor changes. Vendors have no reliable outbound channel that reaches the people who depend on their decisions.
This is a solvable problem. The software industry has solved analogous problems before:
- CloudEvents standardized event format and transport, enabling interoperability across messaging systems.
- OpenAPI standardized HTTP API description, enabling tooling ecosystems to emerge.
- Standard Webhooks standardized webhook delivery signing, enabling consistent security practices.
- The Model Context Protocol standardized how AI systems connect to tools and data sources.
In each case, standardization did not limit what was possible. It expanded the ecosystem by reducing the friction of interoperability.
We are calling for the same approach to software change communication.
ChangeSpec 1.0 is a proposed open standard for communicating software changes from producers to consumers. A ChangeSpec event is a JSON object with a structured taxonomy of change categories, severity levels, and source attribution. It is designed to be consumed by humans, by RSS readers, by compliance workflows, and by AI agents equally. It carries enough information for a recipient to decide whether action is required without reading natural language prose.
The spec is published under the Apache 2.0 license. The reference implementations are MIT licensed. The vendor registry is open. We are not asking for permission to build this. We are asking for others to help make it a real standard by using it, implementing it, and signing their name to this letter.
If you believe that software change communication should be structured, machine-readable, and interoperable - we invite you to sign below.
Steve Leggett
Founder, Roboticforce Inc.
April 2026