HTTP Addressability

Every bullet has a stable, globally resolvable identifier following the pattern bullet://namespace/name@version. This addressing scheme enables bullets to reference each other, declare dependencies, and be discovered across organizational boundaries.

Universal Resource Identifiers

The bullet:// URI scheme provides a uniform way to reference capabilities regardless of hosting location. An identifier like bullet://email/gmail-send@2.1.0 uniquely identifies a specific version of a specific bullet in a specific namespace. This remains stable even if the bullet moves between hosting providers.

Namespaces provide organizational scoping. Verified namespaces like bullet://stdlib/ contain curated standard implementations. Organization namespaces like bullet://acme-corp/ contain private capabilities. Individual namespaces like bullet://user:alice/ enable personal experimentation.

Version pinning is explicit and semantic. When you reference bullet://csv/parser@2.1.0, you get exactly that version. The immutability guarantee means @2.1.0 refers to precisely the same bullet forever.

HTTP as Transport Layer

While the bullet:// URI scheme is protocol-agnostic, HTTP provides the standard transport. Resolvers translate bullet URIs to HTTP URLs using configurable mappings. A default mapping might translate bullet://namespace/name@version to https://bullets.dev/namespace/name/version.yaml.

This leverages existing web infrastructure: CDNs accelerate distribution, HTTP caching reduces redundant fetches, HTTPS provides security, OAuth enables access controls. Standard HTTP semantics apply—GET retrieves bullets, HEAD checks existence, 304 Not Modified optimizes caching, 404 Not Found indicates missing bullets.

Progressive Discovery

HTTP addressability enables progressive discovery rather than requiring upfront knowledge of all bullets. Search APIs return bullet identifiers. Plans contain references to other bullets they compose. Manifests record which bullets were actually used.

An agent can start with a single entry point and progressively discover the entire dependency graph by following references. Each bullet's metadata provides hints about related capabilities.

HTTP-based protocols also enable federation. Different organizations can run their own bullet registries while maintaining interoperability. Cross-registry references work naturally through URL resolution.

Immutability and Trust

Semantic versioning, content hashing, and cryptographic signing create a trust model built on HTTP infrastructure. You can verify that a bullet retrieved from any source matches its claimed identity. You can cache aggressively because immutability means content never changes. You can mirror freely because signatures prove authenticity regardless of hosting location.

This immutability extends to the entire dependency graph. A manifest recording an execution captures bullet IDs, content hashes, and signatures—creating a complete audit trail that remains verifiable indefinitely.

Inspiration from HTTP-Based Execution

This design takes inspiration from HTTP-based execution models demonstrated in earlier systems (like the sauna-skills reference implementation), where agents fetched content dynamically via API calls rather than receiving everything upfront.

The core insight—dynamic, turn-by-turn resolution—carries over. But the Bullet Protocol generalizes beyond HTTP. The resolution mechanism isn't tied to HTTP specifically; it's about programmatic control via hooks that determine what capabilities to load.

Implementations might use HTTP as the transport (fetching bullets from registries via HTTP APIs), but the architecture doesn't require it. The key is the hook-router-resolution pattern, not the specific transport protocol.

This allows implementations to optimize for their context—HTTP for web-scale federation, local filesystem for development, in-memory for testing, cloud storage for production deployments.