dt-sec-semantic-mapping

SkillSecurity

Suggest and validate semantic dictionary (SD) mappings for new security integrations using vendor API samples or live events. Use when: mapping a new security vendor data to Dynatrace SD; checking required fields; validating namespaces; highlighting discrepancies vs the semantic dictionary; proposing mapping improvements; running runtime validation against live tenant data.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the dt-sec-semantic-mapping skill

What this skill tells your AI

The instructions your AI receives, as published by dynatrace/dynatrace-for-ai in skills/dt-sec-semantic-mapping/SKILL.md and read by ahel’s review.

Build and validate semantic-dictionary-aligned mappings for new security integrations.

Purpose

Use this skill when a user wants to:

  • Suggest a mapping from vendor API output to Dynatrace security.events fields (Workflow A).
  • Validate an existing mapping for completeness and quality against:
    • Local baseline samples and semantic dictionary (Workflow B1 — static, offline validation), or
    • Live tenant data via live tenant access (Workflow B2 — runtime validation)
  • Highlight discrepancies vs. the Semantic Dictionary and local references.
  • Get actionable mapping improvements.

Semantic Dictionary

The Semantic Dictionary (SD) defines the canonical field set for security.events. See references/semantic-reference.md for the canonical reference: local-vs-live sources, queryable Grail tables, when-to-query decision matrix, and the authority rule (live SD wins on disagreement).

Required Inputs

Always run the intake checklist in references/intake-and-constraints.md before generating or validating a mapping. If inputs are incomplete, continue with a partial draft but explicitly list missing evidence and confidence limits.

Baseline Sources (self-contained)

All baseline material lives inside this skill:

  • samples/ — real integration payloads covering all finding types and providers. Consulted as a fallback when primary references (SD, data-model-notes, known-discrepancies, validation-rules, object-type-expectations) leave a specific question unresolved — not as a routine step on every workflow run.
  • references/semantic-reference.md — SD reference, field taxonomy, event types, provider taxonomy, and entity scoping
  • references/validation-policy-and-reporting.md — validation rules, acceptable discrepancies, and report templates
  • references/intake-and-constraints.md — intake checklist, output contract, object.type expectations, and OpenPipeline constraints

Event-Type Coverage Requirements

The mapping MUST address the correct set of event.type values per finding class. Detection integrations are push-based and do not use scan cycles — never require scan events for detection.

See validation-policy-and-reporting.md § Event-Type Coverage for the full table, severity rules, and the alternative-classification path when a detection-class mapping incorrectly emits *_SCAN events.

Workflows

This skill operates in three modes. Detect the mode from context:

ModeInputProcedural source
Workflow A — Suggest a new mappingRaw vendor API payloads onlyreferences/mapping-workflow.md § Workflow A (Phase 1 mapping table → user approval → Phase 2 sample JSON)
Workflow B1 — Static validationExisting mapping + vendor API samplesreferences/mapping-workflow.md § Workflow B — classify input mode (final ingested / theoretical), apply rules, produce diff-highlighted table
Workflow B2 — Runtime validationExisting mapping + live tenant accessreferences/runtime-validation.md — load the security (AppSec) events supporting skill first (REQUIRED Step 0), then run the query pack, produce a Validation Summary table

All workflows follow the output contracts in references/intake-and-constraints.md and the report templates in references/validation-policy-and-reporting.md. Validation rules (event-type coverage, required fields, scan references, namespace requirements, value/type checks, vendor-namespace duplication) live in references/validation-policy-and-reporting.md.

Acceptable Discrepancy Policy

See references/validation-policy-and-reporting.md for the canonical list of acceptable SD deviations and vendor-namespace patterns. Do NOT raise critical/major issues for fields on that list. Genuinely unknown fields (not in local refs AND not in the live SD — see references/semantic-reference.md) must be questioned per references/validation-policy-and-reporting.md.

Scope

This skill covers:

  • Mapping suggestion and refinement (Workflow A).
  • Static validation against local baseline examples and semantic dictionary (Workflow B1).
  • Runtime validation via live tenant access against live tenant data (Workflow B2).
  • Semantic-dictionary conformance checks.
  • Gap analysis and improvement recommendations.

This skill does not cover:

  • Live ingestion pipeline deployment.
  • Runtime DQL performance benchmarking.
  • Tenant-side ingestion troubleshooting.

References

  • references/semantic-reference.md — SD reference plus data-model notes: local sources, live (queryable) sources, DQL patterns, when-to-query decision matrix, authority rule, field taxonomy
  • A skill covering full SD access patterns and Grail-table documentation — for DQL query patterns against security.events and Grail tables
  • Semantic Dictionary (public docs)
  • references/intake-and-constraints.md — intake checklist, output contract, OpenPipeline constraints, and object.type namespace expectations
  • references/mapping-workflow.md — how to build and refine a mapping candidate
  • references/validation-policy-and-reporting.md — full validation rule set, known discrepancies, and discrepancy report templates
  • references/runtime-validation.md — optional real-environment query validation pack

Signals

GitHub stars
142
Forks
29
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
dt-sec-semantic-mapping
Source
github.com/dynatrace/dynatrace-for-ai