Pattern library

Turns the factors behind an adverse decision into specific, realistic steps a person can actually take.

Makes an autonomous agent’s actions visible before, during, and after it runs, so oversight stays possible.

Makes AI involvement visible at the moment it matters, including labelling synthetic voices in calls.

Marks AI-generated files and text so their origin travels with them, long after they leave the interface.

Shows the top factors behind a decision in plain language, and whether each one helped or hurt the outcome.

Keeps a tamper-evident record of inputs, model versions, and human interventions that others can actually read.

Signals how sure the system really is about an output, in a form non-technical users can read at a glance.

Makes personal data use understandable at the point of decision, so consent is informed rather than just collected.

Gives people a working route to challenge a decision and get a human review with a documented response.

Shows the smallest realistic change that would have produced a different result, making the decision boundary visible.

Shows where the data behind a decision came from, how current it is, and whether it fits the case at hand.

Lays out a decision as a chronology of steps and actors, from data collection through review to outcome.

Shows how the system performs across different populations, making bias visible and open to challenge.

Explains a result by comparing it to cases the user can recognise, building intuition through analogy rather than abstraction.

Structures an explanation in depth layers, so a quick answer comes first and the full basis stays one step away.

Gives users a low-friction way to report errors and disagree, and tells them what happened to their input.

Distinguishes generated claims that rest on retrievable evidence from those the model may have invented.

Lets authorised people review, change, or override an AI decision, with every intervention on the record.

Lets users interrogate a result directly, probing single factors and testing what-ifs in their own words.

States what the system was built and validated for, and flags clearly when a case falls outside that.

Documents a system’s purpose, data, performance, and limits in a form non-engineers can actually use.

Exposes the documents a response was actually built from, so users can verify claims against the originals.

Adapts the depth, language, and available actions of an explanation to who is reading it and what they may do.

Signals when a model’s reliability may have drifted since deployment, so trust tracks current performance.