System Card

A system card documents an AI system at the deployment level rather than only the underlying model. It can describe how models, safety layers, tools, policies, and product constraints work together.

System cards commonly summarize evaluations, risk areas, mitigations, observed limitations, and release decisions. Because a product may differ substantially from a raw model, system-level documentation can reveal information that a Model Card alone does not capture.

System cards improve transparency around real deployments and create a record of what was tested before release. Their usefulness depends on specificity, evidence, and updates as the system changes.

See also Model Card, Safety Evaluation, and Red Teaming.

Assume a fictional AI document assistant combines a base model, document retrieval, output filtering and a draft-saving tool. Record which components receive input, which material reaches the model and who may request saving. Specify the example boundary between draft creation and separately controlled public publication. This is not a description of actual ORBiS Tree implementation or a particular product configuration.

Connect model characteristics, data paths and tool authority. The Meta system-transparency study ↗ proposes System Cards to explain component interactions and information use.^[1] Describe transfer, storage and access boundaries rather than listing components alone.

These are different conditions for the same ten fictional questions. Supplying correct evidence directly to the model produces nine correct answers: 90%. In the complete retrieval path, eight questions retrieve correct evidence and six of those produce correct final answers. Evidence retrieval success is 8 / 10 = 80%, answer success conditional on retrieval is 6 / 8 = 75%, and end-to-end success is 6 / 10 = 60%.

Different evidence conditions mean model and service scores are not interchangeable experiments. Separate retrieval misses from misreading retrieved evidence, and record tool-saving or authorization outcomes separately. These small illustrative counts are not product success rates or general performance targets.

Suppose a teaching bundle contains model m1, index i3, instructions p5, filter f2 and tool t4. Keeping m1 while replacing i3 with i4 still requires updated source, retrieval and answer evaluation. Changing tools or permissions requires checks of allowed/denied actions, duplicate writes and uncertain timeouts. The identifiers are fictional, not actual service settings.

Retain the previous bundle and recovery point, reason for change, evaluation date/data, expected and observed outcomes, remaining failures and responsible actions. Previous red-team results do not automatically cover new tools. Without a link between report version and deployed configuration, readers cannot identify the system that was evaluated.

The internal algorithmic-auditing study ↗ proposes connecting lifecycle decisions with stage-specific records.^[2] Link evaluation coverage, excluded languages or situations, mitigations and residual limits. Distinguish public documentation from access-restricted reproduction records rather than copying unnecessary personal information or production secrets into a public report.

A document is not certification or proof that all risk has been removed. Reproducible findings linked to the actual configuration and update date let users distinguish observed behavior from untested areas.