Transparency, explainability, and model cards for LLM systems

Three words get used interchangeably and should not be.

Transparency is about the system. Explainability is about one output. Interpretability is about the mechanism. The exam cares about the first two; the third is research depth this associate-level exam confirms as unnecessary.

Here is the fact that makes explainability tractable in an LLM system, and it is the most useful engineering insight in the lesson. You cannot explain why a transformer produced a particular token. No practical method turns billions of parameters and an attention pattern into "because clause 4.2 said so," and any option promising that is wrong. But in a grounded, retrieval-based system you do not need to. You can answer the question the affected person is actually asking — on what basis? — by naming the retrieved passages the answer was built from.

Provenance substitutes for interpretability. That is why RAG appears in transparency answers as often as it appears in hallucination answers, and why the citation requirement introduced in 07-11 as an accuracy control is simultaneously the explainability control here. A cited answer is checkable by a non-specialist: they read the source, and they can agree or object. A confident unsourced answer is unfalsifiable, and unfalsifiable is the opposite of transparent.

L1 — The intuition: transparency is a set of documents plus a habit

The documents are the model card, the data card, and the intended-use statement. The habit is citing sources and disclosing that the system is an AI. Neither half works alone: cards without citations mean nobody can check an individual answer, and citations without cards mean nobody knows what the system is for or where it is known to fail.

L2 — The mechanism: what goes on a model card

A model card is a short structured document that travels with a model and states what it is, what it is for, how it was evaluated, and where it should not be used. It is written for someone deciding whether to rely on the model, not for someone reimplementing it. The sections you should be able to name:

Two constraints on a good card. It must be honest about limitations, because a limitations section listing nothing is read — correctly — as evidence that nobody looked. And it must be versioned with the model, because a card describing last quarter's checkpoint is worse than no card: it is confidently wrong.

A data card is the same idea for a dataset: what it contains, how it was collected, whose data is in it, what consent basis it rests on, how it was labelled and by whom, what was filtered out, what populations it under-represents, and what it must not be used for. In a RAG system the data card describes your corpus — sources, ingestion dates, provenance tiers, refresh cadence, coverage gaps — and it is the document that makes "the assistant did not know about that" explainable rather than mysterious.

NVIDIA's Model Card Generator automates model-card production, so that cards get produced consistently and kept current rather than being a document one person writes once and nobody updates. For the exam, the identity statement is what matters: Model Card Generator = automated model cards for transparency and compliance. If a scenario describes a need for standardized model documentation at scale, that is the named tool.

L3 — Explainability without interpretability: what an LLM answer can actually justify

Rank the explanations you can honestly offer for a generated answer, strongest to weakest.

1. Cited retrieved sources (strongest, and available to you today). "This answer is based on these three passages, from these documents, dated these days, from these sources." A non-specialist can open them. This is the explanation the Transparency pillar's non-technical clause is satisfied by, and it is the only one that scales.

2. The decision trace of the surrounding system. Which retrieval ran, which filters applied, which rail fired, whether a human reviewed. In an application where the model is one component among several, most of the decision lives in the deterministic parts, and those parts are fully explainable. Do not surrender explainability for the whole pipeline because one component is opaque.

3. Structured, constrained output. If the system emits fields — a category, a confidence band, a list of factors considered — each field is inspectable. This is the 05-05 structured-output technique reused as a transparency mechanism.

4. A model-generated rationale (weakest, and the trap). Asking the model "why did you say that?" produces a fluent, plausible narrative that may have nothing to do with the computation. It is generated text about a previous generation, not an audit of it. Chain-of-thought output is a useful reasoning aid — that is 05-03's subject — but treating it as a faithful account of the mechanism is a category error. Any exam option offering "ask the model to explain its reasoning" as the way to satisfy an explainability requirement is a distractor, and this is the most commonly missed item in this lesson.

5. Attribution and interpretability methods. Real research, not a practical control for a production LLM service, and out of scope at this exam's depth.

