Methodology

Unit of analysis

Each registry record represents one identifiable AI capability, not an entire vendor or product.

A capability may qualify where an AI model materially determines a consequential decision, even when a human must approve the action or another system executes it. Model judgement is assessed separately from fixed rules, optimisation, execution mechanisms and human approval.

Evidence standard

Prefer vendor documentation, release notes, support documentation, developer documentation, trust/security documentation and other primary sources. Secondary sources may be used only where appropriate and should be clearly identified.

What we record

Function, data access, action capability, external actions, human confirmation, permission basis, administrative controls, default state, availability, licensing, model/provider information, limitations and uncertainty.

Recorded terms

Some characteristics use controlled terms so that capabilities can be recorded consistently across different vendors and products.

Generative only

The recorded capability generates or transforms information but is not recorded as independently executing operational actions.

Read only

The capability can retrieve or inspect information but is not recorded as modifying data or executing operational actions.

Can take actions

The capability can perform an action that changes data, configuration, workflow state or another operational outcome.

External actions

Indicates whether the capability can take actions outside its immediate product or service. Conditional means this depends on configuration, integrations or the particular action being used.

Human confirmation

Records whether an action requires explicit human confirmation before execution. Conditional means confirmation requirements vary by action or configuration.

Permission basis

Describes the runtime identity or authority under which the capability accesses information or performs actions. An administrator being able to switch the feature on or off is availability control, not a runtime permission mechanism.

• User permissions — execution is tied to the authority of the invoking person whose interaction or task caused the action. A stored credential merely labelled as a user's is not enough without established runtime binding to the invoking user.
• Dedicated agent identity — the AI operates using an account or principal specifically established as the agent's execution identity.
• Separate permissions — the AI acts with access configured separately from the invoking user's normal permissions, such as a connection or credential set up on the platform, without evidence that the authority is an independently established agent identity.
• Mixed — more than one distinct runtime authority mode is documented (see below).
• Admin role — runtime authority is documented as governed by an administrative role.
• Not established — the public evidence reviewed by the Registry does not establish whose runtime authority or permission basis governs the AI's action. It must not be interpreted as “No”.

Mixed

Recorded only where evidence establishes two or more distinct runtime permission or identity mechanisms governing what the capability can access or do — for example the user's permissions plus a separate agent identity, or a separate evaluation of tool or skill permissions.

Not established

The reviewed public evidence does not establish an answer. It must not be interpreted as “No”.

Unknown

The characteristic cannot currently be determined from the evidence available to the registry.

Default state

Records the operational default for an eligible deployment. Enabled means evidence establishes the capability is active without an administrator having to switch it on; disabled means evidence establishes it stays inactive until an administrator activates it; conditional means the documented default itself varies by deployment, tenant, plan, policy or configuration; otherwise it is not established. Licensing eligibility, the need for a user to invoke the feature, and the mere possibility of configuration do not by themselves establish a default.

Uncertainty

Missing information must not be converted into a negative claim. If something cannot be established from public evidence, record it as unknown, not established or explain the uncertainty directly.

Verification

Published records should be tied to identifiable evidence and carry a last verified date.

Investigation does not imply admission. A capability is recorded only where the available evidence establishes the specific consequential decision, the model's material role and the applicable production status. Unresolved claims are not treated as established authority.

Capability changes

When a verified capability changes, preserve the previous state, create a change event, record the new state and keep the history visible. Do not silently overwrite meaningful historical states.

What the registry does not do

No scores, risk ratings, vendor rankings, recommendations, sponsored conclusions or pay-to-play coverage.