[model] trust & verification

Don't trust us.
Verify everything.

Knowledge steers what your agent does — so it deserves the same care as code you ship. The registry is built so you never have to take our word for anything: every guarantee is enforced on our side and re-checked on your machine. Here is the complete model — no marketing, just the mechanics.

On publish — six server-side gates

Name binding

The name inside the package must equal the address it is published to (@namespace/name). The catalog can never claim something the file itself does not say.

Version binding

Same for the version: what you see in the catalog is exactly what is inside the file. No drift, ever.

Signature verification

Every package must carry a valid ed25519 signature from its author — and we actually verify it against the package contents. Merely having one is not enough.

Fingerprint pinning

We compute the package’s SHA-256 fingerprint ourselves and pin it in the catalog forever. Downloads include it in a header so anyone can double-check independently.

Secret scan

Every package is scanned for things that look like credentials — AWS keys, private key blocks, GitHub/Stripe/Slack tokens and more. Clear findings reject the publish outright. No override, no exceptions.

Immutability

A published version is written once and never altered. Only two things can ever change: the yank flag and the download counter.

Trust report

Every release keeps its full verification evidence on record, including the scanner version and any warnings — published at /api/v1/packages/{ns}/{name}/{version}/trust, so anyone can audit any version, any time.

On install — your machine double-checks

Fingerprint re-checked

Your machine hashes the download and compares it against the catalog entry — before anything is installed.

Signature re-checked

The author’s signature is verified again locally. Even a compromised registry could not slip altered content past this check.

Locked for your team

ctxpkg.lock pins exact versions and fingerprints — your whole team and CI install precisely the same thing.

[score] quality

The quality score formula

0–100, computed by the registry from signals it can verify itself. No stars, no reviews, no self-reporting. The component breakdown ships in every API payload, so publishers always see what to improve.

ComponentMax

Completeness

25

Real description (≥40 chars), ≥2 tags, author, layer stats. Empty manifests score low by design.

Reliability

20

Yank-free ratio across all published versions. Versions that stay earn trust.

Adoption

30

log₁₀ of verified installs — 10,000 installs reach the maximum. Organic, not gameable by burst traffic.

Freshness

15

Days since the last release: ≤30d full points, decaying to 0 after 180d.

Provenance

10

Signer history: key age and breadth across packages. Signing is mandatory, history earns the rest.

Inspect any package's live breakdown via GET /api/v1/packages/<ns>/<name>/index.json

[roi] token economics

How the token ROI is estimated

Every pack page shows an estimated cold-start saving. It is derived from exactly two numbers, both verifiable — no marketing math, no self-reported benchmarks. If a manifest carries no compression evidence, no ROI is shown.

distilled_tokens

artifact_size_bytes / 4 — the standard bytes-per-token heuristic applied to the signed artifact you actually install. This is what the pack costs your context window.

source_tokens

distilled_tokens / stats.compression_ratio — the manifest records the measured ratio between the distilled pack and the original context it was built from. The ratio is inside the signed manifest: spoofing it means breaking the signature.

saved_tokens

source_tokens − distilled_tokens — the exploration an agent skips on every cold start because the knowledge, patterns and gotchas arrive pre-distilled instead of being re-derived from the codebase.

It is an estimate: real savings depend on your model's tokenizer and how much of the pack your sessions touch. Reproduce any pack's numbers from GET /api/v1/packages/<ns>/<name>/index.json (field roi) and the signed manifest.

[identity] verified publisher

Verified publisher

Identity beyond a signing key: prove control of a domain and your namespace carries the verified badge everywhere it appears — catalog, package pages, badges, API.

  1. 1. Add your domain in your account and receive a one-time challenge.
  2. 2. Create the TXT record at your DNS provider.
  3. 3. Hit verify. The registry resolves over DNS-over-HTTPS (Cloudflare, then Google) — no propagation race, retry any time.

The DNS record

Type:  TXT
Name:  _ctxpkg.yourcompany.com
Value: ctxpkg-verify=<your-token>

Verification is per publisher account, covers all packages in the namespace, and can be revoked by deleting the domain. Up to 5 domains.

[faq] straight answers

Straight answers

What does yanking do?

Yanking flags a version as withdrawn: new installs skip it, but existing lockfiles can still resolve it for reproducibility. Nothing is ever deleted — supply-chain history stays auditable.

How are publish tokens stored?

Only as SHA-256 digests. The plaintext ctxp_… token exists exactly once, in the mint response. Revoking a token stops publishing with it immediately.

Can the registry tamper with packages?

Not undetected. Your installer re-verifies the SHA-256 and the ed25519 signature locally. The signing key never leaves the publisher’s machine.

Is my data locked in?

No. .ctxpkg is an open format (ctxpkg.org). Packages are exportable artifacts; the manifest, integrity data and signature travel inside the file itself.

What if I publish a secret by accident?

High-confidence credentials (AWS keys, private key blocks, live Stripe keys, …) never make it in — the registry rejects the publish with HTTP 422 before anything is stored. If something subtler slips through: yank the version immediately and rotate the credential. Yanked versions stop resolving for new installs.