> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agentvolumes.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Publisher identity and verification levels

> How publishers register with a bibliotheca and the three verification levels: unverified, verified, and trusted — and what each level means for trust.

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:

```toml theme={null}
[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.

<Note>
  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.
</Note>

## The three verification levels

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

<CardGroup cols={3}>
  <Card title="Unverified" icon="circle-question">
    Email address confirmed. No additional identity signal has been established. No badge is
    displayed on the publisher profile or package listings.
  </Card>

  <Card title="Verified" icon="circle-check">
    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.
  </Card>

  <Card title="Trusted" icon="shield">
    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.
  </Card>
</CardGroup>

<Warning>
  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.
</Warning>

## 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.

```text theme={null}
@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:

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Tip>
  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.
</Tip>