Anthropic System Card Guide

Phase 3 · Document 03 · Model Cards and System Cards Prev: 02 — Google DeepMind Model Card Guide · Next: 04 — Hugging Face Model Card Guide

Table of Contents

1. Why This Matters
2. Core Concept
3. Mental Model
4. Hitchhiker's Guide
5. Warmup Readings
6. Deep Readings and External References
7. Key Terms
8. Important Facts
9. Observations from Real Systems
10. Common Misconceptions
11. Engineering Decision Framework
12. Hands-On Lab
13. Verification Questions
14. Takeaways
15. Artifact Checklist

1. Why This Matters

Anthropic popularized the system card as a safety-forward release artifact, and Claude is one of the leading models for coding, agents, and enterprise use — so you'll read these cards often. They're the richest public example of the system-card skill: Constitutional AI, capability + safety evaluations, red-teaming, ASL risk levels, and extended thinking behavior. The practical payoffs are concrete: understanding extended-thinking billing/latency, Anthropic's data-retention/no-train posture (a frequent enterprise gate), and how to translate the card into your own guardrails. This guide applies 00/01 to Anthropic specifically.

2. Core Concept

Plain-English primer (read first if any term is new)

• System card vs model card — a model card says what a model can do (capabilities, size, limits). A system card focuses on safety: how the model behaves under stress — what it refuses, how it resists "jailbreaks," what dangerous-use tests were run, and what safeguards exist. Why you care: before shipping to real users you need the safety picture, not just the feature list. → Phase 3.01.
• Constitutional AI (CAI) — Anthropic's training method where the model is taught to critique and revise its own answers against a written set of principles (a "constitution") instead of relying only on human labels. Effect: it shapes why Claude helps with some things and politely refuses others. You don't implement it — you just need to know it explains Claude's refusal style.
• Extended thinking / "thinking tokens" — Claude can do hidden step-by-step reasoning before its final answer. That hidden reasoning is extra generated text: it improves hard tasks but you pay for those tokens and the response is slower. You control how much via a "thinking budget." Use case: enable for hard math/coding/planning; leave off for simple chat or lookups. Example: a tough proof might spend thousands of hidden reasoning tokens before a short visible answer. → Phase 2.09.
• Refusal & over-refusal — a refusal is the model declining a request on policy grounds. Over-refusal is when it wrongly refuses a legitimate request (e.g. refusing a benign security question). Why it matters: over-refusal frustrates users and can break real workflows — it's a product cost, not just a safety setting.
• Jailbreak / prompt injection — tricks that try to get the model to ignore its safety rules (jailbreak) or to obey malicious instructions hidden in input data (injection). Why you care: the system card tells you how resistant the model is, and therefore how much you must defend at the application layer. → Phase 14.
• RSP / ASL (Responsible Scaling Policy / AI Safety Levels) — Anthropic's framework that assigns a model a risk level and requires matching safeguards before release. Plain version: "how risky is this model, and what protections did we attach?" Use case: enterprise risk reviews cite the ASL level.
• Data retention / "no-train" posture — whether the provider stores your inputs/outputs and whether it trains on them. Anthropic's commercial API generally does not train on your data, with retention terms in its commercial/privacy docs. Why it matters: this is frequently the deciding gate for enterprise/regulated data — always confirm the current terms for your contract. → Phase 1.08.

With those defined, this guide is "how to read a Claude system card and turn it into deployment + guardrail decisions."

Where they live, what they emphasize

Anthropic publishes system cards at https://www.anthropic.com/system-cards (plus model pages and API docs). They emphasize:

• Constitutional AI — the training method that shapes Claude's helpful/harmless behavior and refusal style.
• Capability evaluations — coding, reasoning, math, agentic, multimodal performance.
• Safety/dangerous-capability evaluations — high-risk domains tested against the Responsible Scaling Policy (RSP) and AI Safety Levels (ASL) thresholds.
• Red-teaming — internal + external adversarial testing and findings.
• Risk mitigations & deployment policy — classifiers, usage policy, and any safeguards tied to the ASL determination.

Claude-specific things to nail

