Reference
Decision briefs
What a decision brief is, how it differs from a recommendation, the verified fields it captures, the data gaps it surfaces, the source trail and freshness notes it carries, and the Markdown / JSON export formats.
Last updated: 2026-05-24
What a decision brief is
A decision brief is a structured export of verified evidence for 2–4 selected AI models. It collects the verified field values, the explicit data gaps, the source trail (every primary-source citation referenced), freshness notes, hosted availability, and a checklist of external tests the reader still needs to run before committing.
Briefs are built at /briefs/build from the same typed local data layer that powers every other surface. The same payload is available as a machine-readable export at /api/briefs/decision (Markdown by default; JSON via ?format=json).
Evidence vs recommendation
A brief is evidence. It is not a recommendation, a winner declaration, a price ranking, or an endorsement. The brief lists what is verified, what is explicitly unverified, and which sources support each claim — the reader weighs those inputs against their own workload.
WebmasterID Models does not generate conclusions of the form "use model X" or "model Y is best for this use case". The reader runs the workload, opens the vendor pages, and decides what to test externally. See /docs/decision-workflow for the no-ranking policy in long form.
Verified fields
Each brief includes a configurable set of per-model fields: identity (provider + canonical API ID), lifecycle, context window, max output, modality channels, first-party pricing references, hosted availability, source count, freshness state, and per-model coverage notes. The field set is driven by DECISION_BRIEF_DEFAULT_FIELDS but can be overridden per request via the ?fields= query parameter.
Every value is rendered straight from the data layer. The helper never derives a value the catalogue does not already carry; it never re-formats pricing into a synthetic "$/1M-equivalent" number; it never ranks.
Data gaps
A data gap is a canonical field the catalogue records as unverified. Briefs surface every gap explicitly so the reader can see what is missing before they read past the evidence rows. Gaps are not invented; the catalogue refuses to guess.
Common gaps include max-output limits (Meta Llama 4 cards), modality channel enumeration (Mistral spec cards that describe a model as "multimodal" without listing channels), and first-party pricing on open-weights models (Meta). Hosted pricing references may compensate where they exist; the brief surfaces both sides.
Source trail
Every brief lists the primary-source citations referenced by any verified field: the citation name, the source type (official vendor docs, official vendor pricing, etc.), the retrievedAt date, and the URL. Source IDs are stable opaque-ish slugs derived from the URL — they let evidence rows reference sources without repeating the URL in every row.
Freshness notes
Each model record carries a deterministic freshness state computed against siteConfig.buildDate. Briefs flag any record or citation that has aged past the fresh window — with a short note explaining when it was last checked and why it should be re-verified before reuse.
Stale ≠ false. A stale record is one whose source has not been confirmed for longer than the policy window; the value may still be correct. The note nudges the reader to re-open the source page before depending on the value for a decision.
Hosted availability
For models hosted on third-party platforms (Groq, Together AI), the brief includes the hosted model ID, the billing provider, whether a pricing reference has been verified, and the last-checked date. Hosted pricing is set by the hosting platform, not by the model creator — the brief preserves that separation and never collapses the two rates into a single "price" number.
Next external tests
The catalogue stops at verified fields. The brief includes a checklist of external checks a reader still needs to run before committing to a model — task-specific prompt tests, latency in the target deployment region, rate-limit confirmation against the provider account, cost validation against the current vendor pricing page, and internal compliance / security review. These are checkboxes, not claims.
Markdown / JSON export
Briefs export via /api/briefs/decision with the same query parameters as the page. Default format is text/markdown — paste it straight into a PR description, a notebook, or a procurement document. JSON mode (?format=json) returns the same structured payload for partner dashboards and internal tooling.
Both responses set X-Robots-Tag: noindex. Generated briefs are personal/team artifacts, not indexable content — only the base /briefs/build page is indexable.
Limitations
- Maximum 4 models per brief.
generatedAtuses the build date, not wall-clock now — the same build produces the same brief.- The brief never asserts latency, throughput, or uptime. Status surface presence is recorded; values are not.
- Pricing references are not live quotes. Re-verify against the vendor pricing page before any procurement decision.
- The brief never declares a winner, never ranks by price, and never recommends a model.
- Verification status describes citations on a date; it does not assert regulatory compliance, certification, or fitness for purpose.
Continue
Related pages
Decision Brief Builder
Generate a brief from selected models.
Selection workspace
Source-backed shortlist with documented order.
Comparison builder
2–4 models side by side from verified fields.
Decision workflow
How the catalogue supports decisions without ranking.
Source verification methodology
Primary-source rules, freshness lifecycle.