How the project is governed
ANS separates project-wide governance from day-to-day technical maintenance. The Charter defines the project’s governance, and the Governance document defines how decisions, reviews, and releases work.
- Technical Steering Committee (TSC): sets project-wide technical direction, handles governance and project proposals, resolves escalated disputes, and appoints maintainers where a repository has none.
- Maintainers: are responsible for individual repositories. They review and merge changes, maintain releases and CI, handle security reports, and mentor contributors.
- Reviewers: provide technical review in their repository or area. Their approvals count toward review requirements; merge responsibility remains with the repository’s maintainers.
- Contributors: open issues, submit changes, review work, improve documentation, and participate in discussions. You do not need a formal role to contribute.
TSC membership does not automatically make someone a maintainer or grant merge authority across the project’s code and specification repositories. The governance repository has its own TSC review and merge responsibilities.
Technical Steering Committee
The initial TSC has five voting members, listed alphabetically by surname. Members serve as individuals; affiliations are listed for transparency.
| Member | Affiliation |
|---|---|
| Scott Courtney | GoDaddy |
| Ken Huang | DistributedApps.AI |
| Michael Kantor | Hashgraph Online (HOL) |
| Keith Perry | GoDaddy |
| Connor Snitker | GoDaddy |
The TSC elects its Chair and Vice Chair. Membership, appointments, and terms are recorded in the TSC roster. The charter defines elections, eligibility, and organization-representation limits.
Who maintains each repository
Use the relevant repository’s issues and pull requests for technical work.
The maintainer index
identifies the responsible teams; repository ownership records and CODEOWNERS
provide local details and review routing.
| Area | Repository | Responsible team |
|---|---|---|
| ANS specifications and schemas | ans-spec | Specification maintainers |
| Registration Authority, Transparency Log, and verifier | ans | Reference implementation maintainers |
| Go SDK and CLI | ans-sdk-go | Go SDK maintainers |
| Rust SDK | ans-sdk-rust | Rust SDK maintainers |
| Java SDK | ans-sdk-java | Java SDK maintainers |
| Gateway authentication | ans-gateway-auth | Gateway authentication maintainers |
| OpenShell integration | ans-openshell | OpenShell integration maintainers |
| Trust evaluation specification | trust-index-spec | Trust Index specification maintainers |
| Trust discovery implementation | agent-trust-discovery | Trust discovery maintainers |
The maintainer index also covers CLI distribution repositories and project administration. The contributor ladder explains how people become members, reviewers, and maintainers.
How changes are reviewed
Changes go through pull requests with explicit review, required checks, and Developer Certificate of Origin sign-offs. A repository maintainer merges ordinary technical changes. Silence does not count as approval of code or specification text.
Changes to normative specification requirements, public interfaces, verification logic, and release tooling have additional review requirements. Some project-wide changes also require a proposal. The governance document defines the exact specification review rules and code review rules.
Decisions and participation
Project decisions are discussed in public and recorded with their rationale and outcome. Start a governance question or proposal in the governance issue tracker. Consult the proposal process and decision records for the formal process and recorded outcomes.
There is no standing meeting schedule. When a TSC or maintainer meeting is called, an issue announces it at least seven days ahead with an agenda. Meetings are open by default, with recordings and notes linked afterward. The governance document defines narrow exceptions for confidential matters.