Transparent Is Not the Same as Understandable

A company publishes a model card, an agency releases a spreadsheet, a platform offers a download of every click, or a team opens the source code. The system is now called transparent. Yet the person affected still cannot answer the question that matters: Why did this happen, what information mattered, what could be wrong, and what can I do next?

Transparency is access to information about a system. Understandability is the ability of a particular audience to build a sufficiently accurate model of that system for a particular purpose. The two overlap, but they are not interchangeable. A glass wall can reveal every moving part while leaving the machine unintelligible.

Disclosure is an input, not an outcome

More information can be valuable. Source code can expose implementation choices. Logs can reconstruct sequence. Documentation can state scope and assumptions. Data access can reveal patterns that a summary hides. But each artifact answers only certain questions, and each requires tools and background knowledge to interpret.

A million-row event log may be complete and practically unusable. Open-source code may show what software could do without showing which version ran, what configuration it used, what data entered, or which human overrode the result. A policy may describe the official process while omitting the queue, informal workaround and exception path that shape lived outcomes. The dataset is not the world, and the disclosed artifact is not the whole system.

This does not make disclosure performative by definition. It makes disclosure the beginning of a chain. The next questions are whether the material is findable, scoped, interpretable, connected to the decision and paired with a route for correction.

Understandable to whom, for what?

There is no explanation that is maximally useful to every audience. An engineer debugging latency needs traces, versions and inputs. A regulator may need controls, validation results and responsibility assignments. A person denied a service needs the main reasons, the data used, the uncertainty or limits, and a way to correct an error. A researcher may need enough method and material to reproduce an analysis.

NIST's four principles of explainable AI make this audience dependence explicit. An explainable system should provide evidence or reasons, make the explanation meaningful to the intended recipient, accurately reflect the process, and operate within declared knowledge limits. The principles do not say that one generic paragraph satisfies every use. Meaningfulness depends on the user and the task.

Before asking whether a system is transparent, finish the sentence: transparent enough for which person to make which judgment? If no judgment is named, the debate can collapse into competing quantities of disclosure rather than useful access.

Six layers of useful transparency

The layers are not a universal compliance checklist. They are a diagnostic. A low-stakes recommendation may require little more than input controls and an undo button. A consequential eligibility, employment, medical, credit or public-service decision can require legal duties and domain-specific procedures beyond this framework. Transparency does not replace those obligations.

An explanation is not automatically the mechanism

People often ask for the reason a system produced an output. The response may be a rule trace, a feature attribution, a simplified narrative, a counterfactual or a summary of policy. These are different objects. A post-hoc explanation can help a person explore an outcome without perfectly reproducing the internal causal process. A faithful technical trace can still be incomprehensible or irrelevant to the affected person.

NIST distinguishes explanation accuracy from decision accuracy: an explanation should correctly describe how the system produced its output, even when the output itself is wrong. That distinction prevents a persuasive story from borrowing credibility from the decision it describes. It also reinforces the point that an AI explanation is not automatically the mechanism.

A useful account should label its type. Is it a faithful trace, a local approximation, a policy reason, an example-based comparison, or a user-facing summary? Do not let a smooth narrative impersonate a complete causal account.

The transparency dump

Organizations can technically disclose while shifting the cost of understanding onto the least resourced audience. Thousands of pages arrive in incompatible files. Critical fields lack definitions. Versions are missing. Links decay. A decision deadline passes before the material can be interpreted. Nothing is secret, yet almost nothing is usable.

This failure has a recognizable signature: volume without navigation, detail without hierarchy, access without context, and documentation without ownership. The fix is not always less information. It is a layered interface: a concise answer for the immediate question, traceable evidence underneath, definitions and version history, and access to deeper material for independent review.

The pattern also appears in personal systems. Downloading an account archive is not the same as understanding what a platform inferred, retained or shared. A dashboard is not the same as a decision model. Use the reality audit to separate direct evidence, system representation and the interpretation placed on top.

A seven-question legibility audit

1. Name the decision. Identify the exact outcome or behavior that needs explanation.
2. Name the audience. State their knowledge, access, time and consequence.
3. Inventory the evidence. List inputs, rules, logs, versions, human actions and source records that actually exist.
4. Trace one case. Follow a real or safely constructed example from input through outcome; do not rely only on system-level prose.
5. Mark the limits. State omissions, approximations, uncertainty, unsupported inferences and conditions where the account stops working.
6. Test comprehension. Ask the intended recipient to predict a nearby case or explain what correction would matter. Recognition is weaker than usable understanding.
7. Test recourse. Confirm the owner, evidence channel, review process, timeline and remedy when information is wrong.

The audit can be recorded in a small table with columns for audience, question, artifact, locator, version, limitation, owner and next action. That makes it compatible with a claim–evidence–inference worksheet or an AI evidence ledger.

Fact, inference and judgment

Sourced fact: NIST's explainability principles separate evidence, meaningfulness, explanation accuracy and knowledge limits. The ICO and Alan Turing Institute guidance treats explaining AI-assisted decisions as a communication and governance practice for affected people, not merely a technical artifact. Inference: disclosure becomes useful when it is tied to an audience, a concrete question and a traceable decision path. Judgment: recourse is often the difference between transparency as information and transparency as accountability. Not claimed: every system can be made fully interpretable, or that explanation alone makes a system fair, safe or legitimate.

Transparency asks whether the curtain is open. Understandability asks whether someone can see what matters, recognize what they do not know and act without pretending the system is simpler than it is.

Primary sources and guidance

• NISTIR 8312: Four Principles of Explainable Artificial Intelligence, for explanation, meaningfulness, accuracy and knowledge-limit principles.
• NIST AI Risk Management Framework, for governance, mapping, measurement and management of AI risk.
• UK Information Commissioner's Office and Alan Turing Institute: Explaining decisions made with AI, for audience-centered explanation practices.
• NIST AI RMF Playbook, for suggested actions aligned with the framework's Govern, Map, Measure and Manage functions.