Validation checks - Demisto SDK Guide - Cortex

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. How to deprecate a pack Ensure all the pack's integrations, scripts and playbooks are deprecated. Deprecate the pack using one of the following methods. Run `demisto-sdk format -i Packs/<pack-name>/pack_metadata.json -d` only if all the pack's integrations, scripts and playbooks are deprecated. Add to the name of the pack in the `pack_metadata.json` the suffix `(Deprecated)` and add to the pack description in the `pack_metadata.json` one of the following formats: "Deprecated. Use {OTHER_PACK_NAME} instead." "Deprecated. {Optional: REASON} No available replacement." To optionally hide a pack, manually add the `"hidden": true` key to the `pack_metadata.json` file.
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.

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 an 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 of 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.

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

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.

Code	Description	Rationale	Autofixable
DA100	Validates the dashboard excludes all the unrequired 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.

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.	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

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 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 dot.	Ensures documentation standards.	Yes

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.

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. How to add a test playbook to your pack Save your newly created test playbook to the `TestPlaybooks` directory in your content item. In the playbook YAML file that you created, edit the `id` field so it is identical to the `name` field. Modify the value in the `version` field to -1 to prevent user changes. For example: id: IPInfo_Test version: -1 name: IPInfo_Test Add the ID of the test playbook to the YAML of your content item under the `tests` key. For example: tests: - Test Playbook Name
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.

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 `multySelect` 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

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
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 the default ones.
IM108	Checks that the author image file is not empty.	If an author image is provided, it must be valid. About the author image file It's possible to add an author image, which is a logo of the contributing company, to be displayed on the Marketplace page of the pack, under the PUBLISHER section. The image should be saved in the root directory of the pack (for example, under `content/packs/MyPackName`), be named `Author_image.png`, and have a maximum size of up to 4 KB and dimensions of 120x50 pixels.
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.

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 more about generic reputation commands.
IN102	Validates the checkbox parameter is configured correctly with required argument set to false.	A checkbox parameter that is required will fail (count 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 the Integrations category is valid.	See the list of allowed categories in the platform.
IN106	Validates the command is valid as a reputation command.	Reputation commands 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.
IN108	Checks whether the subtype is valid.	This field describes the major Python version, `python2` or `python3`.
IN109	Validates 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 word `beta`. This ensures unambiguous identification of production-ready integrations.	Yes
IN112	Validates the display name 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 behaviors.
IN114	Checks that there are no duplicated parameters for the integration.	Duplicate parameters cause confusion and unpredictable behaviors.
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.
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.
IN122	Checks that all existing parameters are in the correct format for feed parameters.	Malformed or missing parameters can lead to errors or incomplete data. Read about feed integrations.
IN123	Checks if the integration display name is versioned correctly.	Integration display names should end with `v<number>` 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` param has a default value.	To maintain optimal load in the platform, the maximum number of incidents per fetch is limited.	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 details, see https://xsoar.pan.dev/docs/integrations/fetching-incidents#first-run.
IN127	Checks that a deprecated integration display name ends with `(Deprecated)`.	Deprecated integrations should end with (Deprecated) in the display name to clearly indicate their status. This prevents inadvertent use of unsupported integrations. Read more about deprecation.	Yes
IN130	Checks that the integration is runable.	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 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 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 more about generic endpoint commands.
IN142	Checks that the integration contains the right `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 more about reputation commands.
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 more about credentials.
IN146	Checks that there is no `fromlicense` parameter field in non Cortex XSOAR supported integrations.	The `fromlicense` param 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.	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 that the URL default parameter starts with `https` rather than `http`.	URL parameters should default to `https` for secure communication, as c could expose sensitive data.	Yes
IN154	Checks that feed integrations and integrations with reputation commands have a reliability parameter.	The reliability parameter 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.
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 for reputation commands.
IN160	Checks that the display name for non-deprecated integration doesn't end with `(Deprecated)`.	Avoids confusion and ensures that users are correctly informed about the integration's status. Read more about deprecation.
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 for event collection integrations.	Yes
IN162	Checks that the support level header for a collector integration in a partner pack is set to `XSOAR`.	Collector integrations in partner packs should specify `{XSOAR_SUPPORT}` level support to inform users about the support level provided by Cortex XSOAR. Read more about the support level header.	Yes
IN163	Checks that the `feedExpirationPolicy` parameter is in the right format for both incremental and fully fetched feeds.	Malformed expiration policy can lead to errors or incomplete data. For more details,	Yes

Code	Description	Rationale
IT100	Checks if the included fields have a positive integer value.	Fields that have to be included cannot be type integer.
IT101	Checks if the playbook ID is valid.	The playbook ID has to be non-UUID format.
IT102	Checks if the `extractSettings` field is valid.	The `extractSettings` field needs to be in the correct format.
IT103	Checks if the auto extract mode valid.	The auto extract mode possible options are: All: To extract all indicator types regardless of auto-extract settings. Specific: To extract only the specific indicator types set in the auto-extract settings.

Code	Description	Rationale
LO107	Checks that only supported types are used in the layout for Cortex XSIAM compatibility.	Limited by the platform.

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.

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.	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.
PA102	Validates the pack is deprecated if it needs to be.	Ensures clarity for users and prevents potential confusion of deprecated content.	Yes
PA103	Validates the pack categories are valid.	See list of allowed 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: `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.
PA118	Validates the metadata's certification field is valid.	See list of allowed certifications in the platform:
PA119	Validates the metadata's use cases field include valid use cases.	See list of allowed useCases in the platform.	Yes
PA120	Validates the metadata's tag section includes only approved tags.	Using approved tags 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.	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

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

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.

Code	Description	Rationale
RM100	Checks that no default section is left empty with just headings.	Ensures that there are no default leftovers such as: FILL IN REQUIRED PERMISSIONS HERE.. Unexplicit version numbers such as version xx of.. Default description belonging to one of the example integrations
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: FILL IN REQUIRED PERMISSIONS HERE.. Unexplicit version numbers such as version xx of.. Default description belonging to one of the example integrations
RM116	Validates the README file is not too short.	Ensures the README file contains sufficient information.

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.

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.

Code	Description	Rationale	Autofixable
SC100	Checks if the script name is versioned correctly, it must end with `V<number>`.	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.