Governance

This document defines the organizational structure, decision-making processes, and change management policies for the Automotive Commerce Protocol. It is intended to be permanent and stable. Changes to this governance document require a supermajority vote of the Steward Council.

ACP Foundation

The Automotive Commerce Protocol is maintained by the ACP Foundation, a vendor-neutral body responsible for the specification, schema, reference implementations, and certification program. The Foundation does not produce commercial software. It produces and maintains an open standard.

The Foundation's responsibilities are:

1. Maintain the ACP specification and JSON Schema.
2. Manage the RFC process for proposed changes.
3. Publish reference implementations and validation tools.
4. Administer the ACP Conformance certification program.
5. Resolve disputes regarding interpretation of the specification.

ACP was initiated and architected by Jamil Ashkar as part of ongoing work to modernize automotive transaction infrastructure.

Vendor Neutrality

The ACP Foundation operates independently of any single vendor, platform, or commercial interest. The specification defines a data interchange format. It does not endorse, require, or prefer any specific AI provider, CRM system, DMS platform, or implementation approach.

No vendor may claim exclusive ownership of, or privileged access to, the ACP specification or its governance process. All specification development occurs in public repositories under open-source licenses.

Foundation stewards who are employed by companies with commercial interests in the automotive AI or CRM space must disclose those affiliations. Stewards must recuse themselves from votes where a direct conflict of interest exists.

Stewards

The specification is maintained by a Steward Council consisting of 3–7 individuals. Stewards are responsible for reviewing RFCs, maintaining the schema, and making final decisions on specification changes.

Role	Responsibility	Term
Lead Steward	Sets agenda, breaks tie votes, serves as public representative of the Foundation.	2 years, renewable once.
Steward	Reviews RFCs, participates in votes, contributes to schema maintenance.	2 years, renewable.
Emeritus Steward	Former stewards who retain advisory status but no voting rights.	Permanent.

New stewards are nominated by existing stewards and approved by a two-thirds majority vote of the current council. Stewards may be removed by a three-quarters majority vote for cause, including inactivity (no participation in 6+ months), undisclosed conflicts of interest, or conduct violations.

Advisory Board

The Advisory Board consists of representatives from organizations that produce or consume ACP envelopes. Board members provide input on specification direction but do not have voting rights on RFCs.

Advisory Board seats are open to:

• CRM vendors that have implemented or committed to implementing ACP receivers.
• AI platform providers that produce ACP envelopes.
• Dealership groups with 10+ locations that consume ACP data.
• DMS vendors that integrate with ACP-compliant systems.
• Academic or research organizations studying automotive commerce data standards.

Advisory Board membership is reviewed annually. There is no fee to participate.

Versioning Policy

ACP follows Semantic Versioning 2.0.0. The version string in acp.version consists of MAJOR.MINOR.PATCH.

Component	Change Type	Compatibility
MAJOR	Breaking structural change. Removal of required fields, restructuring of top-level objects, changes to envelope semantics.	Not backward compatible. Requires migration.
MINOR	New optional fields, new event types, new enum values, new optional top-level objects.	Backward compatible. Existing receivers continue to function.
PATCH	Clarification of existing language, typo corrections, documentation improvements. No schema change.	Fully compatible. No implementation changes needed.

The following actions are prohibited in minor versions:

• Adding new required fields to existing objects.
• Removing existing fields.
• Changing the type of existing fields.
• Narrowing enum values (removing accepted values).
• Changing additionalProperties from true to false.

These actions require a major version increment and the full breaking changes process described below.

Backward Compatibility

Receivers compliant with version X.Y.Z must accept any envelope with the same major version X, regardless of minor or patch version differences. This means:

• A v1.0 receiver must accept v1.1 envelopes without error.
• A v1.0 receiver must ignore unknown fields added in v1.1.
• A v1.0 receiver must ignore unknown event types added in v1.1.
• A v1.0 receiver must ignore unknown intent types added in v1.1.

Producers targeting v1.1 may include v1.1 fields, but must not assume receivers understand them. Producers should document which version they target.

Deprecation Policy

Fields, event types, and enum values follow a structured deprecation process:

No field, event type, or enum value may be removed without completing all three steps.

RFC Process

All changes to the ACP specification, including new fields, new event types, behavioral clarifications, and governance amendments, are proposed through a Request for Comments (RFC) process.

Who May Submit an RFC

Any individual or organization may submit an RFC. There is no membership requirement. RFCs are submitted as pull requests to the AutomotiveAI-INC/ACP GitHub repository in the /rfcs directory.

RFC Format

Each RFC must include:

