What this prompt does
This prompt writes a model card for a production classifier that is honest and specific enough to survive an audit — governance documentation, not marketing copy. It casts the AI as an ML engineer writing for governance review. You provide the [model_name], the [use_case], the fairness [slices], and the [regulatory_context]. It returns a labeled card: purpose and model type in plain language, training-data size, source, distribution, and gaps, intended and out-of-scope use, evaluation metrics reported overall and sliced, known limitations and fairness considerations tied to the regulation, and an update cadence with a monitoring plan and named owner.
The card is what makes a system defensible when someone asks why it decided something. Sliced metrics are non-negotiable: an aggregate number hides exactly the disparities a reviewer cares about, so reporting performance by each [slices] dimension surfaces them. The limitations section is the part auditors actually read, which is why the prompt pushes you to fill it honestly rather than downplay weaknesses.
When to use it
- Documenting a classifier that touches money, access, or other regulated decisions
- Preparing for a governance review under a specific
[regulatory_context] - Reporting metrics sliced by fairness dimensions, not just an aggregate
- Writing an honest limitations section that survives an audit
- Defining a monitoring plan with alert thresholds and a named owner
- Stating intended and explicit out-of-scope use to bound liability
Example output
You get a labeled model card in a fixed order: purpose and model type, training data (size, source, distribution, gaps), intended and out-of-scope use, evaluation metrics overall and sliced by your dimensions, known limitations and fairness considerations tied to the regulatory context, and an update cadence plus monitoring plan with alert thresholds and a named owner. It reads as plain, regulator-ready documentation.
Pro tips
- Name every fairness dimension in
[slices]— country, card type, merchant category — so the metrics section reports each one rather than a single aggregate that hides disparities - State the
[regulatory_context]precisely (e.g. EU, GDPR, fair-lending) so limitations and fairness notes map to the rules a reviewer applies - Fill the limitations section honestly; auditors read it closely, and understated weaknesses are exactly what a review probes
- Describe training-data gaps openly, since an omitted gap undermines the whole card's credibility once discovered
- Assign a real owner in the monitoring plan — an unnamed owner is the first thing a governance review flags
- Reuse the card structure across models so reviewers always find the same sections in the same order
- Spell out intended and out-of-scope use explicitly; bounding what the model should not be used for is what limits liability when someone misapplies it