> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/demisto-sdk-development-guide/demisto-sdk-guide/demisto-sdk-commands/validate/validation-checks.md). # Validation checks
BA: Basic | Code | Description | Rationale | Autofixable | | ------- | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | `BA100` | Validates Marketplace content is set to -1 to make it easier to distinguish it from modified, versioned content. | The version for system content items should always be -1 as per the standard. | Yes | | `BA101` | Validates the file ID and name fields are identical. | The ID attribute serves as the unique identifier for files across the platform | Yes | | `BA105` | Validates the content item ID doesn't include any slashes (/). | IDs with slashes are not allowed in the platform | Yes | | `BA106` | Validates the item's `fromversion` field is sufficient. | Ensures content can use the latest and greatest features of the platform. The minimal value is the third-last platform release version. | Yes | | `BA108` | Checks if there are separators in the folder name. | Ensures consistent, readable folder structures by avoiding separators like spaces, underscores, or hyphens. | | | `BA109` | Checks if there are separators in the script or integration files names. | Ensures filenames for scripts and integrations do not contain separators to maintain consistency and readability. | | | `BA110` | Checks that the entity name or display name does not contain the entity type. | Improves clarity and simplicity in the content repository. | | | `BA111` | Checks whether the name of a content item contains an excluded word. | Increases clarity by keeping content names simple. | | | `BA113` | Checks for content item names with trailing spaces. | Ensures accurate referencing. | Yes | | `BA114` | Checks that a content item from one pack to another. | Ensures content items are not moved from one pack to another. | | | `BA116` | Validates the CLI name and the ID match for incident and indicator fields. | Ensures consistency between the CLI name (used by the platform) and the ID. | Yes | | `BA118` | Validates the item's `toversion` is greater than or equal to its `fromversion`. | Content with a `from_version` greater than the `to_version` will not show in the platform. | Yes | | `BA119` | Validates the Python file doesn't have a copyright section with the words BSD, MIT, Copyright, or proprietary. | Content in Marketplace is licensed under the MIT license. | | | `BA124` | Validates the script/integration has a unit test file. | Unit tests ensure code behaves consistently between versions. | | | `BA125` | Checks that customer facing docs and fields don't contain internal terms. | Ensures customer-facing docs avoid internal terms for clarity. | | | `BA126` | Checks if script/integration is deprecated correctly. | Deprecated scripts / integrations need clear descriptions for user guidance. | | | `BA127` | Validates the level of depth of the context output path in the YAML is less than or equal to 5. | Ensures avoiding overly nested context to ease data extraction. | |
BC: Backward compatibility | Code | Description | Rationale | Autofixable | | ------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | `BC100` | Validates the pack name `subtype` of the new file matches the old one. |

Changing subtype can break backward compatibility.

Type indicates the language your integration is written in. Cortex XSOAR and Cortex XSIAM currently support Python and JavaScript. When using Python, you must specify the subtype field (either: python2 or python3). Additionally, when using Python dockerimage should be specified. If dockerimage is not specified, a default Python 2 image will be used.

| Yes | | `BC101` | Checks whether context output keys were removed from the script's output section. | To verify we don't break backward compatibility. | | | `BC102` | Checks whether the context path changed. | Changing the paths may break dependent content items which rely on the existing paths. | | | `BC103` | Checks whether an argument name changed. | If an existing argument is renamed, it will break backward compatibility. | | | `BC104` | Checks whether a command name or argument name changed. | If an existing command or argument is renamed, it will break backward compatibility. | | | `BC105` | Checks whether the ID of a content item changed. | Changing the ID of an item causes it to show as a new item in the platform, and to not update properly for users who already have a previous version installed. | Yes | | `BC106` | Checks whether the `fromversion` property changed on existing content files. |

Changing the fromversion field for a content item can break backward compatibility.

The last section of a YAML file provides information regarding what version is supported and tests.

fromversion indicates the server version that is supported with the integration. If the server version is below the fromversion, the integration will not display in the Settings area.