• Extended thinking. Claude exposes a thinking budget; the model reasons before answering. Thinking tokens are billed and add latency — read the card/docs to understand the budget control and route hard tasks only (Phase 2.09, Phase 1.03).
• Data retention / training posture. Anthropic's commercial API policy is generally not to train on your API inputs/outputs, with retention terms in the Commercial Terms / privacy docs. Confirm the current terms for your contract — this is often the deciding enterprise gate (Phase 1.08, Phase 14).
• Tool use & agents. Claude is strong at tool calling and computer-use/agentic patterns; the card/eval section indicates agentic capability and the safety testing around it (Phase 10).
• Variants & access. Claude has tiers (e.g. Haiku/Sonnet/Opus — fast→capable) and is served via the Anthropic API, Amazon Bedrock, and Google Vertex AI — pricing/regions/data terms vary by channel.
• ASL level. The card states the model's assessed safety level and the safeguards that level requires — useful context for enterprise risk reviews.

The launch lens (same as 01)

Extract: refusal/over-refusal posture, jailbreak/injection findings, agentic-safety notes, the provider-mitigation-vs-your-responsibility split, and the retention terms — then run your own policy evals.

3. Mental Model

ANTHROPIC SYSTEM CARD READ:
  Constitutional AI → why Claude refuses/behaves as it does
  Capability evals  → coding/agentic/reasoning strength
  Safety evals + ASL (via RSP) → risk level + required safeguards
  Red-team findings → residual jailbreak/injection risk → MY guardrails (Phase 14)
  Extended thinking → thinking budget = billed tokens + latency (route hard tasks only)
  Data retention    → no-train posture? confirm contract terms (enterprise GATE)
  Variant + channel → Haiku/Sonnet/Opus × API/Bedrock/Vertex → cost/region/data differ

Read the card for SAFETY POSTURE; still run YOUR policy evals.

4. Hitchhiker's Guide

What to read first: refusal/over-refusal behavior, extended-thinking billing, and the data-retention posture — the three that most often shape product and procurement.

What to ignore at first: deep RSP/ASL governance prose; note the headline ASL level and move on.

What misleads beginners:

• Treating extended thinking as free quality — it's billed thinking tokens + latency.
• Assuming a data-retention posture without checking current commercial terms for your contract.
• Reading "safe per the card" as "no guardrails needed" — you still own input/output validation and audit.
• Ignoring over-refusal, which can frustrate legitimate Claude use.

How experts reason: they map system-card findings to guardrails and routing (extended thinking only for hard tasks), confirm retention terms against the contract, pick the Claude tier + channel by cost/region/data needs, and verify with their own evals.

What matters in production: thinking-budget control, retention/region terms by channel (API vs Bedrock vs Vertex), agentic-safety guardrails, and over-refusal handling.

How to verify: probe over-refusal and injection on your content; measure extended-thinking cost/latency vs quality on your hard tasks; confirm retention terms in the signed agreement.

Questions to ask: What ASL level and required safeguards? Current data-retention/no-train terms for my channel? Extended-thinking billing and budget control? Over-refusal rate? Channel-specific regions/pricing?

What silently gets expensive/unreliable: blanket extended thinking; assuming stale retention terms; over-refusal in production; treating provider safety as a substitute for app-side guardrails.

5. Warmup Readings

6. Deep Readings and External References

7. Key Terms

8. Important Facts

• Anthropic publishes system cards centered on safety: capability + safety evals, red-teaming, mitigations, and ASL level.
• Constitutional AI shapes Claude's refusal/helpfulness behavior.
• Extended thinking uses a billed thinking budget and adds latency — route hard tasks only.
• Anthropic's commercial API policy is generally not to train on your inputs/outputs — but confirm current terms for your contract.
• Claude has tiers (Haiku/Sonnet/Opus) and is served via Anthropic API, Bedrock, and Vertex with channel-specific pricing/regions/data terms.
• The card states an ASL level and the safeguards it requires — useful for enterprise risk reviews.
• "Safe per the card" ≠ "no guardrails" — you still own app-side validation, permissions, and audit.
• Pin versioned model IDs and verify behavior with your own evals.

9. Observations from Real Systems

• Claude is widely used for coding and agentic workloads; system-card eval sections highlight these strengths and the safety testing around agentic use (Phase 10/11).
• Bedrock/Vertex resell Claude with enterprise regions/governance — a channel decision like Gemini's (02).
• Extended thinking appears in latency dashboards as long, decode-heavy requests (Phase 2.07).
• Enterprise procurement routinely cites Anthropic's no-train/retention posture as a deciding factor.
• AI gateways add the app-side guardrails the system card says are your responsibility (Phase 8/14).

