---
schema_version: "1"
id: c45a27c4dc652709e3350636e68019b5e32784f9f4dff3941e45fcfc51c7b328
title: Creating a Unified-Model (Regular) Policy Project
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/pdk/1.9/policies-pdk-create-project.md
canonical_url: https://docs.mulesoft.com/pdk/1.9/policies-pdk-create-project
source_site: docs.mulesoft.com
content_type: documentation
content_hash: d886cfd88a0601d54d2eb5480b50561cddf0ac1de3637356afafe100a2a0202b
description: MuleSoft Documentation Site
release: "1.9"
latest: false
---
---
product: Omni Gateway Policy Development Kit (PDK)
version: 1.9
---

# Creating a Unified-Model (Regular) Policy Project

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To begin developing a new custom policy with Omni Gateway Policy Development Kit (PDK), generate a
new custom policy project.

To create a new project, complete the following tasks:

1.  [Before You Begin](#before-you-begin)

2.  [Create a New Policy Project](#create-a-new-policy-project)

3.  [Set Up the PDK Build Environment](#setup-the-pdk-build-environment)

4.  Review [Project Structure](#project-structure)

## Before You Begin

Before you can create a custom policy project, ensure that you have installed all
[PDK prerequisites](https://docs.mulesoft.com/pdk/1.9/policies-pdk-prerequisites).

## Create a New Policy Project

To create a custom policy project, run the PDK CLI `create` command, replacing `<my-custom-policy>`
with the name of your new policy:

```ssh
anypoint-cli-v4 pdk policy-project create --name <my-custom-policy>
```

> [!NOTE] If you receive a prompt requesting your group ID, see
> [Troubleshooting Group ID](https://docs.mulesoft.com/pdk/1.9/policies-pdk-troubleshooting#group-id-error).

Running the `create` command creates a custom policy project with the specified name. The project
appears in a new directory with the same name as your policy or a directory specified using the
`--output-dir` flag. The following tutorials refer to this as your project’s root directory.

The `assetID` of the new policy is the policy’s name in lower case with the spaces amended together
with a `-`. For example, a policy with the name `My Header Injection Policy` has the `assetID` of
`my-header-injection-policy`.

The `groupID` of the new policy is the ID of the organization configured in Anypoint CLI.

The `create` command supports the following flags:

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Flag</th><th>Default Value</th><th>Required</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>--name=&lt;value&gt;</code> or <code>-n</code></p></div></div></td><td><div><div><p>N/A</p></div></div></td><td><div><div><p>Yes</p></div></div></td><td><div><div><p>Name of the new policy.</p></div></div></td></tr><tr><td><div><div><p><code>--description=&lt;value&gt;</code> or <code>-d</code></p></div></div></td><td><div><div><p>N/A</p></div></div></td><td><div><div><p>No</p></div></div></td><td><div><div><p>Description of the new policy.</p></div></div></td></tr><tr><td><div><div><p><code>--output-dir=&lt;value&gt;</code> of <code>-o</code></p></div></div></td><td><div><div><p><code>assetID</code></p></div></div></td><td><div><div><p>No</p></div></div></td><td><div><div><p>Directory the new policy is created in.<br>If the directory does not exist, it is created. If no directory is specified, the directory name is the policy <code>assetID</code>.</p></div></div></td></tr><tr><td><div><div><p><code>--version=&lt;value&gt;</code></p></div></div></td><td><div><div><p><code>1.0.0</code></p></div></div></td><td><div><div><p>No</p></div></div></td><td><div><div><p>Version of the new policy.<br>The version format is <code>&lt;major-release&gt;.&lt;minor-release&gt;.&lt;patch-release&gt;</code>.</p></div></div></td></tr><tr><td><div><div><p><code>--group-id=&lt;value&gt;</code></p></div></div></td><td><div><div><p>N/A</p></div></div></td><td><div><div><p>No</p></div></div></td><td><div><div><p>Organization ID of the organization that owns the policy.<br>For additional information about this flag, see <a href="https://docs.mulesoft.com/pdk/1.9/policies-pdk-troubleshooting#group-id-error">Troubleshooting Group ID</a>.</p></div></div></td></tr><tr><td><div><div><p><code>--fips</code></p></div></div></td><td><div><div><p>N/A</p></div></div></td><td><div><div><p>No</p></div></div></td><td><div><div><p>Creates the policy project with FIPS compliance enabled.<br>Configures the PDK to use FIPS-compliant modules. To maintain FIPS compliance, make sure any additional dependencies you add are compliant.</p></div></div></td></tr></tbody></table>

## Set Up the PDK Build Environment

After you [create a new policy project](#create-a-new-policy-project), you must run the `make setup`
command to download additional software dependencies:

```ssh
make setup
```

## Project Structure

After running the `make setup` command, the policy’s root directory contains the following
directories and files shown in the directory tree:

├─ definition/ # Contains the files that describe the policy Definition │ ├── target/ # Contains the
build definition asset files │ └── gcl.yaml # GCL file managed by the developer that describes the
policy Definition ├─ target/ # Contains the implementation asset files and the output of the policy
build ├─ src/ # Contains the implementation source code ├─ playground/ # Contains the artifacts
required for running the policy locally ├─ tests/ # Contains the source and configuration files to
write and run integration tests ├─ Makefile # Provides all the callable actions required during the
policy development lifecycle ├─ Cargo.toml # Rust language standard file that contains the metadata
required to build the policy ├─ AGENTS.md # Documentation for AI coding agents working with the
policy project └─.project.yaml # Project manifest used by PDK

### target/ and definition/target/

There are two separate `target` directories:

- `definition/target/`: Contains the policy asset definition published to Exchange.

- `target/`: Contains the files for the policy’s Exchange asset implementation and the output of the
  project build.

Both target directories and their content are included in the `.gitignore` file. You must compile
the targets on each individual devices using the `make build` command. For example, if you develop a
policy as part of the team, your team can publish the policy and its source code to a remote
repository, but each team member must build the target on their device to work with the policy.

### definition/

The `definition` directory contains the `gcl.yaml` file that defines the policy’s metadata and the
configuration properties.

To configure the `gcl.yaml` file, see
[Defining a Policy Schema Definition](https://docs.mulesoft.com/pdk/1.9/policies-pdk-create-schema-definition).

### Cargo.toml

Custom policies for Omni Gateway are developed in the Rust programming language and compiled to a
WebAssembly binary.

The `Cargo.toml` is the Rust project manifest. Its `[package]` section contains the basic
information about the policy implementation. The version specified in `Cargo.toml` matches the
policy asset version. You can manage the policy version by editing the version number in
`Cargo.toml`. The version follows the format `<major-version>.<minor-version>.<patch-version>`.

#### Configure PDK Features in Cargo.toml

The JWT and XML Validator libraries are gated behind Cargo features to reduce compiled WASM size.
Both features are enabled by default (`default = ["jwt", "xml_validator"]`).

If you don’t require JWT or XML validation functionality in your custom policy, you can disable
these features by editing the PDK dependency in your `Cargo.toml`:

```toml
# Disable both JWT and XML Validator:
pdk = { version = "1.9.1", default-features = false }

# Keep only JWT:
pdk = { version = "1.9.1", default-features = false, features = ["jwt"] }

# Keep only XML Validator:
pdk = { version = "1.9.1", default-features = false, features = ["xml_validator"] }
```

### src/

The `src` directory contains the policy’s source code:

- `lib.rs`: Contains a set of methods that implement the behavior of the policy. PDK includes these
  methods to implement custom policies behavior. For additional information about these methods, see
  [Implementing Your Custom Policy Features in Rust](https://docs.mulesoft.com/pdk/1.9/policies-pdk-configure-features). For complete
  policy examples, see [Custom Policy Examples](https://docs.mulesoft.com/pdk/1.9/policies-pdk-policy-templates).

- `generated/config.rs` and `generated/mod.rs`: Auto-generated modules that make the policy
  configuration, as defined in the `gcl.yaml`, available for use in the `lib.rs` and any of the
  policy source files.

### Makefile

The Makefile contains all the callable actions, such as `make` commands, required for the policy
development lifecycle. Execute all `make` commands at the root level of your custom policy directory
directory:

- `make setup`: Installs PDK internal dependencies for the rest of the Makefile goals.

  For more information about setting up your project, see
  [Set Up the PDK Build Environment](#setup-the-pdk-build-environment).

- `make build-asset-files`: Generates all the policy asset files required to build, execute, and
  publish the policy. This command also updates the `config.rs` source code file with the latest
  configurations defined in the `gcl.yaml` file.

  For more information about compiling a policy, see
  [Compiling Custom Policies](https://docs.mulesoft.com/pdk/1.9/policies-pdk-compile-policies).

- `make build`: Runs the `make build-asset-files` command and compiles the WebAssembly binary of the
  policy.

  For more information about compiling a policy, see
  [Compiling Custom Policies](https://docs.mulesoft.com/pdk/1.9/policies-pdk-compile-policies).

- `make run`: Provides a simple way to execute the current build of the policy in a Docker
  containerized environment.

  For more information about running and debugging your policy, see
  [Debugging Custom Policies with the PDK Debugging Playground](https://docs.mulesoft.com/pdk/1.9/policies-pdk-debug-local).

- `make test`: Executes the tests contained in `tests/` by using the testing framework provided by
  PDK.

  For more information about testing your policy, see
  [Writing Integration Tests](https://docs.mulesoft.com/pdk/1.9/policies-pdk-integration-tests).

- `make publish`: Publishes the policy asset in Exchange.

  For more information about publishing policies in Exchange, see
  [Publishing Unified-Model Policies to Exchange](https://docs.mulesoft.com/pdk/1.9/policies-pdk-publish-policies).

- `make release`: Releases the policy asset in Exchange.

  For more information about releasing policies in Exchange, see
  [Publishing Unified-Model Policies to Exchange](https://docs.mulesoft.com/pdk/1.9/policies-pdk-publish-policies).

- `make help`: Lists all the `make` commands provided by PDK.

### AGENTS.md

The `AGENTS.md` file provides documentation and guidance for AI coding agents (such as Claude Code,
GitHub Copilot, or other AI assistants) working with the custom policy project. This documentation
enables AI assistants to provide more accurate code suggestions and helps prevent common errors when
working with PDK projects. This file includes:

- Repository purpose and architecture overview

- Project structure explanation

- proxy-wasm runtime constraints and limitations

- Coding rules and best practices specific to PDK policies

- Critical pitfalls to avoid when developing policies

- Links to relevant PDK documentation and policy examples

## See Also

- [PDK Troubleshooting](https://docs.mulesoft.com/pdk/1.9/policies-pdk-troubleshooting)