Protocol Changelog

This changelog records released Supply-Y wire contracts and the customer action required by each change. It does not promote supporting Skills, SDKs, discovery documents or installers to the Protocol version. Their versions and availability remain independent.

The machine-readable companion is /protocol/releases.json. Verify the exact Manifest digest from that index before adopting a release.

Protocol 1.0

• Published: 2026-07-14
• Status: Stable
• Change class: First stable major release
• Wire identifier: supply-y/1.0

Protocol 1.0 establishes the stable Agent-to-Agent interoperability boundary for exchanging bounded, encrypted supply-chain decisions. The immutable Release Manifest pins 15 artifacts by URL, byte count and RFC 9530 SHA-256 digest. The public Agent Bundle carries 55 exact implementation and conformance files without requiring repository access.

Added

• six business-object contracts plus one shared JSON Schema definition file;
• the 21-operation Agent API reference contract and 29 validated API examples;
• the Native encrypted Package profile with two-recipient key wrapping and sender signatures;
• Package, Response, Thread, Policy, Network Story and Audit lifecycle semantics;
• signed Policy Receipts that bind local disclosure claims to one encrypted Package digest;
• signed webhook delivery, durable recovery, retry, ordering and acknowledgement rules;
• Native and Catena-X transport mappings with one Package payload per exchange;
• compatibility, migration, security and Safe Agent requirements;
• immutable release and one-fetch Agent Bundle contracts.

Changed from the preview line

• the wire identifier changed from supply-y/0.1 to supply-y/1.0;
• core object and Policy Envelope fixtures moved to schema version 1.0.0;
• Policy Receipts moved to receipt version 1.0.0;
• signatures, authenticated metadata, receipts and dependent digests were regenerated against the stable version binding.

Migration required

A Protocol 1.0 receiver must reject supply-y/0.1. It must not rewrite an old preview Package in place, infer compatibility from similar fields or preserve an old signature after changing the version. A sender migrating preview data must create a new 1.0 object, validate it, regenerate the Policy Receipt, encrypt it again and sign the new exchange envelope.

Read the complete Versioning and Compatibility guide before accepting production-shaped traffic.

Availability boundary

Stable describes the published wire contract, not every service around it. At Protocol 1.0 publication, hosted production APIs, production Skill signing trust, registry SDK distribution, independent partner interoperability and production certification were not generally available. Review the live Availability and Readiness matrix for current implementation status.

Retired pre-stable identifier

supply-y/0.1 was a preview identifier used before the first stable release. It is not a supported Protocol release, has no current immutable Release Manifest and is not accepted by a Protocol 1.0 receiver. Its replacement is supply-y/1.0.

How future entries will be published

Every future Protocol release entry will state the publication time, compatibility class, exact Manifest URL and digest, migration requirement, security impact, deprecation window and customer action. Breaking changes require a new major Protocol version. Published versioned artifacts are never edited in place.

Documentation corrections that do not change accepted wire behavior may update live guides without creating a Protocol release. Any change to what an implementation accepts, rejects, discloses or does requires versioned executable evidence and a new changelog entry.