The model registry explains how LlmWikis will document language and multimodal models without turning model choice into unsourced ranking. Use it as the field guide for model profiles, comparison notes, and source review.
Current scope
This hub is useful now as an editorial and reader guide. It does not publish live model scores, freshness guarantees, pricing claims, or provider endorsements. Individual model records must show sources, dates, and review status before making capability claims.
What exists today
| Layer | Current state | Reader action |
|---|---|---|
| Model Registry hub | Public editorial blueprint for model pages and comparison workflows. | Use it to understand which fields a future model page must carry. |
| Model Profile Template | Copy-ready page structure for identity, capability, evidence, deployment, and limitations. | Draft with sources before treating the result as reference content. |
| Compare Models workflow | Manual decision worksheet for source-backed model choice. | Record requirements, constraints, evidence, missing data, and review date. |
| Live records | Not yet published as verified model pages. | Do not infer rankings, freshness, or endorsement from the template hub. |
Quality ladder for a model record
| Class | Minimum evidence | Allowed public posture |
|---|---|---|
| Stub | Name and official source link only. | Placeholder or source lead; no capability summary. |
| Start | Official docs, model card or release page, release/access status, and date checked. | Basic identity and caveats. |
| C | Capability notes with source-specific caveats and at least one implementation-relevant limitation. | Practical overview without ranking claims. |
| B | Multiple primary or formal sources, benchmark-context notes, deployment constraints, and reviewer status. | Decision-support page for a bounded use case. |
| A or Reviewed | Human-reviewed source trail, stale-claim rule, comparison notes, and update cadence. | Reference page with clear limits and next review date. |
| Field | Purpose |
|---|---|
| Model identity | Name, publisher, release date, license, source links, and version notes. |
| Modalities | Text, image, video, audio, document, UI, spatial, temporal, or other supported inputs and outputs. |
| Architecture | High-level design, training approach, context handling, mixture-of-experts notes, OCR strategy, or memory design. |
| Evidence | Benchmarks, papers, repositories, demos, contamination notes, and last-reviewed date. |
| Deployment | Hardware, latency, memory, API availability, edge/cloud fit, and operational limits. |
| Interop readiness | Known tool calling, structured output, protocol, schema, UAI-1, or MCP notes. |
Model page template
Overview
Provider, model family, release date, license/access, context, modalities, and deployment options.
Capability profile
Reasoning, coding, math, multimodal, tool use, latency, cost, and known limits.
Evidence trail
Benchmarks, sources, reviewer status, and freshness notes so readers know what can be trusted.
Useful reader path
- Start with requirements. Identify context length, modality, deployment boundary, budget, privacy, and latency needs before naming models.
- Read the evidence column. Treat benchmark results, provider claims, and community reports differently; each needs its own source date.
- Check limits first. Capability pages are not useful unless they say where the model fails or where the evidence is incomplete.
- Record the decision. Link the selected model, source trail, rejected options, and review date into the relevant LLM Wiki page.
Production queue fields
| Queue field | Why it matters |
|---|---|
| Target slug | Prevents duplicate pages and keeps route planning explicit. |
| Quality class | Shows whether the page is a stub, start-class draft, or reviewed reference. |
| Source status | Separates official docs, papers, benchmark pages, and unsourced claims. |
| Owner and reviewer | Prevents AI drafts from becoming unowned public truth. |
| Last action date | Makes stale model pages visible before readers rely on them. |