nemotron-policy-generator

Files (13)

• BENCHMARK.md
• SKILL.md
• nemotron_policy_generator.html · assets/
• nemotron_system_prompt_template.txt · assets/
• policy_json_schema.json · assets/
• policy_md_template.md · assets/
• EVAL.md · evals/
• evals.json · evals/
• content_safety_taxonomy.md · references/
• policy_patterns.md · references/
• target_models.md · references/
• skill-card.md
• skill.oms.sig

SKILL.md (first lines)

# 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

### Step 5 — Generate the requested outputs

Use the templates in `assets/`:

- `assets/policy_md_template.md` — the canonical human-readable form. Always produce this; everything else derives from it.
- `assets/policy_json_schema.json` — the JSON schema the structured output must conform to. Validate against it before saving.
- `assets/nemotron_system_prompt_template.txt` — the inference-ready prompt format. Contains ready-to-fill **emit blocks for each target model + deployment pattern** (Reasoning-4B vanilla/custom/topic-following; Nemotron-3 vanilla/custom/multilingual). Copy the block matching the chosen `target_model` + pattern rather than authoring the shape yourself — both models were trained on these exact shapes and deviating reduces accuracy.

Don't invent your own format — both models were trained on these exact shapes and deviating reduces accuracy.

From NVIDIA/skills, Apache-2.0 AND CC-BY-4.0.

More from NVIDIA/skills