Responsible AI: bias, fairness, explainability and the AWS tools that measure them

A model that is accurate on average can still be wrong about the same people every time, confident when it should not be, and impossible to question when it is. Responsible AI is the set of habits that catch those failures before users do: measure who the model gets wrong, say why it decided what it decided, keep a human where the stakes are high, and write down what the model is for and where it breaks. This article covers Domain 4 of the exam, which is fourteen percent of the questions: the vocabulary (bias, fairness, veracity, explainability), the eight dimensions AWS uses to organise it, the types of bias and the metrics that expose them, and the AWS tools that do the measuring. It leans on the Bedrock article for how Guardrails work and on the evaluation article for the metrics that judge model quality; here the question is not "is the model good" but "is it good for everyone, and can we show it".

The map

Read this first when short on time. Every branch is a section below.

The features: what a responsible system has to be

Responsible AI is the practice of building systems that are fair to the people they affect, robust to inputs they did not expect, safe in what they say and do, and truthful, and of being able to demonstrate each of those claims rather than assert them.

The exam guide names six features, and it is worth having a one-line definition of each ready, because questions often describe a failure and ask which feature was missing.

Two of these deserve a note. Bias and fairness are related but not the same: bias is a property of the model or the data (the error is systematic), fairness is a property of outcomes for people (the treatment is comparable). A model can carry a measurement bias that affects everyone equally and is therefore not unfair, and a model with no statistical bias can still be unfair if the world it learned from was. Veracity is the feature that generative AI made urgent: a discriminative model is wrong or right, but a language model can be fluently, confidently and persuasively wrong, which is why hallucination gets its own tooling later in this article.

protected attribute

A characteristic such as age, sex, ethnicity, religion or disability on which the law or the organisation's policy says decisions must not depend. SageMaker Clarify calls it a facet.

hallucination

A fluent, confident statement from a generative model that is not supported by its inputs or by fact. The veracity failure mode.

adversarial input

An input deliberately crafted to make a model misbehave: perturbed pixels, a malicious prompt, a poisoned training example.

The eight dimensions: how AWS organises responsible AI

AWS describes responsible AI as eight core dimensions, and the exam expects each name and a one-line definition: fairness, explainability, privacy and security, safety, controllability, veracity and robustness, governance, and transparency.

The dimensions overlap with the six features above but they are organised as things a builder is responsible for, not as properties of a model. The same list appears on every AWS AI Service Card and in the responsible AI sections of the Bedrock and SageMaker documentation, so it is the frame AWS itself uses when it talks about its own models.

Each dimension, in the words that the exam tends to reuse:

1. Fairness. Considering the impact on different groups of stakeholders. Measured with the metrics later in this article; in AWS tooling this is SageMaker Clarify's bias reports.
2. Explainability. Understanding and evaluating system outputs: a human can see which inputs drove a prediction. Clarify's SHAP attributions, and Model Cards that record what the model was trained on.
3. Privacy and security. Data is obtained, used and protected appropriately: encryption, access control, PII detection, and the promise that Bedrock does not train base models on customer prompts. The next article is entirely about this dimension.
4. Safety. Preventing harmful system output and misuse: Guardrails for Amazon Bedrock, Rekognition content moderation, Comprehend toxicity detection.
5. Controllability. Having mechanisms to monitor and steer system behaviour: Model Monitor, invocation logging, the ability to change a guardrail or roll back a model version without retraining.
6. Veracity and robustness. Achieving correct outputs, even with unexpected or adversarial inputs: grounding in retrieved documents, contextual grounding checks, robustness evaluation with perturbed prompts.
7. Governance. Incorporating best practices into the AI supply chain, including providers and deployers: policies, review boards, audit trails, and the standards the next article lists.
8. Transparency. Enabling stakeholders to make informed choices about their engagement with an AI system: knowing they are talking to a model, knowing what it is for, and knowing its limits. AI Service Cards and Model Cards are the AWS artefacts.

Bias: where it enters and what it does

Bias is a systematic error in a dataset or a model that pushes outcomes in a consistent direction for some inputs or some people, and it can enter at every stage from the world the data was drawn from to the feedback the deployed model generates about itself.

The pipeline of places it gets in

Thinking of bias as one thing makes it impossible to find. It is easier to walk the lifecycle from the SageMaker article and ask, at each step, what could tilt the result.

