Model Card Value Section¶
Template — instantiates Normative Assumption Explicitness
Adds explicit value assumptions, intended uses, excluded uses, affected groups, and evaluation priorities to technical documentation for AI or analytic systems.
A Model Card Value Section is a standardized block of fields added to a technical system's own documentation — the model or dataset card — that declares, up front and shipped with the artifact, the value assumptions baked into it. Its distinctive character is that it is forward-looking and attached: rather than reviewing a past decision, it travels with the model as a standing declaration, so that any downstream user meeting the system inherits an explicit statement of what its target label assumes ought to count as success, where it is meant and not meant to be used, who is affected, and what should trigger re-examination. It is a template — a set of blanks to fill — which is both its strength (repeatable, comparable across systems) and its risk (blanks can be filled thoughtlessly).
Example¶
A property-management firm builds an ML model that scores rental applicants, and its documentation includes a value section rather than only accuracy tables. The section states the embedded value assumption plainly: the target label is "no missed payment within 24 months," which encodes the assumption that past payment stability ought to define tenant desirability — a value choice, not a fact about good tenancy. It names the affected groups the choice lands hardest on: applicants with thin credit files, recent immigrants, and survivors leaving a shared account with damaged joint credit. It draws the scope line explicitly — intended use: an advisory input a human reviewer weighs; excluded use: automated denial with no human review — so the assumption's valid context is fixed rather than assumed universal. And it sets review triggers: a fair-housing complaint, measurable score drift, or deployment in a new jurisdiction.
Because the section ships in the model card itself, a downstream product team that later wants to wire the score straight into auto-rejections meets the excluded-use line first, not after a lawsuit.
How it works¶
- Declare the label's value assumption. State what the target/label treats as good, framed as a normative choice rather than a neutral objective.
- Draw intended and excluded uses. Fix the scope where the assumption is valid, and name the uses it must not be stretched to cover.
- List affected groups. Identify who the value choice benefits and who it burdens, especially at the tails.
- Set review triggers and evaluation priorities. Record what evidence would reopen the value choice and which evaluation metrics are prioritized because of it.
Tuning parameters¶
- Field granularity — how finely the value assumptions are itemized. Finer detail is more informative but heavier to maintain across model versions.
- Excluded-use specificity — how concretely off-label uses are named. Specific exclusions are enforceable; vague ones are decorative.
- Sign-off level — who must approve the section. Higher sign-off adds weight but slows release.
- Version coupling — how tightly the section is bound to model versions, so a retrained model cannot ship with a stale value declaration.
When it helps, and when it misleads¶
Its strength is making the value choice inside a technical system legible to the people downstream who would otherwise treat the score as objective — it puts the assumption where the next engineer will trip over it. It extends the model-card tradition of structured reporting from performance into values.[1]
Its failure mode is the box-ticked template: excluded uses that nobody enforces, affected-group lists that never touch access controls, a value section written to signal responsibility while the model ships unchanged. The classic misuse is documentation as absolution — a thorough card standing in for the harder work of constraining the system. The guarding discipline is to bind the excluded uses to real access controls and the review triggers to live monitoring, so the section governs the system instead of merely describing it.
How it implements the components¶
normative_claim— states the value assumption embedded in the target label, naming what the model treats as success.scope_condition— the intended/excluded-use fields fix the contexts in which the value assumption is valid and bar its silent over-extension.affected_party_map— the affected-groups field identifies who the label's value choice benefits and burdens.review_trigger— records the drift, complaint, or context change that should reopen the value choice.
It declares assumptions in a document but provides no forum to contest them (contestation_channel, Stakeholder Deliberation); it documents the value choice rather than arguing its legitimacy (decision_rationale, Policy Rationale Statement) or forensically testing a neutrality claim (legitimacy_check, Value Audit).
Related¶
- Instantiates: Normative Assumption Explicitness — supplies the value declaration attached to a technical system: assumptions, scope, affected groups, and triggers.
- Sibling mechanisms: Value Audit · Metric Value Review · Decision Record · Policy Rationale Statement · Stakeholder Deliberation · Ethics Checklist · Values Statement · Ethical Impact Assessment
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Model Card Value Section operates as a non-executable information artifact that externalizes static or prospective structure because it adds explicit value assumptions, intended uses, excluded uses, affected groups, and evaluation priorities to technical documentation for AI or analytic systems.
Independent corroboration: The frozen evidence defines Model Card Value Section as 'Adds explicit value assumptions, intended uses, excluded uses, affected groups, and evaluation priorities to technical documentation for AI or analytic systems', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Ethics of Technology & AI Governance
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Making affected groups, intended and excluded uses, value assumptions, and evaluation priorities explicit is characteristic responsible-AI governance practice.
Related originating lineages:
- Data Science & Analytics — Model-card practice provides the technical documentation surface being extended.
- Philosophy — Normative ethics supplies the concepts needed to identify and defend value assumptions.
Review resolution: Both independent reviews agree on primary origin tech_ethics_ai_governance; reconciliation resolves secondary fields (reported_ambiguity, alternate_origin_disagreement). Alternate origins retained (philosophy, data_science) are the union of reviewer-supported formative lineages with explicit rationales, not a list of later application domains. Present-day breadth is represented separately as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis records the historical relationship among lineages. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=true preserves either reviewer's finding that the encyclopedia generalized the mechanism.
Attribution caveat: The value-specific section is an encyclopedia synthesis extending established model cards beyond performance reporting.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D., & Gebru, T. "Model Cards for Model Reporting". Proceedings of the Conference on Fairness, Accountability, and Transparency, 220–229 (2019). Introduces model cards as structured, transparent documents for reporting trained-model performance. registry ↩