Skip to main content


A Package is a collection of related policies consisting of Rego rules and helper functions. Each package has its unique name and organizes its policies.

The following data sources and packages are added by default when a new Custom system is created.


The data sources and packages provide a starting point for new users. Therefore, you can delete these resources from your Custom system when required.

  • features: A package that allows you to define rich data that a stack can use in its rule implementations.

  • labels: A package that identifies your system and describe its purpose (e.g., production), contracts (e.g., pci-compliant), lifecycle (e.g., release), and other characteristics.

  • monitor: A package that defines the results displayed in the Compliance pane for this system and in the Validate results pane. For more information on package monitor, see the Compliance section.

  • rules: A package that is intended to be the place where you write your policies.

  • system.log: A package that is intended to be the place where you specify the policy to remove any sensitive data before uploading the decision to the package system.log.

  • test: A package that is used to write OPA unit tests. Run the unit tests with the Validate button in the policy editor.

  • dataset: A data source that is intended to be the place where you can create dynamic or static JSON data for your policies.

Reserved Packages

Another important concept about packages is that the DAS reserves a small number of package paths.

The following package names may not be used:

  • global: References all of the Rego code in the Library.

  • system: Reserved by OPA for decision log (system.log) and authorization (system.authz).

  • styra: Reserved for future internal functionality.

  • metadata: Reserved for data about the system as a whole. For example, labels.

  • monitor: Used for computing compliance violations.

  • stock packages for a Custom System: rules, test, monitor.


With OPA, you can put any Rego package into any file in the file system, irrespective of the directory path. With the DAS, you have the following limitations to create packages under directories in a hierarchical form.


The file name of a package’s module file does not have to correspond to the last segment of the package name.

The directory path must match the package path as shown in the following examples.

  1. The package api.retail must exist in a file located under the directory api/retail.

    ├── Your Custom System
    ├── api
    ├── retail
    ├── retail_rules.rego //must declare `package api.retail`
  2. The package common must exist in a file located under the top-level directory common.

    1. You are not allowed to create a package common in the directory api.

    2. No package may be a prefix of another package. For example, if you have one file with package api.retail, then you may not have a separate file with package api.

    ├── Your Custom System
    ├── api
    ├── common_rules.rego //cannot have `package api` in `package api.retail`
    ├── retail
    ├── retail_rules.rego // package api.retail
    ├── common
    ├── common_rules.rego // must declare package `common`
  3. Packages can share a prefix like package, package api.retail, and a package can have more than one module file.

    ├── Your Custom System
    ├── api
    ├── finance
    ├── finance_rules.rego // must declare `package`
    ├── retail
    ├── retail_rules.rego
    ├── retail_more_rules.rego // must declare `package api.retail`
    ├── common
    ├── common_rules.rego

You cannot create a Rego file in any of the directories for a package, except the final directory containing the first Rego file for the package.

In the following hierarchy, the package common is defined right at the top, so there is no top level package prefix that can be shared.

├── common
├── common_rules.rego