flowchart TD
  W["The world<br/>historical bias: past decisions were already unfair"]
  C["Data collection<br/>sampling and selection bias, survivorship bias"]
  M["Measurement and labelling<br/>measurement bias, label bias, confirmation bias"]
  T["Training<br/>algorithmic bias: the objective, the features, the proxies"]
  D["Deployment<br/>distribution shift, automation bias in the users"]
  F["Feedback<br/>the model's own decisions become tomorrow's training data"]
  W --> C --> M --> T --> D --> F
  F -. "amplifies" .-> C

The types by name

The exam expects the names. The table gives each with an example and the stage it usually enters.

Bias and variance, and what they do to people

In statistics bias also has a second meaning, the one from the fundamentals article: the error a model makes because it is too simple to capture the pattern. Variance is the error it makes because it is too sensitive to the particular training set. High bias shows up as underfitting (bad on training and test data alike); high variance shows up as overfitting (excellent on training data, poor on anything new). Both hurt fairness in a specific way:

• An underfit model uses a few coarse features, which are often the very demographic proxies (post code, age band) that should not drive the decision. It is inaccurate for everyone and unfair to some.
• An overfit model memorises the majority and treats the minority as noise, because there are too few minority examples to generalise from. Its accuracy on the aggregate hides a much worse accuracy on small subgroups.
• Either way, the effect on demographic groups is the same shape: different error rates, and therefore different rates of wrongful denial, wrongful flagging or wrongful exclusion, for people who did nothing different.

proxy

A feature that is correlated with a protected attribute closely enough that a model can use it in place of the attribute. Post code for ethnicity, or shopping basket for sex.

distribution shift

The data arriving in production no longer matches the training distribution. Also called data drift or concept drift depending on whether the inputs or the input-to-label relationship moved.

feedback loop

The model's outputs change the world in a way that generates its future training data. A policing model that sends patrols to an area finds more incidents there, which justifies more patrols.

Datasets designed for responsible AI

The cheapest place to fix bias is the dataset, so a dataset built for responsible AI is inclusive, diverse, curated from documented sources, balanced across the classes and groups that matter, and representative of what the model will see in production.

Each of those words has a test attached to it, and the exam likes the words:

Balance is the one people get wrong in both directions. A dataset that mirrors the real-world proportions may contain too few minority examples for the model to learn them, so it is often right to over-sample or re-weight minority groups during training even though the result is "less representative" in a naive sense. The goal is a model that is accurate for each group, not a dataset that is a scale copy of the population. Clarify reports the imbalance; the modeller decides whether to fix it with more data, re-sampling, re-weighting or a per-group threshold.

class imbalance

One class or group has far more examples than another. A fraud dataset with 0.1 percent fraud is imbalanced by class; a dataset with 95 percent of one demographic is imbalanced by facet.

re-weighting

Giving under-represented examples a larger weight in the loss so the model cannot ignore them. The alternative to collecting more data.

data sheet

A short document that travels with a dataset: who collected it, why, how, what it contains, what it must not be used for.

Measuring fairness: metrics, audits and red teams

Fairness becomes measurable only once a definition is chosen, and the three definitions worth knowing by name are demographic parity, equalised odds and disparate impact; around them sit the practices that make the numbers trustworthy: label-quality analysis, human audits, subgroup analysis and, for generative models, red teaming and toxicity evaluation.

Before any metric: is the label right?

Every fairness metric compares model output with a label, so a biased label makes the metric lie. Label quality analysis asks how the labels were produced, how much annotators disagreed, whether disagreement clusters on a group, and whether the label is a proxy for the real target (the healthcare-cost example above). Human audits sample decisions and have people re-judge them, blind to the model's answer. Subgroup analysis is the simplest and most powerful technique of all: compute every metric per group, not just in aggregate, because an aggregate of 95 percent accuracy can be 99 percent for one group and 70 percent for another.

The three metrics

Take a binary decision where one outcome is "favourable" (loan approved, transaction cleared, application shortlisted). Split the people into groups by the facet. Then:

These definitions conflict. If the groups genuinely differ in the base rate of the label, a model cannot satisfy demographic parity and equalised odds at once; forcing equal approval rates means accepting different error rates, and vice versa. The choice is a policy decision, made by people who own the outcome, and written into the model card. The model's job is to report the numbers honestly.

For generative models: red teams, toxicity and grounding

A language model has no single label to compare against, so its fairness and safety are probed rather than computed:

