Global AI Assurance · Model assurance

    Frontier Model Assurance

    Frontier developers run serious assurance of their own: capability evaluations, threshold declarations, safeguard reporting, external expert input and, increasingly, third-party evaluation. Those mechanisms are necessary. They are also provider-side.

    An institution needs a second record, held independently, that describes the artefact it is about to depend on and states plainly how much of that description is verifiable by someone other than the provider.

    Published as reference architecture. Control weights, grading rubrics and the full control set are set per engagement.

    The question this record answers

    Safety is a property of a deployment, not of an artefact. What can be assessed about the artefact alone is the strength of the evidence behind it.

    Not the question

    Is this model safe?

    The question

    How much independently verifiable assurance exists about this model's capabilities, safeguards, security, governance and residual risk?

    Safety is a property of a deployment, not of an artefact. What can be assessed about the artefact alone is how much of its behaviour is evidenced by something an outsider can inspect.

    Substantiated

    Independent evidence exists across capability, safeguards, security and governance, and it is current.

    Partially substantiated

    Provider evidence is documented; independent coverage is uneven or dated.

    Provider-attested

    The record rests on the provider's own statements, versioned but unverified.

    Insufficient

    Material domains have no inspectable evidence at all; deployment conditions must carry the risk.

    Five profiles make the record

    Every field exists because a supervisor, an auditor, a board or an incident review asks for it.

    Identity and provenance

    Establishes exactly which artefact is being assured, because the answer changes on every version.

    ProviderModel familyVersion and release dateModel lineage and predecessorsTraining information where disclosedOpen or closed weightsDeployment options offeredGeographic availability

    Capability profile

    What the system can do, assessed against the fifteen domains rather than a benchmark table.

    Domain-by-domain capability readThreshold crossings declared by the providerIndependent evaluation coverageCapability change since prior versionUncertainty where evidence is thin

    Safety profile

    What safeguards exist, what has been tested, and what remains unresolved.

    Provider safeguardsExternal evaluationsRed-team results where publishedKnown failure modesIncident historyDeclared safety thresholdsMitigation mechanismsResidual uncertainty

    Security profile

    How the model itself can be attacked, taken or turned, before any institutional deployment.

    Model theft exposureModel extraction exposurePrompt injection susceptibilityJailbreak susceptibilityTool abuse pathwaysSupply-chain exposureMalicious modification of weights or artefacts

    Governance profile

    Whether the provider's own assurance process is documented, versioned and inspectable.

    Provider governance structureEvaluation methodologyReporting cadenceIncident disclosure practiceChange management on model updatesTransparency artefacts publishedIndependent assessment accepted

    Fifteen capability domains

    Assessed independently of what a vendor calls a release, because the institutional consequence follows the capability, not the branding.

    01

    Reasoning

    Determines whether the system can construct multi-step plans that were never specified by the operator.

    02

    Coding

    Code generation reaches production systems through tools and pipelines, not just through a person reading output.

    03

    Cybersecurity

    Capability to find, chain and exploit weaknesses changes the institution's threat model whether or not it is used offensively.

    04

    Biology

    High-consequence uplift domain with published provider thresholds; relevant to research, health and government estates.

    05

    Chemistry

    Same uplift logic as biology, with different control owners and different national reporting duties.

    06

    Persuasion

    Affects conduct, consumer fairness and information integrity where the system speaks to customers or the public.

    07

    Deception

    A system that can misreport its own reasoning breaks the evidence chain the institution relies on.

    08

    Tool use

    The point at which a model stops producing text and starts producing actions in other systems.

    09

    Long-horizon planning

    Actions taken across many steps outrun single-prompt review and require runtime intervention instead.

    10

    Agentic execution

    Determines whether the system can complete work without a human in each step.

    11

    Self-improvement

    Capability to improve its own performance or successors; a threshold domain for provider safeguards.

    12

    Replication and adaptation

    Persistence and self-copying change containment requirements and incident response.

    13

    Data exfiltration

    Combined with credentials and tools this becomes a data-protection and supervisory reporting event.

    14

    Financial action

    Payment, trading and settlement authority carries prudential consequence and a named accountable person.

    15

    Decision autonomy

    How far the system may decide rather than recommend, which is what the board is actually approving.

    What this is not

    Cabier does not rank providers, does not publish a per-model score, and does not certify any model. A record describes a defined artefact assessed against a defined assurance profile, in a defined deployment context, on a stated date.

    A capability read only becomes useful when it resolves onto assets, obligations and controls.

    Compile capability into institutional risk