UK Algorithmic Transparency Recording Standard Record

Description

An Algorithmic Transparency Recording Standard (ATRS) record is a public account that a UK public sector organisation writes about one algorithmic tool it uses, on the UK government's standard template, and publishes in a central repository on GOV.UK. The template has two tiers: a short plain-language summary for the general public (what the tool is, why it is used and a contact), and eight further sheets for specialist readers such as journalists, researchers and civil society, covering who is accountable for the tool and which suppliers were involved, how it works and what it replaced, how its output feeds into decisions, when a person reviews that output, how members of the public can appeal, the system's and each model's inputs, outputs, architecture and performance (including any bias testing), the data used, and the impact assessments, risks and mitigations. Information that would be exempt under the Freedom of Information Act can be left out or summarised field by field, with the reason stated, and the record is cleared by the tool's team, its senior responsible owner (the role accountable for the tool) and the press office, checked for readability by the central ATRS team, and updated when the tool changes substantially or is retired. Publishing is mandatory for central government departments and for arm's-length bodies that deliver public or frontline services or deal directly with the public, for tools in beta, pilot or production that significantly influence decisions affecting the public or interact with it directly; other public bodies may publish voluntarily. Unlike a model card, written by a developer for people choosing a model, or a supplier's AI FactSheet for buyers, an ATRS record is written by the deploying public body for the public and describes the decision process, human review and appeal routes around the tool as well as the tool.

Example Use Cases

Transparency

A government department piloting a machine-learning model that prioritises benefit claims for caseworker checks publishes an ATRS record before the pilot starts. It tells claimants, journalists and MPs that the score only orders the caseworkers' queue and a caseworker makes every decision, how claimants can ask for a review, what kinds of data the model uses and what bias testing was done.

A district council piloting a supplier's tool that ranks rent-arrears cases for housing officers publishes a voluntary ATRS record. Because the record needs the model type, a description of the training data and performance figures, the council's procurement team writes their supply into the contract, and the record names the supplier, its role and the terms of its access to tenants' data.

A police force using a domestic-abuse risk assessment tool publishes a voluntary record in which the fields that would show how to evade the tool are marked exempt, with the reason, while the summary, the officers' review of each score, the appeal route and the risk mitigations are published in full for oversight bodies and community groups to examine.

A department launching a chatbot that answers questions about a public service publishes a record because the tool interacts directly with the public. The record states that answers come from a named provider's large language model used as supplied, how answers are checked, how often conversations are reviewed and how a user reaches a human adviser.

Limitations

A record is the deploying body's own account. The central ATRS team checks drafts for readability, not accuracy, and nothing in the standard tests the stated performance, bias testing or human review against the tool's behaviour. A record is also only as current as its last update, which depends on the body resubmitting after a substantial change, so it shows what was disclosed and when, not that the tool works as described.
The mandatory scope is narrow: central government departments and qualifying arm's-length bodies, and only tools that significantly influence decisions with public effect or interact directly with the public, from the beta or pilot stage on. Local authorities, police forces and other bodies outside central government publish voluntarily, and analytical models that inform policy are usually out of scope, so the absence of a record does not show that no tool is in use.
Fields can be withheld or summarised under Freedom of Information exemptions, including commercial interests, and no record is published where even the tool's existence cannot be confirmed. Police and commercial interviewees in a 2022 study expected suppliers to resist disclosing proprietary details, so the technical tier of a record for a procured tool can be thin unless the contract requires the supplier to provide the information.
For an off-the-shelf model that the organisation has not trained, tested or refined, such as a large language model used through its web interface, the guidance says to leave the model and development data sections blank. Records for such tools say nothing about the model's training data or evaluation, which is often what a reader most needs in order to judge them.
Whether the public can find, understand and use records has not been tested. Records sit in a repository on GOV.UK rather than reaching people when a decision affects them, although the 2021 public engagement study behind the two-tier design found people wanted active notice for higher-impact uses. Police interviewees in a 2022 study feared records would give more detail than the public needs and accuracy figures without context; its authors called for evaluation with impacted communities.

Resources

Research Papers

Algorithmic Transparency Recording Standard - Previous versions

Dec 2, 2021

Collection of previous versions of the Algorithmic Transparency Recording Standard.