• Red teaming is a deliberate attempt by people (or by another model) to make the system misbehave: jailbreaks, prompt injection, requests for harmful content, questions designed to elicit stereotypes. The findings become test cases and guardrail rules. The prompt engineering article covers the attack side.
• Toxicity evaluation scores outputs for hate, insults, threats and sexual content. Amazon Bedrock model evaluation runs automatic evaluations for toxicity (alongside accuracy and robustness) over built-in or custom prompt datasets, and Amazon Comprehend has a toxicity detection API for text.
• Stereotyping evaluation gives the model paired prompts that differ only in a demographic word and measures whether the output changes; SageMaker Clarify's foundation-model evaluations include a prompt stereotyping task.
• Contextual grounding is the veracity check: does the answer follow from the retrieved documents? Guardrails for Amazon Bedrock scores each response for grounding (is it supported by the source) and relevance (does it answer the question) and blocks responses under a threshold. It is the automated hallucination filter for RAG applications, and the mechanics are in the Bedrock article.

facet

Clarify's word for the sensitive attribute used to split the data into groups for a bias report. The value or range that identifies the disadvantaged group is the facet value.

true-positive rate

Of the people who truly deserved the favourable outcome, the share the model gave it to. Also called recall or sensitivity.

red team

People whose job is to attack the system the way a hostile user would, before a hostile user does.

The AWS tools: Clarify, Model Monitor, Guardrails and the moderation APIs

AWS spreads responsible-AI tooling across the lifecycle: SageMaker Clarify measures bias and explains predictions before and after training, SageMaker Model Monitor watches for bias and attribution drift in production, Guardrails for Amazon Bedrock filters generative input and output, and Amazon Comprehend and Amazon Rekognition detect sensitive or objectionable content in text and images.

Amazon SageMaker Clarify

Clarify is a processing job (and a step in SageMaker Pipelines, Data Wrangler and Autopilot) that produces two kinds of report:

• Bias reports. Pre-training metrics look only at the data: class imbalance (CI), how unequal the group sizes are; difference in proportions of labels (DPL), whether the favourable label is more common in one group; plus distribution-distance measures (KL divergence, Jensen-Shannon, total variation) and conditional demographic disparity in labels (CDDL), which checks whether the disparity survives controlling for a legitimate variable. Post-training metrics compare predictions across groups: DPPL, disparate impact (DI), accuracy difference (AD), recall difference, difference in acceptance and rejection rates, treatment equality, and a counterfactual flip test that changes only the facet and sees whether the prediction changes.
• Explainability reports. Clarify computes SHAP values (Kernel SHAP for tabular models) for the whole dataset and for individual predictions, giving global feature importance and per-prediction attributions; it also draws partial dependence plots showing how the prediction moves as one feature varies. For images it highlights the regions that drove a classification; for text it attributes tokens.
• Foundation model evaluations. Clarify's FM evaluation (also surfaced in SageMaker Studio and JumpStart) scores a language model on accuracy, robustness, toxicity, factual knowledge, semantic robustness and prompt stereotyping across tasks such as summarisation, question answering and classification, using built-in datasets or your own.

flowchart TD
  D["Training data in S3"]
  P["Clarify pre-training bias job<br/>class imbalance, DPL, CDDL"]
  T["Train the model"]
  Q["Clarify post-training job<br/>DPPL, DI, accuracy difference, SHAP"]
  R["Model Registry and Model Card<br/>reports attached as evidence"]
  E["Endpoint in production"]
  M["Model Monitor schedule<br/>bias drift, feature attribution drift"]
  A["CloudWatch alarm<br/>investigate, relabel, retrain"]
  D --> P --> T --> Q --> R --> E --> M --> A
  A -. "new data" .-> D

Amazon SageMaker Model Monitor

Model Monitor runs scheduled jobs against the data captured at a real-time endpoint (or a batch transform) and compares it with a baseline. It has four monitor types: data quality (input distributions), model quality (accuracy against ground truth that arrives later), bias drift (the Clarify post-training metrics recomputed on live predictions) and feature attribution drift (whether the SHAP ranking of features has changed, which often means the model is now leaning on a proxy it did not lean on before). Each violation is written to S3 and emitted as a CloudWatch metric, so an alarm can page someone or trigger a retraining pipeline.

The generative and moderation tools

