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.

A publisher is an entity — an individual or an organization — that publishes volumes to a bibliotheca and owns one or more scopes or scopeless package names. Publisher identity is a registry-level concept: a publisher registers with a specific bibliotheca, and the bibliotheca manages what verification level that publisher has achieved. This is distinct from the content of the volume manifest, which only carries a declarative publisher identifier.

​
Declaring a publisher in volume.toml

Every volume.toml must include a [publisher] table with an id field: 
[publisher]
id = "acme"
For a scoped volume like @acme/research-agent-pack, the id identifies the owning scope. For a scopeless volume, it identifies the owner of the volume name. This field is declarative metadata only — it names who the publisher claims to be. Verification status is not stored in volume.toml and is not part of the manifest. It is managed exclusively by the bibliotheca.
A bibliotheca must reject a publish attempt where the authenticated publisher does not own the target namespace. The id field in volume.toml does not grant any authorization — it only provides a human-readable publisher identifier.

​
The three verification levels

A bibliotheca assigns one of three verification levels to each registered publisher:

Unverified

Email address confirmed. No additional identity signal has been established. No badge is displayed on the publisher profile or package listings.

Verified

GitHub account linked or domain DNS TXT record confirmed. The publisher has demonstrated control of a real-world identity anchor. A verified badge is shown.

Trusted

Bibliotheca-local governance signal layered over verified status. The trusted level is not a canonical release-scoped trust fact — it is a bibliotheca-specific signal applied at the registry level.
The trusted level is a bibliotheca-local governance signal. It is not itself a canonical trust artifact tied to a specific release, and it does not replace provenance attestations or Sigstore-family signatures as objective verification evidence. Treat it as one signal among many rather than as definitive proof.

​
Scopes and publisher namespaces

Scopes (such as @acme) are publisher namespaces. A publisher that owns a scope can publish any volume under that scope without registering each volume name individually. 
@acme/research-agent-pack   → owned by the @acme scope
@acme/github-provider       → also owned by the @acme scope
my-standalone-volume        → scopeless, owned by the publisher who registered the name
Bibliothecas define their own scope-governance policies — including whether they support scopes, how scope registration works, and whether scopeless names are permitted. The high-level shape of that support is discoverable through the bibliotheca capability metadata endpoint.

​
Trust attachment subject binding

Trust attachments — BOMs, provenance attestations, and signatures — are bound to the release subject, not to the publisher identity. When you verify a trust attachment:
  • The subject must match both the logical identity (pkg:volume/<name>@<version>) and the immutable content identity (sha256:<hex>).
  • Publisher identity is one input to evaluating whether a release is trustworthy, but it is not substitutable for artifact-level verification.
If multiple trust attachments claim incompatible logical identities or incompatible content identities for the same release, treat the release metadata as inconsistent and reject it.

​
How to consume publisher trust metadata

When consuming trust metadata from a bibliotheca, follow these principles:
1

Start with objective facts

Consume the raw trust detail view first. It exposes which trust artifact categories are present, what format they are, which release subject they bind to, and what their lifecycle status is. These are facts, not judgments.
2

Treat derived judgments as supplemental signals

A bibliotheca may expose verification labels, trust labels, or publisher badges alongside fact-first trust metadata. These derived judgments are not canonical truth. Apply your own policy to determine whether they are sufficient for your use case.
3

Verify artifacts independently when possible

For Sigstore-family signatures and SLSA provenance attestations, you can retrieve the artifact bytes and verify them independently using standard tooling. Independent verification does not depend on accepting the bibliotheca’s derived judgment.
4

Apply your own trust policy locally

Builder identity allowlists, minimum verification level requirements, and publisher history are local policy inputs. The v0.1 core does not mandate one universal trust policy — it mandates that you apply whatever policy you use against objective, independently verifiable artifact facts.
An empty trust artifact collection for an existing release is not a failure condition by itself — it means no trust artifacts have been attached yet. Whether that absence is acceptable for your use case is a policy decision, not a conformance decision.