So the design rule: build systems whose explanation lives outside the model. Retrieval gives you provenance. Deterministic pipeline stages give you a trace. Structured output gives you inspectable fields. What remains genuinely unexplainable is the token-level generation, and you disclose that as a limitation rather than papering over it with a generated rationale.

The distinction that decides exam items: a technical report is not a transparency artifact under this pillar. Publishing architecture and benchmark tables serves researchers. The pillar asks for explanation in non-technical language to the people affected. A question that offers "publish a detailed technical report" against "provide the user with a plain-language explanation and the sources used" is testing exactly that, and the second is keyed.

The second distinction: a model card is about a model; a system card is about what you deployed. In a RAG application, most of the trust-relevant behaviour is in the parts that are not the model — the corpus, the retrieval scope, the rails, the human-review step. A model card alone under-describes such a system, which is why mature deployments write both.

A constructed scenario, invented for teaching.

The system. A public-sector agency deploys an assistant that answers questions about eligibility for a housing support programme. It retrieves from published policy documents, internal guidance notes, and the applicant's own submitted information. It does not decide anything: a caseworker decides. But applicants read its answers and act on them, and caseworkers read its summaries before deciding.

The complaint that starts the work. An applicant is told they are "unlikely to qualify," does not apply, and later learns from a caseworker that they would have qualified. They ask why the assistant said that. The team's initial answer — "the model generated it based on your information and our policy documents" — is true, useless, and a Transparency pillar failure. Nobody can identify what went wrong, and the applicant cannot contest anything.

Fix 1 — Cited sources on every answer, at the claim level. Every eligibility statement must name the policy passage it rests on, with document title, section, and version date, rendered as something an applicant can click and read. Restructure the answer so each claim carries its own citation rather than dumping a source list at the end.

The immediate diagnostic payoff: the team discovers the answer cited a superseded guidance note, still in the index because ingestion had no expiry. Without citations, that bug is invisible; with them, it is the first thing anyone notices. This is the pattern to internalize — transparency instruments are also debugging instruments, which is why they are worth building even where nobody is asking for them.

Fix 2 — Corpus freshness and provenance in the data card. The data card now records, per source: what it is, who owns it, when it was ingested, when it expires, and its trust tier. Superseded documents are removed rather than left to rot in the index, and the retrieval layer prefers current versions. The card also states the corpus's coverage gaps — which policy areas are not covered — so "the assistant does not know" becomes a documented fact rather than a silent failure.

Fix 3 — A plain-language intended-use and limitations notice, shown in the interface. Not buried in terms of service. Displayed where the user is: This assistant explains the published rules and points you to them. It cannot decide your application and it can be wrong or out of date. Nothing it says prevents you from applying. To speak to a person, use this link. Six lines. That is the pillar's non-technical language requirement, met.

Note the last clause. The most important disclosure in an advisory system is that its output is not a decision — because the harm here was not a wrong answer, it was an applicant treating a wrong answer as a determination. Transparency about authority mattered more than transparency about mechanism.

Fix 4 — Disclosure that the counterpart is an AI system. Stated at the start of the interaction and never obscured by a human-sounding persona. If a question asks which principle is violated when users believe they are talking to a person, the answer is Transparency.

Fix 5 — A system card, not just a model card. The deployed system is a base model plus a corpus plus retrieval plus rails plus caseworker review. The system card documents: which model and version; what the corpus contains and how fresh it is; what retrieval scope applies; which rails run and what they block; that a caseworker makes every actual decision; what is monitored and how often; and the known limitations including the per-slice evaluation gaps from 13-04. This is the document an auditor reads.

Fix 6 — Retained logs that make it auditable. For each answer: the question, the retrieved chunk IDs and versions, the rails that fired, the answer, and the timestamp. That record is what lets the agency answer "what did the assistant tell this applicant on that date, and on what basis?" — a question that arises in every complaint and cannot be answered retrospectively if the sources were not logged. Retention is bounded and the store is treated as personal data per 13-05, which is a real tension: auditability wants long retention, privacy wants short. Resolve it explicitly — retain the minimum period that supports the complaint window, with access controls — and write the decision down.

