nemotron-policy-generator

What this skill does

# 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