Guardrails deserves one more sentence here because it is the tool the exam asks about most. A guardrail is a named policy with up to six parts (content filters, denied topics, word filters, sensitive-information filters, contextual grounding checks and, for newer configurations, automated reasoning checks), attached to a model invocation, an agent or a knowledge base, and also callable on its own through the ApplyGuardrail API so that text from any model, even one outside Bedrock, can be checked. The Bedrock article has the configuration detail.

SHAP

SHapley Additive exPlanations: attributes a prediction to each input feature by asking how much the prediction changes, on average, when the feature is added to every possible subset of the other features. The attributions sum to the difference from the average prediction.

baseline

The statistics Model Monitor computes on a reference dataset (usually the training set) and compares live traffic against.

feature attribution drift

A change in which features the model relies on, detected by comparing live SHAP rankings with the baseline's. Often the earliest warning that the model is now using a proxy.

Human review: keeping people in the loop with Amazon A2I

Amazon Augmented AI (Amazon A2I) is the managed service for routing a model's predictions to human reviewers under conditions you set, collecting their judgements, and returning them to the application and to the training data.

The pieces are a flow definition (the human review workflow: which task template, which workforce, how many reviewers per item, where results go in S3), a worker task template (the web form the reviewer sees, built from a library of templates or your own HTML), and a workforce: your own employees as a private workforce, a vendor workforce from the AWS Marketplace, or the public Amazon Mechanical Turk crowd. A2I has built-in integrations with Amazon Textract (review extracted form fields whose confidence is low) and Amazon Rekognition (review moderation labels in a confidence band), and a custom integration in which your code calls StartHumanLoop for any model's output, including a Bedrock response.

flowchart TD
  I["Input arrives<br/>document, image or prompt"]
  P["Model predicts<br/>label plus confidence"]
  C{"Confident?"}
  U["Use the prediction<br/>random sample still audited"]
  H["A2I human loop<br/>flow definition picks template and workforce"]
  W["Reviewers judge<br/>private, vendor or Mechanical Turk"]
  S["Result to S3<br/>application reads the corrected answer"]
  R["Corrected labels<br/>feed the next training set"]
  I --> P --> C
  C -- "yes" --> U
  C -- "no" --> H --> W --> S --> R
  U -. "sample" .-> H

Two design decisions matter. The threshold trades reviewer cost against error: lower it and more items go to people. The random sample of confident predictions is what most teams forget, and it is the only way to discover that the model is confidently wrong on a subgroup. Both are set in the activation conditions of the flow definition.

human loop

One instance of a human review task created by A2I for one prediction, tracked from creation through completion to the S3 output.

human-in-the-loop

A design in which a person makes or confirms the decision and the model assists. Contrast human-on-the-loop, where the model decides and a person monitors and can intervene.

Choosing a model responsibly: task fit and sustainability

Responsible model selection means choosing the smallest, most efficient model that meets the task's quality bar, because a larger model than needed costs more money, more energy and more carbon for no gain, and is harder to explain and control.

The exam guide files sustainability under responsible AI, and the AWS Well-Architected Framework has a sustainability pillar whose advice for machine learning is simple: measure, right-size, and use the most efficient hardware and region available. Applied to model choice:

Task fit has a responsibility dimension beyond cost. A model chosen for a task it was not built for (a general chatbot giving medical dosing, an image model reading a legal contract) fails veracity and safety at once. AI Service Cards and Model Cards exist so that "intended use" is a documented fact, and choosing outside it is a decision someone owns.

AWS Inferentia

AWS-designed accelerator chips for deep-learning inference (Inf1, Inf2 instance families), programmed through the AWS Neuron SDK.

AWS Trainium

AWS-designed accelerator chips for training (Trn1, Trn2 instance families), also through Neuron.

model distillation

Training a small "student" model on the outputs of a large "teacher" so the student inherits most of the behaviour at a fraction of the cost. Bedrock offers it as a managed feature.

Legal risks of generative AI, and what mitigates each

Generative AI creates legal exposure in ways a classifier never did: the model can reproduce protected material, state falsehoods about real people, leak personal data, give harmful advice, and do all of it in the company's voice.

The exam guide names the categories; the table pairs each with the mitigation that a well-run team puts in place. Most mitigations are the tools from earlier sections, applied with a legal purpose.

indemnity

A contractual promise by the provider to cover the customer's legal costs and damages if a third party sues over the model's output. Usually conditional on using the provider's safety features.

defamation