10. Common Misconceptions

11. Engineering Decision Framework

Adopting Claude:
  1. VARIANT by need: Haiku (fast/cheap) · Sonnet (balanced) · Opus (max capability).
  2. CHANNEL by compliance: Anthropic API (simple) · Bedrock/Vertex (enterprise regions/data).
  3. DATA GATE: confirm retention/no-train terms for that channel/contract (Phase 14).
  4. EXTENDED THINKING: enable + budget ONLY for hard tasks; route the rest cheaply (Phase 2.09).
  5. GUARDRAILS: from red-team/refusal findings, build app-side controls (Phase 14).
  6. VERIFY: run your policy + capability evals; pin versioned ID; write a memo (Doc 07).

12. Hands-On Lab

Goal

Turn a current Claude system card into an enterprise-readiness + cost/latency assessment, including an extended-thinking trade-off measurement.

Prerequisites

• A current Claude system card; an Anthropic (or Bedrock/Vertex) API key.

Steps

1. Read a recent Claude system card. Extract: refusal posture, red-team/jailbreak findings, ASL level + required safeguards, and listed mitigations.
2. Confirm the data-retention/no-train terms for your intended channel; note them in a readiness paragraph.
3. Measure extended thinking: run an easy and a hard task with thinking off vs on (budgeted); record quality, latency, and (thinking) token cost (reuse Phase 2.09 lab).
4. Build the provider-vs-you responsibilities table for your use case.
5. Write a one-page readiness + routing note: which tier/channel, when to use extended thinking, and required guardrails.

Expected output

A safety extraction, retention note, extended-thinking trade-off table, responsibilities table, and a readiness/routing decision.

Debugging tips

• Thinking tokens not visible? Check the response's usage details; some channels report them separately.
• Over-refusal on benign prompts? Tune your prompt and note it as a UX consideration.

Extension task

Compare the same tasks on Claude vs a Gemini variant (02) — quality/cost/latency — to inform cross-lab routing.

Production extension

Add Claude over-refusal/injection probes to your eval harness and gate model/version changes on the results.

What to measure

Over-refusal rate; extended-thinking quality gain vs latency/cost; retention terms; guardrails you must own.

Deliverables

• A Claude readiness note (retention + ASL + guardrails).
• An extended-thinking on/off trade-off table.
• A tier/channel/routing decision with a selection memo (Doc 07).

13. Verification Questions

Basic

1. What does an Anthropic system card emphasize beyond capabilities?
2. What is extended thinking, and how is it billed?
3. What is the ASL/RSP framework, in one sentence?

Applied 4. An enterprise requires no training on its data. How do you confirm Claude meets this? 5. When should you enable extended thinking, and when not?

Debugging 6. Latency and cost jumped after enabling thinking for all requests. Fix it. 7. Claude refuses a legitimate workflow. Where in the card is this anticipated, and what's your response?

System design 8. Design a Claude deployment for a regulated enterprise: tier, channel, retention, guardrails, and routing.

Startup / product 9. Use Anthropic's system card + your guardrails to answer an enterprise buyer's safety/data questionnaire.

14. Takeaways

1. Anthropic system cards are the leading example of safety-forward disclosure (Constitutional AI, evals, red-team, ASL).
2. Extended thinking = billed thinking tokens + latency — route hard tasks only.
3. Confirm the data-retention/no-train terms for your channel/contract — often the enterprise gate.
4. Pick the Claude tier and channel (API/Bedrock/Vertex) by cost, region, and data needs.
5. "Safe per the card" ≠ "no guardrails" — own app-side controls.
6. Verify with your own evals; pin versioned IDs; write a memo.

15. Artifact Checklist

• Claude readiness note (retention + ASL + guardrails).
• Extended-thinking on/off trade-off table.
• Provider-vs-you responsibilities table.
• Tier/channel/routing decision + selection memo (Doc 07).
• Eval integration: over-refusal/injection probes.
• Notes: Anthropic system-card specifics (CAI, ASL, thinking, retention).

Next: 04 — Hugging Face Model Card Guide