After The Builder-Parent Paradox, readers started asking me two new questions:
What assumptions are AI companies making about us, the users?
I answered it here.
How do you read AI model release announcements as an AI PM?
That’s this article.
Today I’m sharing the methodology I use to read model releases. It has evolved over time and, given sufficient encouragement, could easily become a much longer article. But I’m told readers occasionally need to eat.
The short version: define the use, inspect the evidence, map the system, expose the assumptions, make a decision, then monitor what happens after launch.
Hey, I’m Karo Zieminski 🤗
AI PM and builder. I write Product with Attitude, an AI newsletter for tens of thousands of readers across 146 countries, helping them develop critical AI literacy the only way it sticks: through practice.
Here’s what you might have missed:
I read the model cards and follow the footnotes. Subscribe to for more practical ways to test AI claims before they become product decisions.
First, the definitions.
What is a model card?
A model card is documentation that accompanies one or more trained models. At its best, it tells you what the model was designed for, how it was evaluated, where its performance varies, which risks were considered, and what remains unknown.
The original Model Cards for Model Reporting paper proposed documenting intended uses, evaluation conditions, performance across relevant groups and environments, ethical considerations, and caveats. Hugging Face’s current guidance lists intended use, limitations, training data, and evaluation results among common sections.
What Is the Difference Between a Model Card and a System Card?
There is no universal difference. Anthropic and OpenAI use system card for documents that may cover capabilities, safety evaluations, safeguards, routing, deployment evidence, or some combination of them. Compare Anthropic’s Claude Opus 4.1 system card with OpenAI’s GPT-5 system card: the label alone does not tell you what was evaluated. My best tip is to inspect the scope the document declares for itself.
Then, the rules.
8 Rules of Reading Model Cards Like an AI PM
1. Do not read any of these documents as certificates.
Model cards are a transparency mechanism, so their usefulness depends on the integrity of the people creating them. A provider-authored card is valuable evidence, but it’s still provider-authored evidence.
2. Start with a use claim, not the launch claim.
I have sat in the meeting where a room of smart people spends an hour arguing about whether a model is state of the art. We lost that hour of our lives because we talked about the announcement first and thought about it second.
If you want to know how to read AI model cards as a product manager, start before you open the card.
Use-first thinking means defining the user outcome and the operating conditions before you read anybody’s capability frame.
Write down the user, the job, the stakes, and the threshold that counts as success before you open anything. Then look at the model you run today and what users already say about it. Skip that step and the provider picks the frame, which is free for them and expensive for you.
3. Read all the docs at once.
Read the announcement for the promise and the model card for the evidence boundary. Then read your own system design to find out where responsibility lands.
4. Inspect the declared scope, not the title.
Model card, system card, addendum, technical report. The naming is not standardised across providers, and the label tells you very little about what was actually evaluated. Read the scope the document declares for itself, then record its version and date.
5. Name the exact system that produced each score.
Model, snapshot, prompt, tools, memory, retries, safeguards, budget, and grader. “The model” is the wrong noun for what you are deciding about. Use the tested system.
6. Treat every missing condition as an assumption.
Missing evidence does not become reassuring because it was formatted nicely. Every empty bracket in a claim is something you have to test, or knowingly accept.
7. Turn limitations into requirements, tests, controls, or a no-go.
The limitations section is your first product backlog. It is also the section most teams reach when the coffee has gone cold.
8. Ship the monitoring, not just the model.
Watch outcomes, affected people, and broken assumptions after launch. Keep rollback and remediation as two separate plans, because one limits exposure and the other repairs damage.
Now, the order you read in.
Minimum Evidence Chain (MEC)
I borrowed the image from chain of custody: the documented history used to establish evidence’s identity and integrity. If you cannot trace what happened at each handoff, confidence in the conclusion weakens. Plus, “Did you run MEC on that release?” works quite well in meetings. Try it.
Plus, “Did you run MEC on that release?” works quite well in meetings. Try it.
Use. Who the user is, what job they are doing, and the limits you refuse to cross.
Evidence. What the provider’s documents actually establish, and about which exact system.
System. What you would build around that model. Tools, permissions, interfaces, reviewers, and the people affected who never touch the product.
Assumptions. Everything link two failed to establish about link three.
Decision. Archive, watch, sandbox, or stage.
Monitoring. What tells you a link broke after you shipped.
The rest of this guide is how each rule works in practice.
A Practical Way to Decide Whether a New Model Belongs in Your Product
Every model release forces product teams to answer the same question: Does this change what we build next?
There are only four good answers:
Ignore it.
Watch it.
Sandbox it.
Stage it.
Picking one is the job.
The trap is that the announcement picks for you. It arrives with its own definition of impressive, its own tests, and its own comparisons. If you start with the announcement, you might end up in one of the meetings where everyone has an opinion except the user.
Why your situation comes before their benchmarks
The model looks great because it did well on the thing the provider measured. Make sure it does equally well on the things that matter for your product.
I run the same exercise on every release. It takes six minutes and lets you map enough context to interpret the score, then revisit as the system changes.
Step 1: Write this sentence before you read anything
It’s always the same sentence, so I can line six months of them up and watch my own assumptions change.
For [user], during [trigger or workflow], the system will [perform or support a role] to improve [user outcome] versus [current baseline], while staying within [quality, harm, latency, cost, and reversibility limits].
Step 2: Answer five questions:
You already run a model in production. You already have complaints, escalations, retries, and abandoned sessions. Learn from them.
What decision or job is the user trying to complete?
What model do they use today?
What’s the feedback so far?
What would make a new model better?
What would make a new solution better, regardless of model update?
Questions four and five are a pair. Question four asks whether the model is your bottleneck. Question five asks whether anything else is.
You’d be surprised how often question five changes the decision. The better solution may be improved retrieval, or an interface that stops asking users for information the system already has. Sometimes a new model can help, but it is still not the highest priority. A wonderfully unfashionable conclusion.
This is not just my preference, by the way. If you have not run into NIST before, it is the US government's standards body. The same one whose cybersecurity guidance sits underneath a lot of company policy.
In 2023 it published a free, voluntary AI Risk Management Framework. It splits the work into four jobs:
Govern is who is accountable.
Map is understanding the situation you are building into.
Measure is testing the thing.
Manage is acting on what the testing tells you.
The exercise I shared above is Map, done in six minutes.
NIST also says the four functions are meant to be iterative, not a checklist you complete once. So map enough context to interpret the score, then go back through it as the system changes. My two steps are shorthand for that idea (not a substitute), just not in order prescribed by NIST.
Read the Whole Document Stack, Not Just the Launch Page
A release announcement is optimised for attention. A model card is optimised for disclosure. API documentation is optimised for implementation.
Your decision needs all three, plus pricing, usage policies, licensing terms, independent evaluations, and your own production traces. The documents everybody remembers at the end of procurement are usually the ones that decide whether the product can ship.
Follow Every Reference
One card often points to a parent card, a policy, a technical report, or an evaluation appendix. Follow the references.
Anthropic’s Claude Opus 4.1 addendum, for example, explicitly said this:
The document is "provided for transparency and informational purposes regarding model capabilities and limitations," and "does not define or expand permissible uses (which are governed exclusively by Anthropic's Usage Policy and applicable terms of service)." It also supplements the earlier Claude 4 system card rather than replacing it.
How to Read a Model Card Section by Section
Read the Release in Five Passes
Do not read from top to bottom once and call it done. Each pass asks a different question of the same evidence.
First pass: what exactly was tested?
Things to pay attention to:
exact model and version
base, derived, instruction-tuned, or post-trained relationship
license, access terms, training-data cutoff, disclosed recency
API, chat product, coding agent, or another surface
reasoning, verbosity, temperature, and other settings
system prompt and evaluation prompt
retrieval, memory, compaction, tools, permissions
retries, parallel samples, selectors, validators
safety filters and monitors
evaluation date, and who ran it: provider, community, or third party
Pro tip: A product name can be a topology.
OpenAI’s GPT-5 system card described a real-time router choosing between a fast main model and a deeper reasoning model, with smaller variants handling remaining queries after usage limits. A result for one component did not automatically describe every answer produced by the branded product.
So ask whether each result measures the bare model, the model with system instructions, or the deployed system with safeguards and tools.
Those are three different objects.
The same problem shows up in agent evaluations. OpenAI’s 2026 evaluation playbook defines the surrounding prompt, tools, memory, retries, interfaces, and control logic as the harness. So if you change the harness, you can change the observed capability.
Second pass: find assumptions hiding inside the claims
Release language compresses conditions. Your job is to put them back.
Say the announcement reads:
Our new model is the best coding model, supports one million tokens, and costs 50% less.
As a PM, you should understand:
Best on which coding tasks, languages, repositories, and environments?
First attempt, or best result after several attempts?
With which agent harness, tools, test runner, and reasoning budget?
Does “one million tokens” describe maximum capacity, or the ability to find and combine the right evidence across that span?
Fifty percent cheaper per token, per request, or per successful task after longer outputs, retries, tool calls, and validation?
Compared with which model, at which price date, in which configuration?
Once you do that, the announcement becomes specific enough to use.
A small dictionary of model launch language
Release language does work. It directs budgets, roadmaps, status, attention, and permission.
Launch phrase: “Can complete”
What it may mean: The capability appeared under some conditions
What to ask next: How often, on the first try, with which support?
Launch phrase: “State of the art”
What it may mean: a leading score on selected tests
What to ask next: were tasks, budgets, tools, and graders comparable?
Launch phrase: “Up to”
What it may mean: a maximum or an upper bound
What to ask next: what do median, p95, and the failure distribution look like?
Launch phrase: “Safer”
What it may mean: improvement against a defined policy or test
What to ask next: safer for whom, against which threat, with which false blocks?
Launch phrase: “Human-level”
What it may mean: parity with a selected human baseline
What to ask next: which humans, with which tools, time limits, and scoring rules?
Launch phrase: “Long context”
What it may mean: a large maximum token capacity
What to ask next: how much of it can the system use reliably, with distractors and the evidence buried in the middle?
Launch phrase: “Agentic”
What it may mean: the system can act across several steps
What to ask next: which permissions, stops, approvals, and rollback paths exist?
Launch phrase: “Cheaper”
What it may mean: one price unit decreased
What to ask next: what is the cost per acceptable outcome at production volume?
Launch phrase: “Early users say”
What it may mean: a useful hypothesis and a testimonial
What to ask next: what does controlled or representative evidence show?
How to find the assumptions hiding inside the claim
For every sentence that matters, ask two questions in order.
What must be true for this claim to justify our decision?
What is the cheapest credible observation that would prove it false?
Third Pass: Interrogate the Benchmark
A benchmark score is an observation produced by a particular test.
This pass will take the longest. But as an AI PM, you should understand:
What claim was the evaluation designed to support?
The OpenAI evaluation playbook separates three:
Capability elicitation: Can the system plausibly produce the capability being evaluated?
Safeguard performance: How robust are the tested safeguards against the behaviour or attack being evaluated?
Comparison: How do different systems perform under equivalent conditions?
What complete setup produced the score?
The setup can move a lot.
Example: Anthropic documented that small MMLU formatting changes produced about a 5% change in accuracy, and that labs used different prompting methods on the supposedly same benchmark. The UK AI Security Institute’s cyber-range evaluation found gains of up to 59% when the inference budget increased from 10 million to 100 million tokens. Performance was still rising at the largest budget, so the evaluation did not establish a capability ceiling.
Is it pass@1 or pass@k?
pass@1estimates the probability that a sampled completion succeeds.pass@kestimates the probability that at least one of k sampled completions passes the benchmark verifier.
Example: The Codex evaluation paper reported 28.81% pass@1 and 72.31% pass@100 for Codex-12B on HumanEval, with the sampling temperature tuned separately for each metric. The pass@100 evaluation used an oracle-style verifier: the evaluator knew which sample passed the unit tests. If your product returns one answer without an equally capable verifier, pass@100 does not describe the user experience.
Does this benchmark apply to my use case?
Compare the evaluation distribution with your production distribution:
user type and expertise
language and geography
domain and terminology
input length, messiness, and missing information
adversarial or manipulative inputs
single-turn versus long workflow
simulated versus real tools
reversible versus consequential actions
Stanford’s HELM work argues for measuring accuracy, calibration, robustness, fairness, bias, toxicity, and efficiency across scenarios defined by task and domain.
For tool-use claims, ask what “success” means. Valid function-call syntax is not the same as choosing the right tool. Choosing the right tool is not the same as changing the correct state, obeying domain policy, recovering from a tool error, or completing a multi-turn user goal.
Does a large context window mean the model can use all of it reliably?
No. A context window is the total token capacity available to one request, including input, output, and reasoning tokens. Memory is a separate product mechanism that stores or retrieves information across turns or sessions. A large context window does not guarantee durable memory, and stored information does not help unless the system brings the right parts back.
A context window specifies maximum token capacity, commonly shared by input and generated output. It does not promise equal use of every token.
Read that again with a product hat on. The number on the pricing page and the number you can use are not the same number.
The Lost in the Middle study found that the evaluated models often performed best when relevant information appeared near the beginning or the end of a long context, with performance falling when the evidence sat in the middle.
RULER evaluated 17 long-context models. Although they were nearly perfect on simple needle retrieval, almost all deteriorated as length and task complexity increased. At 32K, only half exceeded the paper’s chosen 85.6-point threshold.
If your product reads contracts, research libraries, support histories, or codebases, test evidence placement, distractors, contradictions, tables, repeated entities, and multi-document reasoning.
Further reading:
Could the benchmark be contaminated?
A test can look independent even when the AI has already seen the questions, answers, code, or online discussions during training.
Research on rephrased test samples found that simple paraphrasing or translation could bypass string-matching decontamination. Exact-string deduplication does not catch semantic overlap.
The same paper reports that a 13B model trained on rephrased test variations reached performance “on par with GPT-4” on the benchmark, and that 8 to 18% of HumanEval overlapped with widely used pre-training datasets. Which is worth holding next to every HumanEval number you have ever been shown.
Check when the data was created, if it was public before the training cutoff, how contamination was tested, and if the result reproduces on private, post-cutoff, or freshly authored tasks.
Who graded the answer?
A grader may be an expert, a crowd-worker, another model, a test suite, or a rule. Each fails differently.
Example 1: Anthropic got a zero bias score before discovering that the models were not answering the questions. In Anthropic’s words, the results were “technically unbiased, but they were also completely useless.”
Example 2: In February 2026, OpenAI audited 138 SWE-bench Verified tasks that its models frequently failed and stopped reporting the benchmark. It found material problems in the test design or task description in 59.4% of the audited tasks.
The same audit found evidence of contamination: the frontier models tested could reproduce either exact gold patches or verbatim task details for at least some problems. OpenAI also found that prior exposure made models more likely to solve underspecified tasks.
So one headline benchmark was simultaneously rejecting some correct work and rewarding some prior exposure while the industry treated it as a standard signal.
The lesson for PMs: a precise number can measure the wrong thing. Ask for grader instructions, agreement with blinded experts, unscorable (is that a word?) cases, manual error analysis, and controls for order or verbosity bias.
Where are the error bars and the slices?
Statistical significance is not product significance. Great questions to ask:
How many tasks and runs produced the score?
Is there a confidence interval for the difference?
Would the ranking survive another prompt or seed?
Are results broken down by language, difficulty, user group, and failure type?
Does the improvement reduce severe errors, or polish already acceptable cases?
What did the score cost in time and compute?
A great headline result can hide how much work the model did behind the scenes: longer answers, extra reasoning, more tool use, multiple attempts, retries, and a final check.
OpenAI’s latency guidance puts numbers on it. “Cutting 50% of your output tokens may cut ~50% of your latency,” while “cutting 50% of your prompt may only result in a 1-5% latency improvement.”
Generation is usually the largest latency component. A model that produces long answers or reasoning traces may therefore remain slow even after you trim the prompt; prompt trimming alone is unlikely to offset that output cost.
The lesson for PMs: Record median and p95 end-to-end latency, total billed tokens, tool and verifier cost, retry rate, and cost per successful outcome.
Fourth pass: limitations usually tell you what the product has to add.
I see many people reading the headline, scanning the benchmarks, and then skimming the limitations.
Reverse it.
Pro tip: Agree with your team on terminology first.
A limitation is a boundary or weakness in behaviour.
A risk combines likelihood and consequence of harm in a context. Its source may be a limitation, ordinary operation, misuse, a dependency, an incentive, or an interaction.
A bias is a systematic difference that may create unequal performance or treatment.
A mitigation reduces a risk. It rarely deletes it.
Residual risk is what remains after the mitigation works as designed.
The NIST Generative AI Profile warns against drawing big conclusions from narrow tests or a few examples. It recommends testing AI in conditions that resemble real use, with representative users, and continuing to monitor what happens when people and AI work together.
Fifth pass: map the whole system
The model is just a component. Your product is a system.
Multi-step systems need trajectory thinking
Agent announcements love to say a model can work for longer without human help.
Persistence is useful. It also gives the system more chances to misunderstand the goal, misuse a tool, meet hostile content, or compound an earlier error.
Toy maths makes the point. If ten critical steps were independently 95% reliable, the chance of all ten succeeding would be about 60%:
0.9510≈0.599
Real failures are not independent, so do not use this as a forecast. Use it as an antidote to reading per-step accuracy as workflow reliability.
Don’t confuse succeeding once with succeeding consistently. In the 2024 τ-bench study of tool-using AI agents, GPT-4o scored 61.2% in retail and 35.2% in airline, producing a reported 48.2% average across the two domains. In retail, every tested model’s pass^8, the estimated chance that all eight independent trials succeeded averaged across tasks, fell below 25%. This is the opposite of pass@k, which asks whether any of the attempts worked.
For a workflow you want to run again and again, consistency matters more than one impressive run.
OpenAI made a similar point in its 2026 account of deploying a long-running model. Some failures appeared only during limited deployment, not in pre-deployment tests. OpenAI paused access, built incident-derived evaluations and trajectory-level monitoring, then restored limited access with stronger controls.
The lesson for PMs: For products that let AI take actions, ask two questions:
Is each individual action allowed?
What is the full sequence of actions trying to achieve?
The second question catches plans that look harmless one click at a time but become risky when you look at the whole chain.
Map the feedback loop around the claim
The trust loop
More fluent output increases trust. More trust reduces checking. Less checking lets subtle errors survive. Unlabelled errors preserve the appearance of reliability, which feeds more trust.
NIST names automation bias and over-reliance among human-AI configuration risks. The PM response is not a warning banner nobody reads. It is inspectable evidence, validated uncertainty signals, meaningful friction, sampling, and recourse.
The volume loop
Faster generation produces more output. More output creates more review, storage, support, moderation, and correction work. Teams respond to that load with more automation, which makes still more output possible.
A feature can save 30 seconds per item while creating three new queues downstream.
The permission loop
Better tool use encourages broader access. Broader access produces more visible value, which creates pressure for still broader access.
Usefulness and blast radius grow together. Least privilege, scoped credentials, confirmation thresholds, and audit trails become product features.
The skill loop
As the system performs more of the task, people practise less of it. Their ability to supervise declines, which encourages further reliance precisely when the remaining edge cases get harder to catch.
Agentize the tasks, but keep independent judgment at high-consequence checkpoints.
If the reviewer can’t assess the output independently, redesign the control.
The dependency loop
Several teams adopt the same provider, model family, or evaluation assumption. Each integration raises switching cost, which encourages the next team to use the established dependency too.
Local redundancy starts to look rather decorative when every fallback shares the same upstream failure.
Track portfolio concentration, provider change rights, migration cost, and correlated risk. Vendor strategy is system design too.
Ignore, Watch, Sandbox, or Stage
After the five passes, make one of four decisions:
Ignore: There is no relevant use case, or a disclosed boundary already makes the model unsuitable. Record why and move on.
Watch: The use case is plausible, but the evidence, access, pricing, or product need is not ready. Record what would trigger another review.
Sandbox: The use case survives the first four links, but the claims still need your own bounded evaluation. Test away from users and consequential systems.
Stage: The configured system meets your acceptance criteria on representative tasks. Release it to a limited cohort with monitoring, rollback, and support ready.
Monitor What Happens After Launch
Monitoring is the evidence chain after deployment. Watch the user outcome you defined in link one, the slices where performance may differ, the assumptions you accepted, and the failure costs the benchmark could not represent.
Track more than model accuracy: complaints, appeals, overrides, abandonment, severe errors, latency, cost, tool failures, and which people absorb the correction work. Re-run the decision when the model snapshot, prompt, tools, policy, price, user population, or workflow changes materially.
Set pause and rollback thresholds before the incident. Then keep remediation separate. Rollback limits further exposure. Remediation repairs what already happened.
Five Distinctions Every AI PM Should Make Before Choosing a Model
Model behaviour is not product behaviour. Your user experiences a configured system, usually with prompts, retrieval, tools, routing, safeguards, interface choices, and other humans attached.
Intended use is not demonstrated use. It tells you what the developer had in mind, not whether the model meets your acceptance criteria.
Out of scope is not the same as prohibited or unlicensed. The card, the usage policy, the license, the contract, and the law answer different questions.
Training data and evaluation data do different jobs. One shapes the model. The other supports a performance claim. Overlap inflates the claim.
A capability benchmark is not automatically a safety evaluation or a product KPI. Each one measures a different object for a different decision.
FAQs
What are the biggest AI model card red flags?
The biggest one is a strong claim with no clear tested system, task distribution, grader, denominator, uncertainty, evaluation authorship, or update history.
Others: benchmark contamination, undisclosed best-of-many sampling, comparisons run with different harnesses or budgets, and mitigations described without residual risk.
Are provider benchmark scores enough to choose an AI model?
No. They can shortlist models and reveal capabilities worth testing.
Selection requires evaluating the configured system on representative tasks, with your users, constraints, failure costs, latency, and budget.
What should a product manager read first in a model card?
Read the exact model and version, intended and out-of-scope uses, evaluation setup, limitations, and update date. Then look at benchmark results.
That order gives the number a boundary before the number gives you an opinion.
How do I compare two AI model cards fairly?
Normalise the task, data, prompt, harness, tools, attempts, inference budget, metric, grader, latency, cost, and evaluation date.
If those conditions differ, do not rank the headline scores. Re-run the systems under one decision-relevant protocol, or state clearly what remains incomparable.
When should a PM run local evals?
Run them when the release could materially change a user outcome, an architecture, a cost, or a risk decision.
Skip them when there is no relevant use case, or when the disclosed limitations already make the model unsuitable.
What is the evidence chain?
It is the order I read a release in: use, evidence, system, assumptions, decision, monitoring. Six links, borrowed from chain of custody, where a single broken handoff makes the evidence inadmissible.
A provider’s benchmark result has to survive every handoff before it says anything about your users. Most launches break at assumptions, because that is the only link nobody owns by default
I read the model cards and follow the footnotes. Subscribe to for more practical ways to test AI claims before they become product decisions.