> For the complete documentation index, see [llms.txt](https://docs.nfh.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nfh.global/build/creating-a-network/network-policies/network-manifest.md).
# Creating and publishing the network manifest
This guide explains how a Network Facilitator Organization (NFO) can create, publish, and maintain a network manifest for an NFH fabric network.
## Guide for NFOs - Creating & Publishing Network Manifest
This guide explains how a Network Facilitator Organization (NFO) can create, publish, and maintain a network manifest for an NFH fabric network. The manifest is the control document for a given networkId and allows the NFO to publish network-level configuration in a discoverable, versioned, and verifiable way.
### 1. Overview
In NFH fabric, the networkId is tied to a specific registry maintained by the NFO. That registry represents the network boundary and acts as the network's root of trust. The network manifest is a signed YAML document associated with that registry and serves as the main release document for network-level configuration.
Participants can use the manifest to discover:
* which policies apply to the network
* where those policy artifacts are hosted
* whether observability is enabled
* where telemetry configuration and collector endpoints are defined
The manifest itself can be hosted by the NFO at any stable URL. The URL and signature metadata are then published as metadata on the NFO's network registry, allowing participants to resolve the current network configuration for that networkId.
### 2. Where the manifest is referenced
The NFO should attach manifest-related metadata to the network registry on DeDi Global. This allows participants and ONIX instances to discover the manifest for a specific networkId.
The registry metadata should contain:
| Field | Description |
| ------------------------- | ------------------------------------------------------------------ |
| manifestUrl | URL of the network manifest file |
| manifestSignatureUrl | URL of the detached signature for the manifest |
| signingPublicKeyLookupUrl | Lookup URL of the public key used to verify the manifest signature |
The signing public key referenced here should be retrievable through the registry lookup URL so that participants can verify the authenticity and integrity of the manifest.
### 3. Relationship between registry and network ID
The networkId is formed from:
```
/
```
For example:
```
example-nfo.com/production
```
This means each network registry has its own manifest and its own network configuration. In practice, NFOs usually maintain separate registries and manifest for each environment boundary they are defining using their registries.
### 4. Manifest structure
The manifest is a YAML document for a specific network release. A typical manifest looks like this:
```
manifestVersion: "1.0"
manifestType: "network-manifest"
networkId: "nfo.com/production"
releaseId: 2026.02
publisher:
role: "NFO"
domain: "nfo.example.org"
policies:
type: "rego"
source: "bundle"
bundle:
id: "network-policy-bundle-v0.1"
url: "https://nfo.example.org/policies/network-policy-bundle-0.1.tar.gz"
policyQueryPath: "data.retail.validation.result"
signingPublicKeyLookupUrl: "ac0bc933-3862-481d-ac8b-d87642a5e994"
observability:
enabled: true
config:
url: "https://nfo.example.org/observ/fields.yaml"
signed: true
signatureUrl: "https://nfo.example.org/observ/fields.yaml.sig"
signingPublicKeyLookupUrl: "ac0bc933-3862-481d-ac8b-d87642a5e994"
collector:
url: "https://telemetry.nfo.example.org/v1/network/events"
governance:
effectiveFrom: "2026-03-10T00:00:00Z"
effectiveUntil: "2027-03-10T00:00:00Z"
signed: true
```
### 5. Top-level fields
| Field | Required | Description |
| --------------- | -------- | ------------------------------------------------ |
| manifestVersion | Yes | Version of the manifest schema |
| manifestType | Yes | Must be network-manifest |
| networkId | Yes | Network the manifest applies to |
| releaseId | Yes | Release identifier for this manifest version |
| publisher | Yes | Publisher identity information |
| policies | No | Policy distribution and evaluation configuration |
| observability | No | Telemetry and observability configuration |
| governance | Yes | Validity period and signature state |
#### Publisher
| Field | Required | Description |
| ------ | -------- | --------------------------------- |
| role | Yes | Publisher role, typically NFO |
| domain | Yes | Domain representing the publisher |
### 6. Defining policies in the manifest
The manifest can point to network policies written in Rego. Policies may be distributed either as:
* an OPA bundle
* a single Rego file
The policies section must declare the source format and the evaluation query path.
#### Policy section rules
* type must currently be rego
* source must be either bundle or file
* exactly one of bundle or file must be present
#### Example using an OPA bundle
```
policies:
type: "rego"
source: "bundle"
bundle:
id: "network-policy-bundle"
url: "https://example.org/policies/bundle.tar.gz"
policyQueryPath: "data.retail.policy.result"
signingPublicKeyLookupUrl: "key-reg/prod-policy-key"
```
#### Example using a single Rego file
```
policies:
type: "rego"
source: "file"
file:
id: "network-policy-file"
url: "https://example.org/policies/network.rego"
policyQueryPath: "data.retail.policy.result"
signed: true
signatureUrl: "https://example.org/policies/network.rego.sig"
signingPublicKeyLookupUrl: "https://fabric.nfh.global/dedi/lookup/nfo.org/key-reg/prod-policy-key"
```
The `policyQueryPath` field should point to the decision rule that participants evaluate for that policy artifact.
### 7. Creating and publishing policy artifacts
Detailed guidance for policy authors, including the expected policy output contract, repository structure, build steps, signing flow, testing process, and publication of the final artifact, is covered in the separate guide: [Creating and publishing Rego policy artifacts](/build/creating-a-network/network-policies/rego-policies.md).
In the manifest, the NFO only needs to reference the final published artifact using the appropriate bundle or file section.
### 8. Defining observability in the manifest
The manifest can also define network observability settings. This allows the NFO to standardize what telemetry participants emit and where that telemetry is sent as part of the network release.
#### Observability fields
| Field | Required | Description |
| --------------------------------------- | ----------- | ---------------------------------------- |
| observability.enabled | Yes | Enables observability when true |
| observability.config.url | Conditional | URL of the observability config document |
| observability.config.signed | Conditional | Whether the config is signed |
| observability.config.signatureUrl | Conditional | Detached signature URL when signed |
| observability.config.signingPublicKeyId | Conditional | Key identifier used for verification |
| observability.collector.url | Conditional | Endpoint receiving telemetry events |
#### Example
```
observability:
enabled: true
config:
url: "https://nfo.example.org/observ/fields.yaml"
signed: true
signatureUrl: "https://nfo.example.org/observ/fields.yaml.sig"
signingPublicKeyLookupUrl: "key-reg/prod-policy-key"
collector:
url: "https://telemetry.nfo.example.org/v1/network/events"
```
The observability config document can describe required and optional telemetry fields or other network-wide telemetry rules. Participants should verify the configuration before using it. Please refer the [observability guide](https://github.com/beckn/beckn-onix/blob/main/pkg/plugin/implementation/otelsetup/OBSERVABILITY.md#audit-fields-configuration-configaudit-fieldsyaml) for the understanding the `config.url` parameter and how observability can be set up in ONIX.
### 9. Governance section
The governance section defines the validity window of the manifest.
Example:
```
governance:
effectiveFrom: "2026-03-10T00:00:00Z"
effectiveUntil: "2027-03-10T00:00:00Z"
signed: true
```
#### Governance rules
* effectiveFrom defines when the manifest becomes active
* if effectiveUntil is present, it must be later than effectiveFrom
* once the current time passes effectiveUntil, the manifest should be treated as expired
* if the manifest is signed, the detached signature and key lookup information must be available through registry metadata
### 10. Suggested publishing workflow
Use this sequence when publishing or updating a manifest:
1. Create or update policy artifacts.
2. Create or update observability configuration if required.
3. Publish all referenced files at stable URLs.
4. Create the manifest YAML for the target networkId.
5. Sign the manifest. You can use [this guide](/build/creating-a-network/network-policies/signing-files.md) to sign the manifest file.
6. Publish the manifest and detached signature.
7. Update the NFO registry metadata with manifestUrl, manifestSignatureUrl, and signingPublicKeyLookupUrl.
8. Roll out the new release and communicate the new releaseId to participants if needed.
{% hint style="info" icon="lightbulb" %}
Once published, NPs can configure the same on their ONIX instances using the [policy checker](https://github.com/beckn/beckn-onix/tree/main/pkg/plugin/implementation/opapolicychecker) plugin.
{% endhint %}
### 11. Operational recommendations
* version releases clearly using releaseId
* keep artifact URLs stable and preferably immutable
* test policies before publishing them into production manifests
* avoid mixing unrelated policy changes and observability changes in one release unless necessary
* ensure registry metadata always points to the currently intended manifest for that network
The manifest is the NFO's main distribution mechanism for network-level configuration. Treat it as a versioned, signed contract between the NFO and all participants operating on that networkId.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.nfh.global/build/creating-a-network/network-policies/network-manifest.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.