Comparing AI Safety Terms Across Frameworks: A NIKOLAI Crosswalk Guide

A compliance team tracking frontier AI safety today is usually reading five documents at once: Anthropic’s Responsible Scaling Policy, OpenAI’s Preparedness Framework, Google DeepMind’s Frontier Safety Framework, the EU AI Act’s GPAI Code of Practice, and NIST’s AI Risk Management Framework, each open in its own tab. The underlying ideas overlap heavily — a level of model capability that triggers new controls, a person who signs off on a deployment decision, a technical measure meant to reduce risk — but the words for them don’t line up, and the search terms people actually type reflect that: “capability threshold vs risk tier,” “who is the accountable decision-maker under SB 53,” “NIST AI RMF equivalent of a safety case,” “AI safeguard definition compliance.” Nobody is searching in the framework authors’ own vocabulary; they’re searching in whatever term their own program already uses, trying to find the matching concept somewhere else.

This guide is about the tool CASRAI built for exactly that problem — CASRAI’s own NIKOLAI project, a dictionary of 64 elements across 10 tracks (N1 through N10) that gives frontier AI safety concepts a single, comparable name, then shows a crosswalk of how different frameworks appear to use each one. It walks through four concrete terms, shows what a crosswalk table actually looks like on an element page, and is explicit about what that table is and isn’t: an independent reading CASRAI produced by comparing published documents, not a determination any framework owner has confirmed.

Why the same concept has five different names

Frontier labs, standards bodies, and regulators developed their safety vocabularies mostly independently, on overlapping timelines, each solving a version of the same problem: how much capability is too much before something is required, how do you know a model actually has that capability, what reduces the risk once you know, and who is on the hook for the decision. The result is real conceptual overlap without shared terms:

• Anthropic’s Responsible Scaling Policy talks about capability thresholds and required safeguards.
• OpenAI’s Preparedness Framework talks about tracked risk categories and required mitigations before a model can ship.
• Google DeepMind’s Frontier Safety Framework talks about critical capability levels.
• The EU AI Act’s GPAI Code of Practice talks about systemic risk and its Safety and Security chapter’s thresholds tied to training compute.
• NIST’s AI Risk Management Framework doesn’t use “threshold” as a defined term at all — its Govern, Map, Measure, and Manage functions describe a continuous risk-management process rather than a single numeric trigger.

None of those five documents is wrong, and none of them is simply restating the others in different words — some genuinely cover more or less ground than the concept a reader has in mind. That’s the actual problem a crosswalk needs to solve: not translation, but showing where the overlap is real, where it’s partial, and where a framework doesn’t address the concept at all.

What a NIKOLAI crosswalk row is — and what it deliberately isn’t

Every NIKOLAI element page carries a crosswalk table: one row per framework or organization, showing how that document appears to define or use the element. Every single row is labeled a shadow mapping, and that label isn’t decorative. A shadow row is CASRAI’s own reading of a published document, produced without contacting the lab, regulator, or standards body it’s about. No framework owner has confirmed, endorsed, or been consulted on a shadow row’s accuracy. That status changes only when an organization files its own Mapping Declaration — a verified statement, from the organization itself, about how a term maps in its own usage. As of this guide, NIKOLAI has shadow mappings across dozens of frameworks and no filed declarations, so treat every table below, and every table on the live site, as CASRAI’s independent research rather than any organization’s own word.

NIKOLAI itself is not a standards body, an evaluator, or a regulator, and CASRAI doesn’t claim any authority to certify a lab’s compliance with anything. It’s a reference dictionary, organized into 10 tracks — actors and models, threat models, thresholds and checkpoints, claims and arguments, evidence and evaluations, mitigations and security, incidents, transparency and review, commitments and governance, and assurance roles — covering 64 elements in total. Alongside the element and track pages a person can read directly, the same element and crosswalk data is available through a REST API and a small set of MCP tools, for a team that wants to pull mappings into its own tracker or tooling rather than reading them one page at a time.

Four terms, read across frameworks

