This page describes how the CARL Standard itself is governed. For governance of the CARL project (maintainers, PR process, code ownership), see /governance/ownership/ and /governance/contributing/.

Maintaining entity

The CARL Standard is maintained by Wentzel.ai. Wentzel.ai holds the trademarks, domain names, and final decision authority on changes to the standard, the reference implementations, and the governance process itself.

CARL's source, spec, and prompts are proprietary to Wentzel.ai — all rights reserved, with no open-source license grant in effect today (see License). Contributions are accepted from authorized contributors — Wentzel.ai staff and invited collaborators — with a DCO sign-off; there is no separate CLA for authorized contributors, but being authorized is a prerequisite. It is not a multi-stakeholder foundation at this time. Earlier plans contemplated an openly-licensed model with contributions welcomed from anyone; that plan is not in effect today. Wentzel.ai MAY open-source CARL and/or transition governance to a neutral foundation in the future; no such transition is committed.

Versioning

The standard uses semver adapted for specifications:

• Major bump — normative changes that break existing conformance. A claim against the old version is not automatically a claim against the new version.
• Minor bump — additive changes (new criteria, new pillars) that are backward-compatible for existing claims. Subjects assessed against the old version may stay claimed against it, or choose to re-assess against the new version.
• Patch bump — editorial corrections and non-normative clarifications. Does not invalidate existing claims.

Conformance claims MUST reference the specific version they were assessed against. See conformance claims.

Catalog versioning (independent)

The criteria catalog is versioned independently from the standard. Non-breaking catalog changes (additions, clarifications) ship as catalog patch releases (v1.0.x) without a standard version bump. Changes that would alter an assessed subject's level require a minor version bump to the standard.

Lifecycle

Every version of the standard moves through these stages in order:

1. Working Draft. Under development in spec/drafts/. May change substantially. Not citable for conformance claims.
2. Candidate. Published at the canonical URL with a 60-day public review period. Feedback accepted via GitHub issues. MAY be cited but MUST NOT be used for conformance claims.
3. Ratified. The authoritative version. Usable for conformance claims. Stable for the lifetime of the version line.
4. Superseded. A newer ratified version exists. The superseded version remains published and citable for historical context; existing claims against it remain valid.
5. Withdrawn. Removed from conformance-claim eligibility. Kept in the archive for traceability. New claims MUST NOT be made against a withdrawn version.

v1.0 is currently a First Draft — it has not yet been ratified.

Contribution model

Contributions are coordinated by the CARL maintainers at Wentzel.ai — email hello@wentzel.ai to propose a change.

Every commit MUST include a Signed-off-by trailer (git commit -s) certifying the Developer Certificate of Origin. CI enforces. No CLA is required.

What contributors may propose

• Editorial polish (typos, clarifications that don't change normative meaning) — a PR to the spec source file suffices.
• New criteria for the catalog — open an issue first to discuss scope, then PR. If the criterion would change existing subjects' levels, it targets a minor version of the standard; otherwise it can ship in a catalog patch release.
• Revised rationale or evidence expectations for existing criteria — editorial if non-normative, minor version if the change affects applicability decisions.
• Structural changes to the standard (pillars, levels, methodology) — a major version bump. Start with a design doc in an issue.

Patent non-assertion

The standard is published with a patent non-assertion covenant (see the spec's Appendix C). Contributors to the spec grant the same covenant for any patent claims they own or control that would be necessarily infringed by a conformant implementation of their contribution.

Decision-making

Day-to-day decisions — individual PRs, triage, editorial polish — are made by maintainers. Strategic decisions — major version bumps, pillar or level restructuring, re-levelling of criteria that would change assessed subjects' levels, license changes, governance transitions — are owner decisions, typically after public discussion on GitHub.

Disagreement is welcomed at the issue or PR level. The owner's decision stands once articulated, but MAY be revisited in writing with new information.

Related

• Project governance — roles, maintainers, and project-level decision making.
• Contributing — how to submit a PR against CARL.
• Changelog — release notes for the standard and the tooling.