| name | field-extraction-and-cim-mapping |
| description | Author, explain, diagnose, and validate Splunk search-time field extractions and mappings to Common Information Model (CIM) datasets from representative events, configuration, and search evidence. Use for automatic key-value extraction, regex or delimiter extraction, props.conf EXTRACT and REPORT/transforms.conf rules, SPL extraction commands, aliases, calculated fields, lookups, event types, tags, value normalization, CIM field mapping, and missing or incorrect normalization; do not use for deployment execution, ingestion transport, app installation, knowledge-object governance, data-model acceleration, or unrelated search/dashboard repair. |
| license | Apache-2.0 |
| allowed-tools | ["web"] |
| metadata | {"splunk":{"domain":"data-normalization","products":["splunk-cloud-platform","splunk-enterprise"],"entities":["search-time field extractions","props.conf and transforms.conf","field aliases, calculated fields, and lookups","event types and tags","CIM datasets and normalized fields"],"triggers":["extract fields from sample events","write EXTRACT or REPORT rules","map fields to CIM","validate CIM normalization","diagnose missing fields, aliases, lookups, tags, or event types"],"not-for":["data-model acceleration or tstats tuning","HEC, transport, index routing, or source onboarding","app installation, Cloud changes, or cluster deployment","knowledge-object governance or lifecycle review","unrelated SPL, search, or dashboard troubleshooting"],"outcomes":["cited extraction-mechanism guidance","evidence-bound extraction draft","semantic CIM mapping plan","unverified validation workflow or evidence-based result","bounded normalization-gap diagnosis"]}} |
Field Extraction and CIM Mapping
Produce documentation-backed, evidence-bound guidance for search-time field
extraction and CIM normalization. Draft text artifacts only. Never authenticate
to, modify, install on, or deploy to a Splunk environment.
Prerequisites
Record or ask for only the missing items material to the requested decision:
- representative sanitized raw events, including meaningful edge cases;
- sourcetype and relevant current
props.conf, transforms.conf, SPL, aliases,
calculated fields, lookups, event types, and tags;
- desired source fields and their meanings;
- target CIM dataset and installed CIM version or model details;
- Splunk product/version, persistence scope, app context, and deployment
topology when configuration or routing depends on them; and
- observed field/search/data-model validation output when diagnosing or
claiming validation.
Never invent event structure or field meaning. With partial evidence, first
preserve and assess every supported object-level fact. Mark each absent field
or artifact unknown, and gate only the conclusion it affects; missing context
must not erase supplied evidence. Clearly separate supplied observations,
documented facts, assumptions, provisional conclusions, and unverified steps.
When to Use
Use this skill when the primary outcome is documented extraction guidance, an
evidence-bound extraction draft, a semantic CIM mapping, validation steps, or a
normalization-gap diagnosis. Apply the boundaries below to adjacent work.
Workflow Overview
1. Select the extraction mechanism
Read public-guidance.md. Identify the documented
mechanism that fits the event shape: automatic key-value extraction, regex or
delimiter extraction, inline EXTRACT, reusable REPORT plus
transforms.conf, or an ad hoc SPL command. Separate persistent knowledge
objects from search-local SPL. Treat index-time extraction as a
performance-sensitive exception, not the default.
If source events or deployment context are absent, give only cited general
guidance. End the answer with a direct request for representative events,
sourcetype, product and version, and desired persistence scope before proposing
concrete configuration; merely listing these inputs as absent does not satisfy
the request.
2. Draft an evidence-bound extraction
Use the smallest approach that targets the supplied samples. Provide concrete
props.conf, transforms.conf, or SPL only when representative events and
desired fields are supplied. Explain why it matches the event shape and state
assumptions about sourcetype, app context, delimiters, cardinality, multivalue
behavior, and persistent search-time versus ad hoc scope.