Fix 7 — A contestation route. A link, on every answer, that says "this looks wrong" and routes to a human with the logged context attached. Explainability with no route to challenge is a courtesy, not a control. The pillar's purpose is that a person affected by an output can understand and question it.

What the seven fixes cost. Nothing exotic: citation rendering, corpus lifecycle metadata, an interface notice, one document, structured logging, and a feedback link. Transparency is the cheapest pillar to honour and the most frequently skipped, because none of its artifacts are technically difficult and all of them require somebody to decide to write them.

Transparency is one of NVIDIA's four named pillars, so it is directly examinable under objective 5.1, and its instruments are examinable under 5.3 — describe how to use NVIDIA and other technologies to improve AI trustworthiness — because the Model Card Generator is a named NVIDIA technology and grounding-with-citation is a named practice. The domain scope statement's verifiability requirement also lands here: verifiability means an outside party can check your claim, and cards, citations, and logs are what they check.

Question phrasings to expect:

1. "Which NVIDIA technology automates the creation of model documentation for transparency and compliance?" — Model Card Generator.
2. "What information should a model card include?" — intended use, out-of-scope use, training data, evaluation results, limitations. Expect the correct option to include limitations, and a distractor to be an all-technical-detail list.
3. "An organisation publishes a detailed technical paper but affected users cannot understand decisions. Which principle remains unsatisfied?" — Transparency, because the pillar specifies non-technical language.
4. "Which practice best supports explaining an LLM's answer to a non-technical user?" — grounding with cited sources.
5. "A chatbot presents itself as a human employee. Which principle is violated?" — Transparency (disclosure).
6. "Which document describes the dataset's collection method, consent basis, and coverage gaps?" — the data card.
7. "Why is asking an LLM to explain its own reasoning insufficient for explainability?" — the explanation is generated text, not a faithful account of the computation.

Distractor families:

Nine sections, and you should be able to produce this list under time pressure:

1. Model details — name, version, date, owner, family, size, licence.
2. Intended use — tasks, users, contexts it was validated for.
3. Out-of-scope and prohibited use — where it must not be used.
4. Training and adaptation data — what kind, from where, over what period, with what curation, and which populations are under-represented.
5. Evaluation — metrics, sets, results, and the per-slice table.
6. Known limitations and failure modes — specific, drawn from real error analysis.
7. Ethical considerations and risks — foreseeable harms mapped to pillars, and who bears them.
8. Mitigations in place — rails, grounding, human review, monitoring.
9. Contact, feedback, and contestation route.

For an LLM application rather than a bare model, add four more that a model card alone will not cover: the corpus description (sources, provenance tiers, freshness, gaps), the retrieval scope and access-control model, the rails in force and what they block, and the human-review points. Those four are what turn a model card into a system card, and in a RAG deployment they carry more of the trust story than the model section does.

Not at the level of the computation, and yes at the level of the evidence. Hold both halves of that sentence, because the exam tests both.

You cannot say which parameters or attention patterns produced a token, in any form useful to a person. You can say: these passages were retrieved, this rail passed, this template applied, this is the claim and here is the source it rests on, and a human reviewed it at this step. For everyone who actually asks — the affected person, the caseworker, the auditor, the engineer debugging — that is the answer to the question they meant.

Three things not to do. Do not present the model's self-generated rationale as an explanation of its own processing; it is a plausible story, generated the same way the answer was. Do not promise interpretability you cannot deliver. And do not treat the model's opacity as licence to leave the surrounding system unexplained — most of a production LLM application is deterministic code whose behaviour is fully documentable, and abandoning that because one component is opaque is the most common way teams end up with nothing to show.

The honest formulation for a model card's limitations section: "The system can name the sources an answer was based on and the processing steps applied. It cannot provide a token-level account of why the language model produced a particular wording." That sentence is transparent about the limits of transparency, which is the pillar being applied to itself.

