Methodology

How capabilities are classified and sourced on this site. The taxonomy, the source-quality hierarchy, the editorial process, and the limits.

This document covers capability inclusion. Incident inclusion methodology is forthcoming.

What this site is

A UK-focused, editorially curated record of what AI systems can demonstrably do, the evidence for those capabilities, and the documented incidents arising from them. The unit of analysis is the capability, not the model. Each capability page traces the same arc: theory, controlled lab demonstration, real-world deployment, and a sourced counterargument.

The site is not a comprehensive global tracker. Larger projects exist for that purpose: the AI Incident Database, the MIT AI Incident Tracker, the International AI Safety Report 2026. The site's aim is narrower: to give a UK reader, a parliamentary researcher, or a journalist enough sourced evidence to follow the argument that current AI capabilities outpace current AI governance.

The metadata dimensions

Each capability is tagged across two dimensions. The dimensions are descriptive properties of the capability itself; they are not policy prescriptions. Their purpose is to let the reader filter and reason about capabilities without flattening them into a single severity score.

The capability list is presented as an ordered sequence: from things you already encounter in deployed products, through behavioural patterns of mass-deployed AI, into frontier model behaviours, ending with agentic and system-level emergence. The order is editorial background and is not asserted as a category system. The labels and filters are intentionally restricted to architectural and empirical facts.

Where the capability lives

Where in the architecture the capability physically resides. This is not a claim about how concerning the capability is - it is a claim about whether the capability is a property of the model alone, of the model integrated with tools and agents, or both.

  • Model capability (model-resident): the capability lives in the raw model and surfaces in chat or API interactions. Sycophancy, alignment faking, expert-level answering.
  • Model + harness (harness-required): the capability manifests when the model is integrated with tools, memory, or autonomous loops. Self-replication, autonomous sub-goal pursuit, autonomous decision-making.

Some capabilities carry both labels. A capability is tagged with both where it is present in the raw model and is amplified when the model gains tools or autonomy. Image generation, voice cloning, persuasion, and cyber-exploit code all fit this pattern.

Evidence stage

Where the capability currently sits on the evidence progression that every capability page documents: theory, lab demonstration, real-world deployment. The stage is the furthest point the capability has reached. A reader can verify any classification by reading the evidence timeline on the capability page - that is the trust property the dimension is built around.

  • Hypothesized. Theory and lab demonstrations exist - sometimes in controlled scaffolds that remove hard real-world conjuncts - but the capability is not yet operationally deployed at scale. Hypothesised capabilities are included as forward-looking signals so governance has lead time, not because the capability is already loose.
  • Frontier Model. Demonstrated in frontier closed-source models (Claude, GPT, Gemini, Grok). Lab-level governance - responsible scaling policies, pre-deployment evaluation, UK AISI access, safety-case requirements - still has meaningful leverage over the capability.
  • Open Source. The capability is operationally deployed at scale via open-weight models (Llama, Mistral, DeepSeek, Qwen, Stable Diffusion, XTTS, and others). The bar is deployment at scale, not a single research scaffold on an open-weight model - a lab study showing that Llama 3.1 405B can be coerced into a behaviour in a contrived setting is evidence the capability is approaching open-source status, but the classification belongs at Frontier Model until the capability is shown to be in real-world use. Once a capability is classified Open Source, lab-level controls cannot contain it; governance has to address downstream questions: criminal law, content provenance, platform liability, professional regulation.

The evidence-stage dimension is empirical, not political. The site reports what the deployment evidence shows; it does not assert that open-weight release is right or wrong. The dimension exists because the cleanest dividing line for governance leverage is whether the capability can be recalled, not whether it is harmful.

What counts as a capability

A capability is included if all of the following hold:

  1. The capability is technically demonstrated. At least three sourced lab demonstrations exist, with quantitative results where available.
  2. The capability is contested or contestable. A counterargument from a credible source can be presented in good faith. A capability where no serious objection exists is not interesting; a capability where the objection is genuine is.
  3. The capability has UK governance implications. Either through documented UK incidents, through UK regulatory or evaluation infrastructure, or through legislation that addresses or fails to address the capability.
  4. The capability has theoretical lineage. At least one foundational paper or framework can be cited that anticipated or formalised the capability.

Capabilities that fail any of these tests are not absent because they do not matter; they are absent because the site cannot yet present them honestly to its standard.

Source-quality hierarchy

Sources are not equal. Each capability page makes the source type visible; readers are expected to weigh sources accordingly.

  1. Peer-reviewed research. Published in journals or conferences with double-blind review (Nature, Science, PNAS, NeurIPS, ICML, ICLR, ACL, IEEE S&P). The strongest evidence the site uses.
  2. Institutional reports. Government bodies (UK AISI, US AISI, NIST), established research institutes (METR, Apollo Research, RAND, NewsGuard), regulators (Ofcom, ICO, FCA), and law-enforcement agencies (FBI, NCSC). Strong but should be checked for institutional bias where one exists.
  3. Pre-prints and lab technical reports. Frontier-lab system cards (Anthropic, OpenAI, Google DeepMind), arXiv papers from named research groups, and major lab disclosures. Useful but unreviewed; flagged as such on each capability page.
  4. Quality journalism. Publications with editorial standards and corrections policies (FT, Bloomberg, Reuters, BBC, Nature News, Science). Used where primary sources are not yet public, or to surface incidents.
  5. Vendor claims. Self-reported by the company that built the system. Used only when independent verification is not yet available, and explicitly flagged.

Where a news article reports on an underlying study, the site links to both. Where a vendor figure is the only source for a claim, the figure is presented as approximate.

The counterargument requirement

Every capability page carries a sourced counterargument: the strongest version of the case against treating the capability as a concern, attributed to a named author or institution. Where the counterargument has weight, that is stated. Where it has limits, those are stated too.

A capability where no good-faith counterargument can be found does not yet meet the inclusion threshold for this site.

Editorial confidence

Editorial decisions on capability classification, source weighting, and counterargument selection are made by Sebastian Wood. They are not committee-derived; they are not algorithmic; they are subject to revision when the evidence changes. The honesty about subjectivity is the defence.

Capabilities are not currently displayed with confidence scores. When they are, the scores will be: verified (independent confirmation, peer-reviewed), high (strong evidence, multiple corroborating sources), moderate (single primary source or pre-print), needs-review (claim recently added, awaiting re-verification). Each score will carry a note explaining why.

Conflicts of interest

The site is self-funded. It receives no funding from AI laboratories, AI advocacy organisations, or government bodies. Sebastian Wood has no financial interest in any of the AI companies, products, or research organisations cited. Where this changes, it will be disclosed here before any capability page is updated.

Limits of the methodology

  • Selection bias is real. Capabilities are selected for inclusion. There is no claim of comprehensiveness. The site is curated by a single editor against the criteria above; another editor would make different choices.
  • The capability literature changes faster than the site. Evidence cited on a capability page may be superseded between site updates. Source-verification passes are conducted before each major update; readers should treat any specific quantitative claim as time-sensitive.
  • The taxonomy will get capabilities wrong. The dimensions above are an analytic device, not ground truth. Several capabilities sit on manifestation boundaries or have arguable evidence-stage assignments. Where the assignment is contested, the page says so.
  • UK-relevance is a perspective, not a property. Capabilities matter globally; the site reads them through a UK lens. Other lenses would surface different incidents, different governance hooks, different priorities.