Four elements make the pattern concrete: a capability trigger, the evidence used to test for it, what gets done once it’s triggered, and who signs off. Each is a live NIKOLAI element page with its own crosswalk table; what follows is a summary of what CASRAI’s shadow mappings currently show, not a restatement of any framework’s official text.

Threshold — capability threshold

NIKOLAI defines a capability threshold as a stated level of model capability at which specified additional safeguards or decisions become required, along with whether that level is quantified, qualitative, referenced-but-undefined, or classified. The element’s shadow mappings currently cover more than a dozen organizations — Anthropic, OpenAI, Google DeepMind, xAI, Amazon, Magic, METR, and the Frontier Model Forum among labs and evaluators, plus the EU’s GPAI Code of Practice, California SB 53, and the US government’s Executive Order 14409 among regulatory instruments. What the mappings surface is real variation in disclosure: some frameworks state a threshold as an explicit, quantified number; others reference a threshold without publishing the number itself; a few use qualitative or classified language that resists direct comparison at all. That disclosure-status distinction is easy to miss reading any single document in isolation, and it’s exactly the kind of difference a side-by-side table is built to surface.

Evaluation — evaluation

NIKOLAI’s evaluation element is defined narrowly: a documented procedure that produces evidence about a model’s capabilities, propensities, or safeguard effectiveness — distinct from neighboring track-N5 elements for one execution of that procedure, the elicitation technique used to draw out maximum capability, and the question of whether an evaluation still discriminates capability at all (saturation). Frameworks vary in how much of that structure they make explicit. Some documents specify elicitation method and scoring rule in detail; others describe “testing” or “evaluation” in general terms without separating the run from the procedure from the elicitation technique, which is a real difference in how much a reader can verify from the document alone, not a matter of different frameworks preferring different words for an identical process.

Safeguard — safeguard

A safeguard, in NIKOLAI’s definition, is a technical or procedural measure meant to reduce misuse or misalignment risk, identified by its type, target risk, and deployment scope. The element’s shadow mappings span the major labs’ scaling and preparedness policies alongside the EU GPAI Code and California SB 53. Here the crosswalk mostly shows convergence on the concept, safeguards tied to specific risks and specific deployment contexts rather than blanket controls, with the real variation sitting in scope: some frameworks’ safeguard language covers deployment-time controls only, while others extend it to training-time and internal-use safeguards as well.

Accountable decision-maker — accountable decision-maker

This is the element where the shadow mappings diverge the most, which makes it the clearest illustration of what a crosswalk table is for. NIKOLAI defines an accountable decision-maker as the named role or person who approves a risk, deployment, or framework decision, and what was approved, by whom, and when. Read across CASRAI’s current shadow mappings: Anthropic’s RSP and Meta’s scaling framework name a specific title (CEO and RSO; Chief AI Officer or Director of Alignment and Risk); OpenAI’s Preparedness Framework describes a decision function without a single named title; Google DeepMind’s FSF refers only to “the appropriate governance function,” leaving the specific role unnamed in the document itself; the EU’s GPAI Code spreads accountability across five separate levels running from an organization’s management body down to external assurance providers, rather than vesting it in one role at all; and California SB 53’s language centers on reviewing assessments and mitigation adequacy without naming a signatory. That’s not five frameworks disagreeing about who should be accountable — it’s five frameworks writing the same underlying requirement at genuinely different levels of specificity, which is precisely the kind of gap a single side-by-side table makes visible in a way that reading each document separately does not.

Reading a crosswalk table: a worked example

Take the accountable decision-maker element page as a concrete walkthrough. At the top sits NIKOLAI’s own definition of the element, independent of any single framework. Below it, the crosswalk table lists one row per framework, each one headed “Shadow mapping” and naming the organization, followed by the specific language CASRAI’s research found in that organization’s published document. Reading down the table for this element, a compliance professional can see in one place that: two frameworks name an individual C-suite title, one names a governance function without a title, one spreads the responsibility across five tiers, and several frame it as a review obligation rather than a named-person approval. None of those rows is marked as more authoritative than another, and none of them should be read as a statement that the organization named has confirmed CASRAI’s summary is accurate — that only happens for a row where an organization has filed its own Mapping Declaration, and the table says so explicitly wherever that hasn’t happened. The table doesn’t resolve which framework is “right”; it makes the actual variation visible, which is the step that’s missing when the same question gets answered by reading five PDFs separately.