A false statement presented as fact that damages a real person's reputation. A model that invents a criminal record for a named person has produced one.

Explainability: transparent models, black boxes and post-hoc methods

A transparent (interpretable) model is one whose decision can be read directly from its structure, such as a linear regression or a shallow decision tree; a black-box model is one whose internals are too many or too entangled to read, such as a deep neural network, and it can only be explained after the fact with methods that probe it from the outside.

Interpretable by construction

In a linear or logistic regression, each feature has one coefficient; the prediction is the weighted sum, and the explanation is the coefficients. In a decision tree, the prediction is a path of if-then splits a person can follow with a finger. Rule lists, naive Bayes and generalised additive models (a sum of one-feature curves) are in the same family. The model is the explanation, which is why regulators writing rules for credit and insurance decisions tend to prefer them, and why "adverse action" notices that must state the principal reasons for a decision are easy to produce from them.

Black boxes and how they are explained

A random forest is hundreds of trees voting; a gradient-boosted ensemble is hundreds of trees correcting each other; a deep neural network is millions of weights across many layers; a transformer language model is billions. None can be read. They are explained post hoc, by methods that treat the model as a function and study how the output responds to the input:

Post-hoc explanations are approximations of a model, not the model. SHAP values are faithful in a specific mathematical sense, but two very different models can produce similar SHAP plots, and a SHAP plot does not say whether a feature is a proxy. For a language model, "why did you say that" has no clean answer at all; attention maps show where the model looked, not why it concluded what it did, and asking the model to explain itself produces a plausible story that may not be the real cause. That is why generative systems lean on transparency about inputs (RAG citations: here are the passages the answer came from) rather than explanations of internals.

interpretable model

A model whose decision procedure can be read directly by a person: coefficients, tree paths, rules. Also called a white-box or glass-box model.

post-hoc explanation

An explanation produced after the model is trained by observing its behaviour, without reading its internals. SHAP, LIME, saliency maps and counterfactuals are post hoc.

local versus global

A local explanation is about one prediction; a global one is about the model's behaviour over the whole dataset.

Documenting models: SageMaker Model Cards and AWS AI Service Cards

Transparency is mostly documentation done well, and AWS has two documents for it: SageMaker Model Cards for the models you build, and AWS AI Service Cards for the models AWS builds.

Amazon SageMaker Model Cards

A model card is a structured record, stored and versioned in SageMaker, that answers the questions a reviewer or an auditor asks about a model. Cards can be created by hand, populated automatically from a training job and a Model Registry package (which pulls in the training data location, hyperparameters and evaluation metrics), and exported to PDF for people outside the console. A card moves through Draft, Pending review, Approved and Archived, and the SageMaker Model Dashboard shows every model's card status next to its Model Monitor alerts.

AWS AI Service Cards

AI Service Cards are the same idea written by AWS for its own pre-built models: Amazon Rekognition face matching and face liveness, Amazon Textract AnalyzeID, Amazon Transcribe batch transcription and toxicity detection, Amazon Comprehend PII detection, the Amazon Titan text and image models, and more. Each card has three parts: intended use cases and limitations (what it does well, where it is known to degrade), responsible AI design choices (how fairness was tested across demographic groups, what the confidence score means, what data was excluded), and deployment and performance optimisation best practices (thresholds, human review, image quality). They are how a builder knows, before writing code, what a managed service was and was not designed for.

Open models, open data and licences

Transparency for a third-party model comes from three things: whether the weights are published (open-weight models such as Llama and Mistral can be inspected, fine-tuned and run privately; closed models cannot), whether the training data or at least its composition is documented, and what the licence permits (commercial use, redistribution, fine-tuning, and any acceptable-use clauses). Open weights are not the same as open source in the software sense, and many open models carry use restrictions. Hugging Face model cards and dataset cards are the community's version of the documents above and the exam treats "model documentation" as a transparency tool in its own right.

risk rating

A field in a SageMaker Model Card (low, medium, high, unknown) that records the organisation's judgement of the harm a wrong prediction could do. It drives how much review the model gets.

open-weight model

A model whose trained parameters are published so anyone can run and fine-tune it. The training data and code may or may not be published, and the licence may restrict use.

Safety versus transparency: the trade-off

Transparency and safety pull against each other twice: the most accurate models are the least interpretable, and the internals that make a system explainable are also the internals an attacker studies to defeat it.

Accuracy against interpretability

