# Configuring Network Policies

Once the network environment exists, the network facilitator can define rules that apply across that network. In Beckn, these rules are configured at the network level through a manifest published by the Network Facilitator Organization (NFO) for a specific `network_id`.

This allows all participants on that network to discover the same policy configuration and apply it consistently.

### What network policy configuration does

Network policy configuration gives the NFO a standard way to publish:

* which policy artifacts apply to the network
* where those policy artifacts are hosted
* how participants should evaluate them

In practice, this means the network can enforce shared business and validation rules without each participant implementing a separate, custom integration.

### The role of the manifest

The manifest is the network-level configuration document associated with a specific registry and `network_id`. It is typically published as a signed YAML file and linked from the metadata of the NFO's network registry.

Participants use the manifest to discover:

* the policy source type
* the artifact URL
* the evaluation query path
* the signing key information required for verification
* the governance validity window for that release

### Registry metadata required for policy discovery

The NFO registry should expose metadata that points to the manifest and its signature material.

The key fields are:

* `manifest_url`
* `manifest_signature_url`
* `signing_public_key_lookup_url`

This allows participants and ONIX instances to fetch the manifest and verify that it was published by the expected network authority.

### Policy configuration in the manifest

The manifest defines policy configuration inside the `policies` section.

At a high level:

* `type` identifies the policy language
* `source` identifies how the policy is distributed
* either a `bundle` section or a `file` section describes the final published artifact

#### Example using an OPA bundle

```yaml
policies:
  type: "rego"
  source: "bundle"

  bundle:
    id: "network-policy-bundle"
    url: "https://example.org/policies/bundle.tar.gz"
    policy_query_path: "data.retail.policy.result"
    signing_public_key_id: "key-reg/prod-policy-key"
```

#### Example using a single Rego file

```yaml
policies:
  type: "rego"
  source: "file"

  file:
    id: "network-policy-file"
    url: "https://example.org/policies/network.rego"
    policy_query_path: "data.retail.policy.result"
    signed: true
    signatureUrl: "https://example.org/policies/network.rego.sig"
    signing_public_key_id: "key-reg/prod-policy-key"
```

### Supported policy distribution models

At present, network policies can be distributed in two ways:

* as an **OPA bundle**
* as a single **Rego file**

Exactly one of these should be used for a given policy reference in the manifest.

The `policy_query_path` identifies the decision rule that participants should evaluate from that policy artifact.

### Recommended configuration flow

Use the following sequence when configuring policies for a network:

1. Decide which rules should be enforced at the network level.
2. Prepare the final published policy artifact for those rules.
3. Publish the artifact at a stable URL.
4. Add the `policies` section to the manifest for the target `network_id`.
5. Sign and publish the manifest.
6. Update the NFO registry metadata so participants can discover the latest manifest.

### Detailed guides

Use the following pages for the detailed operational steps:

* 3.3.1 [Creating and publishing the network manifest](https://docs.nfh.global/beckn/creating-an-open-network/configuring-network-policies/creating-and-publishing-the-network-manifest)
* 3.3.2 [Creating and publishing Rego policy artifacts](https://docs.nfh.global/beckn/creating-an-open-network/configuring-network-policies/creating-and-publishing-rego-policy-artifacts)


---

# Agent Instructions: 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:

```
GET https://docs.nfh.global/beckn/creating-an-open-network/configuring-network-policies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.