1. Title — A concise description of the proposed change.
2. Status — Draft, Review, Final, Rejected, or Withdrawn.
3. Authors — Names and affiliations of the proposers.
4. Summary — A one-paragraph description of the change.
5. Motivation — Why this change is necessary. What problem does it solve.
6. Specification — The exact schema and documentation changes proposed.
7. Backward Compatibility — Analysis of impact on existing implementations.
8. Alternatives Considered — Other approaches that were evaluated and why they were rejected.

RFC Lifecycle

The minimum time from Draft to Final is 45 days. This ensures adequate review time for all stakeholders. Emergency security patches may follow an expedited 7-day process with unanimous steward approval.

Voting & Approval

Change Type	Approval Threshold	Comment Period
Patch (clarification)	Simple majority of Steward Council (>50%).	14 days.
Minor (new optional field)	Two-thirds majority of Steward Council (≥67%).	30 days.
Major (breaking change)	Three-quarters majority of Steward Council (≥75%) + Advisory Board consultation.	60 days.
Governance amendment	Three-quarters majority of Steward Council (≥75%).	60 days.

Votes are recorded publicly in the RFC pull request. Stewards must provide a written rationale for their vote. Abstentions are permitted but do not count toward the threshold denominator.

If a vote fails, the RFC may be revised and resubmitted after a 30-day waiting period. An RFC that fails three times is archived and may not be resubmitted for 12 months.

Breaking Changes Policy

Breaking changes are changes that would cause a conformant vN receiver to reject or misinterpret a vN+1 envelope. The following are classified as breaking:

• Adding new required fields to existing objects.
• Removing existing required or optional fields.
• Changing the type of an existing field.
• Changing the semantics of an existing field (same name, different meaning).
• Restructuring top-level objects.
• Removing enum values from existing enumerations.

Breaking changes require the full major-version RFC process: 60-day comment period, 75% steward approval, Advisory Board consultation, and a published migration guide.

Migration Window

When a major version is approved, the following timeline applies:

Milestone	Timeline	Action
T+0	Major version published.	New schema, specification, and migration guide released simultaneously.
T+90 days	Dual-version period begins.	Producers should support both versions. Receivers must accept both.
T+180 days	Previous version deprecated.	Producers should default to new version. Previous version still accepted.
T+365 days	Previous version sunset.	Receivers may reject previous version. Conformance certification requires new version.

These timelines are minimums. The Steward Council may extend them based on adoption metrics.

Sunset Policy

A sunset version is one that conformant implementations are no longer required to support. Before a version is sunset:

1. A migration guide must have been published for at least 180 days.
2. At least 80% of known active producers must have migrated (measured by envelope version distribution reported to the Foundation).
3. The Steward Council must issue a formal sunset notice 90 days in advance.

If the 80% threshold is not met at T+365, the sunset is deferred in 90-day increments until the threshold is reached or the Steward Council votes to override with a three-quarters majority.

Licensing

Specification License

The ACP specification text, including all documentation on acpspec.org, is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0). Anyone may copy, redistribute, remix, and build upon the specification for any purpose, including commercial use, provided attribution is given to the ACP Foundation.

Schema License

The ACP JSON Schema file (acp-schema-v1.0.0.json) and all machine-readable artifacts are licensed under the Apache License 2.0. This permits unrestricted use, modification, and distribution in both open-source and proprietary software.

Reference Implementations

All reference implementations, validation tools, and code examples published by the ACP Foundation are licensed under Apache License 2.0.

Contributions

By submitting an RFC, pull request, or other contribution to the ACP specification or its reference implementations, contributors agree to license their contribution under the same terms as the receiving project (CC BY 4.0 for specification text, Apache 2.0 for code and schema).

Patent Policy

The ACP specification defines a data interchange format. It describes the structure and semantics of ACP envelopes. It does not define the internal methods by which producers generate, score, analyze, or construct envelope contents. Those methods are implementation-specific and outside the scope of this specification.

Contributors to the specification grant a royalty-free, worldwide, non-exclusive patent license for any patents that are necessarily infringed by implementing the specification as written. This license applies only to the specification itself — it does not extend to implementation-specific methods, algorithms, or systems that produce or consume ACP envelopes.

The ACP Foundation does not require patent disclosure from Advisory Board members or users of the specification. The specification is designed to be implementable without infringing any known patents.

Trademarks

"ACP", "Automotive Commerce Protocol", and the ACP logo are trademarks of the ACP Foundation. Use of these marks is permitted in the following contexts:

• Describing compatibility: "Compatible with ACP v1.0" or "ACP v1.0 Conformant."
• Referencing the specification: "Implements the Automotive Commerce Protocol."
• Documentation and educational materials.

Use of ACP trademarks to imply endorsement by or affiliation with the ACP Foundation requires written permission. The "ACP Conformant" mark may only be used by implementations that have passed the conformance certification process.