Auditability is the property that someone other than you can check your claim. Verifiability is the word the exam blueprint's scope statement uses for it. A model card supports both by turning statements that would otherwise be verbal into a dated, versioned document that can be compared against reality.

The chain works like this. The card states an intended use; an auditor can compare it against how the system is actually deployed. The card states evaluation results including per-slice numbers; the eval set and CI history let those be re-run. The card lists mitigations; the rail logs from 13-02 show they fire. The card states limitations; incident records show whether known limitations caused harm anyway. Each claim has a corresponding artifact, and the audit is the comparison.

That is why documentation is not paperwork in this framework. A claim with a matching artifact is evidence; a claim without one is a press release — the same idea 13-01 opens with, applied to the transparency pillar. Regulatory regimes for AI generally push in this direction, toward documented intended use, disclosed limitations, records of testing, and traceability — but the specific obligations differ by jurisdiction and change over time, so the durable skill is producing the artifacts, not memorizing anyone's current statute. Build the card, the data card, the citations, the logs, and the eval history, and you are positioned for most regimes; build none of them and no amount of policy language helps.

• Transparency (pillar) — the ability to explain, in non-technical language, how a system reached its output.
• Explainability — giving a reason for a specific output, at a level the affected person can use.
• Interpretability — understanding the internal mechanism of the model; research depth, out of scope here.
• Model card — a structured document stating a model's details, intended and out-of-scope use, training data, evaluation, limitations, and mitigations.
• Data card — the equivalent for a dataset or corpus: sources, collection, consent basis, labelling, filtering, coverage gaps, prohibited uses.
• System card — documentation of the deployed application as a whole: model, corpus, retrieval, rails, human review, monitoring.
• Intended use / out-of-scope use — the declared boundary that makes misuse identifiable.
• Provenance (per-answer) — the specific sources a given output was built from, cited at claim level with version and date.
• Disclosure — telling the user they are interacting with an AI system, and what its output is and is not.
• Contestation route — a mechanism for an affected person to challenge an output, carrying the logged context to a human.
• Auditability / verifiability — the property that an outside party can check a claim against retained artifacts.
• Model Card Generator — NVIDIA tooling for automated model cards supporting transparency and compliance.

1. The pillar's test is non-technical language. A technical report is not a transparency artifact for affected users.
2. Transparency is about the system; explainability is about one output. Different artifacts, different audiences.
3. Provenance substitutes for interpretability. You cannot explain a token; you can cite the passage. Grounding plus citation is the practical explainability control.
4. A model-generated rationale is not an explanation of the computation. Fluent text about a previous generation, not an audit.
5. Model card sections to recall: details · intended use · out-of-scope use · training data · evaluation including per-slice results · limitations · ethical considerations · mitigations · contact and contestation.
6. A limitations section listing nothing destroys the card's credibility.
7. Version the card with the model. A stale card is worse than no card.
8. A RAG deployment needs a system card, covering corpus, retrieval scope, rails, and human-review points.
9. Disclose that it is an AI, and disclose what it is not — an advisory answer is not a decision, and saying so prevents the most common harm.
10. Log the basis, not just the answer: question, retrieved chunk IDs and versions, rails fired, timestamp — with a bounded retention period, because auditability and privacy pull against each other.
11. Model Card Generator = automated model cards for transparency and compliance. That is the identity statement.
12. Cards, citations, logs, and eval history are what an audit compares against reality. Documentation is the evidence layer, not the paperwork layer.

Transparency asked you to state what your system is and where it fails. The exam blueprint's scope statement asks for one more property that most ethics frameworks do not treat as a principle at all: that the system be energy-conscious. It is the most distinctive item in NVIDIA's framing and the one where public figures are least trustworthy — vendor-reported, methodologically inconsistent, and changing fast enough that any number printed in a study guide is already suspect.

Next: 13-07 takes up energy use, carbon, and efficient AI — why energy-consciousness is a named property of trustworthy AI, which engineering levers actually reduce compute per request, and why this course states that the specific figures are contested rather than inventing one.