EXTENSIONS
User-built models, drivers, vaults, and reports — the parts that plug into swamp.
Filter by what you need and pull what fits.
Sourced Kb
A domain-neutral, sourced, versioned knowledge base — the provenance-aware core generalised out of @stateless/llm-catalog. One uniform `entry` record (open `kind` + open `facets` + `claims` + `relations`, like @stateless/inventory), but with a provenance envelope (asOf, source, versionPins, supersededBy) on every volatile assertion, so it can hold external, decaying, contested knowledge honestly — a value without a date + source is not trustworthy here. Declarative lifecycle: `apply` materialises the declared entries (re-run = versioned trend), `update` folds in a public catalog without clobbering local truth, `prune` soft-retires undeclared entries, `contribute` sanitises selected entries into PR-ready public fragments. It knows no domain (no typed facets, no compute methods); a consuming catalog — LLM-ops, cloud-storage pricing — is an instance whose entries carry that domain's kinds and facets.
Llm Catalog
A sourced, versioned knowledge base of LLM-ops knowledge — NOT a control plane for running models, but the structured, CEL-queryable record that running extensions read to decide which model to run where, with what settings, at what cost. Six subject kinds (model, runtime, provider, hardware, technique, endpoint), all the same uniform `entry` shape (open kind + open facets, like @stateless/inventory); a model's run-options embed on the model in runsOn[] keyed by endpoint, and capacity/plan answer "what to run where" over them. The twist: it records external, decaying knowledge, so every volatile assertion carries a provenance envelope (asOf, source, versionPins, supersededBy) — "best vLLM version" is derived as the latest un-superseded claim, never a bare rotting field. Declarative: `apply` materialises one `entry` resource per id (re-run = versioned trend); `prune` soft-retires undeclared entries.