Knolo Hub: Sharing Knowledge Packs You Can Pin by Digest

Knolo Hub is the public registry side of the Knolo stack: a place to discover portable Knowledge Images, inspect them, pin them by digest, and mount the bytes locally with @knolo/core. The Hub tagline states the contract plainly—“Knowledge you can pin.”—and the site is live at hub.knolo.dev. This note explains what Hub publishes today, what pin-by-digest means, and why Hub is not where queries run. For the open-technology record around the format, start at Knolo on knolo.org.

What Knolo Hub is for

A Knowledge Image is a bounded, content-addressed artifact: documentation, handbooks, policies, and related material packaged so you can check, compare, and mount it like other software artifacts. Knolo Hub lists public packs with digest information, license, verification status, and size before you pull anything into a runtime.

The intended loop matches the Hub quickstart style:

1. Discover a pack on Hub.
2. Inspect the Knowledge Card and verification status.
3. Pin the digest (and version) you intend to use.
4. Download the artifact bytes and mount them with @knolo/core in an environment you control.

Developer-facing Hub guidance also lives under Knolo Hub docs on knolo.dev. The runtime side—build, mount, query, verify—remains @knolo/core on npm under Apache-2.0 (currently 6.2.0). Hub does not replace that runtime.

Pin by digest, the way you pin software

Pinning is the difference between “the refund policy wiki” and “this exact artifact.” On Hub, packs are content-addressed. A digest names one immutable byte sequence. When an application pins that digest, environments stay comparable: the knowledge you mounted in staging can be the same knowledge you mount in production, and a change shows up as a different digest rather than a silent edit behind the same URL.

That is why Hub surfaces SHA-256 digests next to listings. Lockfiles and manifests can keep version and digest together so a later mount reproduces the same artifact. The public Hub copy frames this as pinning knowledge the way teams already pin container images or library versions—reproducible references, not floating remotes.

Integrity matters for the same reason. Hub’s home page publishes an artifact-integrity figure alongside public pack counts, and every listed pack is presented as content-addressed and inspectable. Treat those numbers as Hub’s own published status, not as a third-party audit: the point for users is that you can inspect and verify before you rely on a pack.

What Knolo Hub does not do

Hub is a pin and mount registry, not a remote query engine. Queries run after you mount the image locally with @knolo/core. Hub’s own docs describe the split clearly: discovery and distribution on Hub; prove and query inside the runtime that holds the bytes. Bytes are fetched for local use; the retrieval receipt comes from the runtime you operate, not from a Hub query endpoint.

That boundary keeps Knowledge Images portable. If verification or retrieval depended on Hub being online for every question, the artifact would not be local-first. Knolo’s design rule is the opposite: copy the image, mount it offline if you need to, and verify the bytes against the roots they declare. The Knolo verification center lists official Knolo domains so you can confirm you are looking at the real project surfaces.

How Hub relates to Knolo open technology

Hub distributes public images; the format and licensing rules live in the open-technology record:

• The Knolo specifications index describes the Knowledge Image .knolo contract (V5 current in source, V4 kept for compatibility). Numbered adopted specification records are not all published yet; the working contract lives in public source and documentation.
• The Knolo licensing page states that Knolo Core uses Apache License 2.0, with canonical texts living with each project.
• The Knolo compatibility page expects independent compatibility claims to link versioned tests or documented support—compatibility is not endorsement.
• Trademarks stay separate from the software license: refer accurately (for example, “built with @knolo/core”) and do not imply official approval you do not have.

Together, Hub plus those pages describe a local-first sharing path: find a public pack, pin a digest, mount with the open runtime, and keep claims about the name and the format within the published rules.

Practical next steps with Knolo Hub

1. Browse public packs at Knolo Hub and read a Knowledge Card before you pull.
2. Pin a digest, download the artifact, and mount with @knolo/core following Knolo Hub docs.
3. Verify the mounted bytes with the open verification tools; do not treat listing status alone as a substitute for a local check.
4. For developer packages and docs, use Knolo on knolo.dev. For specifications, licensing, and verification domains, use Knolo on knolo.org.
5. Source and releases: the Knolo core repository on GitHub.

Knolo Hub exists so Knowledge Images can be shared without giving up digests, inspection, or local mounting. Pin the pack you mean, mount it yourself, and keep the query path next to your application—not behind a remote knowledge service as the source of truth.