Skip to main content

Documentation Index

Fetch the complete documentation index at: https://agentvolumes.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Agent Volumes depends on implementers, reviewers, security researchers, documentation contributors, and standards participants. You can help by testing the current release candidate, finding ambiguous requirements, proposing clearer language, or building tools that expose gaps in the specification. This page summarizes the organization-wide contribution, security, and community policies for specification contributors. The canonical policy documents remain the Agent Volumes organization files on GitHub:
The public documentation site is an orientation layer. The canonical specification sources remain the repository artifacts, including agent-volumes-spec.md, schemas/, openapi/, conformance/, and the organization policies linked above.

​
Choose the right contribution path

Security vulnerabilities must be reported privately through GitHub Security Advisories or security@agentvolumes.org. Do not include exploit details, reproduction steps, or sensitive impact analysis in public GitHub Issues or Discussions.

Report a spec issue

Use GitHub Issues for problems, ambiguities, missing requirements, broken links, and proposed changes to the specification repository.

Discuss open design questions

Use GitHub Discussions for broader design questions, early feedback, and topics that need exploration before a concrete proposal.

Build from the artifacts

Implementers can use the guide for clients, bibliothecas, validators, exporters, and runtime adapters, then report interoperability feedback.

Report a vulnerability

Use private security reporting channels for vulnerabilities. Do not open a public issue for security-sensitive findings.

List adoption or evaluation

Projects evaluating or adopting the standard can open an issue or pull request against ADOPTERS.md.

​
How specification changes work

Specification changes follow a lightweight proposal process:
1

Open an issue for material changes

Describe the problem, the proposed change, and the affected sections or artifacts. Open an issue first for new sections, new component types, behavioral changes, or modifications to normative requirements.
2

Discuss the proposal

Work with maintainers and community members to refine the scope. Use discussion to separate normative requirements from implementation-local choices.
3

Submit a pull request

Target main, because the project follows trunk-based development. All work happens from a fork rather than a branch on the main repository.
4

Respond to review

Specification changes require maintainer review. Update prose, schemas, OpenAPI, conformance fixtures, or supporting documentation together when the change crosses artifact boundaries.
Editorial fixes such as typos, grammar corrections, formatting changes, and broken-link fixes can be submitted directly as pull requests without a prior issue.

​
Before you open a pull request

  • Read the current release archive and the canonical source files that your change affects.
  • Preserve BCP 14 usage in normative prose: use MUST, SHOULD, and MAY only when the requirement carries that normative meaning.
  • Define new terms on first use and keep terminology consistent with the glossary and release archive.
  • Keep schema, OpenAPI, conformance fixtures, and prose aligned when a change affects more than one artifact.
  • Sign off every commit for the Developer Certificate of Origin (DCO).
Signed-off-by: Your Name <your.email@example.com>
You can add the sign-off with git commit -s.

​
Route issues to the right place

TopicWhere to go
Specification bugs, ambiguity, or proposalsagent-volumes/agent-volumes-spec issues
Open-ended specification design questionsagent-volumes/agent-volumes-spec discussions
Organization policy or governanceagent-volumes/.github issues
TSC, Working Group, or future member-company participationGovernance Proposal template in agent-volumes/.github
Adopter listing requestsADOPTERS.md in the specification repository
Implementation bugsThe affected implementation repository, such as shelf or alexandria when available
Unsure where to goRouting Help template in agent-volumes/.github
Adopter listings and implementation feedback help prioritize the standard. They do not create certification, trademark authorization, hosted-service approval, or special normative status.

​
Report security issues privately

Do not open a public issue for a security vulnerability. Use one of these private reporting paths: Include the affected repository and version or commit, the vulnerability impact, reproduction steps or proof of concept, and any suggested mitigation. The organization acknowledges reports within 3 business days, performs triage within 7 business days, and provides progress updates at least every 7 business days until closure.
Avoid denial-of-service testing, social engineering, destructive testing, and public disclosure before coordinated disclosure is complete. Good-faith research that follows the security policy is covered by the project’s safe harbor.

​
Participate respectfully

All project spaces follow the Contributor Covenant 3.0 Code of Conduct. The project expects contributors to engage kindly and honestly, respect different viewpoints, accept constructive feedback, credit sources, and help repair harm when it occurs. To report a possible Code of Conduct violation, email conduct@agentvolumes.org. Community Moderators handle reports privately while prioritizing safety and confidentiality.

​
Next steps

Read the release archive

Review the current release candidate before filing feedback or proposing text.

Study core concepts

Learn the vocabulary for volumes, bibliothecas, package identity, trust, and conformance.

Build an implementation

Turn the release artifacts into a client, bibliotheca, validator, exporter, or runtime adapter.

Open a specification issue

Share ambiguity, gaps, editorial fixes, or proposal ideas with the specification maintainers.