Reference

Glossary

Canonical definitions for every SRF term, with stable anchor links for citation. Each term links back to the primary page where it is defined in full context.

Framework Architecture

# Layer
One of five enterprise architecture tiers in the CoSAI SRF (L1-L5). Each layer represents a distinct accountability domain. Requirements cascade from L1 downward through L2, L3, L4, and L5.
# L1: AI Business & Usage L1
The governance, strategy, and compliance layer. Owns regulatory obligations, acceptable-use policy, and incident governance. Security and governance requirements set at L1 constrain every layer below it.
# L2: AI Information L2
The data ownership and privacy layer. Accountable for training data provenance, master data management, privacy controls, and data classification decisions.
# L3: AI Application L3
The development and integration layer. Responsible for guardrails, input validation, output filtering, prompt engineering, RAG pipelines, and agent orchestration logic.
# L4: AI Platform L4
The infrastructure and runtime layer. Covers compute, LLM gateways, model routers, guardrail infrastructure, and platform-level IAM.
# L5: AI Model Provider L5
The foundation model and supply-chain layer. Accountable for model security, model cards, vulnerability disclosure, and distribution governance.
# Persona
A named stakeholder role in the SRF. There are eight personas, each mapped to one or more layers. Controls assign accountability to exactly one persona.
# Operating Model
One of four deployment archetypes (AI-SaaS, AI-PaaS, Agent-PaaS, IaaS) that determines how L1-L5 accountability shifts between customer and provider.

Accountability Rules

# Accountability
The obligation that cannot be delegated. Exactly one party per activity. The SRF's central rule: "shared" is a valid matrix value during analysis but must resolve to a single named persona in every control.
# Accountable Party
The single persona named as accountable for a given control. If a control shows "shared" in the responsibility matrix, the accountable party is still the one who cannot transfer the obligation.
# Responsibility Cascade
The principle that security and governance requirements set at L1 propagate downward through L2, L3, L4, and L5. An L1 policy decision constrains every layer below it.
# Shared Responsibility
A state in the responsibility matrix where both customer and provider carry obligations for a control. Not a final answer: each shared control must still name one accountable persona.
# RACI
Responsible, Accountable, Consulted, Informed. The SRF applies RACI at the control level but enforces exactly one Accountable owner per row.

Operating Models

# AI-SaaS
AI-Enabled SaaS. Provider manages the application (L3), platform (L4), and model (L5). Customer retains L1 governance and L2 data obligations. Lowest customer technical responsibility.
# AI-PaaS
AI Platform as a Service. Customer builds and owns L3. Provider manages L4 and L5. Customer and provider share L2.
# Agent-PaaS
Agentic Platform as a Service. Customer owns agent definitions and L1 business logic on a provider-managed orchestration runtime. L3 and L5 are shared.
# IaaS
Infrastructure as a Service. Maximum customer responsibility. Customer owns L1-L3 and most of L5. Provider is accountable only for physical infrastructure within L4.

Agentic Extensions

# Autonomy Level
A six-point scale (L0-L5) classifying how independently an AI agent acts. L0 = fully human-controlled; L5 = fully autonomous with no human oversight. Every agentic deployment must declare its autonomy level.
# Human Override Tier
A five-point scale (T1-T5) specifying the required human intervention capability for an agentic system. T1 = immediate human takeover at any step; T5 = retrospective audit only. Must be declared alongside autonomy level.
# Agentic System
An AI system that can take multi-step actions, use tools, or operate across sessions with limited human supervision. Agentic systems require autonomy level and human override tier declarations in addition to standard SRF layer assignments.

Evidence & Controls

# Control
A specific accountability assignment within a vertical schema. Each control has an ID (e.g. SRF-L1-DEV-001), a layer, an accountable persona, applicable operating models, and an evidence threshold.
# Evidence Threshold
The measurable criterion that satisfies a control. Specifies a metric, operator, parameter, window, and breach action. Used to determine whether accountability is being exercised.
# OCSF
Open Cybersecurity Schema Framework. The evidence schema used to specify what telemetry or log data satisfies a control's evidence requirement.
# Control Schema
The full set of controls for a vertical. Six are published: Financial Services (40 controls), Healthcare (40), Insurance (40), Public Sector (40), Defense (53), Manufacturing (45).

Personas

Brief definitions. Full responsibilities and layer mappings are on the Personas page.

# AI System Governance L1
Defines security control objectives, measures implementations, and enforces compliance. Includes AI risk officers, compliance teams, and governance boards.
# Data Provider L2
Supplies training data, evaluation datasets, or inference data. Includes data aggregators and dataset licensors.
# Application Developer L3
Integrates AI models into applications via APIs or embedded models. Accountable for application-level security, input validation, and output filtering.
# Agentic Platform Provider L3 L4
Provides development environments, frameworks, and orchestration runtimes for agentic AI.
# AI Platform Provider L4
Provides compute, APIs, and platform services for AI model hosting. Includes cloud providers and MLOps platforms.
# Model Provider L5
Develops, trains, and tunes foundation models. Accountable for model security, model cards, and vulnerability disclosure.