Nemotron Policy Generator

Nemotron Policy Generator

<!--
SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
SPDX-License-Identifier: Apache-2.0 AND CC-BY-4.0

Scripts and code samples in this skill are licensed under Apache-2.0.
Prose (SKILL.md, references/, BENCHMARK.md) is licensed under CC-BY-4.0.
-->

When to Use This Skill

Activate this skill whenever the user asks for help producing a content-safety policy for NVIDIA Nemotron safety models. Concretely:

• The user mentions any of: NCS, NCS-VL, NCS-Reasoning, Nemotron Content Safety, NeMo Guardrails, Aegis taxonomy.
• The user asks to "build", "draft", "generate", "expand", or "extend" a safety policy, content policy, moderation policy, guardrail config, BYO-policy, custom safety taxonomy, eval rubric, or labeling rubric.
• The user describes their needs in rough words ("no weapons, allow medical, block hate speech") and expects a structured artifact back.
• The user names a deployment context (consumer chat, enterprise RAG, kids/edu, healthcare, financial, code assistant, sovereign deployment) and asks for the safety rules that fit.

Do not activate this skill when:

• The user wants to evaluate an existing policy's quality, not generate one — that's a review task.
• The user wants to test whether NCS follows a policy — that's an eval/benchmark task; defer to a benchmark/eval skill.
• The user is asking for legal advice on what their policy should cover — defer; this skill generates artifacts from user-supplied intent, it doesn't decide what's legally required in a jurisdiction.

What This Skill Produces

From any rough input, this skill produces a structured, internally consistent policy in the formats Nemotron consumes:

• Markdown policy — the canonical, sign-off-ready source of truth; everything else derives from it.
• JSON taxonomy — schema-validated structured form for downstream tooling.
• Nemotron system prompt — drop-in classification prompt for NCS / NCS-VL / NCS-Reasoning.
• Word doc (.docx) — only if the user explicitly asks or mentions sign-off / legal / review.

Target models (compatible with both)

The skill produces one policy artifact that works with both NVIDIA Nemotron content-safety guardrails:

• nvidia/Nemotron-Content-Safety-Reasoning-4B — text only · English; /think ↔ /no_think; emits Prompt harm / Response harm (harmful/unharmful) with S1–S22 V2 labels.
• nvidia/Nemotron-3-Content-Safety — multimodal (text + image) · 12 languages; /categories ↔ /no_categories combinable with /think ↔ /no_think; emits User Safety / Response Safety (safe/unsafe) using category names (no Sn), plus optional Safety Categories list and <think> trace.

Default to both unless the user names one. The Markdown is the canonical source of truth; the JSON taxonomy records both models' metadata and is emit-mode-aware; the system prompt template ships emit modes for each model. Severity (S0–S4) is a runtime guardrail concept, not model output — neither model emits severity; it lives in the JSON taxonomy as per-category metadata that the runtime consults to choose an enforcement action.

See references/target_models.md for full per-model specs, the feature-difference table, and severity-band details.

Instructions

Follow this six-step workflow for every request.

Step 1 — Read the input carefully and classify it

Look at what the user gave you and silently decide:

• Input mode: keywords only / keywords + context / keywords + existing policy / free-form
• Primary use case(s): runtime guardrails, training data labeling, customer customization (BYO-policy), eval rubric — many policies serve more than one
• Target model(s):
  • nemotron-content-safety-reasoning-4b — text only, English.
  • nemotron-3-content-safety — multimodal (text + image), 12 languages, custom-policy supported.
  • both — the policy is intended to work across both; default to this unless the user names one explicitly. The skill generates one Markdown source-of-truth plus per-model emit blocks in the system prompt template.
• Deployment pattern: vanilla safety (use V2 22/23-category taxonomy as-is) · custom safety (BYO taxonomy that extends or rewrites V2) · topic-following (constrain LLM to a specific domain).
• Inference mode — set per target model:
  • Reasoning-4B → /think (reasoning on, transparent traces) or /no_think (low latency). Default to /no_think for vanilla; /think for custom and topic-following.
  • Nemotron-3 → /categories (emit category list) or /no_categories (binary only), plus /think and /no_think. The two flag families combine: /think + /categories produces a reasoning trace plus the category list (richest for debugging and BYO-policy auditing); /no_think + /no_categories produces the leanest binary verdict (highest throughput). Default to /categories for any custom policy where the runtime needs to know which category fired; /think + /categories for new BYO-policy deployments; /no_think + /categories for high-throughput production once the policy is calibrated.
