# AI System Card
Document what your deployed model does, where it fails, and who owns it.

_A standard system card you publish alongside any model that ships to production. Forces you to name limits, owners, and monitoring before launch._

Used in: Lesson expert/07 — https://vetslearn.com/lessons/expert/07
Source: https://vetslearn.com/resources/templates/engineering#t-system-card

---

# System Card: [SYSTEM NAME]

**Version:** [VERSION]
**Deployed:** [DEPLOYMENT DATE]
**Next review:** [REVIEW DATE]
**Owner:** [OWNER TEAM] ([OWNER EMAIL])

---

## 1. System overview

*Fill this in: one paragraph. What the system does, what model powers it, who uses it. Plain words.*

- Base model: [MODEL]
- Wrapper / pipeline: [RAG, agent loop, fine-tune, plain chat]
- Primary interface: [API, web app, internal tool]

## 2. Intended uses

*Fill this in: bullet the 3-5 concrete tasks this system is built for. Be specific. "Summarize claims documents under 20 pages" beats "document understanding."*

- [Use 1]
- [Use 2]
- [Use 3]

## 3. Out-of-scope uses

*Fill this in: what this system must NOT be used for. Name them. Legal advice, medical diagnosis, autonomous decisions on people, classified data, etc.*

- [Out-of-scope 1]
- [Out-of-scope 2]

## 4. Training data summary

*Fill this in: if you fine-tuned, name the dataset, size, source, and license. If you use a base model only, say so and link the vendor's data sheet.*

- Base model training data: [vendor disclosure link]
- Fine-tune data: [source, size, license, date range]
- Retrieval corpus (if RAG): [source, size, refresh cadence]

## 5. Evaluation results

*Fill this in: name the eval set, the metric, and the score. Include date. If you do not have an eval set, that is the first thing to fix.*

| Eval set | Metric | Score | Date |
|---|---|---|---|
| [name] | [accuracy / pass@1 / human rating] | [score] | [date] |

## 6. Known limitations

*Fill this in: where the system breaks. Be honest. "Fails on tables longer than 50 rows." "Hallucinates citations for questions outside the corpus."*

- [Limit 1]
- [Limit 2]

## 7. Bias and fairness

*Fill this in: groups you tested across, what you found, what you did about it. If you did not test, say so.*

- Groups tested: [list]
- Findings: [text]
- Mitigations: [text]

## 8. Security considerations

*Fill this in: prompt injection posture, data handling, PII exposure, auth model, logging policy.*

- Input filtering: [yes/no, what]
- Output filtering: [yes/no, what]
- PII handling: [text]
- Auth: [text]

## 9. Monitoring plan

*Fill this in: what you watch, where it lives, who pages.*

- Metrics: [latency, error rate, refusal rate, cost per call]
- Quality signals: [thumbs, eval drift, sampled human review]
- Alert thresholds: [text]
- On-call: [team or rotation name]

## 10. Owners and points of contact

- Product owner: [name, email]
- Engineering owner: [name, email]
- Security contact: [name, email]
- Incident channel: [#slack-channel or pager]

## 11. Version history

| Version | Date | Change |
|---|---|---|
| [VERSION] | [DEPLOYMENT DATE] | Initial deploy |

---

## How to use

Publish the system card in the same repo as the deployment code. Update it on every model version bump or eval refresh. If a section is empty, that is a finding — fix it before launch, not after. Pair this with the risk register and threat model for federal reviews.

## Check before you use it

- No empty sections at launch. An empty section is a finding, not a formatting choice.
- The eval table holds a real set, score, and date — not a plan to have one.
- Owner emails are current. Post once in the incident channel to confirm it is live.
- Re-read the limitations section against the latest eval run, not the launch run.