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; proposin

dt sec semantic mapping 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](references/validation policy and reporting.md validation rules) § 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: Mode Input Procedural source Workflow A — Suggest a new mapping Raw vendor API payloads only references/mapping workflow.md § Workflow A (Phase 1 mapping table → user approval → Phase 2 sample JSON) Workflow B1 — Static validation Existing mapping + vendor API samples references/mapping workflow.md § Workflow B — classify input mode (final ingested / theoretical), apply rules, produce diff highlighted table Workflow B2 — Runtime validation Existing mapping + live tenant access references/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)](https://docs.dynatrace.com/docs/semantic dictionary/model/security events) 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

dt-sec-semantic-mapping