Scenarios

A scenario is a canonical runtime question a policy can answer about data — "may this be used to train a model?", "how is this displayed?", "may this leave the region?". Scenarios are the shared vocabulary between your policies and the agents asking about them: every deployable instruction answers exactly one scenario, and decision-bearing tools resolve every request to one before answering.

Scenarios are defined by Metatate, not by tenants. That keeps the runtime vocabulary bounded and comprehensive: your labels and phrasing can vary freely, but the questions agents can ask — and the keys answers cite — stay stable across every workspace.

Questions, not values

A scenario is not a role, a classification, a decision, or a scope. Those belong elsewhere in the model:

Not a scenario	It's actually a...
ADMIN	role, referenced by an instruction
PII	taxonomy type / scope
mask.full	decision
Customer Data	collection / scope

Lineage, ownership, purpose, retention, AI use, access, export, and audit are scenarios — each answers a distinct governance question.

The canonical library

The library contains 65 canonical scenario keys, each shaped as family.question (matching ^[a-z][a-z0-9_]*\.[a-z][a-z0-9_]*$) and assigned to one of three delivery lanes:

Lane	Keys	Covers
platform	24	Runtime platform behavior: classification and taxonomy, ownership and lineage, discoverability, quality, read/write/admin access, row filtering, masking, encryption and anonymization, residency and cross-border transfer, derivation and combination.
agent	14	AI-specific use: training, inference, prompt and retrieval context, embedding and memory storage, tool use, agent workflows, evaluation, synthetic data, output disclosure, vendor transfer, human review, automated decisioning.
human	27	Human governance processes: allowed and prohibited purpose, sharing and export, approvals and exception handling, retention lifecycle and erasure, legal basis and consent, subject rights, minimization, audit logging, periodic review, regulatory compliance, incident response, contract restrictions.

A few keys and the questions they answer:

• access.read — may this role or actor read the data?
• masking.display — how are values displayed or masked?
• ai.training — may the data train models?
• ai.retrieval_context — may it be retrieved as context for AI answers?
• purpose.prohibited_use — what must the data never be used for?
• residency.cross_border_transfer — may it cross a jurisdictional boundary?
• retention.lifecycle — how long is it kept, and what happens then?
• exception.handling — how are exceptions to the rules requested and handled?

Each definition ships with a lane, label, description, the question it answers over MCP, and extraction cues. The library is data-driven — 65 is the current count, not a hard-coded limit.

Tenant labels are display inputs

Your workspace can attach its own labels and cues to canonical scenarios — your team's phrasing, mapped to the canonical key. Labels are display and mapping metadata only; they never become runtime keys, and no tenant input can mint a new scenario. Runtime answers always cite the canonical key.

How scenarios shape answers

When a policy version becomes deployable instructions, each instruction gets exactly one canonical scenario. Every instruction family has a deterministic default — masking rules answer masking.display, role grants answer access.read, usage guidance answers purpose.allowed_use, retention answers retention.lifecycle, transfer rules answer residency.cross_border_transfer — and authors can refine the default through the policy's scenarioMap extension, recorded as defaulted, ai_suggested, or user_confirmed. AI governance is section-aware: allowTraining maps to ai.training, allowInference to ai.inference, and anonymization requirements to protection.anonymization.

At answer time, decision-bearing tools read the scenario-matched instruction rows for the asset from the current deployment publication. A request with an explicit canonical scenario_key uses it directly. When authorize_use receives free-text use instead, a bounded deterministic mapper resolves it: a verbatim mention of exactly one canonical key wins; otherwise the definition whose extraction cues best match the text wins outright. The mapper never guesses — zero matches or a tie returns the typed not_enough_published_state answer with reason code scenario_unresolved, telling the caller to name a canonical scenario rather than receiving a fabricated decision.

Scenarios also frame coverage: because every instruction is scenario-keyed, "no applicable rows for this asset and scenario" is a precise, reportable gap — see Typed answer states.

Where to go next

The governance model shows where scenarios sit in the pipeline from catalog vocabulary to typed answers, and the Catalog page covers the classifications, collections, and taxonomy types that scenarios are asked about.