| | | `BC107` | Checks whether the `toversion` property changed on existing content files. | Changing the `toversion` field for a content item can break backward compatibility. | | | `BC108` | Checks whether the `marketplaces` property was removed or added in a manner that effectively removes all others. | Removing `marketplaces` or adding a new one that effectively removes all others can cause issues with the content item's visibility and availability. | | | `BC110` | Checks whether new required arguments were added to an existing command. | Adding a new argument to an existing command and defining it as required or changing a non-required argument to required breaks backward compatibility. | | | `BC111` | Checks whether new required arguments were added to an existing script. | Adding a new required argument or changing a non-required one to required without specifying a default value breaks backward compatibility. | | | `BC112` | Checks whether parameters were removed from an existing integration. | Removed parameters can cause errors if the parameter is needed by the server or integration code. | | | `BC113` | Checks whether incident types were removed and incident fields changed. | Ensures no breaking changes are made to existing mappers so customers won't lose data between pack updates. | | | `BC114` | Checks whether a pre-defined list of fields was removed or modified in the integration YAML. | Ensures backward compatibility between different versions of a content item. | |
CL: Classifier | Code | Description | Rationale | Autofixable | | ------- | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ----------- | | `CL100` | Validate that a classifier has a `type = classification` field. | This standardization is for the platform to correctly identify and handle the classifier. | Yes |
CR: Correlation rule | Code | Description | Rationale | Autofixable | | ------- | ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ----------- | | `CR102` | Validates `search_window` exists and is non-empty for `execution_mode = SCHEDULED`. | `SCHEDULED` execution must have a defined time frame `search_window` to operate within. | |
DA: Dashboard | Code | Description | Rationale | Autofixable | | ------- | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | ----------- | | `DA100` | Validates the dashboard excludes all the nonrequired fields. | The dashboard should contain only the required fields. | Yes | | `DA101` | Validates the dashboard includes all the required fields. | The dashboard should contain the required `fromDate`, `toDate`, and `fromDateLicense` fields. | |
DO: Docker image | Code | Description | Rationale | Autofixable | | ------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | `DO100` | Validates the given content item does not use the tag `latest` in its Docker image. | Locking content to use a specific tag of a Docker image ensures stability. The tag is usually updated in newer versions of the content item. For more information, see [Using Docker](/demisto-sdk-development-guide/demisto-sdk-guide/demisto-sdk-usage-and-configuration/using-docker.md). | Yes | | `DO101` | Validates the given content item uses a Demisto Docker image. | The Docker image used in a content item should originate from Demisto's Docker repository. This ensures that the Docker image is trusted, maintained, and compatible with the Demisto platform. | | | `DO102` | Validates the given content item uses a Docker image that is not the `native image`. | The `native-image` Docker image is intended for internal development and should not be used to run integrations or scripts. | | | `DO103` | Validates the given content item's Docker image exists in Docker Hub. | Platform-supported content must have images available in Docker Hub so they can be widely pulled and used. | | | `DO104` | Validates the given content item has a Docker image. | Python and PowerShell content runs in containers. | | | `DO105` | Validates the given content item uses a Docker image that is not deprecated. | Best practice is to use images that are maintained by the platform. | | | `DO106` | Validates the given content item's Docker image isn't outdated. | Updated Docker images ensure that the code doesn't use outdated dependencies, including bug fixes and fixed vulnerabilities. | Yes |
DS:Description | Code | Description | Rationale | Autofixable | | ------- | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----------- | | `DS100` | Checks whether a description file exists for a beta integration. | A disclaimer for beta integrations is required. | | | `DS101` | Checks if a beta disclaimer exists in the detailed description. | A disclaimer for beta integrations is required. | | | `DS104` | Verifies that a description file is present for an integration. | We recommend a description file for each integration, which for example has additional details on how to configure the instance. | | | `DS105` | Checks if the `DESCRIPTION` file contains contribution details. | Ensures the contribution/partner details that are generated automatically are not duplicated. | | | `DS106` | Checks if the description file exists and the name is valid. | Ensures all integrations have all required documentation and the file name is according to our standards. | | | `DS107` | Validates that none of the description lines contains the word `demisto`. | Ensures the current name of the product is used rather than the old one. | | | `DS108` | Ensures all YAML file description fields end with a period. | Ensures documentation standards. | Yes |
GF: Generic field | Code | Description | Rationale | Autofixable | | ------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | `GF100` | Checks if `group` field is set to `4`. | Required by the platform. | Yes | | `GF101` | Checks if the ID starts with `generic_`. | Required by the platform. | | | `GF102` | Checks if the `unsearchable` key is set to `true`. | Marking many items searchable causes index and search loads on the platform. Official `demisto/content` `GenericField` files must be set to `unsearchable`. In custom content, we recommend keeping the number of searchable fields to a minimum. | |
Graph | Code | Description | Rationale | | ------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GR100` | Detects content items that attempt to use other content items that are not supported in all of the marketplaces of the content item. | Ensures content graph proper construction. | | `GR101` | Validates the source's `fromversion` >= the target's `fromversion`. | Prevents issues where used objects are not available due to a version mismatch. | | `GR102` | Validates content items are not used in other content items which have a lower `toversion`. | Prevents issues where used objects are not available due to a version mismatch. | | `GR103` | Validates there is no usage of unknown content items. | Content items should only use existing content items. | | `GR104` | Validates there are no duplicate display names of packs in the repository. | Prevents confusion between packs. | | `GR105` | Ensures each content item has a unique ID to prevent conflicts. | Duplicate IDs can cause conflicts and confusion. | | `GR106` | Checks that every test playbook is linked to at least one content item. The content item has a `tests` key with the ID of the test playbook. | In the `demisto/content` repo, unlinked test playbooks are not run in CI (for PRs) unless the test playbook itself is modified. Proper linkage of test playbooks ensures content quality. | | `GR107` | Validates that deprecated content items are not used in other content items. | Using deprecated content items can lead to unexpected behavior and should be avoided. | | `GR108` | Validates that non-hidden packs do not have a hidden packs as mandatory dependencies. | Hidden packs are not available to install in the marketplace. |
IF: Incident field | Code | Description | Rationale | Autofixable | | ------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | | `IF100` | Checks if the `name` and `cliName` do not contain potential incident synonyms. | The `name` and `cliName` fields are limited by the platform. | | | `IF101` | Checks if the incident field is marked as content. | Required by the platform. | Yes | | `IF102` | Checks if `system` flag is `false`. | Required by the platform. | Yes | | `IF103` | Checks if a given field type is valid. | The types of the `IncidentField` are limited by the platform. | | | `IF104` | Checks if `group` field is set to `0`. | Required by the platform. | Yes | | `IF105` | Checks if `cliName` field is alphanumeric and lowercase. | Required by the platform. | | | `IF106` | Checks if `cliName` field is not a reserved word. | The `cliName` values of the incident field are limited by the platform. | | | `IF111` | Checks if the field type changed. | Changing the `IncidentField` type is not allowed by the platform. | | | `IF113` | Checks if the field name starts with its pack name or one of the item prefixes from pack metadata. | Required by the platform. | | | `IF115` | Checks if the `unsearchable` key is set to `true`. | Marking many items `searchable` causes index and search loads on the platform. Official `demisto/content` `IncidentField` files must be set to `unsearchable`. In custom content, we recommend keeping the number of `searchable` fields to a minimum. | | | `IF116` | Checks if `incidentFields` with `multiSelect` types have empty `selectValues` options. | Due to UI issues, empty values for the `selectValues` field are not supported. | Yes | | `IF119` | Checks if `incidentFields` with `singleSelect` types have empty or more than one `selectValues` options. | Due to UI issues, more than one or only empty values for the `selectValues` field are not supported. | Yes |
IM: Author image The following are the integration logo requirements: * 10 KB maximum size * Black and white or contrasting colors (no light colors) * Dimensions of 120x50 pixels * Transparent background * Only PNG format * No reversed logos or borders | Code | Description | Rationale | Autofixable | | ------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ----------- | | `IM100` | Checks if the integration has an image path. | Images make it easier to find integrations. | | | `IM101` | Checks that the image file size matches the requirements. | The image needs to fit properly in the UI with maximum size 10 KB. | | | `IM106` | Checks if the integration has an image other than the default ones. | If an image is provided, it must not be a default image. | | | `IM108` | Checks that the author image file is not empty. | If an author image is provided, it must be valid. | | | `IM109` | Checks if the pack has an author image path. | Author images make it easier to identify the author. | | | `IM111` | Checks that the image file dimensions match the requirements. | The image needs to fit in the UI. The logo dimensions should be 120x50 pixels. | |
IN: Integration | Code | Description | Rationale | Autofixable | | ------- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | `IN100` | Validates the `proxy` and `insecure` parameters are configured correctly. | The `proxy` and `insecure` parameters in an integration are built-in platform parameters. | Yes | | `IN101` | Checks that outputs of reputation commands are uniform and adhere to standards. | Uniform outputs allow creating generic content. Read about [generic reputation commands](https://xsoar.pan.dev/docs/integrations/generic-commands-reputation). | | | `IN102` | Validates the `checkbox` parameter is configured correctly with the `required` argument set to `false`. | A `checkbox` parameter that is required will fail (counts as missing) when unchecked, thus forcing users to always check it, turning it into a constant `true` value, rather than a dynamic checkbox. | Yes | | `IN104` | Validates that the integration `category` is valid. | See the [list of allowed categories](https://xsoar.pan.dev/docs/documentation/pack-docs#pack-keywords-tags-use-cases--categories) in the platform. | | | `IN106` | Validates the command is valid as a reputation command. | [Reputation commands](https://xsoar.pan.dev/docs/integrations/generic-commands-reputation) must follow standards for consistency and compatibility. | | | `IN107` | Validates the reputation commands include the list of required `contextPaths`. | Reputation commands must include required `contextPaths` for consistency and reliable use in playbooks or scripts. For more information, see [Mandatory Context Standards](https://xsoar.pan.dev/docs/integrations/context-standards-mandatory%20). | | | `IN108` | Checks whether the `subtype` is valid. | This field describes the major Python version, `python2` or `python3`. | | | `IN109` | Validates that the `id` field doesn't include the substring `beta`. | The `id` field in an integration should not contain the word `beta`. This ensures unambiguous identification of production-ready integrations. | Yes | | `IN110` | Validates the `name` field doesn't include the substring `beta`. | The `name` field in an integration should not contain the substring `beta`. This ensures unambiguous identification of production-ready integrations. | Yes | | `IN112` | Validates that the `display` name of a beta integration contains the substring `beta`. | Beta integrations should have `beta` in the `display` name for clear identification and to manage user expectations. | | | `IN113` | Checks that there are no duplicate arguments for integrations. | Duplicate arguments cause confusion and unpredictable behavior. | | | `IN114` | Checks that there are no duplicate parameters for integrations. | Duplicate parameters cause confusion and unpredictable behavior. | | | `IN115` | Validates the `contextPath` field of each output is in the correct format. | The `contextPath` in an integration's output must follow the correct format to ensure data can be used in subsequent playbook steps. Incorrect `contextPath` formats can lead to errors or unexpected behavior. Read about [context and outputs](https://xsoar.pan.dev/docs/integrations/context-and-outputs). | | | `IN117` | Validates type `17` configuration parameters do not include the `display` field. | The display name is handled by the platform. | Yes | | `IN118` | Validates the integration parameter has a `display` field if it's not type `17`. | Integration parameters should have a `display` field for clear user understanding, except for type `17` parameters. | | | IN121 | Validates the fetch integration has the required parameters in the correct format. | Malformed or missing parameters can lead to errors or incomplete data. Read about [fetching integrations](https://xsoar.pan.dev/docs/integrations/fetching-incidents). | | | IN122 | Checks that all feed parameters are in the correct format. | Malformed or missing parameters can lead to errors or incomplete data. Read about [feed integrations](https://xsoar.pan.dev/docs/integrations/feeds). | | | IN123 | Checks whether the integration display name is versioned correctly. | Integration display names should end with `v` for version clarity and consistency. | Yes | | IN124 | Checks that a parameter is not hidden if it should not be hidden. | Hiding these parameters can lead to confusion and may prevent the integration from working as expected. Only the following parameters may be hidden: `longRunning`, `feedIncremental`, and `feedReputation`. | Yes | | IN125 | Validates the `max_fetch` parameter has a default value. | To maintain optimal load in the platform, the maximum number of incidents per fetch is [limited](https://xsoar.pan.dev/docs/integrations/fetching-incidents#fetch-limit). | Yes | | IN126 | Checks that a fetch integration is not missing the `first_fetch` and `max_fetch` parameters. | The `first_fetch` and `max_fetch` parameters in fetch integrations ensure correct incident retrieval. Their absence or incorrect format can lead to errors or inconsistencies. For more information, see . | | | IN127 | Checks that a deprecated integration display name ends with `(Deprecated)`. | Deprecated integration display names should end with `(Deprecated)` to clearly indicate their status. This prevents inadvertent use of unsupported integrations. Read about [deprecation](https://xsoar.pan.dev/docs/reference/articles/deprecation-process-and-hidden-packs#how-to-deprecate-an-integration). | Yes | | IN130 | Checks that the integration is runnable. | Integrations must have a functional purpose, such as executing commands, fetching incidents, fetching indicators from a feed, or running a long-running process. | | | IN131 | Checks that the integration is valid as a mappable integration. | For easy debugging and troubleshooting, integrations supporting schema mapping `ismappable: true` should include the [get-mapping-fields](https://xsoar.pan.dev/docs/integrations/mirroring_integration#get-mapping-fields) command. This validator ensures the command is present in the integration YAML, enhancing maintainability and user experience. | | | IN134 | Checks whether a content item has multiple default arguments. | Multiple [default arguments](https://xsoar.pan.dev/docs/integrations/yaml-file#command-arguments) are not supported by the platform and could lead to unexpected behavior. | | | IN135 | Checks that the parameter display name starts with a capital letter and doesn't contain an underscore `_`. | For consistency and readability, parameter display names should start with a capital letter and not contain underscores. | Yes | | IN139 | Checks that the word `incident` isn't used in any of the command names or argument names for core pack integrations. | Helps maintain the flexibility of the platform. | | | IN141 | Checks that an `endpoint` command has at least one of the required fields. | Without at least one of the required fields, the command may not function properly or may return incomplete or incorrect data. Read about [generic endpoint commands](https://xsoar.pan.dev/docs/integrations/generic-endpoint-command). | | | IN142 | Checks that the integration contains the correct `additionalinfo` fields for the list of parameters with predefined `additionalinfo`. | Ensuring the `additionalinfo` fields are correctly set in an integration's parameters promotes consistency and enhances user understanding of each parameter's purpose and usage. | Yes | | IN144 | Checks that a reputation command has `isArray` field set to `true` for its default argument. | Reputation commands often have multiple inputs to enrich. Without `isArray=true`, providing an array of inputs may impact performance. Read about [reputation commands](https://xsoar.pan.dev/docs/integrations/generic-commands-reputation). | | | IN145 | Checks that Cortex XSOAR-supported integrations do not have non-hidden type `4` parameters. | Parameters that contain API tokens or credentials should be of type `Credentials` (type `9`) instead of `Encrypted` (type `4`) to allow fetching credentials from an external vault. This ensures secure and efficient handling of sensitive data. Using the `Encrypted` type could prevent the integration from fetching the credentials from an external vault, which could lead to operational issues. Read about [credentials](https://xsoar.pan.dev/docs/integrations/code-conventions#credentials). | | | IN146 | Checks that there is no `fromlicense` parameter field in non-Cortex XSOAR-supported integrations. | The `fromlicense` parameter is intended for XSOAR-supported integrations, as they rely on values coming in the platform. | Yes | | IN149 | Checks that a `contextPath` has a description if it belongs to a predefined list of `contextPaths` that require a description. | Common outputs in integrations need descriptions for clarity and effective usage. | Yes | | IN150 | Checks that a SIEM integration display name ends with `Event Collector`. | Consistent naming convention ensures that users can easily understand what the integration is used for. Read more about [naming conventions for event collection integrations](https://xsoar.pan.dev/docs/integrations/event-collectors#naming-convention). | Yes | | IN151 | Checks that all commands have at least one argument. | Prevents potential errors during execution due to missing arguments. | Yes | | IN152 | Checks that the default value of a checkbox parameter is valid. | Checkbox parameters' default values should be lowercase boolean strings (`true`, `false`) for correct interpretation and functionality. | Yes | | IN153 | Checks that the default URL parameter starts with `https` rather than `http`. | URL parameters should default to `https` for secure communication, as `http` could expose sensitive data. | Yes | | IN154 | Checks that feed integrations and integrations with reputation commands have a `reliability` parameter. | The [reliability parameter](https://xsoar.pan.dev/docs/integrations/feeds#required-parameters) is required to set an indicator's reliability. | | | IN156 | Checks that the hidden field value contains only valid values. | Incorrect values can cause unexpected behavior or compatibility issues. | | | IN158 | Checks that the description for non-deprecated integrations is not in the deprecation format. | Avoids confusion and ensures that users are correctly informed about the integration's status. Read more about [deprecation](https://xsoar.pan.dev/docs/reference/articles/deprecation-process-and-hidden-packs#how-to-deprecate-an-integration). | | | IN159 | Checks that the capitalization of reputation-command-specific keys is correct. | Ensures consistency and effective data passage between playbook tasks. Read about the [standard context output](https://xsoar.pan.dev/docs/integrations/context-standards-mandatory) for reputation commands. | | | IN160 | Checks that the display name for non-deprecated integrations doesn't end with `(Deprecated)`. | Avoids confusion and ensures that users are correctly informed about the integration's status. Read more about [deprecation](https://xsoar.pan.dev/docs/reference/articles/deprecation-process-and-hidden-packs#how-to-deprecate-an-integration). | | | IN161 | Checks that the `marketplacev2` tag appears in the `marketplaces` list of a SIEM integration. | SIEM integrations must have the `marketplacev2` tag for visibility in the Cortex XSIAM marketplace, enhancing usability. See [required keys](https://xsoar.pan.dev/docs/integrations/event-collectors#required-keys) for event collection integrations. | Yes | | IN162 | Checks that the `supportlevelheader` for a collector integration in a partner pack is set to `XSOAR`. | Collector integrations in partner packs should specify the `XSOAR` support level to inform users about the support level provided by Cortex XSOAR. Read about the [support level header](https://xsoar.pan.dev/docs/documentation/integration-description#support-level-header-yml-metadata-key). | Yes | | IN163 | Checks that the `feedExpirationPolicy` parameter is in the correct format for both incremental and fully fetched feeds. | A malformed expiration policy can lead to errors or incomplete data. | Yes |
IT: Incident type | Code | Description | Rationale | | ------- | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `IT100` | Checks that the included fields have a positive `integer` value. | Fields that have to be included cannot be type `integer`. | | `IT101` | Checks that the playbook `id` is valid. | The playbook `id` has to be in a non-`UUID` format. | | `IT102` | Checks that the `extractSettings` field is valid. | The `extractSettings` field needs to be in the correct format. | | `IT103` | Checks that the `autoExtractMode` is valid. |

The autoExtractMode possible options are:

|
LO: Layout | Code | Description | Rationale | | ------- | --------------------------------------------------------------------------------------- | ------------------------ | | `LO107` | Checks that only supported types are used in the layout for Cortex XSIAM compatibility. | Limited by the platform. |
MR: Modeling rule | Code | Description | Rationale | | ------- | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `MR100` | Checks that each modeling rule has a corresponding schema file. | Each modeling rule must have a schema file. | | `MR101` | Checks that the modeling rule keys `rules` and `schema` exist and are empty. | This validation is for compatibility reasons. Without the `rules` and `schema` fields the modeling rules won't work. | | `MR106` | Checks that each specified data type in the modeling rule schema files conforms to a predefined set of acceptable types. | Validating types in schema files is crucial for maintaining data integrity and compatibility across systems, preventing errors and ensuring reliable data processing. | | `MR107` | Checks that the modeling rule dataset name shown in the XIF and schema files match. | Ensures the datasets match between the schema and the XIF file to avoid discrepancy between the expected info and the info shown in the UI. | | `MR108` | Checks that ID and name in the modeling rule end with the correct suffixes. | To prevent confusion caused by ambiguous naming of modeling and parsing rules in the Cortex XSIAM UI, the validation ensures the rule ID and name end with `ModelingRule` or `Modeling Rule`. This helps avoid naming conflicts and improves clarity in release notes. |
PA: Pack | Code | Description | Rationale | Autofixable | | ----- | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | PA100 | Validates all the tags in tags field have a valid prefix. | This standardization allows for efficient filtering and grouping in the marketplace. See list of [valid prefixes](https://xsoar.pan.dev/docs/documentation/pack-docs#pack-keywords-tags-use-cases--categories). | Yes | | PA101 | Validates the version mentioned in the pack metadata matches the latest RN version. | Clear documentation for each version change helps users know what's new. Read more about [content pack versioning](https://xsoar.pan.dev/docs/packs/packs-format#content-packs-versioning). | | | PA102 | Validates the pack is deprecated if it needs to be. | Ensures clarity for users and prevents potential confusion of [deprecated content](https://xsoar.pan.dev/docs/reference/articles/deprecation-process-and-hidden-packs). | Yes | | PA103 | Validates the pack categories are valid. | See list of [allowed categories](https://xsoar.pan.dev/docs/documentation/pack-docs#pack-keywords-tags-use-cases--categories). | | | PA104 | Validates the modules field include only labels from the list of allowed labels. | There is currently one allowed module: compliance. | Yes | | PA105 | Validates the pack has the `marketplacev2` label if it includes modules. | This field is only used in Cortex XSIAM. | Yes | | PA107 | Checks that mandatory fields exist in the pack\_metadata. | If these fields are missing, it may lead to unexpected behavior when uploading content packs. | Yes | | PA108 | Validates the pack name field exists and is different from the default name. | A unique and meaningful pack name is crucial for identifying the pack and its contents. | | | PA109 | Validates the metadata description field isn't empty and is different from the default value. | A meaningful description helps users understand how the pack can help them. | | | PA111 | Validates certain metadata fields are not empty. | The following metadata fields are [required](https://xsoar.pan.dev/docs/documentation/pack-docs#pack-keywords-tags-use-cases--categories): `keywords`, `tags`, `categories`, and `useCases`. These fields are required for pack identification and searchability. | | | PA113 | Validates a partner/developer pack has an email or a URL address field completed. | Packs with partner or developer support levels require a contact method (email or URL) for user support and information. | | | PA114 | Checks that the pack metadata version is raised on relevant changes. | When updating a pack, its version needs to be updated to maintain traceability. | | | PA115 | Validates the `pack_metadata` created field is in ISO format. | Required by the platform. | Yes | | PA117 | Validates the pack's support type is a valid support type. | See list of [valid support levels](https://xsoar.pan.dev/docs/packs/packs-format#pack_metadatajson). | | | PA118 | Validates the metadata's certification field is valid. | See list of [allowed certifications](https://xsoar.pan.dev/docs/packs/packs-format#pack_metadatajson) in the platform: | | | PA119 | Validates the metadata's use cases field include valid use cases. | See list of allowed [useCases](https://xsoar.pan.dev/docs/documentation/pack-docs#pack-keywords-tags-use-cases--categories) in the platform. | Yes | | PA120 | Validates the metadata's tag section includes only approved tags. | Using [approved tags](https://xsoar.pan.dev/docs/documentation/pack-docs#pack-keywords-tags-use-cases--categories) makes it easier for users to find the packs that suit their needs. | Yes | | PA121 | Validates no changes were made to the pack's price. | Changing this field affects paying customers. In the demisto/content repo, this requires a force-merge. | Yes | | PA123 | Validates the pack has at least one of the following: playbook, incident type or layout if the tags section contains the `Use Case` tag. | Correct categorization helps users find packs that suit their needs. | Yes | | PA124 | Validates core packs do not depend on non-core packs. | Core packs should be self-contained. | | | PA125 | Validates the pack name is valid. | Pack names should follow conventions for consistency and readability in the marketplace. | | | PA127 | Validates the pack metadata contains a valid URL field. | URLs help users access support or report issues for the pack directly. For more information, see the [fields in the pack\_metadata.json file](https://xsoar.pan.dev/docs/packs/packs-format#pack_metadatajson). | Yes | | PA128 | Checks for required pack files | These files are standard in the demisto/content repository. | Yes | | PA130 | Validates the `pack_metadata` version field is in valid format. | Content versions use semantic versioning to make it easy to tell how significant changes are between two versions. | | | PA131 | Validates the pack\_metadata contains a default data source if there is more than one data source. | Wizards and other tools rely on the default data source to be set. | Yes | | PA132 | Checks that the `pack_metadata` contains a valid default data source, when provided. | Wizards and other tools rely on the default data source to be set. | Yes |
PB: Playbook | Code | Description | Rationale | Autofixable | | ----- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | PB100 | Checks whether the playbook has a role name. If the Playbook has a role name it is not valid. | Playbooks out-of-the-box should not have a role set since this is customizable by the customer. | | | PB101 | Checks whether an ask conditional has a task with an unreachable next task condition. | If the condition cannot be reached the playbook cannot proceed to the next task. | | | PB103 | Checks whether there is an unconnected task. | Ensure there are no unconnected tasks so the playbook will work as expected. | | | PB104 | Checks whether a deprecated playbook has a valid description. | Ensures deprecated content descriptions are consistent. | | | PB105 | Checks whether the playbook has a `DeleteContext` script with all arguments set to Yes. | Playbooks with a `DeleteContext` script with all arguments set to Yes are not valid. | | | PB106 | Checks whether the playbook uses an instance. | If a playbook uses a specific instance it can leads to errors because not all the users have the same instance. | Yes | | PB108 | Checks that the task ID and the `id` under the `task` field are in UUID format. | Each task should have a unique ID in UUID format to avoid unknown behavior and breaking the playbook. | | | PB109 | Checks that the `taskid` field and the `id` field under the `task` field contain equal values. | System requirements | | | PB114 | Validates that playbooks for indicator types are on quiet mode. | Playbooks for indicators typically execute on thousands of indicators so they need to be on quiet mode. | Yes | | PB115 | Checks whether the `quietmode` field of all tasks in a playbook are not set to the default value. | Confirms whether quiet mode is turned off. | Yes | | PB116 | Checks that all playbook tasks stop when encountering an error. | For indicator playbooks, tasks typically execute on thousands of indicators. If a playbook task does not stop on errors, instances can crash and tasks relying on its output will fail. | | | PB118 | Checks that all inputs described in the playbooks input section are used in tasks. |

Depending on the task type that you select, and the script that you are running, your playbook task has inputs and outputs.

Inputs are data pieces that are present in the playbook or task. The inputs are often manipulated or enriched and they produce outputs. Outputs are objects whose entries will serve the tasks throughout the playbook, and they can be derived from the result of a task or command.

For more information, see Playbook inputs and outputs.

For more information, see Playbook inputs and outputs.

| | | PB119 | Checks that all inputs used are defined. | Inputs that are used but not provided to a playbook is probably an oversight. | | | PB122 | Checks whether branches of built-in conditional tasks are handled properly. | Ensures the playbook logic is correct. | | | PB123 | Checks whether an ask conditional has unhandled reply options. | Ensures the reply options are handled. | | | PB124 | Checks that all conditional tasks contain at least two next tasks. | Ensure unhandled cases are note missed in a playbook. | | | PB125 | Checks that a conditional task does not have only a default next task. | Ensures a conditional task has next tasks more than just the default next task so it implements different conditions. | | | PB126 | Checks that conditional tasks have an execution path besides for the default. | Ensures that conditional tasks have more execution paths than just the default path so they implement different conditions. | | | PB127 | Checks that any YAML keys that are Marketplace only have a default non-Marketplace counterpart. | To validate the existence of required YAML keys, we need to make sure that in addition to a specific Marketplace key (for example mykey:xsoar) there is also a basic key with no specific Marketplace (for example: mykey). | Yes |
PR: Parsing rule | Code | Description | Rationale | | ------- | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `PR101` | Checks that `id` and `name` in the parsing rule end with the correct suffixes. | To prevent confusion caused by ambiguous naming of modeling and parsing rules in the Cortex XSIAM UI, this validation ensures the rule ID and name end with `ParsingRule` or `Parsing Rule`. This helps avoid naming conflicts and improves clarity in release notes. |
RM: Readme | Code | Description | Rationale | | ----- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | RM100 | Checks that no default section is left empty with just headings. |

Ensures that there are no default leftovers such as:

| | RM101 | Checks image absolute paths, and prints the suggested path if it's not valid. | In official Marketplace content, ensures that the images can be used in the upload flow properly. | | RM102 | Validates all context outputs defined in the README file are present in the YAML file and vice versa. | Ensures consistency between the README and YAML files to maintain accurate documentation and prevent discrepancies. | | RM104 | Validates the pack contains a full README file with pack information. | Meaningful, complete documentation makes it easier for users to use the content. | | RM105 | Checks if the README file is not the same as the pack description. | An informative README helps users know more about the product and its uses. | | RM106 | Validates none of the README file lines contains the the word `demisto`. | Ensures that the current name of the product is used rather than the old one. | | RM107 | Checks if the generic sentence FILL HERE is in the README file. | Ensures the documentation is high quality. | | RM108 | Verifies images in the README and description files are relative and stored in `doc_files`. | Using relative references to files in the repository folder enhances security by reducing reliance on external links, minimizing the risk of link manipulation or redirection attacks. | | RM109 | Validates there is a README file for the content item. | Ensures the content item contains additional information about use cases, inputs, and outputs. | | RM110 | Validates all commands are mentioned in the README file. | Ensures all commands are documented in the README file to help users understand the available functionality. | | RM113 | Checks that none of the README lines contain the disallowed copyright section keywords. | Content in Marketplace is licensed under the MIT license. | | RM114 | Validates images in the `doc_files` folder used in the README file exist. | Missing images are not shown in rendered markdown. | | RM115 | Checks that no default auto generated sections remain empty. |

Ensures that there are no default leftovers such as:

| | RM116 | Validates the README file is not too short. | Ensures the README file contains sufficient information. |
RN: Release note | Code | Description | Rationale | | ------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | `RN103` | Validates the pack contains a full release notes file. | Meaningful, complete documentation makes it easier for users to use the content. | | `RN105` | Check that there is no more than one added release notes file for each pack. | More than one release notes file for a version may cause confusion and missing information. | | `RN108` | Validates a new pack does not have release notes. | New packs do not require release notes since they do not have any updates. | | `RN112` | Checks if breaking change release notes exist for packs with breaking changes, and they are documented correctly. | Breaking changes should be well documented so they can be available to users when updating versions. | | `RN114` | Validates content types are documented as first-level headers (####) and content items as second-level headers (#####) in the release notes. | Ensures documentation is accurate and clear. | | `RN116` | Validates the release notes have either a valid first level header or a valid force header. | Enforces proper release notes structure to ensure the documentation is readable. |
RP: Reputation (incident type) | Code | Description | Rationale | | ------- | ------------------------------------------------------------------ | ---------------------------------------- | | `RP101` | Validates the `expiration` field has a non-negative integer value. | To align with the platform requirements. | | `RP102` | Validates the `id` and `details` fields are equal. | To align with the platform requirements. | | `RP103` | Validates the incidator type `id` field has a valid value. | Ensures the indicator type ID is valid. |
SC: Script | Code | Description | Rationale | Autofixable | | ------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | `SC100` | Checks if the script name is versioned correctly, it must end with `V`. | Ensures consistency across content items. | Yes | | `SC105` | Checks that the script arguments do not contain the word `incident` in the core packs. | In the system, the word incident can be replaced by any other keyword of the user's choice. To ensure compatibility with this feature, command names, command arguments, and script arguments in core pack integrations and scripts should not use the word `incident`. This helps maintain the flexibility of the system and prevents potential issues caused by keyword replacement. | | | `SC106` | Checks that the script `runas` is not equal to `DBotRole`. | For security reasons, the `runas` field should not be set to `DBotRole`. | | | `SC109` | Validates there are no scripts with the same type and name. | Duplicate names cause confusion and unpredictable behavior. | |
ST: Structure | Code | Description | Rationale | | ------- | ---------------------------------------- | -------------------------------------------- | | `ST110` | Validates the schema structure is valid. | Ensures a valid structure for content items. |
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/demisto-sdk-development-guide/demisto-sdk-guide/demisto-sdk-commands/validate/validation-checks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.