> ## Documentation Index > Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt > Use this file to discover all available pages before exploring further. # Add custom validation > How to add custom validation for limit structures, limits, and incidents in Atoti Limits, covering the default validation checks for each object type and how to extend or override individual validators and error handlers This section describes how to create custom validators, validation errors, and validation error handlers in Atoti Limits. [Limit structures](../../user-ref/datastore/limit-structures), [limits](../../user-ref/datastore/limits-store), and [incidents](../../user-ref/datastore/incident-store) are validated whenever they are created or updated. The default implementations of these validation interfaces provide reasonable checks to promote data quality, but you may wish to customize or extend these checks to suit your organization’s needs. Implementing custom validation is not required, but it can be useful for enforcing business rules or data quality standards. Additionally, any single component or combination of these components can be customized, and any components not customized will use default implementations. For example, you could choose to implement a custom `ILimitValidator` but use `DefaultLimitStructureValidator` and `DefaultIncidentValidator`. Alternatively, you could choose to implement a custom `IValidationErrorHandler` that overrides `DefaultValidationErrorHandler` in the default validators. ## A note on the default validation behavior The default implementations of the validation interfaces are agnostic to the source of the data being validated. However, there is different behavior for the initial load of limits via `ILimitsFileLoadingService` and limits loaded through REST, like [file upload](../../user-ref/using-limits/create-limit/create-limit-upload). For the initial load of limits, the validation is non-blocking, meaning that the system will proceed with publishing the valid limits even if some fail validation. When limits are loaded through REST, the validation is atomic, meaning that the system will not publish any limits if even one fails validation. This is because errors with limits in the initial load are likely to be addressed by an administrator/developer and should not block business users. However, loading through the UI (file upload) is more likely to be done by a business user and needs to have better enforcement of data integrity. ## Checks performed in the default validators This section describes the validation performed by the default validators for limit structures, limits, and incidents. ### Default limit structure validation

Field	Validation performed
Structure ID	Value must be non-null, non-empty, and unique. This field is validated regardless of the ID being provided or generated.
Name	Value must be non-null, non-empty, and unique.
Server Name	Value must be a valid server name in the current list of connections to Atoti Limits.
Cube Name	Value must be a valid cube name in the current list of cubes for the specified server.
Measure Name	Value must be a valid measure name in the specified cube OR a calculated measure saved in the content server.
Scope Keys	Value must contain the name of at least one level, and all levels expressed must exist in the specified cube.
Polling Frequency	Value must be a valid PollingFrequency enum (`EOD` or `INTRADAY`).
KPI Type	Value must be either `Greater Than` or `Less Than`.
Limit Changes Workflow Parameters	If the value for `Limit Changes Workflow` is `StraightThrough` or not provided (will default to `StraightThrough`), this field can be null. For all other workflow types, this field must be a valid map containing at least one field+value pair.

### Default limit validation

Field	Validation performed
Limit ID	Value must be non-null, non-empty, and unique. This field is validated regardless of the ID being provided or generated.
Structure ID	Value must be a valid ID for an existing limit structure.
Scope	If the scope is aggregated (see advanced scopes), the structure this limit is being created on must not contain any live limits. Similarly, attempting to create a limit with any scope on a structure that contains an existing limit with an aggregated scope will result in a validation error.
Start Date	Value must be a valid date in ISO-8601 format (`yyyy-MM-dd`).
End Date	If provided, value must be a valid date in ISO-8601 format (`yyyy-MM-dd`) and must not fall before the `Start Date`.
Limit Type	Value must be a valid LimitType enum (`OFFICIAL` or `TEMPORARY`).

#### Limit overlapping date validation The default limit validator also checks for overlapping dates between limits. Limits are considered to overlap if they have the same `Structure ID`, `Scope`, and `LimitType` **AND** if there is even a single day of overlap between the date ranges represented by each limit’s `Start Date` and `End Date`. #### Temporary limit validation In addition to the checks above, temporary limits require some extra validation: * `End Date` must be provided. The overlapping date validation still applies to temporary limits. * `Source Limit ID` must be provided and the value must be a valid ID for a limit with `Limit Type = OFFICIAL`. ### Default incident validation

Field	Validation performed
Incident ID	Value must be non-null, non-empty, and unique. This field is validated regardless of if the ID was provided or generated.
Limit ID	Value must be a valid ID for an existing limit.