Stewardship
ACC is maintained as an implementation-neutral contract. It should not depend on one runtime's database tables, UI concepts, deployment model, or product packaging.
GOVERNANCE
ACC is maintained as an open contract.
The specification should remain small, stable, implementation-neutral, and useful across different A2B runtimes.
Versioning
Patch releases clarify wording and examples. Minor releases add optional fields or non-breaking behavior. Major releases change required semantics or schema meaning.
Extensions
New core fields should affect portable runtime governance, be testable, and not require runtimes to understand business-specific authorization logic. Passing the admission gate makes a proposal reviewable, not automatically accepted.
Claims
Implementations may say they implement ACC v1. They should not imply official certification unless a formal certification program exists.
Neutrality
No product defines ACC semantics or receives privileged registry criteria, roadmap influence, compatibility status, or commercial endorsement.
Evidence
One implementation may motivate guidance, but normative behavior requires portable, testable semantics that do not depend on its private architecture.
CONTRIBUTION MODEL
Contract changes need stronger justification than examples.
ACC core fields should remain small and stable. Business-specific metadata belongs in standard OpenAPI fields, operation-level business extensions, or runtime-specific extension fields unless it becomes portable governance metadata.
recommended attribution
ACC (Agent Capability Contract),
first published by the BailingHub project.
Implements the ACC v1 Runtime Profile.