Making explicit which AI claims are allowed to stabilize, where, and under what authority

A design- and governance-facing matrix that forces organizations to answer a question they routinely evade:

Which kinds of claims is this system allowed to make, in which contexts, and by whose authority?

Unlike policy statements or ethics principles, this artifact is meant to operate before deployment and during review, when decisions can still be constrained.

This matrix is not a compliance checklist. It is a decision-forcing device.

Why this artifact is necessary

Across the Guardian articles, harm arises not because AI systems produce claims, but because claims are allowed to stabilize as actionable knowledge without authorization.

Examples:

  • Health summaries treated as advice
  • Administrative summaries treated as records
  • Encyclopedic outputs treated as reference knowledge

In each case:

  • no one explicitly authorized the claim to function that way,
  • yet authority emerged through interface, repetition, and scale.

The Claim Authorization Matrix exists to interrupt that emergence.

Core Principle

Claims must not become actionable by default.
They must be authorized, bounded, or refused.

If authorization cannot be articulated, deployment is premature.

The Matrix (Core Structure)

The matrix crosses claim type, domain, and presentation mode against required authorization and constraints.

Below is a canonical version suitable for internal governance use.

Axis 1 — Claim Type

Claim TypeDescription
InformationalDescriptive facts, summaries, explanations
AdvisorySuggestions, recommendations, guidance
NormativeJudgments about what should be done
OperationalInstructions that directly enable action
ReferentialClaims positioned as authoritative reference

Axis 2 — Domain Context

DomainRisk Profile
General knowledgeLow–moderate
Health / medicineHigh
Law / legal statusHigh
Public administrationHigh
EducationModerate
FinanceHigh
Safety-critical systemsExtreme

Axis 3 — Presentation Mode

ModeGovernance Significance
Single synthesized answerHigh authority
Ranked list of sourcesModerate authority
Summary replacing primary materialHigh authority
Companion summaryModerate
Exploratory / sandbox interfaceLower

Authorization Requirements (Illustrative)

Below is a simplified authorization table. Organizations would tailor thresholds, but absence of a cell is not permission.

Claim TypeDomainPresentationRequired AuthorityAllowed?
InformationalGeneralRanked listProduct teamYes
InformationalHealthSingle answerClinical authorityConditional
AdvisoryHealthSingle answerClinical authority + safeguardsRare
OperationalLegalAnyLegal authorityNo
ReferentialHealthSummaryRegulator / professional bodyNo (default)
InformationalAdminSummary replacing recordInstitutional authorityConditional

Mandatory Questions (Per Claim)

Before deployment, reviewers must answer:

  1. What claim type is this output?
  2. In which domain will it be encountered?
  3. How will it be presented to users?
  4. Who explicitly authorizes this claim to be acted upon?
  5. What constraints bind misuse or overreach?
  6. What happens if authorization conditions fail?

If any question cannot be answered, the claim cannot stabilize.

How This Matrix Changes Behavior

Without the matrix:

  • Claims inherit authority from fluency
  • Interfaces quietly elevate outputs
  • Responsibility is displaced downstream

With the matrix:

  • Authorization must be named
  • High-risk claim combinations surface early
  • Deployment debates occur before harm

What This Artifact Is Not

  • Not a static policy
  • Not a safety scorecard
  • Not a product approval stamp

It does not say “yes” or “no.”
It says “who decides, and on what grounds.”

Intended Users

  • Product governance teams
  • Trust & safety groups
  • Public-sector procurement offices
  • Regulatory design teams