Tutorials

Algorithmic Transparency Recording Standard - guidance for public sector bodies

Documentations

Algorithmic Transparency Recording Standard Hub

May 8, 2025

The Government Digital Service (GDS) is helping public sector organisations provide clear information about how and why they are using algorithmic tools.

Related Techniques

Name	Description	Assurance Goals
AI FactSheets	AI FactSheets is a documentation practice in which the developer or supplier of an AI model or service answers a structured set of questions about it, modelled on the supplier's declarations of conformity that industries such as telecommunications and transport use to give written assurance, with evidence, that a product meets stated requirements. The questions cover the service's purpose and its intended and unsuitable uses, the datasets it was trained and tested on, its test methods and results (reported for groups such as age bands or genders where relevant), checks for bias, explainability, behaviour on data unlike its training data and robustness to adversarial attack, how user data is secured, and its lineage, such as when and how its models were retrained; 'N/A' and 'Proprietary' are allowed answers. Facts are gathered from the people in each role across the lifecycle (business owner, data scientist, model validator and operations engineer), and any change to the service produces a new version of the FactSheet while earlier versions are kept. The originating group's seven-step method designs the template with its readers: interview the people who will read the facts and those who will produce them, draft and trial a template of questions, have the real producers complete it, evaluate the result with its readers for content and presentation, and build further templates for other audiences such as a review board or regulator. Unlike a model card, which reports one model's intended use and evaluation to the people choosing it, or a datasheet, which describes one dataset, a FactSheet may cover one model or a whole service built from several models and datasets (attaching their datasheets), gathers facts from each role in the lifecycle and has a different template for each audience; unlike a CycloneDX ML-BOM it is written for people to read rather than as a machine-readable parts list for software tools.	Transparency
CycloneDX Machine Learning Bill of Materials	A CycloneDX ML-BOM (machine-learning bill of materials) is a machine-readable inventory of what a model is made of, written in the CycloneDX standard (ECMA-424) so that tools as well as people can check it. It applies the software bill of materials, a structured list of the components in a piece of software, to models: the model is declared as a component of type machine-learning-model with its identifiers, version, supplier, licence and file hashes, together with the base models it was derived from (its pedigree), the datasets used to train and evaluate it with their source, classification and owners, the libraries it depends on, and an optional structured model card giving its task, architecture, performance metrics, intended uses and known limitations. The BOM is written at release, by hand or with a generator that reads the model's repository and metadata, checked against the CycloneDX schema, and can be signed. Consumers then query it, for example to find every deployed model that uses a dataset or library found to be compromised, or to check a supplier's declared datasets and licences before purchase. Unlike a model card or datasheet, written for people to read, or an experiment log or data version history, which stay with the team that built the model, it is a parts list in a fixed schema that travels with the model and can be matched against vulnerability records and file hashes, but it records what its author declares and verifies none of it.	Security Transparency
AI Incident Reporting with the OECD Common Reporting Framework	AI incident reporting with the OECD common reporting framework records each event in which an AI system caused harm, or could plausibly have caused it, in the common set of 29 fields the OECD published in February 2025, so that reports from different organisations, sectors and countries can be compared and pooled. The framework is meant for both mandatory and voluntary reporting and defines what a report contains, not the reporting interface or what should happen afterwards. The reporter first classifies the event using the OECD's definitions: an AI incident is an event in which the development, use or malfunction of an AI system directly or indirectly leads to harm to people's health, disruption of critical infrastructure, a violation of human rights or of laws protecting fundamental, labour or intellectual property rights, or harm to property, communities or the environment, and an AI hazard is one that could plausibly lead to such harm. Seven fields are mandatory: a title, a description, how the AI system was involved (as a direct cause, a contributing factor, a failure to act, through over-reliance or misuse, through human error, or through a failure to comply with the law), who is reporting, supporting material, the severity (hazard, serious hazard, incident, serious incident or disaster) and the type of harm. The other 22 record, where known and among other things, when and where it happened, the system and the organisations behind it, the people affected, the sector, how widely the system was deployed, whether training data, the model or several interacting systems were involved, the system's task and level of autonomy, and any action taken, giving an inspectable register of what went wrong in operation.	General