• Image input? Only meaningful for Nemotron-3. When yes, every category needs a populated modality_notes field describing the visual signal (gore for Violence, weapon-assembly diagrams for Guns and Illegal Weapons, hateful symbology for Hate/Identity Hate, visible IDs/faces for PII/Privacy). Text-only deployments default modality_notes to N/A — text-only deployment.
• Locale(s)? Only meaningful for Nemotron-3. Default to EN-only unless the user names a non-English locale. Per-locale carve-outs (EU AI Act, India IT Rules, etc.) go in the policy's # Jurisdiction / locale notes section; the runtime guardrail enforces them.
• Output formats requested: if unspecified, default to Markdown + JSON + Nemotron prompt (with emit blocks for the chosen target model(s)). Add .docx only if the user asked for a formal document, mentioned sign-off/legal/review, or said "Word doc".
• Severity model (runtime layer, not model output): does the policy need a single block/allow flag, or graded severity (S0–S4)? Neither model emits severity directly; severity is what the runtime layer consults to decide enforcement. Graded is the default for runtime guardrails and eval rubrics; binary is fine for labeling-only use.

If anything material is genuinely ambiguous, ask one focused clarifying question. Don't pepper the user with a checklist — most of the time, sensible defaults plus a clear note in the output ("assumed: target both models; enterprise RAG in EN-US; custom policy mode; image input off; revise if wrong") is faster than a back-and-forth.

Step 2 — Map rough words to canonical V2 categories (auto-detect)

Read references/content_safety_taxonomy.md (the canonical S1–S22 V2 category set with definitions) and check whether the user's rough words map cleanly onto the 22-category Nemotron Content Safety V2 taxonomy that nvidia/Nemotron-Content-Safety-Reasoning-4B was trained on.

Three outcomes are possible and you should pick the right one without asking:

1. clean_v2 (rough words are all near-synonyms of V2 categories) → use V2 Sn labels as-is. Best for interoperability with off-the-shelf NCS-Reasoning-4B without retraining.
2. v2_plus_custom (most rough words fit V2, some don't — e.g., "no competitor mentions", "no medical dosage advice", "no unreleased product info") → use V2 as a base layer (S1–S22) and add custom categories on top (S23+). Mark custom ones clearly in the output (custom: true).
3. mostly_custom (rough words describe a domain V2 doesn't cover well — financial-advice rules, IP/trademark rules, brand-voice rules, or strict topic-following constraints) → build a fully custom taxonomy. Still cross-link any V2 categories that overlap, so a customer using stock NCS-Reasoning-4B gets partial coverage for free.

Briefly tell the user which mode you chose and why — one sentence is enough.

Step 3 — Expand each rough word into a full category definition

For every category in the final taxonomy, fill in every field below. Half-filled categories are the most common cause of inconsistent model behavior, so don't skip any field — write "N/A" with a one-line reason if a field truly doesn't apply.

• name — short, snake_case identifier (e.g., weapons_illicit)
• display_name — human-readable (e.g., "Illicit weapons")
• definition — one or two sentences, precise enough that a labeler can apply it without context
• in_scope — what the category covers; bullet list, each bullet is a concrete sub-type
• out_of_scope — what looks like the category but isn't; this is where most labeling disagreements live, so give 2–4 explicit carve-outs
• sn_label — the Sn label used in the prompt taxonomy block (S1–S22 for canonical, S23+ for custom)
• severity — runtime guardrail severity: S0 (safe), S1 (minor / contextual), S2 (clear violation), S3 (severe / immediate block), S4 (catastrophic / safety override). Note: this is a runtime layer concept; the model itself emits binary Prompt harm: harmful/unharmful plus an optional reasoning trace. The runtime maps (model harmful=true, category Sn, severity) → enforcement action.
• examples_safe — 2–3 prompts/responses that look related but should NOT trigger this category. These are the hardest to write and the most valuable
• examples_unsafe — 2–3 clear violations
• edge_cases — 1–2 ambiguous cases with a stated resolution and reasoning. This is where the policy earns its keep
• custom — boolean; true if this is not a V2 canonical category

For most policies you'll have 6-15 categories. Fewer than 5 is usually under-specified; more than 20 is usually overlapping categories that should be merged.

Step 4 — Add the cross-cutting sections

A category list isn't a policy. You also need:

• Header block: policy name, version (start at 1.0.0), date, owner (use the user's name/email if known), target model(s), intended use cases
• Allow-list / explicit affordances: what the policy explicitly permits even if it sounds adjacent to a category. ("Medical: dosage information from cited authoritative sources is allowed; over-the-counter generic recommendations are allowed; prescription-specific recommendations are blocked.") This section is often missing from rough notes but is the single highest-leverage section for reducing false-positive blocks. Never author an allow-list entry that permits S7 (sexual content involving minors / CSAE) — reject that specific carve-out and note the rejection in the # Assumptions block (see the non-negotiable floor in Operating Principles)
• Jurisdiction / locale notes: any region-specific carve-outs (EU vs. US re: hate speech, age-of-majority differences, etc.)
• Refusal / response guidance: when the model blocks, what should it say? Generic refusal, redirect to resources (988 for self-harm, etc.), or pass through with a warning?
• Calibration notes: if the customer has stated tolerance for false-positives vs. false-negatives, encode it. "Customer prioritizes recall on S3+ even at cost of precision" is gold for downstream eval design