Skip to main content

Start With Registry

Registry is the fastest way to consume ANIP work that already exists.

Use it when you want to:

  • Browse existing ANIP packages.
  • Generate service code from a reviewed contract.
  • Verify and lock the package you are consuming.
  • Browse starter templates before creating a Studio project.
  • Compare showcase packages such as GTM, Jira, GitHub, Slack, GitLab, Linear, Notion, and Superset.

Registry has two separate artifact types:

ArtifactUse it for
PackageConsume a reviewed behavior contract and generate code.
TemplateStart a new Studio project from safe starter material.

Packages are for consumers. Templates are for authors.

1. Open Registry​

Hosted Registry:

https://registry.anip.dev/registry/packages

Local Registry:

cd registry
docker compose up --build

Open:

http://127.0.0.1:8200/registry/packages

The package browser shows package identity, version, publication metadata, downloads, capability summaries, readiness guidance, package manifests, service definitions, recommended locks, and generator commands.

2. Choose A Package​

Open a package when you want to answer:

  • What governed capabilities does this service expose?
  • Which ANIP spec version does it target?
  • Is the package signed by a trusted Registry key?
  • What source/project lineage produced it?
  • Are there readiness findings the consuming agent should understand?
  • Is there implementation material such as a custom bundle ref?
  • What command generates code from this exact package?

Do not generate from loose JSON copied out of a page unless you are intentionally doing local development. Prefer a Registry package reference and a lock.

3. Verify Before Generating​

Use anip verify against the Registry package:

anip verify \
  --registry-url https://registry.anip.dev/registry-api/v1 \
  --package [email protected] \
  --require-registry-mode production \
  --trusted-registry-key-id anip-protocol-registry-root-2026-q2

Verification checks package identity, manifest digest, service-definition digest, receipt signature, contract signature, and trust metadata.

For local development, use the local Registry URL:

anip verify \
  --registry-url http://127.0.0.1:8200/registry-api/v1 \
  --package [email protected]

4. Generate With A Lock​

Generate code and write a lock:

anip generate \
  --registry-url https://registry.anip.dev/registry-api/v1 \
  --package [email protected] \
  --target python \
  --transport http,stdio \
  --dependency-source registry \
  --write-lock ./anip-package-lock.json \
  --output ./generated/jira-fronting \
  --force

Regenerate later with lock enforcement:

anip generate \
  --registry-url https://registry.anip.dev/registry-api/v1 \
  --package [email protected] \
  --lock-file ./anip-package-lock.json \
  --target python \
  --output ./generated/jira-fronting \
  --force

If the package digest no longer matches the lock, generation should fail. That is intentional.

5. Use Templates To Start Projects​

Templates live separately from packages:

https://registry.anip.dev/registry/templates

Use a template when you want a safe starting point for a new Studio project. A template may include:

  • Project type.
  • ANIP spec version.
  • Industry/domain labels.
  • Markdown source documents.
  • Suggested capability shape.
  • Fronting starter intent.

Templates are not behavior authority. They help authors start. The reviewed Developer Definition and published package become the behavior authority later.

6. What Not To Trust​

Do not treat these as trust signals:

  • Download count.
  • Popularity ordering.
  • A nice README.
  • A package name that looks official.
  • A template that imports successfully.

Trust should come from:

  • Registry key identity.
  • Package receipt signature.
  • Manifest and definition digests.
  • Contract signature.
  • Lock-file enforcement.
  • Scenario validation and conformance evidence.

Next Steps​