Appendix E: Model Card Template

Make the Release Decision Legible

An account-support team proposes replacing its rules-based outreach queue with a ranking model. The candidate finds more accounts likely to need help, measured across the evaluation set as a whole. Buried in the segment results is a reversal: accounts with little recorded history are ranked less reliably than they were by the rules. The release record says only that the model improved performance. Nothing tells the operator whether sparse-history accounts may enter the ranked queue, what should happen to them instead, or which signal would reveal that their treatment is deteriorating.

A model card is a version-specific disclosure, not a biography of a model family. It should let a product owner, evaluator, operator, risk reviewer, and downstream integrator understand what was released, for which uses, on what evidence, under which constraints, and with which residual limitations.

Scope the Card Correctly

Write one card for a specific model or adaptation version. If a provider model is used, record the provider identifier, tested date, and whether the identifier can move without notice. Document your own adaptation, configuration, evaluation, and constraints. Keep a separate system card for retrieval, prompts, tools, interface, workflow, human oversight, and operations; a model card cannot describe the complete AI-enabled system.

Every metric needs a dataset version, population, method, threshold or decoding configuration, date, and limitation. Comparative language such as “better” is meaningless without a named baseline and decision context.

Keep Claims Inside the Evidence Boundary

Translate every evaluation result into a bounded claim. A passing result for English support email does not establish performance for chat, other languages, or account decisions. If evidence is missing, write “not evaluated” and add a deployment restriction; do not replace evidence with a generic warning.

The restriction is part of the result. “Sparse-history accounts performed worse” leaves the release decision unfinished. “Sparse-history accounts remain on the current rules until the segment floor is met” tells a system owner what may enter production. Downstream owners should be able to compare their context with the approved envelope without consulting the original development team.

Model Card

IDENTITY AND OWNERSHIP
Model name and immutable version:
Card version and release date:
Provider / developer / adaptation owner:
Model owner and contact:
Operational escalation route:
License and usage terms reference:
Linked dataset, evaluation, system, and release records:

MODEL DESCRIPTION
Model family and task type:
Inputs and outputs:
Architecture or provider description at an appropriate disclosure level:
Training, fine-tuning, prompting, retrieval, or other adaptation summary:
Dependencies and required runtime:

INTENDED USE
Supported task and workflow:
Intended users and affected population:
Approved regions, languages, domains, and operating conditions:
Permitted action path and required human role:
Expected value and non-AI baseline:

OUT-OF-SCOPE AND PROHIBITED USE
Unsupported populations, contexts, inputs, or decisions:
Actions the model must not trigger:
Known misuse and abuse scenarios:
Binding policy, license, or review restrictions:

DATA SUMMARY
Training / adaptation data summary and datasheet links:
Evaluation data versions and sampling:
Time, geography, language, and population coverage:
Rights, privacy, and provenance notes:
Known gaps, overlap, leakage, and contamination checks:

EVALUATION EVIDENCE
Evaluation question and decision supported:
Baselines:
Primary task metrics and uncertainty:
Segment-level results:
Human evaluation method and agreement:
Robustness and shift tests:
Fairness and harm analysis:
Safety and security tests:
Privacy tests:
Cost, latency, and resource results:
Failed tests and unresolved findings:

THRESHOLDS AND CONFIGURATION
Decision threshold / abstention rule / decoding configuration:
Trade-offs and error allocation:
Calibration evidence where applicable:
Who approved the setting and why:
Configuration that invalidates these results:

INTERPRETATION AND LIMITATIONS
What outputs mean and do not mean:
Explainability or interpretability method and limits:
Known failure modes:
Uncertain or weakly evaluated conditions:
Potentially affected groups and concentrated harms:
Residual risk and accepted owner:

DEPLOYMENT CONSTRAINTS
Required input validation and access controls:
Human oversight and contestability:
Fallback, rollback, and kill conditions:
Volume, latency, environment, or integration limits:
Required system-level controls:

MONITORING AND RE-EVALUATION
Quality, segment, data, safety, security, and service signals:
Thresholds and alert owners:
Feedback and appeal review:
Re-evaluation cadence:
Changes that require a new card and evaluation:

RELEASE DECISION
Status: experimental / conditional / approved / restricted / retired
Approved deployment context:
Conditions and due dates:
Technical / product / risk approvers:
Approval date and expiry or next review:

CHANGE HISTORY
Version / date / component changed / reason:
Evaluation rerun and result:
New limitations or controls:
Approver and migration / rollback note:

Follow One Release to Its Boundary

The outreach candidate is recorded as support-rank-3.2, with its feature pipeline, decision threshold, training snapshot, evaluation snapshot, and card version linked by immutable identifiers. Its intended use is narrow: order accounts for optional human outreach in the existing support-planning workflow. The model may not suppress service, change account terms, assign customer risk, or trigger contact without an operator. Those actions demand different evidence and authority.

The evaluation compares the candidate with the current rules on the same time-bounded account population. Overall ranking performance improves, but the sparse-history segment falls below its agreed floor. The card does not average away the conflict or describe it as a caution. It records that sparse-history accounts remain on the rules-based path. Missing-history detection becomes an input gate; routing counts for both paths become a monitored signal; and a monthly sample checks whether the gate is classifying accounts as expected.

This changes the approval from “the new model is better” to a conditional release. support-rank-3.2 may order only sufficiently represented accounts, for the regions and support products covered by the evaluation. Expansion requires a new segment evaluation. A shift in feature availability, threshold, outreach policy, or downstream action reopens review. The decision expires unless the product owner, model owner, and support-operations owner review the first production evidence by the named date.

Now imagine a collections team asks to reuse the score to prioritize payment reminders. The model card supports a refusal without claiming that the model is universally poor. Payment status was outside the training and evaluation purpose, reminder priority changes the action and affected interests, and the approved human-support workflow supplies none of the controls needed for collections. The release envelope has done its job: a locally supported claim did not become a portable reputation.

Try to Carry the Claim Somewhere Else

Give the completed card to someone proposing a neighboring use. Ask them to identify the exact model and configuration, then compare their task, population, inputs, threshold or decoding configuration, and action path with the approved context. The gaps should become visible without oral history from the development team. Each material weakness should lead to an exclusion, fallback, test, monitoring signal, or named acceptance of residual risk.

Then follow the card into operation. The system record should supply the controls that the model card requires; alerts should reach someone able to act; expiry and change triggers should prevent old evidence from silently authorizing new behavior. A card is unfinished when its strongest claim is easy to quote but its restrictions require interpretation. It is also unfinished when the neighboring use inherits the approval automatically. Model evidence belongs to a particular task, population, method, and context; crossing any of those boundaries requires a new decision.

Use this card with the Dataset Datasheet Template, Model Documentation and Release Discipline, and the Evaluation Plan Template.