Figure 6 is the first trade-off. Both sides must be measured to be traded. Performance is measured with the metrics in the evaluation article: accuracy, precision, recall, F1, AUC for classifiers; ROUGE, BLEU, BERTScore and human ratings for generators. Interpretability has no single number, so teams grade it: intrinsic (the model can be read), locally explainable (SHAP or LIME per prediction), globally explainable (feature importance only), or opaque. A decision is then explicit: for this risk rating, what is the minimum interpretability grade, and how much accuracy will we give up to reach it? In a regulated domain the answer is often "an interpretable model, even if a black box would be two points better", because a decision that cannot be explained cannot be appealed, audited or defended.

Exposure against protection

The second trade-off is less obvious. Publishing weights, exposing per-feature attributions, or returning confidence scores all help users understand the system, and all help an adversary:

• Confidence scores and attributions let an attacker craft inputs that cross the boundary (adversarial examples) or infer whether a record was in the training set (membership inference).
• Open weights make prompt attacks and fine-tuning away safety training trivial; a closed API can at least filter.
• Explaining a guardrail ("your message was blocked because it matched topic X") teaches the next message how to avoid the match.
• Revealing the system prompt is transparency about behaviour and also the first step of most prompt-injection attacks.

The usual resolution is to be transparent about what the system does and its limits (documentation, disclosure that the user is talking to a model, citations) while being guarded about how it does it (weights, prompts, exact thresholds, filter rules), and to give fuller explanations to the people who need them (the applicant who was declined, the auditor) than to the anonymous public.

adversarial example

An input with small, deliberate changes that make a model give a wrong answer with high confidence. Easier to build when the attacker can see gradients, attributions or confidence.

membership inference

Deducing from a model's outputs whether a particular record was in its training data. A privacy attack, sharper when confidence scores are exposed.

system card

A model card for a deployed system rather than a raw model: capabilities, evaluations, safeguards and known failures, without the internals.

Human-centred design for explainable AI

Human-centred design for explainable AI starts from the decision a person has to make and designs the model's output, explanation and interface to make that decision better, rather than starting from the model and hoping people cope with what it emits.

The principles the exam expects, each with what it looks like in a real interface:

1. Design for the user's decision, not the model's output. Ask what the person will do with the answer and what they need to do it well. A fraud analyst needs the top three reasons and a link to the transactions, not a probability to four decimal places.
2. Amplify human judgement instead of replacing it. The system proposes, the person decides, and the interface makes overriding easy and cheap. Where the decision is consequential, a human-in-the-loop design (A2I) is the default, and human-on-the-loop monitoring is the minimum.
3. Aim for appropriate trust, not maximum trust. Show confidence honestly (calibrated bands, "the model is unsure here"), state limitations up front, and make failure visible. Both over-trust (automation bias) and under-trust (ignoring a good model) are design failures.
4. Communicate clearly. Explanations in the user's vocabulary, not the modeller's: "declined because the debt-to-income ratio is high" rather than a SHAP bar chart. Say what the system is (an AI, not a person), what it is for, and what it is not for.
5. Mind cognitive load. One explanation at the right moment beats ten on a dashboard. Progressive disclosure: the short reason by default, the detail on request.
6. Build the feedback loop in. A one-click "this is wrong" that is recorded, reviewed and fed to retraining is worth more than any offline evaluation, because it measures the model on the cases that matter to users.
7. Design inclusively and accessibly. Screen readers, colour-blind-safe visuals, plain language, and testing with the full range of users, including the groups the fairness analysis worried about.
8. Provide reversibility and recourse. A person affected by a decision can understand it, contest it and reach a human. This is a design requirement and, under several regulations, a legal one.

flowchart TD
  D["The user's decision<br/>what will they do with the answer?"]
  O["Model output plus explanation<br/>answer, confidence band, top reasons, limits"]
  U["User acts<br/>accept, override or escalate to a person"]
  F["Feedback captured<br/>corrections, overrides, complaints"]
  L["Learn<br/>relabel, retrain, adjust thresholds, improve the interface"]
  D --> O --> U --> F --> L
  L -. "next version" .-> O

appropriate trust

Trust that matches the system's actual reliability on the case at hand: high where it is good, low where it is not, and visibly so.

progressive disclosure

Showing the simplest useful information first and the detail only when the user asks for it.

recourse

A real path for an affected person to understand, contest and change a decision made with the help of a model.

Recap