How the A3IP specification, reference toolchain, and public registry are maintained. Read this before opening an issue, proposing a change, or asking who decides what.
This document is honest about the current stage of the project: A3IP is single-maintainer as of this writing. The governance described below is the model the project commits to as it grows; today most roles are filled by one person. Where the future-state model differs from the current-state model, both are stated explicitly.
Maksym Prydorozhko (@maksymprydorozhko) — author of the specification, maintainer of the reference toolchain (a3ip CLI, a3ip-creator), and current sole gatekeeper of the public package registry.
Contact: open a GitHub issue in the relevant repo (see Repositories below). Direct email is intentionally not the channel — issue tracking keeps the project’s record public.
A long-term goal is to transition maintenance to a Dutch Stichting (foundation) once the project has demonstrable adoption and at least three independent implementations of the spec. Until then, treat the maintainer’s voice as the project’s voice.
Different change types use different paths. The discriminator is whether the change affects how compliant tools must behave.
Anything that changes what a compliant A3IP implementation MUST or MUST NOT do — adding required manifest fields, changing INSTALL.md semantics, renaming components, modifying the bundle format, etc.
Process:
a3ip-standard/spec titled [Proposal] <short description>. State the problem, the proposed change, and the motivating use case.Wording fixes, expanded examples, fixed-up references, typo corrections, additional rationale paragraphs.
Process: open a PR directly. No comment period. Maintainer merges if the change is genuinely non-normative.
a3ip CLI, a3ip-creator)The reference toolchain is versioned independently of the spec. CLI behavior may evolve faster than the spec; non-breaking CLI improvements don’t require spec changes.
Process: open a PR in the relevant repo (a3ip-standard/cli or a3ip-standard/creator). Maintainer reviews. If the change implies a spec change too, the spec PR happens first.
Anyone can submit a package to the public registry at a3ip-standard/packages.
Process: see CONTRIBUTING.md in that repo. Acceptance criteria: passes a3ip validate with zero errors, has a README explaining what the package does, is not company-specific (no internal URLs, no private API endpoints, no hardcoded team names).
A3IP follows semantic versioning with explicit semantics for each version dimension.
The CHANGELOG at the top of each spec version document names the breaking changes (if any) and the migration path.
Standard semver. Major = breaking CLI behavior; minor = new features; patch = bug fixes. The CLI declares which spec version it targets via __spec_version__; spec compatibility is independent of CLI version.
Same standard semver. Each Creator release pins its minimum CLI version via dependencies.tools.a3ip in its manifest.
Versioned independently. Sample A (ai-code-review-flow), Sample B (ai-research-workspace), and Sample C (ai-standup-assistant) each have their own version trajectory.
Current state (single-maintainer): Maksym Prydorozhko merges everything across all repos in the a3ip-standard organization. There is no separate review committee, no rotating quorum, no maintainer team.
Future state (when 3+ independent implementations exist): the project will form a steering committee with representation from at least 3 distinct implementers. The committee will set merge policy, with explicit roles for spec stewardship, toolchain maintenance, and registry curation. Until that threshold is reached, the future-state structure is aspirational — don’t cite it as current process.
Conflict of interest disclosure: the maintainer is also the primary author of the reference toolchain and the most-used packages in the registry. This is the normal state for an early open standard; it’s named here so participants can factor it into their engagement.
Specification text: Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You may read, implement, redistribute, and build on the spec freely with attribution. The spec is intentionally permissive: implementations are encouraged, alternative tooling is welcomed, and competing distributions of the same spec are allowed.
Reference toolchain (CLI, Creator, official adapters): Licensed under Apache 2.0. Includes an explicit patent grant. You may use the code in commercial products freely.
Sample packages (in a3ip-standard/packages): each package declares its own license in its manifest. The maintainer-authored samples are Apache 2.0.
Trademark “A3IP”: the name “A3IP” is in the process of trademark registration (EUIPO; USPTO filing planned post-launch). The pending trademark covers the project identity — implementations may describe themselves as “A3IP-compatible” without restriction, but should not use “A3IP” in a way that implies official endorsement or affiliation. See COMPATIBILITY.md for the trademark acknowledgements covering other standards we reference.
Logo: TBD. Will be released under the same trademark scope as the name.
In the current single-maintainer model, the maintainer is the final arbiter on every decision. This is documented honestly rather than disguised behind a process. Disagreements have these paths:
There is no escalation path beyond the maintainer until the future-state steering committee exists. Acknowledged limitation.
| Repo | What’s in it | Maintainer |
|---|---|---|
a3ip-standard/spec |
The spec text, JSON Schemas, COMPATIBILITY, GOVERNANCE, README | Maksym Prydorozhko |
a3ip-standard/cli |
The a3ip Python CLI (PyPI: pip install a3ip) |
Maksym Prydorozhko |
a3ip-standard/creator |
The reference authoring tool (a3ip-creator skill) |
Maksym Prydorozhko |
a3ip-standard/packages |
Public package registry: bundles + registry.yaml |
Maksym Prydorozhko |
A3IP Specification v1.10 · © 2026 Maksym Prydorozhko · a3ip.dev