Transparency — PACT Standard assessment axis

What this axis protects.

Transparency protects informed choice, appropriate use, accountability and access to remedy. It should reveal that AI is present, what function it performs, what information shapes an outcome, where the system is unreliable and how a person can question what happened.

It is not a demand to publish every model parameter, dataset or line of code. More disclosure can produce less understanding. The assessment should ask whether the information is accurate, timely, accessible and matched to the recipient’s role and the consequence of the decision.

A transparent system makes its role visible, its limits legible and its outcomes open to meaningful challenge.

Three audiences need different evidence.

People who are affected. They need to know that AI contributed, the purpose of its use, the main factors relevant to their outcome, the consequences and the route to human review or complaint.
People who operate the system. They need instructions, intended-use boundaries, performance limitations, input requirements, uncertainty guidance, oversight measures, logging and maintenance information.
People who govern or audit it. They need traceability across data, models, suppliers, versions, decisions, tests, incidents, changes and accepted residual risks.

Where transparency commonly fails.

Disclosure without timing. A general privacy policy mentions AI, but the person does not see a clear notice when the consequential interaction occurs.
A label without a role. “AI-powered” is disclosed without explaining whether the system generates content, ranks options, predicts risk or determines access.
Technical detail without meaning. Model names, accuracy scores or feature lists are supplied without explaining practical limitations or what a person can do next.
False precision. Scores and probabilities are shown without calibration, uncertainty, population limits or the cost of different errors.
Explanation after the fact. A generic description of the system is offered as if it explains the factors that mattered in an individual outcome.
Vendor opacity. Contractual or intellectual-property restrictions prevent the deployer from obtaining enough information to meet its own duties.
Stale documentation. Notices, instructions and explanations describe an earlier model, dataset, threshold or use context.

Assessment questions.

Where and when are people told that they are interacting with AI or that AI materially informs a decision about them?
Does the notice explain the system’s purpose, role, consequences and responsible organisation in plain language?
Can an affected person understand the main factors relevant to their outcome and distinguish those factors from general system information?
Is the explanation specific enough to support correction, challenge or human reconsideration?
Do operators know the intended use, prohibited use, known limitations, input assumptions, uncertainty and oversight requirements?
Can the organisation trace which system, model, data source, version and threshold contributed to a particular outcome?
Are communications accessible to people with disabilities, appropriate to language and literacy needs, and available through non-digital routes where necessary?
Does the change process update every affected notice, instruction and explanation before the revised system is used?

Evidence to collect.

Audience matrix: For each affected person, operator, decision-maker, auditor and regulator: what they need to know, when they receive it, the format and the owner responsible for keeping it current.
Live notices: Copies and screenshots of disclosure at the real interaction point, including accessible and non-digital alternatives.
Outcome explanation: A tested template connecting the main relevant factors, limitations and next steps to the specific outcome without exposing another person’s data.
Instructions for use: Purpose, capabilities, performance boundaries, foreseeable misuse, input conditions, interpretation guidance, oversight measures, maintenance and logging.
Traceability record: Data and model lineage, supplier and version history, configuration, thresholds, logs, decision ownership and documentation of changes.
Comprehension testing: Evidence from representative users that the information is noticed and understood, including people with relevant accessibility and language needs.

Decision thresholds.

Proceed: AI involvement is disclosed at the right time; explanations support informed use and challenge; operators understand limitations; records allow a consequential outcome to be reconstructed.
Proceed with conditions: Gaps are limited to a specific audience or channel and can be corrected before exposure, with an owner, deadline and temporary restriction on use.
Stop or redesign: The organisation cannot explain the system’s role, obtain essential supplier information, reconstruct an outcome, warn users about material limitations or provide an understandable route to challenge.

Test comprehension, not publication. Ask representative people what they believe the system does, which information mattered, what could be wrong and how they would challenge the outcome. A document’s existence is not evidence that transparency works.

Lifecycle checks.

Before first use

Map audiences and decisions, write layered information, test comprehension and confirm that procurement terms permit the organisation to obtain what it must disclose or explain.

During operation

Monitor unanswered questions, complaint themes, explanation requests and operator misuse. Sample whether notices appear at the right moment and whether logs can reconstruct real outcomes.

When conditions change

Update disclosures and instructions whenever purpose, model, data, supplier, interface, threshold, capability or affected population changes. Treat unannounced behavioural changes as governance incidents.

Sources and further reading.

Primary and institutional sources reviewed for this working document. Legal applicability must be assessed for the specific system and context.