Why this beats five PDFs open side by side

The practical case for a crosswalk table is mundane and specific: instead of a compliance analyst holding open a Responsible Scaling Policy, a Preparedness Framework, a Frontier Safety Framework, the GPAI Code of Practice, and a NIST AI RMF profile at the same time and manually cross-referencing which section of each addresses “who signs off on a deployment,” they look up one NIKOLAI element and see the mapped language from every framework CASRAI has researched, on one page, with the gaps and differences already surfaced rather than buried in five different documents’ section numbering and house style. It doesn’t replace reading the source frameworks — the shadow-mapping label exists precisely because CASRAI’s reading is not a substitute for the original text — but it replaces the first, most repetitive pass: finding out whether a concept exists in a given framework at all, and roughly where.

Where CASRAI’s NIKOLAI dictionary fits in your own crosswalk work

If a team already maintains its own internal glossary mapping its safety program’s vocabulary to the frameworks it has to answer to — a common artifact once an organization is tracking more than one regulatory or lab framework — CASRAI’s NIKOLAI project is useful as a starting structure rather than a replacement for that work. Its 64 elements across 10 tracks (N1 through N10) give each concept a stable name and definition to anchor an internal glossary to, its shadow mappings are a documented starting point for the “how does framework X phrase this” research a team would otherwise redo from scratch, and its REST API and MCP tools let that data be pulled into a team’s own tracking tools rather than copied by hand from the site. None of that is a compliance determination, an endorsement, or a substitute for reading the underlying frameworks — it’s CASRAI’s own independent reference, built to be checked against the source documents, not to stand in for them. A team that finds a shadow mapping wrong, or wants to confirm how it actually uses a term, can file a Mapping Declaration rather than leaving the shadow row as the only record.

FAQ

Is NIKOLAI an official standard or endorsed by the frameworks it maps?

No. NIKOLAI is CASRAI’s own independent reference dictionary. Every crosswalk row is explicitly labeled a shadow mapping unless the named organization has filed its own Mapping Declaration confirming it — no lab, evaluator, or regulator has endorsed NIKOLAI itself, reviewed its mappings as a whole, or been consulted on building it.

What’s the difference between a “shadow mapping” and a confirmed mapping?

A shadow mapping is CASRAI’s own reading of a framework’s published document, produced independently. A confirmed mapping exists only where the organization named in that row has filed its own Mapping Declaration — a verified statement from the organization about how it actually uses the term. Most rows across NIKOLAI today are shadow mappings.

Does NIST’s AI RMF map cleanly onto lab-style capability thresholds?

Not directly. NIST’s AI RMF is organized around four continuous functions — Govern, Map, Measure, and Manage — rather than a single numeric threshold that triggers new controls the way Anthropic’s RSP or Google DeepMind’s FSF do. A crosswalk table makes that structural difference visible rather than forcing a false one-to-one match.

How do I find the right NIKOLAI element if I don’t know CASRAI’s term for it?

Start from the NIKOLAI track index, or from whichever track sounds closest to the concept — thresholds and checkpoints, evidence and evaluations, mitigations and security, and commitments and governance cover most of what a compliance team is usually trying to cross-reference. Each track page (for example Commitments and governance) lists its elements with short definitions, which is usually enough to land on the right one even starting from a different framework’s own vocabulary.

Can I pull NIKOLAI’s crosswalk data into our own tooling instead of reading it page by page?

Yes. Alongside the element and track pages, NIKOLAI’s element and crosswalk data is available through a REST API and MCP tools, for teams that want to pull mappings into an internal tracker rather than copying them by hand.