Model cards

Every evaluated model has a model card that brings its lineage, training history, evaluation evidence, and promotion decision into one verifiable JSON document. Open Card on model detail in the console, or request GET /models/{model_id}/card. The console can download the same JSON payload it displays.

The card you read is assembled at read time. This lets historical evaluated models have cards, but it also means the response describes the model's current state: promoting the model later adds bundle and acknowledgement provenance to subsequent reads. Treat the fingerprints in the card as the immutable evidence, not the card response itself. When you promote a model, Tessera also pins the card as it stood at that moment next to the bundle, and the pinned card is what governance exports and dossiers render.

What the card contains

Section	Evidence
Identity	Model and run ids, checkpoint and configuration fingerprints, the six pinned lineage values, seed, world size, compute class, and the reproducibility tuple.
Data	Dataset split, row counts, label support, training window, encoders, tokenizer, contract, and leakage-policy versions.
Training	Resolved trainer settings, completed steps against the run's maximum budget, wall time, best step, and adaptive-stop outcome when available.
Evaluation	Per-label estimates and entity-level confidence intervals, plus G1–G6 status, diagnostics, catalog name, and server-resolved severity.
Promotion	The latest bundle identity and, when applicable, the exact advisory-gate acknowledgement, reason, actor, and policy mode.
Loss curve	A bounded rendering summary of train and validation loss that preserves the first, last, and best-step points.
Limitations	Facts derived from non-gating labels, acknowledged advisory failures, calibration failures, and count-invariance caveats, including equal-count samples.
Sources	Retrievable artifact references as exact kind, uri, and fingerprint triples.

In the console, model detail has five tabs: Overview, Evaluation, Card, Bundles and Files. Overview opens with the promotion verdict and the next step, then a summary of what the model predicts, the data it used, its held-out quality and where it serves. Card sections show their key facts with units, meaning and bounded display precision. Open Exact values in any section for the served values, or download the JSON, which is unchanged. The Lineage and Artifacts links at the top of the Card tab open the identity and source sections directly. The tab is part of the page address, so a link ending in #lineage, #artifacts, #card, #gate-G1 to #gate-G6, #bundles or #files opens the tab that holds that section.

The optional baselines and signals sections are in the JSON only when evaluation produced those blocks. The baselines section holds the comparison with the internal quality safeguards; the console does not show it, and Exact values leave it out. Older runs can omit adaptive-stop fields, and unpromoted models omit promotion provenance. The console renders these cases as Not available; absence is not an error. See the complete ModelCard schema for the field-level contract.

Reading the evidence

Evaluation values are copied from the fingerprint-verified evaluation report; the card does not calculate new metrics. They are measured on the dataset's held-out test split. In the Test environment that data can be example data, so treat the numbers as a check of the workflow rather than evidence of real-world performance. Gate names come from the platform catalog, while severity comes from the project's current promotion policy. This distinction is useful when a report contains an unchanged failed gate fact but a bundle records that an advisory failure was explicitly accepted. Read Promotion gates for the policy and audit model.

The limitations list is deterministic rather than generated prose. Each item names its source facts, so it can be traced back to a label, gate metric, or recorded acknowledgement. An empty list means none of those defined caveats was present; it is not a general claim that the model has no limitations.

When G3 records degenerate_single_count: true, the card explains that every sampled entity had the same event count. Even when G3 passes, this diagnostic cannot establish invariance across different counts. The evaluator compares neighbor share with the count-shuffled baseline for that sample; the card preserves its decision, metrics, and diagnostics and adds a count_invariance_caveat to make this limitation explicit in the JSON download.

Verification and errors

Before returning a card, Tessera verifies the fingerprinted artifacts used to assemble it. If stored bytes no longer match a recorded fingerprint, the read fails closed with failed_precondition and identifies the artifact kind, uri, expected, and actual values. Tessera never serves a partial card.

A missing model, a model from another project, and a model that has not been evaluated all return the same not_found response. This prevents model ids from revealing data across project boundaries.

Verified artifact reads are cached briefly by URI and fingerprint. A changed fingerprint always causes a fresh verification, so the cache cannot turn a new evaluation into stale card evidence.